Dr.%20rer.%20nat.%20Lars%20Grunske,%20Boeing%20Postdoctoral%20Research%20Fellow,%20School%20of%20ITEE,%20ARC%20Centre%20for%20Complex%20Systems - PowerPoint PPT Presentation

About This Presentation
Title:

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

Description:

School of Information Technology and Electrical Engineering, ... Automotive electronics, aviation, industrial process control and medical applications ... – PowerPoint PPT presentation

Number of Views:91
Avg rating:3.0/5.0
Slides: 24
Provided by: larsgr
Category:

less

Transcript and Presenter's Notes

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

2
Agenda
  • 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

3
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

4
Preliminaries
5
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) 2-13
  • GSE Genetic Software Engineering
    http//www.sqi.gu.edu.au/gse

6
Behavior Tree Syntax (1)
  • Basic Syntax Elements
  • Reversion, Synchronisation



7
Behavior Tree Syntax (2)
  • Control flow in Behavior Trees

8
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)
    104-113

9
Automated Hazard Analysis
  • An Automated Failure Mode and Effect Analysis
    based on High-Level Design Specification with
    Behavior Trees

10
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

11
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

Fault View BT
Original BT
12
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

13
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 (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.

14
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)

15
Case Study
  • Industrial Metal Press

16
Industrial Metal Press
  • Source McDermid, J., Kelly, T. Industrial
    press Safety case. Technical report, High
    Integrity Systems Engineering Group, University
    of York (1996)

17
Industrial 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)

18
Design Behavior Tree Industrial Metal Press
(complete and small ?)
19
Safety 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 )))

20
Results
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.
21
Tool Support BTE BTFail
http//www.sqi.gu.edu.au/gse/tools/
22
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)

23
Conclusion
  • 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?
Write a Comment
User Comments (0)
About PowerShow.com