Скачать презентацию An Automated Failure Mode and Effect Analysis based Скачать презентацию An Automated Failure Mode and Effect Analysis based

af127ba5232e7c3685ca7e1ecfaac4d4.ppt

  • Количество слайдов: 23

An Automated Failure Mode and Effect Analysis based on High-Level Design Specification with Behavior An Automated Failure Mode and Effect Analysis based on High-Level Design Specification with Behavior Trees Lars Grunske, Peter Lindsay, Nisansala Yatapanage, Kirsten Winter ARC Centre for Complex Systems School of Information Technology and Electrical Engineering, University of Queensland, Brisbane, QLD 4072, [email protected] uq. edu. au 1

Agenda § § Problem description/context Preliminaries § § Automated Hazard Analysis § § § Agenda § § Problem description/context Preliminaries § § Automated Hazard Analysis § § § § Procedure Overview Generation of Design Behavior Trees Generation of Fault View BTs Identification and Specification of Hazard Conditions Model Checking (SAL Toolkit) Generation of FMEA-tables Case-Study § § Behavior Trees Industrial Metal Press Conclusion Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 2

Motivation § Problem Context § Safety-critical software-intensive systems § Automotive electronics, aviation, industrial process Motivation § Problem Context § Safety-critical software-intensive systems § Automotive electronics, aviation, industrial process control and medical applications § Problem § Increasing complexity § Goal § Model and analyze safety-critical behaviors early in the development lifecycle § Systematic and integrated approach for safety analysis § Automate Failure Modes and Effects Analysis (FMEA) § Tool support that automates the tedious and error-prone aspects of FMEA 3

Preliminaries Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Preliminaries Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 4

Behavior Trees § Behavior Tree § Graphical notation to capture the functional requirements § Behavior Trees § Behavior Tree § Graphical notation to capture the functional requirements § Textual requirements are translated into individual requirements trees § These individual requirement trees are merged into one integrated requirements tree § Stepwise, structured approach, § Semi automatic § Early error detection § Literature: § Dromey, R. G. : From requirements to design: Formalizing the key steps. In: Int. Conference on Software Engineering and Formal Methods (SEFM 2003), IEEE Computer Society (2003) 213 § GSE: Genetic Software Engineering: http: //www. sqi. gu. edu. au/gse Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 5

Behavior Tree Syntax (1) § Basic Syntax Elements § Reversion, Synchronisation ^ Dr. rer. Behavior Tree Syntax (1) § Basic Syntax Elements § Reversion, Synchronisation ^ Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems = 6

Behavior Tree Syntax (2) § Control flow in Behavior Trees Dr. rer. nat. Lars Behavior Tree Syntax (2) § Control flow in Behavior Trees Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 7

Generation of Design Behavior Trees § Goal § Decomposition of the integrated requirements BT Generation of Design Behavior Trees § Goal § Decomposition of the integrated requirements BT into component BTs. § Interactions are modeled by message passing (BT events) § Process (semi-automatic) § Identify controller, sensor, and actuator components and the environment (Following the usual architecture of reactive systems) § Each component forms a thread in the overall system § Parallel composition of the components and environment § Literature § Wen, L. , Dromey, R. G. : From requirements change to design change: A formal path. In: Int. Conference on Software Engineering and Formal Methods (SEFM 2004), IEEE Computer Society (2004) 104113 Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 8

Automated Hazard Analysis An Automated Failure Mode and Effect Analysis based on High-Level Design Automated Hazard Analysis An Automated Failure Mode and Effect Analysis based on High-Level Design Specification with Behavior Trees Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 9

Procedure Overview § Precondition § Design BT § Description of the hazard conditions § Procedure Overview § Precondition § Design BT § Description of the hazard conditions § Component fault specification § Procedure § § Inject faults into the design BT fault view BT Translate the fault view BT to SAL code Identify LTL-formulas for the hazard conditions Model-check the system Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 10

Generation of Fault View BTs § A Fault View BT describes the behavior of Generation of Fault View BTs § A Fault View BT describes the behavior of the system when it is affected by one or more component faults. § Fault injection § Prune the design BT (Omission Failure) § Add failure behavior (Commission Failure) § Example Failure: component C is unable to reach state c: § Tree is pruned at C ? ? c? ? branch Original BT Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems Fault View BT 11

Translating Fault View BTs to SAL Code § Generating SAL action systems § Procedure Translating Fault View BTs to SAL Code § Generating SAL action systems § Procedure § Generate variables (component state variables, messages) § Internal vs. external variables § Split BTs into transitions. § Identification of atomic actions § Each condition or event starts a new action § Each branching point starts a new action § Create sequence of actions (using a program counter (PC) concept) § Each action increases the actual PC value § Reversion Set back the PC § New Process New PC § Translation Scheme (contains 8 translation rules) § More details in the paper Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 12

Identification and Specification of Hazard Conditions § Hazard identification § Not the scope of Identification and Specification of Hazard Conditions § Hazard identification § Not the scope of this project § Bidirectional search cause-consequence relationships § Traditional techniques can be used § Hazard Specification LTL formula § Safety Patterns (Natural Language Templates for Specifying LTL/CTL) § Bitsch, F. : Safety patterns - the key to formal specification of safety requirements. In: Int. Conference on Computer Safety, Reliability and Security (SAFECOMP 2001). Volume 2187 of LNCS. , Springer. Verlag (2001) 176 -189 § M. B. Dwyer, G. S. Avrunin, and J. C. Corbett. Patterns in Property Specifications for Finite-State Verification. In 21 st International Conference on Software Engineering, Los Angeles, May 1999. Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 13

Model Checking & Generation of FMEA-tables § LTL model checker of the SAL Toolkit Model Checking & Generation of FMEA-tables § LTL model checker of the SAL Toolkit (http: //sal. csl. sri. com/) § We check, if the model of the fault view BT is able to reach a state in which the hazard conditions (LTL formula) is true. § If yes, we receive a counter example § Trace: initial state hazardous state § Fault propagation § Hint for design changes § If no, the injected fault(s) does not produce a hazard § Generation of FMEA table § Based on the model checking results § Including the counter examples (illustrated) Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 14

Case Study Industrial Metal Press Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, Case Study Industrial Metal Press Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 15

Industrial Metal Press Source: Mc. Dermid, J. , Kelly, T. : Industrial press: Safety Industrial Metal Press Source: Mc. Dermid, J. , Kelly, T. : Industrial press: Safety case. Technical report, High Integrity Systems Engineering Group, University of York (1996) Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 16

Industrial Metal Press Behaviour Description § Press main functions: § Raise plunger to top Industrial Metal Press Behaviour Description § Press main functions: § Raise plunger to top (open the press) § Release plunger (close the press) § Abort operation (stop closing & reopen the press) § System-level requirements/operational concept: § Upon start-up, press will open fully § If button is pushed while press is fully open, press will start to close § Upon closing, press will automatically reopen § If safe to do so, closing can be aborted by releasing the button § Safe = above Point of No Return (Po. NR) Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 17

Design Behavior Tree Industrial Metal Press (complete and small ) Dr. rer. nat. Lars Design Behavior Tree Industrial Metal Press (complete and small ) Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 18

Safety Requirements (Negated Hazard Conditions) HC 1. If the plunger is at the top Safety Requirements (Negated Hazard Conditions) HC 1. If the plunger is at the top and the operator is not pushing the button, the motor should remain on. G ((plunger = attop operator = releasebutton) (motor = on)) HC 2. If the plunger is falling below the PONR, known as falling fast, the motor should remain off. G ((plunger = fallingfast) (motor = off )) HC 3. If the plunger is falling above the PONR, known as falling slow, and the operator releases the button, the motor should eventually turn on, before the plunger changes state. G ((plunger = fallingslow operator = releasebutton) (plunger = fallingslow U motor = on)) HC 4. The motor should never turn off while the plunger is rising. G ( (plunger = risingbelow. PONR plunger = risingabove. PONR) (motor = off ))) Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 19

Results HC 1. If the plunger is at the top and the operator is Results HC 1. If the plunger is at the top and the operator is not pushing the button, the motor should remain on. HC 2. If the plunger is falling below the PONR, known as falling fast, the motor should remain off. HC 3. If the plunger is falling above the PONR, known as falling slow, and the operator releases the button, the motor should eventually turn on, before the plunger changes state. HC 4. The motor should never turn off while the plunger is rising. Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 20

Tool Support BTE & BTFail http: //www. sqi. gu. edu. au/gse/tools/ Dr. rer. nat. Tool Support BTE & BTFail http: //www. sqi. gu. edu. au/gse/tools/ Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 21

Open Problems and Future Work § Modelling and Checking of failure at any time Open Problems and Future Work § Modelling and Checking of failure at any time during system operation § Probabilistic model-checking § Aim: determine the probability that a failure mode leads to a Hazard § Timing Analysis § Aim: investigate timing failures (too early and too late) Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 22

Conclusion § Contribution: § Automation of FMEA § Automatic Fault Injection + Model Checking Conclusion § Contribution: § Automation of FMEA § Automatic Fault Injection + Model Checking § Benefits: § Tool support that automates the tedious and errorprone aspects of FMEA § Systematic and integrated approach for safety analysis § Thanks! § Questions? Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of ITEE, ARC Centre for Complex Systems 23