MISRA Safety Case
Guidelines
Why we are writing these guidelines.....
Helen Monkhouse
Global Product Safety Manager, Protean Electric Ltd.
MISRA Steering Committee Member
Agenda
Introduction to MISRA
Safety Cases
- What is it?
- What constitutes a good one?
MISRA Safety Case Guidelines
February 17, 20142
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:
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
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
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?
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
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
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?
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
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
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
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
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
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?
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
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
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
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
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

MISRA Safety Case Guidelines -

  • 1.
    MISRA Safety Case Guidelines Whywe are writing these guidelines..... Helen Monkhouse Global Product Safety Manager, Protean Electric Ltd. MISRA Steering Committee Member
  • 2.
    Agenda Introduction to MISRA SafetyCases - What is it? - What constitutes a good one? MISRA Safety Case Guidelines February 17, 20142
  • 3.
    Introduction to MISRA February17, 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 MISRAaims 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 CaseArgument 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 ISO26262 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 26262Safety 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 ExplicitSafety 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 WorkProducts 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 theSafety 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 ConceptDeliver 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? Thebenefits 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 behindthe 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 CaseGuideline 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 February17, 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 February17, 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 - Releasedraft 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