1. MISRA Safety Case
Guidelines
Why we are writing these guidelines.....
Helen Monkhouse
Global Product Safety Manager, Protean Electric Ltd.
MISRA Steering Committee Member

2. Agenda
Introduction to MISRA
Safety Cases
- What is it?
- What constitutes a good one?
MISRA Safety Case Guidelines
February 17, 20142

3. Introduction to MISRA
February 17, 20143
The original MISRA project started in 1990.
That project was part of the UK Government‟s “SafeIT” programme, but is now
self supporting.
The MISRA Safety Case Working Group began its work in 2011
The Safety Case Working Group partners are:

4. Introduction to MISRA
MISRA aims to
 Promote best practice in automotive safety-related systems engineering
 Develop guidance in specific technical areas e.g.
• C language
• Software readiness for production
• Safety analysis
MISRA does not
 Run certification schemes
 Promote or endorse specific products
February 17, 20144

5. The Safety Case Argument
February 17, 20145
A safety case should communicate a clear, comprehensive and defensible argument that a
system is acceptably safe to operate in a particular context.
Tim Kelly, University of York
“clear, comprehensive and defensible”
“complete and satisfied”
- Calls for an explicit safety argument:
o An argument without evidence is unfounded
o Evidence without an argument is unexplained
A safety case should communicate a clear, comprehensive and defensible argument that a
system is acceptably safe to operate in a particular context.
Tim Kelly, University of York
Argument that the safety requirements for an Item are complete and satisfied by evidence
complied from work products of the safety activities during development.
ISO 26262:2011
Argument that the safety requirements for an Item are complete and satisfied by evidence
complied from work products of the safety activities during development.
ISO 26262:2011

6. ISO 26262 Requirements
ISO 26262 Part 2 clause 6.4.6 includes the following safety case related
requirements:
- This requirement shall be complied with for items that have at least one
safety goal with an ASIL (A), B, C or D: a safety case shall be developed
in accordance with the safety plan.
- The safety case should progressively compile the work products that are
generated during the safety lifecycle.
February 17, 20146
Does our compilation of ISO 26262 work products lead
to an explicit safety case argument?

7. The ISO 26262 Safety Case Argument
February 17, 20147
Hazard Analysis &
Risk Assessment
all hazards have
been identified
Safety Goals
Functional Safety
Concept
Technical
Safety Concept
Integration Testing
Reports
The system is safe because......
defined safety
goals mitigate all
hazardous events
the functional
safety req‟t deliver
the safety goals
the technical
safety req‟t deliver
the safety concept
The safety req‟t
implementation is
verified
ISO 26262 work products
This is the safety argument that
is implicit within ISO 26262
Asking “but why” at each stage identifies the explicit safety
argument

8. An Example Explicit Safety Argument
February 17, 20148
Accelerator
Pedal
Driver Controller
High Voltage
Battery
Electric
Machine
Transmission
Vehicle
Wheel
Vehicle
Wheel
Item Boundary
CAN Communication
Low Voltage Electrical Power
High Voltage Electrical Power
Mechanical Force / Torque / Power
High Voltage
Power
Inverter

9. ISO 26262 Work Products
February 17, 20149
Hazard Analysis &
Risk Assessment
Safety Goals
Technical
Safety Concept
Integration Testing
Reports
Hazardous Event: Unintended vehicle acceleration during a low speed
manoeuvre amongst pedestrians
Exposure E3
Severity S2 ASIL B
Controllability C3
Safety Goal: Vehicle positive longitudinal acceleration shall not exceed
driver demand by > 1.5 m/s2 for longer than 1 s
Functional Safety Concept:
Functional safety requirements relating to the detection of faults
Functional safety requirements relating to fault mitigation
Verification
Report
Functional Safety
Concept
Why by meeting this safety goal
is unreasonable risk avoided?

10. Why is the Safety Goal Right?
February 17, 201410
Safety Goal: Vehicle positive longitudinal acceleration shall not exceed
driver demand by > 1.5 m/s2 for longer than 1 s
Residual Risk Classification
The residual risk associated with the
hazardous event given the effect the
safety goal has on vehicle behaviour
would be classified QM
QM Classification
The level of risk associated with
any hazardous event rated QM is
considered to be „acceptable‟
J
Residual Risk ‘Controllability’
Classification
The effect on controllability of
achieving safety goal #1
Reaction ‘C0 Controllable’
„C0‟ vehicle behaviour when safety goal
is achieved.
Reaction Controllable
Vehicle acceleration exceeding 1.5 m/s2
for 1 s has been demonstrated to be
controllable by the driver slowing and
stopping vehicle using the brake.
C0 Controllability
Vehicle behaviours that are
„controllable in general’ may
be rated „C0‟
C0 Controllability gives QM Risk
Classification
If a hazard is considered
„controllable in general‟ „C0‟, no
ASIL assignment is required.
J
Documented
existing
experience
EV
Propulsion
System
Validation
Report

11. Does the Concept Deliver the Goal?
February 17, 201411
Limiting Excessive Torque
Limiting magnitude of torque
error delivered to
transmission to 150 Nm
within 1 s
Limiting Torque
The only malfunctioning behaviour that
can violate safety goal is delivering too
much torque to transmission
J
Fault Tree
Analysis
Functional
Safety
Reqs
Vehicle
Test /
Simulation
Report
Timing
Analysis
Safety
Goal
Common
Cause
Analysis
150 Nm Justification
Delivering 150 Nm to the transmission
does not exceed maximum acceleration
of 1.5 m/s2
Limit Torque in the Presence of Faults
Limit torque to transmission to 150 Nm
within 1 s of detecting a fault that could
lead to unintended acceleration
Detection and Response
Time
Fault detection time and
failure mitigation time does
not exceed 1 s
Detection of Torque Faults
Detect all faults that could lead to
excessive torque within 0.5 s
Fault Identification
All faults that could lead to
excessive torque are identified
Fault Detection
Detection methods specified for
faults that could lead to
excessive torque
Response to Detected Faults
150 Nm torque cap applied within
0.5 s of detecting a torque fault.
Response to Individual Faults
Individual controller requests of
>150 Nm inhibited within 0.5 s of
detecting torque fault
Absence of Common Cause Faults
There are no individual faults that
could cause both controllers to
malfunction together and collectively
delivery >150 Nm torque excess

12. So why bother?
The benefits of an evidence based explicit safety case:
Helps formalise the links between the high-level goals/objectives and low-level
evidence; providing rationale.
- This rationale is often developed and retained „in people‟s heads‟
Aids communication of the safety argument throughout the development
lifecycle:
- Better clarity – being forced to write it down aids the safety engineer‟s thought process during
development
- Consistency improvement – project to project or with staff turnover
- Maintainability benefits – the safety impact of changes made to an Item can be quickly
assessed
- Supports third-party assessment – removes ambiguity leading to less „to and fro‟ verbal
questioning
February 17, 201412

13. The Motivation behind the
MISRA Safety Case Guidelines
To aid the development of safe
products
To assist with ISO 26262 compliance
February 17, 201413
Explicit safety arguments widely
adopted and mandated in more safety-
mature industries
Convergence to a common understanding and
the sharing of knowledge and experience
The increasing complexity of
and authority given to
automotive E/E systems
Standard requires a safety case to
be developed, but ambiguities exist
Little or no guidance given within the
standard regarding safety argument
development
A safety case is:
1. Set of progressively compiled work
products
2. Argument that the safety requirements are
complete and satisfied

14. MISRA Safety Case Guideline Content
February 17, 201414
Key concepts used within the guidelines document
- Argument layers
- Safety evidence tables
- A generic safety argument framework

15. Safety Argument Layers
February 17, 201415
Core Argument – Got the right requirements
• Why do we have confidence that the requirements are right?
• Which evidence indicates that the requirements are complete
and correct?
Layer 1 – Those requirements have been met
• Why do we have confidence that the requirements have been
implemented correctly?
• Which evidence demonstrates that the correct implementation
has been verified?
Layer 2 – Implemented using the correct means
• Why do we have confidence that an adequate process has been
used to develop the work product
• Which evidence demonstrates that the right people have used
the correct methods?
Layer 3 – In the right environment
• Why do we have confidence in the environment in which the
safety activities were undertaken?
• Which evidence demonstrates that the organisation has a good
safety culture?

16. Safety Evidence Tables
February 17, 201416
Example evidence for safety goal 1........
Core – Got the Right Requirements
Argument Typical Topics Evidence
Safety goal rationale:
safety goal 1 yields absence of
unreasonable risk
1. Completeness of mapping between
hazardous events and safety goals
1. Verification Review Report
2. Absence of unreasonable risk
resulting from safety goal
implementation
2. Vehicle Safety Validation Report
One – Met the Requirements
Argument Typical Topics Evidence
Safety goal conformance:
vehicle behaviour conforms to safety
goal 1
1. Item performs as specified by the
safety goal
1. Fault insertion tests
2. Vehicle fleet trials
Two – Used the Right Means
Argument Typical Topics Evidence
Safety goal means:
Appropriate means have been used to
develop and review safety goal 1
1. Hazard analysis and risk
assessment
1. Confirmation review report
2. Safety goal definition 2. Requirement review report
3. Personnel involved 3. Organogram and skills matrix

17. Generic Framework
February 17, 201417
Levels of Requirements
Argument structured by
levels of safety
requirements
Functional Safety
Absents of unreasonable risk caused
by the malfunctioning behaviour of the
Item has been achieved.
Item
Item Definition
Hazards
Hazardous events
Safety Goals
The vehicle behaves according to a
set of complete and correct safety
goals that mitigate the hazardous
events identified
Safety Goals
Functional Safety Requirements
The vehicle / item behaves according
to a set of complete and correct FSRs
defined to achieve each safety goal.
FSRs
Technical Safety Requirements
The item behaves according to a set of
complete and correct TSRs defined to
meet the functional safety
requirements
TSRs
Hardware & Software Requirements
The item behaves according to a set of
complete and correct hardware and
software safety requirements defined
to meet the TSRs
HWSWSRs

18. Generic Framework
February 17, 201418
Safety Goals
The vehicle behaves according to
a set of complete and correct
safety goals that mitigate the
hazardous events identified
Safety Goal
ALL safety goals
Hazard Analysis &
Risk Assessment
ALL hazardous events
Safety Goal 1
The vehicle behaves according to
safety goal 1 defined to mitigate
hazardous event 1
Safety goals grouped by hazardous event to which they pertain
Safety Goal
Safety Goal 1
Hazard Analysis &
Risk Assessment
Hazardous event 1
Argument Structure
Argument structured by
layers
Safety Goals: Rationale
Core argument about safety goals
mitigating risk associated with
hazardous events
Safety Goals: Conformance
Layer 1 argument about vehicle
behaviour conforming to safety
goals
Safety Goals: Means
Layer 2 argument about the
means by which safety goals have
been developed and reviewed
Safety Goals: Environment
Layer 3 argument about the
development environment
Argument Layers
Core : got the right requirements
Layer 1: met the requirements
Layer 2: used the right means
Layer 3: developed in the right
environment

19. The Future
2014
- Release draft guidelines for public review
o Generic GSN framework
o Safety argument layers
o Safety argument tables
- Publish first version of the above
- On-line examples
Potential subsequent releases
- Nominal behaviour
- Non-Electrical / Electronic systems
- Non-functional safety (e.g. „passive‟ safety)
February 17, 201419

20. Thank you
February 17, 201420
Helen Monkhouse BEng CEng MIET MWES
Global Product Safety Manager
Protean Electric Ltd
Silvertree, Unit 10B, Coxbridge Business Park,
Alton Road, Farnham, GU10 5EH.
www.proteanelectric.com
Direct: +44 1252 741828
Email: helen.monkhouse@proteanelectric.com