An Automated Failure Mode and Effect Analysis based on High-Level Design Specification with Behavior...

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

1

An Automated Failure Mode and Effect Analysis based on High-Level Design Specification with Behavior TreesLars Grunske, Peter Lindsay, Nisansala Yatapanage, Kirsten Winter

ARC Centre for Complex SystemsSchool of Information Technology and Electrical Engineering,

University of Queensland, Brisbane, QLD 4072,[email protected]


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

A[ a ]

B?? b ??

C?? c ??

D[ d ]

E[ e ]

A[ a ]

B?? b ??

D[ d ]

Fault View BTOriginal 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)

http://sal.csl.sri.com/




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)

Top sensor

PoNR sensor

Bottom sensor

PLC

Button

Plunger

Drive chain

Motor

Clutches

Guard


17

Top sensor

PoNR sensor

Bottom sensor

PLC

Button

Plunger

Drive chain

Motor

Clutches

Guard

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

Component Failure HC1 HC2 HC3 HC4 No failures Top stuck Low Top stuck High X Bottom stuck Low Bottom stuck High X PONR stuck Low X PONR stuck High X Button stuck released Button stuck pushed X X Motor stuck on Motor stuck off

Key: = hazard condition does not arise; X = hazard condition can occur.

ResultsHC1. 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?

An Automated Failure Mode and Effect Analysis based on High-Level Design Specification with Behavior...

Documents

Transcript of An Automated Failure Mode and Effect Analysis based on High-Level Design Specification with Behavior...