principles of altarica language and tools for system
play

Principles of AltaRica Language and tools for system safety - PowerPoint PPT Presentation

Principles of AltaRica Language and tools for system safety assessment January 2016 Pierre.Bieber@onera.fr, Christel.Seguin@onera.fr Outline System Safety Assessment AltaRica Basics AltaRica Data Flow Language Fault tree


  1. Principles of AltaRica Language and tools for system safety assessment January 2016 Pierre.Bieber@onera.fr, Christel.Seguin@onera.fr

  2. Outline • System Safety Assessment • AltaRica Basics • AltaRica Data Flow Language • Fault tree generation • DAL Allocation

  3. System safety analysis and limits of current approaches

  4. Hydraulic System Engine Driven Pump Priority distribution Non-Priority distribution green Pdistg eng1 rsvg EDPg PVg NPdistg Engine #1 Reservoir Priority Valve PTU Power Transfer Unit eng2 EDPy PVy NPisty From electrical rsvy system side #1 EMPy Pdisty yellow elec1 Electrical Motor Pump elec2 PVb NPdistb EMPb rsvb RAT Pdistb blue Ram Air Turbine Safety architecture : 3 independent lines • About 20 components of 8 classes: reservoir, pumps, pipes, valves •

  5. ARP 4754 Safety Assessment Process Aircraft Level Aircraft Level Aircraft FHA requirements FHA: Functional Hazard Analysis Functions Failure Condition, Effects, Functional Classification, Safety Objectives Interactions Allocation of aircraft Functions System Level System to systems FHA Sections Failure Functions Conditions & Effects Failure Condition, Effects, Classification, Safety Objectives Development of PSSA: Preliminary System Safety Assessment system Separation Architectural architecture PSSAs Requirements Requirement System CCAs Architecture Allocation of Item Requirements requirements to Safety Objectives, Analyses Required hardware and CCA: Common Cause Analysis Item Requirements software SSAs System implementation Implementation Separation Verification Physical System Results Aircraft Safety Synthesis Certification Safety Assessment Process System Development Process

  6. Classical failure propagation models and safety assessment techniques (cf ARP 4761) • Failure mode and effect analysis (FMEA) – Model: from a local failure to its system effects / natural languages Functional FMEA template • Fault tree analysis (FTA) – Model: from a system failure to its root causes / boolean formulae – Computation: minimal cut sets / probability of occurrence of top event FT unannunciated loss of wheel braking

  7. Drawbacks of the classical Safety Assessment Approaches • Fault Tree, FMEA Give failure propagation paths without referring explicitly to a commonly – agreed system architecture / nominal behavior => – Misunderstanding between safety analysts and designers – Potential discrepancies between working hypothesis • Manual exhaustive consideration of all failure propagations become more and more difficult, due to: increased interconnection between systems, – integration of multiple functions in a same equipment – dynamic system reconfiguration –

  8. Model based safety assessment rationales Goals • Propose formal failure propagation models closer to design models – Develop tools to – • Assist model construction • Analyze automatically complex models For various purposes – • FTA, FMEA, Common Cause Analysis, Human Error Analysis, … • since the earlier phases of the system development Approaches • Extend design models (Simulink, Build dedicated failure SysML, AADL...) propagation models with failure modes (Figaro, AltaRica, Slim...)

  9. Basics of AltaRica dataflow language

  10. AltaRica language at a glance • Language designed in late 90's at University of Bordeaux • for modelling both combinatorial and dynamic aspects of failure propagation • in a hierarchical and modular way • formally . • Typical content of a basic AltaRica node fault occurrence event nominal event Transitions nominal state error state Assertion Input Output output = f (inputs, states) flows flows

  11. A leading example: the basic reliability block • Let be a basic system component Block that Component name • receives fail • one Boolean input I, • an activation signal A and Component interfaces • a resource signal R. • produces I Block O • a Boolean output O 2 internal • Block performs nominally the following transfer law A R states: - 1 ok • O is true iff I, A and R are true. Nominal mode definition - 1 not ok • Block may fail . • In this case, the output O is false. Failure mode definition • Initially, the block performs the nominal function

  12. AltaRica basic block From concepts to a concrete syntax: node Block flow O:Bool:out; Component interfaces I, A, R :Bool: in; Block.fail state ok: Bool; Component internal states event Ok=true Ok=false fail; Observable event init O= (I and A and R and Ok); ok:= true; I O Transitions: trans Automata part ok |- fail -> ok := false; A R assert O = (I and A and R and ok); edon Assertion: Combinatorial part

  13. AltaRica semantics From AltaRica code to mode automata Block.fail ok=true O=(I and A and R) Ok=true Ok=false fail O= (I and A and R and Ok); I O ok=false O=false A R

  14. Internal operations on mode automata • Interconnection : mapping an input of an automaton with an output of another automaton • preserves all states, variables, transitions, assertions • Introduces new assertions: Block2.I = Block1.O for all pairs of connected interfaces • interleaving parallelism (only one transition at a time) • ! allowed only if variables are not circularly defined • Ex: Block 1 Block 2 block1.ok=block2.ok=true block1.ok=true, block2.ok=false fail2 block1.O=block2.I= block1.O=block2.I= (block1.I and block1.A and block1.R) (block1.I and block1.A and block1.R) block2.O=(block2.I and block2.A and block2.R) block2.O=false fail1 fail1 block1.ok=false, block2.ok=true fail2 block1.ok=block2.ok=false block1.O=block2.I=false block1.O=block2.I=false block2.O=false block2.O=false

  15. AltaRica Model of the Hydraulic System

  16. Safety assessment tools

  17. Formal Requirement Modeling Example of safety requirement Requirement : " Total loss of hydraulic power is classified Catastrophic, the • probability rate of this failure condition shall be less than 10 -9 /FH. No single event shall lead to this failure condition " (SSA ATA29) Extended qualitative requirements could be added to reveal architecture • design concerns: “ if up to N individual failures occur then failure condition FC should not occur ”, with N= 0, 1, 2 if FC is Minor, Major or Hazardous, Catastrophic. Observer nodes are added into the model to detect requirement violation

  18. Fault-Tree generation A pair (output variable, target value) is selected • A Fault Tree of faults leading to this situation is generated • The fault tree can be exported to other tools (e.g. Arbor,...) to • compute of minimal cut sets

  19. Principles of Fault-Tree computation init To compute a fault-tree for a • f1 f2 Failure Condition (FC) from an AltaRica Model: s1 s2 Generate the model automaton 1. f5 f3 f4 Select states where the FC 2. holds s4 s3 Compute event paths that leads 3. from the initial state to the FC selected states State=s3 State=s4 Path_to_s3_by_s1 Path_to_s3_by_s2 Path_to_s4_by_s2 f1 f3 f2 f4 f2 f5 19

  20. Verification of Qualitative Requirements Generate Minimal cut sets from the Fault Tree • Loss of Green Hydraulic : {{distg.fail}, {rsvg.fail}, {empg.fail, edpg.fail}, • {empg.fail, eng1.fail}, {elec.fail, edpg.fail}, {elec.fail, eng1.fail}} The size of minimal cut sets for a FC in Sev should be greater or • equal to NSev . Size Sev MIN MAJ HAZ CAT f0 NSev 1 2 2 3 f6 NSev f3 f1 f1 f4 f4 f2 f5 f5 Safety Results unacceptable

  21. ! Classes of model • Static/Dynamic Model • Static Model: the order of the events in the sequence as no influence on the current configuration • Dynamic Model : the last property is not verified => use sequence generation rather than fault tree generation fail go lost, started ok, started ok, idle fail ok,idle ok, started go

  22. DAL

  23. Development Assurance Level • DAL • DAL ranges from E to A • The DAL is the level of rigor of development assurance tasks performed on functions and items (software, hardware) • DAL allocation • DAL of a function depends on the severity of the most severe Failure Condition that this function fault contributes to. • A Qualitative analysis of the Minimal Cut Sets of the system has to be performed

  24. DAL Allocation • Basic Allocation rule Sev DAL CAT A • If f1 appears in a MCS for of FC with severity HAZ then the DAL of f1 is B HAZ B MAJ C MIN D • DAL downgrading rules • If f1 appears in a MCS in combination with f2 and f3 then the DAL of f1 could be downgraded if there is independence between f1, f2 and f3. f1 f1 f1 f1 f1 f1 Sev(FC)=HAZ f2 f2 f2 f2 f2 f2 DAL(FC) =B f3 f3 f3 f3 f3 f3 Independence No Independence + Option 2 independence + Option 1

  25. AltaRica Tools available Cecilia OCAS from Dassault Aviation • Used for the first time for certification of flight control system of Falcon 7X in • 2004 Tested by contributors of ARP 4761 (cf MBSA appendix) • AltaRica free suite from Labri • compatible with data flow restriction, http://altarica.labri.fr/wp/ • Other tools • Safety Designer from Dassault System, Simfia from APSYS Airbus group, • RAMSES from Airbus, AltaRica 3.0 (under development at IRT Systemix) And plugins to independent tools • NU-SMV (FBK Trento), MOCA-RP (Satodev Bordeaux), Arc (LaBri • Bordeaux), EPOCH (ONERA)…. DAL allocation • DALculator (ONERA) •

Recommend


More recommend