Electronic Architecture and System Engineering Fo

European Commission
Contract number: 2002 - 507690
Electronic Architecture and System Engineering for

Integrated Safety Systems
Report type Deliverable D0.1.2

Report name State of the art
Report status: Public
Version number: Version 1.0
Date of preparation: 5.8.2004
2004 The EASIS Consortium

Authors
Editor
Dr David WARD MIRA Ltd (david.ward@mira.co.uk)
Authors
Mr Malte JACOBS Adam Opel AG (Malte.Jacobs@de.opel.com)
Dr Antoni FERR Lear Corporation (AFerre@lear.com)
Dr-Ing Uwe HONEKAMP Vector Informatik GmbH (uwe.honekamp@vector-informatik.de)
Mr Christian SCHEIDLER DaimlerChrysler AG (christian.scheidler@daimlerchrysler.com)
Mr Xi CHEN DaimlerChrysler AG (xi.chen@daimlerchrysler.com)
Mr Alexander BLECKEN DaimlerChrysler AG (alexander.blecken@daimlerchrysler.com)
Mr Eric FITTERER PSA (eric.fitterer@mpsa.com)
Dr Bernhard JOSKO Kuratorium OFFIS eV (Bernhard.Josko@offis.de)
The Consortium:
DaimlerChrysler (D) Bosch (D) Continental Teves (D)
C.R.F (I) DAF Trucks (NL) DECOMSYS (A)
dSPACE (D) ETAS (D) Philips (D)
LEAR (E) MIRA (UK) Motorola (D)
OFFIS (D) Opel (D) PSA (F)
REGIENOV (F) Universitt Duisburg Essen (D) Valeo (F)
Vector (D) Volvo (S) ZF(D)
Revision chart and history log
Version Date Reason

0.1 10/3/2004 First draft for review at EASIS plenary meeting in Paris, 24 March 2004
0.2 15/4/2004 Second draft for review by EASIS partners
0.3 15/6/2004 Third draft for review by EASIS partners prior to open workshop
0.4 7/7/2004 Fourth draft for review by State of the Art partners
1.0 5/8/2004 Public release version of deliverable
Table of contents
Authors ................................................................................................. i
Revision chart and history log .............................................................. i
Table of contents.................................................................................. i
Executive summary ............................................................................. 1
1 Objectives and deliverables of WT 0.1.2...................................... 3
1.1 WT 0.1.2 objectives ................................................................. 3
1.2 Details of WT 0.1.2 deliverables .............................................. 3
2 Deliverable contents..................................................................... 4
2.1 Summary of findings ................................................................ 4
2.1.1 State of the art of legislation........................................... 4
2.1.2 State of the art of capability and maturity ....................... 6
2.1.3 State of the art of safety ................................................. 6
2.1.4 State of the art of engineering ........................................ 6
2.1.5 State of the art of hardware and software components.. 6
2.1.6 State of the art of tools ................................................... 6
2.2 Summary of items.................................................................... 6
2.2.1 ECE Regulation 10......................................................... 6
2.2.2 ECE Regulation 13......................................................... 6
2.2.3 ECE Regulation 48......................................................... 6
2.2.4 ECE Regulation 79......................................................... 6
2.2.5 ECE Regulation 97......................................................... 6
2.2.6 ECE Regulation 100....................................................... 6
2.2.7 European statement of principles on HMI ...................... 6
2.2.8 RESPONSE projects ...................................................... 6
2.2.9 Capability Maturity Model Integration ............................. 6
2.2.10 ISO/IEC TR 15504 .............................................. 6
2.2.11 Automotive SPICE .............................................. 6
2.2.12 SPICE for Space................................................. 6
2.2.13 IEC 61508........................................................... 6
2.2.14 MISRA Guidelines .............................................. 6
2.2.15 EN 50126, EN 50128, EN 50129 ........................ 6
2.2.16 DO-178B ............................................................. 6
2.2.17 ARP 4754/4761 .................................................. 6
2.2.18 MIL-STD-882D.................................................... 6
2.2.19 MATISSE project ................................................ 6
2.2.20 SETTA project .................................................... 6
EASIS Deliverable D0.1.2
2.2.21 ESACS project .................................................... 6

2.2.22 ISAAC project ..................................................... 6
2.2.23 ASCET-SD.......................................................... 6
2.2.24 AutoFOCUS ........................................................ 6
2.2.25 DECOMSYS::SIMCOM....................................... 6
2.2.26 MATLAB/Simulink/Stateflow ............................... 6
2.2.27 Rhapsody in C++ / C .......................................... 6
2.2.28 SCADE ............................................................... 6
2.2.29 Statemate MAGNUM/MicroC.............................. 6
2.2.30 TargetLink........................................................... 6
2.2.31 Telelogic ObjectGeode ....................................... 6
2.2.32 Real-Time Workshop Embedded Coder 3.2.1 .... 6
2.2.33 SCADE Drive 4.3 for Automotive ........................ 6
2.2.34 CANoe ................................................................ 6
2.2.35 DECOMSYS::DESIGNER................................... 6
2.2.36 DaVinci ............................................................... 6
2.2.37 TTP-Plan/TTP-Build............................................ 6
2.2.38 VNA/LNA ............................................................ 6
2.2.39 RT-Builder........................................................... 6
2.2.40 CalDesk .............................................................. 6
2.2.41 CANape .............................................................. 6
2.2.42 INCA ................................................................... 6
2.2.43 Marc I.................................................................. 6
2.2.44 TTP-Calibrate ..................................................... 6
2.2.45 dSPACE Simulator.............................................. 6
2.2.46 LabCar ................................................................ 6
2.2.47 CANdela Studio .................................................. 6
2.2.48 Diagnostics Toolset (DTS).................................. 6
2.2.49 CANalyzer........................................................... 6
2.2.50 FaultTree+ .......................................................... 6
2.2.51 IQ-FMEA ............................................................. 6
2.2.52 MISRA Checker .................................................. 6
2.2.53 ORA .................................................................... 6
2.2.54 Safety Checker Blockset..................................... 6
2.2.55 PC-lint ................................................................. 6
2.2.56 SARAA................................................................ 6
2.2.57 StackAnalyzer..................................................... 6
2.2.58 SQMlint ............................................................... 6
5.8.2004 Version 1.0 iV

2.2.59 Statemate ModelChecker and ModelCertifier ..... 6

2.2.60 Capital Analysis .................................................. 6
2.2.61 TTP-Verify........................................................... 6
2.2.62 QA C and QA C MISRA ...................................... 6
2.2.63 Polyspace ........................................................... 6
2.2.64 eASEE ................................................................ 6
2.2.65 Tasking Development Tools ............................... 6
2.2.66 Wind River Diab C/C++ Compiler ....................... 6
2.2.67 Green Hills MULTI IDE ....................................... 6
2.2.68 Proprietary in-house solutions ............................ 6
3 Conclusions.................................................................................. 6
3.1 Legislation ............................................................................... 6
3.2 Capability and maturity ............................................................ 6
3.3 Safety....................................................................................... 6
3.4 Engineering ............................................................................. 6
3.5 Hardware and software components ....................................... 6
3.6 Automotive Tools ..................................................................... 6
4 Appendix ...................................................................................... 6
4.1 References .............................................................................. 6
5.8.2004 Version 1.0 iV

Executive summary
The objective of this work task was to identify the state-of-the-art in respect to integrated safety
systems, to provide a baseline for developing the EASIS process. The state-of-the-art
examination covered six topics, namely:
Legislation
Capability and maturity
Safety
Engineering
Hardware and software components
Tools
For each of these topics, a list of subjects to examine was generated and the available items were
studied to determine their contribution to the state-of-the-art.
For legislation, the present state-of-the-art is concerned with the Type Approval process that is
aimed at mechanically-based systems. Some of the legislation is being modified to address
electronic systems: the braking legislation now contains an approval process for software-based
systems that is likely to be extended to other domains, and the steering legislation is being
modified to permit the approval of advanced systems. A number of activities such as the
RESPONSE projects have identified the need for legislation to be further updated to permit the
approval of Integrated Safety Systems. In particular, there is no procedure at present that is
suitable for approving the testing of such systems at the prototype stage. Legislation also needs
updating to address the liability and responsibility issues associated with fully-automatic systems in
which the driver is unable to over-ride the reaction of the system.
For capability and maturity, the present state-of-the-art is concerned with measuring attributes of
the development process that are not specifically concerned with safety, although safety
engineering activities are often part of the activities that can be measured using the capability
maturity assessment techniques. Safety attributes can be explicitly included, as has been done in
the space sector. However, the capability maturity assessment techniques do not yet include
product assessment, which is also needed for Integrated Safety Systems.
For safety, the concepts and principles of safety-related systems engineering are well known,
particularly in the aerospace industry. For automotive systems, the most relevant state-of-the-art is
found in the automotive MISRA Guidelines and in the generic standard IEC 61508. Several
research projects have looked at new techniques that can support the development of dependable
automotive systems; in particular, how techniques used in the aerospace industry can be
transferred into the automotive industry. A German initiative is developing an automotive version
of IEC 61508, recognizing that there are several issues with applying the standard in its present
form directly to automotive systems, including the methods to be used for hazard and risk analysis,
the mapping of the safety lifecycle to automotive product development lifecycles (see also the
engineering topic), and the identification and selection of appropriate lifecycle techniques and
measures. This standard is expected to become an ISO standard in due course.
For engineering, every company (both OEM and supplier) has their own engineering process and
it is difficult to generalize a state-of-the-art. However, generic lifecycles for both vehicles and their
systems have been identified. A gap analysis has been performed on these processes, which has
shown that there are significant needs for the processes to be improved and adapted to meet the
requirements of Integrated Safety Systems in order to achieve future road safety targets. The
most significant gaps were found in engineering method, requirements engineering, safety
requirements engineering, verification and validation, and architectural specification. This gap
analysis is summarized in the table below:
5.8.2004 Version 1.0 1

Area of gap Size of gap Impact on safety

(effort, difficulty)
System and software engineering method
Requirements engineering and management
Safety requirements specification
Traceability
Verification and validation preventative, upstream
Architectural specification
Exchange, integrate data across tools
Transform requirements to design
Transform design to code
Calibrate less and in less time
Scale
Less More
For hardware and software components, there are many different architectures in use ranging
from low-end vehicles with few electronic modules through to luxury vehicles with many ECUs and
several networks. There is a high diversity of approaches in all areas, for example in architecture
and ECU protection strategies, and the approaches are often specific to the manufacturer and the
application. Some standardization is evident: OSEK is becoming the standard for operating-
system software, and standards are beginning to emerge for different safety aspects, notably in the
powertrain and chassis domains. However, the transition from current concepts (low-end and
luxury) to a new architecture concept (integrated safety) is not straightforward.
For tools, many tools to support all stages of the development process are available and are in
widespread use in the automotive industry. These range from full commercial tools right through to
proprietary in house tools developed by a manufacturer for a specific application. However, few
of the commercial tools have a specific qualification for use in safety-related systems (e.g.
certification against IEC 61508). There is greater availability of qualified tools in the aerospace
industry, and some of these are beginning to be adapted for automotive use. There are also some
automotive-specific tools for safety emerging, such as MISRA C code checkers.
5.8.2004 Version 1.0 2

1 Objectives and deliverables of WT 0.1.2
1.1 WT 0.1.2 objectives
The objective of this work task is to produce the state-of-the-art section of Deliverable D0.1.
Deliverable D0.1 will consist of the state-of-the-art information and the glossary produced by Work
Task 0.1.1.
The main focus of the recommendations in this Work Task will be to provide input for subsequent
tasks in WP0.2, especially:
Common objectives and requirements
The EASIS process
1.2 Details of WT 0.1.2 deliverables
According to the proposal for the work task structure [1] the deliverables of WT 0.1.2 consist of the
following parts:
Summary of findings: a summary of the state of the art in each topic
studied
Summary of items: a summary of the source documents and
projects examined
5.8.2004 Version 1.0 3

2 Deliverable contents
2.1 Summary of findings
This work task was divided into the examination of the state-of-the art in six topics, namely:
Legislation
Safety
Engineering
Hardware and software components
Tools
For each of these topics, a list of subjects to examine was generated and the available items were
studied to determine their contribution to the state-of-the-art. These findings are summarized in
this section. The next section contains a summary of the items themselves (e.g. standards and
projects).
The emphasis on the analysis was to examine items related to automotive systems and safety.
Where material from other sectors that can be useful in improving automotive best practice has
been identified this is included, but with a lesser emphasis.
2.1.1 State of the art of legislation
The state-of-the-art in this topic was investigated using the domains suggested in the EAST-EEA
Glossary [2], which lists five traditional domains for automotive electronics:
Chassis (ABS, suspension, etc.)
Powertrain (engine, gearbox, etc.)
Body functions (lighting, seats, windows, door locks, )
Telematics (information exchange between the vehicle and the
outside world)
Human-machine interface (HMI) information exchange between
vehicle systems and vehicle occupants.
Relevant legislative requirements for each of these domains that are concerned with the safety of
electronic systems will be identified.
There are two categories of legislation affecting European vehicles:
European Directives. Some Directives implement ECE Regulations
(see below), whilst other Directives are more general. Directive
70/156/EEC as amended by Directive 92/53/EEC sets the framework
for automotive Type Approval and specifies the items that must be
subject to approval according to specific technical directives. This
system provides for the approval of whole vehicles, vehicle systems,
and separate components.
United Nations Economic Commission for Europe (ECE)
Regulations, which address specific technical aspects of vehicles.
These are applied to vehicle systems and separate components.
5.8.2004 Version 1.0 4

Where certain technical areas of the vehicle are not covered by specific legislation, the European
Directives 2001/95/EC on Product Safety and 85/374/EEC on Product Liability may apply. These
Directives require that manufacturers of products comply with best practice and state-of-the-art of
scientific knowledge at the point of sale of a product. These Directives are particularly relevant for
programmable electronic safety-related systems, as with the exception of Regulation 13 noted
below there is at the present time no specific vehicle legislation relating to such systems. At the
time of preparing this report, there is a proposal to the UN ECE to extend the concepts of
Regulation 13 Annex 18 to all complex electronic systems.
In the following domain descriptions, the ECE Regulations are quoted. Cross-references to the
appropriate European Directives are given in the individual item summaries (2.2.1 to 2.2.6).
2.1.1.1 Chassis
The following ECE Regulations affect electronic systems in the chassis domain:
ECE Regulation 10 (electromagnetic compatibility) [3] requires a level of electromagnetic immunity
performance from systems that can affect the drivers direct control of the vehicle.
ECE Regulation 13 (braking) [4] contains Annex 18 Complex electronic systems. Complex in
this context refers to systems where there is a hierarchy of control, such that lower level functions
can be over-ridden by higher level functions. Annex 18 includes a requirement for the
manufacturer to demonstrate their safety concept, which means the design decision made for the
system to fail safe or be fault tolerant and an overview of the means by which this is achieved.
ECE Regulation 79 (steering) [6]. At the present time this Regulation requires that the primary
steering systems does not rely on steering commands being transmitted by purely electrical means
(or other non-mechanical means). A new version of this Regulation is under development in which
the need for a mechanical link is removed, thus providing scope for the approval of a broad range
of steering systems from traditional mechanical through to steer-by-wire. In addition there will be a
new Annex 6 of the Regulation on Complex electronic systems similar to Regulation 13.
2.1.1.2 Powertrain
The following ECE Regulations affect electronic systems in the powertrain domain:
ECE Regulation 97 (alarm systems) [7] contains a requirement that an alarm system shall not
affect vehicle operation or its safe performance. This may be interpreted as applying to
immobilizers that operate on the powertrain.
ECE Regulation 100 (battery electric vehicles) [8] contains functional safety requirements for
battery electric vehicles, although these are more concerned with the types of safety functions that
are required (e.g. warnings and interlocks) rather than how they are implemented.
2.1.1.3 Body functions
The following ECE Regulations affect electronic systems in the chassis domain:
ECE Regulation 48 (lighting and light signalling) [5] contains requirements on the operation of
lighting, tell-tale (ie. warning) devices, interconnection of lighting and automatic operation of
exterior lights.
5.8.2004 Version 1.0 5

ECE Regulation 97 (alarm systems) [7] contains a requirement that an alarm system shall not
affect vehicle operation or its safe performance.
2.1.1.4 Telematics
The following ECE Regulations affect electronic systems in the telematics domain:
The updates to vehicle EMC legislation will require that vehicle systems demonstrate immunity to
the wanted signals from radio transmitting equipment installed in the vehicle.
2.1.1.5 Human-machine interface
No specific legislation has yet been identified in this domain, but there is a European statement of
principles on HMI [9]. This is principally concerned with aspects of the presentation of information
to vehicle occupants, so that the driver is not distracted; but also includes requirements on the
system design such that the driver maintains safe control of the vehicle at all times.
2.1.1.6 Future legislation
The RESPONSE projects (see [10]) have been included under legislation as, while they are
European collaborative research projects, they have been identifying the need for legislation to
adapt to the development and deployment of advanced driver assistance systems (ADAS).
The projects have investigated the requirements for future legislation for ADAS. In particular
RESPONSE 1 identified the need for a Code of Practice to address issues such as testing of
prototype vehicles with ADAS, and the need for issues of liability with automated systems to be
resolved. RESPONSE 2 identified the need for processes for risk analysis and risk-benefit
analysis for ADAS. RESPONSE 3, part of the PReVENT programme, will:
Develop a risk assessment procedure for next-generation sensors
within ADAS
Provide input on specific ADAS issues to the automotive version of
IEC 61508 being developed by FAKRA
Develop a code of practice for development and testing of ADAS.
Future legislation will need to consider:
Whether any specific legislative requirements are required for
prototype testing of ADAS;
The Type Approval (or other) regime for the approval of ADAS;
Whether any specific driver training and licensing is required to
operate ADAS;
Liability issues if an ADAS system that has full authority over a
vehicle function fails and an accident occurs, who is responsible?
Furthermore, research in the UK [11] from a roadside equipment perspective, that in the UK is also
subject to a Type Approval regime, has shown that an updated approach to operate in parallel to
Type Approval is required for advanced traffic control systems, including those that link to vehicle
functions. The project proposed such an approach that is now being applied to some infrastructure
projects in the UK.
5.8.2004 Version 1.0 6

2.1.2 State of the art of capability and maturity
The following subjects were investigated:

Capability levels use and definition, relationship (if any) to safety
Process reference models
Process attributes in particular, are any safety attributes included?
Key processes in particular, are any safety processes included?
The main sources for capability and maturity are CMMI [13] and ISO/IEC TR 15504 [14] (also
known as ISO 15504 or SPICE). In addition, developments to create an automotive-specific
version of SPICE (Automotive SPICE) are noted [15], and that a version for space applications
(SPICE for Space) [16] has been produced.
2.1.2.1 Capability levels
All capability models are based on graded levels of maturity. In CMMI, there are 5 or 6 levels of
maturity depending on whether a staged or continuous process reference model is used. In ISO
15504 and its derivatives, 6 levels of maturity are used. These levels are summarized in the
following table:
Capability level CMMI Staged CMMI Continuous ISO 15504

0 Incomplete Incomplete
1 Initial Performed Performed
2 Managed Managed Managed
3 Defined Defined Established
Quantitatively Quantitatively
4 Predictable
measured measured
5 Optimizing Optimizing Optimizing
The use of discrete levels invariably invites a comparison with the use of safety integrity levels in
IEC 61508 and the MISRA Guidelines. Various researchers have tried to develop more formal
mappings between these levels for example [19]. In general it can be argued that a process that
is capable of developing a system or software to a certain SIL is likely to have reached a certain
capability level. However the reverse is unlikely to hold; ie. it does not follow that a process that
has attained a certain capability level will be guaranteed to be suitable for developing a system to a
certain SIL. Furthermore, meeting a certain capability level does not necessarily include a
requirement for safety engineering processes to be incorporated. See Figure 1.
May imply
SIL 2 CMMI 3
Safety Does not imply Process

capability capability
SIL and CMMI levels are examples only
Figure 1: Relationship between SIL and CMMI level

5.8.2004 Version 1.0 7
However it can be noted that the MISRA Guidelines [22] require that any software development is
undertaken within the context of a Quality Management System that complies with the
requirements of ISO 9001 as assessed by ISO 9000-3 (now ISO 90003). It has been
demonstrated by practitioners in the subject that ISO 9000-3 accreditation is equivalent to a
process attaining CMMI Level 3 or ISO TR/15504 Level 3. Therefore a Level 3 process capability
can be seen as a quality baseline for a process for developing safety-related software.
2.1.2.2 Process reference models
All capability and maturity models use a process reference model of some kind. The process
reference models include process steps that can incorporate safety engineering activities, but in
the basic models as defined by CMMI and ISO 15504 they are not explicitly included. It is
therefore possible in general to map aspects of the process reference models to specific activities
required in the safety-related standards e.g. IEC 61508. However it is again necessary to observe
that while a mature process capable of developing safety-related systems will therefore include
many of the elements of a well-defined process reference model, the reverse does not necessarily
hold.
In CMMI, process steps are broadly classified as:
Process management
Project management
Engineering
Support.
In ISO 15504 and its derivatives, process steps are generally classified as:
CUS (customer-supplier process)
ENG (engineering process)
MAN (management process)
SUP (support process)
ORG (organizational process).
In the proposed Automotive SPICE, CUS processes have been replaced with ACQ (acquisition
process). No specific safety requirements have been added although it is understood to be a
future work item.
In SPICE for Space, process steps have been added to the SUP processes for safety and
dependability (SUP 9) and independent verification and validation (SUP 10). There is a target
profile by software criticality class (A: catastrophic through to E: negligible) for the required
capability level. For Class A (catastrophic) both SUP 9 and SUP 10 must be at capability level 4.
For Class B (critical) both SUP 9 and SUP 10 must be at capability level 3. There is no
requirement for the lower levels.
2.1.2.3 Process attributes
No specific process attributes relative to safety have been identified so far.
2.1.2.4 Key processes
No specific key processes relative to safety have been identified so far.
2.1.3 State of the art of safety

5.8.2004 Version 1.0 8
The following subjects were investigated:

Safety lifecycles
Hazard and risk identification and classification
Techniques for hazard analysis and risk analysis
Design requirements for safety-related hardware (requirements for
safety and for design process)
Design requirements for safety-related software (requirements for
safety and for design process)
Safety proof
Safety assessment.
The main sources examined for safety were IEC 61508 [20] and the MISRA Guidelines [22].
Standards and guidelines from other sectors have also been noted where they may provide
additional best practice that is not covered by these documents. In addition, a number of research
projects have addressed safety issues. Significant findings from these projects that may influence
the state of the art have been noted.
It should also be noted that there are two initiatives to develop automotive interpretations of IEC
61508: in Germany, the DIN FAKRA committee AA13 and in France the BNA 0315B committee.
These will ultimately be converged and submitted to ISO/TC22/SC3 for publication as an ISO
standard.
2.1.3.1 Safety lifecycles
Traditional development lifecycles for both products and embedded software follow a V model or
waterfall model. There are two approaches to covering safety aspects in a system lifecycle:
Require a separate lifecycle for safety-related function development
Embed the safety activities in the product development lifecycle.
In IEC 61508, the first approach to a safety lifecycle is taken. This standard is based on the
concept of equipment under control and safety functions are added in two contexts:
1. Where a safety-related system is added on to equipment under control to reduce the risk of a
hazardous event by implementing safety functions;
2. Where such safety functions are part of the equipments control system rather than a separate
protection system.
The standard adopts an overall safety lifecycle (see Figure 2 of Part 1) as its technical framework.
This lifecycle is intended as the basis for claiming conformance with the standard. A different
lifecycle can be used, but the objectives and requirements of each clause of the standard must be
met.
The overall lifecycle is concerned with the attainment of risk reduction (q.v.) through three distinct
means:
Electrical, electronic and programmable electronic (E/E/PES) safety-
related systems
Other technology safety-related systems
External risk reduction facilities.
The standard is only concerned with the first means (E/E/PES). Separate safety lifecycles are
given for the E/E/PES themselves (Part 2) and for software (Part 3).
5.8.2004 Version 1.0 9

The IEC 61508 lifecycle does not easily align with the traditional automotive engineering
approaches as described in Section 2.1.4.1. In the automotive approach, there are a number of
iterations for both vehicle and system design; in particular software development may follow
multiple V cycles. The final integration and validation is performed before volume production
commences. In the IEC 61508 model, it is assumed that system realization is a single step. The
final integration and validation may well be performed as part of the commissioning of the system
at its physical installation.
In the MISRA Guidelines, the second approach to a safety lifecycle is taken. The Guidelines
require an appropriate lifecycle to be defined for both system and software. A per-system lifecycle
should be defined that is compatible with the project definition and the overall vehicle plan.
The overall vehicle development lifecycle should have phases identified for safety aspects, and a
safety plan is required.
A generic lifecycle is used as an example that is broadly similar to the one in IEC 61508. Note that
this lifecycle includes both hardware and software.
MIL-STD-882D [29] does not explicitly define a safety life cycle. However, it lists a number of
system safety activities that shall be performed throughout the system life cycle. These activities
are:
Documentation of the system safety approach
Identification of hazards
Assessment of mishap risk
Identification of mishap risk mitigation measures
Reduction of mishap risk to an acceptable level
Verification of mishap risk reduction
Review of hazards and acceptance of residual mishap risk by the
appropriate authority
Tracking of hazards, their closures, and residual mishap risk.
In the MATISSE project [30], a process is proposed based on the use of a formal mathematical
method (B). A B development lifecycle is proposed in which certain stages of the traditional V
model are omitted, being replaced by formal proof of the specification and of the design. The
omitted tasks (unit/integration tests and validation tests) would still have to be done on third-party
libraries and on software developed without using the formal method. Global tests still have to be
carried out.
In the SETTA project [31], shortcomings with applying the traditional V model to the development
of time-triggered systems (such as may be used to implement X-by-wire systems) were identified.
The SETTA project used the concept of the 3V model, where separate V models are applied to
development of the functionality, to rapid prototyping, and to development on the final target
hardware. SETTA proposed a process model in which tool support was used to overcome the
issues.
2.1.3.2 Hazard identification and classification
This subject covers the means by which hazards and/or risks are classified into categories. The
actual process of identifying and classifying specific hazards and/or risks is covered in the next
section.
The majority of standards and guidelines in the safety-related systems domains use risk reduction
as the means for ensuring that a system is sufficiently safe. Hazards are classified according to
the level of risk reduction required to reduce the risk associated with a hazard to an acceptable
level. The required risk reduction is allocated to the various parts of the system.
5.8.2004 Version 1.0 10
IEC 61508, as the generic standard for safety-related systems, is the benchmark for hazard and
risk reduction techniques. It uses the concept of the Safety Integrity Level (SIL) as a measure of
the necessary safety requirements for a particular system or function to achieve its allocated risk
reduction.
IEC 61508 defines safety integrity as the probability of a safety-related system satisfactorily
performing all of the required safety functions under all the stated conditions within a stated period
of time. A SIL is a discrete level for specifying the safety integrity requirements of the safety
functions allocated to the E/E/PES safety-related systems. The necessary risk reduction is
apportioned between the various types of risk-reducing facilities (E/E/PES, other technology,
external) and the SIL is a measure of the safety requirements necessary for a particular system or
function to achieve its allocated risk reduction.
There are four SILs, with SIL 1 representing the lowest level of safety integrity and SIL 4 the
highest.
In the MISRA Guidelines, hazards are classified using controllability which is a measure of the
ability of the driver or other vehicle occupant to control the safety of the situation following a failure.
It recognizes that a failure in a vehicle system does not necessarily lead to a hazardous event.
There are 5 controllability classifications, and the hazard with the highest controllability
classification determines the integrity level for the system.
There is a 11 correspondence between controllability and integrity level, therefore MISRA has 5
integrity levels. MISRA integrity levels 14 are concerned with safety-related functions, and
MISRA integrity level 0 is concerned with non-safety-related functions. MISRA uses integrity
level rather than safety integrity level because integrity in an automotive context encompasses
the need for a system to be reliable not only for safety reasons, but also for reasons of product
quality, preventing economic loss, etc. MISRA integrity levels 14 are broadly equivalent to IEC
61508 SIL 14, and practitioners frequently use the terms interchangeably.
Similar classification schemes are found in other standards and guidelines. Some notable
standards include the UK Defence Standards [32] where SIL is used as a measure of the (safety)
assurance required in a system. SILs are derived by classifying the accident severity and
combining it with the probability of failure. In the civil aviation sector (e.g. [26]) hazards are
classified using a scheme similar to controllability where the ability of an aircraft flight crew to
continue in safe flight and landing after a failure are assessed.
The US MIL-STD-882D [29] takes a similar approach but does not explicitly use the term SIL. For
each identified hazard, the severity and probability of the associated mishap (accident) define the
mishap risk associated with the hazard. The need for risk reduction is determined by the
relationship between these mishap risks and the mishap risk level that has been defined as
acceptable. Some examples of requirements that are relevant in this context are:
The catastrophic mishap rate shall not exceed per operational
hour
No hazards assigned a catastrophic severity are acceptable.
The controllability technique and its relationship to other approaches are discussed more fully in
[33].
2.1.3.3 Techniques for hazard analysis
Hazard and safety analysis techniques are used for two purposes:
To identify the hazards associated with a system and the necessary
level of risk reduction;
To verify during the development of the system that the necessary
level of risk reduction is being achieved.
5.8.2004 Version 1.0 11

In IEC 61508, there are no specific requirements for the hazard analysis techniques to be used,
but examples of quantitative and qualitative methods of SIL determination are given in Part 5.
For quantitative methods, an example of numerical calculation of
failure rates is given.
For qualitative methods, examples of the risk graph and the
hazardous event severity matrix. It is noted that both of these
methods need industry specific versions.
A reference is made to the MISRA guidelines for an alternative
method.
IEC 61508 includes the principles of tolerable risk and ALARP (as low as reasonably practical).
ALARP is a pragmatic approach for assessing the level of risk reduction that can be achieved
compared with the benefits that are delivered by that risk reduction.
The MISRA Guidelines have a requirement for a preliminary safety analysis to be performed during
concept design and for detailed safety analysis (intended to be iterative) during system design.
Preliminary safety analysis can be done using the PASSPORT process (which amounts to an
informal FMEA and FTA) or HAZOP. Detailed safety analysis can include activities such as FMEA
and FTA.
Further guidance on safety analysis is due to be published at the end of 2004 incorporating
automotive versions of the risk graph and HAZOP approaches.
In the SETTA project, it was recognized that functional development and safety analysis are often
carried out separately from each other. It was proposed to integrate both activities via tool
interfacing. Tools supporting FTA could be connected to simulation tools such as Matlab/Simulink
with the aim of generating fault trees semi-automatically.
2.1.3.4 Design requirements for safety-related hardware
This subject is concerned with both safety requirements (the design requirements that are
necessary for the hardware to be safe) and design process requirements.
IEC 61508 Part 2 contains tables of techniques and measures to:
Control failures during operation
Control systematic operational failures
Control systematic failures caused by hardware (and software)
design
Control systematic failures caused by environmental stress or
influences
Avoid systematic failures during different phases of the lifecycle.
Each technique and measure is graded with a requirement for its use by SIL. It is noted that many
of these techniques are quite specific to the industrial process control sector.
The MISRA Guidelines, while not specifically concerned with hardware, give guidance on some
hardware issues related to electromagnetic compatibility (EMC) performance and design of real-
time systems such as interrupts. The MISRA model lifecycle includes parallel activities for the
design and implementation of both hardware and software.
In MIL-STD-882D [29], the topic of design requirements is addressed at a high abstraction level
that covers both hardware and software as well as any other implementation technology. Although
no specific design requirements are given, the document provides some comments and examples
regarding design requirements:
5.8.2004 Version 1.0 12

In decreasing order of preference, the alternative measures for risk

mitigation are:
Elimination of hazards through design selection
Risk reduction through design selection
Incorporation of safety devices
Provision of warning signals to users
Procedures for use and training of users
Design Requirement example: The system shall meet standard
Design Requirement example: A single fault shall not be able to
cause a mishap of a severity higher than
2.1.3.5 Design requirements for safety-related software
This subject is concerned with both safety requirements (the design requirements that are
necessary for the software to be safe) and design process requirements.
IEC 61508 Part 2 contains a table of techniques and measures to control systematic failures
caused by hardware and software design. The software part of the table cross-references to
Part 3. This Part contains a guide to the selection of techniques and measures for software and
provides detailed tables for some of them. Part 7 has an overview of these techniques and
measures. It contains recommendations for specific programming languages including C, which
can be used at all SILs provided a subset, coding standard and static analysis tools are used.
IEC 61508 contains many techniques and measures that are primarily applicable in industrial
process control. Some of these may however be useful in developing guidance for emerging
technologies in the automotive industry. An example is the use for industrial control of PLC
(programmable logic controllers), which are typically programmed using a language such as
ladder logic which is a degree of abstraction removed from the code instructions that implement
it. IEC 61508 describes such languages as limited variability. There may be scope for applying
some of these requirements to assist with implementing model-based development and autocode.
In the MISRA Guidelines, Table 3 gives a summary of requirements for each lifecycle stage
(specification and design, languages and compilers, configuration management, testing,
verification and validation) against integrity level. MISRA C [34] gives specific guidance on the
safer use of C within automotive embedded systems.
2.1.3.6 Safety proof
Safety proof is understood to mean the evidence that a system (the final prototype or the series
product) meets the safety requirements.
IEC 61508 [20] uses the terms overall/ E/E/PES/ software safety validation for the activities of
confirming that the EUC/ E/E/PES/ software meets the respective functional safety requirements
and the safety integrity requirements. The means of validation can be either analysis or testing.
For software, IEC 61508 declares testing to be the main validation method. Part 7 lists as general
validation methods: functional testing under environmental conditions, interference surge immunity
testing, static analysis, dynamic analysis, worst case analysis, expanded functional testing, worst
case testing, fault insertion testing, and five failure analysis techniques: failure modes and effects
analysis (FMEA), cause consequence diagrams, event tree analysis, failure modes, effects and
criticality analysis (FMECA), and fault tree analysis (FTA).
The state of the art in the automotive industry is the existence of a sophisticated quality
management. Safety and reliability are considered to be quality attributes that form the top of a
5.8.2004 Version 1.0 13

pyramid that is based on quality ([35]). Most of the established quality assurance procedures are
not specifically tailored to safety.
For quality assurance specific procedures for the supplier and the vehicle manufacturer are
described in the VDA series on quality management (e.g. in [36], [37]). They include failure modes
and effects analysis, sample tests (including functional tests), reliability tests, reviews and audits.
Failure mode and effects analysis (FMEA) is well-established in the automotive industry. Three
types of FMEA are distinguished: System FMEA, Design FMEA, and Process FMEA. Although
being a method for preventive quality assurance and risk assessment, the value of carrying out an
FMEA from system level down to design level is that it also gives evidence in the systems ability to
fulfil the safety requirements. The VDA FMEA guidelines [37] propose the use of risk priority
numbers (RPZ) which are calculated as the product of the parameters B (seriousness), A
(occurrence probability), and E (probability of recognition). For the parameter B levels from 1 to 10
are defined with the highest levels for safety related hazards. Thus, FMEA can be used to assess
the safety related risks of the product design on a coarse scale. For software the FMEA is usually
carried out only on specification level. Risks of the implementation are not specifically addressed.
Note: in English-language automotive FMEA standards the respective parameters are RPN,
severity (S), occurrence (O) and detection (D).
Fault tree analysis (FTA) is sporadically used in automotive industry for providing quantitative or
more detailed analysis results for critical top events. FTA is also addressed by the VDA series on
quality management ([38]). Nevertheless, different conceptions of suppliers and vehicle
manufacturers with respect to suitable structure, level of detail, and source of claimed failure rates
of an FTA exist which reduces the general acceptance of this method.
Volume 13 of the VDA series [39] which is concerned with software-dominated systems introduces
a set of general requirements for software quality assurance. Based on a V model of software
development a set of review and test activities is defined together with some general criteria. A
link to safety requirements is not mentioned explicitly.
In addition to the comprehensive approaches like FMEA and FTA, there are partial approaches
that validate a product design with respect to specific requirements that are related to safety (e.g.
freedom from certain design faults, robustness with respect to specific faults). Examples of such
approaches are core fault emulation, worst case execution time analysis and automated static and
dynamic code analysis. However, these approaches are only sporadically used in the automotive
industry and not established.
2.1.3.7 Safety assessment
Most safety-related systems standards include a requirement for safety assessment, where the
level of safety achieved by the system has to be assessed independently from the developers.
In IEC 61508, there is a stated requirement for functional safety assessment, meaning the use of a
person or team independent form the system developers. The minimum levels of independence
vary with SIL and also with the degree to which the system or the technology used in it is novel.
The MISRA Guidelines recommend that a company nominates a suitably qualified and
independent assessor and/or auditor to perform product assessment, in order to act as an
advocate for the level of confidence in the safety delivered to the end customer. An assessment
process should be performed to demonstrate that the risks associated with the final system are at
an acceptable level. The MISRA Guidelines are less prescriptive than IEC 61508 on minimum
independence requirements, but it is required to be a different person, or a different
department/section, or a different company/division.
2.1.4 State of the art of engineering
The state of the art for engineering integrated safety systems is described in two parts. Section
2.1.4.1 outlines a representative engineering process from current practice of engineering
5.8.2004 Version 1.0 14
automotive embedded controls. Section 2.1.4.2 is an assessment of the current practice relative to
the state needed for meeting 2010 road safety objectives of the European Commission.
2.1.4.1 A representative engineering process from current practice
To develop an electronic automotive control system, several typical design steps have to be
performed. The requirements are stating what the control system should do. These requirements
are transformed into control-engineering (or functional) models. The subsystems of the functional
model are distributed over several ECUs, e.g. by using existing subsystems on remote ECUs.
Feasibility of the distribution or allocation is checked, i.e., whether the requirements of the
application system are satisfied, e.g., memory and processor capacity on the ECUs, capacity on
the communication buses, and overall timing requirements. Having all subsystems broken down to
ECUs, the software-design of the control-algorithm starts taking into account the current E/E-
architecture. The implementation of the control algorithm (coding) and integration with other
software components on a particular ECU follow the design phase. The ECUs communicating over
the network have to be integrated to form the E/E-architecture. Design of the distribution or
allocation is often iterative, including investigation of modification to the physical architecture.
These design iterations could be costly, and some timing errors could still remain latent. Having
done this, all functions are validated: critical ones on architecture test bench, and all, in vehicle
tests. If a system works at all, it has to be calibrated. Exhaustive field testing may reveal errors
occurring very rarely. This type of a process is often shown as a V Model (Figure 29). All design
steps are shown on the left side, the implementation is in the bottom whereas testing, integration &
calibration steps are shown at the right side of the V.
In automotive control systems design, these design steps are not performed only once, but several
times. The reason is that the electronic design process is embedded in the mechanical design
cycle. The latter spans from CAD-design of the engine/vehicle down to the preparation of the
appropriate production plant. An example is shown in Figure 2.
M0 M1 M2 M3 M4 SOP
Simulation Based Management

Management
Vehicle Development Milestone
Milestone
0
Concept
Phase 1
2
3
Hardware
Support
Mules
Prototype A
Prot. B
Figure 2: Example of a vehicle design process

From the electronic automotive control system development point of view, the following vehicle
prototypes are relevant for series production development.
Mules are the first vehicles used for testing new components. Mules have not the shape of the
planned vehicle, but similar technical characteristics. The new components are usually A-samples
5.8.2004 Version 1.0 15
and integrated in the Mules by prototype shops. From the suppliers point of view, these mules are
often called A-samples, because the vehicle manufacturer obtains a complete automotive
electronic control system which is not the case in the earlier concept validation phase. The
purpose of the Mules is component development and public road tests. The component
development includes crash, durability and noise & vibration testing. For functional chassis
development, one winter and one summer test are included.
Prototype As are the first vehicles that have the shape of the new vehicles. Ideally, the Prototype A
has all new components included. The control units are usually B-samples of the production
supplier. The components are integrated in the vehicle by prototype shops. The purpose of the
Prototype A is the validation of the vehicle integration and the performance evaluation. For
functional chassis development, one winter and one summer test are included. Typically only very
few Prototype A are build up and shared between different departments. The optimisations of the
development process are included into the Prototype A during lifetime. The release of the
production parts are usually based on the Prototype A development.
Different types of Prototype B are the last development vehicles built before SOP (Start of
production). All the parts of the Prototype B are off-tool parts of the production supplier (C-
Samples), the very last group of Prototype B vehicles has to be equipped with parts produced
under production conditions (D-Samples). The purpose of the B prototype is the complete vehicle
validation and the manufacturing process validation. For functional chassis development, one
winter and one summer test are included.
During the Vehicle Development Process, different Management Milestones has to be reached.
Engineering Start, Styling/Package Freeze, Release and Start of Production are possible
milestones. As can be seen in Figure 1, the management milestones are closely linked with the
successful validation of the different prototypes. Therefore, in the sequel the development time to
reach this milestone is called a development stage.
Some examples for typical engineering development processes in the automotive industry are
introduced in the VEESA study [113].
The engineering process looked at from a System Suppliers Point of view can be demonstrated
according to Figure 3:
5.8.2004 Version 1.0 16

Figure 3: Phases in software development process (system suppliers view)

Each sample is developed according to standard V model. Certain steps are omitted according to
the requirements that the respective sample has to fulfill:
The A-Sample can be described as a Pre-Study. No target hardware
is used in the car. A Rapid Development System is used to evaluate
the feasibility through a few tests for some performance aspects, and
to study new functionality. The process in this phase is a rather
reduced one: major process steps are there, but steps are not
detailed.
With AB-Sample, a real hardware is used, but this hardware is just to
demonstrate the function. Hardware does not resemble the later
series hardware. This sample can be described as a Functional
Prototype. The process in this phase is more detailed in the design
steps: Requirements are not only gathered but also analysed. A first
draft of the design on system and module level is generated. Testing
is still performed in one big step System Test.
B-Sample is the Development Prototype. In this phase, the
development process is fully grown up: In addition to AB-Sample,
testing is now performed in several consecutive steps, with module
test and function test on a module basis. The process in this B-
Sample phase can be iterated resulting in B-1, B-2, samples. Two
quality gates have to be passed in this phase, which are represented
by check lists: SWQB1 and SWQB2 (less important)
C-Sample is the Pre-Production-Prototype. Hardware is now close to
the later series hardware. The process is quite similar to B-Sample
5.8.2004 Version 1.0 17

process, but requirements should be completed by now. Steps can

be iterated. Two quality gates have to be passed in this phase, which
are represented by checklists: SWQC1 (less important) and SWQC2.
Production is then prepared with D-Sample.
The different views of the electronic automotive control systems design have been compiled in a
table shown in Figure 4. The rows show the design steps whereas the columns show the
development stage. Besides the above mentioned A-, B-, C-sample stage, there are evaluation
stages before production development starts. This is mainly the concept validation stage where
first ideas of a new automotive control system is either modelled on a PC or validated in currently-
in-production-vehicles. In this particular stage, no emphasis is put on production (and hence on
production cost) at all but it shows the feasibility of the system. The vehicle project stage is a
production prototype preparing stage where the electric/electronic-architecture is specified for that
vehicle type which is kept stable throughout all subsequent development stages and also the
production phase itself. However, some vehicle manufacturers develop a new E/E-architecture
throughout the vehicle lifecycle, while major mechanical parts are kept the same and some minor
changes, often called facelift, may occur.
Concept Vehicle
First Ideas Validation Project A-Sample B-Sample C-Sample SOP Reflashing 1 Reflashing 2
Requirements Management x x x x
Function Analysis/Spec. x x x x x
Partioning x x x x
SW-Design x x x x
Implementation x x x x
SW-Integration x x x x
Com.System Integration ? x x x
Vehilce Test x x x x
Fine-Tuning ? x x
Field Test ? ? x
Figure 4: Development matrix

As can be seen in Figure 4, not every design step is performed in each development stage.
From the software-development point of view, there are several means (development tools and
hardware) dedicated for each design step. However, sometimes these means differ in the
development stages. Therefore, the following sections describes typical design means according
to the above identified design steps and development stages.
Integrated Safety Systems are characterized by integrating several automotive control systems.
Prior the integration of an automotive control system somebody has to validate whether the
concept of this control system will work at all. The typical way for doing concept validation is to
build a model of the control function and integrate this in a vehicle currently in production. In this
vehicle, it is necessary to attach the required sensors and actuators as well as an electronic control
unit. This electronic control unit is as a rule flexible and configurable during the validation phase
(as a rule testing on a track or a bed). The control-algorithms have to be adapted to an existing
E/E-architecture, i.e. the topology of ECUs, gateways and networks. A typical example of the
adaptation of a control-algorithm is the vehicle speed signal which is sent over a network from
other ECUs and does not have to be calculated by the new control systems on its own. As
mentioned above, in the concept validation stage production cost is not the main goal of the
validation. Therefore, the flexible and configurable control unit, also called rapid development or
rapid prototyping system respectively, has a more powerful processor and more memory than a
production control unit. Hence, code-generators for graphical control models focus more on turn-
around times than on memory-consumption.
5.8.2004 Version 1.0 18

Concept Vehicle
Partioning x x x x
SW-Design x x x x
Fine-Tuning ? x x
Field Test ? ? x
Figure 5: Model-based design with rapid development systems

One day, there will be a decision for the next generation of a vehicle and a list of electronic
features, i.e. automotive control systems that a vehicle has to support. For this electronic feature
list, an appropriate E/E-architecture is designed. The software relevant result of the E/E-
architecture design is the communication matrix. It defines on a broadcast network, which inter-
ECU signals are mapped to a communication-systems frame. During several development stages,
control algorithms are modified. These modifications may influence the communication matrix.
Therefore, the consistency of the networked control system has to be kept which requires
permanent testing. Similarly, the E/E-architecture might have to be redesigned to meet the
requirements of the new application system.
Concept Vehicle
Partioning x x x x
SW-Design x x x x
Fine-Tuning ? x x
Field Test ? ? x
Figure 6: Communication matrix definition and testing

The transformation of control algorithm models to embedded C-code is still in its infancies. More
often than not, in the software design phase the graphical models are transformed to C-code and
integrated manually. As experience shows, all modifications to the control algorithms are
performed on C-code level once this transformation has been done. Of course, during
development time the graphical model and the code diverge. This leads to the fact that all
subsequent validation and verification steps, e.g. code reviews or unit tests, have to be done on C-
code level, more often than not a poor match of a control-engineers mindset.
Concept Vehicle
Partioning x x x x
SW-Design x x x x
Fine-Tuning ? x x
Field Test ? ? x
Figure 7: Manual programming and code reviews
5.8.2004 Version 1.0 19

An alternative to manual transformation is an automatic transformation of graphical control models

to C-code. With an appropriate tool-set, these transformations can be done in a sufficient accuracy
even under production cost constraints (minimal memory- and runtime consumption). The
advantage of this (code-generation) approach is that all modifications in the control algorithms can
be performed on model level instead of C-code level, thus ensuring that the C-code will not diverge
from the graphical model. Last but not least people with mechanical- or control-engineering
background have better chances to contribute to the control-software development. Manual
transformation errors are minimized while the code-generators themselves are becoming crucial.
Certification of code-generators is one means to ensure the correct implementation of the
transformation rules.
As shown in Figure 8, code generation is performed during A-, B- and C-sample.
Concept Vehicle
Partioning x x x x
SW-Design x x x x
Fine-Tuning ? x x
Field Test ? ? x
Figure 8: Model-based design with certified code generators and no code review
Automotive control systems can be validated by means of Hardware in the Loop (HIL) systems.
One or several networked ECUs running automotive control software are tested versus vehicle
models running on dedicated real-time hardware in the laboratory. Since on the one hand lab-
tests are cheaper than tests on the track and allow on the other to drive the control-system under
even more scenarios HIL-testing is a crucial complementary validation means. It is performed at
several stages in the production development process as shown in Figure 9
Concept Vehicle
Partioning x x x x
SW-Design x x x x
Fine-Tuning ? x x
Field Test ? ? x
Figure 9: HIL testing

Calibration tools are used to trim control algorithm parameters on the track or testbed. Of course,
they can be (and are) used on HIL-systems too to save some track-time. As shown in Figure 10,
calibration is performed during vehicle testing at all stages of the production development process.
5.8.2004 Version 1.0 20

Concept Vehicle
Partioning x x x x
SW-Design x x x x
Fine-Tuning ? x x
Field Test ? ? x
Figure 10: Calibration
2.1.4.1.1 Example engineering lifecycle of a purchased component
The following example illustrates the interaction between a customer, e.g., automotive OEM, and a
component supplier over the engineering lifecycle of a typical safety-critical component, such as an
airbag. Although the specific process steps, time-frames, and division of work given in the example
may be different for specific components, the nature and importance of the interactions remain
similar. Table 1 provides an overview of the overall process. It is iterative and evolutionary in
nature, with evaluation and validation progressing through a series of prototypes, shown in Figure
2 as A-Sample, B2-Sample, B3-Sample, C-Sample, etc hereafter referenced as A, B2, B3, C,
etc.).
Table 1: The engineering process progresses from conceptualization to industrialization

through a series of prototyping and validation stages in iterative, evolutionary cycles.
Index Customer to Supplier Supplier to Customer
1 Provide requirements and constraints for

the component
2 Realize component
3 Validate component
4 Integrate component in vehicle
5 Perform integrated validation of the
component.
6 Repeat 1, 4, and 6 until component is Repeat 2 and 3 until component is
industrialized. industrialized
The overall engineering lifecycle is outlined below in four main stages (1) Concept Engineering
(Table 2), (2) Realization (Table 3), (3) Industrialization (Table 4), (4) Lifecycle follow-up (Table 5).
Within each stage, the process is tabulated in terms of flow of engineering work products between
the customer and the supplier.
Concept engineering stage
There are three sub-stages in the engineering stage: (1) Preparatory (Table 2 Index 1-2). (2)
Technical specification development stage (Table 2 Index 3-11). (3) Enrichment of the technical
specifications (Table 2 Index 12-22).
Table 2: Engineering progresses through Protoypes A and B1, focused on the product
concept.
5.8.2004 Version 1.0 21

1 Study and choice of concepts, definition of

the interfaces and documents of organic
design of the function worked out with two or
three iterations on the functional
requirements with reliability studies and
organic constraints depending on the organic
architecture decided by the vehicle project.
2 Proposals and validations by calculations and
physical tests of new concepts, feasibility of the
new product with its associated process and
components.
3 Organic and Functional Technical
Specifications of the product including the
requirements of the interfaces and the
reliability, then the list of the hazard events
brought back to the organic part.
4 Management Clauses and plan of quality,
delays, investments, set-up time.
5 A management part describing the project
organisation (plan of development and quality), the
elements of periodic follow-up and the control of
the variations (step risks...)
6 Plan of System Dependability within software and
including the steps, its setting, the associated
tools...and the definition of the levels of criticality
that are unacceptable for the system.
7 Commitment on the OEM quality objectives with the
associated justifications (confirmation on C
prototype)
8 Consolidation of the technical specification of the
product with the traceability matrix of the evolutions
of its requirements, and establishment of the
technical specification of the components.
9 Selection of supplier for production
10 A Preliminary Technical Analysis made up of
the above elements and the following ones:
Definition of the shared responsibilities.
List of the essential design and functional
features of the electronic system (housing +
sensors).
Elements of the reliability study: preliminary
hazard analysis and dreaded events of the
vehicle, fault tree analysis of the system,
external functional analysis (consolidated in
review of detailed design)
List of the known risks and defects.
11 A preliminary technical analysis made up of the

following:
A plan of development and quality containing a
description of the product, the list of the principal
components, the prototype phases and their hardware
and software contents.
5.8.2004 Version 1.0 22

A Control Plan of the risks, identified by the OEM and

the SUPPLIER, and of the eradication of the defects,
including the defects met on products or similar
developments, the risks resulting from the plan of
reliability, and the defects met at the time of the
system development.
Plan of integration and validation with the list of the
tests for the totality of the requirements (the final
version is frozen at the end of the detailed design
review).
Recall of the sharing tasks between the OEM and the
SUPPLIER.
A forecasting study of traceability of the system on
vehicle (customers and tier supplier...) to consolidate
at the design review and at the process validation
review.
12 Reviews of preliminary design Reviews of preliminary design

13 A prototype
14 Acceptance of the elements of justification,

validation and checking of the robustness of
the A prototype definition.
15 Documents of product definition as follows:1
Documents of systems design
Synthesis of the product
FMEA
Estimated reliability analysis
Justification steps of the design product (conformity

with the requirements)
Internal functional analysis
Preliminary hazard analysis
Identification of the critical components
Commitment on the quality objectives (hazard events

of the technical specification)
Justifications, quantified fault tree analysis of the
components
Calculation and analyzes of the product estimated
reliability
Diagnosis matrix
Detailed product FMEA
Documents of the reliability synthesis (to argue the

results reached and to identify the elements allowing
their justification)
Documents of integration validation with plan and
procedure, matrix of conformity with the technical
specification and reports of test.
1 Updated at the product validation review and at each stage of evolution: model, B2 & C prototype,
preproduction.
5.8.2004 Version 1.0 23

Control plan of the risks and the eradication of the

defects.
Documents of justification of the product conformity.
16 Results of Checking of the SUPPLIER

definitions: validation of SUPPLIER
commitment on estimated reliability, and
product FMEA validation.
17 Officialisation of the above items.
18 Functional technical specification
(consolidated) of version for delivery of
representative prototype.
19 B1 prototype
20 Acceptance of the elements of justification,

validation and checking of the robustness of
the B1 prototype definition.
21 Repetition of item 15 for B1
22 Repetition of items 16-18 for B1
Realization stage
Process: Improve product, process and tools through a series of prototyping and validation cycles.
End state reached from this process:
Product is defined
Process is defined
Product and Process definitions are compatible
Tools are robust
Prototypes B2, B3 and C are realised during this phase. The number of representative prototypes
depends upon the project.
Table 3: Process for realization of a safety-critical component. Duration is less than 1 year.
1 Results of the unit tests of the integration (1-3 times

for B2)
2 Validation documents for B2
3 Latest version of the software for B2, with test
report, including functionally tested and
guaranteeing the non-regression. Report also
includes reference documents, trace-ability of the
evolution, list of functions implemented, list of
functions not implemented, functional state of the
product, list of detected defects, list of open
(uncorrected?) defects, list of tests carried out prior
to delivery and results of tests, etc.
4 Anomalies report for B2 (product, process
and tooling are validated, integrated in
5.8.2004 Version 1.0 24

vehicle)
5 As listed above, but for B3
6 Anomalies report for B3
7 As listed above, but for C, as necessary
8 Anomalies report for C As above.
9 Finalized product definition documents
(finalized justification file and receipt report),
and the process definition and tools.
Industialization stage
There are three sub-stages in the industrialization stage: (1) Detailed design process (Table 4,
Index 1-5). (2) Validation of the product made with pre-production tooling offline (Table 4, Index 6-
12); duration = 1 year. (3) Validation of the product made with pre-production tooling in-line,
including customer-acceptance (Table 4, Index 13-17); duration = 1 year.
Table 4: Process for industrialization.

1 C Prototype is realised with zero blocking

functional defect. Two off line products are
delivered with no major functional defects.
2 Product, processes and tools definitions are
robust (phase of life series).
3 Process FMEA is available, monitoring and
action plans are defined.
4 Acceptance of the SUPPLIER definitions and in
particular of the compatibility of the product
definition with the constraints of the process
qualification (example: estimated capability).
5 Officialization of the launching of the tool realisation
(specific tools for manufacture).
6 Definition of a data file of calibration.
7 Pre software calibration (constraints and
proposals of the calibration).
8 Acceptance of the SUPPLIER calibration with its
dispersion.
9 Results of tests on a vehicle
10 Analysis of the vehicle tests and confirmation
of the margins and the robustness of the
calibration.
11 Documents of process definition with the
synthesis of the process FMEA, calculation
of the process FMEA capabilities, and
assessment of the action plans.
12 Acceptance of the product pre-qualification
13 Two in line products are delivered with no
major functional defects.
5.8.2004 Version 1.0 25

14 Results of validation of software calibration.

15 Acceptance statement of the preproduction
products in factory.
16 Documents of process qualification.
17 Acceptance of product and process qualification
before SOP
Lifecycle follow-up stage
Table 5: Follow-up lifecycle process for of a safety-critical component.

1 Information on the cases of Product expertise of detection.

"doubtful explosions" with the
vehicle expertise.
2 Commitment defined over the conformity of measured
production, the conformity of the product with 1 year, 2 years
and 3 years of rolling.
Customer Tasks
1. Audit SUPPLIER operation
2. Audit process of achievements of the reliability studies
3. Evaluate the test facilities and the full rates (cadences) on site of manufacture.
Supplier tasks:
1. Ensure management of configuration (for traceability, evolution, and coherence of the
product...).
2.1.4.2 State of the engineering process relative to 2010 road safety goals
The current state of automobile engineering practice, outlined in the previous section, is
characterized in terms of the distance from the state needed to meet the 2010 road safety targets
of the European Commission. Topics in this assessment have been selected in consideration of
their potential impact on the road safety objectives. With the increasing software content,
complexity and quality issues in vehicles, the assessment is focused on issues affecting software.
To help assess the magnitude of the development gaps identified, research references are cited.
However, citations do not necessarily imply advocacy of adopting their solutions.
Figure 1 sets the context of this work in terms used in IEC 61508 [20]. In this assessment,
engineering is defined as the application of a systematic, disciplined, quantifiable process to
transform customer needs, e.g., road safety, into embedded software-intensive systems to control
the vehicle.
First, an integrated assessment is provided, followed by assessments of critical aspects of the

overall engineering process.
5.8.2004 Version 1.0 26

2.1.4.2.1 Integrated assessment
There is no adequate, accepted, mature, demonstrated process for engineering integrated safety
systems of the scale of todays automobiles. There are fundamental weaknesses at the system
engineering level [93], starting from fuzzy notions and usage of basic terms such as system,
safety, and integrated.
For example, analyze the definition of Integrated Safety System proposed for EASIS: A
composition of functions In current practice, notions of composition and function do not
even conform to ordinary dictionary definitions of these terms, in the requirements space, as well
as in the solution space. If the requirements are not formally specified, then compliance with the
requirements cannot be formally verified. Therefore, one cannot prove that risk is contained within
acceptable levels. Thus, it is not possible to assure that the (vehicle) system meets its intended
road safety objectives.
Current practice does not engineer risk management aspects of the vehicle, driver and the
environment, as a system, as defined in [29]. Even risk from within the vehicle itself is not
managed as an integrated system. A contributor to the problem is the manner in which OEM
organization structures divide roles and responsibilities, e.g., separation of safety, hardware and
software. Many factors - not usually recognized as safety related - can influence risk in unintended
and unexpected ways. No systematic, disciplined, quantifiable process is used to identify and
analyze these influences.
In current practice, safety is often engineered in terms of protective measures that are incorporated
in addition to normal operating functions, rather than being integrated. For example, the
manufacturing automation industry has been applying IEC 61508 to functional safety by
engineering it separately from normal operating functions separate processors, buses and
software.
The automobile industry does not have a systematic, disciplined, quantifiable process for hazard
analysis [94], [95], [96] in the requirements engineering phase, i.e., preliminary hazard analysis
(PHA). The process is particularly weak in analyzing influences of the environment on the vehicle.
For example, [22] Section 3.2.2.2 specifies, A preliminary safety analysis should be performed
early in the lifetime to determinethe hazards associated with potential failures in the system
However, hazards are not always caused by failures of electronic systems. Hazards may also
result from factors such as driver behaviour, traffic conditions, and road layout. Engineering is
focused on failures and faults within the vehicle, and thus on reliability and dependability related
metrics. As a result, the approach to risk management has been overly concentrated on
replication-based fault-tolerant design, as opposed to a requirements-driven systematic search for
alternative solution approaches, e.g., early detection and warning of (impending) failure, mitigation
of fault propagation, reduction of services (degraded mode; limp home capability).
Searching for environmental risk management approaches outside the automobile industry, we find
useful parallels in the aviation industry. Hazard analysis on aircraft systems includes an
assessment of the environment within which the system will operate, including the maintenance
regime, aircrew training and airframe limitations. Within the automotive context, there are parallels
including the annual roadworthiness inspection required in Europe, and the driving test and
statements of good driving practice (e.g. in the UK Highway Code). However these are often
limited in their scope, e.g. a driving test need only be passed once, and there is no requirement for
periodic revalidation. There is no general consensus on what the overall constraints or safety
envelope (vehicle maintenance, driver skill maintenance, use restrictions) should be for an
integrated safety system. Thus, the {vehicle, driver, environment} system is unbounded. It is not
possible to arrive at a satisfactory solution, i.e., risk level which is acceptable and achievable.
5.8.2004 Version 1.0 27

System Lifecycle Process
Safety Assessment Process
System/Subsystem Design Process
- Requirements allocated
- Safety Integrity Level
Feedback
- Requirements allocated
Hardware Lifecycle Process Feedback - Safety Integrity Level
Software Lifecycle Process

Software Planning Process
Software Development Process
Software Integral Processes
Figure 11: Relationship across System Lifecycle Process and Software Lifecycle Process
5.8.2004 Version 1.0 28

2.1.4.2.2 Gaps in system and software engineering methodology
The overall business process tends to bundle electronic hardware and software with the
corresponding electromechanical subsystems, e.g., steering and brake. Requirements from the
OEM (system engineering) for subsystems, typically specific to a vehicle, flow down to respective
subsystem suppliers. These requirements typically specify functions and hardware interfaces, e.g.,
interfaces to the buses. Software interfaces are typically specified in terms of communication
messages, formatted for specific communication buses. There is little control over the software
process used by the subsystem supplier. Software specification techniques used by customers are
not rigorous enough to allow efficient verification of software from suppliers, even though better
specification techniques exist [97].
Typically, engineering is specific to a single vehicle, following the waterfall method (the traditional
V model). The process is dominated by predefined hardware constraints. There is little
opportunity for software engineering to influence system specifications and hardware constraints,
often resulting in compromised software. Reuse of software is ad hoc, and mainly within a
suppliers own organization.
In contrast, the Software Product Line Engineering (SPLE) approach [98] is in practice in other
industries. The process strongly depends upon architectural specifications [99] and reusable
components [100] conforming to the architectural specifications. Requirements Engineering is the
weak link in the current state of SPLE, although requirements reuse techniques are emerging
[101].
Leading innovators in other industries are moving away from the traditional waterfall method and
towards a method of iterative incremental evolution and development [102]. The iterative cycles
allow tradeoffs against hardware constraints and other system requirements.
2.1.4.2.3 Gaps in requirements engineering and management
Typically, requirements from OEMs to suppliers lack the rigor needed for High Integrity Systems,
By and large, requirements specifications [103] are incomplete [104], inconsistent [105], and not
formally analyzable [106], although some recent progress has been reported [107].
Requirements tend to be docu-centric, text-oriented, and informal. Subject matter experts who
have knowledge of requirements often lack the expertise to express themselves in terms of formal
specifications. On the other hand, a formal methods expert lacks the expertise to elicit the real
requirements out of the subject matter experts, and may create specifications that may not reflect
the real needs and may not be easily reviewable by the knowledge-sources. This informal-formal
gap exists across all industries. However, there are well-documented approaches to address this
gap [108], [109].
System requirements and results of preliminary hazard analysis (PHA) and subsequent Hazard
Analysis (HA) are not well integrated [110]. There are no information model standards for the
results of PHA and HA to be integrated into requirements models, although some progress is
reported [111], [112], [113], [114].
Typical relationships across requirements include derived from and supports. However, other
types of relationships are also needed, e.g., conflicts with (to support tradeoff analysis),
composition (to formalize the model), causality (to support hazard analysis), mutual exclusion,
etc.
5.8.2004 Version 1.0 29

2.1.4.2.4 Gaps in traceability
It is not possible to trace from an individual atomic requirement item to its corresponding design
element and vice versa. There are a number of barriers, including the lack of formalism in the
requirements engineering process, the lack of design standards to facilitate mappability, and
inadequate support in design tools. Without traceability, it is difficult to check whether all
requirements are satisfied and whether the design goes beyond the specified requirements.
Similarly, the traceability from requirements to software validation and verification plans (SVVP) is
also weak, making the verification task more effort-consuming and error-prone. In tools that link
requirement to test-cases through correspondence tables, the manual maintenance burden is very
high; it results in inconsistencies.
2.1.4.2.5 Gaps in safety requirements specification
There is no agreed-upon acceptable (or tolerable) risk level for integrated safety systems. A
moving automobile is continuously exposed to risk, influenced by many unknowns in the condition
of the road surface, the environment, and the driver the vehicle is only one set of factors.
According to IEC 61508-5 Section B.2, any risk must be reduced to a level which is as low as is
reasonably practicable (ALARP). However, there is no public agreement on what is reasonable
and what is practicable. When society does arrive at some agreement, application of ALARP
would require adaptation of IEC 61508-5 methods to the automobile context. The forthcoming
MISRA Safety Analysis publication will demonstrate how to perform the adaptation within the
context of automotive control systems.
To quote an excerpt from IEC 61508-5 Section A.4, tolerable risk level is based on the current
values of society and in Section A.2, Important factors will be the perception and views of those
exposed to the hazardous event. For illustration of the issue, consider a scenario of 107 vehicles
running on roads around the world at any time (an equivalent of 107 continuously operating
vehicles). Consider a requirement for the highest integrity level in IEC 61508-1, Section 7.6.2.9
and the more demanding continuous mode of operation, in which 10-9 is the most stringent limit on
the probability of a dangerous failure per hour for a safety function. Now approximate the rate at
which a dangerous failure of one safety function might occur somewhere in the world!
Furthermore, consider that there could be many such safety functions with dangerous failure rates
of the same order of magnitude. Would that be an acceptable risk in 21st Century human society?
In [33], hazard is classified by the degree of controllability (by the vehicle driver). Controllability
refers to the ability of the driver to control the safety of the situation following a failure, and
assessment of controllability includes examining the scope of the system authority, the provision
of backup facilities and the driver reaction time. However, active safety systems introduce a new
factor in controllability. Consider the following future scenario: Active safety automation handles
the more common and more frequently occurring conditions, and the driver exercises less active
control to cope with them. The driver is left with the responsibility of those conditions that the active
safety automation cannot handle. However, the frequency of these conditions reduces as active
safety automation improves. In this state, when that infrequent hazardous condition does arise,
will the driver be able to react to it? The question concerns loss of skill and loss of focus due to
inactivity. There are unknowns about the driver-vehicle-environment system. The RESPONSE
consortium has made some progress to address such issues [10][129].
2.1.4.2.6 Verification and validation (V&V)
Validation of requirements is inadequate, even though there are general techniques such as
Quality Function Deployment [115] and techniques specific to software system safety [95].
5.8.2004 Version 1.0 30

The traditional approach to verification is weighted towards downstream code-level testing. It yields
results too late at too high a cost. Testing can only reveal the presence of a defect it cannot
guarantee the absence of defects. V&V should be performed at every stage of the process, i.e.,
shift from the traditional V process to the Y process [116]. Requirements should be checked for
consistency and completeness, for which techniques are available [104], [105]. Current practice
uses simulation to improve design. However, as in testing, it can only reveal the presence of a
defect it cannot assure absence of defects. Formal verification methods are more promising in
this respect [117], [127], [128], [129]. However there are several limitations. First, requirements
specifications are not formal. Hence a translation from the requirements specification language to
the input language of the formal verification tool is necessary. This translation requires
extraordinary skills and it is a potential source of error. Secondly, formal verification methods are
just beginning to be scaleable to the size of embedded automotive control systems. Research has
shown promise by exploiting hierarchical state machines with properly defined semantics [106],
[127], [128]. Formal methods are more developed for discrete control, such as in body electronics,
but not so well developed for control systems that also include continuous-time functions, such as
in steering, braking and propulsion. This is a subject of long-term research [122], [123].
Robust interface specifications of interacting software components can improve verifiability at the
source code prototype (signature) level. Weak data typing deprives the auto industry from
exploiting type-checking available in compilers. However, no such support is available for
verification of distributed interacting components. As a result, too many errors are discovered at
various stages of integration with progressive cost-escalation.
Testing unit code is the most popular verification technique used today. Industry is trying to
automate test-case generation. This trend is not good enough for High Integrity Systems.
Research is underway to shift emphasis towards upstream V&V [116]. The SafeAir project
developed an improvement of the V based development process to save development time and
effort while preserving or improving the dependability of the developed systems. The emphasis
within the project was on formal development of systems, providing formal specification, formal
verification, automatic test case generation and validated code generation. The semantic
integration of system-level and design-level modeling tools allows a virtually integrated V-process
that is sharpened up to a Y-based process with the required steps at the bottom of the former V
being considerably automated. See Figure 12. For more details see [116].
Optimized-Y Improved-Y
Y V
System State of the art
Specification
System
(supplier
Software
specification
Equipment
(manufacturer)
Advanced users
DO178B
Detailed design
compliance
time
Figure 12: Improving V based processes (Safeair project)

5.8.2004 Version 1.0 31
2.1.4.2.7 Gaps in architectural specification approaches
As mentioned earlier, the multitude of programmable electronic functions embedded within the
automobile are not a system in the sense of a true composition. In other words, one cannot identify
an explicit unified single system architecture, specifying or even describing all the inter-
relationships of functions related in some manner, directly or indirectly. Without this comprehensive
view of a system, its architecture and the discipline of defining this architecture, it is not meaningful
to discuss an integrated safety system or its safety properties. Unfortunately, the term
architecture [118] is often used for the physical configuration of interconnections and
interconnected devices. In contrast, available architecture description technology is demonstrated
in EAST-ADL [119].
For engineering vehicles as product lines or families, with software components reusable across
members of the family, commensurate commonality of architectures is needed across all
members. To maximize reusability value over time and product variety and changing technologies,
we need an architectural framework or domain architecture from which specific but compatible
architectures can be derived. This discipline is lacking in current practice. Without it, an integrated
safety system with guaranteed safety properties cannot be composed from components supplied
by different sources. Standardization of a physical platform is not sufficient it draws attention
from more important aspects of architectural specifications, e.g., unambiguous semantics of
interactions and information exchanges.
2.1.4.2.8 Gaps in transformation of requirements to design
The transformation of requirements to design is a subjective, labor-intensive, error-prone process,

resulting from incomplete requirements and implicit design constraints. It does not assure one-to-
one bidirectional traceability. At times, it over-constrains the design.
Model-based design is rapidly emerging in functional units. However, the input and output are tool-
specific proprietary formats and the semantics of the design model are not mathematically-defined
and explicit. Thus, it is not easy to apply third party tools for analysis or verification of the design.
Due to this fact a mathematical semantics of modelling tools are required to apply formal analysis
methods and tools [125], [126]. Furthermore, a tool specific integration of the analysing techniques
is necessary to scope with the formal semantics. It is also not possible to apply a software product
line engineering (SPLE) process with third-party library assets, reusable across tools and
suppliers.
Application of model-based techniques is lagging in the design of the distributed system

infrastructure. A key barrier is the lack of mathematically-defined explicit models of the properties
of the infrastructure resources. Behavior semantics are not explicit. Some research is underway to
address this gap [120]. These gaps exist across industries. It requires substantial research. For an
example of the commercial state of practice, see the Davinci tool suite [55].
There is a need for standards to exchange data unambiguously across the various stages of the
engineering process, across the corresponding tools, and between customers and suppliers with
IP protection where required.
2.1.4.2.9 Gaps in transformation of design to code
By and large the process is manual, using a subset of the C programming language, e.g., as
specified in MISRA [33] [34] and checking the program for conformance to the restrictions [76].
5.8.2004 Version 1.0 32

The transformation of design to programming language code is closer to automation, for a single
functional unit, without reuse of its components across applications, tools, or suppliers. However,
semantic equivalence, and hence correctness of transformation, cannot be proven. A key barrier is
the lack of strong data typing, both within the modeling environment and within the C
programming language.
One-to-one bidirectional correspondence is not preserved. It is common to make changes in code

manually at the time of integrated testing, but it is difficult to maintain consistency between code
changes and corresponding design changes.
Challenges are in automatic code generation which is already used today in some application
areas (e.g. avionics systems). To reduce the testing and validation effort for the resulting unit, the
code generator has to be certified too. As the certification process is quite expensive new releases
of certified code generators are very rare and one has to live with known bugs. Another approach
which overcomes this drawback of certified code generators is code validation, i.e. verifying that
the target code produced by a code generator (equivalently, a compiler or a translator) is a correct
implementation of the source specification [124].
2.1.4.2.10 Calibration issues
Excessive calibration is required at the time of vehicle integration and testing. There are several
contributing causes. Either the algorithm provides too many or too few degrees of freedom in the
calibration. This problem has to be solved by improving the requirement specification for the
algorithm. Secondly, accurate plant models are not available at the time the algorithm is being
developed. Thirdly, algorithm modeling and plant modeling use different modeling paradigms,
making model integration difficult.
2.1.4.2.11 Capability maturity level of the engineering process
The automobile industry, as a community, does not have a continuous improvement process [13]
to grow towards achieving its shared goals in integrated safety systems, i.e., it lacks a
systematized feedback, root cause analysis and correction process. It is limited by the lack of
traceability across all stages and work products in the engineering process. This limitation is rooted
in the lack of an adequate requirements engineering and management process.
2.1.4.2.12 Gaps in software planning processes
With the current state of system and software engineering, high safety integrity levels will require
high quality in work products, as well as the processes. As the main software engineering process
begins to utilize automation and reusable assets, industry must assess the state of readiness of its
software planning processes [26] that direct the software development processes and the integral
processes. These processes produce the software plans and standards and define the
development environment, including tools and their qualification criteria. These outputs will require
standardization across the community of customers and suppliers participating in the realization of
integrated safety systems. Industry lacks adequate tool qualification criteria and qualified tools for
automating software processes such as correct by construction code generation.
2.1.4.2.13 Gaps in integral processes
Integral processes [26] include software verification (already discussed above), quality assurance,
and configuration management (CM).
5.8.2004 Version 1.0 33

CM for families of products is difficult with the mainstream commercial CM tools.

Industry is already experiencing difficulty in coping with the increasing number of software releases
maintaining consistency across products is becoming more difficult.
2.1.4.2.14 Summary of gap analysis
Figure 13 shows a summary of the gap analysis.

Area of gap Size of gap Impact on safety
(effort, difficulty)
System and software engineering method
Requirements engineering and management
Safety requirements specification
Traceability
Verification and validation preventative, upstream
Architectural specification
Exchange, integrate data across tools
Transform requirements to design
Transform design to code
Calibrate less and in less time
Scale
Less More
Figure 13: Summary of gap analysis
2.1.5 State of the art of hardware and software components
2.1.5.1 General architecture
Today vehicles present an enormous variety of electronic architectures: from a highly centralised
approach (with few electronic control units in the car) to vehicles with more than fifty electronic
control units. Low-end vehicles have a single network with CAN Low Speed protocol while medium
and high-end vehicles may several buses: CAN High Speed for engine modules because of the
amount of information to share in short time, CAN low speed for body and diagnostics, LIN-bus for
local sub-networks, MOST for multimedia, ...
In most vehicles, the splitting of the network is similar to the diagram in Figure 14. This splitting is
usually done according to functional areas, hierarchy, safety, stand-by current, etc. Usually,
different messages should go from one bus to another, and then there should be a Gateway
between each of them.
5.8.2004 Version 1.0 34

GATEWAY Standard
Option
Multimedia Body Chassis Powertrain
Figure 14: Example vehicle network architecture
2.1.5.2 Analysis of powertrain domain
2.1.5.2.1 Architecture in the powertrain domain
In todays vehicles the powertrain domain is mainly consists of two ECUs: an engine control unit
and a gearbox unit (the latter only for automatic or semi-automatic gearboxes). For specific
functions such as stop and start, alternative fuel engines (e.g. LPG) or shift-by-wire, additional
ECUs are added to the main network.
The powertrain ECUs are generally connected with the chassis domain ECUs to a high-speed
CAN network of 500 Kbit/s. For several further functions as electro-magnetic valve control,
controlled alternator, diesel warm up, etc. a local network such as LIN or a dedicated CAN network
can be implemented on the engine control unit.
OSEK OS, COM and NM are the only software standards used in these ECUs and they are not
necessarily implemented in every ECU. Component suppliers provide their own ECU with their
own software integration.
2.1.5.2.2 Hardware
Engine control unit

The following are examples of the different functions that are implemented on a petrol (gasoline)
engine controller:
Fuel injection
Engine torque control
Ignition system (petrol)
Electronic throttle control (petrol)
Canister purge control (petrol)
5.8.2004 Version 1.0 35

Lambda sensor heating

Accelerator pedal position acquisition
Engine speed acquisition
Knocking treatment
Map controlled thermostat
Engine cooling unit control
Diagnostic management
Software sensors.
System description
There are many ECU variants with a typical vehicle line having a range of engines from a small
engine to a powerful one and depending on the vehicle, a petrol or a diesel variant. This diversity
introduces the management of a few tens (for instance around thirty for PSA) of hardware variants,
but for software the number of variants is higher than one hundred.
Otherwise the architecture of the ECU is very similar for each application. Typically this is a two-
chip design with a different dimensioning of the microcontroller and the power stages. In this
domain the main processor is typically a 16 or 32 bit device with a second processor (see Section
2.1.5.2.4 Protection strategy) an 8 bit device (or an ASIC). The internal clock can vary from 64 to
120 MHz, the Flash-ROM from 512kB to 1.5MB, an EEPROM space of a few kB is needed and the
smallest cycle time is around 10ms. Direct injection control is a function requiring a large CPU
resource and has the greater impact for the CPU load.
The power consumption of the ECU is between 400mA and 800mA in operation and around 100A
in a sleep mode.
Sensors
Taking as an example the engine management system for a basic engine there are around 20
analogue sensor inputs and 5 logical inputs. The sensors include:
Admission air pressure (or boost pressure)
Admission (intake) air temperature
Coolant pressure
Throttle (flap) angle position (2 sensors)
Accelerator pedal position (2 sensors)
Hard point position of the accelerator pedal
Lambda sensor
Neutral clutch contact
Assisted steering bumper
Redundant stop
Vehicle speed
Motor fan diagnostic.
Actuators
For the same conventional ECU the number of outputs (or commands) is around 15. This varies
with the type of engine and the electro-valves are more numerous for diesel or powerful engines.
The different basic outputs of an engine are as follows:
Injection command (one per cylinder)
5.8.2004 Version 1.0 36
Motor fan supply

Lambda sensor heating
Electro-valves (depending on the engine, more numerous for a
diesel engine or a powerful one: dump valve, fuel control valve, turbo
cooling valve, wastegate valve, etc)
Petrol:
Ignition command (2 or more)
Electronic throttle command
Thermostat command
Canister purge command.
Diesel
Glow plugs
High pressure regulation
Exhaust gas valve.
Safety modes
A limp-home mode is defined and corresponds to a specified mechanical position (without
electrical control) under fault conditions. It is activated when the monitoring (see Section 2.1.5.2.4
Protection strategy) detects a fault and after several resets of the microcontrollers have occurred
without an effect (i.e. the disappearance of the failure).
For other cases such as the loss of an accelerator pedal contact a management mode is
implemented at the application level. In the case of this type of failure, a local degraded mode is
defined such a constant engine speed.
Gearbox control unit
The following are examples of the different functions that are implemented on an automatic
gearbox controller:
Drive position
Transmission ratio control
Clutch control
Gear position
Mechanical monitoring
System description
The number of ECU variants is still high depending on the type of gearbox, automatic or semi-
automatic, and the engine used. This diversity is lower than for the engine control units with less
than ten ECUs to manage (for example at PSA) but the number of software versions to manage is
still higher than one hundred.
The architecture of the ECU is a two-chip design for the semi-automatic gearbox (single processor
for the automatic gearbox) with a different dimensioning of the microcontroller and the power
stages. In this area the main processor is typically a 16 bit device (a few have a 32 bit device) with
a second 8-bit processor (see Section 2.1.5.2.4 Protection strategy) for the semi-automatic
gearbox. The external clock can vary from 16 to 40 MHz, the Flash size from 192 kB to 1 MB, (an
EEPROM space of few kB is needed), the RAM size from 4 kB to 16 kB, and the smallest cycle
time is around 2 ms for a servo-control basic function.
5.8.2004 Version 1.0 37

The power consumption of the ECU is under 1A. However, the power stage can control between
4 A to 30 A.
Sensors
The number of inputs is around 10 analogue sensors (up to 20 for a semi-automatic gear box) and
10 logical inputs, for example:
Selector level
Engine speed
Engine torque
Oil temperature
Oil pressure
Throttle
Kick down
Brake contact.
Actuators
The number of outputs (commands) is more than 10 (both high-side and low-side outputs), such
as:
Torque converter
Shift lock
Clutch actuator
Gear shift actuator
Start-up interlock.
Safety modes
Several critical functions are identified where safety concepts are applied (see Section 2.1.5.2.4
Protection strategy).
As for the engine control unit, a limp home mode is defined and corresponds to a specified
mechanical position under fault conditions (without control). For the automatic gearbox it
corresponds to a gear position and for the semi-automatic gearbox it corresponds to an open
clutch.
2.1.5.2.3 Software in the powertrain domain
In the powertrain domain OSEK is the emerging standard for operating-system software with a few
examples of its use in series production. Many suppliers have their own solution for the operating
system that can be adapted to (or be compliant with) to the OSEK standard. For the
communication layer, OSEK COM and OSEK NM are the standards provided by Tier 2 suppliers,
integrated by the component suppliers and so used in this domain.
A complete description of the software OSEK OS, COM & NM is given in the Standards section
(2.1.5.7).
2.1.5.2.4 Protection strategy
Several automotive companies, especially in the powertrain domain, apply safety

recommendations (based on the VDA concept) to the engine control unit and the gearbox unit with
the objective to provide fail-safe ECUs. These recommendations impact the software and also the
5.8.2004 Version 1.0 38

hardware. The main microcontroller is supported by a monitor unit (a small microcontroller or a

state machine) that acts as an intelligent watchdog. In this domain the fail-safe approach is
between the dual system and the simple watchdog. It is very specific to the operation of the
application even if finally some bases can be considered as generic or standard.
These recommendations are generic rules and are based on a concept that is described with three
layers and consists of safety monitoring that is internal to the ECU.
Layer 1: secured function (or process on critical functions)
This layer corresponds to the application software that manages the critical functions.
A part of the reliability requirements of these functions is to reinforce the functional behaviour of
the system. These requirements often consist of modules that check inputs (e.g. signal range) and
detect critical situations of actuations and the vehicle status (as control and supervision functions).
Fault reactions at this level usually invoke limp home functions.
Layer 2: process monitoring
This layer represents the software modules necessary to monitor (supervise) the critical functions.
Usually these modules are simpler redundant functions of the critical functions. They compare the
results and they take the final decision (actuation or not), plus a simple check on the background
of the main function.
Note: Level 1 and Level 2 are primarily implemented in the main microcontroller.
Layer 3: processor (or microcontroller components) monitoring
This layer represents the modules necessary to monitor the hardware of the ECU (ROM, RAM,
instructions, tasks, monitor unit etc.) Fault reactions at this level usually cause the engine to shut
down.
TCU
Redundant inputs MC
ADC Control Function Y

Redundant DRI Actuator
Analogical Signal
Check
Control Function Y (Process) Monitoring
Processor Monitoring
Program Flow / Instruction Set / Memory
Function
Level 1
Process Monitoring Question Answer Reset

Level 2
Processor Monitoring
Level 3 MU
ADC Evaluation Processor Monitoring
Error
Figure 15: Example of the safety layers in a powertrain ECU

These layers have a decreasing priority, for instance Layer 2 can cancel the control of a function in
Layer 1 if the checked conditions are not fulfilled.
Gearbox ECU example
With an actual example for a gearbox ECU, Layers 2 and 3 are described below in more detail:
Level 2
This layer (re-) implements the critical functions with the most important variables and much
simpler algorithm than Level 1. For example the function of Level 2 will calculate only whether the
5.8.2004 Version 1.0 39

principal conditions are met to control the actuator. A comparison of results between Level 1 and
Level 2 is made. If there is a difference, only the result of Level 2 is taken into account. So Level
2 is used to avoid an unhappy decision of Level 1.
Therefore in the case of an engine or a gearbox control, the instructions for engine torque or
actuators are calculated 2 times by 2 different algorithms.
This layer also implements the detection of an A/D converter failure. With this scheme, an
analogue signal with little dynamics is acquired at the same time on the main microcontroller and
on the monitor unit and the results of the conversions are exchanged between the two units.
Level 2
This corresponds to an execution test of the instructions of the function: the main microcontroller
sends constant vectors of the input data of the critical functions, adds all the results and sends it to
the monitor unit for a (static) comparison.
Level 3
This level typically contains the following functions:
Test of the RAM and the ROM by the two microcontrollers.
Mutual test of the software versions by the two microcontrollers,
Management of a dependable serial communication interface
between the two microcontrollers.
MC - Main Controller
Copy of Process Monitoring
ROM-Test RAM-Test Process Monitoring
Instruction Set Test
ROM-Test Program Flow Monitoring
Level 2
AD Value
SW-Version Predrive
RAM-Test
Level 2 Timeout/Checksum/Command/Interface
SPI COMMMUNICATION
Timeout/Checksum/Command
Value
A/D Predrive
SW-Version
ROM-Test
Instruction Set Test Program Flow Monitoring
RAM-Test
MU - Monitoring Unit
Processor Monitoring Process Monitoring

Level 3 Level 2
Figure 16: Processor monitoring on an ECU of the powertrain domain
2.1.5.3 Analysis of chassis domain
2.1.5.3.1 Architecture in the chassis domain
Number of ECUs
5.8.2004 Version 1.0 40

In the chassis domain, there are typically only a few ECUs, between 1 and 6. However, if you look
at the very-low-end of car segments, there can be no ECUs in the chassis domain at all. In low-end
vehicles, there is normally at least one ECU, i.e. for the anti-skid system (ABS).
In this analysis, the Volkswagen Golf V is taken as an example of the typical version with an
average number of ECUs in the chassis domain, i.e. 2. These are the Braking System ECU (ESP)
and the Electrical Power Steering (EPS) ECU. As can be seen, there is no dedicated chassis Bus
system and the control systems related to chassis functionality are represented by a brake ECU
and an ESP cluster (Figure 17).
Figure 17: Electronic architecture of Golf V series
The S-Class from DaimlerChrysler and the BMW 7 series are taken here as the typical vehicle
version with the maximum number of ECUs. In the S-Class there are 5 main ECUs in the chassis
domain, which are the Electronic Stability Program (ESP), the Active Body Control (ABC), the
Adaptive Damper System (ADS), the Tyre-pressure Control System (RDK) and Distronic (DTR).
The EWM (Electronic Selection-level) could be view as a part of the chassis or the powertrain
domain.
Looking at the topology of the BMW 7 series, you can find that there is no dedicated bus system
for the chassis systems. On the powertrain CAN-C bus there are several ECUs that either
contribute to the powertrain regulation or to chassis control systems. In Figure 6 you can see these
ECUs (blue boxes represent extra features, green boxes represent standard equipment), which are
the adaptive cruise control, active roll stabilisation, dynamic stability control, electronic
transmission control, electromechanical parking brake, digital diesel/engine electronics, adaptive
light control, electronic damper control, and rotational speed sensor (which is not an ECU).
5.8.2004 Version 1.0 41

Diagnostic
Access
Central
Gateway
SZ-
Vehicle ACC
DWA AHM MMI-GT CAS Steering DDE 1
Centre Module
Column
DME 1
1-Axle- A-Pillar A-Pillar
PDC ASK COMBI TM DD TM DP ARS
Air Spring left right
DDE 2
SZ-MK Antenna B-Pillar B-Pillar
SZ-MK MMC TM DDR TM DPR SIM DSC
Fond tuner left right DME 2
Chassis
Video SM SM Seat
RDC Integration CDC Seat Driver EGS ALC
Module Driver Passenger Passenger
Module
Rain SM SM Door Door

SHD NAVI KH_INT EMF EDCK
sensor Driver Passenger Front left Front right
Wiper Voice Input Power

LSZ Amplifier HKL Seat rear Yaw Rate
Module System Module
Sensor
IHKA Controller TEL-IF
Standard
SH/ZH Equipment
Optional
Equipment
K-CAN MOST K-CAN Periphery byteflight PT-CAN

System
Figure 18: Electronic architecture of BMW 7 series

Another example of a luxury cars electronic architecture is shown in Figure 19. The green line
represents the chassis/powertrain high-speed CAN which connects motor and transmission
electronics, safety components and the airbag system with the gateway. Also attached to this bus
are chassis systems, such as the electronic parking brake, continuous damping control, adaptive
frontlighting system, beam width control, and adaptive cruise control. Information exchange can
not only take place between the gateway and the components but also between components.
Figure 19: Excerpt of electronic architecture of Audi A8
5.8.2004 Version 1.0 42

Communication
In todays vehicles no dedicated bus systems for the chassis domain exist. Typically, the chassis
ECUs are connected to the Powertrain CAN with the high-speed CAN of 500 Kbit/s. Usually there
is only one centralized gateway from Powertrain CAN to CAN Comfort.
Conclusion
In order to assess the state-of-the-art hardware and software in the chassis system, it is important
to first examine what the purpose of electronic systems in this domain is. Altogether, it can be
identified that all chassis systems should either improve comfort, improve vehicle safety, ease
mechanic constructions by using electronic intelligence, reduce weight of conventional systems,
reduce cost compared to conventional systems, or increase reliability and quality of the vehicle.
Following these goals, future applications in the chassis domain will encompass robust and fault-
tolerant systems for longitudinal, lateral and vertical vehicle dynamics. These systems require
control loops that are distributed over several ECUs, synchronous and deterministic system
behavior, and high system availability. Nowadays and in the near-future, the most commonly used
architectural elements will be CAN and Flexray as bus systems, OSEK/OSEKtime as the operating
system, and OSEK-COM/FTCom as communication software. Today there is no dedicated bus
system in the chassis domain. Chassis and powertrain ECUs share the same high-speed CAN bus
in order to fulfill their real-time tasks. In the near future in the luxury class Flexray will probably be
introduced due to rising communication requirements between the components.
2.1.5.3.2 Hardware in the chassis domain
In order to give an overview of the hardware in the chassis domain that is commonly used, we
have taken ESP, EPS and ACC. The first two are widely-deployed systems whereas the latter is an
example of a rather recent and complex system that can typically be found in high-end vehicles.
These examples were chosen to show a common structure and principle.
Electronic stability program
The Electronic Stability Program (ESP) is a regulation system in the brake system and powertrain
which prevents uncontrolled sideways vehicle movement. The ABS prevents the wheels locking
when braking, ASR helps avoid wheel spin when accelerating. ESP ensures that the vehicle does
not become unstable or veer off course when steering.
ESP further improves on the advantages of ABS and ASR regarding active safety in the following
ways:
active support for the driver even in lateral dynamically critical
situations
advanced driving stability; directional stability in critical conditions in
all operational states such as full and partial braking, drive,
deceleration and load change.
advanced driver stability even with extreme steering manoeuvres
(fear and panic reactions), and therefore drastic reduction in risk of
skidding
improved vehicle behaviour also in critical situations and therefore
predictive regarding the limits of the drivers experience.
In the ESP ECU several different functions are realised:
Electronic Braking-force Distribution (EBV)
Transmission-slip Control (ASR)
Anti-skid System (ABS)
Automatic Stability Control (ASC)
5.8.2004 Version 1.0 43
Motor Drag-torque Control (MSR)

Dynamic Brake Control (DBC)
Concerning Brake Control (CBC)
Hydraulic-Brake Assistant (HBA)
Automatic Differential Brake (ADB)
Brake Assistant (BA)
System description
One example of an actual ESP system is the MK60-Braking Control generator from Continental
Teves. It consists of an integrated electronic control with redundancy concept and two-chip
design.
The microprocessor of the ECU is a Texas Instrument Processor with 44 MHz, 512 KB Flash-ROM
and a cycle time of 10 ms.
Sensors
The sensors of an ESP system are listed as the following:
Wheel rpm sensor
Residual acceleration and vehicle rotational sensor
Steering angle sensor
Brake pressure sensor
Brake pedal state sensor
Actuators
The hydraulic unit is an ESP MK60si with integrated pressure and temperature sensor, including
hydraulic units for all the wheels, BAS-brake assistant.
Adaptive Cruise Control
The Adaptive Cruise Control (ACC) is an enhancement of the traditional cruise control. The basic
functions of Adaptive Cruise Control (ACC) are based on conventional vehicle speed regulations
(cruise control), which maintains a speed specified by the driver. ACC can furthermore alter the
speed through automatic acceleration, deceleration, or braking to adapt to changing traffic
conditions. This system thus permits the vehicle to maintain a distance from the preceding vehicle,
dependent on speed.
The automotive systems involved in the realisation of the ACC functionality include motor
management ECU, radar sensor control unit, brake functionality by ESP/ASR, central display unit,
and wheel and acceleration sensors.
System description
The ACC sensor emits radar signals and receives the backscatter reflected by objects. It takes n =
3 send / receive lobes with every 3 of an opening angle. From the signals received, the distances
and relative speed to target objects are calculated using signal propagation delay and by means
of Doppler-shift respectively. The ECU receives the data which has been pre-processed by the
radar sensor and analyses this. Using this information, the ECU interprets the current traffic
situation and calculates the response needed from the engine, brakes, gears and any visual or
acoustic warnings. Should the vehicle approach a slower vehicle, the ACC system reduces the
speed to an extent that the required distance from the preceding vehicle is maintained. The ACC
system communicates using high-speed CAN with the motor, gearbox and ESP ECU.
For the sake of comfort, the braking action is limited to a deceleration of a=2m/s2 (around 20% of
the maximum possible acceleration).
5.8.2004 Version 1.0 44

Sensors
The most important part of the ACC is the radar sensor, which measures the distance, angle and
speed difference to the car in front. A typical ACC radar sensor uses a 3-ray 77 GHz Pulse-
Doppler with an average sending power of 200 W and a measuring distance of roughly 150 m. It
can measure the distance to objects in front of the vehicle with an accuracy of 1 m. It is connected
to the high-speed CAN.
Actuators
The actuators with which the ACC ECU communicates are
Motor (engine) ECU
Gearbox ECU
ESP ECU
Protection strategy
Protection strategy is of vital importance for the safety-critical ECUs used in the chassis domain,
which should have some characteristics which enable them to deal with possible faults. Two main
requirements are given for fault-tolerant systems: safety and availability.
Fail-safe ECU
The requirement for fail-safe ECUs is as follows: All critical faults have to be detected and
mitigated, e.g. by switching the ECUs to a safe state. Theoretically, no ECU component
characteristic which is 100% fail-safe can be produced. In practice, with the common fault-
recognition strategies, very high rates of fault-recognition can be achieved.
There are a variety of different concepts to realise fail-safe ECUs. Two of the most common
concepts are presented here (see Figure 20).
Single processor system with watchdog: The fault recognition in
a single processor system with watchdog is realised by software and
hardware in an external observer watchdog, which switches off the
processor power or resets the processor in case of failure.
Dual system with two processors: In a dual system the same
software runs in two identical processors. Alternatively, the system
can also be realized with different processors and software. Both
processors can set the ECU in a fail-safe state.
Single Processor with Watchdog Dual - System
Actuators Actuators
Application - Watchdog Application - Application -
Processor Processor Processor
Sensors Sensors
Comm. - Power supply Comm. - Power supply

Controller Controller
Data Bus Data Bus
Figure 20: Realization of fail-safe ECUs

Both concepts have pro and cons. Compared to a two processor system, a single processor
system with watchdog is cheaper as regards the material cost, with identical performance. The
disadvantage of the single processor system is the development cost and validation of the
observing system, so this cost advantage of the second concept is only achieved if developed on a
large scale.
5.8.2004 Version 1.0 45
Fault-tolerant ECU
Nowadays there is no real fault-tolerant automotive ECU in practice. From other domains (e.g.
aerospace) there are two common concepts under the assumption of one-failure-tolerance (as
shown in Figure 21).
The Dual-Duplex-System is realised with two duplex-units, each of them fail-safe, that is to say,
when there is a failure in one system, it is switched off. The ECU itself will continue to operate with
the second unit.
A typical Triplex System is realised with 3 processors, which operate in parallel, and the decision is
carried out using the voting-principle (votes out of 3).
Dual-Duplex-System Triplex System
Duplex Unit A Duplex Unit B

Application - Application - Application -
Appl.- Appl.- Appl.- Appl.- Processor 1 Processor 2 Processor 3
Proc. 1 Proc. 2 Proc. 3 Proc. 4
Comm. - Comm. - Comm. - Comm. -

Controller Controller Controller Controller
Data Bus Data Bus
Figure 21: Realization of fault-tolerant ECUs
2.1.5.3.3 Software in the chassis domain
In this paragraph a description of the existing and emerging standards of the Software
Implementation Framework in the chassis domain is given.
Figure 22 shows the basic building blocks of the chassis domain (as worked out in the EAST
project). However, the middleware layer has not yet been used in serial product.
Standardisation OSEK OS / OSEKtime OS
driven by: Application
OSEK Middleware
OSEK KWP 2000 CCP

FTCom (ISO 14230-1..4) (ASAM
OSEK ASAP) I/O Library
HIS NM (Hardware Abstraction Layer )
OSEK TL:
(ISO 15765-2)
DiagOnCAN
EEprom I/O
others Device Driver (FlexRay,TTCAN, CAN, LIN) ...
Driver Driver
Figure 22: Basic building blocks of the chassis domain

A complete description of software structure (OSEK OS, OSEKtime OS, ) used in the chassis
domain is given in the section on standards (Section 2.1.5.7).
2.1.5.4 Analysis of body domain
5.8.2004 Version 1.0 46

2.1.5.4.1 Main characteristics of body domain
In todays architecture, as electronics gets cheaper and integrates more and more power
elements, it is becoming more common to distribute body electronics, because power is better
handled, (less losses and risk), monitoring can be done at the electronics end, software is
distributed and simplified, and because size is better distributed.
Nevertheless, hierarchy must be kept and main control has to exist for safety reasons. But it can
be split into two or three major modules: the Smart Distribution Nodes (SDN). Normally one SDN is
defined for engine management, (ESDN), a second one, (main, CSDN), for cockpit, and a third one
for the rear area, (RSDN). This third one may be integrated in the CSDN if there are very few
elements to manage in this rear area.
We have to differentiate CSDN from other SDNs like engine or rear ones. The CSDN usually
includes the main gateway and can have redundancy of systems, (microcontroller, limp home),
to ensure safety of the electronic system. CSDN carries only a small number of power loads.
ESDN and RSDN are usually more devoted to the control of big loads (cooling fan, wiper) and/or
communication with local buses. Therefore, they have a lot of protection related to the power
loads. In the near future, with 42V/14V architectures, these SDNs will probably include the DC/DC
converters. Therefore, the CSDN is left as the main brain of the vehicle with optimised processing
speed and safety, although it may mean redundancy of components. Cost optimisation comes
when considering that this module can easily be used in several kinds of vehicles.
Therefore, functions like internal or external lighting, door features, seat control, etc. are being left
for other peripheral units, leaving energy and power management, central safety control, (alarms),
or gateways for SDNs. When a local bus, such as LIN is used, the SDNs are usually the master of
the local bus. Also, all SDNs can have reduced operation of distributed functions in case of other
modules breakdown or communication loss.
Today SDNs can be characterised with a 16 bit microcontroller with no more than 256 Kbytes of
Flash memory. A special case is the SDN with Gateway functions or equivalent, (i.e. BCM). For
these modules speed is a must, together with redundancy or ensuring maximum protection against
possible failures. For these modules the microcontrollers will have 16 bits, or even 32, with
memory size up to 512 bytes. There may also be two microcontrollers, one dedicated only to
gateways or to which is redundant in primary elements.
The SDNs have an operating system which fully implements OSEK. In some cases (low-end cars),
OSEK in not implemented and only a scheduler with network management is implemented.
As regards small electronic modules like those for seats, doors or smaller, (mirrors, wipers), the
tendency is to specialise the microcontroller peripherals. Only 8 bits are needed and memory sizes
up to 32 or 48 Kbytes, but as the module size is critical, and versatility is a need, the type of other
elements inside the microcontroller has to be carefully selected: one or two bus drivers, output
controllers, timers, voltage supply, RF
Another important point is the introduction of Diagnostics Services. The Diagnosis Services allow
the car configuration, the self diagnosis of the car while normal operation, the access to failures
information stored on a distributed way within the ECUs, read inputs, act upon loads for reparation
or testing...
The Diagnosis Master Tool should be capable of accessing all the diagnosis information stored in
the ECUs. It should also be able to request certain services to all ECUs even if they are not
connected to the same bus where the tool is. For this reason the complexity of the architecture
normally has a great effect on the electric diagnosis.
There are different possible solutions for this. One solution is the use of an independent bus
connected to all ECUs used for diagnosis. The advantage of this method is the independence of
the diagnosis data from the rest of application data, the reduction on diagnosis complexity and the
reduction of the bus load.
5.8.2004 Version 1.0 47

Another solution is to use the already existing buses for diagnosis. This means that the SDNs act
as gateways between the diagnosis bus (also used for application) and the sub-buses. In the case
of automotive buses normally the standard protocols defines how the gateways should behave. If
the Architecture Complexity splits the functionality in sub-buses more and more then more gateway
functionality will be required for diagnosis. The ECU acting as a gateway is the diagnosis master
for the sub-bus.
2.1.5.4.2 Example engine smart junction box
As an example, consider a typical module in this domain: the Engine Smart Junction Box (E-SJB).
This module controls several loads such as Lamps (Interior and Exterior), Door Locks, Cooling
Fan, Wipers, Fuel pump, Washer pump, Tailgate and Horn, among others.
This module also acts as a gateway between the High-speed CAN (500 kbps) and a fault-tolerant
Low-speed CAN (125 kbps). It includes another Low-speed CAN (125 kbps) for diagnostics and
two LIN-buses (1 for communication 1 for diagnostics). In both cases, this module is the master.
This module includes a Limp Home Mode (implemented using discrete circuitry) to protect micro
and voltage regulator failures and several fuses for overcurrent protection (next generation SJBs
have polyswitches and magnetic current sensing).
The microprocessor of this module is a 16-bit processor, 512 KB Flash-ROM, running at 16MHz.
The system has an operating system which fully implements OSEK. In low-end cars, OSEK in not
implemented and only a scheduler with network management is implemented.
The E-SJB acts as a central gateway for diagnostics, implementing KWP2000 through one
dedicated low-speed CAN-bus.
The system has very limited scalability capabilities, only one LIN-bus for extra option(s)
configurable at the end of production line. The next generation SJB will have enhanced plug and
play capabilities by modification of the serial bus.
2.1.5.5 Analysis of telematics/communcations domain
2.1.5.5.1 Main characteristics of telematics/commmunications domain
Telematics/Communication is one of the most recent emerging technologies within the automotive
industry and may be broadly defined as, "the interactive exchange of information, via voice or data,
over a wireless communications network".
Telematics allows a number of different interactive systems to be provided though three basic
capabilities:
1. Two-way communication capabilities (wireless)
2. Location technology (geographic position)
3. Computing platform for system control and interface to automotive electronic systems(s).
In todays vehicles, key capabilities are two-way communications (such as GSM) and location
technology (such as a global positioning system receiver GPS), which are combined with a
computer hardware and software to create the telematics system. The interface to other electronic
systems inside the car is usually provided too. This kind of system, as integrated in the BMW
Series7, can offer the following services (among others):
Navigation
Emergency call and roadside assistance
Vehicle security notification and stolen vehicle tracking services.
5.8.2004 Version 1.0 48

Travel information (traffic updates, parking availability, airline status),

Information (sports, weather, stock market updates and Internet
access)
Usually, the telematics services are provided by one / several modules integrated within the
multimedia / communication bus. The most common protocol used is MOST (Multi Oriented
Systems Transport). Usually, the Gateway from MOST to CAN is also present. A typical high-end
configuration is:
Navigation System
Phone Module
Video Module
Audio Module (Tuner / Amplifier)
Compact Disc Changer
Gateway (MOST to CAN)
Head Unit / Display
Voice Recognition / Microphone
Depending on the vehicle/OEM, some of the services are grouped in the same electronic module.
For instance, in BMW Series 7 the Display and the Gateway are in the same module.
More recently, Bluetooth is rapidly emerging as the electronics in-vehicle wireless networking
standard. Different European and Japanese OEMs are moving quickly to install the in-vehicle
Bluetooth architecture, while mobile phone and PDA makers are releasing Bluetooth-capable
handsets.
Some telematics systems create a wireless connection, using Bluetooth technology, to mobile
phones, allowing drivers to make and receive calls using the audio and / or voice recognition
systems. In this way, a Bluetooth-enabled cellular phone can be placed anywhere in the vehicle.
However, actual possibilities of this technology go far further.
Also, the capability to interface to the rest automotive electronic systems is rapidly enhanced. The
use of hierarchical architectures enables the implementation of on-board diagnostics systems, i.e.,
continuous supervision of all system characteristics. Among all the applications, we may highlight
the following ones:
Inputs / outputs state supervision (physical): switches
malfunctioning, detection of opencircuit / shortcircuit in loads
System state supervision (behavioural): system power mode, battery
monitoring
Network state supervision (timeout supervision): bus malfunctioning
Storing of fault codes: control modules store on nonvolatile memory
fault codes based on the information received from the sensors
If a fault code is identified, then a warning can be generated by a
control module
Detection of a potential problem within a core vehicle system can
occur prior to a potential failure; driver can be alerted in time to take
appropriate caution
For instance, Subaru B9 Scrambler uses Bluetooth to connect the Lamillion HEV battery and
several other systems as part of the Vehicle Data Monitoring System to continuously monitor
diagnostics and make it easy for a mechanic to quickly check battery status or driving records
without having to connect anything physically to the car.
5.8.2004 Version 1.0 49

2.1.5.5.2 Example: Bluetooth-CAN gateway
For instance, LEAR has presented an electronic control module for demonstration integrated in an
overhead console. This electronic module contains the following functionality:
GPS & GSM
Emergency Call
Vehicle Tracking
Bluetooth
Remote Keyless Entry
Navigation / Diagnostics / MP3 download using a PDA
Hands-free using a Mobile phone
LCD Display
Interior Lighting
The microprocessor of this module is a 32-bit RISC processor, 512 KB Flash-ROM, running at
24MHz. The Bluetooth module is a two-chip solution: one device for RF and another device
including the base-band and the implementation of the lower layers of the protocol.
In this module the Bluetooth protocol has been implemented based on the Serial Port Profile. The
Serial Port Profile is based on Radio Frequency COMMunications (RFCOMM). RFCOMM provides
serial port emulation, enabling Bluetooth support for serial data connections and it is integrated in
the Bluetooth component with the low level layers. The host microcontroller contains only the
application layer and communicates with the Bluetooth device through a series protocol.
This implementation allows the application layer and the rest of the stack to be completely
separated. If the SPP profile is installed on the host microcontroller, the particular application must
be always used in conjunction with the stack that it was developed for.
Application Layer
Application
Device Physical Interface Controller (UART)
Physical Interface Driver (UART)
Control Interface
SDAP Serial Port Profile (SPP)
Bluetooth Generic Access Profile (GAP) Audio

Device
SDP RFCOMM
HCI L2CAP
Base-band Control
Figure 23: Implementation of Bluetooth stack
2.1.5.6 Interdomain communication
5.8.2004 Version 1.0 50

The major trend in current vehicle development is the increasing number of electrical and
electronic systems in the cars. These systems are being introduced in order to give more
functionality, comfort, and safety to the customer.
Some of the trends (and challenges) that this evolution introduces are:
Higher number of decentralised control tasks
Higher number of monitoring and diagnostic tasks
Scalability and variety (High number of options and variants)
Higher communication bandwidth between control units and between
sensor/actuator units and control units
Integrated safety systems are adding an additional dimension to these general challenges,
because they connect domains (powertrain, chassis, body and telematics) which are only loosely
coupled in todays in-vehicle systems. Furthermore the environment sensing needs fusion of
different sensors to reach a high reliability for detection and classification of objects, and future
systems for accident free driven will extend the dependability requirement for electronic systems.
Adaptive headlight functionality is a good example of interdomain communication. Adaptive
headlight systems shift the headlamps spread to enhance visibility when cornering at night. In
order to compute the right angle, the inputs from sensors sending information on vehicle steering
angle, yaw rate, and road speed are used. In most cases, these modules are mechatronics located
near the lamp.
An appropriate algorithm controls the light beam according to the drivers commands, geared in
each case to the respective situation on the road and the speed of the car.
The information needed is generated on the powertrain bus. Usually, the adaptive headlight
systems are not connected directly to the powertrain because, in case of a frontal crash, the
powertrain bus may be severely damaged. In this case, is better to connect the adaptive headlight
modules to a separated CAN-bus.
Some OEMs propose to link the adaptive headlight system to the cars GPS satellite navigation
system and digital road maps that present all curve radii in the area covered, which will enable the
headlights to illuminate bends even before the driver turns the steering wheel.
2.1.5.7 Standards
2.1.5.7.1 Hardware protocols
CAN bus
CAN-bus is the world standard for Class B and Class C protocols [79].
Class B protocols body/infotainment have speeds between 10 Kb/s and approximately 125
Kb/s. Must support event-driven and some periodic message transmission plus sleep/wakeup.
Protocols used for Class B networks are listed in Table 1.
NAME: USER: USAGE: MODEL YEARS: COMMENTS:
ISO 11898 Europe Many 1992+ 47.6 Kb/s to 500 Kb/s in use
Fault-tolerant CAN Europe Many 2000+ ISO 11519 CAN
GMLAN (low) GM Many 2002+ GM only ; J2411 single wire CAN
GMLAN (mid) GM Infotainment 2002+ 95.2 Kb/s might be IDB-C
Ford MSCAN Ford Many 2004+ 125 Kb/s; J2284
DCX LSCAN Chrysler Many 2004+ 125 Kb/s; ISO 11519
J2284 GM,Ford, DC Many 2001+ 500 Kb/s; based on ISO 11898
J1939 T&B Many 1994+ Replacing J1708/1587/1922
5.8.2004 Version 1.0 51

Table 6: Class B protocols

The fault-tolerant Low-Speed two-wire CAN interface is becoming popular in most body
applications. CAN physical layer is slower and costs a bit more than an ISO 11898 interface, but
the system functionality is enhanced through bus fault detection capability.
Figure 24: Two-wire CAN bus logic levels
Figure 25: Fault-tolerant two-wire CAN bus logic levels

CLASS C protocols chassis/powertrain have bit rates between 125 Kb/s and 1 Mb/s. They
must support real-time periodic parameter transmission in the few milliseconds range.
ISO 11898 Europe Many 1992+ Various speeds of CAN
GMLAN (high) GM Many 2002+ 500 Kb/s; J2284
HSCAN Ford Many 2004+ 500 Kb/s; J2284
HSCAN Chrysler Many 2004+ 500 Kb/s; J2284
J1939 T&B Many 1994+ 250 Kb/s CAN
Table 7: Class C protocols

The main properties of CAN-bus protocol are:
Main characteristics
Event-triggered philosophy. The most standardised protocol in its
field.
Two version: CAN 1.2 and CAN 2.0 (HighSpeed: 1Mbps)
Configuration flexibility of the node set, because use functional
addressing.
Link layer: complete
MAC Sublayer
5.8.2004 Version 1.0 52

CSMA/CD-A (Carrier Sense Multiple Access with Collision Det.

using Arbitration).
Addressing (ID- identifier): Functional (the content of the
message defines the address) and its independent of the
physical situation.
Arbitration: The message priority is address-based (functional). If
appear a collision between multiple nodes (2 o more) the one
which have the highest priority (lowest address) wins the access
to the bus. The rest of nodes change to reception mode.
Frames types: Data, Remote (asking for a data), Error, Overflow.
LLC Sublayer
Automatic retransmission if erroneous frame is detect.
Physical layer
Signal levels: recessive (1), dominant (0).
Arbitration: dominant level forces the bus to "0" although rest of
nodes send "1"
Codification: NRZ with bit stuffing (good bandwidth efficiency).
Operation
A node can send a message if not coincide with other higher-priority
message.
The message can be read by any node connected to the bus.
However each node has its own frame filter, receiving only the
defined set of frames.
The instant when this message is sent is not synchronised with de
rest of the system.
Frames
Data frame
A node sends a data frame when have to communicate a event
(data) to the rest of the system. The frame is received by all
nodes with the suitable filter.
In-frame ACK response.
Remote transmission request
A node request to other node by using a remote frame (Same ID
than the data frame)
Error frame
When a node detects an error on the bus (CRC or bit stuffing
error) it sends immediately a error frame collisioning with the
current frame (data/remote).
The collision is detected by the transmitter and other receivers
and the transmitter repeat the frame again.
Overflow frame
When a node are not ready to receive, then it communicates this
to the system sending a overflow frame after the data frame
during the interframe-spacing
5.8.2004 Version 1.0 53
Maximum: 2 overload frames concatenated.

Real-time characteristics analysis
Maximum latency and jitter are no guaranteed.
A message with the second highest priority or less could never be
sent.
Not suitable for hard Real-Time applications.
Error detection/treatment
Detection: Losing bit synchronism: a clock has to be detected every
5 bit times or less
Detection: Frame format: CRC has to be correct.
Detection: In-frame ACK response, but only one ACK can be
detected.
Treatment: Automatic frame retransmission
Fault confinement: Based in 2 Local Error counters. Error
passive/active mode
Bandwidth efficiency
High bit codification efficiency (NRZ bit stuffing).
However, the bus load has to be low (25%) in order to get a high
probability of message transmission successfully.
System level properties analysis
Flexibility: Very high
Composability: Depend of the bus load
Dependability: Low.
Sleep/Wake-Up Mode.
LIN-bus
LIN-Bus is becoming the European standard for class A protocols [79]. Table 3 lists the status of
some of the most used automotive Class A protocols.
Most of these Class A protocols are UARTs. UART is very simple and economical to implement.
The transceiver is smaller and cheaper than those of other protocols. Today, the transceiver may
be integrated in the same integrated circuit with regulators, drivers, etc.
UART GM Many 1985 - 2005+ Being phased out
Sinebus GM Audio 2000+ Radio steering wheel controls
E&C GM Audio/HVAC 1987 - 2002+ Being phased out
I2C Renault HVAC 2000+ Used little
J1708/J1587/J1922 T&B General 1985 - 2002+ Being phased out
CCD Chrysler Audio/HVAC/etc 1985 - 2002+ Being phased out
ACP Ford Audio 1985 - 2002+
BEAN Toyota Body 1995+
UBP Ford Rear backup 2000+
LIN Many OEMs Body 2003+ LIN Consortium developing
Table 8: Some Class A protocols
5.8.2004 Version 1.0 54

The main properties of LIN-bus protocol are:

Main characteristics
Low cost, low speed (20kbps), Single wire.
Protocol can be implemented by software.
Scheme: master-slave. Master acts as scheduler.
Communication scheduling not defined. It must be defined and built
in the application localized in the master.
Physical layer
Bit-rate obtained by low cost RC oscillator and self-tuned by a
specific byte pattern contained in any frame (MAC/DLC layer
specification).
Codification: NRZ (Non Return to Zero) with clock synchronisation at
byte level.
MAC sub-layer
Frame format: two parts, header ("token") + response part (in-frame
response).
Addressing: Physical situation. Any node has a static address.
Master-slave model.
Master acts as scheduler, sending the "token" to the responder.
Slave addressed (or the own master) sends the response.
Never exist collision because all transference are controlled by the
master in a centralised way.
Bit-rate defined by self-synchronism
DLC sub-layer
Not specified, although protocol spec. recommends its existence
Centralised scheme of transmission
A scheduler should be implemented in the master
Real-Time characteristics
Latency constant and predictable. Low jitter.
Is possible if the master station has a suitable scheduling (TT) and
the messages have a known length or litter than a established
maximum value.
Error detection/treatment
Detection: Checksum (less reliable than CRC), parity bit, stop bit,
timeout.
The replying mechanism isnt implemented. It must be implemented
in the application.
Fault tolerance is not implemented.
System level properties
Composability: Very low. The cluster comm. management must be
established.
5.8.2004 Version 1.0 55

Dependability: Very low.

Flexibility: It will depend of the management adopted
Bluetooth
Bluetooth [81] supports application/link layer authorization, authentication, and encryption and is
able to connect to a large variety of devices (PDAs, computers...) at high data rates (1
Mbit/second). Bluetooth supports many simultaneous and private connections (hundreds of private
piconets within range of each other); supports different types of data used by mobile users (voice
and data); is low power and compact to support the small portable devices (such as PDAs).
Finally, semiconductor manufacturers are now introducing single chip CMOS radio giving a long-
term cost goal of $5.
The Bluetooth technology is divided into two specifications: the core and the profile specifications.
The core specification discusses how the technology works, while the profile specification focuses
on how to build interoperating devices using the core technologies.
The profiles describe minimum implementations of the Bluetooth protocol stack for typical
applications. Manufacturers can add to these, but each profile describes a minimum recipe for
building a particular type of device. Bluetooth profiles are built up in layers, with each profile relying
upon the layers beneath.
MOST
MOST [82] is a high-speed communication standard created by DCAG, Becker, and other
corporations. The configuration of the system is a combination of ring and star topology similar to
D2B. MOST is in production in multiple vehicle platforms from many automotive OEMs. MOST
Technology is royalty-free, so it incurs no additional costs.
The main characteristics are:
Plug and play; self identifying devices with auto initialisation
Dynamically attachable and re-configurable devices
Virtual network management including channel allocation, system
monitoring addressing and power management
Applications from x Kbps to 25 Mbps
High degree of data integrity with low jitters
Support of asynchronous and synchronous data transfer
Support of multiple masters
Supports up to 64 devices
Simultaneous transmission of multiple data streams such as control,
packet and real-time information
Devices can be constructed out of multiple functions
Low overhead due to embedded network management
Synchronous Bandwidth
Synchronous channels provide guaranteed bandwidth with no
buffering required
Up to 25 Mbps synchronous data throughput
Asynchronous Bandwidth
Variable asynchronous data throughput
Up to 15 Mbps asynchronous data
5.8.2004 Version 1.0 56

Dedicated control channel with more than 700 Kbps

Flexibility
Wide range of real-time channel sizes and packet sizes
Remote operation and flow control
Variable arbitration mechanisms
Protocol independent and object-oriented
Synergy with consumer and PC industry
Operates with or without PC
Consistent with PC streaming and Plug and Play standards
Low implementation cost
Suitable for implementation in cost sensitive peripherals
Optimised for use with low cost Plastic Optical Fibber
Uses low cost connectors
Highly integrated system-on-a-chip IC implementations available
IEEE 1394
IEEE 1394 [83] is an international standard, low-cost digital interface that will integrate
entertainment, communication, and computing electronics into consumer multimedia. Promoted by
IEEE, the main characteristics are:
A hardware and software standard for transporting data at 100, 200,
or 400 Mbps.
A digital interface-there is no need to convert digital data into
analogue and tolerate a loss of data integrity.
Physically small-the thin serial cable can replace larger and more
expensive interfaces.
Easy to use-there is no need for terminators, device IDs, or
elaborate set-up.
Hot pluggable-users can add or remove 1394 devices with the bus
active.
Inexpensive-priced for consumer products.
Scaleable architecture-may mix 100, 200, and 400 Mbps devices on
a bus,
Flexible topology-support of daisy chaining and branching for true
peer-to-peer communication.
Inexpensive-guaranteed delivery of time critical data reduces costly
buffer requirements.
Non-proprietary - There is no licensing problem to use for products.
Serial Bus Management provides overall configuration control of the
serial bus in the form of optimising arbitration timing, guarantee of
adequate electrical power for all devices on the bus, assignment of
which IEEE 1394 device is the cycle master, assignment of
isochronous channel ID, and notification of errors. Bus management
is built upon IEEE 1212 standard register architecture.
5.8.2004 Version 1.0 57

Automotive Qualified
There are two types of IEEE 1394 data transfer: asynchronous and isochronous. Asynchronous
transport is the traditional computer memory-mapped, load and store interface. Data requests are
sent to a specific address and an acknowledgment is returned.
In addition to an architecture that scales with silicon technology, IEEE 1394 features a unique
isochronous data channel interface. Isochronous data channels provide guaranteed data transport
at a pre-determined rate. This is especially important for time-critical multimedia data where just-in-
time delivery eliminates the need for costly buffering.
Much like LANs and WANs, IEEE 1394 is defined by the high level application interfaces that use
it, not a single physical implementation. Therefore as new silicon technologies allow high higher
speeds, longer distances, and alternate media (wireless?), IEEE 1394 will scale to enable new
applications.
Perhaps most important for use as the digital interface for consumer electronics is that IEEE 1394
is a peer-to-peer interface. This allows not only dubbing from one camcorder to another without a
computer, but allows multiple computers to share a given camcorder without any special support in
the camcorders or computers. All of these features of IEEE 1394 are key reasons why it has
become the A/V Digital Interface of Choice.
1394b [83] is a significant enhancement to the basic 1394 specification that enables speed
increases to 3.2 Gigabits/sec, supports distances of 100 meters on UTP-5, plastic optical fibber
and glass optical fibber, and significantly reduces latency times by using arbitration pipelining. It is
fully backwards compatible with the current 1394-1995 and 1394a specifications. 1394b is an
important step forward in increasing the performance and simplifying the implementation of 1394
on PCs, and, with its long-haul capabilities, makes 1394 the convergence bus between PC
products, consumer electronic systems, automotive and home networking.
FlexRay
A consortium including BMW, DaimlerChrysler, GM, VW, Bosch, Motorola / Freescale, and Philips,
is developing FlexRay for chassis and powertrain control in cars [84]. In total the consortium is
supported by more than 70 companies that are organized in 4 different membership shells.
Overview
Flexray defines a communications system consisting of the specification of a communications
protocol and the specification of an appropriate physical layer. FlexRay provides scalable fault-
tolerance to enable an economic design of distributed non-fault-tolerant systems as well as
distributed fault-tolerant systems.
FlexRay supports different topologies for interconnection such as star-based ones and bus-based
ones, as depicted in the figures below. In both cases, duplication of the interconnection is optional.
The star configuration of FlexRay can also be deployed in distributed configurations where
subsystems are connected by hub-to-hub links.
5.8.2004 Version 1.0 58

Figure 26: Topology of a FlexRay network using active stars
Figure 27: Topology of a FlexRay network using passive bus

A distributed system of FlexRay nodes can be also designed by combining the active star and the
passive bus approach. Several nodes may be connected to a branch.
Function
In order to satisfy the diverse communication requirements FlexRay provides periodic data
communication with bounded latency and small latency jitter as well as ad-hoc data
communication for efficient utilization of bandwidth to satisfy varying bandwidth requirements at
run-time.
Within FlexRay communication occurs in recurring communication cycles. Within each of such a
communication cycle a static communication segment is provided for bounded latency data
communication, while a dynamic communication segment is provided for ad-hoc data
communication. The static communication segment uses a TDMA-based communication scheme.
Within the dynamic communication segment different nodes may compete for bandwidth using a
priority-driven mini-slotting scheme. FlexRay is targeted at a bit-rate of 10 Mbit. Support for further
bit-rates is under ongoing consideration.
The communication cycle is executed in a synchronous way by means of a time-base within each
node that is synchronized among all nodes. To maintain synchrony even in the event of faults the
synchronization algorithm used by FlexRay is designed to be fault-tolerant. Generally speaking
the synchronization algorithm considers the transient/permanent fault class as well as the
5.8.2004 Version 1.0 59

symmetric/asymmetric fault class. The synchronized time-base is made available to the

application to enable synchronized operation of the overall system.
The temporal characteristics of the communication cycle are defined at design time and stored
statically in each node. Nodes that require greater bandwidth and those that need shorter update
intervals for messages are assigned more slots than those that require less bandwidth or those
that allow for longer up-date intervals for messages. The nodes are not, however, provided with
the overall communication matrix and, in particular, the communications protocol does not require
knowledge of the physical identity of senders of messages. This strategy allows functions that are
spread across multiple nodes to be integrated into a single node and functions that are provided by
a single node to be separated into multiple nodes after deployment of the system, in a way, that is
fully transparent to the remaining nodes in the system. This is beneficial for migrating nodes
across different clusters that have a different functional partitioning within the cluster.
Online resources
The FlexRay specifications can be obtained from the FlexRay consortium web site at
http://www.flexray.com [84].
2.1.5.7.2 Software: operating systems
OSEK OS
Overview
The OSEK [85] operating system is the most commonly used operating system for automotive
ECUs, which provides a pool of different services and processing mechanisms. It can be built
according to the user's configuration instructions at system generation time.
Four conformance classes are available to satisfy different requirements concerning functionality
and capability of the OSEK operating system. Thus, the user can adapt the operating system to the
control task and the target hardware. The operating system cannot be modified later at execution
time.
Applications which have been written for a certain conformance class have to be portable to OSEK
implementations of the same class. This is ensured by a definition of the services, their scope of
capabilities, and the behavior of each conformance class. Only if all the services of a conformance
class are offered with the determined scope of capabilities, the operating system implementation
conforms to OSEK.
Function
Task management
Activation and termination of tasks
Management of task states, task switching
Synchronization
The operating system supports two means of synchronization
effective on tasks:
Resource management and
Access control for inseparable operations to jointly used (logic)
resources or devices, or
for control of a program flow.
Event control: Event management for task synchronisation.
Interrupt management: Services for interrupt processing
Alarms: Relative and absolute alarms
5.8.2004 Version 1.0 60

Intra processor message handling: Services for exchange of data

Error treatment: Mechanisms supporting the user in case of
various errors
OSEKtime OS
Overview
The OSEKtime operating system provides the necessary services to support distributed fault-
tolerant highly dependable real-time applications (e.g., start-up of the system, message handling,
state message interface, interrupt processing, synchronization and error handling).
Function
Architecture of an OSEKtime system
The OSEKtime operating system is responsible for the on-line management of the CPUs
resources, management of time and task scheduling. The FTCom layer is responsible for the
communication between nodes, error detection and fault-tolerance functionality within the domain
of the communication subsystem. Application software and FTCom layer are executed under
control of the operating system. The OSEK Network Management component describes node-
related (local) and network-related (global) management methods and is optional.
Main functions
Time Triggered Task Activation: Task activation is performed by
the OSEKtime dispatcher as a result of OSEKtime dispatcher
ticks (TT interrupts). OSEKtime dispatcher invocation events are
defined in an offline generated dispatcher table.
Deadline Monitoring of Tasks: The OSEKtime operating system is
responsible monitoring of the deadlines of tasks. If a deadline
violation is detected the operating system will shut down.
Synchronization to a Synchronization Layer: Each ECU operates
with a local time that increments according to the local clock
source. If a global time is available from a Time-Triggered
Communication System a synchronization mechanism will be
executed.
OSEK OS inside the OSEKtime OS with lower Priority: Beside
the OSEKtime subsystem it is possible to include a full
OSEK/VDX OS subsystem in the kernel.
Online resources
[85] Specification available at www.osek-vdx.org
OSEKtime FTCom
Summary
The fault-tolerant communication layer (FTCom layer) is responsible for the interaction between
the communication controller hardware and the application software. It provides the necessary
services to support fault-tolerant highly dependable real-time distributed applications (e.g. start-up
of the system, message handling, state message interface).
Function
Fault-tolerant communication
The OSEKtime FTCom layer is built in accordance with the user's configuration instructions
at system generation time.
Services of the FTCom layer
Global message handling
5.8.2004 Version 1.0 61
Replication and agreement

Message filtering
Communication controller communication network interface
(CNI) access via CNI driver (incl. connections to multiple
communication media, e.g., gateways)
Start-up
Time service and optional external clock synchronization
Layered model of OSEKtime FTCom architecture
The layered model of OSEKtime FTCom system is divided into two subsystems:
Firstly, the Fault Tolerant Subsystem that contains fault tolerant
mechanisms; and
Secondly, the Communication Subsystem that is responsible for
the communication between distributed components.
FTCom is also divided into layers

Application Layer:
Provides an Application Programming Interface (API).
Message Filtering Layer:
Provides mechanisms for message filtering.
Fault Tolerant Layer:
Provides services required to support the fault-tolerant
functionality:
Provides judgement mechanisms for message instance
management.
Supports a message status information.
Interaction Layer:
Provides services for the transfer of message instances via
the network:
Resolves issues connected with the presentation of a
message instance on different hosts (e.g. different byte
ordering).
Provides a message instance packing/unpacking service.
Supports a message instance status information.
The CNI Driver is not part of FTCom. It provides services for the transfer of FTCom frames via
network:
Resolves FTCom CNI frames presentation issues.
Supports a FTCom frame status information.
Deals with a specific CNI access scheme of a particular
implementation of the communication hardware.
General limitations
Constraints on the FTCom and the underlying communication controller are:
5.8.2004 Version 1.0 62

The fundamental basis for real-time and time-triggered systems is

a globally synchronized clock with sufficient accuracy. The
globally synchronized clock must be accessible and it must
provide means to generate programmable time-interrupts.
Error detection must be supported in the event of data corruption.
Additionally, the communication protocol must support the
detection of missing, late or early messages at the receiver(s)
and the senders.
Time-triggered, periodic frame transmission is assumed for all
messages handled by the FTCom layer. Other types of
transmission must be handled implementation specific.
Defined Worst Case Start-up Time: The communication system
must have a deterministic worst-case start-up time.
Online resources
OSEK NM
Overview
OSEK NM defines a set of services for node monitoring. Node monitoring is used to inform the
application about the nodes on the network. Thus the application can check with the appropriate
service if all stations required for operation are present on the network.
Function
Node monitoring/network management
Function:
Direct Network Management: Inform the application about the
nodes on the network => Application can check with the
appropriate service if all stations required for operation are
present on the network.
Logical Ring for Node Monitoring
Logical Ring over different networks possible
Detecting, processing and signaling of operating states for
network and node (state of a monitored node: node present,
node absent, state of a monitoring node: present or mute,
absent or mute)
Indirect Network Management:
Transmission: Determination of emitter states when
sending, by using transmission monitoring scheme
Reception: Determination of the set of receiver states by
using reception monitoring scheme: node i checks the
presence of all its source nodes by monitoring the
reception of a chosen cyclic frame per each remote
source.
Status Signal: Determination of the Network Interface
status by using controller indications for the
communication Data Link Layer
Operating modes
5.8.2004 Version 1.0 63

Function: Co-ordination of global operation modes (e.g. network

wide sleep mode)
NMActive NMPassive: in heterogeneous networks,
individual nodes can suspend their network communication
due to their specific requirements.
Each node own a silent mark which can be set an reset by
the application.
NMBusSleep - NMAwake: The NM controls the access to the
communication media on demand of the application. If the
application in all nodes do not require the communication
media, then the NM changes to the state NMBusSleep.
Each node owns a sleep mark, which can be set and
cleared by the application.
The NM maps the sleep mark into each ring message.
When the sleep mark is set NM prepares for notified and
network wide confirmed sleep mode.
The request for global NMBusSleep is set in a ring
message. At each node participating in the logical ring
this request for global sleep must be confirmed. The sleep
mode initiating node must wait for network-wide
confirmation of his request.
If the NM message has completely looped in the logical
ring then the request is confirmed by a ring message. The
transition is performed after a global delay.
General limitations
Only management of network states, and ECU states; no
application states.
The NM of a node detecting a failure cannot distinguish whether
the failed node is no longer able to communicate due to a line
fault or due to a complete failure, without additional support. Any
possible reactions, e.g. change over to redundant physical paths,
must be specified together with entire system requirements.
Online resources
2.1.5.7.3 Diagnostics
CAN Calibration Protocol (CCP)

Overview
CCP (Can Calibration Protocol) is a standard and low level software developed in the late 90s by
ASAP task force (Arbeitskreis zur Standardisierung von Applikationssystemen). CCP is now part of
the ASAM-MCD standard (Measurement, Calibration and Diagnosis) which defines interfaces for
the description and integration of control systems. This standard is held by ASAM Association for
Standardization of Automation and Measuring Systems created within the German car industry in
1991 and extended now to the transportation domain. ASAM provides standards for data models,
interfaces, and syntax specifications for a variety of applications (e.g. testing, evaluation,
simulation).
5.8.2004 Version 1.0 64

CCP is a CAN specific protocol, very popular for software development, test and calibration
purpose. It is implemented in widespread measurement and calibration tools such INCA (ETAS)
and CANape (Vector). Vector provides free of charge his CCP source code that can be
implemented in ECUs to communicate with its CANape tool. As calibration and test are identified
as general requirements for EAST middleware, CCP should be used as an existing standard.
Function
The CCP defines the communication of controllers with a master device using the CAN 2.0B (11-
bit and 29-bit identifier), which includes 2.0A (11-bit identifier) for:
Read and write access to various memory locations, variables
and data structures,
Download of calibration and measurement at the same time,
Flash programming,
Simultaneous handling of several ECUs.
The master device is a calibration, a diagnostic, a monitoring or a measurement tool issuing
commands to the controllers. Therefore, CCP may be used for the development and the test of
electronic control units, calibration regarding the controlled devices (combustion engines,
gearboxes, suspension)
Master device
CAN bus
Slave device Slave device Slave device
Figure 28: CCP controller hierarchy

Providing these functions the CCP may be used in the areas of
development of electronic control units (ECU)
systems for functional and environmental tests of an ECU
test systems and test standards for the controlling devices
(combustion engines, gearboxes, suspension systems, climatic
control systems, body systems, anti-locking systems)
on-board test and measurement systems of pre-series vehicles
any non-automotive application of CAN-based distributed
electronic control systems.
Limitations
CCP is CAN specific, this means there must be a CAN bus between the ECU and calibration or
test tool.
Online resources
[86] Definition by ASAM: Association for Standardisation of
Automation and Measuring Systems and ASAP: Standardization
of Application/Calibration Systems task force. Available as
freeware on Vector Website: www.vector-cantech.com
[87] Specification version 2.1-February 18th 1999 on ASAM
Website: www.asam.de
5.8.2004 Version 1.0 65

[88] Vector application note AN37-12, july 2001

Keyword Protocol 2000 (KWP 2000)
Overview
Keyword protocol 2000 was developed as an ISO standard mainly for diagnostic and ECUs
software downloading purpose in after-sales. At the beginning, this protocol was focused only on
the K line which is a specialized serial line on each ECU, dedicated for such after-sales
applications.
Nowadays, as the diagnostic on CAN has become an ISO standard, it is possible to take benefit of
the high speed CAN bus data rate to achieve the same operations and for example to download
several ECUs in parallel or to ask for the status of diagnostic data from an unique access point
(e.g. EOBD).
Function
Whether on K line or on CAN bus, the main services available on Keyword protocol 2000 are the
same:
Start/stop communication,
Start diagnostic session,
Data read: parameters, default codes
Data write: telecoding, software or calibration files downloading,
Input-output monitoring: test and diagnostic,
ECUs specific routine monitoring: default code erasing, test and
diagnostic.
All those features are used in the chassis domain.
Limitations
KWP 2000 specifies only the protocol, it is being used by car manufacturers in different ways to
achieve complex operation like software downloading with the result that there is no common
existing middleware but only specific implementations. Downloading and diagnosis are general
middleware requirements for the EAST project.
Online resources
[89] K-line: ISO 9141 Road vehicles -- Diagnostic systems --
Requirements for interchange of digital information (www.iso.org)
[90] KWP 2000 (Keyword protocol 2000): ISO 14230 Road
vehicles -- Diagnostic systems -- Keyword Protocol 2000
(www.iso.org)
[91] Diagnostic on CAN: ISO 15765 (www.iso.org)
[88] Vector Application Note: AN37-12 July 2001
Transport protocol
Overview
The task of the transport layer is to transmit messages, which might be longer than the payload
segment of the used communication protocol. If messages do not fit into the payload segment of
the communication frame, they will be segmented by the transport protocol.
Today the ISO/TF2-transport protocol is mainly used for diagnosis applications in motor vehicle.
Most of all KWP2000 is used as a diagnosis protocol (currently: [ISO14230], near-future UDS
[ISO14229]).
Function
5.8.2004 Version 1.0 66

Task of the transport protocol is to transmit messages, which are generally longer than a CAN
message. If a message is very short, it is transmitted unsegmented.
Construction of unsegmented messages
Unsegmented messages are transmitted by a SingleFrame-message. SingleFrame messages can
have a length of maxframesize -1 data bytes at a maximum (normal addressing) respectively
maxframesize - 2 data bytes (extended addressing). There is no Flow-Control.
Construction of segmented messages
Messages, which do not fit into a SingleFrame are sent by a sequence of single communication
frames. The receiver is informed of the length of the whole message in the FirstFrame by the
sender. ISO/TF2 defines here a maximum length of 4095 for user data. The receiver answers by a
FlowControl. The receiver gives the BlockSize and the SeparationTime STmin to the sender in this
FlowControl. The BlockSize controls the number of ConsecutiveFrames, which might be sent by
the sender before waiting for the receivers FlowControl. The minimum value of the
SeparationTime STmin describes the minimum sending distance between two
ConsecutiveFrames, which can be processed by the receiver. The sender transmits the maximum
BlockSize ConsecutiveFrames after the reception of the FlowControl. It is not answered with a
FlowControl by the receiver, if all data has been transmitted, even if it would be its turn as a result
of the adjusted BlockSize in the course of the protocol.
Limitations
Message length limited to <5000 bytes
CAN-specific
Only point-to-point connection
Does not support multiple parallel connections from one ECU
Currently only underneath KWP2000
Online resources
[92] ISO/ WD 15765-2 Road Vehicles - Diagnostic Systems, Part
2: Network layer services. Date 1998-06-24 (www.iso.org).
[88] Vector application note AN37-12, july 2001
2.1.6 State of the art of tools
The V cycle is the perfect model for categorizing automotive tools according to the area in which
they are chiefly used [40]. In this document, the tools are classified to apply for certain categories
(see Figure 29), such as development tools, test tools, calibration and measurement tools, and
diagnostics tools.
5.8.2004 Version 1.0 67

Figure 29: Coarse outline of "V" cycle

Please note that the collection of tools described in this document is certainly far from being
complete. This is partly caused by the existence of grey areas, i.e. the relevance of a tool for this
collection could be questioned because the tool is occasionally used in the automotive domain but
does not necessarily have to be considered as a typical automotive tool. In this case, it depends
on the individual assessment of the reader whether the tool is automotive or not.
2.1.6.1 Taxonomy of automotive tools
2.1.6.1.1 Design tools
The purpose of a design tool is to (in the broadest sense) contribute to the description of ECU
software. In most cases design tools are accompanied by code generators that convert the
abstract functional description carried out by means of the design tool to source code. The latter
can be further processed and compiled to ECU-ready executable code.
Beside tools for the functional specification of automotive software this category is populated by
tools that support e.g. the configuration of the underlying RTOS or the communication middleware.
In addition, tools exist that concentrate on the mere definition of the data and variable content of an
ECU. By this means it is possible to automatically generate all data structures used in a type of
ECU. The actual behaviour of the ECU, on the other hand, is directly coded in (C) source code
according to this approach.
Please note that particular general-purpose modelling tools (like MATLAB/Simulink) are
considered in this document although they are far from being specially tailored for the automotive
industry. The importance of these tools for the design of automotive software, however, is so vital
that they should not be neglected.
2.1.6.1.2 Tools for calibration and measurement
Tools for calibration and measurement are used to fine-tune the behaviour of automotive software.
To be sure, these tools are not suited nor intended to change the functionality of the software
fundamentally but to adjust parameters to meet the actual vehicle behaviour.
5.8.2004 Version 1.0 68

Please note that the calibration of parameters is deliberately performed while the ECU is under
operation. By this means it is possible to observe the response of the ECU to even the slightest
change of parameters in real-time.
Please note further that calibration requires special technical arrangements on the ECU since
parameter values of ECU are typically located in a (in the broadest sense) ROM memory area.
This corresponds to the fact that in normal vehicle operation the values of parameters are
intentionally not supposed to change during run-time.
Furthermore, it is possible to measure the values of internal variables for the purpose of debugging
and/or function verification.
Tools for measurement and calibration share a common characteristic: it must be possible to
operate the tool in a vehicle while the vehicle is manoeuvred across a (in some cases difficult) test
track or even a public road.
Sine inside a car usually no space for a PC mouse is available, the tools are required to be fully
controllable by means of the keyboard. Some tools provide audible interfaces for providing
information for the user. In addition, there is a growing demand for other I/O devices such as e.g. a
head-up display of selected program outputs.
2.1.6.1.3 Test systems and HIL simulators
A hardware-in-the-loop (HIL) simulator is used to simulate the environment of an ECU as accurate

as applicable for testing the ECU before it is attached to the actual vehicle. By this means it is
feasible to test the behaviour of an ECU even if the vehicle for which it is targeted does not actually
exist.
Furthermore, it is possible to reproducibly emulate particular driving situations (e.g. -split
braking) without having to actually operate the vehicle.
Of course, HIL simulators to a large extend consist of hardware which is out of scope of this
document. The software part of HIL simulators, on the other hand, may be worth of having a look
at for completing the description of the tool landscape in the automotive market.
Please note that the usage of HIL simulators for safety-related systems is highly recommendable
since HIL simulators provide a realistic and platform for stress experiments and code coverage
analysis.
2.1.6.1.4 Tools for diagnostics
The main use of tools for diagnostics is to support probing production ECUs built into series-
production vehicles. The function of these tools is to describe the diagnostics-relevant information
contained in a specific type of ECU such that it is possible to configure a tester device in a
workshop.
The tester device is used to actually probe the ECU and e.g. retrieve the contents of the built-in
fault storage. Please note that the consideration of tester devices or software products that
emulate tester devices is out of scope of this document.
Another use case would be the specification of EOL programming for ECUs. By this means it is
possible to adapt the behaviour of a particular ECU to the type of vehicle (or maybe, the individual
vehicle) it is attached to.
2.1.6.1.5 Analysis tools
This category is populated by tools than contribute to the analysis of automotive software systems.
This could be, for example, the analysis of communication behaviour of a specific CAN bus.
5.8.2004 Version 1.0 69

Furthermore, tools for verifying the consistency of certain model descriptions used in the
automotive domain as well apply to this category
2.1.6.1.6 Process tools
The development of automotive software is tightly connected with the usage of process tools. The
latter are used to implement or support a particular development process.
Especially the provision of calibration data management (CDM) is of steadily growing importance
for the automotive software development.
2.1.6.1.7 Development tools
Although not typically developed for the automotive domain, development systems like compilers
and linkers are indispensable for the creation of automotive software. Please note, however, that a
large number of development environments for the typical microprocessor platforms used in the
automotive domain is available on the market.
The description of each and every relevant product is beyond the scope of this document.
Therefore, the selection of development environments referenced in this document is intended to
give some indications of popular development environments as well as some interesting features
(e.g. integrated MISRA checker, analysis of static stack utilization) concerning the design of
integrated safety systems.
2.2 Summary of items
In this section, a summary of each of the items examined is given.
2.2.1 ECE Regulation 10
Legislation
ECE Regulation 10 [3] is concerned with the Type Approval of vehicles with regards to
electromagnetic compatibility. It applies to vehicles and/or electronic subassemblies unless the
vehicle and/or subassembly and/or electrical/electronic system does not contain an electronic
oscillator with an operating frequency greater than 9 kHz.
The Regulation sets limits on emissions behaviour for all electrical/electronic systems (subject to
the previous statement) and on immunity behaviour for all systems that could affect the direct
control of the vehicle and its functions by the driver or as observed by other road users.
Whilst this Regulation now effectively applies to all electronic systems, some other Regulations
(e.g. Regulation 13 [4], Regulation 79 [6]) still contain earlier statements of performance with
regard to EMC. It can now be assumed that any approval authority would expect Regulation 10 to
be applied as the means of conformance with these requirements.
ECE Regulation 10 is implemented in European law as Directive 95/54/EC [12]. This Directive is
being updated and a new version will become effective at the end of 2005. ECE Regulation 10
should be updated in due course. Two significant changes to the updated vehicle EMC legislation
should be noted:
It will require that vehicle systems demonstrate immunity to the
wanted signals from radio transmitting equipment installed in the
vehicle
The definition of systems that must demonstrate immunity is
expanded to include:
5.8.2004 Version 1.0 70

Functions related to the direct control of the vehicle by

degradation or change in control functions (e.g. engine,
transmission, brakes, suspension, active steering, speed
limitation devices), or by affecting the drivers position (e.g. seat
or steering wheel positioning) or by affecting the driver's visibility
(e.g. dipped beam or windscreen wiper).
Functions related to driver, passenger and other road user
protection (e.g. airbag and safety restraint systems)
Functions which when disturbed cause confusion to the driver or
other road users (such as incorrect operation of external lighting,
wrong information from warning indicators, lamps or displays
related to the two previous groups of functions that might be
observed by the driver; acoustical disturbances e.g. incorrect
operation of anti-theft alarm or horn)
Functions related to vehicle data bus functionality, by blocking
data transmission on vehicle data bus systems, which are used to
transmit data, required to ensure the correct functioning of other
functions.
Functions which when disturbed affect vehicle statutory data, e.g.
tachograph, odometer
Legislation
ECE Regulation 13 [4] is concerned with the Type Approval of vehicles with regards to braking.
Annex 18 of the regulation is titled Complex electronic systems. Complex in this context refers
to systems where there is a hierarchy of control, such that lower level functions can be over-ridden
by higher level functions. This Annex includes a requirement for the manufacturer to demonstrate
their safety concept to the Approval Authority, which means the design decision made for the
system to fail safe or be fault tolerant and an overview of the means by which this is achieved. In
practical terms this Annex is being applied to any electronic system that can modify the drivers
braking demands or activate the brakes independently of the driver, including systems such as
ABS, ACC and stability control.
ECE Regulation 13 is also implemented in European law as Directive 71/320/EEC, last modified by
2002/78/EC. The latter does not include the complex electronic systems annex.
Legislation
Regulation 48 [5] is concerned with the Type Approval of vehicles with regards to the installation of
lighting and light-signalling devices. Whilst this Regulation is principally concerned with visibility
and positioning of external lighting, there are provisions on the operation of tell-tale (warning)
devices, interconnection of lighting and operation of exterior lights that may need to be considered
in the design of a system. These requirements are mostly functional, but see Section 2.2.1.
In European law these systems are covered by Directive 76/756/EEC as amended by 97/28/EC.
Legislation
5.8.2004 Version 1.0 71

Regulation 79 [6] is concerned with the Type Approval of vehicles with regards to steering
equipment. Vehicles are not permitted to have a steering system that relies on a purely pneumatic,
purely electric or purely hydraulic transmission of the steering forces; apart from:
Auxiliary steering equipment (effectively rear wheel steering) for
categories M (passenger vehicles) and N (goods vehicles), which
can rely on electric or hydraulic transmission
Steering for vehicle category O (trailers), which can rely on hydraulic
transmission.
A purely X transmission means that at some point in the transfer of commands from the driver
input to the road wheels the forces are transmitted by a means which is entirely X with no
mechanical transmission involved.
This Regulation therefore does not allow the steering commands to be transmitted by purely
electrical means (or other non-mechanical means). Work in the ECE GRRF will shortly lead to a
new version of this Regulation in which the need for a mechanical link is removed, thus providing
scope for the approval of a broad range of steering systems from traditional mechanical through
steering assist through to steer-by-wire. In addition there will be a new Annex 6 of the Regulation
on Complex electronic systems similar to Regulation 13.
In European law steering systems are covered by Directive 70/311/EEC as amended by
1999/7/EC.
Legislation
Regulation 97 [7] is concerned with the Type Approval of vehicles with regards to alarm systems.
Whilst its requirements are mostly functional, there is a requirement that an alarm system should
not affect the vehicle operation or its safe performance. See also Section 2.2.1.
In European law security systems are covered by Directive 74/61/EEC as amended by 95/56/EC.
Legislation
Regulation 100 [8] is concerned with the Type Approval of battery electric vehicles. Its
requirements are concerned with construction and with functional safety. Functional safety in the
context of the Regulation is concerned with the types of safety functions that are required (e.g.
warnings and interlocks) rather than how they are implemented.
2.2.7 European statement of principles on HMI
Legislation
The European statement of principles on HMI [9] is a set of recommendations on the essential
safety aspects to be taken into account in designing the human-machine interface (HMI) for in-
vehicle information and communication systems. Whilst largely concerned with the location of
displays or controls, and the presentation of information on them, it also covers design aspects
such as system interaction so that the driver maintains safe control of the vehicle under all
circumstances, feels comfortable and confident with the system and is ready to respond safely to
unexpected occurrences.
2.2.8 RESPONSE projects
5.8.2004 Version 1.0 72

Legislation
The RESPONSE projects have been included under legislation as, while they are European
collaborative research projects, they have been identifying the need for legislation to adapt to the
development and deployment of advanced driver assistance systems (ADAS).
RESPONSE 1, Project TR4022 in the Transport Sector of the Telematics Applications Programme,
ran from August 1998 to September 2001.
The project adopted an integrated approach towards user, system, and legal perspectives. The
final report concluded that ADAS remain manageable from the legal perspective and the users
viewpoint only as long as they can be controlled and/or overruled by the driver at any time.
However, once assistance systems are developed that cannot be overruled by the driver (or which
would require a reaction time to do so that is beyond human performance limits), then the driver
could not be held liable if they were unable to control the system. RESPONSE showed that this
would mean a greater emphasis on product liability, and the need for a clearly defined technical
and user centred development and testing process to reduce the risks for both the manufacturer
and the user of the system.
The project therefore recommended that there should be a clearer definition of the concepts of
reasonable safety and the duty of care, in order to legally protect the manufacturer and the
other stakeholders. Furthermore, methods need to be developed for gaining a deeper
understanding of the risks and opportunities of ADAS. These considerations need to be developed
into a Code of Practice for the technical and user-centred testing of ADAS.
RESPONSE 2, Project IST 2001-37528, ran from September 2002 to February 2004.
The project continued the work started in RESPONSE 1. Starting from the legal requirements of
reasonable safety and duty of care, the project sought to define them by agreement with
industry and other parties. The project also sought to move towards a Code of Practice for the
development and testing of ADAS from an integrated system safety and human factors viewpoint.
One of the major findings of the project was the need for a change of perspective from a product-
liability driven product development approach to one based on risk-benefit analysis and a Code of
Practice. Furthermore the project aimed to agree on requirements for the Code of Practice by
applying the definitions of reasonable safety and duty of care.
It was concluded that risk analysis is different from hazard analysis, and that there is no agreed
automotive process for performing risk analysis, nor for conducting a risk-benefit analysis on
ADAS.
RESPONSE 3 is part of the PReVENT Integrated Project. The project has three aims:
To develop a risk assessment procedure for next-generation sensors
within ADAS
To provide input on specific ADAS issues to the automotive version
of IEC 61508 being developed by FAKRA
To develop a Code of Practice for development and testing of ADAS.
In proposing a Code of Practice, all technical reliability and system safety issues will be assumed
to be covered by the future automotive specific adaptation of IEC 61508. The Code of Practice will
describe elements and phases for a human factors design process as part of the whole ADAS
development process. The Code of Practice will be applicable from the time that the first ADAS
concept development starts up to the commencement of vehicle production (Job #1).
2.2.9 Capability Maturity Model Integration

CMMI [13], the Capability Maturity Model Integration, is a development of the earlier Capability
Maturity Models (CMM) developed by the Software Engineering Institute at Carnegie Mellon
5.8.2004 Version 1.0 73
University. The motivation for this work has largely been the US Department of Defense, in
seeking to improve the quality and uniformity of products and services it procures whilst
addressing the plethora of standards that exist.
CMMI brings together the older CMMs, namely:
Capability Maturity Model for Software (SW-CMM)
Systems Engineering Capability Maturity Model (SE-CMM)
Integrated Product Development Capability Maturity Model (IPD-
CMM)
The application of CMM and CMMI is perhaps best-known in the software context (ie from SW-
CMM).
Within CMMI there are four types of models:
software engineering
software engineering and system engineering
software engineering, system engineering and integrated product
and process development
software engineering, system engineering, integrated product and
process development and supplier sourcing
A CMMI model consists of model components called process areas, each of which contain a
purpose statement, introductory text, specific goals, specific practices, generic goals, and generic
practices. These model components are contained in both representations.
Each CMMI model has two representations, staged and continuous. Both representations of a
CMMI model contain nearly identical information. A representation reflects the organization, use,
and presentation of model components within a CMMI model.
The staged representation is intended for approaching process improvement step by step.
Process areas are grouped at maturity levels that provide organizations with a proven approach for
process improvement. The staged representation specifies the order in which each process area
is implemented according to maturity level and the necessary performance that has to be achieved
before moving to the next level. This staged approach focuses on total organizational
improvement using a proven building block approach.
The continuous representation is offered as an alternative but complementary approach to process
improvement. It is designed for organizations that want to focus on a particular process area or set
of process areas based on known issues in the organization or on the organizations business
objectives. The organization maps its process-improvement objectives to CMMI process areas to
identify which process areas to implement. As each process area is implemented, the specific
practices and generic practices are implemented incrementally according to capability level. The
continuous representation also allows an organization to implement different process areas at
different rates. In addition, the organization of the process areas in the continuous representation
is derived from ISO 15504 and permits alignment of the CMMI approach with the SPICE approach.
CMMI is not explicitly concerned with developing safety-related systems. Safety activities are
frequently mentioned as an example of activities that might have to be considered at various
stages. Examples include, but are not limited to:
Project management > risk management
Engineering > requirements development
Engineering > technical solution
Support > configuration management
5.8.2004 Version 1.0 74

2.2.10 ISO/IEC TR 15504

In contrast to CMMI, ISO/IEC TR 15504 [14] (commonly known as ISO 15504 or SPICE) is
solely concerned with software process assessment. As noted above, the continuous
representation of CMMI is structured to permit alignment with ISO 15504.
ISO 15504 is essentially a two-dimensional model of the process capability, where the first
dimension is the processes and the second dimension is the capability level. Therefore an
assessment of a process capability is in essence a mapping into the two-dimensional space
defined by the processes and capabilities.
The processes are categorized into five process categories or steps, namely:
Customer-supplier process (CUS)
Engineering process (ENG)
Management process (MAN)
Support process (SUP)
Organizational process (ORG).
For each identified process the following are defined:
The purpose of the process
The deliverables of the process (known as outcomes)
The base practices, which define the actions to be taken to achieve
the outcomes
The input and output work products, the objects that are acted on by
the process (e.g. software code or documentation).
The capability levels are defined by a set of process attributes.
Level 1: Process performance
Level 2: Performance management
Work product management
Level 3: Process definition
Process resource
Level 4: Process measurement
Process control
Level 5: Process change
Continuous improvement
In performing an assessment, each process is rated against these attributes, thereby providing a
process profile.
At the present time, most of the parts of ISO 15504 have the status of a Technical Report. These
parts are in the process of being updated to and ratified as an international standard. Further
activities are noted seeking to align the ISO 15504 processes with ISO 9001.
2.2.11 Automotive SPICE
5.8.2004 Version 1.0 75

The Automotive Special Interest Group of the Procurement Forum is developing guidance on
applying SPICE processes to the assessment of automotive software suppliers. A number of
European automotive OEMs are already requiring that their software suppliers be subject to SPICE
audits, and the intention of Automotive SPICE is to produce a common assessment framework that
is acceptable to all the OEMs. Thus, if a supplier has been assessed according to Automotive
SPICE and found to have a certain capability level, this is then acceptable to any OEM who
requires a supplier with a capability up to that level.
The work of the Automotive SPICE group is concerned initially with developing a unified framework
to the quality and development process attributes found in ISO 15504. CUS processes have
been replaced with ACQ (acquisition process). It is planned to address safety aspects at a later
stage.
2.2.12 SPICE for Space

SPICE for SPACE was developed as part of a programme for software process improvement
sponsored by the European Space Agency (ESA). It is based on ISO 15504 and relates it to
existing ESA procedures for software engineering [16].
One significant difference in SPICE for Space is that additional process steps have been added to
the SUP processes for safety and dependability (SUP 9) and independent verification and
validation (SUP 10). There is a target profile by software criticality class (A: catastrophic through
to E: negligible) for the required capability level. For Class A (catastrophic) both SUP 9 and SUP
10 must be at capability level 4. For Class B (critical) both SUP 9 and SUP 10 must be at
capability level 3. There is no requirement for the lower levels. These additions recognize that the
space industry frequently produces software that is safety-related or mission critical.
The R4S risk model adds a third dimension, process risk, to the assessment model. This is
concerned with identifying the risk that an inappropriate process capability is applied [17].
A further development is concerned with software reuse and adds a new category of processes,
cross functional processes which includes APP application engineering covering the reuse
of existing assets [18].
2.2.13 IEC 61508
Safety
IEC 61508 is an international standard with the title Functional safety of electrical, electronic and
programmable electronic safety-related systems [20]. Although IEC 61508 is a generic standard,
its origins are in the process control industry sector. The standard is intended to be used in two
possible ways:
As the basis for a sector-specific standard. Parts 14 of IEC 61508
have been designated a basic safety publication by IEC, which
means that they should be included in any sector instantiation of the
standard, with interpretation where appropriate;
As a standard to be applied directly, where no sector-specific
standard yet exists.
IEC 61508 was developed against the model of equipment [that is] under control, for example an
industrial process in a chemical plant; and of the safety functions that need to be applied to that
equipment. These safety functions may be part of the control system for that equipment, or they
may form a dedicated protection system. These are distinguished in the standard as continuous
(or high-demand) systems and on demand systems.
5.8.2004 Version 1.0 76

IEC 61508 sets requirements for the reliability of the safety functions, which is known as safety
integrity. In practice, safety integrity is classified into discrete levels called safety integrity levels
(SILs). Hazard analysis is used to identify the safety functions that are needed, and the SIL of the
system that performs them can be determined by classifying the severity of the hazards. The SIL
indicates the reliability that must be achieved where this can be calculated, for example, for
electronic hardware; or the degree of rigour that must be achieved in the design and
implementation measures in order to gain adequate confidence in the system. These measures
are usually those needed to reduce systematic faults such as software errors or (lack of)
electromagnetic immunity.
IEC 61508 is already being suggested as the standard to apply to automotive systems (but see
also Item 2.2.14). The IEC 61508 frequently asked questions (FAQ) [21] suggests that
automobile indicator lights, anti-lock braking and engine-management systems are examples of
safety-related systems and further suggests that ABS is an example of an on demand safety-
related system. However there are a number of issues with the direct application of the standard
in the automotive domain:
1. The term functional safety in IEC 61508 only refers to the safety of the equipment under
control and its control system that depends on the correct functioning of the electrical,
electronic and programmable electronic safety-related systems, other technology safety-
related systems and external risk reduction facilities. In many automotive systems, the
manufacturer needs to be concerned with the safety of the system due to its control
functions, not just the safety functions.
2. Methods for the determination of SILs (such as the risk graph) are only given as examples,
and versions for the automotive industry need to be developed.
3. Many of the techniques and measures recommended in IEC 61508 are very specific to the
industrial process control sector.
4. The model of validation in the standard does not align with the automotive industry
practices of prototype development and testing, and the automotive Type Approval
process.
5. Compliance with IEC 61508 requires a clause-by-clause demonstration of compliance with
the objectives of the standard that may not be possible if alternative techniques have to be
proposed in the automotive context.
There are however many useful techniques and concepts in IEC 61508, and the importance of this
standard cannot be underestimated. Nevertheless, further and not insignificant work is needed to
adapt it to the automotive domain.
2.2.14 MISRA Guidelines
Safety
Development Guidelines for Vehicle Based Software (better known as the MISRA Guidelines)
[22] was developed in the early 1990s by a UK-based consortium of automotive companies
representing vehicle manufacturers, the supply chain and researchers. The Guidelines were
written against the background of the development that was taking place on IEC 61508 and
acknowledged that, while the track record of the automotive industry in respect of embedded
software was good, a recognized industry position on embedded software development for safety-
related vehicle control systems was needed.
The team producing the Guidelines had access to draft material from the committees that
produced IEC 61508, and many of the concepts and principles in this standard are embodied in
the Guidelines. The Guidelines sought to incorporate these principles within the context of the
standard approaches for automotive engineering.
The notable approaches in the Guidelines are:
5.8.2004 Version 1.0 77

The emphasis on safety activities in the development lifecycle;

The use of controllability to classify hazards. This is a different
approach from IEC 61508, although a similar process is used by the
aviation industry;
The use of (safety) integrity levels to classify systems and/or
functions according to the level of risk mitigation required;
A summary table recommending the degree of process rigour
required with increasing (safety) integrity level.
Although the Guidelines have been in use worldwide in the 10 years since their publication, a
number of issues can be identified:
There is no formal mapping with IEC 61508, despite many of the
underlying principles being present;
There is a perception that the Guidelines are only concerned with
software. In fact the Guidelines advocate a systems engineering
approach, but provide guidance only for the software aspects;
There is a perception that the Guidelines carry less weight than
IEC 61508, as they are not a standard, notwithstanding that in terms
of product liability legislation they represent best practice;
They do not explicitly address recent technology developments such
as model-based development and automatic code generation.
2.2.15 EN 50126, EN 50128, EN 50129
Safety
EN 50126 (Railway Applications: The specification and demonstration of Reliability, Availability,
Maintainability and Safety (RAMS)), EN 50128 (Railway Applications: Software for railway control
and protection systems), and EN 50129 (Railway Applications: Safety related electronic systems
for signalling) are a group of European standards dedicated to railway systems.
These standards describe processes to be followed in order to be able to assure the safety of
railway systems. EN 50126 [23] is the top-level document. It contains the overall process for the
total railway system and defines the Safety Integrity Levels (SILs). It gives the framework for the
more detailed activities, which are described in the accompanying documents EN 50128 [24] and
EN 50129 [25]. EN 50128 is the software specific part of EN 50129.
This family of standards is designed to be broadly consistent with IEC 61508 EN50126 und
EN50128 are based on earlier versions of IEC61508 and EN 50129 is based on the current
version. Hence, the contents are similar to those of IEC 61508. EN 5012x are customized for
railway applications and embodies good practice for both signalling and train-borne systems. The
requirements regarding techniques and methods that should be used for the different SILs are
tightened such that some methods are now highly recommended for SIL 3 whereas these
methods are only recommended at SIL 3 in IEC 61508.
2.2.16 DO-178B
Safety
The purpose of the RTCA document DO-178B Software Considerations in Airborne Systems and
Equipment Certification [26] is to provide guidelines for the production of software for airborne
systems and equipment that performs its intended function with a level of confidence in safety.
The guidelines give:
5.8.2004 Version 1.0 78

Objectives for software life cycle processes

Descriptions of activities and design considerations for achieving
those objectives
Descriptions of the evidence that indicate that the objectives have
been satisfied.
The document discusses those aspects that pertain to the production of software for airborne
systems and equipment used on aircraft or engines. A complete description of the system life
cycle processes, including the system safety assessment and validation processes is not given.
Only the software related part is considered.
Based on the failure condition categorization (Catastrophic, Hazardous/Severe-Major, Major,
Minor, No Effect) software assurance levels are defined:
Level A for software whose anomalous behaviour would cause or
contribute to a failure resulting in a Catastrophic failure condition
for the aircraft;
Level B to Level E are defined in an analogous manner for
Hazardous/Severe-Major through to No Effect.
Guidance concerning determination of software level is given.
The guideline does not specify a concrete software life cycle, but describe separate processes that
are part of most lifecycles and the interaction between them. Due to the standard for each
software product, the software lifecycle includes the following processes:
The software planning process
The software development processes (software requirements,
software design, software coding, integration)
The integral processes to ensure the correctness, control, and
confidence
Software verification process
Software configuration management process
Software quality assurance process
Certification liaison process.
For every process the standard discusses the objectives and activities of the process. During the
software lifecycle various data is produced to plan, explain, define, record, or provide evidence of
activities. The document also discusses the characteristics and contents of such software lifecycle
data.
The annex provides tables for each sub-process that identifies which objectives of that process are
applicable for each software level and which output should be generated. References to the
detailed descriptions are given.
2.2.17 ARP 4754/4761
Safety
The SAE Standard ARP 4754 Certification Considerations for Highly-Integrated Or Complex
Aircraft Systems [27] discusses the certification aspects of highly-integrated or complex systems
installed on aircraft. The term highly-integrated refers to systems that perform or contribute to
multiple aircraft-level functions. The term complex refers to systems whose safety cannot be
shown solely by test, and whose logic is difficult to comprehend without the aid of analytical tools.
The document addresses the total life cycle for systems that implement aircraft-level functions. It
5.8.2004 Version 1.0 79

excludes specific coverage of detailed systems, software and hardware design processes beyond
those of significance in establishing the safety of the implemented system. The focus is toward
ensuring that safety is adequately assured through the development process and substantiating
the safety of implemented systems. It contains detailed instructions on how to integrate various
assessments into the system development process to ensure freedom from safety critical design
and implementations flaws.
Figure 30 below outlines the relationships between various documents providing guidelines for
system development, safety assessment, and the hardware and software life-cycle processes:
Safety Assessment Process

Guidelines and Methods
(ARP 4761)
Intended
Function, Failure System Design
Aircraft and Safety
Function Information
Functional
System Development System
Processes
(ARP 4754)
Aircraft System Functions and
Development Requirements Implementation
Process
Hardware Lifecycle Hardware Development

Process Lifecycle
(DO-254)
Software Lifecycle Software Development

Process
Lifecycle
(DO-178B)
Figure 30: Relationship between civil aviation standards and guidelines
Methodologies for safety assessment processes are outlined in

ARP4761 Guidelines and methods for conducting the safety
assessment processes on civil airborne systems and equipments
[28]. It contains details on how to conduct safety assessments and
details on application of safety analysis methods (FTA, FMEA, etc.).
More detailed coverage of the software aspects of design are dealt
with in RTCA document DO-178B Software Considerations in
Airborne Systems and Equipment Certification (see Item 2.2.16) and
its EUROCAE counterpart, ED-12B.
Coverage of complex hardware aspects of design are dealt with in
RTCA document DO-254 Design Assurance Guidance for Airborne
Electronic Hardware and its EUROCAE counterpart ED-80.
The concept of development assurance is illustrated along a conceptual system development
process. There is an interaction between the system development process and the safety
assessment process. Both are connected to the certification process.
5.8.2004 Version 1.0 80
Aircraft functions
Aircraft Level
Aircraft Level
FHA
Functional
Failure condition, Effects,
Requirements
Functional
Classification, Safety Requirements
Failure
Conditions Allocation of
& Effects
Aircraft Functions
System Level system functions
to Systems
FHA Sections
Failure condition, Effects,
Classification, Safety Requirements
Development
Separation of System
Architectural Requirements
CCAs Requirements Architecture
PSSAs system architecture
Allocation of Item
Item Requirements Requirements to
Item Requirements, Hardware and
Safety Objectives,
Analyses Required Software
Separation &
System
Verification SSAs
implementation
Implementation
Results Physical System
Certification
Safety Assessment Process System Development Process
Figure 31: Civil aviation certification process

The goal of the certification process is to substantiate that the aircraft system complies with all
relevant requirements. The certification process is based on a certification plan and includes all
necessary information from the development process, safety assessment process as well as
validation and verification plans and data.
Safety requirements are determined by identifying and classifying associated functional failure
conditions. Based on the most severe failure condition classification (Catastrophic,
Hazardous/Severe Major, Major, Minor, No Safety Effect) associated with the considered function,
a system development assurance level is assigned (level A, B, C, D, or E). Section 5 of the
document discusses the determination of requirements and the related failure condition
classifications.
The objectives of the safety assessment process is to provide analytic evidence showing the
compliance with the airworthiness requirements. The main items of the safety assessment process
model are:
FHA: The functional hazard assessment (FHA) is a systematic and
comprehensive examination of functions to identify potential
functional failures and classify the hazards associated with specific
failure conditions. The input for the FHA are aircraft functions or
system functions and the outputs are failure conditions with
classification and effects and the required systems development
assurance level.
PSSA: The preliminary system safety assessment (PSSA)
establishes specific system and item safety requirements and
provides preliminary indication that the safety requirements will be
met.
5.8.2004 Version 1.0 81

SSA: The system safety assessment (SSA) combines the results of

various analyses to verify that the implemented system meets the
system safety requirements established by the FHA and PSSA.
CCA: The common cause analysis (CCA) provides evidence that
physical and functional separation and isolation requirements are
met and that the failures assumed to be independent are truly
independent.
To substantiate the correctness and completeness of requirements the document describes the
necessary validation and verification activities. For each development assurance level, the
document discusses the recommended validation and verification methods.
The SAE Standard ARP 4761 Guidelines and Methods for Conducting the Safety Assessment
Process on Civil Airborne Systems and Equipment [28] describes guidelines and methods of
performing the safety assessment for certification of civil aircraft. The methods outlined in the
document identify a systematic means, but not the only means, to show compliance. The concept
of aircraft level safety assessment is introduced and the tools to accomplish this task are outlined.
It gives detailed definitions of e.g. fault tree analysis (FTA), dependence diagrams (DD), Markov
analysis (MA) including illustrating examples of their practical application.
2.2.18 MIL-STD-882D
Safety
This standard practice for system safety [29] is issued by the US Department of Defense (DoD)
and describes an approach for managing mishap risks in DoD systems regardless of their
implementation technology. It provides requirements for the identification and evaluation of mishap
risks, and for mitigating these risks to an acceptable level. The actual requirements that have to be
met if conformance to MIL-STD-882D is to be claimed are covered on two pages, with the rest of
the 26 pages providing guidance, definitions and other supportive information.
The most important part of the standard, i.e. the actual requirements, defines the system safety
activities that shall be performed. There is an emphasis on organizational and procedural aspects
rather than technology-related details.
2.2.19 MATISSE project
Safety
The MATISSE project [30] had the objective of developing industrial-strength methods and
associated technologies for the engineering of software-based critical systems. This was achieved
in practice by recommending a process based on the use of formal mathematical methods.
The project partners were Aabo Akademi University, ClearSy, CNRS-TIMA Laboratory Grenoble,
Gemplus, Siemens Transportation Systems, University of Southampton and QinetiQ.
The project produced the MATISSE Handbook showing how the formal mathematical methods
proposed could be incorporated into the product engineering lifecycle for safety-related systems.
The handbook includes material provided from the separate perspectives of the executive board of
an organization, the project manager and the practitioners responsible for the design and
implementation.
The project recommendations are based on analysis and experiences of three industrial case
studies developed as part of the MATISSE project:
automatic transportation system (actually part of an automated
railway control system);
multi-application smartcard embedded byte-code verifier;
5.8.2004 Version 1.0 82

health care control system.
2.2.20 SETTA project
Safety
The overall goal of the SETTA project [31] was to push time-triggered systems - an innovative
European-funded technology for safety-critical, distributed, real-time applications such as fly-by-
wire or drive-by-wire - into future vehicles, aircraft, and train systems. To achieve this goal, SETTA
focused on the systems engineering of time-triggered systems. The SETTA consortium consisted
of leading European companies in the transport and component supplier sector (DaimlerChrysler,
Renault, Airbus Germany, Alcatel Austria, and SiemensVDO), innovative European high tech start-
ups (TTTech, DECOMSYS), and universities with an excellent reputation in real-time (University of
Technology at Vienna) and safety-critical systems (University of York).
A key feature of the SETTA methodology is virtual prototyping. Time-triggered systems are, in
contrast to event-triggered systems, fully predictable in their run-time behaviour. SETTA exploits
this property for advanced system modelling. Simulation building blocks for the Matlab/Simulink
environment were developed by DECOMSYS (product name: xCom) which model the
communication behaviour of time-triggered systems. Based on these building blocks, virtual
prototypes of distributed, embedded systems - e.g., a brake-by-wire system - can be easily
realised. Various properties of the embedded system, e.g., the accuracy of distributed control
algorithm, or the correctness of fault-tolerance strategies, can be analysed before a physical
prototype is built.
Further tool components were developed in the course of the SETTA project to increase the
maturity of virtual prototypes. A verification tool developed by TTTech (product name: TTPVerify)
checks the correctness of scheduling configuration files. The verification tool will be certified with
respect to Federal Aviation Administration (FAA) standards. A prototypical worst-case execution
time analysis tool (WCET) from the Technical University of Vienna calculates the worst-case
execution time of programs statically. This tool is tightly integrated into the Matlab/Simulink
environment and supports WCET analysis on the modelling level. Two target processor
architectures - Motorola M68000 and Siemens C167CR - are supported.
A further objective of the SETTA project was better integration of functional development and
safety analysis. A prototypical fault-tree synthesis tool set has been developed by DaimlerChrysler
in co-operation with the University of York. The synthesis algorithm performs a backward traversal
of the data flow graphs given by the virtual prototype. Finally, a robustness analysis tool from
DaimlerChrysler helps to identify design errors in stateflow components of virtual prototypes.
The SETTA methodology and the corresponding tool components were evaluated by pilot
applications from the automotive, aerospace, and railway domain. The automotive validator is a
brake-by-wire system combined with an adaptive cruise control system, implemented by
DaimlerChrysler, Renault and SiemensVDO. Two control loops are closed by a time-triggered
communication system: firstly, the basic control loop between braking pedal and brake actuator,
and secondly, between brake system and adaptive cruise control system. The aerospace validator,
which has been developed by Airbus Germany, is a cabin pressure regulation system which
controls the pressurisation of the cabin via out flow valves. Their opening will be commanded
according to the desirable pressure in the cabin. Since the pressure regulation in the entire cabin is
safety critical, it operates fully automatically. The automotive and aerospace validator were
developed firstly as virtual prototypes and secondly as physical prototypes. Alcatels railway
validator covers a redesigned Field Element Controlling (FEC) subsystem of Alcatels electronic
interlocking system ELEKTRA. The railway validator is used for the evaluation of the WCET
analysis tool and the schedule verification tool.
2.2.21 ESACS project
5.8.2004 Version 1.0 83

Safety
ESACS (Enhanced Safety Assessment for Complex Systems) is a European GROWTH project
running from 2001 to 2003. The technical and scientific objectives of ESACS are to define a
methodology to improve the safety analysis practice for complex systems development, to set up a
shared environment based on tools supporting the methodology, to validate the methodology
through its application to case studies. The environment between design and safety will consist of
tools to generate parts of the safety analysis using information extracted directly from the system
model and of a repository including all the safety information related to the complex system under
development.
Current development processes are characterized by the fact, that on the one hand, models are
developed by the system design engineer to specify and to analyse the expected behaviour of the
system under consideration. This is done on different levels of abstraction resulting in
requirements models or lower level architectural models.
On the other hand, the envisaged system is analysed by safety specialists with respect to
malfunctions (unintended behaviour). The safety analysis, performed at each stage of the system
development, is intended to identify all possible hazards with their relevant causes. Among
common safety analysis methods are Functional Hazard Analysis, Failure Mode and Effect
Analysis (FMEAs) and Fault Tree Analysis (FTA). Partly, mathematical methods are used (FTA,
stochastic models such as Markov Processes).
Currently, effects of erroneous behaviour are mostly determined by engineering judgement and
verified by testing. The accurate engineering judgement is becoming more and more difficult: the
number of possible system states increases due to digital controllers and due to increasing
interaction between different aircraft system which involves a risk of interaction failures. Often the
classification of effects is too pessimistic: a worst case consideration is made resulting in
additional redundancies raising the price of the resulting system in an unnecessary way.
Currently, information between system engineer and the safety analyst about the same system is
exchanged by means of paper: i.e. information about the system behaviour given by text or by a
model is first interpreted by the safety analyst and in a next step FMEAs or FTA are performed
(supported by other tools). This type of information processing is error-prone, implies duplication
of efforts in modelling the system (once for the design and once for the safety) and also delays the
identification of the system problem areas. In fact, in this way, the safety process is slightly
delayed in respect to the design process.
A solution to these problems is to perform the safety assessment analysis in some automated way
directly from the system functional model. This means that the models used for the design of the
system must be enriched with safety information/requirements and with simulation
methods/checkers and tools to help to realise a correct and effective safety assessment analysis.
The main innovations and benefits coming out of this project are the following:
The integration of the safety and design/development processes will
be enhanced
Traceability of safety issues during the complex system development
will be improved
Computer aided analysis helps to master complexity
Worst case considerations in FMEAs and FTA can be avoided
Weak points that are difficult to detect by engineering judgement can
be revealed in the early phase of design
The activities of designing and doing safety analysis can be done
more easily in an iterative manner which result in a more effective
development process, where the results of the safety analysis can
influence the design in short period of time
5.8.2004 Version 1.0 84

All these points will lead to a higher level of confidence in the certification process.
Some of the ESACS deliverables are publicly available at www.esacs.org:
Deliverable 1: Requirements for improving the safety process on
Complex systems and definition of the tools integration concepts,
May 2001.
Deliverable 4: Formal notations suitable to express safety properties
identified, September 2001.
Deliverable 6: Safety techniques for complex systems, October
2001.
Deliverable 7: Tools for performing safety analysis starting from the
design system model, February 2002.
Deliverable 14: Results of methodology application on cycle 1 case
studies, April 2003.
Deliverable 18: Results of methodology application on cycle 2 case
studies, October 2003.
2.2.22 ISAAC project
Safety
ISAAC (Improvement of Safety Activities on Aeronautical Complex systems, FP6-2002-Aero-1-
501848) is a follow-up project of ESACS.
The FP5 project ESACS has shown the benefit of using formal techniques to assess aircraft
safety. ISAAC builds upon and extends the results of ESACS to go a step further into the
improvement and integration of safety activities of aeronautical complex systems. Potential
benefits range from higher confidence in the safety of systems to increased competitiveness of
European industries.
To reach the goals mentioned above, ISAAC will focus on the following three dimensions:
Extension of formal techniques to deal with human error, common
cause analysis, mission analysis, and testability. This will help
providing a more comprehensive tool-supported coverage of the
safety analysis process.
Improvement of the ESACS notations to represent safety
requirements and qualitative (timing) and quantitative aspects. This
will help improving interaction and increasing the quality of the
results provided by tools.
Integration, achieved through common methodological
recommendations and shared libraries and interfaces. This is one of
the keys to improve, e.g. the efficiency of industrial processes, that
more often rely on the use of different tools.
ISAAC's results will be used by the partners to improve their safety process for their present and
future programs. The results will also be disseminated to other areas, like, e.g., transportation
(railway and automotive), industrial process control, energy production.
2.2.23 ASCET-SD
Automotive tools > Design tools > Functional design
5.8.2004 Version 1.0 85

ASCET-SD [41], [42] is developed by ETAS GmbH (Stuttgart, Germany). It is used to create an
abstract model-based description of the functionality of an ECU and generate optimized target
code based on the model specification.
ASCET-SD pursues an object-based approach to functional modelling. The main modelling
elements are modules and classes. Classes (e.g. a filter algorithm or a PID controller) can be
multiply instantiated (in a particular model) and each instance independently parameterized. By
this means the creation of lean model descriptions is possible.
The currently available version of ASCET-SD is V4.2. According to the vendor, the main benefit of
ASCET-SD is the abstract model description in the physical domain. The transformation to the
limited numerical capabilities of a typical microcontroller is supported by the definition of
conversion formulae between the physical and the raw data domain as well as the ASCET-SD
code generator.
The latter can be used either to create code for particular functions that can be added to manually
created code projects or as an integration platform for the creation of the entire ECU software incl.
the necessary OSEK RTOS. The first use case mentioned above is also known as the additional
programmer scenario.
Furthermore, the tool supports a smooth transformation of the abstract model to the ECU target by
providing simulation experiments on different levels of abstraction (i.e. physical, quantized, integer
arithmetic). Simulation experiments can be carried out in real-time on the so-called ES1000
development and experiment platform. The latter can also be used to set up bypass applications
for the stepwise development of ECU software.
The executable code generated by ASCET-SD is accompanied by a corresponding ASAM MCD
2MC description. For more information about the range of supported microcontroller target please
consult the ETAS website.
Please note that particular versions of ASCET-SD have recently been certified according to the
IEC61508 standard for safety-related applications.
2.2.24 AutoFOCUS

AutoFOCUS [43] is developed by Validas AG (Garching, Germany) based the technology
introduced by the chair of Software and Systems Engineering at the Technical University of
Munich, Germany. The focus of the tool is the development of reliable software systems by using a
component-based paradigm to represent models of distributed embedded systems.
As a major characteristic, AutoFOCUS supports the formal verification of model behaviour. Of
course, this capability is especially relevant for the creation of safety-related systems since it
provides a much higher degree of confidence in a model as can be achieved by mere simulation
experiments.
The modelling capabilities of AutoFOCUS, on the other hand, are limited to discrete modelling
paradigms (like state machines) that can be (compared to e.g. the modelling by means of
nonlinear ODE) more or less easily verified by means of formal methods.
2.2.25 DECOMSYS::SIMCOM

DECOMSYS::SIMCOM is a blockset for modelling FlexRay communication within a Simulink
model. In particular, it consists of blocks to transfer Simulink signal over a FlexRay bus.
This eases, according to the vendor, the development of distributed control applications within a
Simulink model especially with respect to the impact of FlexRay communication and the behaviour
of control loops that are distributed over several ECUs.
5.8.2004 Version 1.0 86
Furthermore, fault injection interfaces are provided. By this means the robustness of control
algorithm with respect to channel loss, node loss, message loss, frame disturbance, etc. can be
studied.
Since the FlexRay communication system has been developed with special emphasis on safety-
critical applications, it is highly relevant for the EASIS project.
2.2.26 MATLAB/Simulink/Stateflow

Simulink (developed by The Mathworks, Nattick, MA, USA) is one of the most prominent tools
used for modelling and simulation in the automotive industry and beyond. Simulink is based on
The Mathworks' MATLAB environment.
Simulink provides a graphical modelling means based on block diagrams and signal lines
connecting the particular blocks. While Simulink emphasizes on a data-flow modelling paradigm,
Stateflow can be used to create statechart models which can be seamlessly integrated into
Simulink models.
Simulink provides a block library from which the user may pick relevant blocks and drag them to
his own model. The library contains blocks for investigating and verifying the behaviour of Simulink
models (the so-called model verification blockset).
The blocks can be used to, for example, monitor the upper bound of a particular signal and report if
the condition is validated. Therefore, these blocks are especially useful for the creation of safety-
relevant models.
The Mathworks provide several code generators for transforming Simulink models to executable
code. The Real-Time Workshop (RTW) (see Section 2.2.32) is mainly used to create code for
experiment platforms and rapid-prototyping systems. Furthermore, the so-called RTW Embedded
Code is provided for generating production-ready code for ECU targets.
The modelling and simulation capabilities of Simulink can be conveniently extended by adding
additional block libraries called blocksets. By this means it is possible to introduce domain-specific
automotive model semantics (e.g. for bus communication) to Simulink models. In this manner, for
example, the DECOMSYS::SIMCOM blockset (see Item 2.2.25) can be used to model FlexRay
communication in a Simulink model.
2.2.27 Rhapsody in C++ / C

Rhapsody in C++ generates full production C++ code for a variety of target platforms based on
UML 2.0 behavioural and structural diagrams. The C++ version targets many popular 32-bit
RTOS environments as well as smaller devices in the 16-bit space with or without an RTOS [44].
Rhapsody in C generates full production C code for a variety of target platforms based on UML 2.0
behavioural and structural diagrams as well as providing reverse engineering of C code for reuse
of existing designs within a model-based environment. The C version targets many popular 32-bit
RTOS environments as well as 8-bit and 16-bit microcontrollers with or without an RTOS through
its interrupt driven framework. Rhapsody in C brings model-based development to the C
developer by giving them a flexible environment to work in an object based environment or to
define more functional code. By extending Rhapsody in C to allow both methodologies,
developers can take advantage of key enabling technologies of full production code generation,
model execution, and model-code associativity [45].
The above description also covers other UML-based tools.
5.8.2004 Version 1.0 87

2.2.28 SCADE

The SCADE Suite and SCADE Drive [46] provide solutions for the avionics, automotive, and
other industries to be used to create safety-, mission- and business-critical embedded software
systems.
The Esterel Studio is used to similarly automate and guarantee the correct implementation for
hardware circuit designs and complex protocols for consumer electronics, semiconductors and
telecommunications.
Both of these products have at their core a unified conceptual model of embedded computation
backed by three strong technical principles:
Specific high-level rigorous graphical and textual descriptions
Compiling algorithms for correct-by-construction implementation
Formal validation and verification techniques.
See also Section 2.2.33.
2.2.29 Statemate MAGNUM/MicroC

Statemate and Rhapsody in MicroC [47] are developed by I-Logix (Andover, MA, USA). Statemate
MAGNUM (currently available: V3.2) provides a graphical modelling language for specifying
models using (according to the vendor) standard engineering diagrams, including data and control
flow diagrams, truth tables, statecharts, and control law block diagrams [48].
Furthermore, a simulation platform is provided that allows the instant simulation and debugging of
Statemate models based on the generation of either C or Ada code. Models can be animated
during simulation which simplifies the understanding of actual model behaviour.
A code generator for creating executable code for rapid-prototyping platforms is also included. The
MicroC code generator, on the other hand, is used for the creation of production-ready code for
ECU targets.
According to the vendor, the system behaviour can be validated and specification errors removed
early in the design process. Furthermore, a complete, consistent, and formal documentation of the
model can be generated on demand [48].
With respect to these characteristics, Statemate MAGUM could be considered as another tool to
be recommended for the design of integrated safety systems. After all, the vendor claims that the
tool is used (outside the automotive domain) for designing vital medical systems (e.g. defibrillators
and pacemakers).
2.2.30 TargetLink

TargetLink [49], developed by dSPACE GmbH (Paderborn, Germany) is an add-on product to
Simulink. With TargetLink (currently available as V1.3), the user is provided with means to create
production-ready series code out of a Simulink model.
Nevertheless, the model has to be enhanced for this purpose, i.e. additional information (e.g. the
transformation of physical data to the domain of "raw integer" fixed-point arithmetic) is to added to
the model.
5.8.2004 Version 1.0 88

Furthermore, a whole blockset is provided for adapting particular model functionality to the
requirements of series code. TargetLink provides means for simulating the generated code in a
PC-hosted environment. Furthermore, the generated code can be optimized with respect to target-
specific characteristics. This feature is called target-awareness.
Simulink models can be converted to TargetLink models and vice versa. According to dSPACE,
the code generated by TargetLink is conform to the vast majority of MISRA C [34] rules.
Exceptions from the rules are identified and documented.
2.2.31 Telelogic ObjectGeode

Commercial product overview [50]:
ObjectGeode is a toolset dedicated to analysis, design, verification and validation through
simulation, code generation and testing of real-time and distributed applications. Such applications
are used in many fields such as telecommunications, aerospace, defense, automotive, process
control or medical systems. ObjectGeode supports a coherent integration of complementary
object-oriented and real-time approaches based on the UML, SDL and MSC standards languages.
ObjectGeode provides graphical editors, a powerful simulator, a C code generator targeting
popular real-time OS and network protocols, and a design-level debugger. Complete traceability is
ensured from Requirement to code.
The code generation of this toolset is more directed for prototypes than production. Its strong point
is the modelling of communications-based systems with a standardized language (SDL/MSC). It is
already used for this purpose in the telecommunications industry. It can be attractive for the
design of complex communications-based systems.
2.2.32 Real-Time Workshop Embedded Coder 3.2.1
Automotive tools > Design tools > Code generation

Generate production code for embedded systems. Real-Time Workshop Embedded Coder
enables you to generate, test, and deploy production C code in real-time embedded systems.
Real-Time Workshop Embedded Coder provides a framework for producing code that is optimized
for speed, memory usage, and simplicity. It extends the capabilities of Real-Time Workshop by
adding the software engineering dimension that is crucial for deploying complex embedded
systems. Features provided with Real-Time Workshop Embedded Coder let you easily customize,
document, test, and validate the generated code, all within the Simulink environment.
This product is mainly used for prototyping. Although it has been used in series production for a
few applications, because of component constraints such as the problem of changing a floating-
point value into an integer (for which a block has to be introduced manually rather than
automatically, therefore a potential source of error), this tool is not optimized and directed for
safety.
2.2.33 SCADE Drive 4.3 for Automotive
Automotive tools > Design tools > Code generation

Building on a successful pedigree of dozens of projects in civilian avionics and other safety-critical
applications, Esterel Technologies SCADE Drive has hit the road. In civilian avionics, SCADE
has already been qualified to the strict software guideline DO-178B, and now SCADE Drive will
cover the emerging automotive requirements called out in the IEC 61508 standard. SCADE
5.8.2004 Version 1.0 89
Drives seamless software development process from requirements to code generation increases
productivity and assures meeting the highest quality standards. SCADE Drives efficient generated
source code is MISRA-compliant and IEC 61508 SIL Level 4 certification is in progress. For critical
embedded software that must perform perfectly the first time and every time, the SCADE proven
development environment is the choice of industry leaders.
Figure 32: Use of SCADE tools

This tool has some advantages for safety applications: its synchronous aspect makes it possible
to control the temporal sequencing, its formalism brings constraints to avoid features that are not
desirable in safety-related systems (e.g. pointers, skeletal operators), and it allows proof that the
safety properties are respected or that sever events will not occur.
This tool is potentially of interest because it is targeted at safety applications (certification, model
checking and time-triggered architectures).
2.2.34 CANoe
Automotive tools > Design tools > Infrastructure and middleware design
The main purpose of CANoe [53] (Vector Informatik GmbH, Stuttgart, Germany) is the
development of communication networks for automotive systems . According to the vendor, the
major application areas are:
Communication design/model creation: definition of the
communication matrix.
Communication validation: provide a reliable simulation platform for
bus communication.
Remaining bus simulation/functional test: CANoe simulations can be
seamlessly combined with existing ECUs. By this means parts of the
bus are actual existing while others are simulated by CANoe.
Diagnostics: analysis of diagnostics communication.
Distributed development/integration: mutually independent and
parallel development of network nodes
CANoe supports various communication protocols such as CAN [54], [56], LIN, MOST, FlexRay,
etc.. The behaviour of the ECU code is accurately simulated down to the consideration of RTOS
activities. For this purpose Vector provides the osCAN library that enables the operation of OSEK-
based applications as part of CANoe simulation experiments.
5.8.2004 Version 1.0 90
2.2.35 DECOMSYS::DESIGNER
DECOMSYS::DESIGNER is the fundamental tool for design- and configuration tasks in the entire
DECOMSYS FlexRay toolchain.
In this context, the tool is used to describe the system structure (i.e. nodes, controller, busses) as
well as the data flow (signals, relationships between sender and receiver, etc.) among the nodes
based on a block structure.
Furthermore, it is possible to add scheduling information for the bus system (the cluster). Then, the
dataflow graph must be mapped to the hardware structure.
Code generation of configuration files, the FTCom layer, and documentation can be carried out on
the basis of the information gathered in DECOMSYS::DESIGNER.
The workflow in DECOMSYS::DESIGNER is supported by various wizards, e.g. for defining the
bus schedule. A property view for getting detailed information about particular objects is also
provided.
2.2.36 DaVinci
The DaVinci tool suite [55] (developed by Vector Informatik GmbH, Stuttgart, Germany) can be
used to:
Develop complex distributed automotive software systems on the
basis of reusable software components.
Perform the integration of reusable software on a single ECU and
automatically create required communication middleware as well as
the configuration of the underlying OSEK RTOS.
DaVinci (currently available as V1.0) provides abstract modelling means for the formal
specification of reusable vehicle functions. A collection of vehicle functions (in DaVinci terminology:
software components) can be compiled to form the software architecture (or: software system) of a
specific vehicle.
Furthermore, it supports the specification of the hardware topology (i.e. ECU, bus, sensor,
actuator) thus defining a so-called hardware system. The combination of software system and
hardware system (mapping system) is the basis for the concrete realization of a specific ECU
functionality.
For this purpose the behaviour of software components must be specified by either direct C coding
or the usage of BMT and accompanying code generators. For sensors and actuators, ECU-specific
firmware must be provided.
A code generator is subsequently used to integrate both software components and firmware with
the RTOS and the communication middleware.
The code can be generated for either a PC-based experimental system based on CANoe (see Item
2.2.34) or (with identical functionality) directly for the target ECU.
The DaVinci methodology is based on a formalized approach. Therefore, models can be validated
against the formal methodology. For this purpose a multitude of validation checkers is provided as
part of the tool suite. The user gets detailed information about potential violations of modelling
constraints. This is a major prerequisite for building safety-related applications.
DaVinci supports a distributed development process based on the exchange of XML documents
and/or the usage of a configuration management tool. The main area of application is currently
5.8.2004 Version 1.0 91

body electronics but the methodology is not limited to this domain and can be extended to other
application domains (e.g. Telematics, power train).
2.2.37 TTP-Plan/TTP-Build
TTP-Plan [57] (provided by TTTech Computersysteme AG, Vienna, Austria) is a tool for designing
the global timing and communication pattern of a TTP bus.
According to the vendor, the composability and modular testability of systems based on the time-
triggered approach relies on a correct and complete specification of the system-wide
communication schedule both in the value and time domains.
TTP-Plan is used to create such a schedule by means of a graphical user interface or
import/export interfaces. Furthermore, the design can be checked for correctness and the
properties of the network (e.g. bus utilization, etc.) can be visualized on demand.
Individual nodes can be designed using the TTPBuild tool [58]. This affects in particular the
scheduling of tasks and the generation of the OS configuration.
2.2.38 VNA/LNA
The Volcano Network Architect (VNA) [59] as well as the analogous tool for LIN, LIN Network
Architect (LNA), is provided by the Volcano Automotive Group (Gteborg, Sweden).
According to the vendor, VNA is a standalone offline tool, providing a user-friendly Windows
interface for logically describing and configuring CAN and LIN networks at a high abstraction level.
In a nutshell, the Volcano approach for middleware development is to establish a holistic
mathematical model of the entire communication processes on a specific bus. Based on this
model, it is then possible to assign certain time slots to different messages in order to avoid
collisions and thus remove the need for arbitration.
By this means, according to Volcano Automotive, it is possible to set up a deterministic and reliable
communication scheme even for CAN communication. For implementing the results of the
mathematical communication model, as special code generator (the offline tools) to create the
communication middleware has been realized.
2.2.39 RT-Builder
RT-Builder is one of the most advanced solutions for Real-Time design, modeling and analysis of
complex, multi-processors and multi-bus systems and software.
For complex and critical real-time system and software design, RT-Builder is an environment for
specifying, modeling and analysing control and data-oriented fonctions.
With RT-Builder, users can model, simulate, formally verify and executable specifications and
prototypes of their systems prior to HW availability, and of course generate design documentation.
RT-Builder is the unique tool supporting both asynchronous and synchronous aspects of real-time
developments thanks to its GALS (Globally Asynchronous Locally Synchronous) approach, and
managing both control and data-flows.
RT-Builder comes with existing libraries modeling advanced Real-Time Operating Systems
(RTOS) and Bus libraries: ARINC653 for Integrated Modular Avionics, CAN, OSEK, FlexRay
5.8.2004 Version 1.0 92
standards for Automotive. These libraries can easily be customized or extended to integrate
dedicated needs or provide a powerful support of customers real-time choices.
With RT-Builder, users can model and manage interactions between control and data functions,
but also concurrency, multi-tasking, pre-emptive actions, shared resources, event routing and
filtering, FIFO buffers, point-to-point data propagation time.
2.2.40 CalDesk
Automotive tools > Tools for measurement and calibration

CalDesk [61] has been developed by dSPACE GmbH (Paderborn, Germany). The tool has been
released in August 2003 to the market . It supports both the usage of a memory emulator and the
XCP [62] calibration protocol. Support for other existing protocols, such as CCP [63], is under
development.
CalDesk is based on the dSPACE data dictionary as the backbone for the description of calibration
and measurement information. According to the vendor, it is possible (by means of a published
API) to realize the integration of standard data descriptions like ASAM MCD 2MC [64] as well as
proprietary file formats used by specific OEMs or first-level suppliers.
CalDesk provides a wizard and template mechanism to automatically generate the folder
structures and basic settings for a project and experiment.
2.2.41 CANape

CANape [65] is a product of Vector Informatik GmbH (Stuttgart, Germany). This tool is established
in the market over several years and a new version (5.0) has been released in October 2003. For
accessing an ECU it mainly supports the serial calibration protocols CCP [63] and XCP [62].
As a highlight of the latest release CANape provides support for diagnostics data such that both
MC and D (for diagnostics) can be covered by a single tool. The tool comes in several variants, the
CANape standard version, CANape Graph, and the CANape server version.
Important components of CANape are the ASAP2 editor for administration of the description of
MC-relevant data as well as the CDM studio for data management. The latter provides means for
administrating parameter sets used in an ECU. Furthermore, the tool provides means for
programming the Flash memory of an ECU.
2.2.42 INCA

INCA [66] (short for Integrated Calibration and Application Tools) is one of the most established
tools on the market. The latest version is V4.0. ECU access is implemented by means of serial
calibration protocols (e.g. CCP [63]) or memory emulators, the so-called ETK.
INCA is shipped with several integrated tools:
Calibration Data Management (CDM): management of parameter
sets, compare program and data versions with each other
Measure Data Analyzer (MDA): analysis of acquired data
Variable User Interface Builder (VUI): creation of customer-specific
display screens for measurement and calibration variables in the
experiment environment
Flash tool (ProF): re-programming of Flash memory
5.8.2004 Version 1.0 93
2.2.43 Marc I

MARC I is a measurement and calibration system developed and distributed by AFT
Fahrzeugtechnik GmbH (Werdohl, Germany). The tool uses serial protocols like CCP [63] and
XCP [62] for accessing an ECU. MARC I is compatible to existing ASAM standards for description
of MC data and test bench automation.
2.2.44 TTP-Calibrate

TTP-Calibrate [67] has specially been developed to calibrate replicated, time-triggered real-time
systems. The tool has been developed by TTTech Computertechnik AG (Vienna, Austria) as part
of its TTP technology products.
According to the vendor, TTP-Calibrate operates directly on the corresponding Simulink model of
the vehicle function. For this purpose TTP-Calibrate has been tightly integrated with TTP-Matlink.
2.2.45 dSPACE Simulator
Automotive tools > Test systems and HIL simulators

The dSPACE Simulator [68] is like other dSPACE products tightly connected to
MATLAB/Simulink (see Item 2.2.26). Its main use cases are the verification of control algorithms
(incl. failure investigations), ECU calibration, integration tests in an ECU network, as well as the
test of diagnostics functionality.
The link between MATLAB/Simulink and the dSPACE simulator is provided by the dSPACE real-
time interface (RTI). The latter is provided as a comprehensive Simulink blockset.
The execution of actual HIL-simulations is supported by the ControlDesk software. Experiments
can be automated using the AutomationDesk software.
2.2.46 LabCar
Automotive tools > Test systems and HIL simulators

ETAS LabCar software consists of several components:
LabCar Operator for administrating real-time simulation of models.
During simulation, access to internal variables and parameters is
possible.
LabCar Developer is used to create own vehicle models or modifying
existing ones in terms of functionality
Labcar Automation is used to set up automated experiments for e.g.
regression test suites
Furthermore, pre-built models for various use cases are provided. The LabCar PinControl interface
supports the simulation of various failure modes of electrical systems.
2.2.47 CANdela Studio
Automotive tools > Tools for diagnostics
5.8.2004 Version 1.0 94

CANdela Studio [69] is developed and distributed by Vector Informatik GmbH. It features the
detailed description of diagnostic telegrams for various diagnostics protocols. Furthermore, it
provides a template mechanism by which means the tool can be adapted to specific customer
requirements.
CANdela Studio is tightly integrated with the CANdesc diagnostics embedded software component.
A code generator provides means for automatically generate and configure an instance of
CANdesc according to the description of diagnostics telegrams carried out by means of CANdela
Studio.
Furthermore, the tool is integrated with the CANoe tool. By this means the user has full access to
the diagnostics interface of (simulated) ECUs. As mentioned before (see Item 2.2.41), CANdela
studio collaborates with CANape by providing a diagnostics view for the latter.
2.2.48 Diagnostics Toolset (DTS)
Automotive tools > Tools for diagnostics

DTS is developed and distributed by Softing GmbH (Haar, Germany). The purpose of the tool is to
support ECU developers and test engineers. DTS supports several communication protocols used
for diagnostics purposes, such as ISO-9141, KWP 2000, EOBD, and CARB. Furthermore it can be
adapted to OEM-specific diagnostics protocols.
The basic diagnostics system can be adapted to customer-specific requirements by means of a
published API. DTS supports the usage of the ASAM MCD 2D description format and provides a
specific editor (VENICE) for viewing the contents of ASAM MCD 2D documents.
Furthermore, the tools CANDI (graphical user interface for test applications), TBX-pro (batch tool
for testing and Flash programming), and the Diagnostic Tester are members of DTS.
2.2.49 CANalyzer
Automotive tools > Analysis tools

CANalyzer [70] (by Vector Informatik GmbH, Stuttgart, Germany) is an established solution for
monitoring and analyzing data traffic on up to 32 CAN channels. The tool, currently available in
V5.0, provides a graphical interface which depicts data flow from the bus over the PC interface to
the various screen evaluation windows and to the log file.
Data traffic can either be illustrated on raw data level as well as on physical level. The
correspondence between raw and physical interpretation of a bus signal is interpreted on the basis
of the contents of a so-called CAN database.
According to the manufacturer, this database has become a de facto standard in the motor vehicle
industry. The user-friendly database management program CANdb++ is included with CANalyzer.
The functionality of CANalyzer can be extended by means of the C-like CAN Access Programming
Language (CAPL).
2.2.50 FaultTree+

The Isograph fault tree software FaultTree+ [71] is a fully interactive graphics and analysis
program for performing probabilistic risk assessment using integrated fault tree, event tree and
Markov analyses. The program runs under Microsoft Windows and is capable of analysing large
and complex fault and event trees producing the full minimal cut representation for fault tree TOP
events and event tree consequences.
5.8.2004 Version 1.0 95

FaultTree+ is used in all the safety process during safety assessment activity. The analysis is more
and more deep (fault tree more detailed) as the system development progresses. The main
modelling capability of FaultTree+ is pictorial representation of fault trees. FaultTree+ supports the
following quantitative failure models:
fixed unavailability and failure frequency model
constant failure and repair rate model
mean time to failure and repair model
dormant failure with periodic inspection model
sequential failure model
event tree initiator model
standby model
uncertainty values
The analyses supported by this tool are:
cut sets (qualitative analysis)
calculation of system unavailability and related parameters (e.g. total
system down time, number of failures over the observation time, etc.)
calculation of gates probabilities
importance analysis (e.g. Fussell-Vesely, Birnbaum, etc.)
time-dependent, sensitivity and confidence analysis
common cause failures
Event trees describe scenarios where more than one top level event occurs. This analysis
complements FTA because across-fault-tree dependencies can be visualized and computed.
2.2.51 IQ-FMEA

IQ-FMEA (APIS GmbH Wrth) is a tool to perform systematically a FMEA.
IQ-FMEA is a database with several editors to define technical systems (architecture, function- and
malfunction-interrelations) and supports standardized FMEA - Form Sheets. Further more the tool
supports developers at different locations to complete their tasks in a timely manner.
The FMEA-process supported by the tool is based on a guideline for System-FMEA published by
Verband der Automobilindustrie e.V.
System-FMEA is performed along the following steps:
1. Define the system structure
Using the structure-editor the user models the hierarchical system structure as a
component tree. Each node in the tree represents a system element, the links between
nodes represent has-part associations.
2. Define functions of system components
The user has to define functions for each system component. In order to specify
dependencies between functions the user has to build up a function network using the
function editor. Nodes in these networks represent functions, links show how a function is
composed by other functions of subcomponents.
3. Define malfunctions of system components
5.8.2004 Version 1.0 96
The definition of system structure and functions serve the purpose of deriving an extensive
collection of failure modes. Thus failure modes are derived from component function. The
easiest way to do so is to negate the functions: function component delivers output,
negation component does not deliver output.
Each malfunctions is thus associated with a function and via the function with a system
component.
The user can construct a kind of failure network in order to represent the dependencies
between malfunctions. IQ-FMEA supports a forward approach in order to generate the
FMEA formsheet, however the resulting failure net can be displayed as a preliminary fault
tree (this kind of tree is different form the fault tree used in FTA as this tree is not
generated in a top-down analysis of the system) which can hold the information of AND and
OR gates, but will only compute the OR-Logic.
4. Quantitative Analysis
Given failure rates and repair rates for every leaf in the fault tree, the values for
malfunctions of the system can be computed.
5. Concept optimization and definition of counter measures
For each system component a FMEA table will be automatically created. The user has now
to include suggestions for possible counter measures by which the failure can be prevented
or detected.
2.2.52 MISRA Checker

According to the vendor (Cosmic Software, Woburn, Massachusetts, USA), the Cosmic Software
MISRA Checker is a standalone software utility that aids in the production of well structured and
portable C language code using guidelines prescribed by MISRA.
In contrast to SQMlint (see Item 2.2.58), it can be used with any ANSI C compiler. It is, however,
specially tailored to integrate tightly with Cosmics own compiler tool suites.
2.2.53 ORA

ORA (Operational Reliability Analysis, developed by Frankfurt-Consulting Engineers)
The task of ORA is to perform the probabilistic analysis. The tool implements a stochastic model
for computation of time-dependent probabilities of system failures that meets the requirements by
the aviation industry for a safety and reliability assessment of technical systems. ORA allows to
compute: the probability of a Failure Condition during any flight of the aircraft life, the probability of
flight interruptions/cancellation, the operational reliability. The inputs include: reliability block
diagram, various life-time distributions, check intervals, tolerance time, repair time etc. Also
stochastic coupling between component failures are handled.
The ORA tool allows the user to define a non-homogenous discrete time Markov Chain with a finite
number of (system-) states. These states are the Cartesian-Product of component states.
Component states contain information e.g. about the age of a component, whether it is functioning
or failed (i.e. whether a certain failure exists or not), whether the failure has been detected or not.
A subset of (system-) states is interpreted as a failure of the system which is made up out of these
components. The probability that the system is in one of these failure states is computed by ORA.
The probability is a function of time.
The model is defined in terms of the following basic ingredients:
A list of components of a system
5.8.2004 Version 1.0 97
A text box associated with each component describing a failure in

plain English
A Distribution Function (Life Time Distribution allowing for description
of ageing)
A check interval for dormant failures
Description of stochastic dependencies between failures
A block diagram
ORA can be used in Preliminary System Safety Analysis (PSSA), System Safety Analysis (SSA)
and Operational Reliability Analysis.
2.2.54 Safety Checker Blockset

The blockset is provided by TNI-Valiosys. The purpose of the blockset is to provide means for
formally verifying Simulink models. According to the vendor, this method is superior to simply
carrying out (even a large number of) simulation experiments.
The model to be verified, however, is required to meet particular "Design for Verification" rules
described in the user manual of the blockset. TNI-Valiosys explicitly recommends the application of
the blockset to automotive models, e.g. for X-by-wire applications.
2.2.55 PC-lint

PC-lint from Gimpel Software (Collegeville, Pennsylvania, USA) is one of the most popular lint
derivates. Lint has been developed to carry out extensive source code analysis beyond the
detection of mere syntax errors. The tool is therefore supposed to be extremely useful for the
development of integrated safety systems.
The major problem of the proper use of lint is the configuration, i.e. the definition of relevant cases
to report and irrelevant cases to suppress. Without a proper configuration it could turn out that the
diagnostics messages issued by lint could not be reasonable analysed due to the sheer amount of
information.
2.2.56 SARAA

The SARAA tool (SAARA Safety and Reliability Analysis for Aircraft; developed by APSYS,
Toulouse) supports system level FHA (Functional Hazard Assessment), PSSA (Preliminary
System Safety Assessment), SSA (System Safety Assessment), and IECHA (Intrinsic /
Environmental Condition Hazard Analysis). It includes probability calculation via dependence
diagrams or fault trees, and tables for FMES. It includes the results of human factor analysis for
each system. Any imaginable functional or hardware /software failure can be integrated.
This SARAA tool interacts with the IQ-FMEA tool. The IQ-FMEA tool creates a DB with containing
some information, which is necessary for SARAA.
2.2.57 StackAnalyzer
5.8.2004 Version 1.0 98

The StackAnalyzer (provided by Vector Informatik GmbH) provides resources for determining the
stack usage of individual functions. By this means potential stack overflows can be detected and
avoided.
The result of the analysis is provided graphically in form of a function call tree. By this means
developers can conveniently browse the stack requirements of individual functions called by the
application software.
Please note that the availability of the StackAnalyzer is limited to certain microprocessor platforms,
i.e. Infineon C16x, Motorola MPC5xx and 68HC12, STMicroelectronics ST10.
2.2.58 SQMlint

SQMlint, developed by RENESAS (Tokyo, Japan), is a tool to inspect C source code according to
the MISRA C rules [34]. The product, however, cannot be used stand-alone but is an add-on to
RENESAS compiler products.
2.2.59 Statemate ModelChecker and ModelCertifier

For Statemate (see Item 2.2.29) two modules are available which provide formal verification
techniques. Statemate ModelChecker [72] is a tool for the System Development CASE Tool
Statemate Magnum. It supports the typical Statemate user with its daily work. The easy to use
(simple push button technology) tool is made for robustness checks and standard analysis to
prevent the user from typical design errors. Another key feature of the tool is the practically
automated debugging of typical modelling errors. Statemate ModelCertifier [73] extends the
functionality of the ModelChecker by providing verification techniques to certify a design by proving
the correctness of the requirements of a design.
2.2.60 Capital Analysis

Capital Analysis [74] is part of the Mentor Graphics integrated harness design environment
Capital Harness Systems. It provides automated FMEA and sneak path analysis at the
schematic level. The designer produces the schematic and incorporates functional models of the
various components (switches, modules, relays, etc.) along with a list of the failure modes
associated with the components including natural language descriptions of the failure modes. The
functional models are based either on logical expressions giving combinations of inputs and
outputs, or on state machines that can be designed in the tool or imported from other tools such as
Statemate.
A top-level set of functions is associated with the system, and the tool is able to generate an FMEA
report in a standard format with natural-language descriptions of the failure modes and their
effects. The calculation of risk priority numbers (RPN) in FMEAs is carried out automatically and
therefore with greater consistency than would be achieved by manual processes alone.
The tool is also capable of performing sneak circuit analysis based on comparing the functional
states of a circuit during various operational conditions (e.g. combinations of switch inputs) with the
expected functionality.
NB this product was formerly known as AutoSteve and was marketed by FirstEarth Ltd, a UK
company acquired by Mentor Grahics in 2003.
2.2.61 TTP-Verify
5.8.2004 Version 1.0 99

TTP-Verify (provided by TTTech, Vienna, Austria) is a tool for the verification of TTP [75] cluster
designs. According to the vendor, the role of this tool in the design process is to detect and
automatically analyze faults of cluster designs.
As a result, major savings are possible early in the design process by significantly reducing
expensive trial-and-error iterations during the verification and test phases. Please note that at the
time of this writing the product has not yet been released.
2.2.62 QA C and QA C MISRA

QA C is a deep-flow static analysis tool which will increase productivity and improve quality
standards in a C language development environment. QA C is designed to identify problems in C
source code that arise from language usage that is dangerous, over complex, non-portable, hard
to maintain or which simply diverge from local coding guidelines. It will warn about many issues
that are not reported by compilers or other development tools. QA C will significantly reduce the
time that needs to be spent in conducting code-reviews and will raise programmer awareness of
features of the C language which are often not fully understood. By drawing attention to problems
at an early stage in the development process, code quality will be improved and the testing cycle
will be shortened. So it improves the quality of C code and reduces future maintenance costs by
enhancing reliability, portability and maintainability.
Using the MISRA Compliance Module they are able to enforce compliance with the MISRA C
guidelines. With the aid of the MISRA Compliance module, analyses source code and detects
constructs, which do not comply with MISRA C rules. Rule violations are clearly identified in
annotated source code, code quality summary reports and a full suite of graphical views. One of
the most powerful features of is that it is highly configurable. Warning messages are directly linked,
via HTML, to all occurrences of that message within the analysed source code and also to the
appropriate MISRA rule reference. These references include explanatory examples of alternative
MISRA compliant code as well as providing a cross-reference to the rule definition.
This tool is used in automotive applications for a static analysis of code with 1200 rules, a
possibility of adding rules or controlling the level of compliance with the MISRA C rules.
2.2.63 Polyspace

Polyspace Developer Edition. Bug detection without testing. The earliest and easiest way to find
bugs in freshly written code. At compile time, without test cases to write and without execution of
the code. Includes:
Scalable abstract interpretion analysis techniques from file to full
software application
Desktop based solution at user's click distance
A ten fold reduction in debugging cost
A shortened time-to-market
Unparalled quality benefits
Available for Ada, C++ and C development languages.
5.8.2004 Version 1.0 100

Polyspace Auditor Edition. Source code verification for software applications that have to comply
with embedded system industry standards (DO-178B, MISRA). Fast, easy to use, repeatable and
low cost acceptance criteria for software applications. Includes:
Verification of compliance with standards through static analysis
Precise and automatic identification of software reliability breaches
Multi-task analysis for control and data coupling verification
Support documentation to meet with independent quality control
procedures
Qualification package upon request
Available for Ada, C++ and C development languages.
This tool permits the checking/validation of code with a simulation of the dynamic operation of a
program by mathematical algorithms, without execution of the code, and only the boundaries of
validity of the input and output signals are required.
This tool mainly identifies errors at run-time and dead code. It permits making the process more
robust.
2.2.64 eASEE
Automotive tools > Process tools

eASEE (electronic Automotive Systems Engineering Environment) is provided by Vector
Consulting GmbH (Stuttgart, Germany). Its purpose is to provide a framework for supporting the
development process of automotive software, in particular with respect to:
project management: administration of projects (i.e. planning, status
reports, life cycles, etc.), etc.
requirements management: tracking of requirements down to the
source code, etc.
configuration management: support of the entire development cycle,
etc.
calibration data management: administration of parameter variants,
etc.
All aspects of the development process for automotive software can be formalised by means of
dedicated workflows. Each workflow defines a sequence of operations to be carried out by specific
roles. Roles are implemented by process stakeholders who are supposed to process a specific
task list that is continuously updates as the workflow proceeds.
All components of eASEE are tightly integrated with each other and support according to the
vendor the collaboration of different organisations.
2.2.65 Tasking Development Tools
Automotive tools > Development tools

The Tasking development tools (provided by Altium, Sydney, Australia) are available for a wide
range of microcontrollers (Infineon TriCore and C166, STMicroelectronics ST10, Mitsubishi M16C,
Phillips XA, and 8051). The most popular platform, however, seems to be the Infineon C166.
Tasking provides integrated facilities for applying a conformance check according to the MISRA
C guidelines to the source code under compilation [78].
5.8.2004 Version 1.0 101

2.2.66 Wind River Diab C/C++ Compiler
Automotive tools > Development Tools

The Wind River (Alameda, California, USA) Diab C compiler is one of the most popular compiler
tool suites for the Motorola PowerPC platform, especially the MPC5xx. In general, however,
several other platforms, e.g. Motorola 68K, Hitachi SH, Mitsubishi M32R, and ARM cores are as
well available. Supported host platforms are various Windows derivates, Solaris, HP-UX, and Linux
2.2.67 Green Hills MULTI IDE
Automotive tools > Development tools

The Green Hills (Santa Barbara, California, USA) MULTI integrated development environment
(IDE) is an example of a tool suite that ships with integrated code coverage analysis capabilities.
This feature is supposed to have a positive impact on the development of automotive integrated
safety applications.
Green Hills MULTI is available for a variety of target platforms, e.g. Motorola PowerPC and 68K,
NEC V8xx, ARM cores. The set of supported host platforms consists of Windows, Solaris, HP-
UX/PA-RISC, Linux.
2.2.68 Proprietary in-house solutions
Automotive tools
Despite the trend to concentrate on the automotive core business, a multitude of companies still
use specially tailored in-house solutions developed in most cases by their own IT departments.
PSA use an in-house tool as part of the design process. The tool is used for the mapping of
functions on ECUs, and allows functional views for each ECU (internal and external functions), as
well as the resulting signals to be exchanged between ECUs.
PSA use an in-house tool for infrastructure and middleware design, which is a database of all the
frames of the communication system that have to be exchanged between ECUs
Although specific tools for measurement and calibration are available for many years now, the
share of in-house solutions of the overall "market" for measurement and calibration products is still
considered noticeably high. A similar trend may be observed for diagnostics tools.
5.8.2004 Version 1.0 102

3 Conclusions
3.1 Legislation
The present state-of-the-art is concerned with the Type Approval process that is aimed at
mechanically-based systems. The braking regulation contains an approval process for software-
based systems that is likely to be extended to other domains. The steering regulation is being
modified to permit approval of advanced systems. Work in research projects (notably the
RESPONSE series of projects) has identified the need for new processes and legislation to permit
the development and approval of advanced driver assistance systems. This is particularly
important in systems which may operate automatically without the possibility of the driver
overriding them (either because of their function or the reaction time involved).
3.2 Capability and maturity
The present state-of-the-art is concerned with attributes of the development process that are not
specifically concerned with safety. Safety attributes can be included, as has been done in the
space sector, but product assessment also needs to be included.
3.3 Safety
The concepts and principles of safety-related systems engineering are well known, and the most
relevant state-of-the-art is found in the MISRA Guidelines and IEC 61508. Several research
projects have looked at new techniques that can support the development of dependable
automotive systems. Further work is underway to adapt IEC 61508 specifically for the automotive
industry, and to transfer tools and techniques that have been successfully applied in other domains
(notably aerospace) to automotive systems.
3.4 Engineering
Each company (both OEM and supplier) has their own process and it is difficult to generalize a
state-of-the-art. However, these engineering processes have to be improved and adapted to the
requirements of Integrated Safety Systems of to meet future road safety targets. A gap analysis
has been presented of the way in which engineering processes need to be adapted.
3.5 Hardware and software components
For hardware and software, there are many different architectures in use ranging from vehicles
with few electronic modules through to luxury vehicles with many ECUs and several networks.
Standards are beginning to emerge for different safety aspects, notably in the powertrain and
chassis domains.
3.6 Automotive Tools
The evolution of automotive tools with respect to the emerging trend to use model-based design
methodologies facilitates the concentration on the actual engineering problem to solve. For
integrated safety systems, this trend obviously comes out right in time.
In particular, the following conclusions can be derived from the state-of-the-art of automotive tools:
The design of integrated safety systems should be based on as much as possible formal
and verifiable model descriptions (as opposed to the manual creation of source code
according to a prose requirements document).
5.8.2004 Version 1.0 103
The usage of simulation experiments, (formal) model checkers and/or modelling guidelines
is highly recommended.
The usage of automatic code generators is supposed to further contribute to reliability and
safety aspects of ECU software.
Of course, the test of ECU soft- and hardware using HIL technology is an important aspect
of integrated safety systems in terms of early elimination of potential hazards.
Some development systems (i.e. compiler, linker, etc.) provide some extended services
(e.g. MISRA checking, code coverage analysis) that are expected to have a positive impact
on the reliability of the integrated safety application.
5.8.2004 Version 1.0 104

4 Appendix
4.1 References
[1] IST Program EASIS project, Proposed structure for the state of the art deliverable of
D0.1, version 0.4, 12/2/2004, David Ward, MIRA.
[2] EAST-EEA project, Embedded Electronic Architecture, ITEA project 00009, Glossary, 30
October 2003.
[3] United Nations Economic Commission for Europe Regulation 10, Uniform provisions
concerning the approval of vehicles with regard to electromagnetic compatibility.
concerning the approval of vehicles with regard to braking.
concerning the approval of vehicles with regard to the installation of lighting and light-
signalling devices.
concerning the approval of vehicles with regard to steering equipment.
concerning the approval of vehicle alarm systems (VAS) and of motor vehicles with regard
to their alarm systems (AS).
concerning the approval of battery electric vehicles with regard to specific requirements for
the construction and functional safety.
[9] Statement of principles on human machine interface (HMI) for in-vehicle information and
communication systems, Official Journal of the European Communities, L19, pp. 64 68,
25 January 2000.
[10] RESPONSE Project information. <http://response.adase2.net/>
[11] UTMC 22 Project, Framework for the development and assessment of safety-related
UTMC systems. Available from <http://www.utmc.gov.uk/utmc22/pdf/utmc22-
framework.pdf>
[12] Commission Directive 95/54/EC adapting to technical progress Council Directive
72/245/EEC on the approximation of the laws of the Member States relating to the
suppression of radio interference produced by spark-ignition engines fitted to motor
vehicles and amending Directive 70/156/EEC on the approximation of the laws of the
Member States relating to the type-approval of motor vehicles and their trailers, Official
Journal of the European Communities, L266, 8 November 1995.
[13] CMMI Version 1.1, Carnegie-Mellon University, 2003.
<http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr011.pdf>
[14] ISO/IEC TR 15504, Information technology Software process assessment (in 9 parts),
ISO, 1998.
[15] Automotive SPICE working group.
[16] A. Cass, C. Vlcker, L. Winzer, J.M. Carranza and A. Dorling, SPiCE for SPACE: A
Process Assessment and Improvement Method for Space Software Development, ESA
Bulletin 107, August 2001.
[17] C. Vlcker, R. Ouared, H. Steinen, Taking SPICE to the third dimension: adding risk
analysis to ISO 15504, 14th International Conference on Software and System
Engineering and their Applications (ICSSEA 2001), Paris, December 2001; available from
<http://www.synspace.com>
[18] H. van Loon, R. Dietze, F.A. Montero, Software reuse and SPICE for SPACE, SPICE
2003, ESTEC, Noordwijk.
[19] O. Benediktsson, R.B. Hunter and A.D. McGettrick, Processes for Software in Safety
Critical Systems in Software Process: Improvement and Practice, volume 6, issue 1, pp.
47-62, 2001, John Wiley and Sons Ltd.
5.8.2004 Version 1.0 105
[20] IEC 61508, Functional Safety of Electrical, Electronic and Programmable Electronic
Safety-Related Systems (in 7 parts), IEC, 19982000.
[21] IEC 61508 FAQs, <http://www.iec.ch/zone/fsafety/questions.htm>
[22] Development Guidelines for Vehicle Based Software, MIRA, November 1994. Also
available as ISO/TR 15497:2000.
[23] EN 50126, Railway applications The specification and demonstration of Reliability,
Availability, Maintainability and Safety (RAMS), CENELEC, 1999.
[24] EN 50128, Railway applications Communication, signalling and processing systems
Software for railway control and protection systems, CENELEC, 2001.
[25] EN 50129, Railway applications Communication, signalling and processing systems
Safety related electronic systems for signalling, CENELEC, 2003.
[26] DO-178B, Software Considerations in Airborne Systems and Equipment Certification,
RTCA, 1999.
[27] ARP 4754, Certification Considerations for Highly-Integrated Or Complex Aircraft
Systems, SAE, 1996.
[28] ARP 4761, Guidelines and Methods for Conducting the Safety Assessment Process on
Civil Airborne Systems and Equipment, SAE, 1996.
[29] US Department of Defense: MIL-STD-882D, Standard Practice for System Safety, 10
February 2000 (http://www.safetycenter.navy.mil/instructions/osh/milstd882d.pdf)
[30] MATISSE project, Methodologies and Technologies for Industrial Strength Systems
Engineering, IST Contract 11435, MATISSE Handbook for Correct Systems Construction,
April 2003.
[31] SETTA project, Systems Engineering for Time Triggered Architectures, IST Contract
10043, Final Document, 18 April 2002.
[32] UK Defence Standards: Def Stan 00-56, Safety management requirements for defence
systems (Parts 1 and 2); Def Stan 00-55, Requirements for safety-related software in
defence systems (Parts 1 and 2); Interim Def Stan 00-54, Requirements for safety-related
electronic hardware in defence systems (Parts 1 and 2). In each case Part 1 is the
requirements and Part 2 guidance.
[33] Hazard classification for moving vehicle hazards Controllability, MISRA Technical
Report, version 1, May 2004, available at <http://www.misra.org.uk>.
[34] Guidelines for the Use of the C Language in Vehicle Based Software, MIRA, April 1998.
[35] Verband der Automobilindustrie e.V. (VDA): Ensuring reliability of car manufacturers and
suppliers reliability methods and aids, VDA Series on Quality Management in the
Automobil Industry, Volume 3, Part 2, 2000. This document is only published in German:
Zuverlssigkeitssicherung bei Automobilherstellern und Lieferanten
Zuverlssigkeitsmethoden und Hilfsmittel, VDA Schriftenreihe Qualittsmanagement in
der Automobilindustrie, Band 3, Teil 2, 2000.
[36] Verband der Automobilindustrie e.V. (VDA): Quality assurance of suppliers, VDA Series
on Quality Management in the Automobil Industry, Volume 2, 3rd edition, 1998.
[37] Verband der Automobilindustrie e.V. (VDA): Ensuring quality during product realization,
methods and procedures System FMEA, VDA Series on Quality Management in the
Automobile Industry, Volume 4, Chapter 3, 2nd edition, 2003. This document is only
published in German: Sicherung der Qualitt whrend der Produktrealisierung, Methoden
und Verfahren System FMEA, VDA Schriftenreihe Qualittsmanagement in der
Automobilindustrie, Band 4, Kapitel 3, 2. Auflage, 2003.
[38] Verband der Automobilindustrie e.V. (VDA): Ensuring quality during product realization,
methods and procedures Fault Tree Analysis, VDA Series on Quality Management in
the Automobile Industry, Volume 4, Chapter 4, 4th edition, 2003. This document is only
published in German: Sicherung der Qualitt whrend der Produktrealisierung, Methoden
und Verfahren Fehlerbaumanalyse, VDA Schriftenreihe Qualittsmanagement in der
Automobilindustrie, Band 4, Kapitel 4, 4. Auflage, 2003.
[39] Verband der Automobilindustrie e.V. (VDA): Development of software dominated systems
Requirements for processes and products, VDA Series on Quality Management in the
Automobile Industry, Volume 13, 1st edition, 2002. This document is only published in
German: Entwicklung softwarebestimmter Systeme Forderungen an Prozesse und
Produkte, VDA Schriftenreihe Qualittsmanagement in der Automobilindustrie, Band
5.8.2004 Version 1.0 106
13, 1. Auflage, 2002.

[40] V-Model 97, Lifecycle Process Model -Developing Standard for IT Systems of the Federal
Republic of Germany. General Directive No. 250. June 97, available e.g. from
<http://www.v-modell.iabg.de/vm97.htm>
[41] ETAS GmbH: ASCET-SD White Paper, Version 4.2, September 2003 (in German),
<http://www.etasgroup.com/downloads/ascetsd_wp_de.pdf>
[42] ETAS GmbH: ASCET-SD Product Brochure, Version 4.2, August 2002,
<http://www.etasgroup.com/downloads/ascetsd_br_en.pdf>
[43] Schtz, B; Huber, F.: Specifying distributed Systems with AutoFOCUS, Technical
University of Munich, Department of Computer Science, 1996,
<http://autofocus.in.tum.de/Infos/afinfo-en.html>
[44] I-Logix Inc, Rhapsody in C++,
<http://www.ilogix.com/products/rhapsody/rhap_incplus.cfm>
[45] I-Logix Inc, Rhapsody in C, <http://www.ilogix.com/products/rhapsody/rhap_inc.cfm>
[46] Esterel Technologies, <http://www.esterel-technologies.com>
[47] Hoffmann, H.-P.: The automotive Approach to using Statemate MAGNUM and Rhapsody
MicroC, Whitepaper, I-Logix Inc., Andover, MA, USA,
<http://www.ilogix.com/whitepaper_PDFs/CONCEPT_TO_CODE.pdf>
[48] I-Logix Inc.: Statemate MAGNUM Product Brochure, I-Logix, Andover, MA, USA, 2003,
<http://www.ilogix.com/products/magnum/Brochure/StatemateMAGNUMBrochure(V3).pdf>
[49] dSPACE GmbH: More than just a Production Code Generator, product catalog, 2004,
<http://www.dspace.de/shared/data/pdf/katalog2004/dspace_catalog2004_targetimplemen
tation.pdf>
[50] Telelogic ObjectGeode, < http://www.telelogic.com/products/additional/objectgeode>
[51] The Mathworks Real-Time Workshop Embedded Coder

<http://www.mathworks.com/products/rtwembedded/>
[52] Esterel Technologies SCADE Drive 4.3 for Automotive <http://www.esterel-
technologies.com/v3/?id=13282>
[53] Vector Informatik GmbH: CANoe/DENoe User Manual, V4.1, <http://www.vector-
informatik.com/support/manuals/CANoe_Manual_EN.pdf>
[54] Kiencke U.; Dais, S.; Litschel, M.: Automotive Serial Controller Area Network, SAE 86,
Detroit MI, USA, SAE-Paper 860391, 1986
[55] Davinci tool suite, Vector Informatik..
<http://www.vector-informatik.com/english/index.html?../products?davinci.html>
[56] Kiencke, U.: Controller Area Network - From Concept to Reality, Proceedings of the 1st
international CAN Conference (iCC), Erlangen, Germany, 1994
[57] TTTech Computertechnik AG: TTPPlan The TTP Cluster Design Tool, Product Flyer,
http://www.tttech.com/products/software/ttpplan/TTTech-TTP-Plan-Flyer.pdf
[58] TTTech Computertechnik AG: TTPBuild The TTP Node Design Tool, Product Flyer,
<http://www.tttech.com/products/software/ttpbuild/TTTech-TTP-Build-Flyer.pdf>
[59] Volcano Automotive Group: VNA Concept Sheet,
<http://www.volcanoautomotive.com/pdf/Product_Brochures/Concept_web.pdf>
[60] TNI-Software RT-Builder
<http://www.vnvware.com/?p=products&ss=rtbuilder&type=overview>
[61] dSPACE GmbH: CalDesk the Experiment Software for Calibration, product catalog,
2004,
<http://www.dspace.de/shared/data/pdf/katalog2004/dspace_catalog2004_calibration.pdf>
[62] ASAM: MCD1 XCP The Universal Measurement and Calibration Protocol Family,
Version 1.0, April 2003, <http://www.asam.de/new/docs/xcp_universal-measurement-and-
calibration.zip>
[63] ASAM: MCD1 CAN Calibration Protocol, Version 2.1, February 1999,
<http://www.asam.de/new/docs/MCD-19-NAP-CC-R-0201-E.pdf>
[64] ASAM: MCD 2MC - ASAP2 Interface Specification, Version 1.51, November 2003,
5.8.2004 Version 1.0 107

<http://www.asam.de/new/docs/P05-01-2MC-1-51.zip>
[65] Vector Informatik GmbH: CANape & CANape Graph User Manual, Version 5.0,
<http://www.vector-informatik.com/support/manuals/CANape_Manual_EN.pdf>
[66] ETAS GmbH: INCA Product Brochure, August 2002,
<http://www.etasgroup.com/downloads/inca_br_en.pdf>
[67] TTTech Computertechnik AG: Testing and Validating Time-Triggered Bus Systems, 2003,
<http://www.tttech.com/technology/docs/general/TTTech-TTP-Calibrate-and-TTP-
Verify.pdf>
[68] dSPACE GmbH: Cutting-Edge Systems for ECU/Controller Testing, product catalog, 2004,
<http://www.dspace.de/shared/data/pdf/katalog2004/dspace_catalog2004_ecu-
testing.pdf>
[69] Vector Informatik GmbH: CANdela Studio User Manual, Version 2.0, <http://www.can-
diagnostics.com/index.html??candela_studio.php>
[70] Vector Informatik GmbH: CANalyzer/DENalyzer User Manual, V4.1, <http://www.vector-
informatik.com/support/manuals/CANalyzer_Manual_EN.pdf>
[71] Fault Tree+ <http://www.isograph-software.com/ftpover.htm>
[72] Statemate ModelChecker <http://www.osc-es.de/products/en/modelchecker.php>
[73] Statemate ModelCertifier <http://www.osc-es.de/products/en/modelcertifier.php>
[74] Capital Analysis Tools, <http://www.mentor.com/harness/analysis.html>
[75] Poledna, St.; Kroiss, G.: The Time-Triggered Communication Protocol TTPTM/C, Real-
Time Magazine, April 1998, <http://www.tttech.com/technology/docs/history/Real-Time-
Magazine_1998-04-The_Protocol_TTP-C.pdf>
[76] Programming Research Ltd, QA C and QA C MISRA
<http://www.programmingresearch.com>
[77] Polyspace Technologies <http://www.polyspace.com/datasheets/datasheets.htm>
[78] Tasking: MISRA C code checking, Product brochure, 2001
[79] CAN-bus: < http://www.can.bosch.com/
[80] LIN-bus: < http://www.lin-subbus.org/
[81] Bluetooth protocol: <www.bluetooth.com/>
[82] MOST protocol: < http://www.mostnet.de/>
[83] IEEE 1394: < http://bmrc.berkeley.edu/courseware/cs298/spring96/dscheel/
[84] Flexray: <www.flexray.com>
[85] OSEK: < www.osek-vdx.org>
[86] Standardisation of Application/Calibration Systems: <www.vector-cantech.com>
[87] CCP Specification version 2.1-February 18th 1999 on ASAM Website:<www.asam.de>
[88] CCP Vector application note AN37-12, July 2001
[89] K-line: ISO 9141 Road vehicles -- Diagnostic systems -- Requirements for interchange of
digital information: <www.iso.org>
[90] KWP 2000 (Keyword protocol 2000): ISO 14230 Road vehicles -- Diagnostic systems --
Keyword Protocol 2000: <www.iso.org>
[91] Diagnostic on CAN: ISO 15765: <www.iso.org>
[92] ISO/ WD 15765-2 Road Vehicles - Diagnostic Systems, Part 2: Network layer services
June, 24th 1998: <www.iso.org>
[93] System safety in computer-controlled automotive systems, Nancy G. Leveson, SAE
Congress, March 2000. <http://sunnyday.mit.edu/papers/sae.pdf>
[94] HAZOP studies on systems containing programmable electronics, Interim Defence

Standard 00-58, UK. <http://www-scm.tees.ac.uk/hazop/html/58.htm>
5.8.2004 Version 1.0 108

[95] Safeware: System safety and computers, Nancy G. Leveson, Addison-Wesley, 1995.
<http://www.safeware-eng.com/index.php/publications/booktoc>
[96] Software deviation analysis: A Safeware technique, Jon Damon Reese and Nancy G.
Leveson, AIChe 31st Annual Loss Prevention Symposium, Houston, Texas, March 1997.
<http://sunnyday.mit.edu/papers/cels97.pdf>
[97] Preserving system safety across the boundary between system integrator and software
contractor, Jeffrey Howard, SAE 04AE-144, 2004.
<http://www.safeware-eng.com/publications/04ae-144.doc>
[98] Product line approach to software development, Carnegie Mellon Software Engineering
Institute. <http://www.sei.cmu.edu/plp/plp_init.html>
[99] Software architecture technology initiative, Carnegie Mellon Software Engineering Institute.
<http://www.sei.cmu.edu/architecture/sat_init.html>
[100] Predictable assembly from certifiable components (PACC) initiative, Carnegie Mellon
Software Engineering Institute. <http://www.sei.cmu.edu/pacc/pacc_init.html>
[101] Reusable specification components for model-driven development, Kathryn Anne Weiss,
et al, INCOSE 2003. <http://sunnyday.mit.edu/papers/incose.pdf>
[102] Evolutionary Project Management & Product Development, Kai Gilb, 2003.
<http://www.gilb.com/Download/EvoProjectMan.pdf>
[103] A Requirements Modeling Framework for High Integrity Software-Intensive Automotive
Product Lines, Sushil Birla (General Motors), Ramin Tavakoli Kolagari (DaimlerChrysler),
MKWI 2004, Multikonferenz Wirtschaftsinformatik, Teilkonferenz 8: Software-Produktlinien,
2004-03-10.
[104] Completeness in formal specification design for process control systems, Nancy G.
Leveson, Proceedings of Formal Methods in Software Practice Conference, August 2000.
<http://sunnyday.mit.edu/papers/completeness.pdf>
[105] Completeness and consistency in hierarchical state-based requirements, Mats P.E.
Heimdahl and Nancy G. Leveson, IEEE Transactions on Software Engineering, May 1996.
<http://sunnyday.mit.edu/papers/mats-tse.pdf>
[106] Formal analysis of hierarchical state machines, Rajeev Alur, University of Pennsylvania.
<http://www.cis.upenn.edu/~alur/Talks/hsm03.PDF>
[107] M. Weber, J. Weisbrod, Requirements Engineering in Automotive Development:
Experiences and Challenges, IEEE Software, Jan/Feb 2003.
[108] Competitive Engineering, Tom Gilb, 2003.
<http://www.gilb.com/Download/CompetitiveEng.pdf>
[109] Making formal methods practical, Marc Zimmerman, et al, Digital Aviation Systems
Conference, Oct 2000. <http://sunnyday.mit.edu/papers/dasc-fm.pdf>
[110] Enhanced safety assessment for complex systems, ESACS Technical and scientific
objectives. <http://www.cert.fr/esacs/overview.html>
[111] How AP233 supports a systems engineering process, ISO.
<http://step.jpl.nasa.gov/AP233/>
[112] Requirements engineering knowledge management based on STEP AP233,
Heimannsfeld, K. and Mueller, D., IMW Institutsmitteilung Nr. 25, 2000.
<http://www.imw.tu-clausthal.de/inhalte/forschung/publikationen/
mitteilungen/25/pdf/2000_073_heimannsfeld.pdf>
[113] ISO STEP System Engineering Project (ISO 10303 AP233), PDES, Inc.
<http://pdesinc.aticorp.org/systems_engineering.html>
[114] Enhanced safety assessment for complex systems, ESACS Technical and scientific
objectives. <http://www.cert.fr/esacs/overview.html>
[115] QFD for software development considering future design risks, Yuji Kyoya, et al, Software
th
Engineering Center, Toshiba Corporation, Japan, 9 International symposium on QFD,
2003.
[116] Advanced design tools for safety critical software, SAFEAIR II, IST-2001-34263. Project
URL: http://www.safeair2.org/download/34363_safeairii_project_pres_v1-0b.doc
[117] Formal verification of reactive system designs overview, Dr. Bernhard Josko, et al.
OFFIS project. <http://www.safeair.org/safeair/workplan/overview_verification_talk.pps>
5.8.2004 Version 1.0 109

[118] IEEE 100, The Authoritative Dictionary of IEEE Standard Terms
[119] FAR EAST: Modeling an automotive software architecture using the EAST ADL, Henrik
Loenn, et al. <http://www.mrtc.mdh.se/publications/0698.pdf>
[120] Correct development of real-time embedded systems, IST-2001-33522 OMEGA.
<http://www-omega.imag.fr>
[121] VEESA project, IST-2001-37598, Deliverable D3: System Level Certification
[122] Stability analysis for hybrid automata using conservative gains, Rom Langerak, et al,
<http://www.nlr.nl/public/hosted-sites/hybridge/documents/R4.4%20final.pdf>
[123] Hybrid automata: An algorithmic approach to the specification and verification of hybrid
systems, Rajeev Alur, et al.
<http://www-cad.eecs.berkeley.edu/~tah/Publications/hybrid_automata.pdf>
[124] A. Pnueli, O. Shtrichman, and M. Siegel: The Code Validation Tool (CVT) - Automatic
verification of a compilation process. Journal of Software Tools for Technology Transfer
(STTT), Vol 2(2), pp 192-201, 1998
[125] W. Damm, B. Josko, H. Hungar, and A. Pnueli. A compositional real-time semantics of
STATEMATE designs. In W.-P. de Roever, H. Langmaack, and A. Pnueli, editors,
Proceedings COMPOS'97, Lecture Notes in Computer Science 1536, pages 186-238.
Springer-Verlag, 1998
[126] W. Damm, B. Josko, A. Pnueli, and A. Votintseva. Understanding UML: A Formal
Semantics of Concurrency and Communication in Real-Time UML. In Proceedings of the
First International Symposium on Formal Methods for Components and Objects (FMCO),
LNCS. Springer-Verlag, 2003.
[127] T. Bienmller, J. Bohn, H. Brinkmann, U. Brockmeyer, W. Damm, H. Hungar, and P.
Jansen. Verification of automotive control units. In E.-R. Olderog and B. Steffen, editors,
Correct System Design, volume 1710 of LNCS, pages 319-341. Springer Verlag, 1999.
[128] T. Bienmller, U. Brockmeyer, W. Damm, G. Dhmen, C. Emann, H.-J. Holberg, H.
Hungar, B.Josko, R. Schlr, G. Wittich, H. Wittke, G. Clements, J. Rowlands, and E.
Sefton. Formal Verification of an Avionics Application using Abstraction and Symbolic
Model Checking. In F. Redmill and T. Anderson, editors, Towards System Safety --
Proceedings of the Seventh Safety-critical Systems Symposium, Huntingdon, UK, pages
150-173. Safety-Critical Systems Club, Springer, 1999.
[129] W. Damm and M. Cohen. Advanced validation techniques meet complexity challenge in
embedded software development. Embedded Systems Journal, 2001.
Table 9: list of documents and sources
5.8.2004 Version 1.0 110

Electronic Architecture and System Engineering Fo

Uploaded by

Copyright:

Available Formats

You might also like

Electronic Architecture and System Engineering Fo

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Electronic Architecture and System Engineering Fo

Uploaded by

Copyright:

Available Formats

European Commission

Contract number: 2002 - 507690

Electronic Architecture and System Engineering for

Report type Deliverable D0.1.2

Report status: Public

Version number: Version 1.0

Date of preparation: 5.8.2004

2004 The EASIS Consortium

Version Date Reason

2.2.21 ESACS project .................................................... 6

5.8.2004 Version 1.0 iV

2.2.59 Statemate ModelChecker and ModelCertifier ..... 6

5.8.2004 Version 1.0 iV

5.8.2004 Version 1.0 1

Area of gap Size of gap Impact on safety

5.8.2004 Version 1.0 2

1 Objectives and deliverables of WT 0.1.2

1.1 WT 0.1.2 objectives

1.2 Details of WT 0.1.2 deliverables

5.8.2004 Version 1.0 3

2.1 Summary of findings

2.1.1 State of the art of legislation

5.8.2004 Version 1.0 4

2.1.1.3 Body functions

5.8.2004 Version 1.0 5

2.1.1.5 Human-machine interface

2.1.1.6 Future legislation

5.8.2004 Version 1.0 6

2.1.2 State of the art of capability and maturity

The following subjects were investigated:

2.1.2.1 Capability levels

Capability level CMMI Staged CMMI Continuous ISO 15504

Safety Does not imply Process

Figure 1: Relationship between SIL and CMMI level

2.1.2.2 Process reference models

2.1.2.3 Process attributes

No specific process attributes relative to safety have been identified so far.

2.1.2.4 Key processes

No specific key processes relative to safety have been identified so far.

2.1.3 State of the art of safety

The following subjects were investigated:

2.1.3.1 Safety lifecycles

5.8.2004 Version 1.0 9

2.1.3.2 Hazard identification and classification

2.1.3.3 Techniques for hazard analysis

5.8.2004 Version 1.0 11

2.1.3.4 Design requirements for safety-related hardware

5.8.2004 Version 1.0 12

In decreasing order of preference, the alternative measures for risk

2.1.3.5 Design requirements for safety-related software

2.1.3.6 Safety proof

5.8.2004 Version 1.0 13

2.1.3.7 Safety assessment

2.1.4 State of the art of engineering

2.1.4.1 A representative engineering process from current practice

Simulation Based Management

Figure 2: Example of a vehicle design process

5.8.2004 Version 1.0 16