available recently.

The table covers the three steps specific to FTA (Steps 3-5 Figure
3.3). Roberts et al. (1981) and Bari et al. (1985) provide a more extensive list of FTA
computer codes suitable for mainframe application.
Computer codes are available that will draw trees, given the input logic. Fault trees
can also be drawn using readily available personal computer graphics packages.
3.2.2. Event Tree Analysis
3.2.2.1. BACKGROUND
Purpose. An event tree is a graphical logic model that identifies and quantifies possible
outcomes following an initiating event. The event tree provides systematic coverage of
the time sequence of event propagation, either through a series of protective system
actions, normal plant functions, and operator interventions (a preincident application),
or where loss of containment has occurred, through the range of consequences possible
(a postincident application). Consequences can be direct (e.g., fires, explosions) or
indirect (e.g., domino incidents on adjacent plants.)
Technology. Event tree structure is the same as that used in decision tree analysis
(Brown et al., 1974). Each event following the initiating event is conditional on the
occurrence of its precursor event. Outcomes of each precursor event are most often
binary (SUCCESS or FAILURE, YES or NO), but can also include multiple outcomes (e.g., 100%, 20%, or 0% closure of a control valve).
Applications. Event trees have found widespread applications in risk analyses for both
the nuclear and chemical industries. Two distinct applications can be identified. The
preincident application examines the systems in place that would prevent incident-precursors from developing into incidents. The event tree analysis of such a
system is often sufficient for the purposes of estimating the safety of the system. The
postincident application is used to identify incident outcomes. The event tree analysis
can be sufficient for this application. Studies such as the Reactor Safety Study (Rasmussen, 1975), have used preincident event trees to demonstrate the effectiveness of successive levels of protective systems. Some CPI risk assessments (Health and Safety
Executive, 1981; World Bank, 1985) use postincident event trees. Protective systems
are also investigated this way. Arendt (1986a) demonstrates the use of event trees to
investigate hazards from a heater start-up sequence. Human reliability analysis uses
event tree techniques (see Section 3.3.2).
3.2.2.2. DESCRIPTION
Description of Technique. Preincident event trees can be used to evaluate the effectiveness of a multielement protective system. A postincident event tree can be used to
identify and evaluate quantitatively the various incident outcomes (e.g., flash fire,
UVCE, BLEVE dispersal) that might arise from a single release of hazardous material
(Figure 2.1). Figure 3.8 (from EFCE, 1985) demonstrates these two uses in a chemical
plant context. A preincident example is loss of coolant in an exothermic reactor subject
to runaway. A postincident example is release of a flammable material at a point (X)
and incident outcomes at a downwind location (T). In fact, the two uses are comple-

PRE-ACClDENT EVENTTREE
COOLANTFLOW
ALARM WORKING
B

REACTORTEMP.
ALARM WORKING
C

REACTORDUMP
VALVE WORKING
D

SEQUENCE
DESCRIPTION
1 SAFE SHUTDOWN
2 RUNAWAY REACTION
3 SAFE SHUTDOWN

REACTOR
COOLANT
FAILURE
A

4 RUNAWAY REACTION
5 SAFE SHUTDOWN
6 RUNAWAY REACTION
7 RUNAWAY REACTION
8 RUNAWAY REACTION

POST-ACCIDENT EVENT TREE

IGNITION
ATX
B

WIND
TOY
C

IGNITION
ATY
D

EXPLOSION
ONIGNITION
E

SEQUENCE
DESCRIPTION
1 EXPLOSION AT X
2 FIRE AT X

FLAMMABLE
RELEASE
ATX
A

3 EXPLOSION AT Y
4 FIRE AT Y
5 DISPERSES
6 DISPERSES

FIGURE 3.8. Examples of preincident and postincident event trees. From EFCE (1985).
mentary: the postincident event tree can be appended to those branches of the
preincident event tree that result in FAILURE of the safety system. Good descriptions
of preincident event trees are given in HEP Guidelines (AIChE/CCPS, 1985) and the
PRA Procedures Guide (NUREG, 1983).
Fault trees are often used to model the branching from a node of an event tree.
Also, the top event of a fault tree may be the initiating event of an event tree. By computing the frequency of the top event of a fault tree, the corresponding branching or
initiating event frequency can also be estimated. Note the difference in meaning of the
term initiating event between the applications of fault tree and event tree analysis. A

fault tree may have many initiating events that lead to the single top event, but an event
tree will have only one initiating event that leads to many possible outcomes.
The construction of an event tree is sequential, and like fault tree analysis, is
top-down (left-right in the usual event tree convention). The construction begins with
the initiating event, and the temporal sequences of occurrence of all relevant safety
functions or events are entered. Each branch of the event tree represents a separate outcome (event sequence). The sequence is shown in the logic diagram (Figure 3.9).

STEP1
Identify the
initiating event

STEP 2
Identify safety
function/hazard and
determine outcomes

STEP 3
Construct event tree
to all important outcomes

STEP 4
Classify the outcomes
in categories of
similar consequence

STEPS
Estimate probability
of each branch in
the event tree

STEP 6
Quantify the
outcomes

STEP 7
Test the outcomes

FIGURE 3.9. Logic diagram for event tree analysis.

Step 1. Identify the Initiating Event. The initiating event, in many CPQRAs, is a failure event corresponding to a release of hazardous material. This failure event will have
been identified by one of the methods discussed in Chapter 1 and in more detail in HEP
Guidelines (AIChE/CCPS, 1985). The initiating event might correspond to a pipe leak,
a vessel rupture, an internal explosion, etc. The frequency of this incident is estimated
from the historical record (Section 3.1) or by FTA (Section 3f2.1).
The event tree is used to trace the initiating event through its various hazardous
consequences. It will be simplest for incidents that have few possible outcomes (e.g.,
toxic releases or internal explosions). Releases that are both flammable and toxic may
have many possible outcomes.
Step 2. Identify Safety Function/Hazard Promoting Factor and Determine Outcomes. A
safety function is a device, action, or barrier, that can interrupt the sequence from an
initiating event to a hazardous outcome. A hazard promoting factor may change the
final outcome (e.g., from a dispersing cloud to a flash fire or to a VCE). It is most often
used in postincident analysis.
Safety functions can be of many types, most of which can be characterized as
having outcomes of either success or failure on demand. Some examples are
automatic safety systems
alarms to alert operators
barriers or containment to limit the effect of an accident.
Hazard promoting factors are more varied and include
ignitions or no ignition of release
explosion or flash fire
liquid spill contained in dike or not
daytime or nighttime
meteorological conditions.
A heading is used to label a safety function or hazard promoting factor. Most of the
above branches are binary choices. Meteorological conditions may be represented by
ranges of wind speeds, atmospheric stabilities, and wind directions.
The analyst must be careful to list all those headings that could materially affect the
outcome of the initiating event. These headings must be in chronological order of
impact on the system. Thus, headings, such as multiple ignition sources, may appear
more than once in the event tree depending on what is happening in time.
Step 3. Construct the Event Tree. The event tree graphically displays the chronological progression of an incident. Starting with the initiating event, the event tree is constructed (conventionally) left to right. At each heading or node, two or more
alternatives are analyzed (Step 2) until a final outcome is obtained for each node. Only
nodes that materially affect the outcome should be shown explicitly in the event tree.
Some branches may be more fully developed than others. In a preincident analysis, the
final sequence might correspond to successful termination of some initiating event or a
specific failure mode. The listing of the safe recovery and incident conditions is an
important output of this analysis. For a postincident analysis, the final results might

correspond to the type of incident outcome (e.g., BLEVE, UVCE, flash fire; safe
dispersal).
The event headings should be indicated at the top of the page, over the appropriate
branch of the event tree. It is usual to have SUCCESS or YES branch upward and
FAILURE or NO branch downward. Starting with the initiating event, many analysts
label each heading with a letter identifier. Every final event sequence can then be specified with a unique letter combination (Figure 3.6). A bar over the letter indicates that
the designated event did not occur.
Step 4. Classify the Outcomes. The objective in constructing the event tree is to identify important possible outcomes that have a bearing on the CPQRA. Thus, if an estimate of the risk of offsite fatalities is the goal of the analysis, only outcomes relevant to
that outcome (offsite fatalities) need be developed. Branches leading to lesser consequences can be left undeveloped. Where outcomes are of significance, it is often adequate to stop at the incident itself (e.g., explosion, large drifting toxic vapor cloud).
The subsequent risk analysis calculation (Section 4.4) will consider individual influencing factors (e.g., wind direction or atmospheric stability) on possible consequences
(Figure 1.2).
Many outcomes developed through different branches of the event tree will be
similar (e.g., an explosion may arise from more than one sequence of events). The final
event tree outcomes can be classified according to type of consequence model that must
be employed to complete the analysis.
Step 5. Estimate the Probability of Each Branch in the Event Tree. Each heading in the
event tree (other than the initiating event) corresponds to a conditional probability of
some outcome if the preceding event has occurred. Thus, the probabilities associated
with each branch must sum to 1.0 for each heading. This is true for either binary or
multiple outcomes from a node.
The source of conditional probability data may be the historical record (Section
5.1), plant and process data (Section 5.2), chemical data (Section 5.3), environmental
data (Section 5.4), equipment reliability data (Section 5.5), human reliability data
(Section 5.6), and use of expert opinion (Section 5.7). It may be necessary to use fault
tree techniques to determine some probabilities, especially for complex safety systems
encountered in preincident analyses.
Step 6. Quantify the Outcomes. The frequency of each outcome may be determined
by multiplying the initiating event frequency with the conditional probabilities along
each path leading to that outcome. As a check, the sum of all the outcome frequencies
must sum to the initiating event frequency. The above calculation assumes no dependency among event, or partial success or failure. Either of these conditions complicates
the numerical treatment beyond the scope of this book.
Step 7. Test the Outcomes. As with fault trees, poor event tree analysis can lead to
results that are inaccurate (e.g., due to poor data) or incorrect (e.g., important
branches have been omitted). An important step in the analysis is to test the results
with common sense and against the historical record. This is best done by an independent reviewer.

Theoretical Foundation. Event trees are pictorial representations of logic models or

truth tables. Their theoretical foundation is based on logic theory. Further discussions
are given in Henley and Kumamoto (1981) and Lees (1980). The frequency of an outcome is defined as the product of the initiating event frequency and all succeeding conditional event probabilities leading to that outcome.
Input Requirements and Availability. Analysts require a complete understanding of
the system under consideration and of the mechanisms that lead to all the hazardous
outcomes. This may be in the form of a time sequence of instructions, control actions,
or in the sequence of physical events that lead to hazardous consequences (e.g., the
spreading characteristics of a dense vapor cloud).
The starting point in event tree analysis is the specification of the initiating event.
This event may be identified using other CPQRA techniques such as HAZOP, the historical record, or experience. The quantitative evaluation of the event tree requires conditional probabilities at every node. As discussed earlier, these may be based on
reliability data, the historical record, experience, or from fault tree modeling.
Output. The output of event tree modeling can be either qualitative or quantitative.
The qualitative output shows the number of outcomes that result in success versus failure of the protective system in a preincident application. The qualitative output from a
postincident analysis is the number of more hazardous outcomes versus less hazardous
ones. It highlights failure routes for which no protective system can intervene (single-point failures). The quantitative output is the frequency of each event outcome.
These outputs (which might specify BLEVE, flash fire, or VCE frequencies) are
employed directly in CPQEA risk calculations.
Simplified Approaches. The event tree technique is a relatively simple approach.
However, it can be used in various levels of detail. The level to use for a particular task
can be selected based on the importance of the event or the amount of information
available.
3.2.2.3. SAMPLE PROBLEM
The sample problem is a postincident analysis of a large leakage of pressurized flammable material from an isolated LPG storage tank. An engineering analysis of the problem
indicates that the potential consequences include BLEVE of the tank if the leak is
ignited (either immediately or by flashback). If the leak does not immediately ignite, it
can drift toward a populated area with several ignition sources and explode (VCE), or
produce a flash fire. Other downwind areas have a lower probability of ignition. The
data relevant to the event tree are given in Table 3.5.
Using Table 3.5, an event tree is developed to predict possible outcomes from the
leakage of LPG. This event tree is not exhaustive. Not every outcome is developed to
completion; some events are terminated at entry points to specific consequence
models. For example, three outcomes are possible from BLEVEs [thermal impact,
physical overpressure, and fragments (Section 2.2.3)]. In practice, these outcomes
would be investigated separately in the BLEVE consequence model calculation.

TABLE 3.5. Sample Event Tree Input Data

Frequency or
probability*
(x KFVyr.)

Event

A. Large leakage of pressurized LPG

Source of data"

-O

Fault tree analysis

B. Immediate ignition at tank

0.1

Expert opinion

C. Wind blowing toward populated area

0.15

Wind rose data

D. Delayed ignition near populated area

0.9

Expert opinion

0.5

Historical data

0.2

Tank layout geometry

E. VCE rather than

flash

fire

F. Jet flame strikes the LPG tank

* These data are for illustrative purposes only.

The event tree for the LPG leak initiating event is given in Figure 3.10. From this,
a total of six outcomes are predicted. These outcomes and their predicted frequencies
are given in Table 3.6.
The total frequency of all outcomes is a check to ensure that this equals the initiating event frequency of 1 X 10""4 per year (i.e., 100.0 X 10"6 per year).

3.2.2.4, DISCUSSION
Strengths and Weaknesses. An important strength of the event tree is that it portrays
the event outcomes in a systematic, logical, self-documenting form that is easily
audited by others.
The logical and arithmetic computations are simple and the format is usually compact. Preincident event trees highlight the value and potential weaknesses of protective
systems, especially indicating outcomes that lead directly to failures with no intervening protective measures. Postincident event trees highlight the range of outcomes that
are possible from a given incident, including domino incidents, thereby ensuring that
important potential consequences are not overlooked.
The event tree assumes all events to be independent, with any outcome conditional
only on the preceding outcome branch. Every node of an event tree doubles the
number of outcomes (binary logic) and increases the complexity of classification and
combination of frequency. From a practical standpoint this limits the number of headings that can be reasonably handled to 7 or 8.
Identification and Treatment of Possible Errors. If multiple fault trees are used to
establish the frequencies of various nodes or decision points, common cause failures or
mutually exclusive events can arise that invalidate event tree logic. These problems arise
if the same basic event appears in the fault trees that are used to establish the probabilities of branching at the various event tree nodes. For example, an electrical power failure basic event may appear in several fault trees that support an event tree. Failure by
the risk analyst to recognize and deal with the commonality of the electrical power failure basic event will result in serious errors. Omission of outcomes can lead to serious

Large
LPG
Leakage
A

Immediate
ignition
B

Wind to
Populated
area
C

Delayed
ignition
O

UVCE
or
Rash Fire
E

Ignited jet
points at
LPG tank
F
Outcome

No (0.1)
FIGURE 3.10. Event tree outcomes for sample problem.

Frequency

BLEVE

ABF

axlO^/year

Local Thermal hazard

ABF

SxlO^/year

VCE

ABODE

6.1 x lO^/year

Flashfireand BLEVE

ABCDEF

1.2x10~*/year

Flash fire

ABCDEF

4.9 x lO^/year

Safe dispersal

ABCD

LAxlO^/year

VCE

ABCDE

39.5x10-6/year

Flash fire and BLEVE

ABCDEF

6.9 x lO^/year

Flash fire

ABCDEF

27.5x10^/year

Safe dispersal

ABCD

7.6x10"*/year

TOTAL

1 x 1(T4 /year

TABLE 3.6. Sample Event Tree Outcomes and Frequencies

Outcome

Sequences leading to
outcome

Frequency (per year)

2.0 x IQ-* = 2.0 x IQ-6

BLEVE

ABF

Flash Fire

ABCDEF + ABCDEF

4.9 x 1(T* + 27.5 x HT 6 = 32.4 x 10"6

Flash fire and BLEVE

ABCDEF +ABCDEF

1.2 x IQ-6 + 6.9 x HT 6 = 8.1 x 10^

UVCE

ABCDE + ABCDE

Local thermal hazard

ABF

Safe dispersal

ABCD +ABCD

6.1 x 1(T6 + 34.5 x 10^= 40.5 x ICT6

8.0 x 1(T6 = 8.0 x ICT6
1.4 x IQ-* + 7.6 x ID"6 = 9.0 x 1(T6

Total all outcomes

= 100 x IQ-6

error (e.g., domino effect on nearby equipment). Independent review of final event
trees is the best method to identify such faults (Step 7, Figure 3.9).
Errors can arise in the conditional probability data leading to major errors in the
predicted final outcome frequencies. The analyst should document sources of data
employed to allow for subsequent checking.
Utility. Event trees are a straightforward technique to use. They are a graphical form of
a logic table and are easier to understand by nonspecialists than fault trees. Provided the
assumptions of no dependency and total success and failure are met, the calculations are
easy. They are useful for both preincident and postincident analyses, and are especially
helpful in the analysis of sequential systems or in human error problems.
Resources Needed. Except for unusually complicated problems, event trees tend not
to require significant resources. Because protective system designs tend to be very complex (Section 6.2), postincident analyses tend to be easier to apply than preincident
analyses.
Computer Codes Available.
ETA II, Science Applications International Corp., 5150 El Camino Real, Los Altos,
CA 94022
RISKMAN, Pickard, Lowe and Garrick, Newport Beach, CA
SUPER, Westinghouse Risk Management, P.O. Box 355, Pittsburgh, PA 15230.

3.3. Complementary Plant-Modeling Techniques

The previous section (3.2) discusses the analysis of fault trees and event trees, by using
frequency and probability data. For ease of presentation in that section, some factors
that influence the quality of the analysis were deferred. In this section (3.3) we discuss
common-cause failure analysis (3.3.1), human reliability analysis (3.3.2), and external
Next page