SPIN Italia - Functional safety and software · PDF fileFunctional Safety Software development and ISO 26262. ... Safety goal: Top-level safety requirement ... Hardware safety requirements

Pisa, 15/05/2008

Marco BellottiFiat Group Automobiles

Functional Safety

Software development and ISO 26262

Software development and ISO 26262 2Pisa, 15/05/2008

Agenda

Introduction to Functional Safety

Automotive Safety Integrity Level

From ASIL to SW requirements

1

2

3


Agenda



From ASIL to SW requiremets

1

2

3

Main goalsWhat is functional safetyMilestones


Introduction to functional safety

Main goals

• Harmonize all the development phases of E/E systems

• Fit to automotive sector the too restrictive requirements of the existing IEC 61508

• Provide the right integration within different E/E systems

• Provide design and integration measures for embedded systems (not adequately treated in IEC 61508)


Introduction to functional safety

What is functional safety

Safety: absence of unacceptable risks

Functional safety: absence of unacceptable risk due to hazards caused by mal-functional behaviour of E/E systems

Risk: combination of the probability of occurrence of harm and the severity of that harm


IEC 61508

other Safety StandardsQuality Standards

Engineering Standards

Initial workof individualcompanies

Initiatives within

national standardization

bodies

ISOTC22 SC3

WG16

First drafts of

requirementspecifications

RESPONSEAutomotive SPICE

FAKRABNAMISRA

OEMsSuppliers

Technical Services

9.2005PWI: 6.2005Kick off: 11.05NWI: end 2007PAS: mid 2008FDIS: end 2008IS: 07.2010

1.2004

2002 2003

PAS: Publicly AvailableSpecification.

It gives the opportunity to start working on this arguments with the suppliers. It hasbeen requested and approved the insertion of a legal disclaimer, stating:- the PAS is not “state of the art”

ISO 26262

Milestones


Agenda




1

2

3

Classification flowchartRisk reductionSafety requirementsASIL downgrade



Classification flowchart

System overview

Bottom up methods

Hazard analysis

Top down methods

Hazard classification

Use cases identification

ASIL classification

Safety requirements

ASIL downgrade

Description of the goals of the system, its interfaces and interactions with other elements

Identification of allpossible hazards

(Brainstorming, PHA..)

Identification of allpossible driving situations

(Brainstorming)

Classification of the system/function deliberate about the exposure to the

driving situation, itscontrollability and the

severity of all hazards in allscenarios


Fre

qu

ency

remote

always

negligible catastrophicSeverity

Acceptable

Not acceptable

Risk reduction due to external measures e.g Controllabilityby the driver

Probability of Exposure todriving situation

Tolerable Risk

Required ASIL e.g. failure rate

of safety function

Lower than tolerable risk

Tolerable Residual Risk

Severity of possible accident

Safetyclass

(ASIL)

ASIL: Automotive Safety Integrity Level


Risk reduction



ASIL assignment

DCBE4

CBAE3

BAQME2

AQMQME1

S3

CBAE4

BAQME3

AQMQME2

QMQMQME1

S2

BAQME4

AQMQME3

QMQMQME2

QMQMQME1

S1

C3C2C1

� Assigning categories of ASIL (Automotive Safety Integrity Level)


Safety goal: Top-level safety requirement as a result of the hazard analysis and risk assessment

Safety measure: activity or technical solution to avoid or control systematic faults, detect and/or control random hardware faults and mitigate their harmful effect

Safety mechanism: Measures implemented by E/E functions or components dedicated to detect and/or control failures in order to achieve or maintain a safe state of the item

Function � avert hazards or mitigate their consequences

System � define how to control potential hazardous events

Components � define rules and operation to avoid or mitigate the consequences of hazardous events

ASIL

ASIL

ASIL


Safety requirements


Co

nce

pt

ph

ase

Co

nce

pt

ph

ase

Pro

du

ct d

evel

op

men

tP

rod

uct

dev

elo

pm

ent

Aft

er S

OP

Aft

er S

OP

Hazard analysis and risk assessment

3-6 Hazard analysis andrisk assessment

Hazard analysis and risk assessment


Specification of safety goals


Specification of safety goals


Specification of functional safety requirements

3-7 Functional safetyconcept

Specification of functional safety requirements

3-7 Functional safetyconcept

Specification of technical safety requirements

4-5 Specification oftechnical safety concept

Specification of technical safety requirements

4-5 Specification oftechnical safety concept

Hardware safety requirements

5-5 Specification of HWsafety requirements

Hardware safety requirements

5-5 Specification of HWsafety requirements

Software safety requirements

6-5 Specification of SWsafety requirements


6-5 Specification of SWsafety requirements

Ove

rall

man

agem

ent o

f saf

ety

requ

irem

ents

8-5

Ove

rall

man

agem

ent

of

safe

ty r

equ

irem

ents

Ove

rall

man

agem

ent o

f saf

ety

requ

irem

ents

8-5

Ove

rall

man

agem

ent

of

safe

ty r

equ

irem

ents

They are critical phases, with possible heavvy economical impactsif “System, H/W & S/W safety requirements” will be not welldefined to the supplier.


Safety requirements


ASIL decomposition: tailoring of the ASIL related to those safety requirements implemented redundantly by independent architectural elements.

Criticality analysis: reduction of the ASIL assigned to the elements with a limited or absent impact on safety goals.

Possible only when approaching systematic faults. Two kind of procedures:

Independence / segregation

Freedom of interference


Downgrade


Possible between two indipendent elements implementing the same safety goal

ECU 1

ECU 2

Actuator 1

B

Actuator 2

A

CC

C

Sensor 1 B

Sensor 2 A

Independence: physical separation and/or no common resources involved

System safety requirement - ASIL = C

MeasurementControl Unit

Actuator


ASIL decomposition

C

C


Possible only when approaching systematic faults.

All components af all systems implementing at least one safety goal ranked in a “criticality class” fromCC1 to CC3:

DCBA

QM

C

D

QM

B

C

QM

A

B

QM

A

A

Initial ASIL

CC1

CC2

CC3

Description

direct or cascading violation

violation only in combination with a failure of another element

no cause or contribution to the violation of safety goals


Criticality analysis


Agenda




1

2

3

FlowchartSoftware safety requirementsSoftware architecture designSoftware unit design implementationSoftware unit testingSoftware integration and testingSoftware acceptance test


System design

System safety requirements (safety goals,safety mechanisms...)

Software safetyrequirements

Software architecture

Software unitdesign

implementation

Software unittesting

Software integration and

testing

Software safetyacceptance testing

Design and implementation

Integ

ratio

n, tes

ting an

d acc

eptan

ce

Software development

From ASIL to safety requirements

Flowchart



Define and describe all functional and non-functional safety-related requirements.

Identify each of the safety-related dependencies among hardware and software (architecture; interfaces; all operating modes with a relevant impact on software)

oo++++Walkthrough of software safety requirements

o

++

++

o

++

++

+

++

++

++Model Walkthrough

++Model inspection

++Inspection of software safety requirementsa

++++++Formal verification1c

++++++Semi-formal verification1b

Informal verification1a

DCBA

ASILMethods and Measures for the verification of software safety requirements



++ higly recommended + recommended o optional


Represent all software components and their interactions in a hierarchic structure.

Software architecture design

� Hierarchical structure of all software components implementing the software safety requirements.� Shall be developed to the level that identifies the software units which are to be treated as indivisible.

+++ooSeries inhibitsd 3d

+++ooDiverse software design3c

+++++oControl flow monitoring3b

++++oExternal monitoring facility3a

++++++Detection of data errors2

++++++++Plausibility check1

DCBA

ASILError handling at software architecture design



Software safety architecture


Implement the design as a model or directly as a source code.

�Differences between code based and model based development� It shall be ensured that all the functions contained on embedded software cannot impair the fulfilment of software safety requirements.

Software unit design

implementation

++++++Computer-aided tools for software unit design3

++++++Formal notations for software unit design 2c

+++++++Semi-formal notations for software unit design2b

++++++Informal notations for software unit design2a

++++++++Documentation of the software unit design in natural language 1

DCBA

ASILNotation for software unit design



Software unit design implementation


Demonstrate that the software units fulfil the software unit specifications and do not contain any other functions.

Software unittesting

The test environment for software unit testing shall correspond as far as possible to the target environment.

++++++Equivalence class test based on input domain partitions5

++++Error guessing test4

++++Fault injection test3

++++++++Model-based testing2b

++++++++Software unit interface test2a

++++++++Requirement-based test1

DCBA

ASILFunctional software unit testing



Software unit testing


The software units have to be integrated to create the embedded software of the electronic control unit.

Software integration and

testing

Demonstrate that the software architectural design is correctly realised by the embedded software.

++++Call coverage2b

++++Function coverage2a

+++++++Internal interface test1

DCBA

ASIL

Structural software integration testing



Software integration and testing


Demonstrate that the embedded software fulfils all software safety requirements.

Software safety acceptance testing

Pass or fail criteria for the software acceptance testing shall be specified. They shall be derived from the software safety requirements

++++++++Tests in the test vehicle3c

++++++++Tests within the electronic control unit network3b

++++++Hardware-in-the-loop tests3a

++++Test interface2

++++++++Tests of software safety requirements1

DCBA

ASILMethods and Measures



Software safety acceptance testing


Thank you for your attention

Documents

SPIN Italia - Functional safety and software · PDF fileFunctional Safety Software development and ISO 26262. ... Safety goal: Top-level safety requirement ... Hardware safety requirements