WorkShop Audace:

ISO 26262 and reliabilityINSA ROUEN

8 juin 2012

Introduction

�Situation in automotive industry• New functions are increasingly safety related (E-Stars, E-Latch,

driving assistance)

• No automotive safety standard. The IEC 61508 pretends to beapplicable to any industry field that has no dedicated safetystandard

• Car makers selling in the US began to require compliance toIEC 61508 a few years ago because of liability issues.

• Other car makers are following (not in France).

• IEC 61508 is not well suited to automotive development and isoften subject to different interpretations

• Urgent need of an automotive safety standard

IEC 61508 – Multi sector application� INCONVENIENTS AND LACK OF THE GENERIC

STANDARDS

� IEC 61508 requires a separate lifecycle forsafety related function development. And itis not easy to align it with the traditionalautomotive engineering V approach ->necessity of planning, synchronisationwith project progress

� IEC 61508 imposes the allocation of a SILlevel to safety systems but do not imposean allocation method. It only encouragesreflexion of project responsibles upon it ->insufficient guidelines

Safety Standards overview

Electronic systems safety standards

Airborne Railway

Automotive

?

NuclearPower

Process

DO-178B EN 50126, 128, 129

IEC 61513, IEC 60880

IEC 61511

Introduction

� Overview of existing safety standards

IEC 61508 Derivates• EN 5012x (Railway)• IEC 60601 1-4 (Medical)• IEC 61513 (Nuclear) • IEC 61511 (Process Industry)• ISO EN 12100 (Machinery)

Safety Standards• IEC 61508 (Meta-Standard)

• ISO TR 15497: MISRA Guidelines • ECSS-E-40A (EU, Space)• RTCA DO-178B (Aerospace SW, V&V)• SAE APR 7461 (Aerospace, HW)• NASA-GB-1740.13-96 (SW-Guidebook)• Def Stan 00-55 (Military)• IEC 60880 (SW in Nuclear Power Plants)

Introduction

Introduction

� Main differences between 61508 and ISO 26262

• The IEC 61508 Safety Lifecycle is not suited toautomotive as it originated from process andautomation industry (example: validation afterinstallation)

• ISO 26262 includes requirements on manufacturer/supplier relation and distributed development processes

• Use of HIL-tests, fleet tests and user oriented testsduring validation is taken into account in ISO 26262

• Hazard analysis and risk assessment (determination ofASIL level of hazards) is adapted for typical automotiveuse cases

Introduction

� Main differences between 61508 and ISO 26262 (3)

• A clear distinction between main function and safetyfeatures, as does 61508 is not feasible in automotive

• SIL requirements give probabilistic target for the wholesystem (even if IEC 61508 admits that this cannot be computed for

systematic failures).

• ASIL requirements give only probabilistic target forrandom HW failures.

Driver Controllability(and Usability)

OtherTechnologies

ExternalMeasures

Back to appropriate lifecycle phase

conc

ept p

hase

prod

uct

deve

lopm

ent

afte

r S

OP

Planning of Production7.4

Planning of Operation, Service and Decom.7.5

Product DevelopmentSystem

4

Hard-ware5 Soft-

ware6

Product Release for SOP4.9

Functional Safety Concept3.7

Hazard Analysis and Risk Assessment3.6

Initiation of Safety Lifecycle3.5

Definition of Item under Consideration3.4

Production7.4

Operation, Service and Decommissioning7.5

Supporting Processes8.4 – 8.15

Management of Functional Safety2.4 – 2.6

Content overview - Safety lifecycle

Content overview : Concept phase� Part 3.6: H&R - ASIL

acceptable

not acceptableRisk Reduction external to technical system: e.g. driver controls situation

Probability of exposure to driving situation where accident can potentially happen

Reliability of system and

absence of systematic faultssafety class (ASIL)

Lower than tolerable risk

ResidualRisk

Severity of possible accident

Probability per hour (runtime)

Extremeimprobable

Sometimes

Rarely

Very rarely

Always

Safetyclass

(ASIL)

Low (Catastrophical)Important Hazardous

Random hardware failure

� This probabilistic evaluation shall NOT be describedas a means to predict a number of casualties in thefield, but a means to evaluate a safety architecturewith regard to HW random failures

� Is is in no way a substitute to qualitative evaluation,but a supplementary requirement regarding randomHW failures for higher ASIL level ; it does notalleviates the effort necessary to address the otherkind of failures

Random hardware failure

Hardware architectural metrics

Hardware architectural metrics

Hardware architectural metrics

� Needs : Knowledge of failure modes

Reliability test

� The hardware integration and testing activities shallverify robustness of hardware against externalstresses.

THANK FOR YOUR ATTENTION