MISRA Safety Case Guidelines -

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, 2014 2


February 17, 2014 3

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:


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, 2014 4

The Safety Case Argument

February 17, 2014 5

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, 2014 6

Does our compilation of ISO 26262 work products lead to an explicit safety case argument?

The ISO 26262 Safety Case Argument

February 17, 2014 7

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, 2014 8

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, 2014 9

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, 2014 10

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?


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


The Motivation behind the MISRA Safety Case Guidelines

To aid the development of safe

products

To assist with ISO 26262 compliance


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


Key concepts used within the guidelines document

- Argument layers

- Safety evidence tables

- A generic safety argument framework

Safety Argument Layers


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


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


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


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


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


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)


Thank you


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: [email protected]

http://www.proteanelectric.com/

MISRA Safety Case Guidelines -

Automotive

Transcript of MISRA Safety Case Guidelines -