Fault Tolerance in Automotive Systems

Adithya Hrudhayan Krishnamurthy, Ramkumar Ravikumar

Department of Electrical and Computer Engineering
University of Wisconsin, Madison
{akrishnamur3, ravikumar}@wisc.edu

infotainment, and wireless rely on automotive

communication
systems.
Fault
tolerant
communication systems are built so they are tolerant
to defective circuits, line failures etc., and
constructed using redundant hard- and software
architectures to ensure reliable communication
between different sub-systems in a vehicle. In this
paper we present exhaustive information about fault
tolerance techniques used in the automotive industry.

Abstract - Design of fault tolerant electronics has

become a standard requirement in the automotive
sector these days. These systems increases the overall
automotive and passenger safety by liberating the
driver from handling routine tasks and also assisting
the driver during critical situations. In this paper we
present exhaustive information about some of the
commonly used fault tolerant design techniques in the
automotive domain. We start off by analyzing X-bywire systems, which are fault tolerant distributed
systems that are fail-operational and can maintain a
reliable state all the time. A case study on Steer-by-wire
is included. Fault tolerance techniques used in the
design of automotive software and how they help in
improving the overall reliability and dependability of
the system is investigated. Common design techniques
used in the design of fail-safe Sensors and actuators is
presented. We conclude the paper with a section on the
design of automotive communication systems and
protocols and their ability to ensure reliable
communication between various ECU's in the vehicle.

2. X-by Wire in Automotive Systems

Following the aviation industry, the automotive
industry took to X-by-Wire systems, called DriveBy-Wire. In the automotive environment, X
denotes the commanded action such as accelerating,
braking or steering. Drive-by-Wire systems sense
driver requests and translate them into optimum steer,
brake, and acceleration manoeuvres. X-by-Wire
systems can be classified into Brake-by-Wire,
Throttle-by-Wire and Steer-by-Wire systems
depending upon the commanded action. The
following sections discuss Brake-by-Wire and
Throttle-by-Wire in a succinct manner. Later, a
section has been devoted to the detailed study of
Steer-by-Wire systems.

1. Introduction
Advancements in the field of automotive electronics
have helped in realizing the potential of sophisticated
vehicular control systems. In addition to liberating
the driver from routine tasks, such systems assist the
driver during critical situations, thereby enhancing
vehicular safety and performance. Among these
systems, X-by-Wire systems (where driving, steering
and braking are electronically controlled) have
provided feasible electronic and electromechanical
solutions resulting in enhanced fault tolerance and
reliability. Traditional mechanical and hydraulic
systems employed in automotive and aviation
systems are being replaced by electronic control
systems such as X-by-Wire systems. A current
premium car, for instance, implements about 270
functions a user interacts with, deployed over about
70 embedded platforms. Altogether, the software
amounts to about 100 MB of binary code. Ensuring
fault tolerance in automotive software is an active
area of research. Safety-critical systems such as Xby-wire systems and most ECUs typically use a lot of
sensors for performing their functions. Hence sensors
and actuators, which form the backbone of most
commonly used electronic systems, need to be fault
tolerant as well. Major automotive subsystems such
as chassis, air-bag, powertrain, body and comfort
electronics, diagnostics, x-by-wire, multimedia and

2.1. Brake-by-Wire
Brake-by-Wire (BBW) systems are realized through
electro-mechanical actuators and communication
networks, instead of conventional hydraulic devices.
It offers enhanced safety, cuts off cost associated
with manufacture and maintenance of mechanical
brakes and brake fluids. It also eliminates
environmental concerns caused by hydraulic systems.
There are two ways to realize a BBW system. On one
hand, the system is based on the traditional hydraulic
brake system. The by-wire function is realized
through hydraulic pumps and additional electric
controlled valves Electric Hydraulic Brake (EHB)
[24]. In an EHB system, a hydraulic backup can be
realized with the help of valves. Once a fault is
detected, a direct hydraulic brake circuit will be
closed. On the other hand the brake-by-wire system
based on electric mechanical actuators is called as
Electric Mechanical Brake (EMB). In an EMB
system the brake force and brake control is realized
by electric components [11]. Since a hydraulic brake
cannot be realized, the system must be extremely

reliable. BBW systems enable simple integration of

vehicle traction and stability control.

physical system, must be bounded, typically lower

than a few tens of milliseconds. An excessive end-toend response time of a control loop may not only
induce performance degradation but also cause the
instability of the vehicle.

2.2. Throttle-by-Wire
Conventional throttle systems consist of a cable
running from the gas pedal into the throttle body.
This cable slides within a housing as it winds its way
around various components. Such a system is
relatively bulky and prone to wear. Automotive
manufacturers have implemented a new means of
throttle control known as Throttle-by-Wire. Throttleby-Wire consists of a sensor providing pedal
position. The data acquired by the sensor is sent to
the Engine Control Module (ECM) that determines
the parameters to change. The ECM coordinates
components such as Anti-lock Braking System
(ABS), gear selection, fuel and air intake, and
traction control. This embedded intelligence results in
increased fuel efficiency, reduced emissions,
improved performance, and reduced frictional losses.
Throttle-By-Wire allows the engine computer to
integrate torque management with traction control
and stability control.

2.3. Dependability Constraints

For a critical X-by-Wire system, the following must
be ensured - A system failure does not lead to a state
in which human life, economics, or environment is
endangered; a single failure of one component must
not lead to the failure of the whole X-by-Wire system
[26]. Also, the system must be able to tolerate at least
one major critical fault without loss of functionality
for a long time to reach a safe parking area. The Xby-Wire system should also offer the same
availability
and
maintainability
as
their
mechanical/hydraulic counterparts.
4. Case Study: Steer-by-Wire
Traditionally, vehicle wheels have been turned by a
direct mechanical linkage between the steering
wheel, steering gears and actual wheel. In such a
system, the driver turns the steering wheels to request
the steering gears to turn the vehicle wheels. The
feedback of the torque encountered by the steering
system as the wheels are turned is provided to the
driver through mechanical linkages. This torque
feedback is critical as it provides the driver with a
sense of the road conditions, such as the traction
experienced by the wheels with the road surface.
Steer-by-Wire systems eliminate mechanical
components between the steering wheel and turning
wheels. The system aims to control the wheel
direction according to the driver's request and provide
a mechanical-like force feedback to the hand wheel.
The following sections deal with the functionality of
the architecture, the real-time constraints imposed on
the system, and the protocol used by the nodes to
communicate between each other.

3. Constraints for the Design of X-by-Wire

Systems
3.1. Power Constraint
The challenge faced during the implementation of Xby-Wire systems in vehicles has been to
accommodate such systems amidst the 14 V power
nets in automobiles. The number of electrical
components in cars has steadily increased in recent
years. To guarantee the proper functioning of all
electrical components, a stable voltage supply is
necessary. The automotive industry considered
migrating to 42 Volt systems. With 42 Volts in the
system, vehicles could use thinner-gauge wires and
smaller motors because higher voltage would mean
reduced amperage (Which dictates the size of the
wire).
3.2. Real Time Constraint
X-by-Wire systems are intrinsically real-time
distributed systems. They implement complex
multivariable control laws and deliver real-time
information to intelligent devices that are physically
distant (for example, the four wheels). They have
stringent time constraints, such as a sampling period
of only a few milliseconds [26]. Occasional absence
of samples or out-of-bound delays at the controller or
actuator level, for instance, due to frame loss, does
not necessarily lead to vehicle instability, but
degrades steering performance (or Quality of
Service). This is because most of the control laws
that are used are designed with specific delay and/or
absence of sampling data compensation mechanisms.
End-to-end response times, such as the time between
a request from the driver and the response of the

4.1. Functional Description and Operational

Architecture of Steer-by-Wire System
The two critical services provided by the Steer-byWire system involve the front axle actuation and the
hand wheel force feedback [26].
Front Axle Control - This function computes the
orders that are given to the motor of the front axle,
based on the state of this front axle and the
commands given by the driver through the hand
wheel. The driver's requests are translated depending
on the hand wheel angle, torque and speed.
Hand Wheel Force Feedback - This function
computes the orders provided to the hand wheel
motor based on the speed of the vehicle, front axle
position and the front tie rod force.
An operational architecture for the functions
mentioned above is realized - The operational

architecture includes four ECUs (micro-controllers)

named, respectively, HW ECU1 (Hand Wheel
ECU1), HW ECU2 (Hand Wheel ECU2), FAA
ECU1 (Front Axle Actuator ECU1), and FAA ECU2
(Front Axle Actuator ECU2). Each node is connected
to the two TDMA-based communication channels
(BUS1 and BUS2). Finally, three sensors, named as1,
as2 and as3, placed near the hand wheel measure the
requests of the driver in a similar way, the latter
being translated into a 3-tuple <hand wheel angle,
hand wheel torque, hand wheel speed>. Three other
sensors, named rps1, rps2 and rps3, are dedicated to
the measurement of the front axle position. Finally,
two motors (FAA Motor2 and FAA Motor2),
configured in active redundancy, act on the front axle
while two other motors (HW Motor1 and HW
Motor2) realize the force feedback control on the
hand wheel. Sensors as1, as2 and as3 (respectively,
sensors rps1, rps2 and rps3) are connected by pointto-point links, both to HW ECU1 and HW ECU2
(respectively, FAA ECU1 and FAA ECU2).

wires, ECUs have to be placed close to the sensors,

and communication between ECUs has to be
multiplexed.

Implementation of the Front axle control function The requests of the driver are measured by the three
replicated sensors as1, as2 and as3 and sent to both
HW ECU1 and HW ECU2. Each ECU performs a
majority vote on the 3 received values and transmits
the data on both communication channels BUS1 and
BUS2. The two ECUs, FAA ECU1 and FAA ECU2,
placed behind the front axle, consume this data, as
well as the last wheel position, in order to elaborate
the commands that are to be applied to FAA Motor 1
and 2.
Implementation of the Force feedback control
function - In a way similar to the previous function,
measurements taken by rps1, rps2 and rps3 are
transmitted both to FAA ECU1 and FAA ECU2.
Each of these ECUs elaborates information
transmitted on the network. The consumers of this
information are both HW ECU1 and HW ECU2
which compute the command transmitted to HW
Motor 1 and 2.

Fig 1: Steer-by-Wire operational architecture

Dependability analyses are generally based on a

strong hypothesis assuming that, in the whole system,
n simultaneous component failures can never occur
for any set of redundant components. Lamport states
that 3n+1 redundant components are necessary to
tolerate n Byzantine faults [29]. In order to tolerate
n coherent faults, it is sufficient to have 2n+1
redundant components. According to the rule given
by Lamport, the minimum number of redundant
Hand Wheel ECUs (respectively, Front Axle ECUs)
should be 4. This solution is mainly used in the
aeronautic domain. Therefore a classical solution in
cost prohibitive situations is to use Fail-Silent ECUs.
In this case, only two Hand Wheel ECUs
(respectively, Front Axle ECUs) are necessary.

4.2. Fault Classification and Redundancy

Fault Classification A Byzantine fault is a fault
whose effect can be perceived differently by different
observers. A Coherent faults effect is seen the same
by all observers. A Transient fault is a fault whose
duration is such that the system does not reach a notsafe-state. A Permanent fault is a non-transient one.
The property of fail silence, assumed for some
components, leads to another class of faults. A
component is said to be fail silent if, each time it is
not silent, we can conclude that it is functioning
properly.
ECU redundancy - Two functions need to be
implemented in ECU: Front Axle Control and Force
Feedback Control. To avoid costly and numerous

Hand Wheel Sensor and Actuator redundancy - A

Hand Wheel sensor produces information for two
Hand Wheel ECUs. Three Hand Wheel sensors are
necessary for ensuring that each Hand Wheel ECU,
assumed to provide a voting algorithm, is able to
tolerate one Byzantine fault (and subsequently one
coherent fault or one fail-silent sensor). A single
actuator can take charge of piloting the Front Axle
and it is assumed that an actuator can never wrongly
apply an order received by a Front Axle ECU.
Considering the fail silence property of a Front Axle
ECU, only 2 couples (Front Axle ECU, actuator) are
necessary for the tolerance of, at most, one fault.

If the chosen fault-tolerance strategy is failure

recovery, redundant ECUs will work only in the case
of the primary ECU failing. Failure detection must be
quick and reliable. Otherwise, if the strategy is failure
compensation, redundant ECUs will work in parallel.
Because of the stringent real-time constraint, our
architecture must provide failure compensation.
Redundancy of identical ECUs does not prevent the
architecture from common mode failures: the
hardware of redundant ECUs should be furnished by
different suppliers and their software realized by
different teams.
4.3. Communication Protocol (TTP/C)
TTP/C is a protocol based on the TTP (TimeTriggered Protocol) and implemented so that it meets
the SAE requirements for a class C automotive
protocol. Class C protocols are suitable for high
speed single failure operational safety critical
applications. A principal reason that TTP/C is the
first protocol to qualify as Class C, is that the
previous protocols are all event triggered. Eventtriggered systems are susceptible to several serious
failure modes such as the babbling idiot failure.
TTP/C is a Time Division Multiple Access (TDMA)
protocol in which periodic time slots are assigned to
individual processing nodes in a system. The braking
unit has its own TTP/C nodes, each of which is
replicated as a Fault Tolerant Unit (FTU).

Fig 2: Communication Subsystem with FTUs

Under TTP/C, nodes generate a state message in each

TDMA round, that are posted to the CNI by the
TTP/C host for transmission over the system
network. Nodes receiving messages do not respond
with a receipt acknowledgement.
Clock Synchronization: A commonly maintained
keeper of global time is thus critical to the proper
operation of the protocol. Within a cluster of TTP/C
nodes, all nodes are aware of which node has access
to the bus during a specified time slot, given the a
priori scheduling allocation. By noting the time when
messages are received from other nodes (TTP/C is a
broadcast protocol, so all nodes hear all messages)
with the known schedule, a node can calculate the
difference between the clock of the sending node and
its own clock.
Composability: TTP/C supports a robust level of
composability the capability to carry a thoroughly
tested subsystem into a larger system, and to be able
to depend on the subsystem retaining the same
characteristics that it demonstrated in isolation [32].
In the auto industry, this feature potentially allows
the rapid integration of components provided by
multiple suppliers into a larger framework, without
the need to perform extensive system integration
tuning and testing.
Reliability and Fault Tolerance: Several aspects of
the TTP/C protocol, and the way it is implemented in
real-world systems, serve to provide reliability and
fault-tolerant behavior.
a. Membership: The role of the membership service
component of a real-time protocol is to inform all
system nodes of the failure of a node with minimal
delay [32]. Under TTP/C, a node membership field,
maintained as a status register in the CNI, contains a
so-called node membership vector. This node
membership vector contains one bit for every node in
a TTP/C cluster, with the bit set to True if the node in
question is operating correctly and to False if the
node is not operating or is flawed. The node
membership vector is updated by checking that the
expected messages from other nodes in the cluster are

Node Architecture: System nodes in a TTP/C system

consist of a Host, a Controller Network Interface
(CNI), and a TTP/C communications controller. The
Host runs the application software for the relevant
system function (for instance, the control software for
the braking system in an automobile). The CNI
stands between the Host and the TTP/C controller,
effectively de-coupling the applications-level
software from the network. Within the CNI is a
Message Descriptor List, which contains information
controlling bus access, and a data sharing interface
which is typically implemented with dual port RAM
(allowing the Host and the TTP/C controller to access
the shared memory independently). The TTP/C
communications controller provides the actual
connection between the TTP/C node and the shared
network. The controller supports the protocol with
several essential services such as guaranteed
transmission times with minimal latency, jitter, faulttolerant clock synchronization, and error detection.
Scheduling and State Messages: The system
scheduling in TTP/C protocol is static. The points in
time in which the various nodes in a system are
authorized to transmit form the lattice points of a
TTP/C action lattice. The time difference between
two adjacent points in the action lattice represents the
basic cycle time of the system, and sets a lower
bound on the response time of the system.

received, and by analyzing the cyclic-redundancy

check (CRC) fields in the messages received.
b. Fail-Silence: TTP/C nodes are designed to detect
faults in their own operation. The principle of
operation is that, each and every node must deliver
results which are correct in both the value and the
time domain, or no results at all. If a node detects an
abnormality in its operation, it switches itself off. At
a software level, TTP/C supports, for example, a
variety of techniques, including double execution,
double execution with reference checks, validity
checks, assertion checking, and signature checks.
c. Bus Guardian: The Bus Guardian (BG) is a
hardware element of the TTP/C Controller which
serves as a portal to the system bus. The key role of
the Bus Guardian is to enable the bus driver only
during the transmission slot for its node, and
otherwise to guarantee that the bus driver is in a
disabled state. This serves to prevent babbling idiot
failures [32].
d. Replication of System Components: The TTP/C
protocol supports replication of the hardware
elements of a node, dual system buses and error
detection [32].

requirement of ECU software, so that fault tolerance

mechanisms can handle detected faults locally
without propagation to other SW-components [2].
5.2. Current Approaches
A fault-tolerant architecture based on computational
reflection is proposed [1]. The reflection paradigm
for fault-tolerance purpose relies on the ability of a
system to check and to correct itself in a separate
abstraction level. The software architecture is divided
into two parts (functional and defense software) that
interact together through an interface. It is assumed
that the defense software has enough knowledge of
the structure and expected behavior of functional
software, to control it. The defense software detects
errors by checking safety properties and performs
recovery using generic instrumentation and
infrastructure functionalities. As failures can impact
both data and control, the failure model is structured
into two parts: data flow and control flow. Critical
control flow failures can disrupt control events,
sequence of execution and execution time. Critical
data flow failures can affect both value and timing in
the system. The runtime behavior of a system is
described as a sequence of scheduled entities that are
triggered by events and generate triggering events.
Control flow of a scheduled entity relates to the
control events starting or stopping its execution.
These events are produced by the environment or
other entities. In parallel, data flow of a scheduled
entity corresponds to the input data it consumes and
the output data it produces during its execution.

5. Fault tolerance in Automotive Software

Improving software fault tolerance is a common
interest for aeronautics, railway and automotive
software-based systems. However, the automotive
context meets more stringent economical constraints
and resource limitations, due to higher volume of
vehicle production [1]. The amount of software has
evolved from zero to tens of millions of lines of code.
Today, more than 80% of the innovations in a car
come from computer systems; software has thus
become a major contributor to the value of
contemporary cars [4]. A study made by Mercer
Management Consulting and Hypovereinsbank in
2001 claims that the total value of software in cars
will rise from 4% to 13% by 2010 [3] and digital
hardware and software is expected to account for up
to 30% of the overall cost of a car [5].

The Defense software is organized around logging

tables and three types of services that control
information logging, error detection and error
recovery. Logging or tracing are mechanisms often
needed for debugging and diagnosis issues. The
logging strategy has to select rigorously the
necessary and sufficient critical information to get at
runtime, according to fault tolerance concerns. The
logging architecture is organized into several
bracket-tables that are updated and used at runtime.
Each table is associated with a dedicated logging
routine that uses preferably existing infrastructure
services to get information. Once application-specific
safety properties are specified, the corresponding
error detection routine is developed as an executable
assertion. An assertion is verified at runtime within a
corresponding checking routine. When an error is
detected, the checking routine triggers a recovery
routine.

5.1. Automotive Software Classification

Automotive software is very diverse, ranging from
entertainment and office-related software to safetycritical real-time control software. It can be clustered
according to application area and the associated
nonfunctional requirements. The following five
clusters are usually distinguished [4] as Multimedia,
telematics, and HMI software, body/comfort
software, software for safety electronics, power train
and chassis control software and infrastructure
software. Automotive software development poses
great challenges to automotive manufacturers since
an automobile is inherently distributed and subject to
fault-tolerance and real-time requirements. Reliability
and robustness for automotive software is a critical

At the application level, once an error is detected, the

application is turned into a safe state. Degraded data
can recover to their valid values and new
communication request may arise for missed data
acknowledgement. At the infrastructure level,

recovery actions on control flow include reset,

terminate and restart a task or a set of OS objects. In
the proposed fault-tolerant architecture, each
checking routine is associated with one or more
recovery routines that call available executive
services and update logging tables, if necessary. The
recovery action depends on the detected error. Two
types of software instrumentation considered are
hooks and basic services. Hooks are the means to tie
up defense software to functional software, and to
insert code. Basic services play the role of software
sensors and actuators. Fault injection techniques are
used to measure fault-tolerance coverage, and to
detect remaining software errors of defense software.
The paper, however, does not mention about the
amount of data that can be handled.

redundancy technique involves the use of a software

controlled watchdog timer. As the program executes,
the timer is periodically reset by writing a new value
into the timer register. In the event of a failure, the
watchdog will restart the processor from a re-entry
point in the code. This technique is particularly useful
for avoiding deadlock conditions due to
communication failures. Another simple technique
for data redundancy is complement data write. Rather
than simply duplicating data, it is complemented first.
This adds in some additional fault tolerance by
providing the means to detect stuck-at-faults. As
duplicating every piece of data might be expensive,
often only safety-critical date is duplicated [8].
Corruption of the instruction memory can be detected
and tolerated by duplicating the program in memory
and executing each copy in sequence. Redundant
Orthogonal Coding (ROC), a technique similar to nversion programming, can be used to increase
reliability [8]. The difference is that in ROC,
different algorithms are intentionally used to perform
the same calculation. This addresses the problem of
n-version programming where different people tend
to design programs for a given tasks in very similar
ways and also to make similar mistakes in the design
by explicitly ensuring dissimilarity. This technique
may also catch programming errors. Most of the error
detection techniques focus on memory integrity. A
common technique is to use checksums to verify the
contents of the memory [8]. Another technique to
determine that the system memory is still working
correctly is to test the RAM by writing various
patterns of ones and zeros into every bit in memory.
Another common error detection technique is to use
assertion tests inside a program. Using assertion
checks can catch programming errors as well as
errors arising from unusual conditions.

An alternate method for ensuring fault tolerance in

automotive software is proposed in [6]. Since it might
be difficult for application programmers to
implement fault tolerance features by themselves
while designing automotive software, it is desirable
that the fault tolerance is provided by the middleware
and hidden from application programmers.
Middleware is a software layer that connects and
manages application components running on
distributed hosts. It exists between network operating
systems and application components. Middleware
hides and abstracts many of the complex details of
distributed
programming
from
application
developers. Figure 3 shows the structure of the
proposed middleware for automotive systems. At the
top level, there exists the publish/subscribe interface
that is used by application components. Beneath the
interface, there are QoS Configuration module for
specifying
real-time requirements,
Resource
Allocation module for guaranteeing timeliness
operations, and Clock Synchronization module for
providing a global time base. All incoming and
outgoing messages pass through Fault-Tolerance
Layer in order to guarantee reliability. Finally,
messages are transmitted and received by Transport
Layer.

Currently, the amount of error diagnosis and error

recovery in cars is rather lightweight [9]. In the CPUs
some error logging takes place, but there is neither
consideration nor logging of errors at the level of the
network and the functional distribution. There is no
comprehensive error diagnosis and no systematic
error recovery beyond individual CPUs. Failure
logging to the end of better diagnosis for
maintenance has emerged as a relevant research
problem. There are some fail-safe and graceful
degradation techniques found in cars today, but a
systematic and comprehensive error treatment is
missing. With the upcoming multi-core controllers
for embedded applications, an interesting area for
research is how this can be exploited also for
redundancy/recovery strategies. Several keys areas of
research have been identified in [4]. Reliability and
safety concerns are important for all functions
relevant to driving, from engine control and
passenger safety functions to X-by-wire functions

Fig. 3: Structure of proposed middleware

Because software is very flexible and relatively

cheap, it is a very desirable medium for
implementing fault tolerance mechanisms [7].
Redundancy in software can be accomplished
through redundant computation and redundant
storage. The most common computational

where mechanical transmission is replaced by

electrical signals.

able to tolerate the loss of one or two sensor elements

and to diagnose the failed sensor elements. Hardware
and/or Software Instrument Fault Detection, Isolation
and Accommodation (IFDIA) schemes are finding
more and more applications in automotive
measurement and control systems. A scheme for
detection, location and accommodation of faults is
presented in [13]. This scheme was designed to
identify and accommodate some kinds of faults that
may affect manifold pressure, crankshaft speed and
throttle valve angle position sensors. It is reported
that the realized scheme is able to identify and
accommodate also small faults in all considered
sensors.

6. Fault tolerant actuators and sensors

Safety-critical automotive applications, such as steerby-wire systems, are in most cases control systems
with hard real time requirements. Such systems
typically have a number of sensors (inputs) [12]
connected to them, whose values are processed in
order to produce the control actions. Consequently
the sensors are the first in the flow of information and
control computations rely of these values. Therefore
it is important that the sensors can be trusted.
Actuators are essential for the reliable operation of
various components in the automobile including
brakes, valves and cylinders.

6.2. Fault tolerant actuators

Actuators generally consist of different parts: input
transformer,
actuation
converter,
actuation
transformer, and actuation element. The actuation
converter converts one type of energy (e.g., electrical
or pneumatic) into another (e.g., mechanical or
hydraulic). Fault-tolerant actuators can be designed
by using multiple complete actuators in parallel, with
either static redundancy or dynamic redundancy with
cold or hot standby [11]. Another possibility is to
limit the redundancy to parts of the actuator that have
the lowest reliability. To achieve fault tolerant
control either the actuator must not be a single point
of failure or it has to be fault tolerant. For functions
without inherent redundancy, actuators must be
replicated [12]. When only two actuators are used,
the failure of one actuator must not affect operation
of the remaining unit. Sensors to continuously
monitor the actuator behavior (e.g. injector current,
motor current, motion, force, torque, etc) are
typically used. When these sensors indicate a serious
actuator failure, the power to the actuator should be
switched off. As cost and weight generally are higher
for them than for sensors, actuators with failoperational duplex configuration are preferred [11].
Static redundant structures, where both parts operate
continuously or dynamic redundant structures with
hot or cold standby can be chosen. For dynamic
redundancy, fault-detection methods for the actuator
parts are required.

6.1. Fault tolerant sensors

A fault-tolerant sensor configuration should be at
least fail-operational for one sensor fault [11]. This
can be obtained by hardware redundancy with the
same type of sensors or by analytical redundancy
with different sensors and process models. Sensor
systems with static redundancy are realized with a
triplex system and a voter. A configuration with
dynamic redundancy needs at least two sensors and
fault detection for each sensor. The fault detection
can be performed by self-tests.

Fig. 4: Triplex system with static redundancy and duplex system

with dynamic redundancy

Depending on the importance of the sensed quantity,

additional sensors may or may not be needed to
obtain the required dependability at the system-level.
This type of sensors requires some form of sensorinternal redundancy in the form of a built-in self-test
(BIST) and/or internal replication. If a particular
sensor is not fail-silent, it can be replicated in order to
obtain the fail-silent property at the system level. In
this case, the values of the sensors are collected and
analyzed by an intelligent unit that makes a decision
of which value to use in further calculations. The
required degree of replication is dependent on the
criticality of the sensor. If knowledge of the sensed
quantity is critical, sensor triplication is necessary.
However, if a lack of knowledge about the sensed
quantity is acceptable, dual redundancy is sufficient.

A prototype of an actuator is demonstrated in [10].

Typical electromagnetic faults such as Winding open
circuit, winding short circuit may occur within an
actuator. To develop one single drive that can
continue to operate with any one of these faults, it
became clear that the most successful design
approach was to use a multiple phase drive in which
each phase may be regarded as a single module. The
operation of any one module must have minimal
impact upon the others, so that in the event of that
module failing the others can continue to operate
unaffected. When both sensor and actuator failures

A prototype of a steering angle sensor is

demonstrated in [10]. By extension to a diverse foursensor system (there are six pairs of sensor elements),
the steering angle sensor is fault tolerant since it is

occur at the same time, their mutual effects on

residuals make fault isolation difficult [14]. A
hexadecimal decision table to relate all possible
failure patterns to the residual code has been
proposed in [14]. Detection and isolation of multiple
sensor and actuator failures in automotive engines is
achieved. Simulation and experimental results
indicate that the proposed diagnostic system not only
can be applied to cases where all failures occur in the
same sector, but is also appropriate for isolating
multiple failures occurring simultaneously in sensors
and actuators.

automotive applications, due to its low cost, its

robustness and the bounded communication delays.
CAN has several mechanisms for error detection
[17]. For instance, it is checked that the CRC
transmitted in the frame is identical to the CRC
computed at the receiver end, that the structure of the
frame is valid and that no bit-stuffing error occurred.
Each station which detects an error sends an "error
tag" which is a particular type of frame composed of
6 consecutive dominant bits that allows all the
stations on the bus to be aware of the transmission
error. CAN possesses some fault-confinement
mechanisms aimed at identifying permanent failures
due to hardware dysfunctioning at the level of the
micro-controller, communication controller or
physical layer. The scheme is based on error counters
that are increased and decreased according to
particular events. The main drawback is that a node
has to diagnose itself, which can lead to the nondetection of some critical errors. Without additional
fault-tolerance facilities, CAN is not suited for
safety-critical applications such as future X-by-Wire
systems [17]. For instance, a single node can perturb
the functioning of the whole network by sending
messages outside their specification (i.e. length and
period of the frames). A framework to provide
selective fault-tolerance for messages with various
fault-tolerance requirements scheduled on CAN is
proposed in [19]. The set of messages are analyzed
off-line and scheduling attributes are provided that
ensures feasible transmission of messages as well as
retransmissions upon error occurrences that satisfy
the fault-tolerance requirements.

7. Fault tolerant Automotive Communication

Systems
The specific requirements of the different car
domains have led to the development of a large
number of automotive networks such as LIN, J1850,
CAN, TTP/C, FlexRay, media-oriented system
transport, IDB1394, etc. One of the important
requirements of an automotive communication
system is fault-tolerance [16]. Fault tolerant
(typically safety-critical) communication systems are
built so they are tolerant to defective circuits, line
failures etc., and constructed using redundant hardand software architectures.
7.1. Event triggered vs. Time triggered Systems
There are two main paradigms for communications in
automotive systems [15]: time triggered and event
triggered. Event triggered means that messages are
transmitted to signal the occurrence of significant
events (e.g., a door has been closed). In this case, the
system possesses the ability to take into account, as
quickly as possible, any asynchronous events such as
an alarm. Event-triggered communication is very
efficient in terms of bandwidth usage since only
necessary messages are transmitted. In time triggered
systems, frames are transmitted at predetermined
points in time, which is well suited for the periodic
transmission of messages as required in distributed
control loops. Each frame is scheduled for
transmission at one predefined interval of time,
usually termed a slot, and the schedule repeats itself
indefinitely. As the frame scheduling is statically
defined, the temporal behavior is fully predictable;
thus, it is easy to check whether the timing
constraints expressed on data exchanges are met.

7.3. Time-Triggered CAN (TTCAN)

TTCAN uses the CAN standard but, in addition,
requires that the controllers have the possibility to
disable automatic retransmission of frames upon
transmission errors and to provide the upper layers
with the point in time at which the first bit of a frame
was sent or received. The key idea is to propose a
flexible time-triggered/event-triggered protocol.
TTCAN defines a basic cycle as the concatenation of
one or several time-triggered (exclusive) windows
and one event-triggered (arbitrary) window. Though
TTCAN is built on a well-mastered and low-cost
technology, CAN, does not provide important
dependability services such as the bus guardian,
membership service and reliable acknowledgment
[17]. It does not provide the same level of fault
tolerance as TTP and FlexRay, which are the other
two candidates for x-by-wire [16]. Strong points of
TT-CAN are the support of coexisting event- and
time-triggered traffic together with the fact that it is
standardized by ISO. It is also on top of standard
CAN which allows for an easy transition from CAN
to TT-CAN.

7.2. Controller Area Network (CAN)

CAN (Controller Area Network) is the most widely
used in-vehicle network. It was designed by Bosch in
the mid 80's for multiplexing communication
between ECUs in vehicles and thus for decreasing the
overall wire harness: length of wires and number of
dedicated wires. CAN on a twisted pair of copper
wires became an ISO standard in 1994 and is now a
de-facto standard in Europe for data transmission in

board communication and control networks are built

using Gigabit Ethernet. Sensors are smart and they
are the sources of traffic. Actuators are smart and
they are the sinks of traffic.

7.4. FlexRay
The FlexRay network is very flexible with regard to
topology and transmission support redundancy. It can
be configured as a bus, a star or multistar. It is not
mandatory for each station to possess replicated
channels or a bus guardian, even though this should
be the case for critical functions such as the Steer-byWire [15]. FlexRay also provides fault tolerance by
distributed time-triggered synchronization (clock
synchronization) and error containment on the
physical layer through an independent bus guardian.
FlexRay allows both time-triggered and eventtriggered communication by means of a
communication cycle, where a time-triggered (static)
window and event triggered (dynamic) window are
concatenated. The time triggered window uses
TDMA like TTP, but unlike TTP, a given node may
be able to access the bus multiple times before all
remaining nodes access it. The event-triggered
window uses a technique called Flexible TDMA
(FTDMA) to provide event triggered behavior
without collisions. According to the FlexRay
specification [21] a frame contains a 24 bit CRC
checksum to ensure the integrity of the frame
transmission. The probability of undetected network
errors is less than (6*10^-8). Adequately addressing
fault-tolerance is one of the key aspects that needed
to be considered during the design of FlexRay. To
allow a single communications system to support the
diverse needs of automotive applications across
different application domains the consortium decided
to introduce a concept of scalable fault-tolerance.
Scalable fault-tolerance aims at allowing FlexRay to
be used economically in distributed non fault-tolerant
systems as well as in distributed fault-tolerant
systems.
In addition FlexRay can be deployed using optional
local or remote channel guardians that protect the
communications channels from transmission faults
that violate the TDMA scheme. The clock
synchronization algorithm supports fault-tolerant as
well as non fault-tolerant synchronization. For faulttolerant
synchronization the synchronization
algorithm considers the transient / permanent fault
class as well as the symmetric / asymmetric fault
class [22]. In this protocol, the synchronization of the
global time happens at the macrotick level, with the
use of a cluster-wide clock synchronization
algorithm. This clock synchronization algorithm
continues to operate even in the event of an ECU
failure in the system, unlike a master-slave
synchronization algorithm. Table 1 summarizes the
key differences between the automotive protocols
discussed so far.

USAGE
Chassis
Airbags
Powertrain
X-by-wire
Multimedia
Telematics
Diagnostics
REQUIREMENTS
Fault tolerance
Determinism
Bandwidth
Flexibility
Security

CAN
YES
YES
YES
SOME
NO
NO
YES
CAN

TTCAN
YES
NO
YES
YES
NO
NO
SOME
TTCAN

FlexRay
NO
NO
SOME
YES
NO
NO
SOME
FlexRay

SOME
YES
SOME
YES
NO

SOME
YES
SOME
YES
NO

YES
YES
YES
YES
NO

Table 1: Summary of Automotive Protocols

The controller is a personal computer. The sources of

real time traffic (sensors) are tripled while the
number of sink nodes (actuators) is not increased.
This increase in the number of sensors is made to test
the possibility to build triple-modular redundancy
(TMR) on the sensors level for fault-tolerance. The
disadvantage of TMR is obviously cost since three
sensors are required to produce an output that could
be generated by just one sensor. On the other hand,
the advantage of TMR is an increase in reliability.
The outputs have to go through a voter. Voting can
also be done in software which has been used in this
study. The controller, after reading the outputs of the
three sensors, executes a routine that compares these
three outputs. A major problem here is that the three
outputs may not completely agree because the
sensors, while identical, may not produce the same
exact output. The first solution to this problem is the
mid-value select technique. The second technique
is to ignore the least significant bits of the data. The
number of significant bits that have to agree depends
on the application. With TMR, the data from the
three copies of the sensor is compared and voted
upon. As long as there is only one failed sensor, the
controller will know which of the three packets to
discard and the system will remain operational. When
the second sensor fails, the entire system will fail. A
methodology of interconnecting the automotive bus
networks in a fault tolerant way is proposed in [20].
8. Conclusion
In this paper, we have provided a survey of fault
tolerant design techniques and methodologies used in
the automotive industry. X-by-wire systems that are
discussed in length are expected to be integrated into
most automobiles in the future. Automobile
manufacturers such as Toyota, Nissan and BMW

7.5 Recent Work

A simulation study for fault-tolerant sensor networks
for cars on-board control is presented in [18]. On-

have already introduced Brake-by-wire technology in

some of their recent models. As the amount of
software that goes into a modern car increases
steadily with the introduction of navigation systems,
instrument clusters, software fault tolerant techniques
will become a mandatory requirement in the
automotive industry. FlexRay is expected to be the
network of choice in future X-by-wire designs due to
its high bandwidth. We feel a key challenge in the
area of automotive software will be handling the
huge amount of data that is to be processed (such as
map data in a navigation system), and yet provide
fault tolerance without causing any hindrance to user
experience. As modern cars slowly transition to
functioning as an information hub by providing
connectivity to Laptops, PDAs and cell phones,
another challenge would be to introduce some fault
tolerant services in protocols such as Bluetooth,
ZigBee and MOST. This represents an opportunity
for research for engineers from all backgrounds.

[13]

[14]

[15]

[16]

[17]

[18]

[19]

References
[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

C. Lu, Jean-Charles Fabre, Marc-Olivier Killijian, An

approach for improving Fault-Tolerance in Automotive
Modular Embedded Software, Proc. of the 17th
International Conference on Real-Time and Network
Systems, 2009.
Xi Chen, Requirements and concepts for future
automotive electronic architectures from the view of
integrated safety, PhD Thesis, Universittsverlag
Karlsruhe, 2008.
H. Gustavsson, J. Sterner, An industrial case study of
Design Methodology and Decision Making for
Automotive Electronics, Proc. of the ASME
International
Design
Engineering
Technical
Conferences & Computers and Information in
Engineering Conference, 2008.
M. Broy, I.H. Kruger, A. Pretschner, C. Salzmann,
Engineering Automotive Software, Proc. of IEEE,
Vol. 95, Issue 2, pp. 356-373, 2007.
M. Broy, Automotive Software and Systems
Engineering, Proc. of the 2nd ACM/IEEE Conference
on formal Methods and Models for Co-Design, 2005.
J. Park, S. Kim, W. Yoo, S. Hong, Designing RealTime and Fault-Tolerant Middleware for Automotive
Software, Proc. of International Joint Conference
SICE-ICASE, pp. 4409-4413, 2006.
D. Palsetia, S. Pieper, Fault Tolerance in Automotive
X-by-Wire, Project Report, Department of Electrical
and Computer Engineering, UW-Madison, 2005.
E.G. Leaphart, B.J. Czerny, J.G. DAmbrosio, B.T.
Murray, C.L. Denlinger, D. Littlejohn, Survey of
Software Failsafe Techniques for Safety-Critical
Automotive Applications, SAE 2005-01-0779, SAE
World Congress, 2005.
A. Pretschner, M. Broy, I.H. Kruger, T. Stauner,
Software Engineering for Automotive Systems: A
Roadmap, Proc. of Future of Software Engineering,
pp. 55-71, 2007.
E. Digler, R. Karrelmeyer, B. Straube, Fault Tolerant
Mechatronics, Proc. of 10th International On-Line
Testing Symposium, 2004.
R. Isermann, R. Schwarz, S. Stolzl, Fault-Tolerant
Drive-by-wire Systems, IEEE Control Systems
Magazine, Vol. 22, Issue 5, pp. 64-81, 2002.
A. Manzone, A. Pincetti, and D. De Costantini, Fault
Tolerant Automotive Systems: An Overview, Proc. of

[20]

[21]

[22]

[23]
[24]
[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

10

the 7th International On-Line Testing Workshop, pp.

117-121, 2001.
D. Capriglione, C. Liguori, C. Pianese, A. Pietrosanto,
On-Line Sensor Fault Detection, Isolation, and
Accommodation in Automotive Engines, IEEE
Transactions on Instrumentation and Measurement,
Vol. 52, Issue 4, pp. 182-189, 2003.
P. Hsu, K. Lin, L. Shen, Diagnosis of Multiple Sensor
and Actuator Failures in Automotive Engines, IEEE
Transactions on Vehicular Technology, Vol. 44, Issue
4, pp. 779-789, 1995.
N. Navet, Y. Song, F. Simonot-Lion, C. Wilwert,
Trends in automotive communication systems, Proc.
of IEEE, Vol. 93, Issue 6, pp. 1204-1223, 2005.
T. Nolte, H. Hansson, L.L. Bello, Automotive
Communications - Past, Current and Future, Proc. of
10th IEEE Conference on Emerging Technologies and
Factory Automation, Vol. 1, pp. 985-992, 2005.
N. Navet, F. Simonot-Lion, A Review of Embedded
Automotive Protocols, Technical Report, Nancy
Universit, 2008.
R.M. Daoud, H.H. Amer, H.M. Elsayed, Y. Sallez,
Fault-Tolerant Ethernet-Based Vehicle On-Board
Networks, Proc. of 32nd Annual Conference on
Industrial Electronics, pp. 4662-4665, 2006.
H. Aysan, A. Thekkilakattil, R. Dobrin, S. Punnekkat,
Fault Tolerant Scheduling on Controller Area Network
(CAN), Proc. of Emerging Technologies and Factory
Automation Conference, pp. 1-8, 2010.
H. Kimm, Ho-Sang Ham, Integrated Fault Tolerant
System for Automotive Bus Networks, Proc. of 2nd
International Conference on Computer Engineering
and Applications, pp. 486-490, 2010.
FlexRay
Consortium.
(2004,
June)
FlexRay
Communication System, Protocol Specification,
Version
2.0.
[Online].
Available:
http://www.flexray.com
C. Temple, Networking the FlexRay Way - An
overview of the FlexRay Communications System,
Technical Report, Freescale Semiconductor.
R. Garbenfeldt, X-by-wire: Driving Your Car and the
Semiconductor Industry, Technical Report, 2005.
F. Seidel, X-by-wire, Technical Report, Chemnitz
University of Technology, 2009.
B. Selic, Fault tolerance techniques for Distributed
Systems,
[Online],
Available:
http://www.ibm.com/developerworks/rational/library/1
14.html#N101B5
C. Wilwert, N. Navet, Y. Song, F. Simonot-Lion,
Design of automotive X-by-wire systems, Technical
Report.
L. He, Z. Yu, C. Zong, H. Zhao, The Dual-core Faulttolerant control for Electronic Control Unit of Steer-Bywire System, Proc. of International Conference on
Computer, Mechatronics, Control and Electronic
Engineering, pp. 436-439, 2010.
E. Touloupis, J.A. Flint, V.A. Chouliaras, A FaultTolerant Architecture For Automotive Applications.
Technical Report, Loughborough University.
L. Lamport, R. Shostak, M. Pease, The Byzantine
Generals Problem , ACM Transactions on
Programming Language and Systems, vol. 4, no. 3,
pp382-401, 1982.
IEC61508-1, Functional Safety of Electrical Electronic
Programmable Electronic Safety-related Systems - Part
1 : General requirements, IEC/SC65A, 1998.
D. Jhalani, S. Dhir, Survey of Fault Tolerant
Techniques in Automotives, University of Wisconsin
Madison.
H. Curtis, R. France, Time Triggered Protocol
(TTP/C): A Safety-Critical System Protocol, literature
Survey, University of Texas-Austin, 1999.