Safety Related Fault Tolerant Systems In Vehicles
X-By-Wire
Safety Related Fault Tolerant Systems in Vehicles
Project No. BE 95/1329
Contract No: BRPR-CT95-0032
Final Report
Document Number: XByWire-DB-6/6-24
Authors: X-By-Wire Team
Version: 2.0.0
Date: November 26, 1998
Availability: Non restricted
Status: Ready
File: 0505ee16-5bd7-4def-8ef1-e8d32f954956.doc X-By-Wire ConsortiumV 20.0 Page 1 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
Table of Contents
1 EXECUTIVE SUMMARY 5
2 OBJECTIVES OF THE PROJECT 6
2.1 Introduction 6
2.2 Objectives 7
2.3 Approach 8
3 AUTOMOTIVE REQUIREMENTS 10
3.1 General 10
3.2 Conventional Systems 10
3.3 Technical Requirements 11
3.4 Legal Requirements 11
3.5 User Requirements 12
3.6 Safety Requirements 12
3.7 Subsystems 13
3.8 Communication System 14
3.9 System Architecture 15
3.10 Testing and Verification 16
3.11 Maintainability 16
3.12 Manufacturability 17
3.13 Security 17
3.14 Environment 18
3.15 Benefits 18
4 USABILITY OF EXISTING APPROACHES 20
4.1 Objectives 20
4.2 Collection of Existing Approaches 20
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 2 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
4.3 Evaluation of Existing Approaches 21
4.3.1 Methodology 21
4.3.2 Event-Triggered versus Time-Triggered Operation 21
4.3.3 Systematic versus Application-Specific Fault Tolerance 22
4.3.4 Bus Access Principles 22
4.3.5 Centralised Control with I/O Bus versus Distributed Control 23
4.3.6 Design Alternatives for Fault-Tolerant Nodes 23
4.3.7 Exact or Approximate Consensus 24
4.3.8 Application Programming Languages 25
4.3.9 System Software 25
4.3.10 Development Process – Verification and Validation 25
4.3.11 Conclusions 26
5 ARCHITECTURE DEFINITION 28
5.1 Conceptual Architecture 28
5.1.1 Communication System 30
5.1.2 Hardware 35
5.1.3 Software 37
5.1.4 Development Process 41
6 PROTOTYPE 43
6.1 Introduction 43
6.2 Prototype in General 43
6.3 The Time-Triggered Protocol for Class C applications (TTP/C) 45
6.3.1 Hardware Setup 45
6.3.2 MEDL 48
6.4 Node Architecture 49
6.5 The Steering Wheel Unit 49
6.5.1 Fault-Tolerant Feedback Actuator 49
6.5.2 Fail-Silent Sensors 50
6.6 The Steer-By-Wire Control Unit 50
6.6.1 Technical Data - FSU 50
6.7 The Steering Actuator Unit 51
6.7.1 The Motors 51
6.7.2 The Torque Measurement 52
6.7.3 The Angle Measurement 53
6.7.4 The FSU 53
6.8 Power Supply 54
6.9 Monitoring and Fault Injection 55
6.10 Conclusions 57
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 3 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
7 PRECONDITIONS FOR MASS PRODUCTION 59
7.1 Open Issues 59
7.1.1 Availability of Components 59
7.1.2 Development Process 60
7.2 Standardisation Planning Activities 60
8 PROJECT MANAGEMENT 63
9 CONCLUSIONS 67
10 HISTORY 69
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 4 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
1 Executive Summary
During the last three years the X-By-Wire project has reached a large and wide degree of
fame. The objectives are well known in the automotive and semiconductor industry. A lot of
companies are very interested in the results because of their big potential for future trends in
automotive systems.
The objective of this project was to achieve a framework for the introduction of safety related
fault tolerant electronic systems without mechanical or hydraulic backup in vehicles. These
systems are called x-by-wire systems, while the ―x‖ in ―x-by-wire‖ represents the basis of any
safety related application, e.g., steering, braking, powertrain or suspension control. These
systems will increase overall active and passive safety by liberating the driver from routine
tasks and assisting the driver to find solutions in critical situations.
The severe constraints of mass production and easy maintenance require manufacturable cost
effective solutions for safety increasing driver assistance applications. Solutions which rely on
complex mechanical backup will not meet the cost requirements. With no mechanical backup
available, x-by-wire systems have to be used.
Within this project an architecture for fault tolerant electronic systems in vehicles, capable of
steer-by-wire, has been worked out and implemented in a prototype. The resulting architecture
meets the automotive requirements from dependability to the constraints of mass production.
This common European x-by-wire development, which has the potential to become a
European or even world-wide standard, accompanied by broad and fast dissemination of the
results, translates into a significant strategic advantage for the European automotive, supplier,
and semiconductor industry. The success of the project put the European industry in a pole
position in an important emerging high technology market. Direct benefit to the vehicle
customer is visible by introducing intelligent driver assistance systems based on x-by-wire
solutions. Gaining the techonlogical leadership will also bring a number of benefits to other
industry sectors like aeronautic, railway, or nuclear industry.
This project addresses Brite-EuRam III, technical areas 3B.5 and 3B.6. The consortium came
together as the result of the EUCAR masterplan. Driven by EUCAR, all the interests in the
field of x-by-wire of the European automotive industry were focused and harmonised. The
consortium turned out to be well suited for the work and very powerful for exploitation and
enforcement of standardisation. The consortium consists of the following companies and
institutions: the car manufacturers DaimlerChrysler, Fiat, Ford Visteon, and Volvo, the
suppliers Bosch, Magneti-Marelli, and Mecel, as well as the Chalmers University of
Gothenburg and the Vienna University of Technology.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 5 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
2 Objectives of the Project
2.1 Introduction
There is a trend in the automobile industry for an increasing number of safety-related
electronic systems in vehicles that are directly responsible for active and passive vehicle
safety. These applications will increase overall vehicle safety by liberating the driver from
routine tasks and assisting the driver to find solutions in critical situations.
The realisation of such intelligent driver assistance systems requires direct electronic control
of the steering, braking, suspension and powertrain actuators, dependent on the current driving
conditions and environmental influences. It is expected that the biggest potential lies in the
replacement of (hydro-) mechanical backup systems by distributed fault-tolerant mechatronic
systems. As a consequence there is a need for a standardised dependable, and cost-effective
electronic realisation for mass production.
The general objective of the X-By-Wire project was to achieve a framework for the
introduction of such safety related fault tolerant electronic systems in vehicles, so-called "x-
by-wire systems". The "x" represents the basis of any safety-related application such as
steering, braking, powertrain or suspension control, etc.
More specifically, x-by-wire systems require driver requests to be sensed and interpreted
appropriately so as to take proper account of the current driving conditions and environmental
influences. These requests have to be translated into optimum steer, brake, and acceleration
manoeuvres. The advantages of such safety and comfort increasing applications are well
known (see Figure1 below)
Max Underfloor Passive Safety
Concept (reducing personal injury
Side Airbag Autonomous in case of an accident)
Side Impact Protection Driving
Safety Potential
Airbag Highway Copilot
Deformation Platooning Active Safety
Elements Emergency Brake (avoiding an accident)
Compound Environment recognition
Glass Road recognition (LDW)
Seat
Safety Belt Autonomous Cruise Control
Cell
ASRESP
ETC
ABS
Low Modified Source : Auto-Zeitung Nr. 4 Jan.97
1960 1970 1980 1990 2000 .....
Figure 1: Potential of Active Safety Systems in Vehicles
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 6 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
However, with present implementation strategies active safety systems, or even just a subset
thereof, cannot be realised within the typical constraints of mass production: low costs,
reliability, system modularity, maintainability in the field, whilst meeting the requirements for
safety certification. It can’t be expected that cost-effective manufacturable x-by-wire solutions
will rely on expensive mechanical backup. Today’s fail-safe systems have in general a
reduced limp-home and a driver dependent functionality in case of one significant failure. A
fault-tolerant system, on the other hand, guarantees the whole functionality even after a major
failure has occurred.
Because of big expenditure and outlay in advance, no single vehicle manufacturer has up to
now introduced really fault tolerant safety related x-by-wire systems without mechanical
backup. The X-By-Wire project was set up to share research effort and to offer European wide
accepted solutions, and to prepare the introduction of standards for x-by-wire systems.
Additionally, a common approach towards safety certification and clear legal requirements is
necessary to avoid European fragmentation and uncoordinated and parallel research.
A common European x-by-wire development, which has the potential to become a European
or even a world-wide standard, accompanied by broad and fast dissemination of the results,
translates into a significant strategic advantage for the European automotive, supplier and
semiconductor industry.
2.2 Objectives
Within the X-By-Wire project an architecture for fault tolerant electronic systems in vehicles,
has to be worked out. The resulting architecture has to meet automotive requirements e.g.
mass production constraints. Additionally it has to be implemented in a steer-by-wire
prototype without conventional backup which is regarded as the most demanding challenge. It
is obvious, that an architecture which fulfils those requirements is able to meet most of the
requirements for other by-wire applications.
Main project results have to be disseminated and discussed in order to get the necessary input
if the recommended architectural solutions are widely accepted and suitable to become a de-
facto standard or even an official standard. If necessary appropriate actions concerning
standardisation have to be taken.
To summarise, the detailed objectives are:
Specification and design of a fault tolerant electronic architecture which will cover x-by-
wire applications which do not rely on mechanical backup. It has to meet all vehicle
requirements such as costs, manufacturability, and easy maintenance.
A prototype implementation of this fault tolerant architecture covering a steer-by-wire
application without mechanical backup. Because of cost and time constraints, the
prototype has to be a laboratory demonstrator.
Analysis of dependability and safety of the architecture.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 7 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
Recommendations for the design process and rules for certification and maintenance of x-
by-wire systems.
The development of special driver assistance applications which base on this architecture,
such as autonomous driving, was not part of this project.
2.3 Approach
Firstly, the project had to establish a common set of automotive industry requirements for
safety critical electronic onboard systems (x-by-wire systems) under the constraints of mass
production.
Secondly, the general architecture for a scaleable fault tolerant electronic system for vehicles
had to be defined. This architecture was intended to be the framework for highly reliable and
manufacturable cost effective systems and components linked by a network, and for adequate
development and maintenance processes.
For this purpose a general conceptual architecture was defined and agreed upon. After that, a
more detailed definition of the different architectural aspects of a fault tolerant system such as
dependability, development process, communication system, hardware, software and
certification was performed.
For all aspects of the architecture, existing approaches (aeronautic, railway, nuclear, ships)
were investigated concerning their suitability for vehicle requirements and manufacturability.
Especially, work which had already been done in other EC-Projects was taken into account in
order to realise a technology transfer from research status into production, especially:
the work done on the MARS architecture refined in PDCS and all the additional work
already done or planned contributing to this architecture including the time-triggered
communication protocol TTP that has been developed in the context of the MARS project
(for which a number of international patents have been granted).
the BASEMENT concept, which is an architecture for in-vehicle distributed real-time
systems. It covers application development, as well as hardware and software which
provides execution and communication support.
the work done at Chalmers concerning distributed control systems for safety critical
applications in cars, covering the DACAPO concept regarding the development process,
system architecture, OS, communication, ...
Thirdly, in order to verify the main parts of the architecture specification, a steer-by-wire
prototype had to be built.
The prototype had to be a laboratory demonstrator, for evaluation purposes only, based as far
as possible on components available today. It could not be installed in a vehicle because of
cost and time constraints. Components were automotive mechanical parts (e.g. steering wheel,
mechanical front axle) several redundant electronic control units, sensors and actuators, a fault
tolerant communication system and the appropriate software modules with basic steering
features implemented.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 8 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
As accompanying measures, work had to be done concerning
the collection of unresolved issues, e.g. issues were solutions are not yet available on the
market or existing solutions are not satisfactory.
early dissemination to get the necessary input to decide how to proceed with
standardisation activities.
The described technical approach was mapped to the following project structure:
afe
S ty re latedfault tolerant
s
system in vehicles
(x-by-wire)
0 aim
D ler-Benz
A otiv
utom e Usability of Preconditions for
rch
A itecture definition Prototype mass production Project m agem
an ent
requirem ents g
existin approaches
1 osc
B h 2 Chalmers 3 olv
V o 4 CRF 5 Ford 6 aim
D ler
un
F ctional R esolutionof open
Collec tion of C eptual
onc Selec tion and
Perfo anc
rm e issues and collation O an
verall m agement
g
existin approaches Architecture Spe cification
Dependability of open results
1.1 osc
B h 2.1 Chalmers 3.1 D ler
aim 4.1 V o
olv 5.1 D ler
aim 6.1 D ler
aim
Maintenance Evaluation of tan
S dard planning
a
M nufacturability Dependability Implementation activity Loca m agem
l an ent
g
existin approaches
1.2 aim
D ler 2.2 V o
olv 3.2 osc
B h 4.2 M l
ece 5.2 Ford 6.2 All
Prototype D m
evelop ent Integration Quality assurance
proce ss
1.3 CRF 3.3 Chalmers 4.3 ece
M l 6.3 All
W om
H C ponents Evaluation Exploitation
3.4 CRF 4.4 CRF 6.4 All
ac
P kaging
Dissemination
ow u ly
P er S pp
Sensor/act. coupling
3.5 CRF 6.5 All
om u
C m nication Legend:
Final report
System
3.6 Vienna Title of workpackage 6.6 D ler
aim
r orktask
o w
x.y Coordinator
Software
Worktask
Workpackage
3.7 a
M relli
Figure 2: Project Structure
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 9 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
3 Automotive Requirements
3.1 General
Highly sophisticated future vehicle applications such as driver assistance or autonomous
driving need computerised control of the driving dynamics. This requires that driver requests
are sensed and interpreted appropriately taking into account the current driving conditions and
environmental influences. These requests have to be translated into optimum steer, brake and
acceleration manoeuvres. The typical constraints of (future) mass production must be
considered: low costs, reliability, system modularity and maintainability in the field. The
system requirement specification (SRS) sums up the requirements that hold for an x-by-wire
or more specifically for a steer-by-wire system.
A very basic requirement for a steer-by-wire system is that it must be as good as its existing
counterparts. Thus, starting from a detailed description of conventional steering systems
implications of this requirement on steer-by-wire systems are analysed.
Generally speaking a steering must be possible as long as the vehicle keeps moving whether
or not the engine is running. Technical and legal definitions of what a ―steering function‖
must be able to do can easily be applied to the steering-by-wire. However, safety and
dependability considerations and most of all the public’s general attitude towards new
technologies make it necessary to introduce a very strict global fault tolerance concept. The
ability to tolerate at least one major critical fault is therefore required.
The different requirements are analysed in more detail below.
3.2 Conventional Systems
Starting from conventional systems, there are some basic requirements concerning the
function of a steering system. Steering at standstill must be possible as well as pushing off the
kerbstone in order to guarantee that a vehicle is able to leave the parking lot even if the wheel
touches the kerbstone. It must be possible to provide tactile feedback to the driver to give him
information on the road surface conditions. Note that there might be differences in the
feedback between the European and the American market. The steering geometry must be self
centring, self stabilising and not exhibit over sensitive or under sensitive steering at both low
and high speeds. If the engine is not running the steering function must be available at least
for an appropriate time interval. The driver has to be informed in time about the loss of the
steering function before expiration of this time interval. The durability and reliability
requirements that are standard in the automotive industry certainly can be translated to any x-
by-wire system.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 10 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
3.3 Technical Requirements
Some of the technical requirements can as well be derived from conventional systems. The
maximum angles of the front wheels should be at least about 40 degrees, although there
might exist angles up to 90 degrees in future systems. At least for the introduction of a steer-
by-wire system the number of rotations at the steering wheel from one block to the other
should be approximately 3.5 - 4 rotations although this can depend on the vehicle situation
and velocity. The resolution of the steering wheel should be less then 1 degree. Superior
steering systems will probably be going down to a resolution of 0.1 degree. The accuracy
between the steering wheel and the steered wheels should be approximately 1 degree.
Concerning the dynamics, it must be possible to move the steered wheels with an angle
velocity of about 40 degrees per second. It is possible that this requirement changes when
driver assistance systems are implemented. As the steer-by-wire system uses motors there is
some fuel consumption needed for the steering function. This additional fuel consumption
should not exceed the one of servo-steering systems today.
3.4 Legal Requirements
The steering systems of today’s vehicles are governed by legal requirements which hold for
steer-by-wire systems as well. In accordance with the Council Directive of the European
Communities 70/311/EEC the steering system must guarantee easy and safe steering of the
vehicle. It must be possible to drive the vehicle accurately, i.e. without any unusual steering
corrections. Slack in the mechanical parts is impermissible. To give some data: the system
must be able to turn the front wheels into the position corresponding to a turning circle with a
radius of 12 m, respectively 20 m within a maximum of 4, respectively 6 seconds. The
maximum actuating force for intact and defective steering systems depends on the type of
vehicle (number of doors, bus or truck,...), the number of seats and the laden weight. The
actuating force must be harmonious from the centre as far as the end stop and must not
decrease. The entirety of the mechanical transmission devices must be able to cope with all
loads and stresses occurring in operation. In particular unusual driving manoeuvres, such as
driving over obstacles, accident-like occurrences etc., must not lead to any cracks or breakage.
In order to meet the requirements set by product liability it is necessary to provide a record of
all actions of the system. This data recording mechanism records driver inputs, the main
system inputs and outputs, such as wheel positions, etc., vehicle speed and fault codes. The
storage medium must be safe enough to make the data available even after an accident has
happened. The recording should be made without the use of a calendar routine for security
purposes. The only defence against product liability is a fault-free product. Thus the
manufacturer must be able to prove beyond reasonable doubt that his product was not faulty
when it was put into circulation. Traceability must be ensured so that, if faults occur, one can
determine whether other products from the same batch are affected. The greatest possible
level of product safety must be an aim early in the design stage.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 11 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
3.5 User Requirements
X-by-wire systems will only be accepted by the customer and hence be successful if the user
requirements are fulfilled. These user requirements can change over time and might even be
influenced by x-by-wire systems, but for the first introduction into the market a behaviour
similar to existing mechanical solutions is required, including slack-free driver feedback
(maybe depending on the speed and/or the angle of steering) into the zero position, continuous
operation of the steering and automatic straight run. It should be possible to alter a vehicle’s
steering from tight and sporty to a smooth, luxurious feel merely by downloading a new
program to the steering system. As x-by-wire systems allow for an easy adaptation of vehicles
for the special needs of handicapped and disabled persons they should be designed to offer
this possibility.
3.6 Safety Requirements
X-by-wire systems typically are used in safety critical applications thus there is a variety of
safety related requirements. Generally one can expect that a system does not lead to a state in
which human life, economics or environment are endangered. Thus the functional system
specification should be simple enough to completely rule out the possibility that the system
behaves in any of the ways listed as possible failure modes as long as the system performs in
accordance with this specification and no faults are present. In the presence of faults it is
required that the system is at least able to tolerate one major critical fault without loss of the
steering functionality for a time long enough to reach a safe parking area. After a failure has
been detected electronically and indicated to the driver, it must be assumed that the driver will
continue the journey to complete a trip or seek servicing. So there must be a provision to
maintain safe (reduced) operation for a limited period. Simply disabling the vehicle when it is
not absolutely necessary would not be acceptable. In terms of failure semantics this means that
the whole steering system is FoS for all failures in the fault hypothesis. Stronger requirements
may hold for subsystems. Important for subsystem failures is that a single failure of one
component within the steering system must not lead to a fault of the whole steering system.
That means each of the subsystems input, process and output must be fault-tolerant by itself.
Reduced functionality in the case of a failure is permissible as long as there is no risk to the
safety of the driver or other traffic participants. However, the system should keep as much
functionality as possible after detected errors and the implemented safety functions should not
disturb the normal functionality of the steering system. As far as possible the system should
recover from any error that is possible to correct.
On-Board diagnosis should be provided and the system has to react to any fault detected. The
recovery action must preserve safety in the steering manoeuvre in which the fault has
occurred. Fail-restricted functions (FR) must be provided for most of the severe faults by
means of reduced performance of the steering system or the engine management system (for
instance speed limitation). In case of non critical faults the system will maintain the full
operational state but has to advise the driver. For some kinds of intermittent fault the system
should at least memorise an error code for the maintenance. Moreover, the system must
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 12 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
provide information about its internal status (for example: stop immediately, service required,
or correct operation).
Automotive regulations have general requirements that all products for use on public roads
must be ―safe‖. However, such high level ―catch all‖ requirements are not, and cannot be
quantified or measured before accidents occur, and have greatest significance retrospectively
when evidence of not meeting this requirement becomes apparent. At the design stage, the
safety requirement has to be translated into identification of potential hazards and an
assessment of risk. Engineers must accept their professional responsibilities through
requirements such as ―follow best practices for safety related systems‖, ―take all reasonable
precautions‖ and ―do all that is reasonably practical to ensure safety‖. One should avoid a
black and white decision of categorising systems as ―safety critical‖ or ―non-safety critical‖,
instead it is better to use four or five levels of safety integrity. This approach is recommended
as part of the requirements. Bearing this in mind the following requirement should be handled
with care:
The probability of encountering any of the safety-critical failure modes shall not exceed 510-
10
per hour and system. This requirement should be viewed more as an indication of the
required safety level than as an exact measure that the system should be shown to fulfil. If,
however, a safety analysis indicates that a system is likely to violate this probabilistic
requirement, the system should not be certified for use.
For safety reasons there can exist requirements on the mandatory use of certain programming
languages, possibly with restrictions on the use of some programming concepts. Requirements
may also be imposed on the software structure and the entire software development process,
possibly including mandatory use of formal methods. There may also be quantitative but
easily verified requirements such as the number of program lines, the size of code, the number
of software modules, etc. The functional software specification as well as the final code shall
be sufficiently simple to permit the construction of a convincing argument (based on
inspection of the code or employment of formal methods) that there is no possibility that the
occurrence of any of the identified failure modes can justly be blamed on deficiencies in the
software alone. Similar requirements may also be imposed on the hardware such as
prescribed use of certain electronic, electrical and electro-mechanical components. Depending
on where the boundary of the system for which the requirements apply, prescribed use of
certain mechanical and other non-electronic/non-electrical components may also be included
in the requirement specification.
3.7 Subsystems
There exist various requirements concerning the subsystems. In an x-by-wire architecture
subsystems like actuators and sensors should have an electronic interface and for
environmental reasons they should be as dry as possible. For safety reasons the chosen
actuators and sensors should be based upon different physical principles. This enables the
engineer to utilise these different principles in combination to achieve fault tolerant
constraints. As most relative sensors cannot deal with a change of the observed quantity
during power down, absolute sensors should be preferred.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 13 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
A level of redundancy within the power source is required for Electronic Steering. The level
needed is to be determined by assessment and statistical calculations based on known power
supply component MTBFs and the overall system reliability and dependability requirements.
All steer-by-wire components (electronic, actuators and sensors) including their redundancies
must have a fault tolerant power supply while the vehicle moves. If the vehicle stops, this
requirement can be degraded to a single power supply.
3.8 Communication System
A real-time communication system intended for data exchange of safety-critical applications
in the automotive environment has to meet requirements that exceed the usual constraints of
communication systems in other application domains as the x-by-wire communication system
is SAE Class C. Thus regularity of information transfer must be ensured and minimising the
latency jitter or ideally maintaining a constant latency is of utmost importance. The
communication system must exhibit a fail-operational behaviour, i.e. it must be FoS itself.
The continuation of the communication service in case of an error fault tolerance should be
implemented by active redundancy. Such redundant systems require replica determinism to
maintain state synchronism. This means that active redundant components have to make equal
decisions at the same time.
A design that is utmost tolerant to electromagnetic interference and also that can recover from
a ―blackout‖ with a minimal latency is required. For error detection a consensus of which
nodes and functions that are operational, a membership agreement, is necessary, both on a
node level and possibly on the level of control functions. It is important that exits from this
membership are detected unanimously and timely. The communication protocol should
support the option of atomic broadcast and concerning acknowledgement the information
whether its message was received or not has to be provided by a proper acknowledgement
scheme.
In a hard real-time environment the implementation must guarantee, that the worst case
execution time of the server is smaller than the maximum response time that is expected by
the client. The client must respect its obligation to keep a minimum temporal distance
between two successive requests. The communication system must assure that the contents of
the messages are not mutilated and that faults that are specified in the fault hypothesis are
properly handled. From the point of view of the host computer, the details of the protocol
logic and the physical structure of the communication network should be hidden behind the
Communication-Network interface.
For composability as well as for safety reasons a time-triggered communication system should
be used. In such a case the period of the system must be small enough to allow the control
algorithms to work properly. If no assumption can be made about the failure mode of a node,
then four nodes are required to form a fault-tolerant unit that can tolerate a single Byzantine
(or malicious) fault. These four nodes must execute a Byzantine resilient agreement protocol
to agree on the malicious failure of a node.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 14 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
For an integration into a vehicle it is important that it is possible to integrate the time-
triggered real-time protocol and other existing protocols.
3.9 System Architecture
One of the main requirements of an automotive system is that it is composable. In a
composable architecture, the system properties follow from subsystem properties.
Composability is closely related to the maintenance of the temporal constraints over the
various combinations of the nodes of a distributed system. Since the integration effect is
achieved by the interaction between the nodes evidently the communication system plays a
central role in determining the composability of a distributed architecture. From the point of
view of temporal behaviour, Event-Triggered Communication Systems (ET systems) are not
composable. A TT architecture (a Time-Triggered Communication System) is composable
with respect to communication timeliness. Thus a TT-architecture is to be used. Clustering of
a system into loosely coupled subsystems interconnected by gateway nodes must be possible
to decouple different functionality. A flexible architecture should allow the integration of
additional functions, i.e., one standard functionality is developed for various vehicle series and
some comfort functions are integrated for advanced series only. Integration of parts provided
by different suppliers is desirable.
Obviously systematic design faults must be avoided. There are methods in design and
evaluation to verify the avoidance measures. Systematic manufacturing faults should be
avoided by improving manufacturing methods and quality assurance procedures. Operation
outside of the specification range must be avoided by the system designer. Perturbations that
would lead to multiple transient faults must be avoided in the design of the system.
Perturbations that cause only single faults should be treated as point defects.
The implementation of fault tolerance in a distributed real-time system must proceed on two
levels. On the architectural level a node should display simple failure modes. In the optimal
case, a node will exhibit only fail-silent failures. At the node level, the node implementation
must assure that the failure assumption that has been made at the architectural level holds with
a high probability. A node must detect all internal failures within a short latency and must
map these failures to a single external failure mode, a fail silent node failure. The error
detection in the node must be concerned with value failures and timing failures. A single
failure must not lead to a violation of the self checking property of an SRU in the temporal
domain. In a bus system, a babbling node can interfere with the correct operation of good
nodes and thus cause a catastrophic failure of the total communication system. Assuring the
self-checking coverage in the value domain should be in the responsibility of the host.
The messages should have state message semantics, i.e., messages should be in agreement
with the semantics of state variables in real-time applications. State message semantics avoids
the problem of dynamic buffer management.
To provide redundancy management a node failure must be masked by active redundancy.
Repaired or resetted nodes must be re-integrated into the cluster as soon as they become
available again. In case of redundancy it should be possible to power different replicated
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 15 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
objects (nodes, sensors, ...) by diverse power supplies. As far as possible replicated objects
should be mounted at different positions within the vehicle. It should be possible to connect
sensors and actuators to the closest ECU box. This leads to a reduction of the volume of the
wire harness.
3.10 Testing and Verification
The run time system must be designed for verifiability. The basic operation principle must be
simple and resource adequate. A simple operation principle will make the system analysable.
A guaranteed resource integrity is necessary to make it believable that the tests made on
software module level will still be valid after integration. It must be possible to separate
modules with lower dependability requirements from modules that have higher requirements,
and choose the verification level to meet the actual conformance level. Modules with different
conformance levels must be allowed to coexist on the same platform.
It must always be possible to perform a holistic FMEA on the system, software and hardware.
This can only be done if it is possible to break down the system into smaller independent
units, HW modules and ―SW modules‖, with known failure modes. The SW modules can only
be said to be independent if the RTOS can guarantee resource integrity, and if it fails to, this
must be detected so that proper action can be taken to prevent a system failure. To be able to
break down the SW into independent SW modules, it must be possible to model the behaviour
of the RTOS in the presence of faults.
A real-time architecture should support a constructive testing method, which means that each
subsystem is tested independently. If it passes this test an integration with other subsystems
must not have any side-effect. Also, a system should provide test points to connect test and
diagnostic instrumentation during development and operation in order to increase
reproducibility, observability, and controllability of test runs.
3.11 Maintainability
To set up a maintainable system, additional functionality for diagnosis and possible
malfunctions of the system must be provided. This diagnosability allows for a detailed
analysis of the system to recover the reasons of a fault from the observed faulty behaviour. In
this context, a self-diagnosing system is desirable to detect faulty behaviour by the system
itself. The mechanisms for achieving fail-silent components can be used to diagnose a faulty
behaviour of the system. To enable good maintainability, simple and small interfaces have to
be established. Additionally, diagnosis tools and interfaces have to be provided to enable fast
and cost-effective maintenance of the vehicles. Easy replacement of faulty components should
be implemented to establish a fail-reduced function and allow for cost-effective and safe
transportation of the vehicle for repair.
During the development and experimental investigation, data logging functions (that enable
visualisation of the system behaviour) help to rule out hardware and software faults and to
establish a dependable system, thus should be provided. As fault-tolerant components can
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 16 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
hide faults behind fault tolerant units, these non-visible faults should also be diagnosed. This
helps to learn about discrepancies between the actually occurring faults and the assumptions
made in the fault hypothesis. In this context, fault-injection experiments will be used to
validate the system behaviour under a specific fault scenario.
3.12 Manufacturability
The electronic steering design should be sufficiently modular to enable the same control
system, sensors and electronics module to be used on a range of products with difference
steering force requirements and hence different motor torques, power specifications and hence
drive circuits and cable sizes. Similarly, the motor packaging requirements may be different
for front and rear-wheel drive vehicles.
The vehicle manufacturer needs well-defined interfaces and respective safety and functionality
test-scenarios for the whole system. Since single sub-systems are produced by different
suppliers, special care has to be taken on the independent testability of each sub-system. This
can be realised by a composable architecture. Changing requirements are not an exception, but
the rule. A modular scaleable architecture is open to such changes and does not limit the
growth by some pre-set upper limit. The inner behaviour of the subsystems should be
encapsulated behind stable and simple interfaces and only those aspects of the behaviour of a
subsystem that are relevant for the function at issue have to be considered in order to
understand the particular function. The effort required to understand any particular function
should remain constant and be independent of the size of the system in which it is used.
Specific tests in production, field operation and service are absolutely necessary. Usual test
procedures are a chip integrated boundary-scan-test for chip-level-test, hard- and software
realised build-in-test-procedures (BIT) for board- and component-level testing, a hardware-in-
the-loop (HIL) for component-level-test and a full-functionality-test on system-level. The
design must ensure that these tests can easily be performed. During real-time operation,
permanent on-line test procedures should be running beside the normal calculations of the
control loop, in particular a built in self test should be implemented. On detecting errors an
operational or safe system state is selected to fulfil the requirement of always having system
availability.
3.13 Security
Several potential risks are identified, most are associated with deliberate misuse, but some
accidental situations also need to be prevented. Unauthorised additions to the vehicles as
after-market fitments must be prevented. When undertaken without a complete understanding
of the full implications and without adequate revalidation these could represent a major
hazard. Tampering to disguise failure, deterioration and lack of maintenance or tampering to
delete or disguise records that could provide evidence of misuse should be made as difficult as
possible. Tampering for performance enhancements benefits introduces additional risks. The
manufacturer must try to design the system in a way, that the possibility for such an external
influence can be excluded. Personal security or vehicle theft associated with a moving vehicle
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 17 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
imposes additional requirements. It is known that assailants have used electronic gadgets to
disable a moving vehicle for the purposes of personal attack and theft. The adoption of
electronic steering must not make this possibility a greater risk.
3.14 Environment
A waterproof housing for sensors and actuators mounted nearby the steering linkage and for
the ECU mounted in the interior cabin a housing with a lower protection class is required. In
general the housings of the several components have to be as small as possible. Temperatures
from -40oC in the environment up to 120oC in the engine compartment must be endured by
the electronic components. High temperature raising gradients can cause moisture on the
printed circuit board. Protection mechanisms have to be installed to prevent the printed board
from dew, because this can cause short circuits and hence faults. Normal mechanical loads
come from running the vehicle on rough roads and the components have to resist these driving
conditions. The high mechanical shock initiated by dropping the component on a hard surface
like concrete which can occur during assembly must be tolerated. Concerning EMC the
requirements are twofold. First the system must exhibit immunity from external and other
radiating sources and secondly the emission from the product must be controlled. Different
standards, regulations, and guidelines apply in this context. For high integrity requirements
such as steer-by-wire an additional safety margin over and above the legal requirement for
immunity (expressed in volts/metre) would be appropriate.
Concerning recycling and design for environment using materials that have a low
concentration in the Earth’s crust (such as copper, silver or gold) should be avoided. Also
materials that need a lot of energy to refine should be used only if they can be recycled. Only a
minimum number of raw materials should be used. The possibility of energy recycling, e.g.
energy extraction by combustion, should be considered for materials that are very hard to
recycle (e.g. certain plastics). As most hydraulic fluids imply environmental problems during
dismantling, x-by-wire systems should be ―dry‖ systems. Interconnections should not be made
by cable harnesses, but by multiplexed single pair communication busses. A modular
architecture which uses repairable and replaceable components is advantageous for reuse and
recycling. An obvious requirement is, that the system must be easy to dismantle. Moreover,
energy use and damage to the environment during production, assembly and dismantling
should be observed and as far as possible avoided. The steer-by-wire system will produce a
significant weight saving compared to a traditional system, but still it is important to ensure
that the material used actually reduces the total environmental stress.
3.15 Benefits
A steer-by-wire system offers many system specific benefits. The non-existence of a steering
column allows for new packaging concepts in the engine compartment and for a much easier
adaptation of left hand/right hand steering systems. Moreover there is much fewer
transmission of noise and vibration and there is no steering column impact in a collision. In a
steer-by-wire system driver assistance systems can very easily be integrated and an upgrade to
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 18 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
a better, newer, or extended version could in some cases even be performed by mere
downloading of software. This improves active safety as the vehicle dynamic can be
optimised. A variable steering ratio provides more comfort for instance in parking situations
and allows for an adaptation to the special needs of handicapped persons.
Although this have only been a few of the benefits of a steer-by-wire system they clearly show
that such systems will be of great importance in future vehicles.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 19 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
4 Usability of Existing Approaches
4.1 Objectives
The task of this work package was to collect and study existing approaches for distributed
control systems with requirements similar to future x-by-wire implementations. Especially
focus should be put on technical design principles, principles regarding the development
process and certification aspects and methods.
We should cover both existing industrial solutions and principles as well as new solutions
developed by universities or other research bodies.
The found useful principles and solutions were to be evaluated and compared against the
requirements specified in work package 1.
By performing this task we anticipated that we could find many useful solutions, but that we
also could clearly identify were additional research and development was necessary. The goal
was to establish a platform in the project from were additional research and development
could start.
4.2 Collection of Existing Approaches
An enormous lot of input was collected from the partners and from other companies in the
railway, aerospace, automotive, automation industry. We also got much information from
current and earlier research.
A 107 page document of references with comments was created. This document was covers
issues like existing systems, proposed systems, existing details, proposed details,
dependability, electromagnetic compatibility (EMC) and development process.
Existing systems are for example systems used in aircrafts, space-shuttles, satellites, trains,
cars and trucks and in industrial automation.
Examples of details that were covered are architecture, operating systems, agreement
techniques, communication, (clock) synchronisation, membership, software fault tolerance,
transient faults, task analysis, scheduling and task allocation, programming languages, power
supply and distribution, replica determinism and security.
Regarding dependability different assurance techniques were identified and listed.
EMC as well as development process standards were collected for further evaluation.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 20 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
4.3 Evaluation of Existing Approaches
4.3.1 Methodology
After the collection and structuring of the collected information was finished we started the
evaluation process.
We first listed a number of important design alternatives that we found necessary to choose
among and to recommend or not recommend for x-by-wire systems. These alternatives
included time-triggered vs. event-triggered operation, systematic vs. application specific fault
tolerance, different bus access principles, distributed control vs. centralised control with I/O
bus, local vs. global sensor bus, TMR vs. 2 fail-silent nodes in order to obtain fail-operational
system behaviour, exact vs. approximate consensus, experimental validation, application
programming languages and system software.
We decided upon the following important criteria for determining whether a principle or
solution were to be preferred or not: dependability, real-time, performance, manufacturability,
cost, maintenance, development process and other aspects.
The evaluation ended up in a number of evaluation tables of which the most important ones
are shown in the remainder of this section.
4.3.2 Event-Triggered versus Time-Triggered Operation
Evaluation area Event-Triggered Time-Triggered
Dependability Simplified replication management
Real-time Low average delays, limited Minimal jitter
predictability
Performance Efficient use of slack time Low system overhead. Higher
communication bit rate
Cost Less processing power needed
Maintenance Simplified testing. Modular
subsystems
Development Simplified testing and validation
process
Other aspects Improved EMC
Table 1: Evaluation Matrix, Time-Triggered vs. Event-Triggered Operation
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 21 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
4.3.3 Systematic versus Application-Specific Fault Tolerance
Evaluation area Systematic Application-Specific
Dependability Less application software faults,
because of the independence of
application programmer
intervention
Real-time Less system overhead
Performance Better performance because of more
efficient use of application
knowledge
Cost Lower development cost Lower hardware cost
Development Higher quality due to simplified
process validation
Table 2: Evaluation Matrix, Systematic vs. Application Specific Fault Tolerance
4.3.4 Bus Access Principles
Evaluation Area Token Passing CSMA/CD CSMA/CA TDMA
Dependability Fair Poor - no error Simple error
detection detection
Real-time Fair. Certain Poor. Non- Good. No jitter,
latency and deterministic Certain latency.
jitter. latency and
jitter.
Performance Poor Medium Good control
performance at frame performance
high bus overhead Low message
utilisation overhead, poor use
of bandwidth if load
patterns differ much
Development No scheduling Easy Hard scheduling
process scheduling
Other aspects Favourable EMC
properties
Table 3: Evaluation Matrix, Bus Access Principles
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 22 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
4.3.5 Centralised Control with I/O Bus versus Distributed Control
The two basic variants are illustrated in the figure below
Host Global Bus
Global Bus Node
Local I/O
A S
A S A S
Centralized System Distributed System
Figure 3: Centralised and Distributed Systems
Evaluation Area Centralised System with I/O Distributed Control with Local
Bus Buses
Dependability Several nodes on global bus Small number of nodes on global bus
reduce dependability increases dependability
Real-time Large control delays due to Short control delays due to low bus
high bus usage usage
Performance High data rate Low global data rate. Agreement bus
traffic due to distributed intelligence
Cost One bus interface and
connector per device
Table 4: Evaluation Matrix, Distributed Control vs. Centralised Control with I/O Bus
4.3.6 Design Alternatives for Fault-Tolerant Nodes
The two most interesting were compared. The design alternatives are shown in the figure
below:
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 23 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
TMR Fail-Silent
Figure 4: TMR and Two Fail-Silent Nodes
And the comparison is shown in the table below:
Evaluation area Single TMR Node Paired FS Nodes
Dependability Any fault affecting Coverage of fail-silence mechanisms is crucial
a single module is The two nodes may be physically separated (to
tolerated reduce the probability of common mode faults)
Source of Replica
Indeterminism
Performance Fully active replicas require 100% bus traffic
overhead
Cost Triplicated Ultra-dependability may require that each FS node
hardware is a duplex computer (resulting in a total
redundancy factor of four)
Increased number of bus connections
Table 5: Evaluation matrix, TMR vs. 2 Fail-Silent Nodes to Obtain Fail-Operational
System Behaviour
4.3.7 Exact or Approximate Consensus
Exact or approximate consensus is also an important design choice. A comparison is made
below:
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 24 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
Evaluation area Exact Approximate
Dependability Simple voting/comparison Problems with dynamic and wide
technique resulting in high thresholds for detecting for declaring a
dependability on system level value faulty
N-version programming not Complex error detection mechanism
supported
Development - Formal verification and analysis
process difficult
Table 6: Evaluation Matrix, Exact vs. Approximate Consensus
4.3.8 Application Programming Languages
Application programming languages have to be chosen and a number of aspects are important
for the choice. The evaluation parameters used above are not applicable when we discuss
languages. Other parameters dominate. Such parameters are that they are available for the
designated hardware, that they can utilise test tools, that we should avoid special languages
and that it should be possible to perform WCET for applications written in these languages.
It appears that C is the only candidate and that the use of a subset might improve
dependability.
4.3.9 System Software
Regarding system software we can conclude that an operating system is needed. OSEK is
interesting but not suited for safety-related tasks. Among the tasks that has to be handled are
hard real time requirements, distributed fault tolerance, replicated processes, system wide
synchronised view of time, scheduling and inter-process communication. Mechanisms for
handling that replicated processes executes same set of data, dynamic scheduling, static
scheduling (dispatcher is activated by the synchronised clock tick) and error detection in the
temporal and value domain have to be present.
4.3.10 Development Process – Verification and Validation
Our conclusion was that the automotive industry has a very unique and complex
supplier/manufacturer structure and that it is not possible to identify an existing development
process for distributed control systems, which could be extended to cover fault tolerant
systems for very safety critical applications, like x-by-wire as well. Today’s approach for
achieving necessary quality is based on different methods used by suppliers on individual
electronic units and the procedure to assure that all different parts together make up a well
working total system, is more or less based on intensive ad hoc testing when system failures
appear.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 25 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
The most interesting generic standard found was IEC 61508 (formerly IEC 1508). This
standard can be used as one starting point for a development process for x-by-wire systems.
The unique supplier/manufacturer structure that is present in the automotive industry is a very
important but complex and difficult to handle requirement, that must be reflected an
considered by the development process.
A certain requirement that is difficult to handle in a development process is the capability to
verify that the designed and anticipated fault tolerance exists. This is not tested during normal
functional testing. Some sort of fault injection is necessary.
The fault injection techniques can be compared with respect to the characteristics or properties
listed in the following table. Note that the evaluation framework discussed earlier is not
applicable for this type of evaluation candidates. This comparison shows quite clearly that the
different categories of fault injection techniques complement each other well.
Evaluation Area Physical Fault Simulated Fault Simulated Fault
Injection & &
Physical System Simulated System
Can be used early in the design No No Yes
stage
Can be used on the actual system Yes Yes No
Amount of system activity that High High Low
can be studied
Fault modelling capability High Low Medium
Reachability (amount of nodes High Low Medium
that are possible to inject into)
Temporal controllability (ability Low High High
to synchronise to system
activities)
Spatial controllability (ability to Low High High
select fault injection location)
Observability Low Low High
Table 7: Evaluation of Fault Injection Techniques
4.3.11 Conclusions
The efforts performed in work package 2 were very successful and the objectives were met.
The present (before x-by-wire) level regarding design principles, development process etc.
were identified and the necessary research and development could continue in work package 3
Unfortunately the state of current component technology, systematic fault tolerance methods,
development process etc. was below the anticipated level, hence more basic work will be
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 26 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
required in work package 3 than initially estimated. Most of the adequate solutions found
were results from research and existing solutions could not be used.
Based on the previous evaluation tables we decided to recommend a number of preferred
principles. We, for example, strongly recommend that x-by-wire systems operate in a time-
triggered fashion, using TDMA as bus access scheme. Furthermore distributed systems are
favourable regarding dependability and real-time behaviour.
As far as the support for fault tolerance is concerned, a systematic approach should be used as
the basis. Such an approach should be based on fail-silent nodes and defined error models and
error detection principles for the program execution. The fail-silent nodes can be physically
paired and thus implement a fault-tolerant unit. In general it should be possible to implement a
fault-tolerant application by fail-silent applications, ‖hosted‖ on arbitrary fail-silent nodes.
For the implementation of fault tolerance exact consensus is preferred. This does not exclude
more application-oriented methods (design diversity) which might have advantages in certain
applications. The general strategy is systematic but in certain applications other methods could
be added.
For the system software an operating system that meets hard real-time requirements and
supports distributed fault-tolerance and appropriate error detection is required.
The actual application software should be written in a programming language that is available
for multiple hardware platforms (e.g., a well-defined subset of C) and facilitates worst-case
execution time analysis. Tools for the software design and for the pre run time scheduling of
program execution and communication have to be developed.
For the development process of x-by-wire systems the generic IEC 61508 (formerly IEC
1508) standard can be used as a starting point, since there does not seem to exist a
standardised development process for present distributed systems in vehicles.
During the test phase fault-injection support is required in order to validate the fault tolerance
properties of x-by-wire systems.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 27 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
5 Architecture Definition
This work package represents the main part of the project work, as the objective of the x-by-
wire project is to define a framework for the introduction of safety-related fault-tolerant
electronic systems in vehicles. The architecture definition encompasses all levels of an x-by-
wire system, from the conceptual system architecture down to the hardware and software
architecture of the individual subsystems.
The project proposal identified seven work tasks within the architecture definition work
package:
Conceptual Architecture
Dependability
Development Process
Hardware Components
Power supply / Packaging / Sensor and Actuator Coupling
Communication System
Software
As a result of the observations made and conclusions drawn during the project, this report
does not strictly adhere to this subdivision of the architecture definition work package:
Dependability is a major concern throughout the project and has a major impact on all parts
of the architecture definition. Therefore, a separate subsection on dependability-related
results and conclusions is not meaningful.
Owing to the rapid evolution of electronic components, it is neither possible nor desirable
to specify detailed hardware requirements at this point in time. For the electronic
components, the only characteristics suitable for specification are closely related to the
conceptual architecture and communication system, which are reported separately.
Therefore, all other hardware aspects (components, power supply, sensor and actuator
coupling) have been concatenated into a single subsection of this report.
5.1 Conceptual Architecture
In order to cope with the requirements for scalability and dependability, it was decided early
on in the project work that the system architecture should be distributed. Thus, a number of
electronic control units, or nodes, would be interconnected by a communication network,
exchanging information with each other and controlling the applications. The distribution of
functions is also in line with the present trend in automotive electronics.
Owing to the fault tolerance requirement of any x-by-wire function, the chosen architecture is
based on redundancy at all levels. The nodes are arranged in pairs communicating with each
other and with other nodes on a dual-redundant bus as shown in Fig. 3. Each node is designed
to be a fail-silent unit (FSU), i.e. it is either operating correctly or it is completely silent
towards the bus channels and towards its actuators. Two or more such units perform identical
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 28 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
application tasks and together form a fault-tolerant unit (FTU). Note that each of the FSUs
shown in Figure 5 has its own power supply, thus making the FTU capable of tolerating a
single power failure.
The fail-silent property is likewise enforced for each of the two bus channels, based on error
detection coding and check for compliance with expected communication behaviour. Thus,
the architecture is capable of tolerating a failure of any bus channel.
BUS CHANNELS
SENSOR &
ACTUATORS Fault-Tolerant Unit (FTU)
FSU
Fail-Silent
Unit
(FSU)
POWER SUPPLY
Figure 5: Structure of a Fault-Tolerant Unit (FTU)
By interconnecting a number of FTUs, and assigning a specific part of the overall function to
each FTU, a distributed fault-tolerant system solution is obtained. One such FTU could for
instance act as a pedal unit, collecting information from the driver's pedals and another FTU
could perform the overall vehicle motion control algorithms, e.g. ESP1. A single FSU could
control the braking and suspension of, say, the left front wheel of the vehicle, which shows
that a mixture of single FSUs and FTUs will make sense in practice. Yet another FTU could
control the braking and suspension of, say, the left front wheel of the vehicle. In the steer-by-
wire prototype (see Section 6), a similar allocation of the subfunctions is made, with a steering
FTU (two FSUs), a steer-by-wire control FTU and a steering wheel FTU (two FSUs).
In order for the described architecture to be fully fault-tolerant, the fail-silence property has to
be enforced at the FSU level as well as at the communication channel level. Thus, the
identification and analysis of mechanisms for obtaining the fail-silence property constitutes a
large part of the architecture definition work. However, the architecture also permits the
construction of an FTU from more than two nodes. A voting algorithm may then be used, to
enable the masking of value domain failures.
1
ESP (Electronic Stability Program) is a function that compares the vehicle cornering behaviour with the
intentions of the driver (as reflected by the steering wheel) and applies individual wheel braking when necessary.
The main purpose of the ESP function is to avoid excessive understeering and oversteering.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 29 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
A major conclusion of the x-by-wire project is that systematic fault tolerance is preferable to
application-specific techniques. This conclusion has influenced most parts of architecture
definition, and is mainly based on the following observations:
Application-specific fault tolerance is based on plausibility checks for error detection.
These plausibility checks will always be a compromise between the need for high
detection coverage and low probability of "false alarms". Consequently, grey zones will
exist in which existing errors are undetected and/or the system detects an error when there
is no error present. Systematic methods, on the other hand, have a much more well-defined
behaviour and do not suffer from this grey zone problem
With systematic techniques, a clear boundary exists between fault tolerance methods and
application software. Thus, the application designer can focus on the application. As a
result, the system will be much easier to develop, model, validate and test. Application-
specific techniques, on the other hand, typically result in a system for which these tasks are
tedious endeavour, if not impossible.
However, application-specific mechanisms can not be completely ruled out, as cost
considerations may in certain cases dictate that systematic mechanisms can not be employed.
5.1.1 Communication System
The communication system forms the backbone of any distributed system. Rather than opting
for an architecture in which the communication is just one task among many within the nodes
of the system, the project partners decided that the communication system would provide the
foundation on which the operation of the entire system would be based. Thus, the
communication system should provide all services necessary for a truly distributed fault-
tolerant operation to the nodes. These services include synchronisation, membership
agreement, message error detection, reintegration of temporarily failed nodes and support for
fault tolerance mechanisms.
5.1.1.1 Time-triggered communication
The time-triggered communication principle, in which the nodes access the communication
channels according to a predefined static schedule, has a number of attractive properties in
safety-relevant real-time systems. These are:
Separation of data processing and communication tasks within a node
A time-triggered communication operates almost autonomously. From the point of
view of the processing part of a node, the communication system has a simple
read/write interface. Thus, a fault in the processing part of a node can not affect the
time at which messages are transmitted onto the bus. In other words, control errors in
the processing part can efficiently be prevented from propagating to the
communication network. In particular, the "babbling idiot" problem (in which one
node sends meaningless messages at arbitrary points in time, thereby preventing other
nodes from accessing the communication network) can be eliminated. This elimination
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 30 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
can be made very efficient since the bus access principle is extremely well-defined in a
time-triggered system.
Composability
In a composable system, the properties that hold for a subsystem also hold when this
subsystem is integrated with other subsystems. Thus, composability simplifies the
analysis, verification and testing tremendously. For instance, two nodes that together
perform some specific function can be developed without any consideration of the
characteristics and operation of other nodes that may be connected to the same
communication network. Once the static medium access schedule has been defined,
subsystems and subfunctions can be developed and tested independently of each other.
Low jitter
In real-time control systems, timing aspects are obviously extremely important. In
particular, the latency of messages exchanged via the communication network has to
be controlled. In a time-triggered communication system, this latency is determined
before the system is put in operation. Thus, the variation in message latencies, i.e. the
message jitter, can be made very small. This is in contrast to priority-driven
communication systems, in which the latency of a message is dependent on the current
amount of higher-priority messages waiting to be transmitted from other nodes.
Furthermore, processing activities can be synchronised with he communication so that
for instance the reading of a sensor takes place immediately before this value is sent on
the bus.
Support for a global clock
A consistent view of time is highly desirable in distributed real-time control systems,
in order to permit synchronisation of system-wide activities such as mode changes and
actuator activations. With a time-triggered communication system, a global clock is
obtained virtually "free of charge" since the message traffic on the communication
network provides this clock.
No bandwidth limitation imposed by the protocol itself
In the presently predominant communication principle for automotive electronic
systems, CAN (Controller Area Network), message collisions on the bus are perfectly
normal and are handled by a bit-by-bit arbitration mechanism. A prerequisite for this
mechanism is that the bit rate on the bus is below a certain limit. In short, the
arbitration only works when the bit rate is sufficiently low so that propagation delays
between any two nodes of the network are much smaller than the duration of one bit.
In contrast, a time-triggered protocol does not have this limitation, thereby permitting a
much higher bus bandwidth. When and if optical fibers become a viable alternative to
electrical communication media, this aspect will be highly important.
Possibility of strong filtering for improved EMC characteristics
Today, the available communication bandwidth is mostly connected to the amount of
electromagnetic interference generated by the wiring of the communication lines.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 31 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
Obviously, the signals can be filtered but the arbitration mechanism described in the
previous point sets a limit to the amount of filtering that can be made in a priority-
driven communication system such as CAN. A time-triggered communication system,
on the other hand, permits a stronger filtering and thereby appears to permit a higher
bit rate without compromising the EMC characteristics.
Simplicity and predictability
A time-triggered system is conceptually simpler and consequently easier to analyse
than a priority-driven one, particularly when errors are considered. Furthermore, a
time-triggered system is more predictable and provides a cleaner platform for the
introduction of fault tolerance mechanisms, thereby improving the reliability of the
system.
5.1.1.2 The TTP/C communication system
For the x-by-wire project, the TTP/C (Time-Triggered Protocol, Class C2) protocol developed
at the Technical University in Vienna was chosen as the communication system. During the
project, it has been further developed and adapted to automotive requirements. The protocol
and its associated implementation is described in some detail in the following since it
represents an essential part of the architecture definition.
This protocol operates according to the TDMA (Time Division Multiple Access) principle, in
which each node connected to the bus has a pre-allocated time slot in which it sends a
message on the bus. The length of these time slots may be different for different nodes but is
fixed before the system is put into operation. Thus, the TDMA round, in which all nodes send
one message each, is a fundamental concept of TTP/C.
In a TTP/C system, the host computer in a node runs the operating system and the application
software while the TTP/C controller manages the communication with other nodes (Figure 6).
The communication network interface (CNI) between the host computer and controller is
formed by a dual-ported random access memory and an interrupt line from the controller to
the host. The dual-port memory is the data sharing interface between the host computer and
the controller that holds the data that are exchanged between these two subsystems. In
addition, the CNI contains an area in which the controller and the host can exchange status
and control information. (Note, however, that incorrect control messages from the host can
never make the TTP/C controller transmit outside its pre-allocated time slot.) The signal line
delivers the ticks of the globally synchronised time from the controller to the host computer.
To reduce the load on the host computer, only those ticks of the global time that are
significant for the host are signalled. The host can select the significant ticks by setting the
appropriate parameters in the CNI.
The controller comprises the protocol engine, the storage for the TTP/C control data (the
TTP/C message descriptor list, MEDL), and an independent hardware unit, the bus guardian,
to protect the bus from timing failures of the controller. The MEDL contains, among other
2
The Society of Automotive Engineers has defined three classes of multiplex systems, with class C representing
the most demanding requirements, namely those associated with real-time control.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 32 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
information, a description of which locations in the CNI that should be read or written at any
point in time. Thus, the MEDL defines the operations to be made by the controller during a
sequence of TDMA rounds. This sequence, after which the controller starts from the
beginning of the MEDL again, is called a cluster cycle. Figure 6 shows the structure of a
TTP/C node and in Figure 7 the relationship between the protocol-related time intervals is
shown.
Host
Interrupt
Computer
line
CNI
TTP/C Controller
Protocol Engine
MEDL
Bus Guardian
Line receivers/drivers
Two-channel TTP/C bus
Figure 6: Structure of a TTP/C controller
TDMA Slot
(4-64 per TDMA round)
TDMA Round
(2, 4, 8 or 16 per cluster cycle)
Cluster Cycle
Figure 7: Relationship between protocol-related time intervals
The TTP/C protocol includes a mode concept that permits the communication system to
behave differently at different points in time. For example, there is a start-up node in which no
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 33 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
application-related data is exchanged. In this mode, the nodes only exchange the information
required for synchronising the nodes and getting a consistent view of the system.
In addition to providing a basic communication service and the inherent benefits associated
with time-triggered communication, the TTP/C controller provides the following services:
Membership management
The nodes continuously keep track of which nodes that perform correctly with respect
to the predefined communication behaviour. The TTP/C protocol ensures that all
correctly operating nodes get a consistent view of this membership.
Reintegration of a temporarily failed node
A temporarily failed node should be able to reintegrate into the system. It therefore
needs to be able to synchronise to a running TTP/C network and to have a
membership view that is consistent with the other nodes of the network. Also, it
needs to know the current system mode. For this purpose, special initialisation
frames containing all this information are inserted into the message stream. Also, a
reintegrating node may need to be loaded with some application-related data that
represent the history of the application. Thus, transmissions of this history state is
likewise inserted into the message stream. A reintegrating node therefore expects to
receive the history state from the other FSU in the FTU.
Mode management
A TTP/C network has a number of possible modes, with each mode representing a
certain sequence of messages transmitted in a cluster cycle. Thus, each mode is
controlled by a separate part of the MEDL in the TTP/C controllers. The protocol
includes a mechanism for permitting a node to request a mode change and to ensure
that all nodes simultaneously change the mode in response to this request.
Message error detection
The basic mechanism for detection of message errors in a TTP/C system is provided
by a CRC (Cyclic Redundancy Check) field included in each message. This field is
calculated from the data transmitted in the frame and also from the membership,
time and mode as seen by the sender. As a result, a transmission error or an
inconsistency in the view between a sending node and a receiving node results in a
CRC error. In this case, the membership management ensures that the correctly
operating nodes eventually obtain a consistent view of the system.
Clock synchronisation
The TTP/C controller runs a fault-tolerant averaging algorithm that ensures fault-
tolerant synchronisation with a precision in the microsecond range. Typically, the
nodes with the most precise clock generators participate in this synchronisation
while other nodes only adjust themselves to the results of this.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 34 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
5.1.2 Hardware
5.1.2.1 Power Supply
The conceptual architecture described in Section 5.1 includes the notion of a dual-redundant
power supply. Thus, the power supply part of an x-by-wire system shall have two outputs, of
which at least one shall be fully operational even when there is a fault in the power supply
part. In the project, several configurations that provide this capability have been investigated.
It was found that the most suitable solution is the one shown in Figure 8. The switches are
normally closed but are controlled by fault detection circuitry which opens a switch when
necessary. Also, fuses should be introduced to protect against short circuits between the PS
lines and ground.
PS2
PS1
G
Figure 8: Preferred Power Supply Configuration
The rationale for choosing this particular solutions over the other candidates were the
following:
A battery is less expensive than an alternator and the trend of car manufacturers is toward
adopting two batteries. Consequently, solutions based on two alternators and one battery
are not a viable option.
The chosen configuration can tolerate all single and double open circuit faults on batteries,
alternator and connections among them.
A single cable fault does not stop the correct working of the system since PS1 and PS2 use
independent wiring.
5.1.2.2 Sensors
The sensor technology is currently undergoing a rapid development. For x-by-wire
applications, the development of micromechanical and micromachined sensors is particularly
interesting, as are sensor technologies based on optical principles. Also, the concept of a
"sensor cluster", in which several sensors are integrated into an intelligent unit communicating
on a digital bus, is currently attracting a large interest in the automotive industry.
As a result of the continuously ongoing development in this area, specific recommendations
for the design and connection of sensors to be used in x-by-wire systems cannot be made at
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 35 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
this point. A methodology for analysing the dependability of various sensor connection
strategies has been established as part of the x-by-wire project, taking both point-to-point and
bus interconnections into account. Owing to the unknown dependability characteristics of
future sensors and their associated circuits, however, no definite conclusions can be drawn
from the analyses made since the choice of a suitable connection strategy is heavily connected
to these characteristics. Nevertheless, the methodology is expected to be very useful once
these characteristics are known.
An important topic in x-by-wire systems is the concept of fail-silent sensors. Two possible
implementation strategies for achieving this are:
The sensor is internally fail-silent in the sense that it either outputs a correct value or a
detectable incorrect value (possibly by being completely silent towards its output).
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 sensor-internal redundancy in the form 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
analysed by an intelligent unit that makes a decision of which value to use in further
calculations. Again, 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.
5.1.2.3 Actuators
As for sensor connections, a methodology for analysis of the resulting dependability of a
number of actuator connection strategies has been established within the x-by-wire project.
This work has also identified a number of strategies for how to maintain the redundancy all
the way to the controlled object. Examples of this are dual windings in solenoids, flux-
summing devices and the use of redundancy in other electromechanical components.
For actuators, the fail-silence property is essential in order to maintain control of the vehicle
even when an actuator failure exists. In addition to actuator-internal mechanisms to achieve
fail silence, monitoring of the actuator behaviour is typically required. This monitoring
requires the use of sensors that continuously monitor the actuator behaviour (e.g. motor
current, motion, force, torque, etc). When these sensors indicate a serious actuator failure, the
power to the actuator should be switched off.
5.1.2.4 Electronic components
Electronic components in general, and micro controllers and memories in particular, are
currently exhibiting a rapid and steady evolution. Owing to the lack of knowledge about the
characteristics of future components, it is not meaningful to define a low-level hardware
architecture for the electronics in x-by-wire systems. However, a number of hardware-based
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 36 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
mechanisms providing support for fail-silent behaviour have been identified and analysed
within the x-by-wire project. Some examples of such mechanisms are:
Watchdog timers
Error detection coding
Built-in self-test (BIST)
Execution flow monitoring using instruction block signatures
Since the communication is an essential part of any distributed system, particularly when real-
time aspects and fault tolerance have to be considered, the project has focused on the
definition of a communication interface. Thus, the TTP/C protocol and its implementation in
represents a major part of the project work on hardware components for x-by-wire systems.
The TTP/C controller is presented in Section 6.3.1.
Future automotive systems will take advantage of the increased processing capability so that
the software complexity will grow. This will accentuate the need for good software
development procedures. Consequently, the x-by-wire project has devoted much work to the
software structure and the associated development process (see Section 5.1.4 below).
With the decrease of feature sizes and the lowering of operating voltages, transient faults can
be expected to be more frequent in the future. Consequently, the detection and handling of
transient faults has been given much attention throughout the project.
5.1.2.5 Electromagnetic Compatibility Aspects
As previously mentioned, the electromagnetic radiation emitted from the communication
wiring sets a limit to the bit rate that can be used in onboard automotive communication
systems. Within the project, this issue has been studied thoroughly and a number of interesting
results have been found. Mainly, they are the following:
Proper termination of the bus wiring is essential.
Stub connections shall either be avoided or kept short.
A time skew between the two signals in a differential arrangement gives rise to common-
mode "spikes" that cause emission problems.
Owing to the antenna effect, strong radiation emissions occurs at certain frequencies.
Consequently, this has to be considered when the physical layout of the wiring is
determined.
Non-arbitration protocols permits stronger signal filtering, thereby reducing both the
emission and the susceptibility. However, the amount of filtering that can be made is yet to
be determined.
5.1.3 Software
Currently, the software complexity of automotive electronic applications is growing
considerably. For the next generation of applications, it is expected that the aspects of
distribution, fault-tolerance, and hard real-time will dramatically increase overall software
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 37 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
complexity. It is therefore of utmost importance to define a clean software architecture which
integrates these aspects seamlessly while considering the stringent efficiency constraints in the
area of automotive electronics. It was one of the major tasks within work package 3 of the x-
by-wire project to work on this topic and to provide such a framework for the prototype
implementation.
Within the project a number of conceptual application models have been presented, like the
Basement and DFR model. The XBW model defined within the project makes a simple
condense of these models describing the relevant characteristics for the objective of the
model, all according to the frames of the project. The model enabled the definition of a fault
and failure model and thus a systematic analysis of fault tolerance characteristics assuming
this fault and failure model.
The design of the proposed model as well as of Basement and DFR Model was governed by
the following set of objectives:
Composability: Composability means that the components of a software system can be
developed independently and integrated at a late stage of software development. The goal
is to allow smooth and painless integration of components.
Integration on the object-code level is essential to protect the intellectual property rights of
the project partners in collaborations between independent companies.
Reusability: Reusability is based on composability. The goal is that a component can be
used in different control systems and on different hardware platforms. Reusability requires
a strict separation of abstraction levels and domains.
Testability: It is important that software components, once tested, can be integrated with
little or no re-testing in different systems. Again, this requires a strict separation of
abstraction levels and domains which must be maintained by the object model across
different systems.
Maintainability: An existing software system must be easily adaptable to changes in the
specification without incurring a loss of quality and software robustness. Specifically, the
changes must be localised in extent. They must not result in detrimental effects on other
components of the system.
This set of objectives represents the primary determinants for time-to-market, development
cost, and quality of software.
5.1.3.1 xOLT
To support the software-engineers of the project, bringing the specification of a steer-by-wire
system into a laboratory prototype, the DFR-Model has been taken and implemented on the
basis of the so called Off-Line Tools (OLT). This eXtended OLT (xOLT) is a language (xOLT
interface description) to model the safety related fault-tolerant system. Modelling is based on
the predefined objects of the three domains of the DFR-Model:
Value domain: The value domain is concerned with the functional behaviour of objects.
This is the domain addressed by conventional object-oriented programming languages. In a
non-real-time system with sequential software only, this is the domain of interest.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 38 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
Although the functional behaviour of some objects can exhibit internal parallelism, the
value domain does not prescribe any aspect of synchronisation or occurrence of temporal
events.
Time domain: The time domain is concerned with the temporal behaviour of the objects in
a concurrent software system. The time domain addresses the dynamic interaction of
independently active objects — sometimes called agents or actors — and the events
triggering changes in the system state.
Distribution domain: The distribution domain is concerned with the association of
software components to specific processors or nodes in a distributed fault-tolerant system.
These three domains are orthogonal to each other. Inadvertent mixing of the domains
unnecessarily increases the software complexity and effectively prevents the achievement of
the primary quality objectives.
After modelling the system with the xOLT interface description and the functional code in
between, the xOLT is started and pre-processes the specified domains in two phases
Analysis of the specification (syntax checks)
Synthesis of the specification (including conversion to C-code).
The output of the second step is compiler-ready C code of all domains. This code is optimised
to be linked together with the operating system xERCOS (eXtended Embedded RealTime
Control Operating System).
The xOLT interface description offers a lot of possibilities for further service functionalities,
most notably the following:
support of the communication system handling
error detection mechanisms
support for fault-tolerance
These services are briefly presented in the following.
5.1.3.2 Support of the communication system handling
The application programmer should get the best support for the implementation of a
distributed fault-tolerant system, which can be achieved by a well suited design framework,
such as DFR-model or Basement. But the programmer will have to establish some kind of
communication among its replicated systems and the access as well as the configuration of the
communication subsystem has to be supported in an easy way. By defining the system from
the point of view of the distribution domain using a predefined set of commands, e.g. xOLT
interface description, a lot of support can be generated based on this information by a tool, i.e.
automatically. An additional layer between the application software and the communication
subsystem, e.g. TTP/C is established.
The focus of such a functionality, assuming TTP/C is used, relies on:
synchronised start-up of application with TTP/C
start-up membership service
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 39 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
reintegration of a node
membership service
lifesign mechanism
This communication handling is included in the xOLT tool as well and was used during
development of the Steer-By-Wire prototype implementation.
5.1.3.3 Error detection mechanisms
Theoretical work of this work package came up with a lot of error detection strategies
especially for the node local (node level) error detection. Node level covers any errors
detection on a physical node without handling the problem of distribution (replicated nodes).
The node-level mechanisms "double execution", "double execution with reference check",
"validity checks for messages", "history-states", and "resources", "assertion checking", and
"signature checks" support a high error detection coverage. They are necessary to fulfil the
fail-silence assumption for individual processing nodes. These mechanisms are independent of
the semantics of a specific application and can thus be applied systematically. Each of the
mechanisms can be implemented without coupling the application software to a specific fault-
tolerance strategy. Assuming that a subsystem is double execution stable, it can be used both
in fault-tolerant and non fault-tolerant systems without any change of it’s source code.
5.1.3.4 Support for fault-tolerance
It was the goal of this work package to bring the theory about software support for fault-
tolerance into practice. The focus was on systematic fault-tolerance. Whereas application-
specific fault-tolerance uses knowledge about the application domain to achieve fault-
tolerance in an ad-hoc way, systematic fault-tolerance uses replication of components to detect
faults and applies redundancy to achieve continued service in the presence of faults.
Although systematic fault-tolerance potentially incurs higher costs than application-specific
fault-tolerance it offers a number of advantages as well, specifically:
Independence of application knowledge.
Broader applicability.
Less software complexity.
Separation of application-specific and fault-tolerance functionality.
Reusability of fault-tolerance mechanisms across applications.
Reusability of application software in systems with differing degrees of fault-tolerance.
The realisation of these mechanisms is included in the xOLT tool as well and was used during
development of the Steer-By-Wire prototype implementation. If you bring this functionality
into a layer model again, these mechanisms can be summarised into the FT-layer (fault-
tolerance layer, see Figure 9) which has an important role working with active replicated
systems.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 40 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
Host
FT-Layer
TTP/C
Figure 9: The Fault Tolerance Layer within a Node
The distributed mechanisms "active replication"," message agreement", and" timed messages"
support the tolerance of permanent processor node and peripheral faults. Software components
are replicated at the granularity level of subsystems; thus redundancy can be achieved in
correspondence with dependability requirements without incurring unduly high hardware
costs. Again, these mechanisms can be implemented without coupling the application
software to a specific fault-tolerance strategy. A subsystem must be declared replica-
determinate to allow active replication. If this constraint is met, the subsystem can be used
replicated as well as non-replicated without any change of its source code.
5.1.4 Development Process
An integrated development process and certification procedure is highly needed for future
development of x-by-wire systems. This process should be tailored to the automotive-specific
requirements of ultra-dependability and low cost. A survey of the existing procedures for
system development has been carried out within the project, resulting in the selection of the
IEC 61508 (formerly IEC 1508) standard as the starting point for the development of such a
process. This is a generic standard that can be extended and modified to suit a particular
application. In particular, the IEC 61508 needs to be extended with considerations of the
communication between the nodes of the system, in order to be applicable to development of
x-by-wire systems.
To be useful, the development process shall be tailored to the fundamental concepts employed
in the target system. Some of the most important results from the collection and evaluation of
existing approaches (Section 4.3) were that a time-triggered approach shall be adopted for x-
by-wire systems and that a specific software model suited to time-triggered execution, shall be
used. Furthermore systematic fault tolerance is an important basis for x-by-wire systems. All
of these aspects should be reflected in, and supported by, the development process.
Quality assurance performed on existing event triggered distributed control systems has
shown that a specification check list is very useful both during the initial design of systems
and during the verification process. This list may be broken down into several layers, typically
the following for an x-by-wire system:
application tasks covering scheduling, etc.
broadcast data to be sent between application tasks
messages sent on the buses
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 41 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
communication handling
communication controller handling and physical properties
In the x-by-wire project, a number of important parameters to specify have been identified for
each level.
Assuming the specific software model preferred for x-by-wire systems, essential
characteristics and capabilities of the necessary tools for the design and verification have been
identified. These tools include:
tools for pre-run-time scheduling
tools for estimation of worst case execution times
tools for downloading and verification of correct downloading of programs
tools for monitoring the system behaviour during program execution
tools for verification of fault tolerance
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 42 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
6 Prototype
6.1 Introduction
The aim of work package 4 (Prototype) is to specify with great details, implement and
evaluate a steer-by-wire prototype without mechanical backup and to verify the results of the
other work packages.
Main prototype purposes are:
demonstration of the general architectural definition and the processes/methodologies
studied in other tasks
demonstration of the fault tolerance characteristics of a X-By-Wire system
The prototype is a laboratory demonstrator for evaluation purposes only, based on components
available today (off-the-shelf electronics and tools).
The prototype architecture and implementation follow as far as possible what is specified in
X-By-Wire project. Exceptions are related to cost and time constraints, to the laboratory
nature of the prototype and to the fact that the main goal of the prototype is to demonstrate the
fault tolerance characteristics rather than the steer-by-wire function.
Demonstration principles and evaluation of the activities done in this work package take into
account the above mentioned prototype limitations.
The prototype implementation is a ―Steer-By-Wire‖ Demonstrator. This application is very
challenging because of its innovative contents and real difficulties. In facts this is a very
critical application from the point of view of the safety level that such a system must
guarantee, for example there is no fail safe steering position. Moreover this system impacts
both on active and passive safety. By means of opportune active steering control is possible to
avoid that dangerous situations lead to serious accidents. Considering passive safety the
absence of the steering column decreases the effects of an accident on the driver.
Comfort aspects have to be considered too, variable steering characteristics (for example
management of the steering wheel load) make driving more comfortable.
6.2 Prototype in General
The main function of the prototype is to demonstrate the fault tolerance characteristic that an
x-by-wire system must have in a steer-by-wire implementation. It is not necessary to
demonstrate it within a car because most of the functions can be demonstrated using a
laboratory prototype. General functions that the system has to perform are:
Compute the vehicle steering angle starting from driver's wishes, taking into account
vehicle situation, and consequently move the driving wheels.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 43 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
Compute tactile feedback and give feeling to the driver.
React to the faults injected by means of the appropriate strategy.
Optimum steering characteristics are not the most important requirements of the prototype,
since the project essentially intends to demonstrate the safety functions.
The fault tolerance capabilities of the demonstrator are as follows:
the system should tolerate a transient fault
the system should tolerate one permanent fault
the system should tolerate a transient fault after a permanent fault has occurred.
The fault tolerance characteristics can also be expressed using the FO/**/FS concept. The
system should be FO/FS for transient faults, that means fully operational after the first fault
and, in case of a second concurrent fault (very improbable situation), the system should go in
a safe state. Considering a steer-by-wire application there is not a real fail safe steering
position, in this case FS means that the system locks the wheels in the current state during the
fault recovery time.
In case of permanent faults the characteristics are:
Considering power supply system faults, the steer-by-wire system must be FoS/FrS (fully
operational for a predefined time interval after the first fault and operational but
functionally reduced for a predefined time interval after the second fault)
For other permanent faults except FTU faults the steer-by-wire system must be FO/FrS
(fully operational after the first fault and operational but functionally reduced for a
predefined time interval after the second fault)
For FTU permanent faults the steer-by-wire system must be FoS (fully operational for a
predefined time interval after the first fault
Figure 10 is a scheme of the Steer-By-Wire prototype without mechanical backup. The TTP/C
communication bus is the backbone of the demonstrator as it connects the three FTUs:
Steering Wheel Unit, Steer-By-Wire Control Unit and Steering Actuator Unit.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 44 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
Steering Actuator
Unit
µC µC
µC
µC
Steer-By-Wire
µC Control Unit
Steering-Wheel TTP/C Databus
Unit µC with 2 channels
µC
Figure 10: Steer-By-Wire Prototype, Electronic Components
Two replicated nodes form the fault-tolerant steering-wheel actuator unit. This unit obtains the
driver’s intention through measuring the steering wheel angle and sends this value on the bus
to the other FTUs. Additionally, the Steering Wheel nodes receive the measured torque value
of the steered wheels, from the Steering Actuator Unit. The driver is given a feedback torque
on the steering wheel based on the steering wheel angle and the steered wheel torque. The
feedback torque is generated by the steering wheel actuators.
The Steer-By-Wire Unit also consists of two replicated nodes. Both nodes receive the steering
wheel angle provided by the Steering Wheel Unit. Furthermore, the Steer-By-Wire Unit
performs the overall control- and comfort functionality. This function is intended to assist the
driver in critical situations, e.g., when the vehicle skids or during parking maneuvers. The
Steer-By-Wire Unit calculates a steering angle setpoint, which is sent to the Steering Actuator
Unit.
At the front of the prototype, three micro-controllers, three actors (electric-motors), torque
(current) and angle sensors form the Steering Actuator Unit. The unit is performing a replica-
agreed control-loop by driving the electric-motors to reach the desired angle of the road
wheels, received from the Steer-By-Wire Unit. The torque is communicated to the Steering
Wheel Unit to give the driver a feedback from the steered wheels.
6.3 The Time-Triggered Protocol for Class C applications
(TTP/C)
6.3.1 Hardware Setup
The prototype of the TTP/C hardware module which is used in the X-By-Wire project is
implemented as an "IP-Module" according to the Industry Pack Logic Interface Specification
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 45 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
from GreenSpring Computers. This facilitates its use together with any off-the-shelf computer
board as host.
To facilitate hardware debugging most components on the board are mounted on the side of
the PCB that is accessible during operation. This does not comply with the IP specification.
Therefore, when using this prototype module together with VME boards in a standard rack,
the slot next to the carrier board must be left empty.
The main functional unit of this prototype is a Motorola 68332 microcontroller. Additionally,
several peripheral devices are provided.
Flash
IP Logic Bus Controller
clock-interrupt CPU 68332
EPROM
(20M Hz)
(256k*16)
data 16
Dual Ported RAM
data 16
IP addr 19
ctrl
Inte rface ctrl ctrl
(4k*16)
7 13
Logic
Bus
addr 6 Guardian
Dual Se rial
Inte rface Bus Ch A
Controlle r Driv e r
Ch B
Host-Interface Communication Controller
Figure 11: Block Diagram of the TTP/C Prototype Controller
6.3.1.1 Motorola MC68332 Microcontroller
The Motorola MC68332 is a modular microcontroller unit (MCU) consisting of the following
components:
CPU32: The CPU32 executes the main protocol tasks of TTP/C. A background debug
mode (BDM) is provided that allows read and write access to registers and memory over a
dedicated BDM interface.
TPU: The time processing unit (TPU) is an autonomous microcontroller with sixteen
independent, programmable timer channels. It was used for the implementation of all
timing-related functions required for TTP/C.
Internal RAM: In the TTP implementation the internal static RAM (2 KBytes) is used as
microcode RAM for the TPU functions and therefore not available to the CPU32.
Serial Communication Interface: The serial communication interface (SCI) is a full-
duplex universal asynchronous receiver/transmitter (UART). The TTP/C software uses the
SCI for debug outputs.
System Integration Module: This module integrates the following glue logic functions on
the MC68332:
An external bus interface provides functional support for the access to peripheral devices.
Data bus width is 16 bit.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 46 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
A system configuration and protection block controls configuration parameters, preserves
reset status and provides bus and software watchdog monitors.
A system clock unit generates a programmable system clock of up to 20 MHz from a
32.768 kHz crystal (in the current implementation a 16 MHz version of the MC68332 is
used).
The internal modules of the MCU communicate via an Inter Module Bus with 24 address and
16 data lines.
6.3.1.2 Universal Serial Controller
The Universal Serial Controller (USC), a Zilog Z16C30 in the X-By-Wire prototype
implementation, has two independent full-duplex channels with data rates ranging from 0 to
10 Mbit/sec (currently, 1 Mbit/sec is used). Each receiver and transmitter is buffered with a 32
byte data FIFO, which is large enough to hold a complete TTP message. The USC supports
several coding techniques. In the current implementation FM0 is used, because this code
allows synchronization of the receiver without bit stuffing (each bit cell starts with a
transition, a logical 0 is coded with an additional transition in the middle of the bit cell). Data
transfer is controlled by the CPU via several USC registers, status pins and control pins.
6.3.1.3 Bus Transceivers
Each of the two USC-channels is connected to the TTP bus over one bus transceiver that
performs physical signal conditioning. Electromagnetic radiation behaviour associated with
the bus signals can be improved by wave-shaping.
6.3.1.4 Bus Guardian
The bus buardian ensures fail silent behaviour of the TTP/C controller by restricting the bus
access to specific periods of time und thus avoids a babbling idot failure of the controller.
6.3.1.5 Flash EPROM
The array blocking architecture of the flash EPROM allows blocks of predefined size to be
programmed separately. The protocol code located in the boot block can remain write
protected during maintenance operations for other blocks (e.g., MEDL update). A jumper
facilitates write protection for the complete flash EPROM. The flash EPROM can be
programmed on-board via the BDM interface.
6.3.1.6 Dual Ported RAM
The DPRAM used on the TTP IP board comprises the following logical memory areas:
Communication Network Interface (CNI): The CNI is the Communication Network
Interface of the TTP protocol. In order to achieve the required operational decoupling of
host and communication controller, both CPUs may access the CNI simultaneously. The
DPRAM is capable of resolving access conflicts to the same memory cell by delaying the
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 47 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
second access until the first is finished. The maximum delay is limited to 2 cycles of the IP
clock.
Local RAM of CPU32: Since the internal memory of the MC68332 is used by the TPU,
the CPU uses part of the DPRAM as local RAM. Host CPU access to this memory area can
be inhibited through a jumper.
6.3.2 MEDL
Since the prototype application does not require the mode change service of TTP, only one
application mode (bus mode 5) is supported in the prototype application MEDL.
This application mode consists of a single cluster cycle, which is further subdivided into 2
TDMA rounds. This division was required in order to enable the transmission of I-frames to
facilitate the re-integration of failed nodes. For demonstration purposes every FSU (except the
monitoring FSU) transmits an I-frame on both busses once per cluster cycle. This practice on
the one hand yields a very fast recovery of failed FSUs in almost all failure scenarios3, but on
the other hand this approach extends the duration of the cluster cycle.
The number of TDMA slots per TDMA round was chosen in order to accommodate each FSU
of the prototype cluster exactly once. Thus each FSU has its own unique sending slot in each
TDMA round which yields a TDMA round length of 8 TDMA slots.
Hereby the first two slots of each TDMA round are owned by the two FSUs of the steering
wheel FTU. These FSUs transmit I-frames in the first TDMA round of the cluster cycle and
N-frames containing application data in the second one. The following three slots are the
sending slots of the three FSUs of the steering FTU. In the first TDMA round of the cluster
cycle these FSUs transmit only N-frames, whereas in the second TDMA round I-frames are
transmitted. The sixth slot of each TDMA round is reserved for N-frames of the monitoring
node. This node transmits N-frames in both TDMA rounds. The last two slots are occupied by
frames sent by the FSUs of the steer-by-wire control FTU. These FSUs send an I-frame in the
first TDMA round and an N-frame in the second one.
In order to be prepared for future extensions, each N-Frame contains the maximum of 16
bytes of application data. FSUs which send smaller amounts of application data use the
remaining data capacity for monitoring purposes.
To facilitate the synchronisation of the host subsystem with the TTP/C controller the MEDL
for the prototype application instructs the TTP/C controller to raise a dedicated interrupt at the
beginning of the cluster cycle. The duration of a single cluster cycle is about 20ms.
3
In order to keep a cluster running a minimum of two active FSUs is required. At least one of these FSU must
send I-frames to allow other FSUs to re-integrate.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 48 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
6.4 Node Architecture
The node architecture is designed to be flexible and is based on the fail-silence assumption. A
fail-silent node delivers either correct service or no service at all. A silent node does not
interfere with the other system parts.
To reach the fail-silence property a node may consist of one fail-silent unit with fault detection
mechanisms in software. A node may be realised as a duplex system consisting of two
redundant nodes. Another architecture may be based on a triple-modular-redundancy (TMR)
approach.
In applications with strict high fault-tolerance requirements two fail-silent nodes can be
connected to form one fault-tolerant pair. Each single node is completely physically separated.
If a single fault occurs in one of the nodes, the faulty node will become silent and the fault-
free node will continue to deliver the correct service. The global time-base delivered by the
communication system simplifies such implementations. Using two fail-silent nodes to
tolerate one fault has a number of advantages:
Efficiency: there is no need for explicit design mechanisms to tolerate faults. Each node
has only to focus on the detection of faults. Once a fault is detected the node is shut down.
Simplicity: by using the fail-silence property as the underlying concept for fault tolerance, a
clean architecture with a minimum of cross coupling and special mechanisms like voters is
obtained. Furthermore, the concept of a node that is either correct or silent is easy to
communicate within the organisation and to sub-suppliers and partners.
Testability: the fail-silence property is a testable property since it is well defined. The
testing can be concentrated on verifying the fault containment performance, e.g., test that a
node does not violate the fail-silence property.
6.5 The Steering Wheel Unit
The steering wheel unit serves for two main purposes: firstly, it is responsible for sensing the
input of the driver, i.e., the actual value of the steering wheel angle, which is transmitted to
the other subsystems via the TTP bus. The steering wheel angles values are subject to an
agreement algorithm to guarantee replica determinism. Secondly, the unit performs a control
of the feedback actuator. The feedback torque on the steering wheel should emulate the
steering effort of conventional steering systems. The calculated value of the feedback torque is
based on a simulated self centring torque and the actual torque of the steered wheels,
measured by the Steering Unit. Additionally, the Steering Wheel Unit controls the simulated
vehicle velocity by sensing a cruise control lever.
6.5.1 Fault-Tolerant Feedback Actuator
The feedback actuator consists of two redundant motors, each of which performs half of the
feedback torque to the steering wheel. In case one of the motors fails, the second motor
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 49 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
performs the whole torque. A failure of one motor is detected via the TTP bus. The actuator is
controlled by a power electronics unit, the input of which is a current directly proportional to
the torque setpoint. Additionally, the actuator includes two resolvers needed by the power
electronics to control the actuator. This resolver is used to sense the steering wish of the
driver. The two motors and resolvers are controlled by one dedicated FSU (see below) each.
6.5.2 Fail-Silent Sensors
As mentioned before, the resolvers are used to sense the steering wheel angle. To gain fail
silence two sensor values are necessary to implement one fail-silent sensor. Therefore two
additional low-cost sensors are added. One resolver value is compared to the output of the
Kostal sensor, which is a sensor already introduced in mass production, for example in the
ESP (Electronic Stability Program) systems. The second FSU compares the resolver value to a
potentiometer, which is mounted additionally to the feedback actuator. In case, the two sensor
values differ by more than a certain tolerance interval, the FSU becomes silent. The second
FSU delivers the correct angle value.
6.6 The Steer-By-Wire Control Unit
This unit consists of two FSUs which are responsible for calculating the overall control loop
of the Steer-By-Wire application. Example of possible features included in Steer-By-Wire
applications are collisions avoidance, vehicle stability control, side wind compensation or
increased manoeuvrability during parking manoeuvres. The later example has been
implemented in the Steer-By-Wire Control Unit by introducing vehicle velocity dependent
ratio between steering wheel angle and steering angle. The steering setpoint for the Steering
Actuator Unit is calculated based on this angle ratio and the steering wheel angle. This
functionality demonstrates the advantage to a conventional steering systems where the angle
ratio between steering wheel and steered wheels is fixed.
6.6.1 Technical Data - FSU
The FSU is an IP360 Carrier-board from Microsys running a Motorola 68360 32-bit processor
with 33 MHz. The MC68360 hosts the operating system, the system services and the Steer-
By-Wire Control application itself. The OS gets its timing from the TTP/C global time base
and activates the tasks of the application and of the system services in a time-triggered way.
The FSU doesn’t need any further interfaces except the TTP/C controller for communication.
It is plugged into the first IP-Slot of the IP360 and contains the Controller Network Interface
(CNI) to write the message to be sent into the controller and to copy the received messages
into the application’s memory within the MC68360. The TTP/C controllers were provided by
TU Vienna.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 50 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
6.7 The Steering Actuator Unit
Figure 12 contains an overview of the steering actuator unit, which consists of 3 independent
actuator/sensor/processing channels. The FSU gets the agreed setpoint for the desired angle of
the road wheels from the TTP/C bus and calculates the new control output based on the
measured and agreed information of the angle sensor and torque sensors. The FSU generates
the control signal for the power electronics which control the motor itself. The measured
current information is also sent on the bus to be used, e.g., at the Steering Wheel Unit for
feedback calculations.
TTP/C Bus
1 2 3
Figure 12: General Layout of the Steering Unit
6.7.1 The Motors
As it was not the goal of this project to develop a steering actuator from scratch but to show
that it is possible to construct a fault-tolerant steering actuator out of off the shelf components,
the team responsible for this unit used Bosch ABS-motors/power electronics as actuating
components. In the present context to fulfil the reliability requirements at least three motors
are necessary, because an actuator consisting of two motors will still provide full operation. If
another motor fails, only reduced functionality (limp home) is available. Although one might
think that triple redundancy is wasteful in an automotive application, this triple redundancy
can have economic and constructive advantages. In a triplicated system each motor has to
provide 50% of the necessary torque in order to fulfil the described requirement. In a
duplicated system where at least one failure is to be tolerated fully operational, each motor has
to provide 100% of the necessary torque. In practice, as a rule of thumb, doubling the power
of a motor means triplicating its volume, weight and price. Thus the three motor solution
probably can even be more economic than the duplicated system.
6.7.1.1 Technical Data - Motor
The motor is a Bosch motor (ABS 5.3 L) for ABS-Applications. This motor has all the
advantages of a series product including availability and low cost. The maximum torque it can
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 51 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
supply at 12 V is about 200 Ncm which is well enough for the demonstration (a transmission
ratio of 160 is given by the mechanical construction). In this case the motor will need a
current of about 80 A. The motors are mounted within a special Gear Box, which is flanged
on the rest of the steering column of the laboratory prototype demonstrator.
6.7.1.2 Technical Data - Power Electonic
The power electronics originally has been developed to be part of an intelligent actuation
component of a truck clutch, thus is a series part as well. It has been chosen because it is able
to handle the high currents needed by the motor. To control it the FSU must send current,
enable/disable, and left/right signals to the power electronics.
6.7.2 The Torque Measurement
There are different reasons for adding a current sensor into the system. First of all the torque
provided by one motor is roughly proportional to its current. Thus the current measurement
allows a torque estimation, and the torque is available for tactile feedback. A second reason is
to guarantee the fail silent assumption of the motors.
An electric motor can be assumed fail silent if none of its failure modes results in a blocking
of the system or in a reversing of direction. Any failure mode which only implies that the
motor does not actively supply torque any more, but does not need (significant) torque to be
driven, is a fail silent failure mode. If the motor itself blocks, a non-fail-silent failure mode is
present. And if the gear to which the motor is coupled is blocking, when the motor does not
actively drive it, again a non-fail-silent failure mode is present. Reversing of direction can be
made improbable by design and off-line testing, and can be detected on line by a current
measurement. The design of the gear (and the motors) should be done in such a way that a
blocking of the system is avoided for instance if a motor is cut off from power. This is indeed
possible and has been done in the prototype. Finally most of the motor failures that result in a
blocking (for instance melting or loosening of parts by strong magnetic fields) can be
prevented if excessive current inputs can be avoided. Thus by adding a current sensor the
coverage of the fail silence assumption can be strongly improved.
6.7.2.1 Technical Data - Current Sensor
The current sensor is a combination of a standard fast sensor (LEM) and an active RC
component. The time resolution of the LEM sensor is so small that the output of the sensor
still has the PWM signal form. As for current and torque measurement the smoothed value is
relevant, an active, time-delaying RC-component with cut frequency 2kHz was added. The
time delay in this case is less than 200 µs, thus will not significantly decrease the
performance.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 52 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
6.7.3 The Angle Measurement
An absolute angle measurement was necessary, to guarantee absolute angle information at any
point in time, e.g. after start-up of the system or re-integration of the subsystem. The angle
sensors are triplicated and mounted close to the motors within the Gear Box.
6.7.3.1 Technical Data - Angle Sensor
The angle sensor is the fail silent LWS 3.1 sensor. The fail silence property is derived from
the fact, that internally two magnetic sensor elements are present. Each of them produces a
relative angle and both information together allow to determine the absolute angle within a
certain range. Moreover, each of the relative angles is sufficient to detect almost any of the
failures of the other relative angle, thus the sensor can be considered as fail silent with high
coverage. The LWS 3.1 sends the angle value as CAN message which implies that the FSU
needs a CAN interface.
6.7.4 The FSU
Three FSUs are connected to the TTP/C bus. Each FSU controls one motor via a current
signal (steering setpoint) and gets the current signal (torque measurement) from the motor.
Moreover each FSU is connected to an angle sensor.
If each FSU independently tries to move the controlled object into a certain position it cannot
be avoided, that, at least in some positions, one motor works against another one. This is due
to slight differences in the angle sensor readings, which always is possible when converting an
analogue value into a digital one. This typical replica determinism problem can only be
solved, if it is ensured, that all the three FSUs use the same angle value. Thus agreement of
the FSUs has to be done via the TTP/C bus and the fault tolerance layer of the system
software. It has to provide an agreed value even in the presence of faults. An ―inner control
loop‖ using the non-agreed position value must be avoided.
6.7.4.1 Technical Data - FSU
The FSU is again an IP360 Carrier-board like the Steer-By-Wire Control Unit with a TTP/C
Controller. As can be seen in the above picture, the FSU needs an interface to each of the
controlled components (sensors and power electronics). As the controlled components have
completely different interfaces an IP-module has been designed which is able to handle all the
different inputs and outputs by simply plugging in this module into the second IP-Slot of the
IP360. This covers A/D, D/A converters, PWM generator, CAN-Controller and multiple I/O-
ports.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 53 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
This is a CAN message, as the LWS3
To TTP/C Bus sensor has a CAN interface.
PS The power electronics needs an Enable
FSU
signal (two pins), an R/L-pin and a
Current signal.
AS
PS
The current sensor signal is measured
using a (fast) standard sensor and an
active (time delaying) RC component.
PS PE Cut frequency will be 2 kHz, time delay
is less than 200 µs.
PS
CS
PS: Power Supply
Motor PE: Power Electronics
AS: Angle Sensor
CS: Current Sensor
Figure 13: FSU and its Interfaces
6.8 Power Supply
The Power Supply subsystem is composed by a battery charger as alternator emulation,
batteries, wiring, power supply boards for the FTU modules, relays, fuses and switches.
Figure 14 represents the power supply components and their connection strategy.
Fuse1 BSW1
Relay1 To:
PS •SW1 (FSU1)
Board 1 •S1 (FSU3)
•SBW1 (FSU7)
BSW
Battery1
- +
12V
POWER Relay2 BSW2
Battery + 100Ah Fuse2 To:
Charger •SW2 (FSU2)
220V ~ PS
12V Board 2 •S2 (FSU4)
60A - •SBW2 (FSU8)
Battery2
- +
12V
100Ah Fuse3 BSW3
Relay3 To:
PS •S3 (FSU5)
Board 3 •Diag (FSU6)
- + Battery3
12V
100Ah
Figure 14: Power Supply layout
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 54 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
All the system is powered from the AC 220V-50 Hz network by means of the general switch
―POWER‖ in which a differential switch has been integrated for safety reason.
The battery charger (output 12V, 60A) avoids the batteries discharge when the prototype is
running, operating as a car alternator, and is used to charge the batteries when it is necessary,
for example after a long period during which the prototype has not been used.
Each battery is connected to the relative power supply board by means of a fuse in series to a
switch. The fuses protect the system by accidental overload current, while the switches
―BSW1‖, ―BSW2‖ e ―BSW3‖ serve to inject faults in operating condition and to disconnect
the electric/electronic systems from the power supply when the prototype is not running.
The three power supply boards model TRIVOLT GK 60-2 (+5V@6A, 12V@1A) from Vero
Electronics generates the necessary voltages to supply the electronic units.
Three batteries and three power supply boards are necessary for providing the defined fault
tolerant characteristic, the prototype must be fully operational after the first permanent fault
and operational with reduced performance after the second one. As a consequence the wiring
and the connection strategy have been studied to avoid any single failure point in the power
supply system.
In order to prevent current flows among batteries when the prototype is not running, three
relays driven by switch ―BSW‖ isolate each battery.
Battery charger and batteries are located inside the prototype platform, while fuses and
switches are easily accessible on lateral panels of the platform, where there are also lamps
which give information about the power supply status.
6.9 Monitoring and Fault Injection
In the prototype architecture is present a PC, linked with the two TTP/C buses, which is
responsible for the computer driven Fault Injection and the Monitoring System (FIMS)
described below.
This equipment is based on an Industrial PC -Pentium 133 MHz 800x600 TFT Colour Display
equipped with a National PC-DIO-24 board (24 bit parallel digital I/O) that drives two
external relay boxes (PC-ER-8 + PC-ER-16) for physical fault injection, and a TTP-Controller
mounted on a standard PCI-40 board for monitoring functions.
Features of such system may be divided into two main groups, respectively for Fault Injection
and Monitoring functions.
This equipment takes part of the laboratory Steer By Wire Prototype with the aim to introduce
in the system both computer driven and manual faults for Fault Tolerance capabilities
demonstration, and a Monitor to display information present on TTP buses.
FIMS basically interacts with TTP communication buses and power supply lines. The
connection to the TTP buses is advisable in order to use the equipment also for monitoring
purposes.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 55 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
Considering the fault injection, for each intervention point the fault implemented is the open
circuit, only low power signals are controlled by the equipment, while for power lines fault
simulation (i.e. battery disconnection) only the manual way is allowed.
PC driven fault injection is assisted by dedicated SW (SW implementation is based on
LabView environment). Moreover the PC gives the possibility of transient fault simulation. A
limitation on transient fault timing exists due to the performance of National PC-DIO24
board, the performance of F.I.M.S. SW, and relay electrical delay.
A dedicated box equipped with 2 relay boards and switches for manual fault injection
(SWITCH-BOX) is included in the harness of the Steer-By-Wire prototype. This box may be
optionally excluded in a easy way restoring direct cabling at the connector site; the same
happens if you want to exclude either the SW intervention or the manual intervention.
Computer driven F.I. will basically affect Nodes (FSUs), Sensors/Actuators and
Communication.
There are sixteen computer-driven intervention: three are dedicated for the Steering Angle
Sensors power supply, seven for FSUs power supply and six for the communication busses.
As regards the manual intervention points, all sixteen PC driven intervention points are
duplicated in manual way in the Switch-Box, and 3 further intervention points has been added
in order to disconnect each of the three battery of the power supply subsystem (the
corresponding switches are located on a panel of the prototype).
A Man Machine Interface (MMI) has been implemented to monitor the information (Figure
15) and to introduce faults (Figure 16) from PC
Figure 15: Monitoring MMI
Associated with each component a certain number of information may optionally be displayed
in a small dedicated window in the MMI. Information about the ―death‖ of a component is
graphically represented directly on the main window. Moreover in the main window inside
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 56 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
each component (node, sensor or actuator) is drawn a led that light up only if the fault is
generated by the user himself (local echo).
The monitoring has been implemented as a passive system and it is used only as a watcher of
the information available on TTP buses.
Figure 16: Fault Injection MMI
6.10 Conclusions
The partners have worked with great co-operation during the prototype development, and the
prototype itself proves the very good working climate that has accompanied the last two years
of the project in which the steer by wire demonstrator has been specified, implemented and
integrated with success.
Some minor prototype requirements have not been met, this is essentially due to time and cost
constraints and to some problems happened during the project life. Moreover it is necessary to
consider the real difficulty of such an application, from a technical and managerial point of
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 57 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
view. In fact a real steer by wire system has been implemented for the first time and none of
the partners initially had the necessary experience to build alone the whole prototype, while
the working co-ordination of a large number of co-workers, although very successful,
requested more effort than what was foreseen.
Nevertheless the main objectives of this work package have been fulfilled: The system
architecture defined in work package 3 has been proved, a steer by wire demonstrator has been
built, is operating and has the necessary fault tolerant capabilities.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 58 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
7 Preconditions for Mass Production
A number of activities remain to be perform prior to the deployment of an x-by-wire system.
These activities fall outside the scope of mutual co-operation in become ingrained with
competitive advantage.
The key issues are listed below.
Assessment of product liability risk and viability from a legal prospective
Market survey and assessment of customer acceptability
Financial analysis
Product Planning and/or current model integration
Component sourcing
Production level systems and software development
Design for manufacturing
Component packaging
Environmental design & test
Electro-Magnetic Compatibility (EMC) analysis and testing
Durability testing and mileage accumulation
Climatic testing
In-service procedure design
Production line upgrade
Homologation / Type Approval / Certification
Note: that additional activities may be undertaken by some vehicle manufactures.
7.1 Open Issues
7.1.1 Availability of Components
During the realisation of the steer-by-wire prototype we recognised that some components
which are needed for the realisation of the steer-by-wire prototype are not available with the
appropriate performance, accuracy or size, e.g. we have problems to find off-the-shelf
actuators and sensors which fulfil the requirements.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 59 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
As one example the feed-back actuator for the steering wheel could be mentioned. The
problem of the feed-back actuator is the modelling of the end point of the steering wheel,
therefore a strong electrical motor is required which is hard to integrate in a dashboard.
Also we still have problems to find sensors for detecting the steering wheel angle with a
sufficient accuracy.
These problems in common could be solved by the adaptation or development of new sensors
or actuators which are optimised for the use in a x-by-wire system.
7.1.2 Development Process
The realisation of a complex system like x-by-wire would influence the whole development
process of vehicle manufacture and their sub-system or component suppliers. The tool chain
for the development process has to support the specification, system design, proof of design,
design realisation, safety analysis, generation of production data, system integration,
diagnoses and system test. The realisation or adaptation of the complete tool chain to the
requirements of the development of x-by-wire systems is beyond the scope of the X-By-Wire
project, also there are some competition aspects.
During the project the emphasis was placed upon the development of design and integration
tools for time-triggered systems. These are the basic tools which are required to realise time-
triggered architecture which is in the X-By-Wire project the proposed architecture of the
realisation of future by-wire applications.
An important issue for further work is the development of a simulation tool which allows the
simulation of an application and the modelling of system parts which are currently not
available. Also the use of formal methods for the verification of safety critical application or
very safety critical parts of the system would be important.
7.2 Standardisation Planning Activities
There are many other parallel routes and alternatives that have been used by MISRA that can
be considered for X-By-Wire use. These range from using internet to the presentation of
technical papers and liaison with professional and trade organisations.
„The System― associated with all electronic and IT systems has many boundaries, levels and
interpretations. The X-By-Wire research project and results are very „systems orientated―
rather than being just hardware or software issues alone. This creates an „identity― problem
and handling the nebulous nature of a „systems― activity from a standards viewpoint seriously
compounds the problems of identifying the optimum standards technical committees to
approach.
The collective reputation for technical excellence of the Consortium is clearly already high
and assuming the results of the project do justice to this reputation then the dissemination of
the results of the project is unlikely to present an obstacle. This reputation should be used to
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 60 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
the full during the dissemination by taking all opportunities to refer to the supporting
organisation.
Standard take a variety of forms. A full international standard is at one end of the spectrum
with a very detailed, ratified document issued through one of the accredited international
standards organisations. Within automotive engineering national standards have long since
surpassed by international level standards. At the other end of the spectrum is the so-called
„de facto standard― which evolves though custom and practice and general consensus, is well
know and accepted, but does not have the support of an accredited organisation or an
identifiable document.
Before the optimum standardisation route can be selected we must first identify the objectives
and needs of the exercise. The following have been recognised:
World-wide coverage: Europe, USA, Japan
Diversity of approach - covering:
Immediate & longer-term
Overview & in-depth coverage
Full system & component level
Linkage between the methods when more than route is used
Broad publicity of the principles
while being economical with specifics and detail
Maintenance of control from within the partnership
The final point is of high importance to the member companies.
No single route to a standard, or single method of exploitation can fulfil the needs of the
project. Therefore, several parallel approaches must be adopted. Some of the techniques
identified relate to both the objective of standardisation and exploitation, so it recommended
that these two activities originally identified in the Project Plan should be merged.
The full benefits of this diversity are only obtained however, if a harmonised approach is
undertaken, including placing emphasis on the linkages between the chosen methods.
The methods with the shortest timescales and lowest cost should have the highest priority.
The project started with the objective of making draft proposals to standardisation activities.
During the execution of the project, it became clear that the project was not going to produce
specific details which could usefully be treated as a formal international standard. At the same
time, many de-facto standards have been very successfully established, with a speed which
could not have been achieved by formal routes. The results of this project are of a similar and
evolving nature, and are best served by forming an informal forum to further develop this
work.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 61 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
The project team will continue to work towards a de-facto standard through technical
conferences and technical forums. The commitment of individual partners is detailed in their
exploitation plans.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 62 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
8 Project Management
As an overall remark, it has to be stated that the co-operation on project management topics
was excellent. Project meeting were effective and to the point. The few minor points that
came up during project lifetime were always identified early, and dealt with immediately.
Solutions were quickly available, and in time decided upon in a spirit of co-operation.
During the first half year of the project, the necessary rules to run the project were set up. As
the most important step, project guidelines were established. The guidelines define the
responsibility of global and local management, and of work package and work task leaders.
They as well define a documentation structure which has to be followed by all X-By-Wire
partners. Conventions about naming of documents were set up. The name of a documents
reflects the company responsible for the document as well as the state of the document
(worked on, agreed upon by the work package team, final with respect to the project). To store
the documentation, the University of Vienna has installed on their ftp-server a directory for
the X-By-Wire consortium. All official information is stored on this server. To assure the
privacy which is necessary with respect to the sensibility of the information stored, protection
mechanisms like e.g. a X-By-Wire password were put in place. To further ensure protection,
the password was changed during lifetime of the project. Thus, only the X-By-Wire project
members have access to this directory.
After six month usage of the first version of the project guidelines, the experience with the
guidelines resulted in an upgrade of the guidelines into a version which has been valid during
the rest of the project.
The guidelines were complemented by a project directory, which was continuously updated
during the lifetime of the project. Additionally, a project glossary was created already at an
early project stage.
Setting up a consortium agreement took more time. A proposal of the project responsible
company Daimler-Benz for a consortium agreement was issued to all partners within the first
half year of the project. Because of the amount of modifications proposed by the partners, a
complete new second proposal was written. This second proposal was based on the standard
EUCAR contract. After some more discussion concerning distribution of project management
cost, the consortium agreement was finally signed in 1997.
The consortium remained as established when submitting the original project proposal till the
end of the project. However, the department within Ford which is responsible for the X-By-
Wire project was in 1997 transferred to Visteon, a company wholly owned by Ford. The
reason behind was to act more independently with respect to non-Ford-internal customers.
This became a minor problem because Ford submitted an official written statement that the
Visteon employees are internally treated like Ford employees, and that Ford will still take the
responsibility for the X-By-Wire project. This official statement was forwarded to the EC. The
cost statements are still signed by Ford and not by Visteon. Thus, it was not necessary to enter
the lengthy procedure of modifying the original contract.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 63 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
As far as the technical progress of the project is concerned, the milestones were met as
scheduled. The technical reports belonging to the milestones were submitted. To give the
possibility of feed-back during later stages of the project, the reports were kept open for minor
modifications. As far as the mandatory reports for the EC are concerned, the technical parts
were always available in time. However, work on the cost statement did not always proceed
sufficiently fast within all companies involved. As a result, the periodic progress report for
1996 as a whole was late. The report for 1997 was then submitted in time.
Great care was taken to have a state of the art quality assurance for the X-By-Wire project.
The choice was either to set up specific X-By-Wire QA rules, or to use the QA procedures
which are already in place within the X-By-Wire partners. After a first discussion, there was
general agreement that the X-By-wire project should not take the effort to establish totally
new QA procedures. Therefor, the already existing MISRA guidelines were accepted as a base
for quality management. However, for all work done locally, it was agreed that the internal
quality management guidelines of the partners should be used. Additionally, for the prototype
development, the general ideas which came out as a result of work task 3.3 (development
process), were - especially tailored for the prototype development - used to guarantee
sufficient quality of the demonstrator.
Nevertheless, it was felt that the results of the project – especially the documentation - should
undergo a more formal QA procedure. Therefor, a team consisting of two of the automotive
producers was assigned to cross check all final documentation. This is the last check in a
chain of single QA steps.
With a project duration of three years, it was clear from the start that the overall project plan
would have to be adapted. One reason to do so is changing technology during project lifetime.
Another even more simple reason is that it turned out that the way the work was split up
logically (in work tasks) or in assignment (to companies) could be optimised. However, only
minor adjustments have been necessary to the project plan. The adjustments included merging
of work tasks in one (because the topics were intertwined, like work tasks 3.4, hardware
components, and 3.5, packaging, power supply), or changing the companies responsibility
(because of better suitable engineering capacity available within one of the other partners, like
swapping the responsibility for work task 3.2, dependability, and work task 3.7, software,
between Marelli and Bosch). In general, the original project plan turned out to be adequate to
perform the necessary work.
A special point to be solved was the distribution of the prototype cost. As the prototype
definition and cost was not available at the time the project program was written, figures
could only be estimated, and cost distribution was made on assumptions which turned out not
to be correct. Therefor, the prototype cost distribution had to be adjusted. Fortunately, the
overall prototype cost was mostly covered by the money available for consumables and
equipment. However, neither the distribution between consumables and equipment, nor the
distribution among the companies was correctly reflected. When first discussing this issue
with the EC during the mid-term review meeting, the scientific officer stated that there is no
problem to swap money between planned consumables and equipment up to a reasonable
amount. Thus, only the problem of distribution between the X-By-Wire partners had to be
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 64 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
solved. A final solution which took into account all different interests was agreed upon end of
1997 and forwarded to the scientific officer.
During 1996, an ESPRIT project "Time Triggered Architecture" (TTA) was accepted by the
European Commission. Beside other companies, two of the X-By-Wire consortium members,
namely Technical University of Vienna and Daimler-Benz, are as well consortium members
of the TTA project. The project objectives turned out to be of high interest for the X-By-Wire
Consortium.
In the TTA project a time triggered architecture for distributed (safety related) applications in
the fields of aerospace, railway technology and vehicles was to be defined and implemented in
a VLSI communication chip prototype. The TTP Specification which has been a major input
to the TTA project was beforehand distributed to the X-By-Wire partners. All partners agreed
that it would make sense to commonly identify X-By-Wire requirements, and hand them over
to the TTA project as an input for the chip prototype specification. This would make sure that
the implementation within the TTA-project will also cover the requirements of X-By-Wire
applications. It was assumed that this would dramatically ease exploitation of the results of the
X-By-Wire project, especially in the areas of standardisation and early availability of products.
The consortium members therefor decided to propose the exchange of certain information and
results with the TTA consortium. More specifically, the requirement specification of X-By-
Wire was made available to TTA, to make the chip best suitable for highly dependable
automotive applications. In exchange, the TTA-consortium made a number of prototypes of
the TTA-chip available for the X-By-Wire project to be used for the X-By-Wire demonstrator.
The prototype chips are now used in the demonstrator as planned.
The dissemination of project results started much earlier than anticipated. Early very informal
and basic presentations outside the consortium yielded much more interest than expected.
Additionally, in early 1997, project management took part in a discussion, and did an ad-hoc-
presentation, at a meeting organised by SURGE transport (OMI/ESPRIT). Amazingly, ideas
on X-By-Wire systems were presented at this conference. However, the technical approaches
used were inferior with respect to the safety and dependability requirements which have to be
taken into account when designing such a system. The consortium concluded that on one hand
the timing to start with affordable automotive X-By-Wire systems was correct, and on the
other hand, that it was absolutely necessary to start with more public discussions during
conferences etc., to make sure that not only the technical aspects, but also the safety etc.
aspects of such systems are being thought of.
As a result, the strategy which project information may be presented, and how it can be
presented, had to be decided upon much earlier than planned in the work programme. As a
first important step, it was decided that it is generally open to the consortium members to
mention the project during conferences etc. To do this, the project overview in the project
programme (page 1-9) was allowed to be used without need to consult the consortium.
Presentation of project results were made possible with special agreement of all partners. The
consortium specifically encouraged the members to present the project in order to get early
and wide feedback from experts not involved in the X-By-Wire project.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 65 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
Since then, the X-By-Wire project has been presented frequently. The first occasion was the
ESREL conference 1997, were project management had been asked if it would be possible to
present the project at this conference. Follow-up presentations performed by X-By-Wire
partners included SAE (February 98), FTCS (June 98), VDI (September 98). In the meantime,
X-By-Wire has not only be presented during conferences, but also to other companies like
component suppliers (Motorola, Philips, Texas Instruments, ZF, Siemens, ITT ...) or car
manufacturers (VW, BMW...).
Discussion on additional dissemination ideas was already started in late 1996. The ideas were
collected by the global project management, and presented and discussed during a project
meeting end of 1997. As a result, a X-By-Wire www-site was set up. The synthesis report
which is part of the project deliverables will be made available to the public via the www-site.
The idea of an X-By-Wire user group was postponed. As to TTP, an open TTP interest group
was set up by the University of Vienna. X-By-Wire members are welcome to participate.
Therefor, the consortium did not actively pursue this topic.
Dissemination will also be done by showing the demonstrator to the public. The way how the
prototype can be used for further dissemination was agreed upon mid of 1998. The
demonstrator will be passed from consortium member to consortium member, based on a
waiting list. Dismantling is scheduled to take place at the end of 2000 at the latest.
All actions that will take place after the end of the project have to be financed by the
consortium members. However, it is agreed that the www-site will be accessible after the end
of the project.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 66 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
9 Conclusions
During the X-By-Wire project a framework for fault tolerant electronics architecture has been
developed, which suits the needs for safety related applications in vehicles. The consortium
emphasised on solutions that support electronic systems without mechanical or hydraulic
backup in order to establish the possibility to introduce new active safety functionality. These
active safety functions will increase overall vehicle safety by liberating the driver from routine
tasks and assisting the driver to find solutions in critical situations. The realisation of such
intelligent driver assistance systems requires direct electronic control of the steering, braking,
suspension and powertrain actuators. As a consequence there is a need for a standardised
dependable, and cost-effective electronic realisation for mass production.
With present implementation strategies active safety systems, or even just a subset thereof,
cannot be realised within the typical constraints of mass production: low costs, reliability,
system modularity, maintainability in the field, whilst meeting the requirements for safety
certification. It cannot be expected that cost-effective manufacturable x-by-wire solutions will
rely on expensive mechanical backup. Today’s fail-safe systems have in general a reduced
limp-home and a driver dependent functionality in case of one significant failure. A fault-
tolerant system, on the other hand, guarantees the whole functionality even after a major
failure has occurred.
The results of the project are based on a set of automotive industry requirements for safety
critical electronic onboard systems (x-by-wire systems) under the constraints of mass
production. These requirements have been summarised in an system requirement
specification.
Based on these requirements the general architecture for a scaleable fault tolerant electronic
system for vehicles has been defined. This architecture is the framework for highly reliable
and manufacturable cost-effective systems and components linked by a reliable network. It
suits the needs for adequate development and maintenance processes.
For all aspects of the architecture, existing approaches (aeronautic, railway, nuclear, ships)
were investigated concerning their suitability for vehicle requirements and manufacturability.
Especially, work which had already been done in other EC-Projects was taken into account in
order to realise a technology transfer from research status into production.
During the project a general fault tolerant architecture was defined and agreed upon. After
that, a more detailed definition of the different architectural aspects of a fault tolerant system
such as dependability, development process, communication system, hardware, software and
certification was performed.
A widely distributed European team has implemented a steer-by-wire prototype without
conventional backup which was regarded as the most demanding challenge. With this
prototype the feasibility of the fault tolerant architecture, including fault tolerant actuator
coupling, has been demonstrated. The project showed the scalability and scopability of the
architecture. It is obvious that an architecture which fulfils these requirements is able to meet
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 67 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
most of the requirements for other by-wire applications. The viability of tools to design and
develop a time-triggered architecture has been shown as well.
Software techniques for the detection and management of software and hardware errors in a
fault-tolerant distributed safety related system have been established. Additionally the
recommendations for software development in the MISRA Guidelines are appropriate for the
implementation of production level software for X-By-Wire commercial systems.
It has to be stated that the state of current component technology was behind the anticipated
level, hence more basic work was required than anticipated. The basic technology is complete.
However, the pre-conditions for mass production have not been met and some of the tools
need to be brought up to commercial strength.
The main project results have already been disseminated and discussed in international
conferences in order to get the necessary input that the recommended architectural solutions
are widely accepted and suitable to become a de-facto standard. Recommendations for the
design process and rules for certification and maintenance of x-by-wire systems have been
proposed.
The success of the project emerges from the agreement on the overall approach among all
partners.
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 68 of 69
Safety Related Fault Tolerant Systems In Vehicles
Final Report
10 History
Version Author Date Remark
0.0.1 Spohr Nov 2, 98 Initial release (skeleton)
0.0.2 Spohr Nov 3,98 Started to add WP6
0.0.3 Thurner, Spohr Nov 5,98 Integrated Objectives
0.0.4 Spohr Nov 6,98 Integrated 1st version WP5
0.0.5 Spohr Nov 11,98 Integrated WP2 (1st and 2nd version)
0.0.6 Spohr Nov 13,98 Integrated WP1 (1st version), WP3, WP4 (1st version)
0.0.7 Galla Nov 13,98 Integrated WT5.1
0.0.8 Schedl Nov 15,98 Integrated Conclusion and Executive Summary
1.0.0 Schedl Nov 20,98 Final Version to be sent to the EC
2.0.0 Galla Nov 26,98 Unified layout and corrected typos
Document: XByWire-DB-6/6-24 X-By-Wire Consortium V 2.0.0 Page 69 of 69