Event Tree Analysis

Dr K Venkadeshwaran
ETA and FTA
 Event tree analysis (ETA)
• An event tree analysis (ETA) is an inductive
procedure that shows all possible outcomes
resulting from an accidental (initiating) event, taking
into account whether installed safety barriers are
functioning or not, and additional events and
factors.
• Design and procedural weaknesses can be
identified, and probabilities of the various outcomes
from an accidental event can be determined.
 ETA
• This is a complimentary technique to FTA but
defines the consequential events which flow
from the primary ‘initiating’ event. Event trees
are used to investigate the consequences of
loss-making events in order to find ways of
mitigating, rather than preventing, losses.
ETA generic Example
ETA - Example
FTA- Fire example
 Main Steps
• Identify (and define) a relevant accidental (initial) event
that may give rise to unwanted consequences
• Identify the barriers that are designed to deal with the
accidental event
• Construct the event tree
• Describe the (potential) resulting accident sequences
• Determine the frequency of the accidental event and the
(conditional) probabilities of the branches in the event
tree
• Calculate the probabilities/frequencies for the identified
consequences (outcomes)
• Compile and present the results from the analysis
 stages
• Accidental event
• Barriers
• Event sequence
• Outcome alternatives
• End outcomes
• Decision making
 Accidental Event
• When defining an accident event, we should answer the
following questions:
– What type of event is it? (e.g., leak, fire)
– Where does the event take place? (e.g., in the control room)
– When does the event occur? (e.g., during normal operation,
during maintenance)
• An accidental event may be caused by:
– System or equipment failure
– Human error
– Process upset
• For each accidental event we should identify:
– The potential accident progression(s)
– System dependencies
– Conditional system responses
 Barriers
• Most well designed systems have one or more
barriers that are implemented to stop or reduce
the consequences of potential accidental events.
• The probability that an accidental event will lead
to unwanted consequences will therefore depend
on whether these barriers are functioning or not.
• Barriers are also called safety functions or
protection layers, and may be technical and/or
administrative (organizational).
 Barriers
• The barriers that are relevant for a specific
accidental event should be listed in the sequence
they will be activated.
• Examples include:
• Automatic detection systems (e.g., fire detection)
• Automatic safety systems (e.g., fire extinguishing)
• Alarms warning personnel/operators
• Procedures and operator actions
• Mitigating barriers
 Event sequence
• Each barrier should be described by a (negative) statement,
e.g., “Barrier X does not function” (This means that barrier X is
not able to performs its required function(s) when the specified
accidental event occurs in the specified context).
• Additional events and factors should also be described by
(worst case) statements, e.g., gas is ignited, wind blows toward
dwelling area
 Outcome alternatives
• In most applications only two alternatives
(“true” and “false”) are considered. It is,
however, possible to have three or more
alternatives, as shown in the example below:
 End outcomes
• In practice, many event trees are ended before the
“final” consequences are reached
• Including these “final” consequences may give very
large event trees that are impractical for visualization
• This is solved by establishing a consequence
distribution for each end event and the probability of
each consequence is determined for each end event
• In effect, this is an extension of the event tree, but it
gives a more elegant and simpler presentation and also
eases the summary of the end results
 Calculations

The diagram shows an initiating event (e.g. fire) and the subsequent operation or failure of three
systems (e.g. fire suppression) which would normally operate should the event occur. Each system
can either operate or not (somewhat unrealistic, as in some cases, things may partially operate).
Because of the multitude of combinations of success/failure of each system, there are multiple
possible final outcomes (labelled a to h in the diagram). The diagram also illustrates the way event
trees can be quantified. The initiating event is typically specified as an expected annual frequency
(e.g. 2 times per year) and the success/failure for each system as a probability.
 Calculations
• To calculate the frequency of each final outcome (labelled a to h in the
diagram), you multiply along the branches, travelling from left to right
from initiating event to final outcome.
• Thus, from the diagram, the frequency of the initiating event happening
AND systems 1 AND 2 AND 3 working properly is I x S1 x S2 x S3.
• • The sum of each success/failure probability pair, at each specific node
adds up to 1. So, for example, S1 + F1 = 1. This means that if you are
only given the value for success probability of a particular system, it is
easy to calculate the failure probability for that same system, because
the two will add up to give 1.
• • The sum of all the final outcome frequencies (for each outcome a to
h) will add up to equal the frequency of the initiating event (it’s bound
to if you think about it).
 Calculations

in situations where the failure of system 1 means that systems 2 and 3 will not stop
a ‘failure’ outcome, there’s no point in further branching along the failure branch of
system 1. So, in the diagram, if the only real outcome that matters for things not to
go out of control is for systems 1, 2 and 3 all to work properly (success), then
everything else leads to uncontrolled consequences (to different degrees). Taking
this approach, the above diagram can be drastically ‘pruned’, but the same
calculation rules already outlined above apply
 Calculations

The only outcome resulting in control of the event is where the sensor, valve and
water spray operate
Notice also that the sum of all the outcome frequencies adds up to 2 in this case, i.e.
the frequency of the initiating event (the conveyer belt fire).
The event tree could be used to check that there were adequate fire detection,
warning and extinguishing systems.
 Results in decision-making
• The results from the event tree analysis may
be used to:
• Judge the acceptability of the system
• Identify improvement opportunities
• Make recommendations for improvements
• Justify allocation of resources for
improvements
 Pros and cons
• Visualize event chains following an accidental event
• Visualize barriers and sequence of activation
• Good basis for evaluating the need for new / improved
procedures and safety functions
CONS
• No standard for the graphical representation of the event tree
• Only one initiating event can be studied in each analysis
• Easy to overlook subtle system dependencies
• Not well suited for handling common cause failures in the
quantitative analyses
• The event tree does not show acts of omission