Update
Safety-related design
in microprocessor-based
automotive applications
Designers of increasingly complex automotive control systems are considering
ways to maintain the safety record of these systems. In this feature three contributors
consider hardware and formal methods-based software approaches to this problem
The use of computers in safety-related applications has
increased greatly in the last five years. Wider awareness and
public concern and the implications of various govern-
ment directives have placed safety-critical assessment high
on the agenda of computing design. At a recent lEE
colloquium on 'Safety critical software in vehicle and traffic
control" (London, UK, 13 February 1990) some of the key
issues on this agenda were raised within the particular
context of automotive and traffic control applications. To
widen this debate this topical feature presents edited
extracts from three presentations given at the colloquium
which focus on the use of microprocessors in such
systems: one a hardware architectural approach, and two
advocating the use of formal methods for the design of
'correct" software.
microsystems safety-criticalcomputing automotivecontrol
software design formalmethods
SYSTEM ARCHITECTURES FOR SAFETY
CRITICAL AUTOMOTIVE APPLICATIONS
John M i l l w a r d
Microprocessor-based control systems are now common-
place in vehicles. They have traditionally been employed
in systems where a failure will cause inconvenience but
the consequential hazard potential is low (except perhaps
automatic braking systems). These systems usually have a
well defined safe state. Many manufacturers and com-
ponent suppliers are now experimenting with systems
whose failure can have much more serious consequences
such as: control by wire and supervisory systems, which
can override the driver's inputs; and complex inter-
connected systems where one failure can effect several
others. The safety record of automotive electronic
systems has been very good, but to maintain this situation
the safety and reliability attained by these systems must
increase at a rate equal to their complexity.
Lucas Automotive, Advanced Engineering Centre, Dog Kennel Lane,
Shirley, Solihull, West Midlands B90 4JJ, UK
0141-9331/90/05318-7 © 1990 Buttena/orth-Heinemann Ltd
378
Sources of failure
Random failures. Random failures of electrical com-
ponents, connections, wiring and mechanical devices are
amenable to statistical prediction. Although the task is
not simple, due to the number of components and in
some cases the lack of data on which to base the
predictions, failure probabilities can be produced. These
figures together with an FMEA analysis can be used to
estimate the hazard potential and hence the acceptability
of the system. Improved computer assistance with these
processes together with a pool of freely available
predicted and achieved reliability data would be of
benefit.
Systematic errors. Systematic errors can occur in the
system requirements, the hardware design orthe software
design. They are not random: given the same input
conditions the same incorrect behaviour will occur. They
are the result of human error in the design process or the
design of the tools used in the process, and therefore
render the supplier morally and legally liable for any
consequences. There is no adequate method for pre-
dicting the probability of such failures in typical auto-
motive control systems and it is therefore a question of
engineering judgement as to how much effort, and hence
cost, is incurred in trying to prevent their occurrence. This
judgement may have to be defended (in court), causing
pressure to always use the best possible practices
regardless of the immunity of the system to random and
interference type failures. The adoption of an inter-
nationally agreed standard on classification of systems (for
example by hazard analysis) and the procedures necessary
for each class seems the best current option. Adherence
to these standards would then be cited as a defence in
liability claims.
Intermittent failures. Intermittent failures, particularly
those caused by EMC problems are difficult to predict and
also depend on factors outside the supplier's control,
such as the environment in which the vehicle will operate.
Again an internationally agreed test standard, adherence
to which can be used as a defence in liability claims,
seems the best current solution.
Microprocessors and Microsystems

System architectures for systems with a
safe state
The classic approach to achieving the required system
safety level is to provide redundancy in some form. This
improves safety at the expense of reliability. A typical
architecture for a dual redundant system is shown in
Figure 1.
This system uses two identical channels, each of which
performs exactly the same function. The outputs of the
two channels are then compared and if they are found to
be different the system is shut down into its fail-safe state.
This architecture is very effective at identifying com-
ponent failures within the ECU. It will also identify
intermittent faults which affect only one channel, but
since the channels are identical there is a significant risk of
a common mode type of failure. A systematic fault in the
hardware design will produce identical but incorrect
outputs on both channels and hence will not be
detected. The same argument is true for software errors
and errors in the system specification. This type of
architecture can give the fastest and most reliable
detection of random component failures but its use
places very high demands on the integrity of all stages of
the system design.
A variation on this architecture is to use different types
of microprocessor for each channel. The software for each
channel can also be written by different teams, thus
reducing, although not eliminating, the possibility of
common software errors. This architecture reduces the
likelihood of common mode failures but since the
internal processing of the data may be different, thus
preventing direct comparison of intermediate results,
both the time taken and the reliability of failure detection
can be adversely affected. It is for this reason that some
very high integrity systems (e.g. A320 fly-by-wire system)
use a combination of both architectures. It is important to
note that this architecture offers no protection against an
error in the original system requirements or specifications;
in this case both channels will agree on the incorrect
action.
It is this author's belief that specification error is the
most serious problem facing the designers of future
automotive systems. Improvements have taken place
in the translation of specifications into hardware and
software but the problems of specifying the correct
outputs, for every combination of inputs, in every
possible scenario, of complex interconnected systems
have still to be resolved.
An altemative architecture is shown in Figure 2. This
architecture has two dissimilar channels. Moreover these
channels perform very different functions, as is explained
below, and therefore the chance of a common mode
specification, software, hardware or interference failure
should be greatly reduced. This diversity is obtained by
dedicating each channel to a different task. The main
processor is designed to carry out the control function, in
the same way as a single channel system, whilst the
second channel, or 'safety processor', is used to monitor
the system and ensure it never enters an unsafe state. The
Vol 14 No 5 June 1990
Update
I~ ControlMicro1
SafetyCritical
Inp•uts
Actuator
ControlMicro2
SafetyCritical
Figure 1. Duplex processor system
Inputs ControlMicro ts Fail-Safe
NonSafetyCritical Actuator
Interrogation ~ ~
Bus
- WatchdogMicro /
SafetyCritical ..........
POWER
Figure 2. Main and monitor system
two channels communicate to exchange data and to
check that each channel is functional.
The second channel monitors both the system inputs,
outputs and as many intermediate variables as are
considered necessary to provide acceptable failure
detection time. The safety processor does not repeat the
control calculations of the main processor, but determines
from its input data whether or not the system is in a safe
state. For example, in a closed-loop throttle control
system the main processor will determine the required
actuator drive signal, whereas the safety processor could
ensure that the direction of the drive signal is appropriate
and that the integral of the error signal is below a certain
threshold.
The task of specifying the function and the unsafe
states for the safety processor is not simple, but it is a
valuable task for checking the requirements for the
main processor. The functionality required from the safety
processor should be less than that required from the main
processor since it may not need to perform all the control
calculations. More importantly, the safety processor will
be easier to design as a deterministic synchronous system
since the precise timing constraints required for control
can be relaxed. This could allow formal methods to be
used effectively in its design and implementation. The
precise mathematical notation of formal methods appear
well suited to the task of describing states and behaviour
that a system should not exhibit.
To prove that such a system is safe, it would be
necessary to prove that the operation of the safety
processor was logically correct and that all random errors
in the safety processor could be detected by the main
processor. Logical proof of the control function is not
necessary for safety, although of course it is necessary for
319
 Update
reliability. This is an important point because the author is additional logic to prevent both channels relinquishing
unaware of any techniques for formally proving the control at the same time. Dissimilar hardware and
correctness of typical automotive control systems with software could again be used. Safety could again be
their complex realtime structures. improved by having different requirements for each
channel. The first channel would perform the full
functionality and would operate until a failure was
System architectures for systems w i t h o u t detected by its safety processor or the second channel
a safe state failed. The second channel would provide a reduced
functionality, but safe, back-up system. The second
Figure 3 shows the classic triple redundant system. This channel would therefore be designed against a different
type of system has been used for many years in aerospace specification, thus providing some diversity. It should also
applications, but it does admit the possibility of common be simpler, easier to validate and hence cheaper.
mode failures. Previous experience with these systems An example of this approach could be an electrically
was gained on systems where the control strategy and operated braking system where the first channel provides
implementation were relatively simple. As the complexity many sophisticated features, such as anti-skid, anti-spin
of the hardware, software and system requirements and hill-holding. The second channel would merely
increases so must the danger of a common error. provide a braking force proportional to the driver's pedal
Using dissimilar hardware and software for each force.
channel becomes more difficult as the number of
channels increases due to the availability of suitable
components and provides no protection against Conclusion
specification error.
An alternate implementation which should reduce the As electronic control systems increase in both complexity
chances of a common mode error, and which is also and control authority there must be a commensurate
potentially cheaper to produce, is shown in Figure 4. This increase in our ability to design and implement these
is basically a duplex version of Figure 2 with some systems safely. The use of common specifications,
hardware and software are all seen as potentially
hazardous for very high integrity systems. Diversity is
,/. . . . i Control Micro 1 [
_ regarded as the best approach for providing the safety
levels required and the preferred approach is to provide
this by utilizing checking and back-up systems which are
I
designed against a different requirement, and have less
Inputs i ,
.

v Sa|elyCritical tLs•
)u Fail-Safe
Voter ~ Actuator functionality than the main control system. In this way the
integrity of these systems can be kept high at a reasonable
cost.
L, 1

I SaletyCritical
ON THE DEVELOPMENT OF A F O R M A L
Figure 3. Triplex dependable system M E T H O D S - B A S E D SOFTWARE DESIGN
M E T H O D O L O G Y FOR A U T O M O T I V E
POWER APPLICATIONS

S Tran, J Cullyer, E Hines and K Marks

,ntetrogationBus ~'=i ~ ...... Microprocessor systems are beginning to be used in a

variety of safety-critical applications in the automotive
industry. Throttle, brake and steering systems are
Inputs SafetyCritical O ts Actuator changing from mechanically-controlled systems to
electrical systems. Thus there is a need for safe and
Failsafe reliable actuators and controllers. The issue of reliability
Voter
should be considered by the customer from a system
viewpoint, since it is affected by both hardware and
Inputs software. There already exist stringent standards for
SafetyC ~ Actuator
hardware design, such as the German TUV standard, but
there remains a need for rigorous standards to produce
more reliable software.

tw....oo, f
SafetyCdtcal ....
,
1
POWER
N Software is the key to a successful or disastrous micro-
processor-based circuit design. Poorly developed software

Department of Engineering, Warwick University,

Figure 4. Two channel dependable system Coventry CV4 7AL, UK

320 Microprocessors and Microsystems