Title: Dr.%20rer.%20nat.%20Lars%20Grunske,%20Boeing%20Postdoctoral%20Research%20Fellow,%20School%20of%20ITEE,%20ARC%20Centre%20for%20Complex%20Systems
1- 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,
- grunske_at_itee.uq.edu.au
-
2Agenda
- Problem description/context
- Preliminaries
- Behavior Trees
- 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
- Industrial Metal Press
- Conclusion
3Motivation
- 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
4Preliminaries
5Behavior 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) 2-13 - GSE Genetic Software Engineering
http//www.sqi.gu.edu.au/gse
6Behavior Tree Syntax (1)
- Basic Syntax Elements
- Reversion, Synchronisation
7Behavior Tree Syntax (2)
- Control flow in Behavior Trees
8Generation 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)
104-113
9Automated Hazard Analysis
- An Automated Failure Mode and Effect Analysis
based on High-Level Design Specification with
Behavior Trees
10Procedure 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
11Generation 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
Fault View BT
Original BT
12Translating 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
13Identification 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 (SAFECOMP2001). 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 21st International
Conference on Software Engineering, Los Angeles,
May 1999.
14Model 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)
15Case Study
16Industrial Metal Press
- Source McDermid, J., Kelly, T. Industrial
press Safety case. Technical report, High
Integrity Systems Engineering Group, University
of York (1996)
17Industrial Metal PressBehaviour 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 (PoNR)
18Design Behavior Tree Industrial Metal Press
(complete and small ?)
19Safety Requirements (Negated Hazard Conditions)
- HC1. 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)) - HC2. If the plunger is falling below the PONR,
known as falling fast, the motor should remain
off. - G ((plunger fallingfast) ? (motor off ))
- HC3. 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))
- HC4. The motor should never turn off while the
plunger is rising. - G (? (plunger risingbelowPONR ? plunger
risingabovePONR)? (motor off )))
20Results
HC1. If the plunger is at the top and the
operator is not pushing the button, the motor
should remain on. HC2. If the plunger is falling
below the PONR, known as falling fast, the motor
should remain off. HC3. 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. HC4. The motor should never turn off while
the plunger is rising.
21Tool Support BTE BTFail
http//www.sqi.gu.edu.au/gse/tools/
22Open 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)
23Conclusion
- Contribution
- Automation of FMEA
- Automatic Fault Injection Model Checking
- Benefits
- Tool support that automates the tedious and
error-prone aspects of FMEA - Systematic and integrated approach for safety
analysis - Thanks!
- Questions?