Model based development for functional safety
Download
Report
Transcript Model based development for functional safety
Model based development for
function safety
Continental Automotive France
Philippe CUENOT
OFFIS
Thomas PEIKENKAMP
Model based development for function safety
• Process overview
• Hazard Analysis
• Items definition
• Architecture and Safety Concept
• Qualitative Safety Analysis
• Quantitative Safety Analysis
• Conclusion
Continental Automotive / Philippe Cuenot / OFFIS / Thomas Peikenkamp / 2012.09.25
ITEA 2 ~ 10039
Process overview
(not including safety management)
• Main input for the hazard analysis: Definition of the Item (under
investigation), including
– Dependencies/interaction with other items of the vehicle
– Dependencies/interaction with the environment of the vehicle
(including the driver and possibly other traffic participants)
• Identify & model hazards (resp. hazardous events)
– In model-based development we would expect that all identified
hazardous events can be “executed” within the model
– For each hazard a safety goal for hazard avoidance/mitigation
needs to be identified
• Result of hazard analysis shall enable the validation of the
Functional Safety Concept
• Initiate the Functional Safety Concept using architecture model
OFFIS / Thomas Peikenkamp / 2012.09.25
ITEA 2 ~ 10039
Process overview
(not including safety management)
• Qualitative Analysis and rework of the Functional Safety Concept
– Demonstrate that function failure do not violating the safety goal
using model based techniques (Failure Mode as model property)
• Develop the Technical Safety Concept
– Refine architecture model and perform allocation of Logical Function
into SW or HW Functional Block model
• Qualitative Analysis of technical Safety Concept
– Demonstrate that HW and SW function failure do not violating the
safety goal (not cut set of order 1) using model based techniques
• Quantitative Analysis of technical Safety Concept
– Metrics and probabilistic calculation (FIT defined as model property)
• Develop HW and SW component (and then verify)
OFFIS / Thomas Peikenkamp / 2012.09.25
ITEA 2 ~ 10039
Hazard Analysis
Contributing Factors
• Several factors are contributing
to the occurrence of hazardous
events
• For traceability reasons ISO
26262 requires the analysis
– to identify these factors
– to show how they contribute
OFFIS / Thomas Peikenkamp / 2012.09.25
ITEA 2 ~ 10039
Hazard Analysis
Formalization
• Formal description of hazardous events should identify
– identify each factor
– show how it is contributing to its occurrence
Hazard: partial loss of steering function
Factor contributing to hazardous event:
Controllability of torque on steering wheel
OFFIS / Thomas Peikenkamp / 2012.09.25
ITEA 2 ~ 10039
Hazard Analysis
Modeling Needs
• An abstract model of the item/vehicle is used to identify the
concepts needed within the hazard formalization (no design
model!)
• Includes the hazard formalization
• Items are characterized from different perspectives within this
model …
OFFIS / Thomas Peikenkamp / 2012.09.25
ITEA 2 ~ 10039
Items definition
• The item (under investigation) and other items of the vehicle
have to be looked at from different perspectives when describing
hazards and safety goals:
– How is the item used within vehicle/environment?
Operational perspective
– How does it interact with other items?
Functional perspective
– Where is it installed within vehicle?
Geometrical perspective
– What is the HW/SW architecture of the item?
Technical perspective
Need for adequate architecture model …
OFFIS / Thomas Peikenkamp / 2012.09.25
ITEA 2 ~ 10039
Architecture and Safety Concept
Architecture abstraction*
*From SPES Meta Model architecture (OFFIS)
Continental Automotive / Philippe Cuenot / 2012.09.25
ITEA 2 ~ 10039
Architecture and Safety Concept
Mapping with EAST-ADL/AUTOSAR
Continental Automotive / Philippe Cuenot / 2012.09.25
ITEA 2 ~ 10039
System decomposition
Qualitative Safety Analysis
(mix of inductive and deductive methods)
Hazard
analysis
Safety
Goal
FE
FMEA
FMEDA
Generated
FTA / ETA /..
Generated
FTA / ..
Generated
FTA / …
Generated
FTA / …
Merged FTA / ETA/…
Step 1: Elementary block failure mode analysis (Dysfunctional behavior)
Step 2: Tag of each block safety contribution (function, diagnosis, mechanism…)
Step 3: Generation of propagation for Qualitative analysis (FTA / ETA /…)
Continental Automotive / Philippe Cuenot / 2012.09.25
ITEA 2 ~ 10039
Quantitative Safety Analysis
Hardware electronic component
Electronics HW Architecture (Function Blocks)
EAST-ADL / HDA
Hardware Block
Driver
μP
Monitoring
Power Supply
Matching Requirement structural organization
Includes safety mechanism
Describing Function and Interface
Top Level Hardware Safety Requirement
Hardware
Safety Req.
Package
Allocation
from safety qualitative analysis
Component X shall not contribute to Hardware Block Failure
Mode
Electronic Package Allocation
Additional hardware safety requirement
FPGA1
C1
ASIC1
μP
ASICx shall integrate Safety Mechanism 1
FPGAX shall ensure independence between Function 1
and Function 2
Electronic Design
Component Super Set (ASIC1 + C1+ …)
Next step for qualitative analysis
Electronics HW Schematic (Components)
Continental Automotive / Philippe Cuenot / 2012.09.25
AUTOSAR ECU Ress Temp. (IP-XACT match)
ITEA 2 ~ 10039
Quantitative Safety Analysis
FIT allocation to hardware component
SPF
Failure Mode Identification
Archite
cture Function
block
Power
supply
3.3V
Electronics HW architecture (Blocks)
Quantification based on Function Block
FM11: Complete lost of power 0.0002
(from generic design)
λFM11
Y
FM12: Transient power
0.0001
λFM12
N
FM13: Power up impossible
0.003
λFM13
Y
FM14: Power down impossible 0.001
λFM14
FM15: Loss of power
performance
X
λFM15
FM21 : No reset activation
Y
λFM21
FM22 : misplaced reset
Z
λFM22
FM23: Reset always active
T
λFM23
FM24: Non respect of reset
timing
u
λFM24
…etc
Component FIT allocation
for HW component Super Set
Viol.
FIT
FIT
DC
SG1
DC
SG Viol.
(Target) (Calculus
SM HW&S with SM HW&
SG1
)
W Comb.
SW
Fct3
%
Safety Goal 1
Reset
Failure
Mode
MPF
RF+SPF rate
(FIT)
MPF +SF rate
(FIT)
Allocation
(from electronic component and project)
Calculation
Metrics Verification
Target versus Calculated FIT from HW component
PS: Same concept of allocation/calculation can be applied to DC
Continental Automotive / Philippe Cuenot / 2012.09.25
ITEA 2 ~ 10039
Quantitative Safety Analysis
Hardware component metrics contribution
Quantification based on HW electronic Component
Electronic Components Super Sets Failure Mode Analysis
Quantitative contribution to Top level hardware safety requirement (as failure mode FMxx)
Inductive methods for analysis of electronic component failure
Made by specialist as electronic designer and use reliability data base
Use reliability block diagram or failure mode and effect Analysis
Allocation of failure and ratio of component FIT to block failure mode (λFMxx)
Calculation or direct Reliability Block Diagram
FMEA style
HW Block failure Mode
Electronic component
Top level hardware safety
Failure mode
requirement
C1 - λC1oc
λFM11
λFM12
C1 - λC1D
λFM11
ASICB12 - λAB12
etc.
HW Block failure Mode
Top level hardware safety
requirement
HW component sub-set
relation from Reliability
λFM11
AND(C1, ASICB11)
λFM12
OR (C1, ASICB12)
λFM13
Cf. Complex Truth Table (R1,
C1, C2, ASICB11, ASICB12…)
calculus
(λC1oc * λC1D) +
(λAPxol * λAPxcg * λAPxdog) +
λAB11
λC1oc * λAB12
…etc
Serial (AND): λC1oc * λASIC1
Parallel (OR): λC1o + λASIC1
Complex Truth Table Modeling: Σ((λC1oc*λASIC1)+(λC1ccg*λASIC1)) as simplification of OR and AND combination)
Continental Automotive / Philippe Cuenot / 2012.09.25
ITEA 2 ~ 10039
Conclusion
• Benefit of approach
–
–
–
–
Hazard: allows (semi-) formal verification for future
Architecture: clear separation of design and implementation
Reduce time for safety analysis (library and generation approach)
Standardized safety element exchange
• SAFE current status
– 1st extension of EAST-ADL Meta model
‾ Hardware relevant element : metrics, failure…
‾ Hazard and situation using formal semantic
– Formalism for qualitative analysis under revision (FTA / EVA…)
Continental Automotive / Philippe Cuenot / OFFIS / Thomas Peikenkamp / 2012.09.25
ITEA 2 ~ 10039
Thank you for your attention
We value your opinion and questions