Guidelines For Safety Analysis of Vehicle Based Programmable Systems

The Motor Industry Software Reliability Association
Licensed to: Lear Corporation

Jose Luis Vicente. 17 Dec 2007. Copy 1 of 1
November 2007
First published November 2007
by MIRA Limited
Watling Street
Nuneaton
Warwickshire CV10 0TU
UK
www.misra.org.uk
© MIRA Limited, 2007.
“MISRA” and the triangle logo are registered trademarks of MIRA Limited, held on behalf of the
MISRA Consortium.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or trans-
mitted in any form or by any means, electronic, mechanical or photocopying, recording or otherwise
without the prior written permission of the Publisher.
ISBN 978-0-9524156-5-7 (paperback)

ISBN 978-0-9524156-7-1 (PDF)
British Library Cataloguing in Publication Data.

A catalogue record for this book is available from the British Library
This copy of Guidelines for safety analysis of vehicle based programmable systems is issued to
Jose Luis Vicente of Lear Corporation at C/ Fusters, 54-56 -Poligono Industrial-, Valls, Tarragona,
43800.
The file must not be altered in any way. No permission is given for distribution of this file. This
includes but is not exclusively limited to making the copy available to others by email, placing it
on a server for access by intra- or inter-net, or by printing and distributing hardcopies. Any such
use constitutes an infringement of copyright.
MISRA gives no guarantees about the accuracy of the information contained in this PDF version of
the Guidelines. The published paper document should be taken as authoritative.
Information is available from the MISRA web site on how to purchase printed copies of the
document.

The Motor Industry Software Reliability Association
Guidelines for
Safety Analysis
of Vehicle Based
Programmable
Systems
November 2007
i
MISRA Mission Statement: To provide assistance to the automotive industry in the application and cre-
ation within vehicle systems of safe and reliable software.
MISRA, The Motor Industry Software Reliability Association, is a collaboration between vehicle man-
ufacturers, component suppliers and engineering consultancies which seeks to promote best practice in
developing safety-related electronic systems in road vehicles and other embedded systems. To this end
MISRA publishes documents that provide accessible information for engineers and management, and
holds events to permit the exchange of experiences between practitioners.
Disclaimer
Adherence to the requirements of this document does not in itself ensure error-free robust software.
Compliance with the requirements of this document, or any other standard, does not of itself confer
immunity from legal obligations.
ii
Executive summary
These Guidelines provide an extension to the original MISRA Development Guidelines for Vehicle
Based Software, in that they give extended detailed advice on the sections on Integrity and Safety
Analysis, as well as presenting additional advice on other parts of safety management and the safety life-
cycle.
This subject matter is being used increasingly to enable new programmable systems to be deployed onto
vehicles, and will become automotive best practice when the ISO 26262 standard is published.
The Guidelines begin by explaining why it is necessary to provide an approach for automotive systems
that it different to those provided in the current standards, in particular IEC 61508. It describes how the
safety lifecycle for automotive systems fits into the total development lifecycle of a vehicle, and descrip-
tions are given of the various plans and other documents that are needed in order to manage that safety
lifecycle effectively.
The process of Preliminary Safety Analysis on a system concept or outline design is described in some
detail. Guidance is given on how to model the system and use this model to identify hazards. A scheme
for classifying hazards, the MISRA Risk Graph, is introduced which extends the original classification
scheme described in MISRA Development Guidelines for Vehicle Based Software. It is then shown how
the resulting Risk Levels can be translated into safety integrity requirements. A set of possible quanti-
tative requirements is also presented.
The process of Detailed Safety Analysis on a design, by which the safety integrity requirements can be
verified and validated, is then outlined. The Guidelines propose the use of both deductive analysis, e.g.
FMEA, and inductive analysis, e.g. FTA, as part of this procedure.
The contents of these Guidelines have been reviewed extensively both by their primary authors, as well
as by an international panel of experts from Europe, North America and Japan.
iii
Acknowledgements
The MISRA consortium would like to thank the following individuals for their significant contribution
to the writing of this document:
Richard Evans Jaguar Cars

Paul Groves Land Rover
Katrin Hartwig Deutsches Zentrum für Luft- und Raumfahrt
Edith Holland Jaguar Cars
Peter Jesty The University of Leeds
Keith Longmore Lotus Engineering
Frank O’Neill TRW
Roger Rivett Land Rover
David Ward MIRA Limited
The MISRA consortium also wishes to acknowledge contributions from the following individuals
during the development and review process:
Henrik Aidnell Jan Jacobson Steve Minns

Andy Ashworth Stuart Jobbins Yasuharu Nishi
Per-Olov Brandt Lars-Åke Johansson Felix Redmill
Olle Bridal Shigeyuki Kawana George Romanski
David Farr Takehisa Kohda Walter Schilling
Takao Futagami Toshiyuki Kuwayama Thomas Schmitt
Robert Gruszczynski Clive Lee Paul Simpson
Max Halbert Sabine Marksell Michele Tedeschi
Simon Hughes Robert Marshall András Toth
David Jackson Tohru Matsuodani Udo Voges
The comments and contributions made by the SESSAME/CROSV and JasPar groups in Japan are also
gratefully acknowledged.
iv
Contents
1. Introduction 1
1.1 A changing situation 1
1.2 The purpose of these Guidelines 2
1.3 Systems engineering 3
1.4 Relationship with IEC 61508 and Def Stan 00-56 4
1.5 The structure of this document 6
2. Safety management 8
2.1 Introduction 8
2.2 Organizational structure 9
2.3 Safety culture 9
2.4 Safety Policy 10
2.5 Project Safety Plan 10
2.6 Safety envelope 11
2.7 Safety Argument and Safety Case 12
2.8 Competencies 13
2.9 Claiming compliance 14
3. Overview of the MISRA Safety Process 15

3.1 Introduction 15
3.2 The safety lifecycle 15
3.3 Vehicle development 19
3.4 The MISRA System Safety Analysis Process 22
3.5 Overview of PSA 24
3.6 Overview of DSA 27
4. Preliminary safety analysis 31

4.1 Introduction 31
4.2 System and environment modelling 34
4.3 Hazard identification 35
4.4 Hazard classification 38
4.5 Risk assessment and system safety requirements 53
4.6 Conclusion of preliminary safety analysis 60
5. Detailed safety analysis 61

5.1 Introduction 61
5.2 System design 62
5.3 Inductive analysis 64
5.4 Deductive analysis 65
5.5 Results analysis 67
5.6 Results summary 70
6. References 71
v
Contents (continued)
Appendix A: Boundaries and hazard identification models 74

A.1 System and environmental model 74
A.2 Open TOEs 75
A.3 Closed TOEs 76
Appendix B: “What if?” analysis 80
Appendix C: Advice on performing HAZOP 82
Appendix D: Controllability 84
D.1 Introduction 84
D.2 Controllability parameters 86
D.3 Controllability classification 89
Appendix E: Quantitative acceptable hazard occurrences 92

E.1 Definition of Broadly Acceptable Risk 92
E.2 Derivation of Target System Safety Requirements 92
Appendix F: Advice on performing FMEA 95
Appendix G: Advice on performing FTA 97
vi
Abbreviations
ABS anti-lock braking system
ALARP as low as reasonably practicable
ASIC application specific integrated circuit
DSA detailed safety analysis
E/E electrical and/or electronic
ECU electronic control unit
ETA event tree analysis
EUC equipment under control
FMEA failure mode and effects analysis
FMECA failure mode, effects and criticality analysis
FTA fault tree analysis
HAZOP hazard and operability study
HMI human-machine interaction/interface
HSE Health and Safety Executive (UK)
IEC International Electrotechnical Commission
LRU line replaceable unit
MAIS maximum abbreviated injury severity
MEM minimum endogenous mortality
MISRA Motor Industry Software Reliability Association
MoD Ministry of Defence (UK)
NR no risk
PASSPORT Promotion and Assessment of System Safety and Procurement of Operable

and Reliable road transport Telematics (European project)
PSA preliminary safety analysis
RPN risk priority number
SIL safety integrity level
SRfP software readiness for production
TOE target of evaluation
vii
Glossary of terms
Words in italics in the definitions are also defined in this table.
Term Definition
Base Element The lowest level of system decomposition to be studied as a unit.
Broadly Acceptable Risk Risk which is accepted in a given context based on the current values
of society.
Common Cause Failure The result of an event which, because of dependencies, causes a
coincidence of failure states in two or more components (excluding
secondary failures caused by the effects of the primary failure).
Configuration Management Discipline of identifying the components of an evolving system for the
purposes of controlling changes to those components and maintaining
continuity and traceability throughout the lifecycle.
Cut-set A term used in fault trees for the combinations of base events that can
cause the top event.
Dangerous Failure Failure which has the potential to put the safety-related system into a
hazardous state.
Error Discrepancy between a computed, observed or measured value or

condition and the true, specified or theoretically correct value
or condition.
Fault Abnormal condition that may cause a reduction in, or loss of, the
capability of a functional unit to perform a required function.
Failure Termination of the ability of a functional unit to perform a

required function.
Failure Mode The effect by which a failure is observed in a system component.
Harm Physical injury or damage to the health of people either directly, or

indirectly, as a result of damage to property, or to the environment.
Hazard Potential source of harm.
Hazard Analysis The process of analysing a concept or design to identify hazards.
Hazardous Event Hazardous situation which results in harm. Note: this document is only
concerned with hazardous events that result from technological causes.
Hazardous Situation Circumstance in which a person is exposed to hazard(s).
Hazard List A formal list of the hazards that have been associated with the system
of interest.
viii
Glossary of terms (continued)
Hazard Log See Hazard List
Human Error Human action or inaction that can produce an unintended result
— a possible cause of a fault.
Impact Analysis Activity of determining the effect that a change to a function or

component in a system will have on the other functions or components
in that system as well as on other systems.
Mistake See Human Error
Quality The degree to which a set of inherent characteristics fulfils

stated requirements.
Quality Culture The extent to which all of an organization’s members are motivated
towards, and involved in, the development and manufacture of
a quality product.
Quality Plan A formal statement of the necessary operational processes and related
resources to fulfil the quality objectives.
Random Hardware Failure Failure, occurring at a random time, which results from one or more of the
possible degradation mechanisms in the hardware.
Residual Risk Risk remaining after protective measures have been taken.
Risk Combination of the frequency, or probability, of occurrence of harm and

the severity of that harm.
Safety Freedom from unacceptable risk (see broadly acceptable risk).
Safety Argument The logical structure of a safety case.
Safety Case A formal presentation of evidence, arguments and assumptions aimed at

providing assurance that a system has met its safety requirements and
that the safety requirements are adequate.
Safety Culture The extent to which all of an organization’s members are motivated
towards, and involved in, identifying and reducing hazards and risks
to themselves and to others.
Safety Envelope The safety envelope defines the operational and environmental limits
within which the system is expected to behave in a safe manner.
Safety Functions Functions to be implemented by a safety-related system, which are

intended to maintain a safe state in respect of specified hazards.
ix
Glossary of terms (continued)
Safety Integrity The degree of confidence in a safety-related system satisfactorily

performing the required safety functions under all the stated conditions
within a stated period of time.
Safety Integrity Level Discrete level for specifying the safety integrity requirements of the
safety functions allocated to the safety-related systems, where SIL 4 has
the highest level of safety integrity and SIL 1 has the lowest.
Safety Plan A formal statement of the specific actions, resources, roles,

responsibilities, deviations, limits etc. needed to assure that a safe product
is developed and manufactured.
Safety Policy A formal statement of a company’s or organization’s strategy for

encouraging and maintaining safety.
Safety-Related System A designated system that:

• Implements the required safety functions necessary to achieve or
maintain a safe state for the total system; and
• Is intended to achieve, on its own or with other systems, the
necessary safety integrity for the required safety functions.
Safety Requirements The requirements of the safety functions that have to be fulfilled by the
safety-related system.
Systematic Failure Failure related in a deterministic way to a certain cause, which can only
be eliminated by a modification of the design or of the manufacturing
process, operational procedures, documentation or other relevant factors.
Terminator An external entity with which the system communicates.
Tier 1 Supplier A supplier with prime design responsibility for key subsystems or
components of the end product.
Type Approval The procedure whereby a Member State certifies that a type of vehicle,
system, component or separate technical unit satisfies the relevant
technical requirements of the relevant Directives. Certification is
conducted by the Type Approval Authority of the Member State generally
assisted by Technical Services appointed by them to perform various
testing and administrative functions.
Vehicle Hazard A hazard that relates to the use of one, or more, vehicle(s); it can manifest
itself both inside and/or outside the vehicle.
Vehicle Hazard Boundary The interface between the vehicle and its environment.
x
Preface
The number, interconnectivity, interdependency and complexity of programmable electronic systems fit-
ted to vehicles, or provided as part of the road transport infrastructure, is growing. In many cases the
correct operation of these systems is essential for the well being of the vehicle occupants, the occupants
of other vehicles and those in the environment through which the vehicle passes.
The term safety can relate to a number of different issues, indeed many languages have the same word
for both safety and security. In this document the term safety will normally relate to functional system
safety, where the concern is the result of the unsafe behaviour of a vehicle system that is usually, but not
always, due to a failure of a component. Such behaviour relates to cases where a vehicle system fails to
operate, operates incorrectly, operates when it is not required to do so, or is operated in an unintended
manner, or operates correctly in conjunction with one or more other systems, or conditions, such that
dangerous behaviour results. Some vehicle system failures can result in fire, the emission of hazardous
fluids etc., and so these are also the subject of this document. The document is not concerned with issues
such as mechanical vehicle safety (crash regulations), manufacturing plant safety, or health and safety at
work, which are all covered by appropriate existing regulations.
In order for the automotive industry to maintain its good record of product safety, while remaining eco-
nomically profitable, it is necessary to understand the safety implications of the systems deployed, and
to ensure that they are developed with the appropriate degree of rigour. It should be noted that whilst
all automotive ECUs will normally have self diagnostics and degraded modes of operation, it is neces-
sary to define and analyse these features as part of the overall system.
A great deal of experience has been gained in other industrial sectors and there is now a body of knowl-
edge contained in standards and other publications on how to tackle the development of safety-related
systems. However this work is not known about universally within the automotive industry and further
work is required to apply it in the automotive context.
These Guidelines form part of the set of documents being published by MISRA to assist those who are
developing safety-related automotive systems, though other industry sectors have also found them use-
ful. The original Development Guidelines for Vehicle Based Software [1] provides guidance on some
aspects of the safety lifecycle. These particular Guidelines provide detailed advice for those parts of the
lifecycle that are concerned with system safety analysis. In particular they provide:
• A description of the process that can be used to assess the safety implications of
automotive systems;
• A risk assessment scheme for automotive systems;
• Guidance on how to confirm that the final system is within the target risk classification.
As will be discussed in Chapter 2, the development of a safety-related system does not simply require
the systematic application of a sequence of techniques, important though that is, it also requires a prop-
er understanding, by the development engineers, of the system and the implications of its potential use,
as well as an overall safety culture within the company. Of necessity these Guidelines concentrate on
the former issues, since the latter can only be gained with experience. This document is therefore tar-
geted at automotive engineers with varying amounts of experience, though it is expected that all devel-
opment will be led by a senior engineer with a sufficient degree of domain experience.
xi
Preface (continued)
These Guidelines are divided into two parts. The main Chapters contain statements of the tasks that need
to be done, whilst the Appendices provide some more detailed explanations, especially on those topics
that are likely to be novel to the reader. The References are also of two types. Some provide details of
the origin of a particular concept, others provide details of publications on current techniques and prac-
tices that all readers should be able to acquire.
Although the automotive industry is a global industry, different laws and regulations apply in different
(sets of) countries. It is therefore not possible to define a detailed set of procedures that will apply every-
where, and the (senior) reader is expected to make the necessary interpretations. However, all engineers
are expected to demonstrate “due care” and these Guidelines are designed to promote the necessary good
practice for both current systems, and those expected to be deployed in the automotive industry during
the next ten or so years.
xii
1. Introduction
1. Introduction
1.1 A changing situation
The last decade of the 20th century heralded a major growth in the complexity of motor vehicles as soft-
ware-based technology matured, commercial pressures increased, and both the breadth and depth of the
scope of possible applications of electronic control systems were realized and then accepted. The rate
of change is increasing in the 21st century with up to 90% of all innovations being realized through elec-
tronics [2]. Indeed, the rate of growth of the use of software in motor vehicles is comparable with any
other product at this time.
Programmable electronic systems are no longer confined to the car itself; they also play a significant role
in roadside traffic management systems, which will soon be expected to interact with systems in the
vehicle, and maybe in the future even taking some control away from the driver.
Typical examples of programmable electronic vehicle systems include:
• Current systems
– Powertrain: e.g. engine management; cruise control; adaptive cruise control; transmission
control; hybrid powertrain control systems; cylinder disablement; variable valve timing;
“stop and go” (automatic engine stop at rest and restart on demand).
– Chassis: e.g. anti-lock braking; stability control systems; parking aids; chassis dynamics
control; electrically assisted steering; traction control; electric park brake; tyre deflation
detection and warning.
– Body and comfort: e.g. automatic wiper and lighting control; locking; security; electric
windows, sunroof and mirrors; seat and mirror memory and control; heating ventilation
and air conditioning; secondary restraint.
– Telematics, HMI and entertainment systems: e.g. route guidance; traffic information;
alternative routes; radio, CD/DVD player; telephone; Internet.
• Imminent and future systems

– Chassis: integrated chassis systems for yaw control and vehicle stability.
– X-by-wire: e.g. steering; brakes; cam-less engine control.
– Co-operative driving: e.g. co-operative vehicle highway systems, intelligent speed
adaptation; road pricing; road trains.
– Enforcement: e.g. digitally encrypted tachographs; black box recorders; automatic policing.
The growing public awareness of product and service safety issues has led to the use of more rigorous
engineering processes related to safety, and the widespread deployment of complex electronics has
brought with it a need for something of a revolution in the way that systems are demonstrated to be safe.
No longer is road testing alone sufficient to validate vehicle behaviour.
1
1. Introduction (continued)
1.1.1 Complexity
The underlying issue behind the difficulties of both developing a safety-related system, and being
able to demonstrate, to a third party if necessary, that it can be used in the environment for which it is
intended, is complexity. This problem can be demonstrated very effectively in the following two
definitions [3]:
A system may be classified as simple if its design is suitable for exhaustive simulation and
test, and its behaviour can be entirely verified by exhaustive testing.
A system is classified as complex if its design is unsuitable for the application of exhaustive
simulation and test, and therefore its behaviour cannot be verified by exhaustive testing.
1.1.2 Assessment
A consequence of complexity is that the traditional methods used during Type Approval for simple
mechanical and electrical systems are no longer sufficient to validate the safety of programmable elec-
tronic systems. Instead it is necessary to create a safety argument to show that the system is safe for its
intended application. This safety argument and its supporting evidence should be documented in a
Safety Case (see Section 2.7).
1.2 The purpose of these Guidelines
In 1994 the Motor Industry Software Reliability Association (MISRA) published its Development
Guidelines for Vehicle Based Software [1]. A key aspect of those Guidelines is that the hazards associ-
ated with a system must be identified, understood, and taken into consideration from the beginning of
its development. It is therefore necessary:
• To identify and assess the risks associated with the behaviour of a system;
• To do this early enough to take design actions that can reduce those risks to an acceptable level;
• To provide documentary evidence of the reasoning that lies behind the design decisions taken.
The automotive industry has long been in favour of Failure Mode and Effects Analysis (FMEA), or
Failure Mode, Effects and Criticality Analysis (FMECA) as a means to manage the system and hardware
risks associated with its products. However, the use of FMECA does not represent a comprehensive
safety management process as advocated in recent standards such as IEC 61508 [4] or Def Stan 00-56
[5], but rather it is an element of such a process.
In the section on integrity the MISRA Guidelines [1] call for a safety analysis, which includes hazard
analysis and (safety) integrity level assignment, to be performed early in the lifecycle. Whilst it does not
mandate the use of specific techniques or methods for undertaking a safety analysis, it does refer to
Preliminary Safety Analysis (PSA), which is part of the “PASSPORT” methodology [6] that was being
developed at the same time as the MISRA Guidelines [1] were being written. MISRA has since found
2
that there are a number of approaches that can be used, depending on the nature and scope of the system
being analysed, a good example being a Hazard and Operability study (HAZOP) [7] of a Closed TOE
(see Appendix A). Note that whilst PSA only needs a functional specification of a system, the HAZOP
of a Closed TOE needs a level of system design.
This document provides recommendations on how the use of these various techniques can be co-ordi-
nated during the development of automotive systems. It explains how to approach safety assessment for
“blue-sky” conceptual systems, and for systems whose basic design can be already assumed. It not only
expands on the recommendations made in the original MISRA Guidelines [1] on the issue of “integrity”
but also augments the scope to include system and hardware issues, as well as software considerations.
The treatment of safety analysis is also expanded to include Detailed Safety Analysis (DSA) as well as
PSA. The intention is to offer ideas which complement the automotive industry’s quality system stan-
dards, which include specific requirements for FMEA ([8] and [9]), in such a way as to bring the con-
cepts covered by PASSPORT, and in standards such as IEC 61508 [4] and Def Stan 00-56 [5], into a
single “MISRA Safety Analysis” approach.
1.3 Systems engineering
Few systems are developed using only one of the traditional academic disciplines of mechanical engi-
neering, electrical engineering, psychology, etc. In practice the system must be considered as a whole,
using the relevant aspects of each individual discipline when necessary. This has led to the formation of
a new joint discipline, Systems Engineering.
“Systems Engineering is an interdisciplinary approach and means to enable

the realization of successful systems. It focuses on defining customer needs
and required functionality early in the development cycle, documenting
requirements, then proceeding with design synthesis and system validation
while considering the complete problem… Systems Engineering integrates all
the disciplines and specialty groups into a team effort forming a structured
development process that proceeds from concept to production to operation.
Systems Engineering considers both the business and the technical needs of
all customers with the goal of providing a quality product that meets the user
needs.” [10]
Safety analysis is just one activity in the systems engineering process, and requires a certain knowledge
of the mechanical, electrical, electronic and programmable electronic components of which a vehicle is
comprised. An understanding of the behaviour of the drivers and passengers that will use the vehicles,
as well as of vulnerable road users, is required. In addition, an understanding of the influence that the
rest of the environment will have on the vehicle and those potentially at risk, is also required. Some of
the results of this analysis are the property requirements for the hardware, and the process requirements
for the development of the hardware and software. Unless these requirements are met it is not possible
to identify and construct a valid argument about the residual risk associated with the final system.
3
1.4 Relationship with IEC 61508 and Def Stan 00-56
1.4.1 IEC 61508
The original MISRA Guidelines [1] were written at a time when the International Standard on the
functional safety of safety-related electrical, electronic or programmable electronic systems, now
IEC 61508 [4], was in its first draft. The MISRA consortium needed to make their Guidelines both
applicable and acceptable to the automotive industry sector at that time and thus, whilst they followed
the basic philosophy then being proposed, the document did not follow the exact structure and contents
of that draft.
The published version of IEC 61508 Parts 1–4 is now a Basic Safety Publication for use by Technical
Committees in the preparation of more specific industry sector standards. If no such standard exists for
a given industry sector then IEC 61508 Parts 1–4 should be used directly for the development of any
safety-related electrical, electronic, or programmable electronic systems. However, deviations from
IEC 61508 are permitted, provided they can be justified. At the time of writing this document there was
no sector specific version of IEC 61508 for the automotive industry, though one was under development
at the time of first publication (see Section 1.4.1.1). This document therefore provides guidance for the
automotive industry based on IEC 61508, but with deviations when necessary.
IEC 61508 was developed against a background of industrial process control in which there is “equip-
ment under control” (EUC). Safety functions are to be added to reduce the risks associated with the haz-
ards of the EUC to an acceptable level. Where these safety functions are realized in an electrical, elec-
tronic or programmable electronic system then IEC 61508 applies (see Figure 1.1).
Figure 1.1: The basis of IEC 61508
When seeking to apply IEC 61508 to automotive systems the following issues are evident:
• The safety lifecycle does not align well with the typical product development processes
followed for vehicles. For example, automotive systems are usually subject to a Type
Approval process, whereby the system is fully developed and validated, then approved, and
then released for volume production. In contrast the safety lifecycle in IEC 61508 assumes
that the final validation of the system is carried out once it has been installed on the EUC
as part of the commissioning process.
4
• Automotive systems are rarely the classical “protection” systems of Figure 1.1. Instead, safety
functions are often implemented within the control system and, therefore, it tends to be
difficult to make a physical distinction between EUC control system and the safety system.
• IEC 61508 makes little mention of human factors, yet drivers are crucial to the way that a
vehicle behaves.
• Many of the techniques and measures required by IEC 61508 are only applicable to the process
control sector, whereas many of those that are commonplace in the automotive industry are
not mentioned.
• IEC 61508 does not address the supply chain structures commonly found in the
automotive industry.
• IEC 61508 is rather abstract in nature and more detail, specific to the development of
automotive systems, is required in order to fulfil its requirements. This includes topics such as:
– Safety management;
– Safety processes and methods;
– Safety requirements and their determination;
– Organizational interfaces and responsibilities.
This document therefore conforms to the principles of IEC 61508 Parts 1–4, whilst taking the above
issues into account. However, it should be noted that:
• The techniques and processes described in this document have been devised for the automotive
industry, and these Guidelines are specific to that industry.
• The technical scope of these Guidelines is not as extensive as the full version of IEC 61508;
• The contents of the chapter on safety management is more extensive than IEC 61508;
• The safety-related systems covered by these Guidelines will only be a part of a vehicle, and
their development has to be incorporated into the overall vehicle development process — these
Guidelines are targeted at engineers working in this environment;
• IEC 61508 Parts 5–7 are for guidance (only), and some of the techniques described therein are
unsuitable for many vehicle systems. These Guidelines therefore make use of an alternative,
and more applicable, approach for hazard classification and risk analysis1.
1.4.1.1 Automotive version
Towards the end of writing these Guidelines an ISO working group, ISO/TC3/SC22/WG16, began
preparing an automotive version of the generic standard IEC 61508, to be known as ISO 26262. As both
these Guidelines and the ISO work are based on IEC 61508, there is a general agreement in their
respective approaches. However, these Guidelines do not cover all the stages of the safety lifecycle
(see Table 3.1), but rather provide a framework that can be used by a company to introduce functional
safety management, supported by an appropriate process. Within this framework, the requirements of
either IEC 61508 or draft ISO 26262 can be met. However, it should be noted that:
• ISO 26262 will contain some alternative process measures to those in IEC 61508 that are
more appropriate for the automotive industry in the 21st century.
• These Guidelines do not contain recommendations for SIL process measures; instead they
reference other MISRA publications, e.g. [1].
1 It should be noted that part of this approach, called Controllability, was first introduced in the original
MISRA Guidelines, and is recognized as an additional approach in IEC 61508 Part 5 paragraph 1.2.
5
These Guidelines contain recommendations for processes to undertake safety analysis in general, and to
perform hazard classification and risk analysis in particular. It should be noted that the former is not
dependant on the latter, and that the MISRA safety analysis process can be used with different approach-
es to hazard classification and risk analysis. At the time of writing the approaches to hazard classifica-
tion and risk analysis recommended within these Guidelines and by draft ISO 26262 differ in certain
details: this is because these Guidelines have a wider scope.
A company should always state in its Safety Policy (see Section 2.4) which hazard classification and risk
analysis scheme is to be used, and which process is to be followed to satisfy the SIL requirements.
1.4.2 Def Stan 00-56
Def Stan 00-56 Issue 4 Part 1 [5] is now a short top-level goal oriented set of requirements for the safe-
ty management of defence systems and contains no references to any specific techniques, and this doc-
ument is consistent with its principles.
1.5 The structure of this document
The document contains four principal chapters that describe the MISRA safety analysis process, support-
ed by a number of appendices that describe some of the techniques that may be used.
Chapter 2 discusses a number of issues associated with the management of the safety process.
Chapter 3 provides an overview of the system safety process that should be followed when developing
a new vehicle system, and introduces the concept of Preliminary Safety Analysis and Detailed Safety
Analysis.
Chapter 4 describes the processes that should be undertaken during Preliminary Safety Analysis, in par-
ticular, system modelling; hazard identification; hazard classification; risk analysis and system safety
requirements elucidation. The objective of these processes is to define the requirements and targets that,
when implemented, will ensure that the final system will be safe to use. This chapter includes a descrip-
tion of the MISRA Risk Graph.
Chapter 5 describes the processes that should be undertaken during Detailed Safety Analysis, in partic-
ular, system design; inductive analysis; deductive analysis and results analysis. The objective of these
processes is to confirm that the requirements and targets have been met and that the final system is safe
to use.
It should be noted that although Chapter 4 is much longer than Chapter 5, this is not because the former
is more important than the latter, but because the techniques to be used as part of a Preliminary Safety
Analysis are less well known than those required for Detailed Safety Analysis, and therefore need more
detailed explanation.
6
As with any document of this nature, the references given are for those documents and versions that are
available at the time of publication. The reader should note in particular that the MISRA Steering Group
is planning to publish additional relevant guidelines and technical reports that will be available from the
MISRA web site.
7
2. Safety management
2. Safety management
2.1 Introduction
In order to manage safety effectively, it is necessary that all safety activities are performed within a basic
framework that forms part of a company’s engineering structure and culture, and that has its own organ-
ization (see Figure 2.1).
Figure 2.1: Safety management structure
In order to establish an effective safety management structure a company or organization requires

a Safety Policy that defines the company-wide strategy for the management of product safety (see
Section 2.4). This, like all top-level company policies, is the means by which the intent and commit-
ment of the highest level of management is stated though, to be fully effective, it must be supported by
a suitable organizational structure (see Section 2.2) and safety culture (see Section 2.3). From this
policy a management structure is created to ensure that the policy statements are adhered to, and the
means of their implementation monitored for effectiveness throughout the engineering lifecycle.
8
2. Safety management (continued)
As with quality, each project should start with safety planned into it. A strategy is not effective alone: it
depends on tactical decisions, objectives, and substantive actions to become effective. The Safety Policy
establishes the strategy, and individual Project Safety Plans define the tactics in the form of engineering
procedures that will be specific to individual projects (see Section 2.5).
In order to establish safety requirements for the system (see Section 4.5.3), the “expected” or “intend-
ed” use of the vehicle needs to be defined. These operational constraints are termed the safety envelope
(see Section 2.6).
During the development of the system evidence is collected in a Safety Case to demonstrate that it is
safe for its intended use. The strategy used to create a Safety Case is known as the Safety Argument
(see Section 2.7).
An important part of safety management is that engineering staff employed in the management of safe-
ty should have professional competencies in safety engineering, appropriate to their level of responsibil-
ity (see Section 2.8).
2.2 Organizational structure
The organizational structure of a project team should match the design and development as far as is
practicable, and allow for appropriate independence of verification, validation and assessment (see
Section 2.5). There should be a continuous reassessment of tasks with frequent interaction between
personnel. Individual team members should be encouraged not only to take responsibility for their own
tasks, but also to share responsibility for the overall project. In particular, the setting of project goals
should involve some degree of group participation. Further advice can be found in [1].
2.3 Safety culture
Many products, when in the hands of a consumer or user, have the potential to cause harm to that user,
to a third party, or to have a negative impact on the environment. A significant impact on the potential
for harm arises from the care (or lack of care) with which the product was engineered and developed.
Where a safety culture exists, the members of an organization actively promote and pursue the achieve-
ment of safety as a primary objective for the product and its development. For an organizational safety
culture to be successful, the promotion of safety must be actively pursued and supported at every level,
starting at the top of the organization.
Thus a safety culture is not only about there being good safety attitudes in the members of the organiza-
tion, but it is also about good safety management being established by an organization. It requires the
highest priority to be given to safety, and a constant assessment of the safety significance of events and
issues in order that the appropriate level of attention can be given to them.
9
2.4 Safety Policy
A Safety Policy should define the company’s or organization’s strategy for encouraging and maintaining
safety. The Safety Policy comprises a set of statements of commitment and intent from the board of
directors of a company or organization. The statements should define, at a high level, the fundamental
aims and responsibilities for managing product and process safety issues as specific, verifiable aims.
The Safety Policy document is the top-level safety document, which resides at the apex of all other safe-
ty procedure documents, just as a Quality Policy document heads up a company’s quality procedures.
Each company or organization will have its own Safety Policy, which should encompass [11]:
(a) The company or organization’s commitment to safety for its products;

(b) Definitions of responsibilities and accountabilities and required competencies for
safety management;
(c) Issues concerning the independence of the safety team and its management;
(d) The mechanism of safety assurance;
(e) Compliance with standards and regulations;
(f) The goals to be sought for managing risk (see also Section 4.5.4 and Appendix E);
(g) A requirement for each project to have a Safety Plan.
As with a Quality Policy, the Safety Policy should be monitored for its effectiveness, and improvements
identified and implemented on an ongoing basis.
2.5 Project Safety Plan
In addition to having a Project Quality Plan, in order to implement effective safety management it is nec-
essary to have a Project Safety Plan. This states all the specific actions, deviations, limits, etc. that can-
not be covered by a global set of procedures, and shows how and when all the elements required by the
Safety Argument (see Section 2.7) will be produced. A Project Safety Plan should be assembled at the
start of the project, but should be reviewed during the engineering lifecycle to ensure that it remains
appropriate for handling the actions resulting from safety analysis and risk assessment. If any deficien-
cies are found then all the activities that depended on the deficient process may need to be re-assessed.
Typically, a Project Safety Plan would include:
(a) A definition of the system scope;

(b) Identification of actions to be taken if a system SIL exceeds a predetermined level, for example
“SILs 1 and 2: a qualitative risk assessment; SIL 3: a quantitative risk assessment; SIL 4: not
permitted under any circumstances, rethink the design” (see also Section 2.6);
(c) A list of responsibilities and authorities versus named individuals (see also Section 2.8);
(d) Standards and/or procedures to be used, including any deviations or concessions;
(e) The risk management criteria for this product (see also Section 4.5.4 and Appendix E);
(f) Definition of the level of reporting required (e.g. formal technical report; technical report
supported by a safety argument; formal Safety Case).
10
Where the Safety Policy might state that safety issues should be examined and signed off at project mile-
stones, the Safety Plan would indicate which safety issues, and which milestones relate to their sign-off.
It should be noted that it is necessary to ensure that there is a degree of independence between those who
are responsible for the design of a system, and those who are responsible for implementing the Project
Safety Plan. The higher levels of integrity should require greater independence of assessment in order to
ensure that there is neither bias from the development team, nor misplaced pressure from management [1].
2.6 Safety envelope
It is necessary to identify a consistent set of conditions that will be assumed when analysing a system.
Indeed it is often the case that these conditions will relate to the type of vehicle, rather than the type of
system. Exceptions to these conditions may be incorporated in a Project Safety Plan for an individual
project, system, or product. For example, a dynamic vehicle control system may be introduced into a
vehicle design for a number of reasons, including:
• As an aid to normal driving, and designed to mitigate hazardous driving conditions due to the
driver misunderstanding the situation, or overestimating his or her driving skills, e.g. ABS or
Active Yaw Control;
• To ensure that a vehicle is stable for all rated load and driving conditions (e.g. Electronic
Stability Enhancement);
• To provide assistance to the driving task, e.g. Adaptive Cruise Control, Intelligent
Speed Adaptation.
The safety envelope defines the operational and environmental limits within which the system is expect-
ed to behave in a safe manner. It defines the “expected” or “intended” use of the vehicle with the sys-
tem fitted and operational, so that risks associated with the system can be evaluated under defined con-
ditions, should it fail to perform an intended function correctly. A safety envelope will normally only
apply to hazards associated with the movement of the vehicle, because the others will be covered by
existing regulations.
When the system under consideration is an aid to “normal driving”, i.e. only to come into operation when
driving conditions are abnormal, or to provide additional information to the driver concerning the envi-
ronment, then the safety envelope may need to consider the widely recognized phenomenon of risk com-
pensation, where drivers rely on the extra features for part of their normal driving behaviour. Particular
examples of this are the reliance on ABS to provide improved braking characteristics, and the reliance
on Electronic Stability Control to compensate for what would otherwise be unsafe modes of driving.
The safety envelope will need to be defined to take account of this example of reasonably foreseeable
misuse as required by IEC 61508 [4] (see also Section D.2.3.1).
A typical safety envelope could include:
(a) The driver is qualified to drive this class of vehicle (see also Section D.2.3.1);
11
(b) The vehicle is being operated in accordance with its design intent, e.g. as specified in the
User’s Handbook, together with reasonably foreseeable misuse;
(c) The vehicle is not defective in any way other than with the issues identified in the
safety analysis;
(d) The vehicle is in a legal and roadworthy condition;
(e) The vehicle is being operated in a manner consistent with its type (e.g. not driving a luxury
saloon at high speed cross-country);
(f) The weather conditions are assumed to be within the vehicle design parameters, and are not in
themselves a major contributory factor in the analysis of the safety issues;
(g) The vehicle is being driven in a manner that does not significantly amplify the consequences
of a hazard, or provoke the hazard on its own.
Note that, although “with due care and attention” is the standard of driving that would be expected of a
reasonable, prudent and competent person in all the attendant conditions [12], a company may wish to
extend the safety envelope beyond this limit to cover unintentional excursions due to short-term mis-
judgements of the current conditions.
For some complex systems (e.g. multi-function vehicle dynamics control), with more than one mode of
operation, it may be desirable to consider more than one safety envelope, so that diverse aspects of the
system’s operation may be analysed. However, this should be done with care because some drivers may
not understand the distinctions being made (see also point (a) above).
2.7 Safety Argument and Safety Case
The ultimate goal of a safety management approach to systems engineering is some form of evidence
that the system is safe with specified limitations (the safety envelope). This evidence may be collected
together into a Safety Case.
A Safety Argument is the logical explanation that ties together the evidence from the system safety
analyses with the safety requirements, and shows that all the hazards have been mitigated (see
Section 4.3.4). It is essential for the creation of the Safety Plan because it specifies the evidence that
will be required to support the Safety Case, and therefore what processes and procedures are required in
order to produce that evidence. The Safety Argument may, of course, iterate as the project proceeds.
The Safety Case shows that the Safety Argument has been fulfilled, and it is supported by the necessary
evidence. It can be created and presented using a variety of different techniques, e.g. [13] and [14].
In non-automotive industries, a Safety Case is normally assessed by an independent party, which will
examine all aspects of the product’s engineering, such as:
• The standards selected for the product to meet;

• The tests used to show compliance with the standards selected;
• The design measures used to ensure safety;
• The manufacturing control measures used to monitor and maintain safety;
12
• The validity of the Safety Argument that the safety requirements arrived at, and the
procedures and standards used do, in fact, provide an adequate level of safety for the product.
The final output from the third party assessor, or auditor, will usually be a report accompanied by a
Safety Certificate. Whilst the latter is not a legal requirement for road vehicles at this time, a Safety Case
is useful to confirm that everything necessary has been done, and may be used as evidence of due care
for the purpose of defending a legal action.
In the automotive industry the decision as to whether to subject a Safety Case to third party assessment
is an internal matter for the company making the product, though if it is not done then no Safety
Certificate can be given. Advice on when to use independent assessment, and its degree of use, can be
found in [1].
However, it should be borne in mind that Type Approval legislation is heading in the direction of a Safety
Case approach and, in the course of time, Type Approval may become equivalent to a formal Safety
Certificate for safety-related vehicle systems. This has begun with an extension being added to the brak-
ing regulations [15] and subsequently to the steering regulations [16]. Similar extensions are expected
to be added in time to the regulations that apply to other electronically-controlled systems.
2.8 Competencies
Safety engineering requires specialist knowledge and it is important that safety practitioners have the
necessary knowledge and skills, and are competent. In general, it is anticipated that safety practitioners
should be properly qualified, e.g. Chartered Engineers in the UK, Professional Engineers in the USA.
and should have appropriate experience and/or qualifications in safety engineering, and be active in
maintaining their professional education. Key positions in the management of the safety issues should
be held by people of sufficient seniority, as well as of sufficient competence.
Staff who are employed on safety engineering tasks do not all need to have the requisite qualifications
and experience, provided:
• They are supervised by appropriately qualified safety practitioners, and

• They are not given tasks, or responsibility, that could lead to the safety of the system
being compromised.
A description of the competencies required for safety-related system practitioners can be found in [17].
It is important to appreciate, however, that these competencies are written in a general manner so that
they cover all industry sectors, and it is vital that safety-related practitioners also have a good knowl-
edge of the automotive industry and the application with which they are working. In the event that a
(small) company does not have anyone with these competencies in-house, then it will need to use out-
side consultants who do.
13
2.9 Claiming compliance
Compliance can only be claimed for a process, or a product, and not for an organization. When claim-
ing compliance to the process defined in the MISRA Safety Analysis Guidelines2 (this document) a
developer is stating that:
• There are written procedures for carrying out each process stage (normally referenced in a
Project Safety Plan);
• Evidence exists to show that all of the process stages have been followed;
• Evidence exists to show that the software development process requirements have been
fulfilled, e.g. [4] or [1];
• Evidence exists to show that the hardware reliability requirements have been fulfilled;
• In addition to the above the following documentation exists:
– A Safety Policy;
– A definition of broadly acceptable risk;
– A list of Classified Hazards;
– A list of safety requirements;
– A SIL assignment for each safety function, and hence for the safety-related system
(and sub-systems if applicable).
However, the blind following of a process without a proper understanding of all the issues is unlikely to
produce a product that is safe for its intended purpose. Developers should always have the goals that
they are trying to achieve in mind, and demonstrate that they have achieved them with evidence. An
effective way for a manufacturer to do this is to compile a Safety Argument and Safety Case, which has
been subject to a third party audit and assessment.
2 For the avoidance of any doubt, it should be noted that MISRA does not provide a compliance
assessment service.
14
3. Overview of the MISRA Safety Process
3. Overview of the MISRA Safety Process

3.1 Introduction
The MISRA Safety Process is designed to ensure that:
• The vehicle manufacturer/system supplier has understood the safety implications of the system;
• The risks arising from the safety implications have been assessed;
• The risks have been reduced to an acceptable level by a combination of:
– A design to eliminate inherent risks;
– A design to mitigate the effects of hazardous events;
– The use of suitable development techniques with appropriate rigour;
– The use of hardware with adequate reliability for its purpose;
• The remaining (residual) risks associated with the final system have been approved by
sufficiently senior management on the basis of a company-approved policy, which takes
into account the level of risk considered to be broadly acceptable to society as a whole.
3.2 The safety lifecycle
These Guidelines are intended to be compliant with the requirements of the basic overall Safety
Lifecycle defined by IEC 61508 (see Figure 3.1), though they do not cover all the phases of that lifecy-
cle since they are a supplement to the original MISRA Guidelines [1]. As explained in Section 1.4.1, the
IEC 61508 Safety Lifecycle does not align well with the typical product development processes followed
for vehicles that are given in the following two figures, albeit in a simplified manner.
15
3. Overview of the MISRA Safety Process (continued)
Figure 3.1: Basic IEC 61508 safety lifecycle [4]
Figure 3.2 shows the MISRA Safety Process, a safety lifecycle that more closely represents the process-
es that are followed in the automotive industry. It contains the same reference numbers as in Figure 3.1
so that comparisons can be made easily. The topics that are covered in this document are:
16
Figure 3.2: Overview of the MISRA Safety Process
17
• Preliminary Safety Analysis (PSA): This defines the proposed system and describes how it
is intended to work. From this understanding an assessment is made of the safety implications
of the system. A risk analysis then determines the required risk reduction such that, when
achieved, the residual risk will be acceptable. See also Section 3.5.
• Detailed Safety Analysis (DSA): This confirms that the implementation of the system is
consistent with the required risk reduction measures. See also Section 3.6.
Since safety should be addressed throughout the whole lifecycle, Table 3.1 provides a brief summary of
where advice and guidance on various phases of the MISRA Safety Process can be found in documents
published by MISRA.
Phase Activity MISRA Guidance
System modelling Section 4.2
Hazard identification Section 4.3
Preliminary Safety Analysis Hazard classification Section 4.4
Risk analysis Section 4.5
System safety requirements Section 4.5.3 and reference [1]
Maintenance
Planning Validation
Installation
System design
Realization Component design
Module design
Detailed Safety Analysis Chapter 5
Safety validation Software verification
Reference [1]
and validation
Maintenance, servicing
and repairs
After sales Modifications and retrofits
End of life
Table 3.1: Guidance on the MISRA Safety Process
Many new systems are actually modifications of older systems. Thus, in practice, most developments
will start by going “back to the appropriate phase”, which should normally be PSA. If a good set of doc-
umentation already exists for the older system then it should only be necessary to perform an Impact
Analysis to find out how the changes in the system, and its intended use, will modify the hazards. If the
changes are very large and/or the existing documentation is poor, then it is best to consider the modified
system to be a completely new system. These criteria should hold whether the modified system is being
developed for a new vehicle, or in response to some changes that need to be made to an existing model.
18
3.3 Vehicle development
When a new vehicle is being developed all the systems within it, whether they be pre-existing, modified
or new must be confirmed as being suitable for their intended application. Although Tier 1 suppliers will
actually provide many systems, the vehicle manufacturer is responsible for giving the safety target as a
requirement. In the event that the supplier is providing a complete system with little involvement from
the vehicle manufacturer, then the supplier must state what safety goals have been achieved and the man-
ufacturer must state explicitly that these are acceptable. (See also Section A.3.1)
Figure 3.3 shows how the phases of the vehicle systems lifecycle relate to the stages of vehicle devel-
opment, and the principal vehicle development gateways at which high-level decisions are taken to pro-
ceed, or else to re-work or even cancel the project. In practice, the stages may be more detailed, and
individual manufacturers may use more gateways or milestones.
19
Figure 3.3: The vehicle lifecycle, gateways, and safety lifecycle steps
20
Despite the increasing use of software, the vehicle lifecycle, as exemplified in Figure 3.3 is still based
on the traditional requirements of the mechanical engineers. As a consequence it does not align well
with the development of software-based systems. This will be exacerbated when the software is to be
used to control hardware that is being developed concurrently, i.e. the requirements for the software can-
not be finalized until the mechanical component it is controlling has been finalized. Thus, in practice,
the software may not be fully developed, or be suitable for approval, at any given gateway until the start
of production. When, for practical reasons, late changes to the software requirements are made to solve
mechanical problems, because the lead times for software changes are seen as being shorter than for
hardware, the risk associated with the software changes can easily be underestimated. This risk relates
not only to the planned changes being implemented correctly, but also that the change, even if imple-
mented correctly, will not affect other aspects of the whole control system.
This creates a dilemma, both for the software engineer and the project manager: should development
continue although the gateway notionally is not satisfied, or should the software be approved, even
though it is not completed? One potential solution is to have a software development lifecycle running
in parallel with the main vehicle lifecycle; but even then, there must be some flexibility built in to the
software lifecycle in order to accommodate its iterative, evolutionary nature. Another potential solution
is the use of the Software Readiness for Production (SRfP) metric developed by MISRA [18]. In this
case, the target for any given gateway can be the achievement of a certain level of SRfP metric.
Whatever solution is adopted, by Start of Production, if not earlier, a consistent set of design documen-
tation should exist that faithfully represents what is going into production, and for which there is a cor-
responding set of safety analyses and associated safety arguments, reasoning and validation records.
3.3.1 Traceability and change management
The system design must be under Configuration Management so that there is no doubt upon what the
safety analysis has been performed and that, if changes are made, the need to repeat (part of) the safety
analysis is clear. The processes of system safety analysis, and their inputs and outputs, thus need to be
traceable, both to the system requirements and design, and to the changes that have been made to them.
Consequently, the model(s) and the analyses (PSA and DSA) must be subject to Change Management
with a rigour equal to the design itself, so that full traceability is maintained and the analyses reflect the
actual system at any given time.
The MISRA Guidelines [1] provide advice on Configuration Management and version control process-
es at all Safety Integrity Levels (SILs), which dictate the level of rigour with which the system must be
engineered (see Section 4.5.3.1).
21
3.4 The MISRA System Safety Analysis Process
The objective of system safety analysis is to provide the evidence needed to support the Safety Argument
in the Safety Case to show that a system is free from unacceptable risks, given its intended use.
Manufacturers have a duty of care to their customers, and system safety analysis is key to demonstrat-
ing that due care was exercised in the design and development of the product. The combined results of
Preliminary Safety Analysis (PSA) and Detailed Safety Analysis (DSA) provide the additional informa-
tion needed to satisfy IEC 61508 requirements.
“Safety analysis is iterative; as the design progresses, the analysis should be

repeated to take account of change and extended to cover the extra detail. The
design can then be modified to avoid hazards or reduce risks as soon as they
are identified. The process should start as soon as a high-level description of
the system is available.” [11]
The PSA and DSA processes were originally defined in the EC DRIVE II project PASSPORT [6], [19].
These two processes are outlined in Figure 3.4, which shows the basic flow of information through the
system safety analysis process. PSA is described in Section 3.5, and DSA is described in Section 3.6.
22
Figure 3.4: The MISRA System Safety Analysis Process
23
3.5 Overview of PSA
The objective of the PSA process is to identify the hazards that may be associated with the functionali-
ty of a system, and to derive its high-level safety requirements, including the SIL of the safety function(s)
or, since the control and safety functions are normally in the same unit, then of the complete system.
The PSA process may be started at almost the earliest point of the engineering lifecycle, and should be
reviewed and developed iteratively as the design of the system evolves. The process of performing a
PSA adds to the scope and range of the overall understanding of the system, both as the functional
description is developed, and as the system behaviour is analysed in increasing detail.
PSA is a process that begins with a model of the system and the environment, together with its function-
al description, which is subsequently analysed to deduce any hazards associated with the effects of its
functionality at the outputs. Each hazard is assigned a MISRA Risk Level, from which a SIL can be
deduced for each safety function (see Section 4.5), and hence of the safety-related system. In addition
a set of high-level system safety requirements is derived from the analysis results, and this forms one of
the outputs of the PSA, and inputs to the DSA. An overview of the PSA process is shown in Figure 3.5.
24
Figure 3.5: Overview of the MISRA Preliminary Safety Analysis Process
25
3.5.1 Inputs to the PSA process
The principal inputs to the PSA process are:
• Overall system functional requirements;

• (The system’s) operating environment;
• Initial safety envelope
• Safety Policy;
• (Initial) Project Safety Plan;
• Plan for Traceability and Change Management.
3.5.2 Stages of the PSA process
The PSA process “looks out” from the system boundary into the outside environment to identify how the
system interacts with the rest of the world; this is in contrast to DSA, which “looks in” to the system
from the system boundary to determine the cause of these interactions. The PSA process is likely to be
iterative as more information is obtained about the system, much of it as a result of the PSA itself.
Details of the PSA process stages can be found in Chapter 4, and the remainder of this section provides
a brief overview of them.
For a PSA to be performed, the system must be modelled within well-defined boundaries (interfaces with
its environment) in a form that can be conveniently analysed (see Section 4.2). An analysis of the model
and its functional description, together with its interaction with the environment within which it oper-
ates, results in the identification of the hazards associated with the system as defined by its model. There
are two principal techniques that may be used to undertake this hazard identification, either a “What If?”
analysis (see Appendix B) or a high-level HAZOP (see Appendix C). Each hazard must then be classi-
fied (see Section 4.4) and its risks assessed (see Section 4.5), from which a SIL can be deduced for each
safety function (see Section 4.5.3.1), and hence of the safety-related system. A “What Causes?” analy-
sis can then be used to aid the identification of the high-level safety requirements (see Section 4.5.3).
Finally the results of these processes are used to develop the Project Safety Plan (see Section 2.5), and
support the safety argument that is used to justify the adequacy of the final Safety Case (see Section 2.7).
3.5.3 Outputs from the PSA process
These outputs are all used during the DSA process, and most feed directly into the Safety Case (see
Section 2.7):
• Model of the system (and associated functional definition) and the environment;
• Refined safety envelope;
• Hazard List;
• High-level safety requirements;
• Safety Argument;
• Updated Project Safety Plan;
• Safety integrity level((s) for the safety function(s)).
26
3.6 Overview of DSA
The objective of the DSA process is to analyse in detail the system design, from its architecture to the
level of decomposition necessary, in accordance with the demands of the Safety Argument and the high-
level safety requirements identified during the PSA.
In summary, it aims to confirm whether the Hazards identified and recorded in the Hazard List can be
caused by failures of the system and, if they can, whether they can be mitigated by the safety integrity
requirements (see Section 4.5.3.1). If the safety integrity requirements cannot be met, and are not in
compliance with the Safety Policy (see Sections 2.4 and 4.5.4), then that fact identifies the need for addi-
tional mitigation, including redesign.
If, during the analysis of the failure modes, one or more additional hazards are found to exist, the PSA
should be revisited and their implications explored. Particular attention should be given to the contin-
ued appropriateness of the previously derived SIL(s).
Like PSA, DSA is an iterative process that is performed in parallel with the system design and develop-
ment and is completed with the creation of a Safety Case. The Safety Case must demonstrate, with a
sufficient level of confidence, that the system is free from unacceptable risk. The level of confidence
required is dictated by the SIL(s) assigned to the safety functions, and hence to the safety-related
system.
In the event that the system needs to be modified, or maintained, for whatever reason, the existing Safety
Case will no longer be valid. It will therefore be necessary to re-visit the system safety analysis process
again.
An overview of the DSA process is shown in Figure 3.6.
27
Figure 3.6: Overview of the MISRA Detailed Safety Analysis Process

28
3.6.1 Inputs to the DSA process
The inputs to the DSA process are:
• Detailed description of system requirements, architecture and operating environment;

• High-level safety requirements;
• System model (and associated functional definition);
• Plan for Traceability and Change Management;
• Updated Project Safety Plan
• Safety argument;
• Hazard List;
• Safety integrity level((s) for the safety function(s));
• Safety Policy;
• Refined safety envelope.
3.6.2 Stages of the DSA process
Whilst the PSA process “looks out” from the system boundary into the outside environment to identify
how the system interacts with the rest of the world; the DSA process “looks in” to the system from the
system boundary to determine the cause of these interactions. In the event that changes are made to the
design, e.g. as a result of the DSA process itself, the relevant parts of the DSA process should be repeat-
ed. The DSA process comprises the application of well-defined techniques, and the remainder of this
section provides a brief overview of them.
The first principal stage of DSA is an inductive analysis, and the most common technique used in the
automotive industry is Failure Mode and Effects Analysis (FMEA). FMEA is an analysis based on
examining the components of the system, identifying how they may fail or misbehave, and the effects
that their failure can lead to (see Appendix F). It is thus a bottom-up inductive technique that works
upwards from the fault, or failure mode, to the resultant effect. It should be noted that FMEA identifies
only single-mode failures. Other techniques are possible (see IEC 61508-2 Table B.5 and IEC 61508-3
Annex A [4]).
The second principal stage of DSA is a deductive analysis, and a common technique to use is Fault Tree
Analysis (FTA). FTA examines the mechanisms that lead to the hazards (see Appendix G). It is
therefore a top-down deductive technique, which starts from a hazard (top event) and works downwards
to determine all of its causes until the level at which individual failures occur (base events) is reached.
Since FTA is based on Boolean logic diagrams, it inherently takes multiple or combinatorial failures
and effects into account. Other techniques are possible (see IEC 61508-2 Table B.5 and IEC 61508-3
Annex A [4]).
The results of the FMEA and FTA need to be analysed to check whether the design that has been cho-
sen requires additional “derived” low-level safety requirements. These may need to be fed back to the
beginning of the DSA process to validate the results. In the event that the design introduces a new haz-
ard that was not identified during the PSA, it will be necessary to re-design the system, and to repeat that
phase as well.
29
3.6.3 Outputs from the DSA process
The outputs from the DSA are used to support the creation of the Safety Case. The outputs include:
• Component Failure Modes;

• Low-level safety requirements;
• Analysis Results (and Reports).
30
4. Preliminary safety analysis
4. Preliminary safety analysis

4.1 Introduction
The main purpose of PSA is to understand the safety implications of the system being proposed or
designed. Consequently it is applied to the functional requirements or a high level design, and can only
be based on the level of understanding and maturity of the system functional requirements at the time
that the analysis is being performed. If the analysis is based on just a concept, or early ideas, then the
results should be viewed as tentative and the analysis repeated when a formal functional requirements
specification has been issued.
The main output of a PSA is the Hazard List from which are derived, via hazard classification and risk
assessment, the initial safety requirements that take the form of a set of high-level safety requirements,
including a SIL. These will be supported by the Safety Argument (which is the rationale by which it will
be argued that the system is fit for production), and the Safety Plan that shows how and when all the ele-
ments required by the safety argument will be produced (see Chapter 2)
After introducing automotive hazards this Chapter describes each of the PSA process steps shown in
Figure 3.5, namely:
• Model the system and environment;

• Identify hazards;
• Classify hazards;
• Assess risk and system safety requirements.
4.1.1 Vehicle hazards
The generic definition of a hazard is a “Potential source of harm”. In the automotive context the people
that are potentially exposed to a source of harm arising from the vehicle typically include:
• Vehicle driver and passengers;

• Drivers and passengers of other road vehicles, e.g. cars, motorbikes;
• Vulnerable road users, e.g. cyclists, pedestrians;
• Service technicians;
• Vehicle manufacturing staff;
• Staff involved in end of life disposal.
When a vehicle is operated it interacts with, or influences, things in its environment that may be station-
ary or moving. The environment includes not only the people potentially at risk above, but also other
factors such as:
• The road;
• Road-side objects;
• The atmosphere.
31
4. Preliminary safety analysis (continued)
Vehicle hazards arise at the interface between the vehicle and its environment; this interface is called the
Vehicle Hazard Boundary, and the term hazard is only used for effects that occur at the Vehicle Hazard
Boundary and not for the potential causes of those effects.
Assuming that the vehicle is being operated within its safety envelope (see Section 2.6), hazards arise at
the Vehicle Hazard Boundary when the interaction between the vehicle and its environment produces
unsafe behaviour. In general this can be due to one of:
• An error in a requirements specification, which results in the unsafe behaviour;

• A correct requirements specification that, due errors of omission and/or commission in its
implementation, results in the unsafe behaviour.
Some unsafe behaviour relates to the control of the movement of the vehicle; this includes:
• Lateral control (steering);

• Longitudinal control (acceleration/deceleration);
• Handling/stability (the ease with which a driver can control the movement of the vehicle,
e.g. yaw, pitch and roll).
Some unsafe behaviour relates directly to the user; this includes:
• Burns from heat or fire;

• Pollution from undesirable emissions;
• Physical injury, e.g. seat and window glass movement, each with the potential to trap a
part of the body.
Some unsafe behaviour can affect the driver’s ability to make sound judgements when controlling the
vehicle; this includes:
• Reduced visibility;
• Confusing feedback from the controls (vehicle “feel”);
• Incorrect displays of information.
Vehicle Hazards are the emergent result of one or more of these unsafe behaviours. Some hazards direct-
ly affect the ability of the driver to direct the vehicle on a chosen trajectory at a chosen speed, while the
other hazards do not directly affect the dynamic state of the vehicle. This distinction should be borne in
mind when using the MISRA Risk Graph for hazard classification where different branches of the graph
are used for hazards associated with the “driver in the loop” model of vehicle control, and those hazards
that are associated with an area of danger (see Section 4.4.4).
The mechanisms by which a vehicle may interact with its environment can be captured in a diagram of
the form shown in Figure 4.1; this captures both inputs to the vehicle:
• Data: from devices that a driver can use to provide control signals to a system in the vehicle,
e.g. throttle, brake pedal, switches; information about the (relative) position and speed of
surrounding objects, e.g. from radar, cameras;
• Influences: from the environment, e.g. weather, road surface friction;
32
Figure 4.1: Interactions and emergent properties at the vehicle hazard boundary
and outputs from the vehicle:
• Data: to the displays and warning systems for the driver, e.g. speedometer, ABS failure
lamp, vision enhancement systems;
• Influences: lateral, longitudinal and vertical forces (e.g. acceleration, deceleration, and
steered angle); forces due to the nature of the physical materials used, e.g. heat/fire;
forces on the environment due to the emissions that are expelled from the vehicle,
e.g. exhaust, compressed air.
Whereas many applications will reside in a single E/E-system, some applications may be implemented
by more than one E/E-system using a network for communications. For some applications that are now
appearing on vehicles it is not obvious to the casual observer “where” the system is located. This fact
should not be overlooked when performing the hazard identification described in this chapter.
33
Figure 4.1 is not meant to be a complete diagram for all possible vehicle applications because new sys-
tems may introduce new interactions. When performing the hazard analysis it is necessary to create an
appropriate drawing that captures all the factors relevant to the system being analysed. Hazards are also
not necessarily related directly to the E/E-system. Some are inherent in the concept of the vehicle and
can result from purely mechanical failures; most of these have been present since the very first vehicle
was produced.
Hazards may be associated with an E/E-system by:
• Failure modes within the E/E-system that can lead to a hazard, which was also present in the
traditional mechanical system that it replaced;
• The use of an E/E-system that introduces a new hazard which was not present before, e.g.
– The introduction of air bags introduced a hazard related to un-commanded deployment;
– The use of a new actuator, controlled by an E/E-system, has new failure modes that result
in hazards that could not arise with the traditional mechanical system that it replaced.
Hazards can also arise when a vehicle is operated in an unintended manner, or is operated correctly in
conjunction with one or more other systems, or conditions, such that dangerous behaviour results.
4.2 System and environment modelling
Hazard identification is performed on a model of the system and its environment, therefore the first
phase in the Preliminary Safety Analysis is to produce a suitable model. The inputs to this phase are:
• Overall system functional requirements and/or a concept design;

• Operating environment;
• Plan for Traceability and Change Management (see Section 3.3.1).
A model is an approximation and therefore it is necessary to ensure that the model includes all the infor-
mation that is relevant to the analysis being performed. The factors that influence the choice of model-
ling approach include:
• The means by which the system interacts with the environment, and the things within the
environment with which it interacts;
• The nature of the system, i.e. does it fall within a well established design paradigm,
or is it a new concept;
• The design responsibility of those performing the analysis as imposed by the organization;
• The scope of the definition of hazard appropriate for the analysis, i.e. as well as the potential
for human injury, it could also include potential damage to the natural environment and/or
potential damage to property.
34
Appendix A describes the modelling task in more detail, including the choices and consequences of mod-
elling at different design levels.
The output from the modelling phase is a system model that consists of:
• The Target of Evaluation (TOE) and its boundary elements;

• The terminators in the environment;
• A description of the interactions between the boundary elements and the terminators;
• A list of factors in the environment that may influence these interactions.
4.3 Hazard identification
4.3.1 Introduction
The inputs to the hazard identification phase are as follows:
• A model of the system under analysis;

• Operating environment;
• An initial safety envelope;
• Safety Policy.
In addition the project team needs a good knowledge and domain experience of the behaviour of the pos-
sible components, and of the way that a vehicle and its driver can behave.
The hazard identification activity explores the possible hazardous states of the vehicle and/or its systems.
Note that a vehicle driving on an empty road under good environmental and road conditions, in a good
state of repair and with an alert driver does not constitute a hazardous state. A hazardous state is entered
when the behaviour of the vehicle, or a system within the vehicle, can lead to harm to the driver, to vehi-
cle occupants, to the occupants of other vehicles, to property or to the environment.
The goal of hazard identification is to identify the potential failure modes of a system that could lead to
the vehicle being in a hazardous state. Thus, hazard identification is concerned with identifying the
events that could cause a transition from State 1 to State 2, or from State 3 to State 4, (see Figure 4.6 in
Section 4.4.3).
There may also be the situation where the complex interaction of several systems, all functioning as per
their specifications, gives rise to unanticipated emergent behaviour which is hazardous. In these cases
the state transitions have effectively occurred before the vehicle is ever driven.
Since the objective of hazard identification is to identify all the hazards associated with the system being
analysed, a systematic approach to hazard identification is required in order to have a sufficiently high
degree of confidence that a complete set of hazards has been identified. This is because the risk associ-
ated with hazards that have been identified can be mitigated; but the risk associated with hazards that
have not been identified cannot be known and, therefore, cannot be mitigated.
35
Note that in this activity only “black box” failures of the system are considered. Whilst extensive lists
of driving scenarios are not required, in practice it is usually necessary to consider factors which define
a context for determining if a particular failure is indeed a hazard. These factors should not be specified
in great detail; rather generalized descriptions should be used. These may include:
• Vehicle usage scenarios, e.g. high-speed driving, urban driving, parking, off-road;
• Environmental conditions, e.g. road surface friction, side winds;
• Reasonably anticipated driver use/misuse.
It should be noted that, when performing a hazard analysis, one is considering what can conceivably hap-
pen. Hazards should not be ignored because the possible mitigations for the hazard are known to be
common practice, or because new ideas for mitigations are conceived at the same time as the hazard is
identified. These mitigations should be documented as safety requirements and become part of the
Safety Argument justifying that all the hazards have been adequately mitigated.
The reason for discounting hazards that are the result of extremely unlikely scenarios, e.g. those that rely
on a sequence of rare coincidences, should be recorded.
It should also be noted that a hazard is not an accident, but rather a situation which, given a suitable trig-
ger event, may lead to an accident, or hazardous event. The description of the hazards should reflect this
distinction.
Hazard identification will produce:
• A list of hazards for the system;

• An improved understanding of the system, including a refined safety envelope;
and these form the basis for deriving the safety requirements designed to mitigate those hazards (see
Section 4.5.3).
4.3.2 Vehicle hazard identification
If the Boundary of the TOE is coincident with the Vehicle Hazard Boundary then the analysis of the
TOE/environment model will produce hazards directly, because the vehicle hazards exist at the bound-
ary of the vehicle.
If the Boundary of the TOE is not coincident with the Vehicle Hazard Boundary then the analysis of the
TOE/environment model does not produce the vehicle hazards themselves, but rather the causes of the
vehicle hazards that lie within the vehicle. For example, functions executing on a controller lead to out-
puts from electro-mechanical actuators which, if not to design intent, result in the vehicle being in a haz-
ardous state. Such a chain of events between an initial fault and the final hazard is shown in Figure 4.2,
which uses the definitions of Fault, Error and Failure given in IEC 61508 [4], and reproduced in the
Glossary of Terms3.
3 It should be noted that other definitions of these terms exist elsewhere.
36
Figure 4.2: Fault – Error – Failure chain of events within a vehicle
In cases like these either one, or both, of the following approaches should be taken:
• Use an inductive technique to relate lower level fault/error/failure to vehicle level effects;
• If the hazards at the vehicle hazard boundary have already been identified, use a deductive
technique to relate them to the lower level fault/error/failure.
It may be necessary to consider situations in which the outputs of the TOE are to be combined with those
of other systems to produce an emergent property (see Section 4.3.3). This is particularly likely to be the
case for hazards associated with the “driver in the loop” model of vehicle control (see Section 4.4.3).
The rationale for the combinations chosen, and those that are not chosen, should be documented, and the
choice should ensure that the worst-case scenarios are considered.
As described in Section 3.5.2, hazard identification is performed by “looking out” from the system
boundary into the external environment to identify how the system interacts with the rest of the world.
There are two principal techniques that may be used to undertake this hazard identification, either a
“What If?” analysis (see Appendix B) or a high-level HAZOP (see Appendix C). Other techniques may
also be applied, for example “Use Cases” (which can be an effective means of capturing requirements
for a state based system). If the “extends” construct is used to capture all the ways that the normal Use
Case could fail to achieve its goal, then consideration of the consequence of not achieving a particular
goal may reveal a hazard. Another approach to hazard identification is the use of Checklists; this is par-
ticularly suited to hazards that relate directly to the user, e.g. trap, burn, electrical shock.
As with all analyses, hazard identification can only be performed with staff that have the requisite
knowledge of the vehicle components involved. It should also use the initial safety envelope as a refer-
ence to identify whether the scenario being considered falls within, or outside of, the defined operational
and environmental limits of the vehicle. During the course of the analysis, changes or refinements may
be made to these limits based on a greater understanding of the system and how it will affect the vehi-
cle, and the initial safety envelope should be changed to reflect any such changes to produce the refined
safety envelope.
37
4.3.3 Multiple systems
When two or more systems are working together it is advisable to undertake a PSA on each one sepa-
rately before considering their joint functionality. There are two principal ways of looking for hazards
produced by two or more systems working together.
• Consider the communication path(s) between them, and undertake a HAZOP study
(see Appendix C).
• Consider each state of one system, and then consider the result of the consequential state(s)
of the other system(s) at that time.
A particular concern with multiple systems is an emergent property which can only occur when two or
more systems are all working together. This can sometime create a hazard even when each system is
working correctly on its own.
4.3.4 Hazard List
The end result of the hazard identification process is a set of hazards, and it is not unusual to find the
same hazard appearing on a number of occasions. Once the similarity of any hazards has been con-
firmed, or otherwise, a formal list of all the hazards should be created — the Hazard List. This List is a
primary input for the later stages in the safety process, as well as for the Safety Argument and the Safety
Case (see Section 2.7).
The Hazard List is a living document. Should a new hazard be identified later in the lifecycle then it
must be added to the Hazard List, and the Safety Case is not complete until all the hazards in the Hazard
List have been “closed”.
4.4 Hazard classification
4.4.1 Introduction
This section provides guidance for the activity of hazard classification. The inputs to the hazard classi-
fication phase are:
• A model of the system under analysis and its environment (see Section 4.2);
• The operating environment;
• The Hazard List (see Section 4.3.4);
• A refined safety envelope (see Section 4.3.2);
• The Safety Policy and any other relevant document that modifies, or further defines, the policy
for the particular project under consideration, e.g. Project Safety Plan (see Section 2.5).
In addition the project team needs a good knowledge and domain experience of the behaviour of the pos-
sible components, and of the way that a vehicle and its driver can behave.
38
The objective of this section is to describe a method for the classification of vehicle hazards using the
MISRA Risk Graph. The outcome of the classification is an estimate of the risk associated with a haz-
ardous event, presuming that the hazard exists. MISRA refers to this estimate as the “MISRA Risk
Level”. The MISRA Risk Level is later used to identify the safety integrity requirements necessary to
achieve a broadly acceptable level of risk (see Section 4.5).
4.4.2 The “IEC 61508” risk model
In many industry sectors, including those that generated the international standard IEC 61508 [4], the
model of risk is as follows:
• There is “equipment under control” (EUC) which poses a risk to its environment,
typically associated with a misdirected or uncontrolled release of energy
(the hazardous event) (see Figure 4.3);
Figure 4.3: IEC 61508 model of system and safety functions
• The equipment is controlled by electrical, electronic or programmable electronic (E/E) systems

which normally run autonomously. Human responsibilities are mainly supervisory, and active
intervention is only performed on rare occasions;
• This risk can be quantified, usually as a combination of the consequences of the hazardous
event and the probability of it occurring due to a malfunction of the equipment or its
E/E controller;
• Measures need to be taken to reduce this risk to a level considered “broadly acceptable”.
A broadly acceptable risk is a level of risk commensurate with the risk associated with
everyday life (see Figure 4.4).
39
Figure 4.4: IEC 61508 model of risk reduction
• In the context of IEC 61508, these measures include safety functions, implemented in
an electrical, electronic or programmable electronic (E/E) system. The safety functions
may either be implemented as a separate protection system or integrated into the
EUC’s control system.
• The safety requirements for safety functions are set in terms of a Safety Integrity Level (SIL)
which covers:
– Measures to avoid random hardware failures expressed as a design target for the probability
of failure to operate on demand (for protection systems) or the maximum acceptable failure
rate for dangerous failures (for functions which are part of EUC control systems);
– Measures to avoid or eliminate systematic failures in the system, hardware and
software design;
– Measures to tolerate random hardware failures.
4.4.3 MISRA risk model
This section describes the theoretical basis behind the MISRA Risk Graph. The use of the MISRA Risk
Graph itself is described in Section 4.4.4.
In road vehicles, there are only a few systems which conform to the IEC 61508 view of a protection sys-
tem or safety function. The majority of vehicle systems are concerned with the control of the motion of
the vehicle, and the safety of the situation depends on the correct, normal operation of these systems; not
simply on the availability of a specific safety function. Hazards can arise from the failure of these sys-
40
tems to function as specified either through a fault leading to an incorrect state or failure, or through a
dangerous function of the system. In addition, hazards can also arise through the interaction of the sys-
tem with its environment. An example of such an interaction is electromagnetic interference.
There are several types of E/E system, for example:
• Systems that allow the driver to control the motion and behaviour of the vehicle
(see Figure 4.5). It should be noted that the driver is normally “in the loop” in terms of
vehicle control, and hence must be taken into account when analysing vehicle system failures.
Figure 4.5: “Driver in the loop” model of vehicle control systems
• Systems that provide information upon which the driver’s strategy is devised.
• Systems to which a degree of control is delegated.
In the context of a safety function such as those envisaged by IEC 61508, a fault in a technical system
will generally lead to a failure to deliver the safety function (depending on the architecture and diagnos-
tic schemes implemented). In the automotive context a fault in a technical system can lead directly to a
hazardous event. However, this will only occur if all of the following conditions are true:
• The fault is present in a technical system leading to the system being in an unwanted or
potentially dangerous state (the hazard);
• The environmental conditions (including the scenario in which the vehicle is being driven)
mean that the driver is exposed to a hazardous situation;
• The driver is unable to control the safety of the situation following the appearance of the
hazardous situation.
This dependency may be represented by means of a state machine model, as shown in Figure 4.6. This
model shows the state transitions between a failure occurring in a system and a hazardous event occur-
ring.
41
Figure 4.6: State-machine model of automotive risk
It should be noted that a failure does not necessarily lead to a hazardous event, and thus in order to
perform a risk assessment it is necessary to evaluate the following parameters.
• P: The probability that the failure occurs. In Figure 4.6 this is the probability that a transition
occurs from State 1 to State 2, or from State 3 to State 4.
• E: The probability of exposure to a hazardous situation. In Figure 4.6 this is the probability
that a transition occurs from State 4 to State 5. It is the probability that, if the hazard is
present, that there is an “accident trigger” — an external event or condition which means that
the driver is exposed to a hazardous situation.
• V: The probability of failing to avoid the hazardous event. In Figure 4.6 this is the probability
that a transition occurs from State 5 to State 6. It is the probability that if the driver is in a
hazardous situation he/she will not be able to exercise control over the situation and prevent
a hazardous event from occurring.
• S: The severity of the outcome (i.e. the severity of the potential hazardous event).
42
Thus the goal of risk assessment is to determine the probabilities of the state transitions and combine
them with the severity in order to allocate a risk to the hazard. This is represented by a function of the
probabilities of the state transitions and the severity of the hazardous event, and therefore hazard risk is
defined as4:
f HR (P, E, V, S) 5
Note that in this function, since P, E and V are probabilities, they are therefore dimensionless. S is not
dimensionless, and its units depend on the severity classification scheme chosen. In this document S is
defined using the Maximum Abbreviated Injury Scale (MAIS) (see Section 4.4.4.1).
Risk analysis is concerned with setting requirements for the system such that the risk associated with
each hazard is at a broadly acceptable level. In general terms, this is done by identifying whether a haz-
ard risk is greater than the broadly acceptable level of risk; and if so, taking measures to modify one or
more of the parameters in the risk equation such that the hazard risk is less than or equal to “broadly
acceptable risk”. Note that this analysis relies on the existence of some well-defined measure of broad-
ly acceptable risk. The risk inequality can now be stated as:
f HR (P, E, V, S) ≤ (Broadly Acceptable Risk)
Typically it is not practical for the designers of automotive control systems to influence the values of E,
V and S as they are determined by factors outside their control. The most usual approach is therefore to
ensure that the value of P is such that the inequality holds.
The value of P arises from many factors related to the design and implementation of the control system.
The principal used in functional safety standards is that these factors can be identified and then con-
strained in such a way that the resulting value of P is also constrained. The degree of constraint is
referred to as the safety integrity. Underlying this approach is the assumption that meeting a set of con-
straint requirements, which address both random failures and systematic faults, implies that the desired
value of P has been achieved. It is this approach that is used in this document.
Thus P can be replaced by safety integrity so that the risk inequality becomes:
f HR ((Safety Integrity), E, V, S) ≤ (Broadly Acceptable Risk)
Risk analysis is then a process of setting the safety integrity parameter for each hazard to ensure that the
risk associated with that hazard is at or below the level of broadly acceptable risk.
4 Although parts of this chapter use mathematical notation, which implies a precise use of the symbols,
in practice the ideas being communicated are not completely defined mathematically and so the use of
the mathematical notation should only be taken as a convenient way of communicating the ideas.
5 The notation f (...) is used to denote a generalized function which maps the parameters.
x
43
The values of safety integrity are found using the MISRA Risk Level (R), and the values of R are deter-
mined using the same parameters, E, V and S, as those that appear in the above inequality.
R = f RL (E, V, S)
By using the same parameters it is possible to so arrange the scheme that the value of R is determined
such that the risk inequality holds. The values of R are then mapped to a set of constraint requirements
(see Section 4.5.3.1)
In practice a system will have several hazards and it is standard practice to set the safety integrity
requirement for the system to be the highest of all of the Safety Integrity (SI) requirements of the indi-
vidual hazards.
SI system = max(SI 1 , SI 2 , … SI n )
A common approach to evaluating a function such as f RL in a qualitative manner is to use a risk graph,
in which each parameter is assigned one of a discrete set of values. A discussion on how many values
each parameter is allowed to take, and their actual values, can be found in [20].
4.4.4 MISRA Risk Graph
This section describes how to use the MISRA Risk Graph. The theoretical basis behind it is described in
Section 4.4.3.
The MISRA Risk Level, R, can also be written as f RL (S, E, V) with the parameters now listed in the
order of their use within the MISRA Risk Graph. The MISRA Risk Graph itself is shown in Figure 4.7,
with a tabular version in Table 4.2. It is traversed from left to right once the values for each parameter
have been found. The parameters themselves are defined in Table 4.1 and the following sections.
44
Figure 4.7: MISRA Risk Graph
For the failing to avoid parameter, V, two different approaches were found to be necessary:
• For those hazards that are associated with systems which can be represented using the “driver
in the loop” model (see Figure 4.5) the concept of “controllability” is useful for assessing the
possibility to avoid the hazard. In this case, Controllability refers to the ability of the driver
(or other traffic participants) to control the safety of the situation in the presence of the
hazard, and V = C.
• For those hazards which do not affect the driver’s ability to maintain control of the vehicle,
the action to avoid the hazardous event is usually to physically remove oneself, or a body
part, from the hazardous area, and V = A.
There are a few hazards that are difficult to place into only one of these categories, e.g. unintended
deployment of an air bag. In these situations both approaches should be used because they will each
highlight different aspects of the hazard.
45
The use of the resulting MISRA Risk Level to determine the required safety integrity is described below
in Section 4.5.
Risk parameter Classification
S1 Minor injuries
S2 Major injuries
Severity (S) Severe or life-threatening injuries (with the possibility of a

(see also Section 4.4.4.1) S3
maximum of one6 person sustaining unsurvivable injuries)
Severe or life-threatening injuries (with the possibility of

S4
multiple persons sustaining unsurvivable injuries)
Rare exposure to a hazardous situation in the event of

Probability of exposure to E1
a hazard.
a hazardous situation (E)
in the event of a hazard
Regular or permanent exposure to a hazardous situation
(see also Section 4.4.4.2) E2
in the event of a hazard.
Possibility of avoiding A1 Possible under certain conditions.

the hazardous event (A)
(see also Section 4.4.4.3) A2 Almost impossible.
This relates to hazardous situations that produce operational

C1 limitations, but avoidance of an accident (hazardous event)
is normally possible with a normal human response.
This relates to hazardous situations where there is a reduction

in the safety margin, and whilst avoidance of an accident
C2
(hazardous event) is difficult, it is usually possible with a
sensible human response.
Controllability (C)
(see also Section 4.4.4.4) This relates to hazardous situations that are not normally
controllable, and avoidance of an accident (hazardous event)
C3 is very difficult. However, under favourable circumstances,
some control can be maintained by an experienced
human response.
This relates to hazardous situations that are not controllable,

C4
and the outcome cannot be influenced by a human response.
Table 4.1: Definition of MISRA risk parameters
6 At the time of writing, in the event that an accident includes fatalities,

the average number of fatalities that occur is close to one.
46
Severity Probability MISRA Risk Level
Hazard type
S E A or C R
A1 No Risk
E1
A2 R1
S1
A1 R1
E2
A2 R2
A1 R1
E1
A2 R2
S2
Hazards associated A1 R2
E2
with an area of A2 R3
danger A1 R2
E1
A2 R3
S3
A1 R3
E2
A2 R4
A1 R3
E1
A2 R4
S4
A1 R4
E2
A2 R5
C1 No Risk
C2 No Risk
E1
C3 R1
C4 R2
S1
C1 No Risk
C2 R1
E2
C3 R2
C4 R3
C1 No Risk
C2 R1
E1
C3 R2
C4 R3
S2
C1 R1
C2 R2
E2
Hazards associated C3 R3
with the “driver in C4 R4
the loop” model C1 R1
of vehicle control C2 R2
E1
C3 R3
C4 R4
S3
C1 R2
C2 R3
E2
C3 R4
C4 R5
C1 R2
C2 R3
E1
C3 R4
C4 R5
S4
C1 R3
C2 R4
E2
C3 R5
C4 R5+
Table 4.2: Tabular definition of MISRA Risk Graph
47
4.4.4.1 Severity classifications (S)
The severity classifications represent the upper limit on the severity of any credible accident scenarios
(hazardous events) associated with the hazard being classified.
In general, injury does have a recognized severity scale, called the Abbreviated Injury Severity
scale [21]. This scale is based on a medical assessment of injuries, co-incidentally derived from
automotive accident victims, and provides a helpful way to understand and categorize the possible
consequences of an accident. For the purposes of this document it is more convenient to use the
severity of the worst injury, known as the Maximum Abbreviated Injury Scale (MAIS). The six MAIS
levels have been condensed into Severities S1, S2 and S3.
Since the scope of the MISRA Risk Graph includes systems which can affect more than a single vehi-
cle, an additional value for the severity parameter, S4, is also used.
4.4.4.2 Probability of exposure to a hazardous situation in the event of a hazard (E)
This parameter represents the probability that the situation is such that the failure of the system (the haz-
ard) is present in a hazardous situation, i.e. that the “accident trigger” is present.
For those hazards where the driver’s ability to maintain control of the vehicle has been reduced, then the
issues that create a hazardous situation include:
• The environment (weather conditions) hot/cold, dark/light, wet/dry, hilly/flat;

• The road style: number of lanes, junction types, surfaces, signage;
• The status of the vehicle when the failure occurs (speed, direction);
• The density and status of other vehicles, or road users, in the immediate vicinity.
When a value is being assigned to the exposure parameter it will need to be what can reasonably be
assumed to be an average value taking into account:
• All markets into which the vehicle is to be sold;

• The possible driving styles of the customers;
• The possible vehicle usage patterns: e.g. urban, multi-lane, single lane, rural roads, towing.
Clearly, given so much diversity inherent within a global mass-market product, it is difficult to give
advice on how to make this judgment. If E1 is chosen it means that a significant risk reduction can be
argued from reduced exposure.
For those failures which do not affect the driver’s ability to maintain control of the vehicle, the exposure
is related to the time spent in the proximity to the hazardous system failure, for example the time spent
working in the engine compartment for vehicle repairers to be exposed to the un-commanded movement
of mechanical parts, cooling fans, etc.
48
4.4.4.3 Possibility of avoiding a hazardous event (V or A)
For those failures which do not relate to the “driver in the loop” model of vehicle control, the action to
avoid the hazardous event is usually to physically remove oneself, or a body part, from the hazardous
area. In these cases it is appropriate to consider only whether or not this is reasonably possible, and not
to have a large number of possible values of the parameter. Examples of such system failures include:
• Failure of an air bag to deploy in a crash event;

• Movement of the seats resulting in crushing or trapping the occupants;
• Movement of the vehicle body resulting in crushing or trapping the those working on a vehicle;
• The continued delivery of fuel after a crash;
• Doors being locked after a crash event;
• Production of smoke or fire;
• Ejection of hot fluid during crash events resulting in burns to vehicle occupants or
rescue workers.
For these types of system failures the Possibility to Avoid (A) parameter is used, which represents the
possibility that the person exposed to the risk can take an action to avoid it. Only two values of A are
used, since it is not considered possible to distinguish between different situations with any greater pre-
cision than this. If A1 is chosen, it means that a significant risk reduction can be argued from the action
to avoid.
A vehicle that is moving without a driver present will be a danger to surrounding area, and to any per-
son within that area, i.e. the vehicle is an unintelligent projectile. Since the people in the area of danger
may be able to remove themselves from the danger zone before impact occurs, the Possibility to Avoid
(A) parameter should be used for this type of hazard.
4.4.4.4 Controllability (V or C)
The risk model described in Section 4.4.2, where consequence refers to the outcome of a particular haz-
ardous event, is used in constant and known environments. However, for a moving vehicle, the road,
traffic and weather situations are changing constantly and so, if one were to try to assess the actual out-
come of an accident, or hazardous event, associated with the control of a moving vehicle, one ends up
with “it depends on the situation at the time”. Neither is taking the worst-case scenario much help,
because it is usually possible to dream up a situation where even what would normally be considered to
be a “mild” hazard could produce the worst possible conceivable hazardous event.
For systems which can be represented using the “driver in the loop” model (see Figure 4.5) the concept
of “controllability” is useful for assessing the possibility to avoid the hazard. In this case, Controllability
refers to the ability of the driver (or other traffic participants) to control the safety of the situation in the
presence of the hazard. It should be noted that the phrase “safety of the situation” has a wider connota-
tion than just the safety of the single vehicle with a fault. It relates to the entire traffic situation that
might be affected by the consequences of the hazard. Thus Controllability provides a qualitative assess-
ment of the:
Controllability of the safety of the situation in a hazardous situation,
and is similar, though not identical, to the categorization of hazards used in civil aviation [22].
49
For those failures where the driver’s ability to maintain control of the vehicle has been reduced, the abil-
ity of the driver to maintain the safety of the situation depends on:
• The level of system inter-dependency;

• The loss of authority or control due to the system failure;
• The provision of backup or other mitigation;
• The reaction time of the driver and/or other people affected.
For a particular application of a system to a vehicle most of these factors are known with a high degree
of certainty, and it is only the reaction time that must be assessed. Based on the assessment of the loss
of authority or control, the effort required by the driver (or other participants, but primarily the driver)
to take actions that maintain the safety of the situation has to be assessed, taking into account the fol-
lowing reaction time factors:
• Recognizing the change of circumstances;

• Formulating a strategy to maintain the safety of the situation;
• Applying the corrective actions.
It should be noted that whether the failure to maintain the safety of the situation results in an accident,
or Hazard Event, is taken into account by the exposure parameter, E.
A systematic technique for deriving values for the Controllability parameter can be found in Appendix D.
Although this appendix uses a value of C0, since a “hazard” with this value would imply that it is not
safety-related, it is therefore not used in the MISRA Risk Graph.
Since the assignment of a Controllability classification includes an assessment of human behaviour, it is

recommended that the phenomena of “risk compensation” and “de-skilling” (see Section D.2.3.1) should
be acknowledged in the chosen value of either the A parameter or C parameter as appropriate, otherwise
the risk associated with the hazard may be lower than is in fact warranted. To do this it may be neces-
sary to involve human factors experts and psychologists.
The Controllability scheme is the only one suggested in the MISRA Development Guidelines of
1994 [1] and is referenced in IEC 61508-5 [4]. Over the years it has been used successfully to classify
all types of hazard associated with moving road vehicles, for systems located in a vehicle, at the road-
side and, in research projects, for co-operative systems.
4.4.5 MISRA Risk Graph examples
4.4.5.1 Introduction
It should be noted that it is not possible to provide a simple list of systems with their corresponding
MISRA Risk Level that can be used in all circumstances. Each vehicle has its own set of characteristics
and these will affect the choice of Risk Graph parameters or Controllability parameters, e.g. hazards
associated with an engine will be affected by its power. In addition an increasing number of systems are
being used in more than one application, each with its own set of hazards. Thus, whilst the values of the
parameters in the following two examples are indicative, they would have to be validated for a given
vehicle.
50
4.4.5.2 Hazard associated with the “driver in the loop” model of control
“What if?” scenario: a “normal” family saloon vehicle petrol (gasoline) engine management system
(EMS) develops a fault such that the engine is unable to provide power to the wheels.
Hazard: the vehicle slows down and the driver no longer has full longitudinal control.
Inside the system boundary: EMS (and engine).
Outside the system boundary: gears, brakes and steering (unaffected in the short term).
It is now necessary to find values for each of the MISRA Risk Graph parameters:
Severity: whilst this hazard could occur at any time, and in any traffic conditions, a vehicle slowing
down with lateral control is unlikely to lead to an accident with very severe consequences. Thus the
Severity parameter has a value of S2.
Exposure: given that the hazard exists, the exposure to an “accident trigger” will be regular or perma-
nent. Thus the exposure parameter has a value of E2.
Controllability: since this hazard relates to the “driver in the loop” model, it is necessary to find grades
for each of the following four topics (see Appendix D):
• Levels of system interaction — The EMS does not provide any data that is used to affect the
functioning of any other system that is used to control the safety of the situation. The EMS is
therefore an autonomous system or function: Grade E.
• Loss of authority/control due to the hazard — Whilst engine power contributes to the control
of the safety of the situation, so do all the functions outside the system boundary. The loss of
control is therefore partial: Grade C.
• Provision of backup/mitigation — Although acceleration is lost, the driver will still be able to
decelerate with the brakes, and have full lateral control with the steering. The provision of
backup is therefore with reduced functionality: Grade C or D.
This suggests that a driver should be able to avoid an accident under favourable circumstances provid-
ed this is supported by the fourth parameter.
• Reaction time — Whilst drivers will have to react immediately to this failure, and perform
functions that they were not expecting to have to do at that time, this should be within their
normal capabilities. The reaction time is thus similar to human: Grade C.
Note that since this failure produces gradual deceleration, issues such as the inter-vehicle gap or risk
compensation are not relevant to this classification. It is also assumed that the vehicle, together with the
surrounding traffic, is being driven with proper care and attention.
Final grading: The grades obtained are thus:
E C C/D C,
51
which suggest that a final grade of C would be appropriate. However, before allocating the correspon-
ding Controllability classification to this hazard it is first necessary to confirm that its full definition does
indeed reflect the situation.
A final grade of C implies value of the Controllability parameter of C2 (“This relates to hazardous situ-
ations where there is a reduction in the safety margin, and whilst avoidance of an accident (hazardous
event) is difficult, it is usually possible with a sensible human response”), which is a reasonable descrip-
tion of this hazard.
From this a value R2 is arrived at for the MISRA Risk Level (see Table 4.3).
Hazard I E C A MISRA Risk Level

The vehicle slows down and the driver
S2 E2 C2 – R2
no longer has full longitudinal control
Table 4.3: Engine management system failure hazard classification
4.4.5.3 Hazard not associated with the “driver in the loop” model of control
“What if?” scenario: An electric window protection system fails to stop the window lift mechanism
when an object obstructs the movement of the window glass.
Hazard: the window lift mechanism applies a continuous force to the object.
It is now necessary to find values for each of the MISRA Risk Graph parameters:
Severity: since there are known cases where children have been killed in this situation, the Severity
parameter has a value of S3.
Exposure: since people do not put an arm or head through the window very often the exposure param-
eter has a value of E1.
Possibility of avoiding the hazardous event: this parameter is used because the hazard does not relate
to the “driver in the loop” model. The trapping process, and the incurring of an injury, is not instanta-
neous and the switch controls are readily available in the vehicle; thus, “under certain conditions”, it will
be possible to avoid the hazardous event. The Avoidance parameter therefore has a value of A1.
From this a value R2 is arrived at for the MISRA Risk Level (see Table 4.4).
Hazard S E C A MISRA Risk Level

Electric window trap hazard S3 E1 – A1 R2
Table 4.4: Electric window trap hazard classification
52
4.5 Risk assessment and system safety requirements
4.5.1 Introduction
This section provides guidance for the activity of risk assessment. The inputs to the risk assessment
phase are:
• A model of the system under analysis and its environment (see Section 4.2);
• The list of hazards classified according to the company Safety Policy, e.g. using the scheme
described in Section 4.4 or an alternative;
• The refined safety envelope;
• Project Safety Plan, which includes a definition of broadly acceptable risk;
• Safety Policy and the Project Safety Plan;
The process of risk assessment needs an understanding of the relationship between:
• The risk associated with the system, as captured by the hazards and their classification;
• The possible risk reduction measures that can be applied;
• The residual risk, after the reduction measures have been applied.
It is then possible to compare the risk associated with the system against the definition of broadly accept-
able risk in order to specify the risk reduction requirements, and hence create the residual risk. The risk
reduction requirements specify the degree of mitigation against random hardware and systematic fail-
ures and these measures may apply to both programmable and non-programmable technologies.
Provided it can be shown that each hazard is independent of the others, they can be considered separate-
ly, each with its own set of safety requirements. In that case the risk associated with each hazard must
each be demonstrated to be broadly acceptable.
The risk reduction requirements need to be defined before the detailed design work begins. Once a
detailed design has been created it is subject to a Detailed Safety Analysis (see Chapter 5), whose results
show to what degree the risk reduction requirements have been met.
The remainder of this section presents a possible definition of broadly acceptable risk and then goes on
to show how this may be used to set risk reduction requirements, and finally how the results of the
Detailed Safety Analysis can be compared with the initial requirements.
4.5.2 Derivation of target system safety requirements
For most vehicle systems the severity of the consequence of a hazard is inherent in the nature of those
systems, and therefore risk can usually only be reduced by lowering the probability or frequency of
occurrence; though it may be possible to provide some mitigation with, for example, air bags.
53
As described in Section 4.4.3, risk analysis is the process of setting the safety integrity parameter for
each hazard to ensure that the risk inequality holds:
f HR ((Safety Integrity), E, V, S) ≤ (Broadly Acceptable Risk)
Safety integrity specifies a set of constraint requirements which, if met, justify a claim that the probabil-
ity of the failure is such that the risk inequality holds. The set of constraint requirements has two aspects,
measures to address random hardware failures and measures to address systematic failures.
The measures to address systematic failures should be taken from other functional safety standards or
guidelines (see Sections 4.5.3.1 and 5.2.5).
The measures to avoid random hardware failures are expressed as a design target for the maximum
acceptable failure rate for dangerous failures, h. The relationship between h and the MISRA Risk Level
(R) is expressed in the inequality:
f HR1 (h, R) ≤ (Broadly Acceptable Risk)
Table 4.5 provides a set of qualitative descriptions for the values that h can take [1]. Since these words
are descriptive only, before this table can be used numerical values will need to be assigned to them,
which are recorded in the Safety Plan. As is the convention with safety standards, the values will nor-
mally change by an order of magnitude for each value of R. One possible set of values can be found in
Appendix E.
MISRA Risk Level h — acceptable hazard occurrence

R1 Reasonably Possible
R2 Unlikely
R3 Remote
R4 Very Remote
R5 Extremely Improbable
R5+ See text
Table 4.5: Acceptable probability of occurrence for each MISRA Risk Level
R5+ denotes a situation that is only considered to be acceptable on very rare occasions, and then only
with the agreement of senior management. In addition, sole reliance should never be placed on E/E sys-
tems to maintain the safety of the situation, and the acceptable hazard occurrence should be at least an
order of magnitude smaller than for R5. Since it is anticipated that R5+ will not be needed for a number
of years, it has been omitted from later tables in these Guidelines.
54
4.5.3 System safety requirements
If the MISRA Risk Level is R1, or higher, then it is necessary to identify a specific set of requirements
to reduce the risk to an acceptable level — the safety requirements. These can be of two basic forms
(see also Figure 4.8):
Figure 4.8: Safety specification
• Safety functions: functions to be implemented by a safety-related system, which are intended

to maintain a safe state in respect of specified hazards;
• Safety integrity: the degree of confidence in a safety-related system satisfactorily performing
the required safety functions under all the stated conditions within a stated period of time.
The objective of the safety functional requirements is to maintain a safe state in the presence of one, or
more, faults. There are three generic types of safe state:
• Maintain full control: the system must be fault tolerant, i.e. it must continue to perform
a required function in the presence of faults or errors. This is also called “fail live”.
• Maintain partial control: the system may lose some high-level functionality, but must
continue to perform certain functions in the presence of faults or errors. This is also called
“limp home”.
• May lose functionality
– The system is not crucial to the control of the vehicle and there is a state it can be put into
which does not itself constitute a hazard, e.g. suspension dampers default to the
hardest setting.
– The system is crucial to the control of the vehicle but the driver is given sufficient warning
and control is maintained long enough for the vehicle to be placed in a safe location,
e.g. at the side of the road. This is also called “fail safe”.
Thus, in the automotive context, safety functions are likely to perform one or more of the following
tasks:
• Detect erroneous states, values, actions or inactions;

• Perform mitigating actions, e.g.
– Move to a safe state;
– Communicate with other E/E systems of the vehicle;
– Communicate with the driver.
The safety requirements can be obtained by analysing the system design to determine how the failure of
sub-systems or components may give rise to the hazards. This can be done by using either a high-level
55
Fault Tree Analysis (see Appendix G), or by using a “What Causes?” analysis. The distinction between
them lies in the level of formality that is used. The possible causes of each hazard are developed into a
cause-event tree, so far as the current information permits. This tree is then analysed to identify the nec-
essary system properties to mitigate the hazard by “cutting” the cause-event chain, and thus prevent the
hazard from occurring. The identified system properties are the high-level safety requirements, and
should be explicitly identified as such in the design documentation.
Once this has been done, a review of the safety requirements should be undertaken to check that the safe-
ty integrity requirements are likely to be met by the major sub-system or components. This may give an
early indication of where redundancy may be required, e.g. with regard to throttle demand sensing. If
the safety integrity requirements cannot all be met then it may be possible for one component to com-
pensate for another. Thus, for example, a component hardware reliability target cannot be met but it is
possible for a software function to detect the hardware failure and take some action to avoid the hazard
occurring. In the case where such compensation is not possible, then it will be necessary to re-work the
design.
4.5.3.1 Safety integrity requirements
The derived values of broadly acceptable risk due to technological failures are for both systematic and
random hardware failures — there is not, and never can be, any distinction between them from the
perspective of the person at risk. Therefore the safety integrity requirements deal with both random hard-
ware and systematic failures.
The random safety integrity requirements are intended to mitigate against random hardware failures and
are used for two distinct purposes. One is deciding the general approach as realized in the overall sys-
tem architecture. The other is stating the degree of mitigation required by each specific hazard.
The random safety integrity requirements may be given quantitatively and/or qualitatively. The quanti-
tative requirements are given as the maximum probability of occurrence of the hazard. The qualitative
requirements are given as rules concerning combinations of failure modes that can result in a hazard, for
example, “no single point failures shall cause a hazard requiring a SILx safety function”. The Safety
Policy should state how the random safety integrity requirements are to be specified and used.
Quantitative requirements are useful for guiding decisions concerning the appropriate system architec-
ture design and for attributing target failure rates to broad areas of that design. However, if they are used
to state the degree of mitigation required by each hazard, it may be difficult to obtain the necessary fail-
ure data needed to verify the requirement.
Qualitative requirements are less useful for guiding decisions concerning the appropriate system archi-
tecture design but are easier to evaluate when verifying the requirements for the degree of mitigation
required by each hazard.
Random hardware failures relate to failures of mechanical and electrical components that occur due to
latent faults, or wear out mechanisms. These are traditionally handled in terms of reliability and the
probability of hazard occurrence for each MISRA Risk Level can easily be re-written as a random safe-
56
ty integrity requirement for each MISRA Risk Level (see Table 4.6). The probabilities presented in
Table 4.6 represent the target that is required, and this may be achieved through a combination of pro-
grammable technologies and other technologies (see Figure 4.4), with the safety targets associated with
the programmable system being reduced accordingly. If the Safety Policy requires the use of quantita-
tive random safety integrity requirements, then the Acceptable Hazard Occurrence Frequencies derived
in Appendix E can be used. Alternatively the organization can derive its own set of targets.
h — random safety integrity requirement

MISRA Risk Level
Probability of a dangerous failure
R1 Reasonably Possible
R2 Unlikely
R3 Remote
R4 Very Remote
R5 Extremely Improbable
Table 4.6: Random safety integrity requirements for each MISRA Risk Level
Systematic failures relate to deterministic failures that are a result of human error in the design process.
Design errors may be made in the system design, the hardware design or in the software. Whilst both
the system design and the hardware design, being realized in mechanical components, may also suffer
from random failures, software itself does not suffer from random failures even if the appearance of
some failure modes sometimes gives this impression. IEC 61508 [4] does contain systematic safety
integrity requirements for system and hardware design, and the next version is expected to contain some
for the design of ASICs.
The failure rate for systematic failures that lead to a hazard is assumed to be insignificant in comparison
(note — this is not to say that there are no software errors) provided that the systematic safety require-
ments are complied with. These include:
• Appropriate software architecture;

• Hardware detection of software failures;
• Software self-checking of software failures;
• Software checking of hardware failures;
• Process measures to avoid the making of errors or their detection before shipping.
Systematic safety integrity requirements for software are specified in terms of Safety Integrity Levels
(SILs). MISRA recognizes 4 Integrity Levels (in the past Level 0 was used to denote non-safety-relat-
ed requirements), and associated with each Integrity Level is a definition of software development
process rigour [1]. The underlying concept of Integrity Levels as a risk reduction measure is that the
more rigour that is applied to the software development process the more likely it is that errors will not
be made, or else they will be found before release of the software. If all the measures defined by a par-
ticular Integrity Level have been met, then it is considered that the necessary risk reduction has been
57
achieved. The degree of rigour of the MISRA Integrity Levels 1–4 [1] are considered to be broadly in
line with the requirements of IEC 61508-3 Safety Integrity Levels 1–4 [4].
Table 4.7 defines the relationship between the MISRA Risk Level and the systematic safety integrity
requirement given in terms of SILs.
MISRA Risk Level Systematic safety integrity requirement
R1 SIL 1
R2 SIL 1
R3 SIL 2
R4 SIL 3
R5 SIL 4
Table 4.7: Systematic safety integrity requirement for each MISRA Risk Level
Where the software in a single unit can give rise to a number of different hazards with different MISRA
Risk Level values, then the SIL value assigned to that software is the one associated with the highest
MISRA Risk Level.
Where the software consists of both safety functions and non-safety-related functions, all the SIL
requirements of the safety function also apply to all the non-safety-related functions unless it can be
demonstrated that it is not possible for a non-safety-related functions to fail in such a way that it affects
any safety functions.
Note that the relationship given in Table 4.7 assumes that the software can directly cause the hazard. If
the analysis of the system design demonstrates that this is not the case (see Section 5.2.5), then it may
be permissible to reduce the SIL assigned to the software.
4.5.4 Residual risk and risk assessment
Residual risk is the risk that remains once all the risk reduction measures have been put in place. The
residual risk may be greater than the broadly acceptable risk for two main reasons:
• It is not practicable to reduce the risk into the broadly acceptable region, or
• Due to some safety dividend associated with the system (e.g. air bags) a lower level of risk
reduction is deemed appropriate.
In order to make a sensible decision concerning risks that are greater than the broadly acceptable risk, it
is necessary to have some framework within which to work. A suggestion is presented here based on a
set of Risk Classes defined in Table 4.8. These Risk Classes relate to the acceptability of the residual
risk. A Risk Class of I is unacceptable under any circumstances while a Risk Class of IV would be
58
broadly acceptable. Risk Classes II or III must be managed according to the guidance given in Table 4.8.
Risk Class Description

I Unacceptable
II Undesirable
III Acceptable with sign-off
IV Broadly Acceptable
Table 4.8: Risk class definitions
If it is deemed reasonable that both the random and the systematic safety integrity requirements can be
met for a particular hazard, then that hazard is assigned to Risk Class IV. However, if it is thought like-
ly that either of the random or the systematic safety integrity requirements cannot be met for a particu-
lar hazard, then that hazard is assigned to one of the other Risk Classes. The overall relationship is given
in Table 4.9.
MISRA Risk Level
Probability of a dangerous failure R5 R4 R3 R2 R1 SIL

h — random safety integrity
Reasonably Possible I I II III IV SIL1
Systematic safety integrity

Unlikely I II III IV IV SIL1
requirements
Remote II III IV IV IV SIL2 requirements
Very Remote III IV IV IV IV SIL3
Extremely Improbable IV IV IV IV IV SIL4
Table 4.9: Derivation of risk class
Where a hazard associated with a system is in a Risk Class other than Risk Class IV, the preferred course
of action is to re-assess the design and the risk reduction measures so as to bring the result into Risk
Class IV. If this is not possible, then the ALARP principle [23] may be applied if it can be argued that
the overall safety of the vehicle occupants, and all other road users, is increased by the deployment of
the system of interest using a set of risk reduction requirements that can be met.
59
In the event that it becomes necessary to justify a hazard in a Risk Class other than IV, there needs to be
a mechanism, contained within the safety management process, which states how it will be done.
Different criteria may be used for system suppliers than for vehicle manufacturers. Typically, a suitably
senior person should authorize this decision on behalf of the organization. The allocation of this respon-
sibility is a matter for the company Safety Policy (see Section 2.4). In general the higher the Risk Class
then the more senior should be the corresponding signatory.
4.5.4.1 Risk class re-assessment
As a result of performing the Detailed Safety Analysis on the design (see Chapter 5), it will be possible
to predict the occurrence of hazardous failure modes with a certain degree of confidence. Also, as the
software is written it is possible to have the development process assessed for compliance with the SIL
requirements. If, as a result of the knowledge gained during the realization phase, it becomes apparent
that any of the safety integrity requirements will not be met in full, then the Risk Class should be re-
assessed and a course of action decided by senior management as described above.
4.6 Conclusion of preliminary safety analysis
The principal outputs from the PSA process are:
• The high-level safety requirements;

• A safety integrity level for the system;
• An outline Safety Argument (see Section 2.7);
• An updated version of the Project Safety Plan (see Section 2.5).
These are passed on to the Detailed Safety Analysis process. Should changes be made to any of the orig-
inal PSA inputs, e.g. system functional requirements, operating environment, then it will be necessary to
repeat (part of) the PSA process.
60
5. Detailed safety analysis
5. Detailed safety analysis

5.1 Introduction
The purpose of Detailed Safety Analysis (DSA) is to ensure that the safety requirements set during the
PSA (see Chapter 4) have been implemented in the design in accordance with the Safety Policy (see
Section 2.4). The safety requirements arise from the classification of the hazards and the Safety Policy
statements regarding what is considered necessary for the system to be free from unacceptable risk.
The hazards addressed by the DSA arise from hazardous failures within the system, and the safety
requirements fall into 2 categories (see also Section 4.5.3):
• Safety functions: functions to be implemented by a safety-related system, which are intended

to maintain a safe state in respect of specified hazards;
• Safety integrity: the degree of confidence in a safety-related system satisfactorily performing
the required safety functions under all the stated conditions within a stated period of time.
Hazardous failures arise as a result of random or systematic causes and there are safety integrity require-
ments for both categories (see Table 4.6 and Table 4.7):
• Random safety integrity requirements define the criteria by which the random hardware
failures that can lead to a hazard are judged as acceptable. The criteria can be quantitative
or qualitative and should be stated in either the Safety Policy or the Safety Plan.
• Systematic safety integrity requirements specify design and development measures that are
intended to avoid or eliminate systematic faults.
In order to ensure that the safety requirements set during the PSA have been met, and have been imple-
mented in the design in accordance with the Safety Policy, it is necessary to perform the following DSA
process steps (see also Section 3.6 and Figure 3.6):
• Design the system so that it meets the safety requirements.

– The design should implement safety functions.
– The design should meet random safety integrity requirements.
– The design process should conform to the systematic safety integrity requirements.
• Check by analysis that the system design meets the safety requirements.
– Use inductive and deductive analysis to confirm whether the hazards recorded in the Hazard
List can be caused by failures of the system and, if they can, that the measures taken to
prevent and manage the failures are in accordance with the Safety Policy.
– If, during the analysis, one or more additional hazards are found to exist, the PSA should
be revisited and their implications explored. Particular attention should be given to the
continued appropriateness of the previously derived SIL(s).
• Check that each hazard has been mitigated and that the product is safe.
– Confirm that the safety functions have been implemented correctly, and that they provide
the hazard mitigation intended.
61
5. Detailed safety analysis (continued)
– Confirm that the random and systematic safety integrity requirements have been met.
– If the safety requirements are not in compliance with the Safety Policy, then that fact
identifies the need for additional mitigation, possibly including re-design, or acceptance
of the deviation by sign-off from senior management, see Section 4.5.4.
DSA is an iterative process and its analyses are performed in parallel with the system design and devel-
opment. The results of the DSA are used in the creation of the Safety Case which must demonstrate, with
a sufficient level of confidence, that the system is free from unacceptable risk, in accordance with the
Safety Policy.
The actual system design will be represented by formally issued drawings, schematics, etc., and the
resulting analysis should reference these source documents. It is these source documents that are
analysed, so if the design and/or drawings change for whatever reason, the existing Safety Case may no
longer be valid, and the DSA will need to be reviewed and modified if necessary. If any part of the DSA
is modified then all decisions based on it will need to be reviewed and those processes affected by the
changes repeated as necessary.
5.2 System design
The inputs to this phase are:
• A detailed description of the system requirements, architecture and operating environment;

• A system model (see Section 4.2);
• The high-level safety requirements (see Section 4.5.3);
• Safety Policy;
The system design has to satisfy both the system requirements and the (high-level) safety requirements.
The resultant design is expressed in documentation that shows:
• The system design;

• The component parts and the total Bill of Materials.
5.2.1 Conformance with the Safety Policy
If the Safety Policy has statements concerning design, for example, there shall be no single point fail-
ures, then the system must be designed to meet these criteria.
5.2.2 Derivation of the low-level safety requirements
Quantitative targets for random hardware failures can be used to guide the architectural design, e.g.
degree of redundancy required. This architectural design can then be analysed using a deductive method,
e.g. Fault Tree Analysis (FTA) (see Section 5.4), to get an indication at an early stage whether or not the
62
proposed architectural design will comply with the random safety integrity requirements; see
Section 4.5.3.1. This evaluation can be performed by an analysis of the cut-sets and/or the use of
generic hardware failure data depending on the way that the random safety integrity requirements are
specified. If this analysis indicates that the random safety integrity requirements may not be met, con-
sideration should be given to the use of further design redundancy and/or additional safety functions.
When input data is taken off a networked data bus, it is possible to assign safety requirements to the com-
munications layer and the source of the data.
5.2.3 Implementing the safety functions
Safety functions normally detect erroneous states, values, actions or inactions (which arise from system-
atic failures or random hardware failures) and take actions in order to mitigate any hazards that may arise
as a result (see Section 4.5.3). Since these functions must not in themselves cause a hazard, it is neces-
sary to determine what actions are required to produce a safe state. For example, when a hardware
watchdog is to be used to detect and manage gross processor failures, it is necessary to consider how the
resultant action will affect the actuators being controlled, and ensure that no hazards will be caused dur-
ing the reset period by the reset actions, such as considering the default drive states of the actuators while
the reset is active.
5.2.4 Meeting the random safety integrity requirements
The criteria for the acceptable occurrence of random hardware failures (see Table 4.6) are met mainly
by architectural measures. There are, however, trade-offs that can be made between different technolo-
gies, e.g. software diagnostics and failure management for components that would otherwise not meet
the criteria; or hardware watchdogs, etc., to protect against software malfunctions. Note that these are,
effectively, new safety functions.
5.2.5 Meeting the systematic safety integrity requirements
The requirements that aim to avoid or eliminate systematic faults relate to the process (methodology,
measures and techniques) that will be used during the development, in particular to produce the software.
The initial SIL required comes from Table 4.7, but it may be possible to use architectural measures to
reduce the SIL associated with particular components (see IEC 61508 Part 2 [4]). This document
assumes that there will not normally be a separate protection system, and that therefore the application
functional requirements, and the safety functions, are all executed on the same hardware. Thus, the tech-
niques and measures required by the SIL will normally apply to both the application functions and the
safety functions.
The Safety Policy will state the Standard, e.g. IEC 61508 [4], or Guidelines, e.g. MISRA Development
Guidelines [1], from which the measures and techniques to be used will be selected. These should be
formalized within the company Quality Management System.
63
5.2.6 Safety function validation
The products of the design process must be verified and/or validated, in particular all the safety func-
tions included in the original design, or added as a result of the inductive and deductive analyses. It is
necessary to validate that both of the following hold true:
• The safety functions are correctly implemented;

• The safety functions achieve the degree of hazard mitigation intended.
The records of the validation of the safety functions are evidence required as part of the Safety Case in
support of the Safety Argument (see Section 2.7).
5.3 Inductive analysis
5.3.1 Introduction
The first principal stage of DSA is an inductive analysis although, in practice, inductive analysis and
deductive analysis need not necessarily be carried out sequentially, but can be performed in parallel.
Inductive analysis is a bottom-up approach that works upwards from the fault, or failure mode, to the
resultant effect. It only considers the effect of a single fault at a time. The most common inductive tech-
nique used in the automotive industry is Failure Mode and Effects Analysis (FMEA) (see Appendix F).
The inputs to an inductive analysis are:
• System design;
• Bill of Materials;
• Refined safety envelope.
The purpose of the inductive analysis is to determine the base elements that will be used in the deduc-
tive analysis. There are potentially many failures at different levels of detail that could be used for the
base elements. Choosing the correct ones will prevent the deductive analysis proceeding further than is
needed and will also make the assignment of failure rates easier. An inductive analysis will therefore
produce:
• List of base elements;

• Failure modes of each base element;
• Confirmation of the Hazard List.
64
5.3.2 Process of inductive analysis
From the system design, and the Bill of Materials, decide the components that make up the system
design. For each component:
• Determine its possible failure modes;

– It is only necessary to consider those failure modes that can arise while the vehicle is
operating within the refined safety envelope.
• Determine the possible effect on the next component in the casual chain (see also Figure 4.2);
• Determine the possible causes of the failure modes;
• From the failure modes, effects and causes decide which components should be used as the
base elements in the deductive analysis.
Inductive reasoning may identify failures at the Vehicle Hazard Boundary that may suggest a new
hazard(s) that has not been identified during the PSA phase. In these circumstances the PSA has to be
revisited, this new failure at the Vehicle Hazard Boundary considered and, if appropriate, a new hazard
added to the Hazard List.
5.4 Deductive analysis
5.4.1 Introduction
The second principal stage of DSA is a deductive analysis although, in practice, inductive analysis and
deductive analysis need not necessarily be carried out sequentially, but can be performed in parallel
(note — the deductive analysis can not be completed without the results of the inductive analysis).
A common technique to use is Fault Tree Analysis (FTA) (See Appendix G).
The inputs to a deductive analysis are:
• System design;
• List of base elements;
• Component failure modes;
• Hazard List.
The purpose of this analysis is to determine the failure mechanisms that can lead to the Hazards.
Therefore the technique starts from a failure that causes the hazard, and works backwards, using some
form of logical representation, to determine all of its causes in terms of the failure modes (fault events)
of the base elements identified by the inductive analysis.
If fault trees are created for the derivation of safety requirements (see Section 5.2.2), it may be possible
to start with these, but they will inevitably need to be modified to take account of the detailed design
work that has been performed subsequently. Also, if a quantitative assessment of the random safety
integrity requirements criteria is being performed, the failure data used will be for the actual compo-
nents, as opposed to the more general figures used when deriving safety requirements.
The outputs of a deductive analysis are:
• Base element combinations that cause hazards.
65
5.4.2 Process of deductive analysis
For each hazard in the hazard list:
• Link the hazard to a failure mode of the system design, the top event;
• Link the top event through a series of intermediate events to failure modes of the
base elements.
Starting with the failure that causes the hazard in question, the analysis recursively identifies the chain
of cause and effect from failure mode to failure mode (see also Figure 4.2). Failure modes, or fault
events, may take the form of:
• A primary failure of the component to perform its intended function;

• The failure of the component to perform its intended function in the presence of certain
environmental effects;
• An error in the control or data signal to the component.
The analysis proceeds down to the level of the failure modes of the base elements identified by the
inductive analysis. If a quantitative evaluation is being performed, these base elements will require a
credible occurrence figure for each failure mode. For embedded automotive systems the failure modes
of the base elements are likely to include:
• Mechanical failures of actuators and sensors;

• Errors in data received over network buses;
• Mechanical and electrical failures of the electrical distribution system;
• Mechanical and electrical failures of the electrical hardware;
• Failures due to software behaviour.
The completed analysis shows the possible multiple causes of a hazard. The final step is to produce a list
of the combinations of base element failures that can lead to the hazard, or cut-sets in fault tree termi-
nology.
5.4.2.1 Handling software in deductive analysis
It is recommended that software failures are included in the analysis. This may be related to software
implementing the control algorithm, or software implementing a safety function, as this allows a fuller
understanding of what is required for a hazard to occur.
Since all design (hardware and software) is prone to error, it is not reasonable to assume that a sufficient-
ly rigorous process will result in there being zero failures due to systematic errors. Thus additional
design measures, such as error detection, watchdogs, redundancy etc. are used to increase confidence
that any remaining systematic errors will not lead to hazardous failures (these measures will also pro-
vide mitigation for random hardware failures). Use of deductive analysis techniques, e.g. qualitative
FTA, on the software design can help to understand fault propagation routes, and identify common-mode
faults which might undermine the independence of diagnostic functions.
66
5.4.3 Results of deductive analysis
• Combinations of base element failures for each hazard;

• Analysis showing the logic linking the combinations of base element failures to the hazard.
5.5 Results analysis
The primary objective of analysing the DSA results is to report on each hazard in the Hazard List, and
show how it has been mitigated in accordance with the safety integrity requirements and Safety Policy.
These reports will be included in the Safety Case.
The inputs to the process of analysing the DSA results are:
• System design validation records;

• Base elements combinations that cause hazards;
• Hazard List;
• Project Safety Plan;
• Safety Policy;
• Safety Argument;
• Refined safety envelope;
• Safety integrity level;
• Component failure modes.
Once the analysis of the DSA results is complete the outputs are:
• Summary of the results for the Safety Case (see Section 5.6);
• Additional (low-level) safety requirements.
5.5.1 Process of analysing the DSA results
The DSA results are checked to ensure that the Safety Policy requirements have been met for each haz-
ard with respect to:
• The safety functions (see Section 5.5.1.1);

• Random safety integrity requirements (see Sections 5.5.1.2 and 5.5.1.3);
• Systematic safety integrity requirements (see Section 5.5.1.4).
Assessing whether or not the design meets the random safety integrity requirements is done by evaluat-
ing the base element combinations. This can be done qualitatively or quantitatively depending on how
the random safety integrity requirements are expressed.
If it is discovered that some of the requirements have not been met then one or more of the following
tasks should be undertaken:
• Determine the additional low-level safety requirements that are necessary to meet the
requirements. All the changes will need to be fed back to the beginning of the DSA
process to validate the results.
67
• In the event that the DSA reveals that the design has introduced a new hazard that was not
identified during the PSA, it will be necessary to repeat (part of) that phase as well.
• Seek sign-off (see Section 4.5.4).
All the assumptions recorded whilst performing any of the DSA stages should be validated as soon as it
is possible to do so. Validation may take the form of:
• Performing tests;
• Obtaining confirmation in writing from an authoritative source regarding some attribute of
a component;
• Obtaining confirmation in writing from an authoritative source regarding some attribute of
the vehicle on which the system is to be deployed.
Formal records should be kept and referenced in the Safety Case as supporting evidence.
5.5.1.1 Safety functions
The system validation records are reviewed to ensure that all the safety functions identified in the design
documentation have been correctly implemented, and that the degree of hazard mitigation intended has
been achieved.
5.5.1.2 Random safety integrity requirements (quantitative assessment)
Each base element failure mode is assigned a failure rate, or probability of failure occurrence. The val-
ues used in the DSA should be specific to the components and their failure modes used in the actual
design rather than the generic data used when deriving the safety requirements. In many cases the data
will be provided by the component supplier(s). It is important to ensure that the value used is the one
for the particular failure mode used in the analysis, as a general figure that covers all possible failure
modes will normally be too pessimistic. It is also important to ensure that the values used have the same
dimensions, for example, probability of failure per hour (assumed to be constant over the life of the vehi-
cle), as the raw data provided by different suppliers may use different dimensions.
The possible sources for the failure rate data include:
• Field data of the same, or similar, component(s) already in use;

• Predicted value(s) based on FMEA;
• Standard reliability tables, e.g. [24].
The purpose of the analysis is to predict the probability of a system failure due to random hardware fail-
ures and, by definition, this excludes software causes, therefore a value of zero should be assigned to the
probability of a failure of the software implementing a safety function. That the software implementing
the safety function is suitably robust is argued using a different mechanism given by the systematic safe-
ty integrity requirements.
68
However, it can be useful to perform a sensitivity analysis, by entering non-zero probabilities for soft-
ware failure. This will indicate the contribution software failure can make to the probability that the haz-
ard will occur.
From the base elements combinations and the failure rates assigned to each base element, it is possible
to calculate the predicted failure rate of the system failure that results in the hazard being present. This
predicted value can be compared with the target value, using Table 4.9, and thereby determine if Risk
Class IV has been achieved.
It should be noted that the failure rate assigned to each base element assumes that it has been manufac-
tured correctly, and that each one in a batch are “identical”. Variations within, or between, batches are
the subject of quality control.
5.5.1.3 Random safety integrity requirements (qualitative assessment)
Qualitative assessment is applicable when the Safety Policy states requirements on the nature of failures
that can cause hazards, for example, “no single point failures shall cause a hazard requiring a SIL x safe-
ty function”, or “all hazards requiring a SIL x safety function shall have a software check on the main
state variable”. The combinations of base element failures that can cause each hazard can be checked
against the Safety Policy requirements, as follows:
• It is possible to determine if a hazard can only result from more than one fault event by
analysing the combinations of base element failures that lead to the failure that causes the
hazard in question. If a hazard can only result from more that one fault event, then a single
fault could occur without its effect being apparent until a further fault(s) occurs.
• If the error associated with the first fault is not detected by a safety function, then it is often
referred to as a latent fault and consideration should be given as to whether safety functions for
its detection and management are required. The Safety Policy may specify such a requirement.
• If the first fault is detected by a safety function, then it is often referred to as a dormant fault
and the safety functions for management should be reviewed to ensure that the correct actions
are taken.
If a base element failure is detectable by software then it may be possible to avoid the potential haz-
ardous consequences by changing the behaviour of the system. This approach may be used when the
random safety integrity requirements have not been met. However, since it is recommended that a value
of zero be assigned to the probability of a failure of the software implementing a safety function (see
Section 5.5.1.2 and Appendix G), if an argument is used that the addition of safety functions makes the
missed target acceptable, this should be documented as part of the Safety Case. Any such additions rep-
resent low-level safety requirements that need to be fed back to the beginning of the DSA process.
If the analysis shows that the software does not contribute to the hazard, or requires at least one other
fault to be present, then it may be possible to reason that the SIL value assigned to the safety function in
order to mitigate the hazard can be reduced. If this is not the case, then the original SIL assignment
stands.
69
5.5.1.4 Systematic safety integrity requirements
The safety integrity requirements for systematic failures are either design measures or process
requirements. These are taken from the standards or guidelines specified in the Safety Policy (see
Section 5.2.5).
• Design measures may include appropriate software and hardware architecture, internal error
detection and management, and a hardware watchdog (see IEC 61508 [4] for further advice).
Validation of these requirements may be achieved by review and/or test.
• Process requirements are validated by an audit of the development processes, and
conformance should be justified on the basis of evidence related to the particular
system under consideration.
Based on the above, it is possible to assess the extent to which the systematic safety integrity require-
ments have been met and then using Table 4.9 it is possible to determine if Risk Class IV has been
achieved.
5.6 Results summary
On the successful review of the results of the DSA activities it should be possible to state for each haz-
ard how all the Safety Policy requirements have been met, for example:
• Safety functions;
– List the diagnostics and responses, and reference the validation results records.
• Compliance with random safety integrity requirements;
• Compliance with systematic safety integrity requirements.
This information is a key input into the Safety Case.
70
6. References
6. References
[1] MISRA, Development Guidelines for Vehicle Based Software, MIRA, CV10 0TU, 1994,
ISBN 0-9524156-0-7.
[2] Kearney A T, Software Operated Vehicle Systems Define the Future of the Automobile, 2001.
[3] Def Stan 00-54, Requirements for Safety Related Electronic Hardware in Defence Equipment,
UK Ministry of Defence, 1999.
[4] IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related

Systems, International Electrotechnical Commission, 2005.
[5] Def Stan 00-56, Safety Management Requirements for Defence Systems — Issue 4, Ministry
of Defence, 2007.
[6] Hobley K M, et al., Framework for Prospective System Safety Analysis Volume 1 — Preliminary
Safety Analysis, Deliverable N° 9a, V2058 PASSPORT project of the Advanced Transport
Telematics (ATT/DRIVE II) sector of the TELEMATICS APPLICATIONS Programme,
Third Framework Programme (1991–94), 1995.
[7] Redmill F, Chudleigh M, and Catmur J, System Safety: HAZOP and Software HAZOP,
John Wiley & Sons Ltd, 1999, ISBN 0-471-98280-0.
[8] SAE J1739, Surface Vehicle Recommended Practice on Failure Mode and Effects Analysis,
Society of Automotive Engineers, 2002.
[9] VDA, Quality Management in the Automotive Industry, Quality Assurance before Series
Production: Volume 4 Part 2: System FMEA, Failure Mode and Effects Analysis,
Verband der Automobilindustrie e.V., 1996.
[10] International Council on Systems Engineering, July 2007, http://www.incose.org/
[11] Engineering Safety Management — Volumes 1 and 2, Fundamentals and Guidance (Issue 3),
Yellow Book 3, Railtrack, 2000. http://www.yellowbook-rail.org.uk
[12] Sampson F, Blackstone’s Police Manual — Road Traffic, Blackstone Press, 2001,
ISBN 1-84174-081-0.
[13] Kelly T P, Arguing Safety — A Systematic Approach to Managing Safety Cases, PhD Thesis,
University of York, 1998.
[14] Adelard, Adelard Safety Case Development Manual, 2004, http://www.adelard.com
71
6. References (continued)
[15] Regulation No. 13, “Uniform Provisions Concerning the Approval of Vehicles of Categories M,
N and O with Regard to Braking, Annex 18: “Special Requirements to be Applied to the Safety
Aspects of Complex Electronic Vehicle Control Systems”, Revision 5, United Nations Economic
Commission for Europe, 8 October 2004.
[16] Regulation No. 79, “Uniform Provisions Concerning the Approval of Vehicles with Regard to
Steering Equipment, Annex 6: “Special Requirements to be Applied to the Safety Aspects of
Complex Electronic Vehicle Control Systems”, Revision 2, United Nations Economic
Commission for Europe, 21 October 2005.
[17] IET, Safety, Competency and Commitment: Competency Guidelines for Safety-Related System
Practitioners, 1999, ISBN 0-85296-787-4.
[18] MISRA, Software Readiness for Production — Metrics for the tracking and reporting of
software development progress, MIRA, CV10 0TU, 2006, ISBN 0-9524156-8-2.
[19] Hobley K M and Jesty P H, “Analysis and Assessment of Advanced road Transport Telematic
Systems”, Proceedings of the 14th International Conference on Computer Safety, Reliability
and Security (SafeComp ‘95), Belgirate, Italy, G Rabe Ed., Springer-Verlag, 1995,
ISBN 3-540-19962-4.
[20] Ward D D, Rivett R S and Jesty P H, “A Generic Approach to Hazard Analysis for
Programmable Automotive Systems”, Society of Automotive Engineers World Congress, 2007,
Paper number 2007-01-1620.
[21] AIS 2005, Abbreviated Injury Scale Manual, Association for the Advancement of Automotive
Medicine, 2005.
[22] DO-178B/ED-12B, Software Considerations in Airborne Systems and Equipment Certification,

RTCA-EUROCAE, 1992.
[23] The Tolerability of Risk from Nuclear Power Stations, Health and Safety Executive, 1992,
ISBN 0-11-886368-1.
[24] Reliability Engineer’s Toolkit, The ROME Laboratory, US Airforce Material Command,
Griffiss Air Base, NY, 1993.
[25] IEC 61882, Hazard and Operability Studies (HAZOP Studies) — Application Guide,
International Electrotechnical Commission, 2001.
[26] MISRA Technical Report, The Use of Controllability for the Classification of Automotive
Hazards, MIRA Ltd, CV10 0TU, 2007.
72
6. References (continued)
[27] Evans R and Moffett J, “Derivation of Safety Targets for the Random Failure of Programmable
Vehicle Based Systems”, Proceedings of the 19th International Conference on Computer Safety,
Reliability and Security (SafeComp 2000), Rotterdam, The Netherlands, Koornneef F &
van der Meulen M Eds., Springer, 2000, ISBN 3-540-41186-0.
[28] Road Casualties Great Britain: 2004 Annual Report, Department for Transport, 2005,
ISBN 0-11-552703-6.
[29] Hayward M, Clarke N, Becker S, Nilsson L, Sala G, “The Analysis of User Needs for an
In-Vehicle Collision Warning and Avoidance System”, Proceedings of the 4th World Congress
on Intelligent Transport Systems, 1997.
[30] CASCADE, Generalised Assessment Method, Part 2: Guidelines, ESPRIT P9032, 1997.
[31] IEC 60812, Analysis Techniques for System Reliability — Procedure for Failure Mode and
Effects Analysis (FMEA), International Electrotechnical Commission, 2006.
[32] IEC 61025, Fault Tree Analysis (FTA), International Electrotechnical Commission, 2006.
73
Appendix A
Appendix A: Boundaries and hazard identification models

A.1 System and environmental model
Hazard identification is performed on a model of the system and its interactions with its environment.
The model recommended in this document consists of boundary elements, which are situated immedi-
ately inside the boundary of the system, and their interactions with defined elements in the environment,
which are represented as terminators. The system is referred to as the Target of Evaluation (TOE) and
the TOE may not in fact always be the same as the system (see Section A.3.1). The generic model is
shown in Figure A.1 and examples of boundary elements and terminators are given in Table A.1
Figure A.1: The boundary of the TOE
Terminator examples Boundary element examples

Non-vehicle mounted system, e.g. radio station Interface to system, e.g. aerial
Driver/passenger Human Machine Interface
Throttle body Throttle motor position; Throttle sensor
Table A.1: Boundary elements and terminators
The interactions between the boundary element and the terminator are via some form of inter-connec-
tion. Mechanical inter-connections pass forces, electrical interconnections pass signals, and program-
mable components may pass signals and/or messages (information). The attributes associated with an
interconnection include the “thing” that is being passed, the rate at which it is doing so, and its value,
accuracy and phase.
74
Appendix A (continued)
The system/environment model therefore consists of:
• A list of boundary elements for the TOE;

• A list of terminators in the environment;
• A description of the interconnections between the boundary elements and the terminators and
their relevant attributes.
TOEs associated with vehicles can be grouped into two categories, Open TOEs and Closed TOEs (see
Figure A.2).
Figure A.2: Different types of TOE
A.2 Open TOEs
Systems are modelled using an Open TOE, see Figure A.2(a), when the terminators, and their intercon-
nections with the system, are not well defined at the concept stage, for example, first design for adap-
tive cruise control with radar detection. These often fall more into the “blue sky” category of systems
and the input to the modelling task does not include a concept design.
75
The boundary elements of Open TOEs tend to be of three basic types:
• If the TOE is communicating with another system X, then the boundary element will normally
be an “Interface to X”, or its name;
• If the terminator is a person the boundary element will normally be the human machine
interface device;
• If the TOE is a control system then the boundary elements will normally include sensors and
actuators, unless they are being shared between systems (e.g. via a CAN bus) in which case
the boundary elements will be an “Interface to sensor/actuator”.
The recommended model for describing the internal operation of an Open TOE is known as the
PASSPORT Diagram [6], a very simplified version of which is shown in Figure A.3. Note that the model
only includes items that are situated within the Boundary of the TOE. The description of the terminators
will be included in the textual description of each boundary element that must accompany the diagram.
Note also that the “Data” is that which passes from the boundary element to/from the “Kernel of the
TOE”, and not the data that passes from the boundary element to/from the terminator, which may be
different in nature due to some transformation that may take place inside the boundary element.
Figure A.3: Simplified outline PASSPORT Diagram
A.3 Closed TOEs
Systems are modelled using a Closed TOE, see Figure A.2(b), when the terminators, and their intercon-
nections with the system, are well defined, e.g. traditional cruise control. Closed TOEs are more likely
to be appropriate if there is a well-established industry approach to the design of these systems and the
input to the modelling task includes a concept design.
A system modelled using a Closed TOE will typically consist of the following elements:
• E/E-system;
• Sensors and actuators;
• Networked I/O;
• Mechanical components that produce vehicle-level behaviour.
An example of a schematic of an air suspension system modelled using a Closed TOE is shown in
Figure A.4.
76
Figure A.4: Example air suspension system
A.3.1 Boundaries
Figure A.4 also shows a number of different boundaries. The potential for the other boundaries arises
because the organizational structure within a company, or the supply chain structure, often imposes a
zone of responsibility on those performing hazard analysis which does not allow the TOE boundary to
be coincident with the system boundary.
The definitions of these boundaries are:
• System boundary of the system of interest: This defines the scope of the “system of
interest” to the development team. This is unlikely to be an entire vehicle, but the automotive
industry does refer to its major vehicle units as “systems” rather than “sub-systems”.
The system includes all the components, irrespective of their technology.
• Boundary of the Target of Evaluation (TOE): This term can be used to define the scope of
the item being considered during a specific PSA. It will often be coincident with the system
boundary, but in some cases may only cover a sub-set of the system of interest, e.g. the team
developing the power train may wish to analyse the engine and gear box separately.
A TOE is unlikely to cross the system boundary.
77
• Zone of responsibility: This defines the scope of the authority held by the development team,
and relates to the degree to which they can control or influence changes in both their own
design, and in the design of other systems. This zone is likely to be defined according to the
business and organizational requirements of the company, e.g. by office, building, department
or country. Whilst it may be normal for the development team to have full responsibility for
their own system of interest, it is essential that the company has a mechanism in place
whereby, should the development team identify changes that are both necessary and outside
their own zone of responsibility, then it is possible for this information to be acted upon in a
proper manner.
Where these boundaries lie affects the content of the TOE/environment model which in turn affects the
hazard identification.
• Example 1
TOE: E/E-system, as shown in Figure A.4
Boundary element: Valve drive
Terminator: Solenoid valve
Interconnection: Duty ratio output
Interaction: Valve position
• Example 2
TOE: Zone of responsibility as shown in Figure A.4
Boundary element: Solenoid valve
Terminator: Mechanical valve
Interconnection: Valve position
Interaction: Air flow
• Example 3
TOE: System boundary as shown in Figure A.4
Boundary element: Air spring
Terminator: Vehicle body
Interconnection: Pressure in air spring
Interaction: Vehicle height
• Example 4
TOE: Vehicle body
Boundary element: Air spring
Terminator: Road
Interconnection: Road wheel
Interaction: Longitudinal and lateral forces
When used for the purpose of hazard identification (see Section 4.3), Example 3 may allow hazards
related to vehicle height to be determined and Example 4 may allow hazards related to vehicle yaw,
pitch and lean to be determined. If the zone of responsibility means that the TOE has to be similar to
Examples 1 and 2 then the analysis will only produce the potential causes of hazards. Relating these to
the vehicle hazards is discussed in Section 4.3.
78
It is obviously preferable to use examples similar to 3 and 4 if the zone of responsibility allows it and
there are no other overriding reasons.
A.3.2 Components
In its basic physical sense a system is built up from components. The level of detail at which one con-
siders a component will depend on the nature of the work and the type of the system, but it is wise to
choose a consistent level at each stage, for example, all Line Replaceable Units (LRU), or all electron-
ic components.
The attributes of a component include not only its physical properties, but also the function(s) that it per-
forms (for this reason it is sometimes called a functional element). Thus the failure modes associated
with a component can be physical, for example, short circuit; or functional, for example, brakes do not
act on the wheels.
The behaviour of a system, however, is usually more than just the sum of the behaviours of its compo-
nents. These emergent properties can only be obtained when the components are working together. One
consequence of this is that an analysis based on LRUs may not produce the same results as one based
solely on the electrical and mechanical components of which it is comprised. This is particularly true
when some of the components are programmable.
79
Appendix B
Appendix B: “What if?” analysis

For Open TOEs (see Section A.2), the PASSPORT method for PSA has been shown to be particularly
effective as a systematic way of identifying hazards at the concept phase of the design [6].
Hazard identification is undertaken using an adapted version of FMEA that is sometimes called
“What If?” analysis, or Functional FMEA. Each boundary element of the PASSPORT Diagram, and the
statements of its functionality, is considered in turn, and the possible vehicle hazards are considered
systematically (see Section 4.1.1), both for when the TOE is working normally, and when there is a
failure in the operation of the boundary element, or there is an error in the data being transferred from/to
it. Each interaction between the TOE boundary element and the terminator in the environment is
analysed to determine how that interaction could possibly be different from that intended, and then how
this could affect the behaviour of the terminator in the environment. For each boundary element a series
of “What If?” questions are constructed, and the answers are tabulated (see Table B.1); from each
answer to a “What If?” the resulting hazard is deduced and classified using the Risk Graph parameters
(see Section 4.4.4) and, if necessary, the Controllability parameters (see Appendix D).
“What if?” Resulting Controllability parameters A

Id S E R Comments
scenario hazard I A B T C
Table B.1: Example table for hazard identification and classification
The nature of an interaction can take many different forms, for example:
• Data flows;
• Energy flows;
• Mechanical movement;
• Vehicle forces.
The effects of unintended values of the different attributes of the interaction should be considered, for
example:
• Magnitude;
• Rate;
• Frequency;
• Timeliness.
80
Appendix B (continued)
Factors in the environment that may affect the interaction should also be considered, for example:
• Road surface, e.g. µ (mu), camber, inclination;

• Vehicle occupancy;
• Ambient lighting;
• Traffic density;
• Road type, urban, motorway, country, off-road, straight, with bends;
• Vehicle speed.
It may be helpful to consider possible errors in the inputs to the system, to the extent that these are known
at the time the analysis is performed, in order to gain an insight into possible unintended interactions at
the outputs. In addition, when analysing the interactions, a diagram of the form of Figure 4.1 may be
used as a checklist for the factors that should be considered. Combinations of interactions should also
be considered, and the rationale for those chosen and those that are not chosen should be documented.
The choice should ensure that the worst-case scenarios are considered.
81
Appendix C
Appendix C: Advice on performing HAZOP

An increasingly popular technique for hazard identification is Hazard and Operability studies (HAZOP),
adjusted where necessary, for the automotive setting. Whilst it does need a design, it can be used at any
level of detail, and is particularly effective for Closed TOEs (see Section A.3).
The most important concepts of HAZOP are:
• Entity: A label associated with an interconnection between components;

• Attribute: A property of an entity;
• Guide word: A word that describes a deviation from the design intent.
A HAZOP study involves the construction of HAZOP cases through the combination of entities, attrib-
utes and guide words in order to describe some deviation from design intent.
Each HAZOP case is then used to identify potential hazards, e.g.
What if [Entity] [Attribute] is [Guide word]?
In the automotive control system context:
• The entities for the analysis are associated with the inputs and outputs of the TOE;
• The choice of attributes is derived from behaviour at the electro-mechanical boundary;
• An application specific set of guide words has been defined, based on the generalized list
shown in Table C.1.
Generic properties Timing

No Early
More Late
Less Before
As well as After
Part of
Reverse
Other than
Table C.1: Generalized list of HAZOP guide words
A common problem when performing a HAZOP study has been the choice of attributes. An output from
a controller can be considered from many perspectives e.g. voltage/current levels, frequency, output
state, position of an actuator, etc. Experience has shown that the best attributes to choose are those asso-
ciated with the behaviour of components being controlled on the electro-mechanical interface.
For example, Figure C.1 depicts an embedded controller that maintains the vehicle ride height by con-
trolling an air suspension system. It has one output signal that controls a pneumatic valve, and one input
82
Appendix C (continued)
signal that is used to provide vehicle height feedback from a height sensor. The interconnection between
the controller and the valve, i.e. the valve command signal, becomes an entity for the HAZOP study. In
this example, a good choice of attribute would be valve position, since it is associated with a component
on the electro-mechanical boundary (air spring). It is then necessary to choose a set of guide words that
are meaningful in the context of this system. One possible choice would be the guide word “More”
(implying “maximum”); thus, for example, the HAZOP case would become:
What if [VALVE COMMAND SIGNAL] [VALVE POSITION] is [MORE]?
Figure C.1: Example air suspension system
This “entity, attribute, guide word” combination describes some deviation from the design intent; how-
ever, it does not yet have a defined meaning in the context of this system due to the generic nature of the
guide words. It is therefore necessary to assign a meaning to this question. A possible interpretation of
its meaning is that the valve has been commanded to become fully open. The effects of this behaviour
would then be determined and then, using an inductive technique, followed through to the relevant haz-
ards. This would be achieved using the combined knowledge and experience of a carefully selected
group of engineers.
For a detailed explanation of HAZOP, refer to [7] or [25].
83
Appendix D
Appendix D: Controllability
D.1 Introduction
The term “controllability” refers to the ability of the driver, another vehicle occupant, or another person
interacting with the system (such as a traffic control room operator) to control the safety of the situation
following a failure. This approach recognizes that in road transport scenarios, whilst a failure in a sys-
tem produces a hazard, it does not necessarily lead to a hazardous event (an accident). Indeed whether
or not an accident will occur will depend as much on the road and traffic conditions at the time, as on
the failure itself, probably more so. Taking the worst-case scenario is not much help either, because it
is usually possible to dream up a situation where even what would normally be considered to be a “mild”
hazard could produce the worst possible conceivable hazardous event. The technique for assessing
Controllability:
• Is independent of traffic, weather and lighting conditions, and thus applicable on any road in
any country;
• Is independent of the type of accident that may result from the hazard, including none;
• Can take into account the possible reactions of the vehicle occupants to the occurrence of the
hazard, including the fact that they may make mistakes;
• Is independent of the number of units deployed so that, say, a high volume vehicle
manufacturer or Tier 1 supplier would have the same risk assessment for the same system
in the same application, as a low volume manufacturer or supplier.
Controllability provides a qualitative assessment of the:
Controllability of the safety of the situation in a hazardous situation
The technique recognizes the fact that between the occurrence of a hazard and a possible accident, whilst
there is a loss of some control, the vehicle occupant(s) may be able to mitigate the risk. This chain of
events may be represented diagrammatically as shown in Figure D.1. It has been validated by a project
that compared the effect on drivers of system failures in a driving simulator, and the “paper based”
approach described below [26].
Figure D.1: How some control may be lost
The intuitive relationship between the loss of control and the mitigation effort required to maintain the
safety of the situation is shown in Figure D.2. This also shows the mitigation effort which it is reason-
able to assume that the average driver can achieve, and captures the intuition that the mitigation effort
to maintain the safety of the situation increases in a non-linear manner from zero, for no loss of control,
84
Appendix D (continued)
to a high value as more control is lost. Figure D.2 also shows that it can be reasonably expected that the
driver will provide the increasing mitigation effort up to a certain point but after that an accident is
inevitable.
Figure D.2: Model of mitigation effort and Controllability
Hazards are classified by allocating them to one of five Controllability classifications, which are defined
in Table D.1, and which map onto the model of mitigation effort as shown in Figure D.2. The
Controllability value C0 is available to aid the process of assigning values to hazards by providing a clas-
sification that spans all the way from “fully controllable” to “extremely uncontrollable”. However, once
a hazard has been classified with a Controllability of C0, it can be removed from the Hazard List.
Controllability Definition
This relates to hazardous situations where avoidance of an accident (hazardous
C0 event) is expected, safety is not normally affected, and customer satisfaction is
the main consideration.
This relates to hazardous situations that produce operational limitations, but
C1 avoidance of an accident (hazardous event) is normally possible with a normal
human response.
This relates to hazardous situations where there is a reduction in the safety mar-
C2 gin, and whilst avoidance of an accident (hazardous event) is difficult, it is usu-
ally possible with a sensible human response.
This relates to hazardous situations that are not normally controllable, and
avoidance of an accident (hazardous event) is very difficult. However, under
C3
favourable circumstances, some control can be maintained by an experienced
human response.
This relates to hazardous situations that are not controllable, and the outcome
C4
cannot be influenced by a human response.
Table D.1: Definition of the Controllability classifications
85
D.2 Controllability parameters
The original Development Guidelines for Vehicle Based Software [1] identified four parameters that
influence the Controllability of a hazard:
(a) Level of system inter-dependency;

(b) Loss of authority or control due to the hazard;
(c) Provision of backup or mitigation;
(d) Reaction time.
The first two parameters are concerned with the importance of the system of interest (see Appendix A),
and the amount of authority or influence that it has to affect, or maintain, the safety of the situation. The
second two parameters are concerned with what the vehicle occupants(s), normally the driver, can do to
maintain control of the safety of the situation in the presence of the hazard.
D.2.1 Level of system inter-dependency
Level of system inter-dependency is concerned with system integration. It relates to the degree to which
other systems are relying on the correct functioning of this system for their own correct functioning, e.g.
when this system provides data for use by systems in this, or other vehicles. It should be a functional
dependency, not just the existence of a communications link (which is a design issue that will be assessed
later during Detailed Safety Analysis). It should be noted that:
• The concern here is not whether this system is part of a tightly integrated application, which
would warrant a safety analysis in its own right, but whether this system is providing data
for other, and distinct, systems that will modify their functionality according to the value
of that data.
• Note that the system receiving the data may be in another vehicle, or at the roadside.
D.2.2 Control of the safety of the situation
The next two parameters are concerned with the amount of control that the road users, or vehicle occu-
pants, have to maintain a safe (traffic) situation (see Figure D.3). Normal control is maintained by driv-
ers using a number of different systems, both within the vehicle and at the roadside. Examples of such
systems include engine management systems, braking systems, electronic stability control, automatic
incident detection systems and information/command systems that use variable message signs. Drivers
use each one, to some degree, to build up their total control of the safety of the traffic situation. When
a hazard occurs as a result of a fault in the System of Interest, the driver loses some control over the safe-
ty of the situation.
86
Figure D.3: How control is built up
D.2.2.1 Loss of authority or control due to the hazard
The second parameter, loss of authority or control due to the hazard, relates to functionality that is inside
the system boundary of the System of Interest. Each hazard will reduce the authority of this system
and/or the control of the vehicle occupants, to maintain a safe (traffic) situation. It should be noted that:
• It is not possible to lose more control than that provided by the functionality from inside
the system.
• The concern is for the physical well being of the vehicle occupants (normally), and all drivers
are expected to be able to maintain a safe situation for their own vehicle, and for others, at all
levels of congestion. Thus a system that provides indirect advice or command (to one or more
drivers), for example, a variable message road sign, must be assessed in terms of the degree to
which the hazard can modify that basic safe situation, e.g. through distraction (which might
affect the driver’s ability to apply the functions outside the system boundary properly).
• A system that provides advice, or even a command, to the driver will have little direct control
unless that driver has an instinctive reaction to it (e.g. at traffic signals).
D.2.2.2 Provision of backup or mitigation
The third parameter, provision of backup or mitigation, relates to any other functions that are available
from outside the system boundary of the System of Interest that are being, or may be, used to control the
safety of the (traffic) situation. Note that:
• This does not refer to a multi-channel implementation of the function that has failed (this is a
design issue and will be one way of achieving the required safety integrity level).
• A system that provides incorrect advice, or commands, to the driver, other than a system failure
warning, will have no effect on the vehicle functions available to that driver.
• See also Section D.2.3.1.
87
D.2.3 Reaction time
The final parameter, reaction time, refers to the speed with which the vehicle occupant(s), normally the
driver, must be able to apply the backup functions from outside the system boundary in order that they
will succeed in creating a safe state. Note that:
• Once the hazard under consideration exists the vehicle occupant, or the driver, has to:
– Recognize that a change of circumstances has occurred (the exact failure mode is unlikely
be diagnosed, only its effect);
– Work out what can be done to maintain the safety of the situation;
– Apply the corrective actions.
• There is therefore a window of opportunity available that may, or may only with difficulty,
or may not, be sufficient to maintain the safety of the situation.
D.2.3.1 The human in the loop
“Reaction time” and, to a certain extent, “Provision of backup or mitigation” are both dependent on the
ability of the driver, or another vehicle occupant, to understand what can be done, perform the task
correctly, and with sufficient speed. Whilst it is obvious that people will vary in their abilities, and with
age, there are some assumptions that can be made; and for the purpose of this analysis it can be assumed
that:
• Drivers have passed the relevant test, and are capable of controlling their respective vehicles
in traffic;
• Other road users are obeying the basic rules and regulations that apply to them;
• Control room operators have been trained properly.
However, road users are not expected to be super-human, and this is emphasized in the wording of the
Controllability classifications in Table D.1.
It can also be assumed that vehicles are being driven with due care and attention, with reasonable con-
sideration for other road users, and are not being driven dangerously, i.e. that drivers are behaving in a
manner that conforms to accepted and normal driving practice and standards. “Driven with due care and
attention” is the standard of driving that would be expected of a reasonable, prudent and competent driv-
er in all the attendant circumstance, e.g. road layout and geometry, other traffic and road users, weather
conditions, and visibility [12]. Hazardous situations that occur as a result of vehicles being driven dan-
gerously or without “due care and attention” are therefore considered to be outside the “safe driving
envelope” and should be recorded as such during the hazard analysis process.
Consideration does, however, have to be taken of normal driving styles, even though they may not
always conform precisely to the recommended safe approaches. In particular:
88
• Inter-vehicle gap: Whilst the normal recommended headway between vehicles is 2 seconds,
most drivers maintain a gap of around a second. This therefore reduces the time that they have
available to avoid a collision. It should be noted that a driver’s reaction time to any sudden
unexpected abnormal situation may well exceed this freely chosen headway separation, and
that as a result an accident situation may be caused.
• Risk compensation: A number of vehicle systems are being introduced with the objective of
helping a vehicle to maintain a safe passage in situations where an accident might otherwise
occur. However, these systems only provide that additional margin of safety if the vehicle is
being driven as if it did not contain them. Many drivers change their driving style when their
vehicles have these systems knowing that their normal margin of safety has been increased. In
these situations any additional margin of safety can be substantially reduced. An example is
seen with ABS. ABS is intended to help the driver maintain steering control during heavy
braking by reducing wheel lock-up and therefore the probability of skidding. Many drivers,
however, drive their ABS-equipped vehicles as if ABS is capable of reducing the safe headway
that it is necessary for them to maintain to the preceding vehicle.
• De-skilling: When a novel system is introduced onto a vehicle, it is sometimes argued that
the drivers can revert to what they did before having that system in the event of a failure.
Unfortunately this argument is only valid for a short period of time. The existence of the novel
system will mean that drivers will no longer have to practice that particular skill, and this will
soon result in their loss of that skill. In addition, new drivers may not have even been taught
that skill.
It is therefore necessary to take into account some human failings, whilst at the same time assuming that
people do know how to behave properly even if they do not always do so.
D.3 Controllability classification
The four Controllability parameters can be assessed using the following scheme. Other schemes are pos-
sible, e.g. practical experiments, simulations, but they must be systematic and rigorous.
Initially the parameters are considered separately and a grade from A (worst case, high value) to E (best
case, low value) is assigned to each one. Once grades for the four parameters have been obtained, then
the final consolidated grade is considered. Whilst a single low value (towards E) might be ignored, it is
unwise to ignore a single high value because that will be pointing out a particular characteristic of the
hazard. Note that a simple average of the grades is not taken since the grades do not have the same
dimensions; they actually define a point in the four-dimensional space of the parameters. Once a possi-
ble final grade has been chosen, the full definition of the corresponding Controllability classification
(Grade A implies “C4”, Grade B implies “C3” etc.) is studied to confirm that it does indeed reflect the
controllability of the safety of the situation that results from the hazard under consideration. The
Controllability classification for each hazard should be chosen carefully and reasonably, since the high-
est Controllability classification will normally be used to help define the MISRA Risk Level of the sys-
tem.
It should be noted that this technique is qualitative, and thus needs experience and judgement to be
gained before consistent results will be obtained.
89
Level of system inter-dependency
The grades for this parameter are ranked as follows:
A. Full functional inter-dependency

B.
C. Partial functional dependency
D.
E. Autonomous system or function
Loss of authority or control due to the hazard
A. Full authority/control lost

B.
C. Partial authority/control lost
D.
E. No effect
Note that, with reference to Figure D.3, Grade E refers to a region at or near 0% and Grade A refers to
a region at or near 100%.
Provision of backup or mitigation
A. No other functions available

B.
C. Other functions available, but with reduced functionality or safe state
D.
E. Full redundancy or diversity, or functions not affected
Note that:
• In the case of a system failure, “full redundancy or diversity” refers to other systems that
can provide the same function, but by other means; it does not refer to a multi-channel
implementation of the function that has failed (this is a design issue and will be one way
of achieving the required safety integrity level).
90
Reaction time
A. Much faster than humanly possible

B.
C. Similar to human
D.
E. Similar to normal traffic situation
Note that:
• “Similar to normal traffic situation” in this context refers to the speed of reaction necessary to
maintain normal safe traffic conditions, i.e. the driver does not have to perform any extra or
different tasks to maintain the safety of the situation.
• “Similar to human” refers to a speed of reaction necessary in an emergency situation, but with
in the capabilities of most drivers. This is a scenario where drivers have to perform one or
more tasks that they did not expect to have to do until the hazard under consideration occurred.
• “Much faster than humanly possible” refers to scenarios, such as platooning, in which vehicles
are legitimately not under the immediate control of their drivers.
91
Appendix E
Appendix E: Quantitative acceptable hazard occurrences

E.1 Definition of broadly acceptable risk
This definition of broadly acceptable risk (see also [27]) is based on the risk to an individual person
rather than the cumulative risk associated with the complete fleet of manufactured vehicles, since it is
not possible to predict how many vehicles (containing the system of interest) will eventually be produced
by a manufacturer, or how many of those systems will be produced by a supplier.
The broadly acceptable probability of fatality is given as a probability interval bounded by an upper and
lower value. The values are derived from a consideration of the risk associated with accidents. The
lower value is taken from work published by the UK Health and Safety Executive (HSE) while the upper
value comes from the Minimum Endogenous Mortality (MEM) criterion.
The results are based on the assumption that the risk to an individual, which could be considered to be
broadly acceptable (given the many benefits associated with transport) is 10-6 < P(Fatality) < 10-5 per
person-year. This assumption is based on the following data (see also [27] with updates from [28]):
• Whilst not used directly in the derivation of broadly acceptable risk, a relevant benchmark is
that the average risk associated with road traffic accidents in the UK is approximately 10-4
fatalities per person-year [28].
• It is generally accepted that the majority of these deaths are attributable to human error rather
than to technological failure (> 90%) [29].
• A basic safety requirement in some industries is related to the MEM criterion. This sets the
upper limit of risk to an individual (through technological causes) to 10-5 fatalities per
person-year [30].
• The HSE have set the upper limit for broadly acceptable risk to an individual (given an
associated benefit) at 10-6 fatalities per person-year [23].
E.2 Derivation of target system safety requirements
For most vehicle systems the severity of the consequence of a hazard is inherent in the nature of those
systems, and therefore risk can usually only be reduced by lowering the probability or frequency of
occurrence; though it may be possible to provide some mitigation with, for example, air bags.
As described in Section E.1, the definition of broadly acceptable risk is expressed with respect to acci-
dents and in terms of the acceptable probability of fatality per person-year. However, in order to estab-
lish appropriate safety requirements for a particular vehicle or vehicle system it is necessary to deter-
mine the limit on the allowable frequency of occurrence of hazards. This limit on hazard frequency must
be determined based on the definition of broadly acceptable risk associated with accidents. The MISRA
approach is to associate a limit on allowable hazard frequency with each of the five MISRA Risk Levels,
R1 to R5 (see Section 4.4.3), such that the resultant risk in terms of accidents due to vehicle, or vehicle
system, operation is broadly acceptable.
92
Appendix E (continued)
The remainder of this appendix describes the derivation of safety requirements in terms of hazard fre-
quency used by MISRA.
Taking the case where the outcome of an accident is a fatality, Figure D.1 can be extended as shown in
Figure E.1, where:
• P(A|H) is the probability of an accident, given that a hazard has occurred. It is the combined
effect of the Risk Graph parameters E and V (see Section 4.4.3).
• P(F|A) is the probability of a fatality, given that an accident has occurred.
Figure E.1: How a fatality may occur
The expression for risk of a fatality can therefore be stated as:
q(S, (h x P(A|H) x P(F|A)) ≤ (Broadly Acceptable Risk of a Fatality)
The MISRA Risk Graph evaluates a component of the above expression (see Section 4.4.3), i.e.:
R = g(S, P(A|H))
If R is substituted into the expression for risk we get:
q 1 (R, (h x P(F|A)) ≤ (Broadly Acceptable Risk of a Fatality)
At this point it is relevant to note that, whilst in general there are differing degrees of severity associat-
ed with accidents, the basis for reasoning about risk used in this appendix is that of fatalities. In order to
accommodate the classification of hazards whose outcomes have differing upper limits on severity, the
MISRA Risk Graph has been designed on the basis of the risk associated with a single fatality and then
normalizes other severities to this level through the use of the Severity parameter (S).
Therefore, given the above, the expression for risk becomes:
(Broadly Acceptable Risk of a Fatality) ≥ R x h x P(F|A) fatalities per person-year
In order to evaluate the acceptable rate at which hazards may occur (i.e. the value for h) we re-arrange
the previous equation which gives:
(Broadly Acceptable Risk of a Fatality)

h≤ per year
R x P(F|A)
93
Appendix E (continued)
The MISRA Risk Graph recognizes 5 different discrete levels of risk R1 – R5, therefore there are 5
different corresponding values of h, h1 – h5 respectively. Therefore, the risk inequality becomes:
(Broadly Acceptable Risk of a Fatality)

h 1-5 ≤ per year
R 1-5 x P(F|A)
Before this inequality is used to evaluate h1–h5 the following information is needed:
• The desired units of h is events per hour. To convert the expression for h from units of years to
units of hours we approximate the number of hours in a year as 104. Hence the expression for h
will be divided by 104.
• The value for broadly acceptable risk has been determined in Section E.1 as
10-6 < P(Fatality) < 10-5 per person-year.
• The value of P(F|A), i.e. the probability of a fatality given an accident, has been determined
through a study of UK Road Accident data [28] and has the value of 10-3.
• The maximum Risk Level for a single vehicle is assumed to be R4. Since the upper limit on the
number of fatalities that could reasonably be expected to result from an accident due to a system
in a single vehicle is close to unity, R4 is given the value “1” with the values for the other Risk
Levels varying by orders of magnitude, i.e. R1 = 0.001, R2 = 0.01, R3 = 0.1 and R5 = 10.
• It is assumed that there is a contribution from no more than 10 relevant7 vehicle based systems
on a vehicle, and therefore the system safety target is a factor of 10 lower than that of the hazard
probability for the vehicle as a whole. Hence the expression for h is divided by 10 such that it
can be applied to individual vehicle systems.
The above information, in conjunction with the expression for h, results in the figures shown in
Table E.1. These indicate the acceptable probability of hazard occurrence for each of the five MISRA
Risk Levels, R1 to R5.
h — Acceptable hazard occurrence

MISRA Risk Level
frequency per hour
R1 10-5 ≤ P(Hazard) < 10-4
R2 10-6 ≤ P(Hazard) < 10-5
R3 10-7 ≤ P(Hazard) < 10-6
R4 10-8 ≤ P(Hazard) < 10-7
R5 10-9 ≤ P(Hazard) < 10-8
Table E.1: Acceptable probability of occurrence for each MISRA Risk Level.
7 i.e. systems that are subject to the requirements of these Guidelines.
94
Appendix F
Appendix F: Advice on performing FMEA

As Failure Mode and Effects Analysis (FMEA) was originally conceived, a system must first be decom-
posed into its lowest level component parts. For each component part a list must then be compiled of
the possible ways in which it may fail to perform as intended (i.e. the “failure modes”). Finally, for each
failure mode, the effects on the system are deduced and documented. The documentation of the FMEA
is carried out on a standardized form, which is usually implemented in a spreadsheet or word processor
tabular format.
It should be noted that FMEA is best performed as a team activity, and should be used iteratively, though
it is acknowledged that both of these pieces of advice are often ignored. The most frequent and signif-
icant criticisms of FMEA as a process are that it is usually done too late, and often by people who are
outside the core design team.
FMEA can be applied at many different levels in the hierarchy of a vehicle. Figure F.1, which is one
way of decomposing a vehicle, shows that a number of different levels exist at which it may be sensible
to undertake an FMEA. However, as shown in Figure 4.1, the only level at which the end effects pro-
duce hazards is at the vehicle boundary. It is therefore necessary to maintain traceability between the
fault, or failure mode, and the final hazard through the “intermediate effects” at each level.
Figure F.1: Decomposition of a vehicle
95
Appendix F (continued)
FMEA as described in SAE J1739 [8] is actually a form of Failure Mode, Effects and Criticality Analysis
(FMECA). When FMECA is used, each failure and its effect are scored, for Severity, Probability of
Occurrence, and Ease of Detection; these factors are traditionally multiplied to create a Risk Priority
Number (RPN). In the automotive industry, these three factors are subjective, and the RPN derived from
them is often used only to determine which failures should receive attention. In practice, the RPN should
be used with great care, since it is a one-dimensional assessment of three dimensions of information, i.e.
information is lost during its creation. Of particular concern is the case where only one of the parame-
ters has a high value; this may result in a low RPN but be highlighting a specific major problem. It is
for this reason that some companies are now only using the “severity” parameter.
If the FMEA/FMECA suggests that a failure mode may lead to a Hazard already in the Hazard List, but
the analysis so far has not identified that failure as being related to that particular Hazard, then the fail-
ure mode should be taken into account in the probability analysis, as it is likely to increase the
Probability of Occurrence for the Hazard. Consideration should also be given to revisiting the “What
Causes?” part of the PSA.
For a detailed explanation of FMEA, refer to [31] or [8].
96
Appendix G
Appendix G: Advice on performing FTA

Fault Tree Analysis (FTA) is a Boolean “Backward Logic” model of the results of component failures in
a system, that allows the practitioner to deduce the manner in which single events related to component
failure combine and lead to system-level effects.
The system level hazards must first be deduced from a PSA; then each failure that causes the hazard in
question forms the top event for each Fault Tree. The tree is then developed downwards, with the imme-
diate causes (fault events) for each level being recorded at the next level down, until the tree cannot use-
fully be further developed. The lowest fault events that lead to the top event are then the base events,
many of which often correspond to the component failure effects derived in the FMEA. The FTA tree
consists of Boolean logic symbols connected together to represent the causal relationships that lead from
the base events to the top events. The trees should be refined using Boolean Algebra, so that the “min-
imal cut sets”, i.e. the base events that can lead directly, or the simplest combinations of events that can
lead, to the top event are identified. Any single point failures apparent in the minimal cut sets should be
consistent with the FMEA, and the results of the latter should be checked to see if it is indeed consistent
with the FTA in this respect.
Consider a hazard “Engine Fire”: if an FMEA is carried out on the engine management system, two sin-
gle point events may be identified:
• Ignition over-advanced;
• Engine over-fuelled.
Neither single point failure can directly, and alone, lead to an engine fire. However, use of FTA should
show that the hazard could result if the conditions “excess fuel in the inlet manifold”, “inlet valve open”,
and “spark plug activated” coincide. The value of FTA is principally that it brings to the attention of its
practitioners the combinations of events, possibly individually innocuous, that lead to the top events.
This is of great importance and potential value early in the design cycle, in aiding the designer to avoid
undesirable failure scenarios. Thus FTA can be used to explore the effects of different designs.
FTAs can also be used to identify actual common-cause failures, and to confirm or deny any assump-
tions of common-cause failure, particularly those related to the independence of functions.
Complex products such as road vehicles usually require detailed diagnostic and servicing instructions.
With programmable systems, and with some mechanical systems, diagnostics have often taken the form
of flowcharts, or some form of cause-effect tables. FTA is a valuable aid to developing a diagnostic and
servicing strategies, since it provides a detailed view of each cause-effect path.
FTA is also the primary technique for quantifying the probability of the hazards, based on reliability met-
rics for the individual components or LRUs, and determining the critical factor(s) that lead to a specific
reliability figure. Reliability tools that incorporate FTA are commercially available, as well as stand-
alone FTA tools.
97
Appendix G (continued)
Where the failure of software is believed to contribute to a base event, the question arises as to how to
take account of the probability of a software failure in the calculation of the top event’s probability of
occurrence. Since the purpose of the analysis is to predict the probability that the hazard will occur due
to random hardware failures and, by definition, this excludes software causes, a value of zero should nor-
mally be assigned to the probability of a failure of the software implementing a safety function. That
the software implementing the safety function is suitably robust is argued using a different mechanism
given by the systematic failure requirements.
Alternative approaches are also possible, but since this is a subject of active research, no particular tech-
nique will be recommended here. In addition, it should be noted that FTA can also be used to analyse
the software itself, e.g. to identify critical sections, and hence provide a guide for adding defensive pro-
gramming.
Despite the “problem” with software, quantified fault trees can still be very useful in gaining an under-
standing of the failure mechanisms within a vehicle system. For example, even though the absolute
validity of the calculated occurrence rates of the top event may be questionable, the tree can be used to
test assumptions and to perform sensitivity analysis on the effects of the uncertain component failure
rates on the system failure rates. It may also be possible, accepting the pessimistic outcomes, to see how
close a particular system design gets to the target figures in IEC 61508 [4], for example when choosing
between different vehicle system architectures.
For a detailed explanation of FTA, refer to [32].
98

Guidelines For Safety Analysis of Vehicle Based Programmable Systems

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

Guidelines For Safety Analysis of Vehicle Based Programmable Systems

Uploaded by

Copyright:

Available Formats

The Motor Industry Software Reliability Association

Licensed to: Lear Corporation

© MIRA Limited, 2007.

ISBN 978-0-9524156-5-7 (paperback)

British Library Cataloguing in Publication Data.

Licensed to: Lear Corporation

Richard Evans Jaguar Cars

Henrik Aidnell Jan Jacobson Steve Minns

3. Overview of the MISRA Safety Process 15

4. Preliminary safety analysis 31

5. Detailed safety analysis 61

Appendix A: Boundaries and hazard identification models 74

Appendix B: “What if?” analysis 80

Appendix C: Advice on performing HAZOP 82

Appendix E: Quantitative acceptable hazard occurrences 92

Appendix F: Advice on performing FMEA 95

Appendix G: Advice on performing FTA 97

ABS anti-lock braking system

ALARP as low as reasonably practicable

ASIC application specific integrated circuit

DSA detailed safety analysis

E/E electrical and/or electronic

ECU electronic control unit

ETA event tree analysis

EUC equipment under control

FMEA failure mode and effects analysis

FMECA failure mode, effects and criticality analysis

FTA fault tree analysis

HAZOP hazard and operability study

HMI human-machine interaction/interface

HSE Health and Safety Executive (UK)

IEC International Electrotechnical Commission

LRU line replaceable unit

MAIS maximum abbreviated injury severity

MEM minimum endogenous mortality

MISRA Motor Industry Software Reliability Association

MoD Ministry of Defence (UK)

PASSPORT Promotion and Assessment of System Safety and Procurement of Operable

PSA preliminary safety analysis

RPN risk priority number

SIL safety integrity level

SRfP software readiness for production

TOE target of evaluation

Words in italics in the definitions are also defined in this table.

Error Discrepancy between a computed, observed or measured value or

Failure Termination of the ability of a functional unit to perform a

Failure Mode The effect by which a failure is observed in a system component.

Harm Physical injury or damage to the health of people either directly, or

Hazard Potential source of harm.

Hazard Analysis The process of analysing a concept or design to identify hazards.

Hazardous Situation Circumstance in which a person is exposed to hazard(s).

Hazard Log See Hazard List

Impact Analysis Activity of determining the effect that a change to a function or

Mistake See Human Error

Quality The degree to which a set of inherent characteristics fulfils

Risk Combination of the frequency, or probability, of occurrence of harm and

Safety Freedom from unacceptable risk (see broadly acceptable risk).

Safety Argument The logical structure of a safety case.

Safety Case A formal presentation of evidence, arguments and assumptions aimed at

Safety Functions Functions to be implemented by a safety-related system, which are

Safety Integrity The degree of confidence in a safety-related system satisfactorily

Safety Plan A formal statement of the specific actions, resources, roles,

Safety Policy A formal statement of a company’s or organization’s strategy for