System Safety - M9 Fault Tree Analysis (FTA) V1 · PDF fileSystem Safety M9 Fault Tree Analysis (FTA) V1.1 Matthew Squair UNSW@Canberra 13 May 2015 1 Matthew Squair M9 Fault Tree Analysis

System SafetyM9 Fault Tree Analysis (FTA) V1.1

Matthew Squair

UNSW@Canberra

13 May 2015

1 Matthew Squair M9 Fault Tree Analysis (FTA) V1.1

Except for images whose sources are specifically identified, this copyright work islicensed under a Creative Commons Attribution-Noncommercial, No-derivatives 4.0International licence.

To view a copy of this licence, visit http://creativecommons.org/licenses/by-nc-nd/4.0/


1 Introduction

2 Overview

3 Methodology

4 The future of Fault Trees

5 Limitations, advantages and disadvantages

6 Conclusions

7 Further reading


Introduction

1 Introduction

2 Overview

3 Methodology



6 Conclusions

7 Further reading


Introduction

Learning outcomes

The student will be able to appropriately apply the FTA method as part ofa hazard analysis

The student will understand the strengths and weaknesses of the method


Overview

1 Introduction

2 Overview

3 Methodology



6 Conclusions

7 Further reading


Overview

Overview

“Perform an analysis only to reach a decision. Do not perform ananalysis if that decision can be reached without it. It is not e↵ectiveto do so. It is a waste of resources.”

— Dr. V.L. Grose, GWU


Overview

Basic concepts

Fault Tree Analysis (FTA) translates the failure behavior of a system intoa:

logical model, and a

visual diagram (not a tree (in the graph-theoretic sense))

FTA is a deduction analysis technique working from a top level event(TLE) to a set of component states & events that cause it

Based on

Deductive argument (known outcome, unknown cause)

Top down (major event to specific factors)

Boolean Algebra, Probability and Set Theory

Reliability Theory (for quantitative assessments of failure)


Overview

Outcomes of the analysis

Produces

Graphic display of chain of events

Identification of critical contributors

Identified unsafe part behaviour

Improved understanding of system

Qualitative/quantitative insight into probability of the TLE

Identification of resources committed to preventing failure

Guidance for deploying resources to optimise control of risk

Supports SSHA & SHA activities, can also be used (in qualitative form)during concept design


Overview

Key definitions

Cut set is any group of fault tree initiators which, if all occur, will causethetop event to occur

A Cut set, minimal is a least group of fault tree initiators which, if alloccur, will cause the top event to occur

Fault, failure Definitions as per module one

Primary (basic) failure. The failed element has seen no exposure toenvironmental or service stresses exceeding its ratings to perform. E.g.,fatigue failure of a relay spring within its rated lifetime; leakage of a valveseal within its pressure rating


Overview

Key definitions (cont’d)

Secondary failure. Failure induced by exposure of the failed element toenvironmental and/or service stresses exceeding its intended ratings. E.g.,the failed element has been improperly designed, or selected, or installed,or calibrated for the application; the failed element isoverstressed/underqualified for its burden

Single point failure. A failure of one independent element of a systemwhich causes an immediate system level failure


Overview

Logic symbols (Events and Gates)

Events and Gates are not component parts of the system being analysed,they are symbols representing the logic of the analysis

They are bi-modal and function flawlessly

Over the years the number of symbols has evolved, however in practice youonly need seven basic symbols


Overview

Logic symbols (cont’d)


Overview

Key assumptions

Classical FTA is based on some key assumptions (& limitations)

A non repairable system (static snapshot)

No sabotage

Markovian (constant f/r and future is independent of past)

Bernoulli (we use two mutually exclusive states)

We can improve our model fidelity, for example by using Markovian chainsto model repair processes, but this adds complexity

Model fidelity versus truthfulness

The degree to which additional model complexity is needed is inferredfrom the degree of accuracy required for the answer.


Overview

Fault tree analysis and the system lifecycle


Methodology

1 Introduction

2 Overview

3 Methodology



6 Conclusions

7 Further reading


Methodology

Methodology

1 Scope the analysis

2 Identify undesirable TLE and define it

3 Identify first level contributors to top event

4 Link contributors to TLE by logic gates

5 Identify second level contributors

6 Link contributors to TLE by logic gates

7 Repeat 5 and 6 until end (leaf) events are obtained

8 Analyse tree for qualitative and quantitative properties

9 Document analysis

A tree generally starts with ’state of system’ contributors and ends up with’state of component’ contributors


Methodology

Basic steps in constructing the fault tree


Methodology Defining the scope of the analysis

Scope the analysis

Common analysis scoping (sometimes called ground rules) include:

Model at the highest level for which data exists and there are nocommon HW interfaces across contributors

Do not model passive components (e.g wiring or piping)

Do model CCF for identical redundant components

Do not model out of design conditions

Do not model human errors of commission

Do not continue to model AND gates with n >3 inputsif there are triple, double or single contributors elsewhereand there are no common hardware interfaces to the inputs

Do not model OR gate input if Px n POR



Defining the Top Level Event (TLE)

Carefully defining the TLE reduces the amount of e↵ort required byconfining the analysis to relevant issues

To ’scope’ is defining the level of loss at which the event becomesunacceptable, usually through applying modifiers to the basic eventdescription

Remember the clarity test

To define L we need O to be well specified such that people could, inprincipal, agree as to whether it has/has not occurred. A ’fuzzy’ definitionof O, will result in fuzziness in the estimate of L



Defining the Top Level Event (cont’d)

Too broad

Example

Fuel leak

Better definition

Example

Fuel leak causes a potentially explosive build up of propellant

Better still

Example

Fuel leak su�cient to cause a potentially explosive build up of propellant(20 ppm) in the APU module while the system is shutdown for a nominal5 day mission period


Methodology General rules and conventions

General rules of construction

FTA is a very stylised analysis, this makes checking the logic easier

Use single stem inputs to gates

Don’t let a gate feed a gate, always have an intermediateevent/condition

Standardise names throughout the analysis

Numerically number each gate and event in large trees

Say what failed and how ”Relay R-32 contacts failed closed”

No miracle ’saviour’ events

Validate your model before you present it

Initiators must be independent (at the gate), immediate, necessary,consistent and complete



The I2NC2 rule for selecting initiating events

Fault trees must be logically rigorous

Logical rules for event selection and definition

Initiators must be Immediate, Independent (at that gate), Necessary,Complete & Consistent

What’s wrong with the following example?



The I2NC2 rule for selecting initiating events (cont’d)

Figure: Source: [Clements 1993]

Inconsistent naming leads to ambiguity and loss of independence



The I2NC2 rule for selecting initiating events (cont’d)


Inconsistent naming leads to ambiguity and loss of independence



State of component technique

Can be applied usefully when the analysis is at the device level

Figure: Image source: [Clements 1993]



Example fault tree for electrically driven pump



Modelling modes

How do we deal with a system when it passes through various phases ormodes? With di↵erent modes or phases

base event probabilities may change

success criteria and TLEs may change

system configuration may change

Example

A re-usable space vehicle might have storage, launch, separation, on-orbitcheckout, transfer, operations & recovery modes. In each mode di↵erentfunctions are required and therefore criticality of failure will vary by phaseor mode



Modelling modes (cont’d)

If for each phase there are distinct basic event probabilities but no logicchanges

break out each basic event into individual mode events under an ANDgate

Alternatively handle it in the quantification stage such thatprobability of failure in phase also includes probability of non-failure inprevious phases

If the logic changes we need to have mode specific legs of the FT

Event trees and Fault trees

If there is a complex mission phase sequence, the use of an event tree tostructure it may assist the analysis



Modelling modes (Cont’d)

Figure: NASA Space shuttle FT for APU failure (Source: NASA)



Modelling control loops and feedback

If not careful recursive modeling of feedback loops can occur

Figure: Feedback loops ([NASA OSMA 2002])

Only include the failures of individual components due to internal causes,not due to any feedback from the associated component, this breaks theloop



Modelling common cause

Overlooking common cause is a common flaw in faut trees, when you seeridiculous TLE probabilities, the analyst may have overlooked commoncause failure

Two methods of modeling CCF

For simple systems put common causes at the top of the tree

For complex systems with several redundant component sets associatethe CCF with that redundant component set using an OR gate

Consider both system dependencies (common power, services) ANDmore general CCF via the � factor or similar parameter

We can use cut set analysis techniques to identify sources of CCF



Modelling common cause (cont’d)

Figure: CCF modelled as associated event to redundant components



Modelling human error

Modelling human error is di�cult, some guidance:

Generally try to include it in equipment � failure rate

Model separately if it causes mis-configuration of a component

Include explicitly if it can cause �2 failures of components

If in doubt, model it and make it a base event

Model errors of omission as base events causing failures

Modelling errors of commission is v.di�cult & usually not done

If important for detection & recovery model errors explicitly

Analyse cut sets for human error vulnerability


Methodology Qualitative analysis

Qualitative analysis

Cut set and component importance by order number

Analysis of the cut set for

unexpected initiator combinations

single point failures

common cause vulnerabilities

Requires the set of minimal cut sets



Cut sets

Qualitative analysis of FTs can give us insight into system vulnerabilities,common causess and the structural importance of parts of the FT andindividual initiators. To do so we make use of Cut Sets

Cut sets and Minimal cut sets

A Cut set is any group of fault tree initiators which, if all occur, will causethetop event to occurA Minimal cut set is a least group of fault tree initiators which, if alloccur, will cause the top event to occur

Cut sets are also useful in evaluating quantitative cut set importance &initiator importance



Generating cut sets

1 Ignore all tree elements except the initiator events

2 Below the top event assign a letter to each gate & a number to eachinitiator

3 Stepwise from the top event gate down create a matrix:The top event gate is the first matrix entryReplace each AND gate letter by letters/numbers of inputs in thehorizontalReplace each OR gate letter by letters/numbers of inputs in the verticalEach new OR row must contain all other entries in parent row

4 A final numbers only matrix is the result (Rows are Cut Sets)

5 Eliminate any row that contains all of a lesser row & any redundantrow elements (Rows are Minimal Cut Sets)



Example: Generating cuts sets

Assign unique letters togates, and initiators

If initiators appear more thanonce, use the same number

Construct the matrix, startingwith A



Example: Generating cuts sets (cont’d)




Example: Cut set tree equivalence

These minimal cut sets are an equivalent fault tree to the original

Note that sometimes these equivalent trees are not necessarily animprovement.



Example: Fault trees to reliability block diagrams

Reliability block diagrams represent the success paths through the system,minimal cut sets can be thought of as ’cutting’ the path



Cut set importance measures

We can use cut sets to qualitatively evaluate the importance of variousaspects of the FT

The less the number of initiatiors in a cut set the more important it is(only one then it’s a single point failure)

Components can be ranked in importance in the number of times thatthey appear in cut sets

If the set of cut sets is deep, the system is more vulnerable



Cut set and common mode failures

We can use cut sets to identify common cause vulnerability

We inspect each of the minimum cut sets for vulnerability to commoncause e↵ects, such as high temperature from a fire in a shared equipmentzone

If all initiators are vulnerable then we can introduce this ’cut set killer’under the top level event gate (which will now be an OR gate)


Methodology Quantitative analysis

Quantitative analysis

Numerical calculation of PT

Compute FT probabilities for the Minimum cut sets

Compute FT importance measures from the cut sets

Requires failure rates and exposure intervals (reliability data)



Calculating PT with cut sets

Min cut sets can be used to calculate PT quite simply. From the example

PT ⇡X

Pk

⇡ (P1 ⇥ P2) + · · ·+ (P1 ⇥ P4) (1)

Correct calculation of PT

Min cut sets eliminate duplicated initiators, if we leave these values in thetree when we calculate PT, the result will be erroneously conservative



Calculating cut set quantitative importance

The quantitative importance of a cut set is the probability that, if a topevent occurs, that cut set induced it

Ik =Pk

PT...Quantitative importance (2)

From the example for the min cut set (1,3)

PK =X

Pe = P1 ⇥ P3

Calculation of IkQuantitative importance allows us to quantitatively rank the contributionsto system failure and deploy resources e↵ectively



Calculating initiator quantitative importance

The quantitative importance of an initiator is the probability that, if a topevent occurs, that initiator contributed to it

Ie ⇡NeX

Ike ...Quantitative importance (3)

From the example for the initiator event 2

I2 =(P1 ⇥ P2) + (P2 ⇥ P3)

PT

Calculation of IeQuantitative importance allows us to numerically rank the contributions tosystem failure and deploy resources e↵ectively



Relationship of PF to <

Let S denote Success, and F denote Failure

< =S

S + F...Reliability (4)

PF =F

S + F...Failure probability (5)

) <+ PF =F

S + F+

S

S + F(6)

= 1

Where

� = Failure rate =1

MTBF(7)



The bathtub curve

The bathtub model assumes that components have fault rates (�=1/MTBF) that are constant (�0) over long periods of useful life, failuresare independent and random (a memoryless process)

Figure: The bathtub model (and assumptions)



The exponential model of failure

Fault probability is modeled acceptably well as a function of exposureinterval (T) by the exponential function

For a brief exposure (T<0.2 MTBF), PF ⇡ �T to within 2%




Propagating PF through gates

Using boolean logic and set theory we can combine the probabilities ofindividual events via ’OR’ and ’AND’ logic gates




Exact OR gate solutions using the q function

The q is the IP function which is the cofunction of ⇧, it provides an exactsolution for OR gates, but usually we can get by using the rare event

approximation

PT = qPe = 1� ⇧(1� Pe) (8)

= 1� [(1� P1)(1� P2) . . . (1� Pn)]

The rare event approximation

For PA,B 0.2 we can use PA,B ⇡ PA + PB with an error of 11%



Probability data sources

The logic may be impeccable (perhaps) but the quantitative analysis isonly as good as the probability data. Sources for such data include

Manufacturers warranty period

Industry standards

MIl-HDBK-217

Field history of equivalent systems

Expert ’estimation’, which can be quite unreliable

ERDA log average method



Typical component failure rates

Component failures per 106 operating hours [Hammer 1972]

Device Min Average Max

semiconductor diodes 0.1 1 10Transistors 0.1 3.0 12.0Microwave diodes 3.0 10.0 22.0MIL-R-11 resistors 0.0035 0.0048 0.016Rotary electric motor 29 41 80Connectors 0.01 0.1 10



Typical human error rates

Human eror is highly context sensitive, so tables of ’typical’ error ratesshould be taken with a grain of salt, perhaps a large one...

Human error per event [NRC 1975], [NRC 1980]

Activity Error rate

Error of omission/item embedded in procedure 3 X 10�3

Simple arithmetic error with self-checking 3 X 10�2

Inspector error of operator oversight 10�1

General rate/high stress/ dangerous activity 0.2-0.3Checko↵ provision improperly used 0.1-0.09 (0.5 avg.)Error of omission/10-item checko↵ list 0.0001-0.005 (0.001 avg.)Carry out plant policy/no check on operator 0.005-0.05 (0.01 avg.)Select wrong control/group of identical, 0.001-0.01 (0.003 avg.)labeled, controls



The ERDA log-average method [Briscoe 1982]

If probability is unavailable, but upper and lower credible bounds can beestimated

1 Estimate upper and lower credible bounds of probability

2 Average the logarithms of the upper and lower bounds

Geometrical mean of probability

The antilogarithm of the average of the logarithms of the upper and lowerbounds is less than the upper bound and greater than the lower bound bythe same factor. Thus, it is geometrically midway between the limits ofestimation

Geometrical means are less sensitive to outliers in a population of data,e.g. very high values


Methodology Model validation

Model validation

Having developed the model, we need to validate it

Review your scoping assumptions, still valid?

Look at the tree, and then think about what we might have omitted

Review failure data sources for plausible events and check for inclusion

If there is uncertainty in quantitative data, perform an uncertaintyanalysis (e.g. Monte Carlo or Hypercubes)

If we are concerned about a specific base event (e) and it’s influence,perform a sensitivity analysis

If �Pe/�PT ' 0.1 then the TLE probability is considered sensitive toPT


Methodology Model validation

Model validation (cont’d)

Generate a success path for the FT and check that it really is one

Generate cut sets (at lower levels) and validate their success/cut paths

Check the probability of the TLE, does it seem reasonable?

Check base event probabilities, do they seem reasonable?

Check the intermediate (fault) events, do their numbers seemreasonable?


Methodology Managing the analysis

How far should a fault tree grow?

In theory we should drive the analysis only to the point where we canassign probability data with confidence or qualitatively evaluate a cut-setof ’state of component’ base events

In practice, we may decide to go deeper to ensure we haven’t overlooked acommon cause of failure (such as a shared power circuit breaker for tworedundant flight computers)

The objective is insight, not ’fault tree lantana’


The future of Fault Trees

1 Introduction

2 Overview

3 Methodology



6 Conclusions

7 Further reading



Dynamic Fault Trees Analysis (DFTA)

DFTA is a term used to refer to analysis of a system which dynamicallyresponds to a stimulus [NASA OSMA 2002]

High levels of redundancy

Spares (hot, warm, cold)

Software and software fault tolerance

Imperfect fault coverage

Functional and sequence dependencies

All of these add complexity, which classical FTA finds di�cult to handle



Example: After a primary failure switch to secondary

Figure: Example source: NASA FTA notes



DFTA (cont’d)

DFTA integrates Markovian ’chain’ models into fault trees to allow us tomodel these dynamic processess [Dugan 1992]

Modular approach with dynamic modules used as necessary

Tree is broken up into independent subtrees, these are solved as traditionalfault trees or via Markov chain models

Aproach allows for complex redundant and dynamically reconfiguredsystems to be modelled (e.g many modern mission or safety criticalsystems)



Example: HECS modular DFTA model

Figure: Example source: [Dugan 1992]


Limitations, advantages and disadvantages

1 Introduction

2 Overview

3 Methodology



6 Conclusions

7 Further reading



Limitations of the method

Limitations of the method are

Undesirable end events must be foreseen and are only analysed singly

All significant contributors to fault/failure must be anticipated

Bernoulli process model

Initiators at a given analysis level must be independent of each other

Events/conditions at any analysis level must be true, immediatecontributors to next-level events/conditions

Each Initiator failure rate must be a predictable constant



Advantages

Advantages of the method are:

Quantifying system failure probability

Assessing system CCF vulnerability

Optimising resource deployment to control vulnerability

Guiding system reconfiguration to reduce vulnerability

Identifying potential SPOF

Supporting trade studies with di↵erential analyses

A good technique to use for Systems Hazard Analysis (SHA) activities



Disadvantages

Disadvantages of the technique are:

if there are multiple TLEs the analysis scope is considerable

Does not handle forward time sequence oriented searches well

Each fault/failure initiator must be constrained to two conditionalmodes

Requires considerable system knowledge but also requires significantknowledge of the technique (a rare combination)

As a strongly visual technique, it can blind one to what has beenomitted


Conclusions

1 Introduction

2 Overview

3 Methodology



6 Conclusions

7 Further reading


Conclusions

Conclusions

Consider using FTA to investigate the causal factors for a small set of highconsequence top level events

Where there are many possible TLE or possible successful outcomesconsider using another technique, such as FMEA/FMECA

If you develop a model you are required to validate it

Any statement of probability of a top level event must be accompanied bya statement of the uncertainty


Further reading

Bibliography

[Briscoe 1982] Briscoe, Glen J. (1982) Risk Management Guide, System SafetyDevelopment Center, SSDC-11, DOE 76-45/11, September 1982.

[Clements 1993] Clements, P., (1993) Fault Tree Analysis, 4th Ed., Sverdrup.

[Dugan 1992] Dugan, J.B., Salvatore J. Bavuso, S.J., (1992) and Mark A. Boyd,Dynamic fault tree models for fault tolerant computer systems, IEEE Transactionson Reliability, Volume 41, Number 3, pages 363-377, September 1992.

[Hammer 1972] Hammer, W., (1972) Handbook of system and product safety, Publ.Prentice Hall.

[NASA OSMA 2002] NASA (2002) Fault Tree Handbook with AerospaceApplications,O�ce of Safety and Mission Assurance (OSMA), V1.1.

[NRC 1975] Nuclear Regulator Commission (NRC) (1975), WASH-1400(NUREG-75/014),Reactor Safety Study An Assessment of Accident Risks in U.S.Commercial Nuclear Power Plants, 1975.

[NRC 1980] Nuclear Regulator Commission (NRC) (1980), NUREG/CR-1278,Handbook of Human Reliability Analysis with Emphasis on Nuclear Power PlantApplications, 1980.


Documents

System Safety - M9 Fault Tree Analysis (FTA) V1 · PDF fileSystem Safety M9 Fault Tree Analysis (FTA) V1.1 Matthew Squair UNSW@Canberra 13 May 2015 1 Matthew Squair M9 Fault Tree Analysis