SPIN Italia - Functional safety and software · PDF fileFunctional Safety Software development...
Transcript of SPIN Italia - Functional safety and software · PDF fileFunctional Safety Software development...
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
Software development and ISO 26262 3Pisa, 15/05/2008
Agenda
Introduction to Functional Safety
Automotive Safety Integrity Level
From ASIL to SW requiremets
1
2
3
Main goalsWhat is functional safetyMilestones
Software development and ISO 26262 4Pisa, 15/05/2008
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)
Software development and ISO 26262 5Pisa, 15/05/2008
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
Software development and ISO 26262 6Pisa, 15/05/2008
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
Software development and ISO 26262 7Pisa, 15/05/2008
Agenda
Introduction to Functional Safety
Automotive Safety Integrity Level
From ASIL to SW requiremets
1
2
3
Classification flowchartRisk reductionSafety requirementsASIL downgrade
Software development and ISO 26262 8Pisa, 15/05/2008
Automotive Safety Integrity Level
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
Software development and ISO 26262 9Pisa, 15/05/2008
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
Automotive Safety Integrity Level
Risk reduction
Software development and ISO 26262 10Pisa, 15/05/2008
Automotive Safety Integrity Level
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)
Software development and ISO 26262 11Pisa, 15/05/2008
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
Automotive Safety Integrity Level
Safety requirements
Software development and ISO 26262 12Pisa, 15/05/2008
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
3-6 Hazard analysis andrisk assessment
Specification of safety goals
3-6 Hazard analysis andrisk assessment
Specification of safety goals
3-6 Hazard analysis andrisk assessment
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
Software safety 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.
Automotive Safety Integrity Level
Safety requirements
Software development and ISO 26262 13Pisa, 15/05/2008
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
Automotive Safety Integrity Level
Downgrade
Software development and ISO 26262 14Pisa, 15/05/2008
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
Automotive Safety Integrity Level
ASIL decomposition
C
C
Software development and ISO 26262 15Pisa, 15/05/2008
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
Automotive Safety Integrity Level
Criticality analysis
Software development and ISO 26262 16Pisa, 15/05/2008
Agenda
Introduction to Functional Safety
Automotive Safety Integrity Level
From ASIL to SW requiremets
1
2
3
FlowchartSoftware safety requirementsSoftware architecture designSoftware unit design implementationSoftware unit testingSoftware integration and testingSoftware acceptance test
Software development and ISO 26262 17Pisa, 15/05/2008
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
Software development and ISO 26262 18Pisa, 15/05/2008
Software safety requirements
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
From ASIL to safety requirements
Software safety requirements
++ higly recommended + recommended o optional
Software development and ISO 26262 19Pisa, 15/05/2008
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
++ higly recommended + recommended o optional
From ASIL to safety requirements
Software safety architecture
Software development and ISO 26262 20Pisa, 15/05/2008
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
++ higly recommended + recommended o optional
From ASIL to safety requirements
Software unit design implementation
Software development and ISO 26262 21Pisa, 15/05/2008
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
++ higly recommended + recommended o optional
From ASIL to safety requirements
Software unit testing
Software development and ISO 26262 22Pisa, 15/05/2008
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
++ higly recommended + recommended o optional
From ASIL to safety requirements
Software integration and testing
Software development and ISO 26262 23Pisa, 15/05/2008
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
++ higly recommended + recommended o optional
From ASIL to safety requirements
Software safety acceptance testing
Software development and ISO 26262 24Pisa, 15/05/2008
Thank you for your attention