Event Tree vs Fault Tree: Two Ways to Count Fire Risk

A fault tree asks how a fire can happen. An event tree asks what happens once it does. One walks backward from disaster to root causes. The other walks forward from a spark to outcomes. Both methods initially grew out of cold-war missile and reactor work. Both now sit at the core of fire risk assessment. Yet engineers still reach for the wrong one. Worse, many use only one, and the risk picture goes blurry. So this post works through the logic of each method. Then it adds the algebra, and a warehouse example where the two meet.

TL;DR

• A fault tree reasons backward, from one bad outcome to its causes. An event tree reasons forward instead.
• Fault trees run on Boolean gates. Minimal cut sets then expose single points of failure.
• Event trees multiply conditional branch probabilities. Every path must sum back to the trigger frequency.
• Sprinkler studies put system reliability near 90–98%. Shut valves alone drive about 61% of failures.
• The warehouse below gives 5 × 10⁻⁴ major losses per year. Its event tree splits that into three end states.
• Worst of them: a fatal path near 2 × 10⁻⁶ per year. Dropping the independence assumption lifts it by 58%.
• A bow-tie bolts both halves onto one central event. It now anchors UK COMAH and Seveso III safety cases.

What is a fault tree?

A fault tree maps every combination of failures that can produce one undesired top event. H. A. Watson built the first one at Bell Telephone Laboratories in 1962. An Air Force contract paid for it, and the Minuteman I launch system supplied the problem. Dave Haasl at Boeing saw the wider value a year later. He then carried the method into commercial aircraft design.

Two handbooks still define practice. The US Nuclear Regulatory Commission published NUREG-0492 in 1981. NASA followed with its own aerospace handbook in 2002. Today the formal international standard carries the number IEC 61025.

The method runs deductively, from the top down. First, you name one undesired top event. Major warehouse fire loss works. So does sprinkler fails on demand. Next, you ask what immediate causes could produce it. Then you wire those causes together through Boolean gates. Finally, you repeat the question downward until you hit basic events: a dead pump, a closed valve, a skipped inspection.

In short, three gates carry most of the load. An AND gate fires only when every input occurs together, so it models redundancy. But an OR gate fires when any single input occurs. It therefore models a chain with no spare. A priority-AND gate adds order, and fires only when its inputs occur in sequence. Finally, voting and inhibit gates handle the rest.

How do you quantify a fault tree?

You push basic-event probabilities upward through the gates, one level at a time. An AND gate over independent inputs simply multiplies.

$P_{\text{AND}} = \prod_{i=1}^{n} p_i$

An OR gate needs more care. Summing its inputs would double-count the overlaps, so the exact form takes the complement of everyone succeeding.

$P_{\text{OR}} = 1 - \prod_{i=1}^{n}(1 - p_i)$

For small probabilities, though, a shortcut works well.

$P_{\text{OR}} \approx \sum_{i=1}^{n} p_i$

That shortcut carries the name rare-event approximation. It always errs high, but for small numbers it errs high by very little. Take five failure modes of 0.5%, 2%, 1%, 1% and 0.5%. The exact form gives 4.91%, and the shortcut gives 5.00%. So the error runs to 1.9%, and engineers happily trade that sliver of conservatism for arithmetic they can check by hand.

Still, the qualitative output matters just as much as the number. Boolean reduction turns the tree into a set of minimal cut sets. Each cut set names the smallest group of basic events that alone can trigger the top event. Their probabilities then sum to an upper bound.

$P_{\text{top}} \le \sum_{k} \prod_{i \in C_k} p_i$

A cut set of size one flags a single point of failure. So no amount of redundancy elsewhere buys it back.

Next, ranking falls out of the Fussell–Vesely importance. It measures the share of top-event probability that runs through basic event $i$.

$I^{FV}_i = \frac{P_{\text{top}} - P_{\text{top}}\big|_{p_i = 0}}{P_{\text{top}}}$

Set one component to perfect, then watch how far the top event drops. That drop gives its importance directly, and maintenance budgets follow the ranking.

What is an event tree?

An event tree traces every outcome that can follow one initiating event, branch by branch. The technique first crystallised in the 1975 Reactor Safety Study. MIT’s Norman Rasmussen led it for the US Atomic Energy Commission. His team enumerated roughly 130,000 candidate accident sequences. They cut those down to some 650 meaningful ones, and reported a core-melt frequency near one per 20,000 reactor-years.

That study married the two methods for the first time. First, fault trees supplied the failure probability of each safety system. The event tree then strung those systems into sequences. Modern probabilistic risk assessment still runs on the pairing, as the NRC’s PRA tutorial explains. The formal standard carries the number IEC 62502. It also appears as technique B.5.6 in ISO 31010.

Where a fault tree reasons backward, an event tree reasons forward. You start on the left with an initiating event. An ignition, a pipe rupture, or a loss of containment all qualify. Then you walk rightward through pivotal events. Each pivot names a safety barrier or a human action, and most branches split in two. Success runs above, while failure runs below.

Also, every branch carries a conditional probability. Multiply along one path, then scale by the initiating-event frequency $f_I$.

$f_j = f_I \prod_{i=1}^{n} p_{ij}$

That product gives the frequency of one specific end state. A tree with $n$ binary pivots therefore holds up to $2^n$ paths. Because success and failure exhaust each branch, the paths must also add back up.

$\sum_{j} f_j = f_I$

That identity hands you a free completeness check. It catches most arithmetic slips before a reviewer does.

How do fault trees and event trees differ?

Direction, above all. One method reasons from effect to cause. The other reasons from cause to effect. Everything else follows from that single choice.

Dimension	Fault tree	Event tree
Direction	Backward	Forward
Starts at	Top event	Trigger
Logic	AND/OR gates	Branch odds
Output	Cut sets	End states
Answers	Why?	What next?
Best use	Causes	Consequences
Weak spot	No timing	Needs a trigger

A fault tree works like a logic diagnostic. An event tree works like a timeline. For instance, take a fire pump. The fault tree tells you the pump dies if either the motor or the power supply dies. The event tree asks a different question. Once the pump has died, does the backup spin up within ninety seconds?

Fires demand both framings, because a fire counts as two things at once. It counts as an outcome nobody prevented. It also counts as a process that unfolds over minutes. So most serious fire studies carry both diagrams.

Where do fire engineers use each method?

Fault trees dominate reliability work on fire protection systems. For example, sprinklers offer the clearest case. Moinuddin and Thomas built fault trees for Australian high-rises and shopping centres. Their models landed on 90–98% system reliability. According to NFPA’s operational statistics, field performance sits nearer 88–92%. Shut valves and lapsed maintenance explain most of the gap.

One number from that data set deserves its own line in every tree. A closed water supply accounts for roughly 61% of sprinkler failures. As a single-event cut set, it dwarfs every clever redundancy in the pump room. It also explains why sprinkler design mistakes so often trace back to operations rather than hydraulics.

Meanwhile, event trees dominate the consequence side. The canonical fire application carries the name Detection-Suppression Event Tree. NRC and EPRI defined it in NUREG/CR-6850, the methodology behind NFPA 805. Given an ignition, that tree walks through automatic detection, fixed suppression, brigade response, and barrier performance.

Its key output takes an unusual form. Suppression behaves like a Poisson process, so the chance that nobody has put the fire out decays with time.

$P_{ns}(t) = e^{-\lambda t}$

Here $\lambda$ gives the suppression rate for that fire type, fitted to incident data. Meanwhile $t$ counts the minutes available before damage. So the event tree hands the analyst a curve rather than a constant. Every extra minute of detection lead time then shows up directly in the answer.

The same forward logic drives process-industry work. LPG release trees in the CCPS chemical process QRA guidelines branch on immediate ignition, then delayed ignition, then congestion. Their end states name the classic outcomes: jet fire, flash fire, pool fire, vapour-cloud explosion, or safe dispersion.

What is a bow-tie diagram?

A bow-tie fuses a fault tree and an event tree onto one central event. Imperial Chemical Industries presented the idea in a 1979 hazard-analysis course at the University of Queensland. Royal Dutch Shell then institutionalised it across the group after Piper Alpha in 1988.

The layout explains the name. A top event sits at the knot, say loss of flammable containment. On the left, a simplified fault tree fans out into threats. Preventive barriers cross each of those paths. On the right, a simplified event tree fans out into consequences, with mitigative barriers across every branch.

That picture now serves as the standard visual of major-hazard safety cases. UK COMAH and Seveso III both expect it. Buncefield in 2005 and Texas City became textbook bow-tie studies. Both showed a row of barriers collapsing one after another, rather than a single dramatic failure.

The bow-tie also does managerial work that neither parent diagram does well. Each barrier gets an owner, a performance standard, and a degradation control. So the diagram doubles as a live register of safety-critical elements.

A worked example: a sprinklered warehouse

Consider a distribution warehouse storing Class III commodities. A wet-pipe sprinkler system protects it. Historical data give an ignition frequency of 1 × 10⁻² per year, or one fire per century of operation. Both methods now take that same warehouse as input.

The fault tree half

Define the top event as major warehouse fire loss. A top AND gate combines ignition with sprinkler failure on demand, since neither alone produces the loss. The sprinkler sub-tree then runs as an OR over five independent failure modes.

Basic event	Probability
Fire pump fails to start	2.0%
Main control valve closed	1.0%
Head activation failure	1.0%
City main unavailable	0.5%
Low discharge pressure	0.5%

Add them up. The rare-event sum gives 5.0% sprinkler failure on demand, against 4.91% by the exact product form. Multiply through the top AND gate, and the loss frequency follows.

$f_{\text{top}} = 10^{-2} \times 0.05 = 5 \times 10^{-4}\ \text{yr}^{-1}$

That equals one major loss every 2,000 warehouse-years. Because the top gate sits above a pure OR, every minimal cut set has size two. Fussell–Vesely importance then ranks them cleanly.

Minimal cut set	Frequency (per year)	Importance
Ignition + pump fails	2.0 × 10⁻⁴	40%
Ignition + valve closed	1.0 × 10⁻⁴	20%
Ignition + head fails	1.0 × 10⁻⁴	20%
Ignition + no city main	5.0 × 10⁻⁵	10%
Ignition + low pressure	5.0 × 10⁻⁵	10%

Read the top row twice. The pump alone carries 40% of the risk, so a weekly churn test buys more here than a second riser ever would.

The event tree half

Now take the same ignition as the initiating event. Three pivotal events follow. Sprinkler control succeeds 95% of the time, brigade intervention 80%, and complete evacuation 98%. Only failed branches develop further, which keeps the tree small.

End state	Path	Probability	Frequency (per year)
Minor fire, sprinklers hold	S	0.9500	9.5 × 10⁻³
Brigade save after failure	S̄B	0.0400	4.0 × 10⁻⁴
Major fire, all escape	S̄B̄E	0.0098	9.8 × 10⁻⁵
Catastrophic fire, fatalities	S̄B̄Ē	0.0002	2.0 × 10⁻⁶

Two checks pass immediately. The probabilities sum to exactly 1.0000. The frequencies sum to exactly 1.0 × 10⁻² per year, so no path went missing.

Notice also where the two methods touch. The last three rows sum to 5.0 × 10⁻⁴ per year. That reproduces the fault-tree answer exactly. In short, the fault tree gave the trunk, and the event tree split that trunk into branches of wildly different severity.

Only the forward method exposes the tail. A catastrophic frequency near 2 × 10⁻⁶ per year sits just above the UK HSE’s broadly acceptable line of 1 × 10⁻⁶ per year. So this warehouse cannot claim safety by assertion. It owes a demonstration that the risk falls as low as reasonably practicable. A societal risk check follows too, if many people work under that roof.

What happens when the branches are not independent?

The tail grows, usually by more than anyone guesses. Multiplying branch probabilities quietly assumes each pivotal event stands alone. Yet real barriers share power supplies, instrument air, control panels, inspection crews, and the same distracted night shift.

Add detection as a fourth pivotal event, and the coupling shows up. Automatic detection succeeds 95% of the time. Sprinklers work on heat, so they hold their 95% either way. However, a failed detector delays the alarm. Brigade success then drops from 80% to 50%, and evacuation from 98% to 90%.

End state	Detection works	Detection fails	Total
Minor fire	9.03 × 10⁻³	4.75 × 10⁻⁴	9.50 × 10⁻³
Brigade save	3.80 × 10⁻⁴	1.25 × 10⁻⁵	3.93 × 10⁻⁴
Major fire	9.31 × 10⁻⁵	1.13 × 10⁻⁵	1.04 × 10⁻⁴
Catastrophic	1.90 × 10⁻⁶	1.25 × 10⁻⁶	3.15 × 10⁻⁶

Read the bottom row carefully. The fatal path climbs from 2.0 × 10⁻⁶ to 3.2 × 10⁻⁶ per year. That marks a rise of 58%, even though the detector fails only one time in twenty. Nearly 40% of the remaining fatal risk now hides in a branch carrying 5% of the ignitions.

Fault trees suffer the same problem from the other side. Analysts patch it with a beta-factor model. A share $\beta$ of a component’s failures moves into a common cause that takes down every redundant train at once.

$Q_{CCF} = \beta\, Q_{\text{total}}$

Typical $\beta$ values run from 1% to 10%. Redundancy therefore stops paying long before independent arithmetic suggests. A duplicated pump on a shared power feed buys far less than the numbers promise.

Which method should you pick?

Match the method to the question. Reach for a fault tree when the question sounds causal. Reach for an event tree when it sounds consequential. Use a bow-tie when it sounds like both.

• Pick a fault tree to interrogate one bad outcome: a suppression failure, an egress failure. It also fits design work under IEC 61508, and reliability budgets for redundant equipment.
• Pick an event tree to watch a trigger travel through barriers. It prices detection, suppression, and evacuation layers separately, and quantitative risk assessment consumes exactly those end-state frequencies.
• Pick a bow-tie when regulators expect a whole risk picture. COMAH, Seveso III, and the quantitative tier of NFPA 551 all ask for one.

The SFPE Guide to Fire Risk Assessment embeds this choice in its framework. So does the fire safety concepts tree in NFPA 550, and PD 7974-7 in the UK. None of them treats the two methods as rivals.

Where do both methods break down?

At the edges of their own assumptions, and both edges show up in fire work. A classical fault tree stays static and binary. Every component sits either failed or working. Nothing degrades gradually, and repair never appears unless the analyst forces it in by hand.

Dugan (1992) attacked that limit with dynamic fault trees. Priority-AND, sequence-enforcing, and spare gates let the model tell one failure order from another. On the event tree side, the branch-independence problem never fully goes away. Writing conditional probabilities for every combination defeats the purpose of the diagram.

A deeper fix maps the whole structure onto probability theory. Bobbio and colleagues showed in 2001 that any fault tree converts directly into a Bayesian network. That move unlocks multi-state components, dependent failures, and Bayesian updating from field data. Classical gates express none of the three.

Software carries most of the load now. RiskSpectrum dominates nuclear PSA, and SAPHIRE serves NRC and NASA work. EPRI’s CAFTA handles the very large trees behind NFPA 805 fire studies. On the consequence side, DNV Phast and Safeti drive most oil and gas QRA. BowTieXP has become the reference tool for bow-ties, while open-source options such as SCRAM cover smaller jobs.

The most interesting movement couples probability to physics. Dynamic PRA frameworks sample uncertain parameters, then run a deterministic simulation for each sample. Fire versions now link NIST’s Fire Dynamics Simulator to fault-tree engines. So a branch probability can come from a computed heat release rate and a real smoke layer, rather than a table lookup. Performance-based design keeps drifting toward exactly that coupling.

Taking home

Fault trees and event trees answer different questions. Choosing between them usually means answering only half of yours. The fault tree works like a microscope aimed at causes. The event tree works like a camera tracking consequences. A bow-tie then forces both conversations to meet over one central event.

The warehouse shows why the pairing matters. The fault tree gave one clean number, 5 × 10⁻⁴ major losses per year. It also named the fire pump as the worst offender, at 40% importance. Then the event tree took that identical number apart. Inside it sat a 2 × 10⁻⁶ per year fatal path, riding on a single pivotal event. Dropping the independence assumption pushed that path 58% higher still.

Neither diagram produces that insight alone. No amount of care inside one method substitutes for the other. So build the fault tree to find what breaks. Build the event tree to find what follows. Then read the two together before signing anything.

For the ignition side of this story, see the science of fire. For the bench data behind these probabilities, see cone calorimeter 101.

Cite this article

Dinh, D. C. (2026, April 18). Event Tree vs Fault Tree: Two Ways to Count Fire Risk (Updated July 25, 2026). PyroRisk. https://pyrorisk.net/blog/event-tree-vs-fault-tree/

Get citation →

---