Model based development for function safety Continental Automotive France Philippe CUENOT OFFIS Thomas PEIKENKAMP

ITEA 2 ~ 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 /

ITEA 2 ~ 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 /

ITEA 2 ~ 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 /

ITEA 2 ~ Hazard Analysis Contributing Factors OFFIS / Thomas Peikenkamp / Several factors are contributing to the occurrence of hazardous events For traceability reasons ISO requires the analysis –to identify these factors –to show how they contribute

ITEA 2 ~ Hazard Analysis Formalization OFFIS / Thomas Peikenkamp / 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

ITEA 2 ~ Hazard Analysis Modeling Needs OFFIS / Thomas Peikenkamp / 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 …

ITEA 2 ~ Items definition OFFIS / Thomas Peikenkamp / 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 …

ITEA 2 ~ Architecture and Safety Concept Architecture abstraction* *From SPES Meta Model architecture (OFFIS) Continental Automotive / Philippe Cuenot /

ITEA 2 ~ Architecture and Safety Concept Mapping with EAST-ADL/AUTOSAR Continental Automotive / Philippe Cuenot /

ITEA 2 ~ Qualitative Safety Analysis (mix of inductive and deductive methods) 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 /…) Merged FTA / ETA/… System decomposition FMEA FMEDA Hazard analysis Safety Goal Generated FTA / ETA /.. Generated FTA /.. Generated FTA / … FE Generated FTA / … Continental Automotive / Philippe Cuenot /

ITEA 2 ~ Package Allocation Power Supply Monitoring μPμP Driver μPμP FPGA1 C1 ASIC1 Hardware Block Matching Requirement structural organization Includes safety mechanism Describing Function and Interface Hardware Safety Req. Electronics HW Architecture (Function Blocks) Electronics HW Schematic (Components) Top Level Hardware Safety Requirement from safety qualitative analysis Component X shall not contribute to Hardware Block Failure Mode Quantitative Safety Analysis Hardware electronic component Continental Automotive / Philippe Cuenot / EAST-ADL / HDA AUTOSAR ECU Ress Temp. (IP-XACT match) Electronic Package Allocation Additional hardware safety requirement 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

ITEA 2 ~ Electronics HW architecture (Blocks) Failure Mode Identification Quantification based on Function Block Metrics Verification Target versus Calculated FIT from HW component Archite cture block Function Failure Mode FIT (Target) FIT (Calculus ) SG SPFMPF Viol. SG1 SM DC HW&S W Viol. SG1 with Comb. SM DC HW& SW Power supply 3.3VFM11: Complete lost of power0.0002λ FM11 Safety Goal 1 YFct3% FM12: Transient power0.0001λ FM12 N FM13: Power up impossible0.003λ FM13 Y FM14: Power down impossible0.001λ FM14 FM15: Loss of power performance Xλ FM15 ResetFM21 : No reset activationYλ FM21 FM22 : misplaced resetZλ FM22 FM23: Reset always activeTλ FM23 FM24: Non respect of reset timing uλ FM24 …etc RF+SPF rate (FIT) MPF +SF rate (FIT) Allocation (from electronic component and project) Calculation Component FIT allocation for HW component Super Set (from generic design) PS: Same concept of allocation/calculation can be applied to DC Continental Automotive / Philippe Cuenot / Quantitative Safety Analysis FIT allocation to hardware component

ITEA 2 ~ Electronic Components Super Sets Failure Mode Analysis Quantitative contribution to Top level hardware safety requirement (as failure mode FMxx) HW Block failure Mode Top level hardware safety requirement HW component sub-set relation from Reliability calculus λ FM11 AND(C1, ASICB11)(λC1oc * λC1D) + (λAPxol * λAPxcg * λAPxdog) + λAB11 λ FM12 OR (C1, ASICB12)λ C1oc * λ AB12 λ FM13 Cf. Complex Truth Table (R1, C1, C2, ASICB11, ASICB12…) …etc 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 ) Serial (AND): λ C1oc * λ ASIC1 Parallel (OR): λ C1o + λ ASIC1 Complex Truth Table Modeling: Σ((λ C1oc* λ ASIC1) +(λ C1ccg* λ ASIC1 )) as simplification of OR and AND combination) Quantification based on HW electronic Component Quantitative Safety Analysis Hardware component metrics contribution Continental Automotive / Philippe Cuenot / FMEA style Electronic component Failure mode HW Block failure Mode Top level hardware safety requirement C1 - λ C1oc λ FM11 λ FM12 C1 - λ C1D λ FM11 ASICB12 - λ AB12 etc. Calculation or direct Reliability Block Diagram

ITEA 2 ~ 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 –1 st 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 /

Thank you for your attention We value your opinion and questions