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 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@itee.uq.edu.au

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 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

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 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

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 4

Preliminaries

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 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

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 6

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 7

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

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 9

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

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 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

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 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

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 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.

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 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)

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 15

Case Study

Industrial Metal Press

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 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

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 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)

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 18

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

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 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.

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.

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 21

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

Dr. rer. nat. Lars Grunske, Boeing Postdoctoral Research Fellow, School of

ITEE, ARC Centre for Complex Systems 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?