Fault Tree Analysis: Building and Quantifying a Fault Tree from First Principles

Most failure analysis starts with a component and asks what it could do wrong. Fault tree analysis starts at the other end: it names one specific event that must never happen, and works backwards to every combination of faults that could cause it. That single change of direction, from asking what could go wrong with a component to asking what would have to happen for a specific consequence to occur, is what makes fault tree analysis the right instrument for the failures that matter most and occur least often.

This series has already built the four functions that describe failure behaviour, the Weibull family that models it, and the block diagrams that compose component reliability into system reliability. Fault tree analysis takes the same components and asks a different question of them, reasoning downward from an undesired consequence rather than upward from a success path. This page builds a tree from first principles, reduces it to its minimal cut sets by hand, and carries one original scenario through to a quantified, ranked answer.

A tree is only as good as the discipline behind its construction, and the discipline is not complicated once the rules are explicit. This page states them as numbered steps, gives the exact arithmetic behind every gate, and shows why the minimal cut sets, not the diagram itself, are the actual output an engineer acts on.

The Top Event Decides Everything

Get the top event wrong and every hour spent on the tree beneath it is wasted, because the tree can only ever be as precise as the question it was built to answer.

A top event is the one specific undesired outcome the analysis exists to explain. It must be a fault, meaning it must state precisely what condition is wrong and under what circumstances that condition counts as a fault (NUREG-0492). "Pump failure" is not a usable top event because it never says what the pump was doing, what consequence follows, or which fault is meant. "Vessel overflows to atmosphere while the vessel is in normal charging service" is usable, because a reader can point to the exact moment the event has or has not occurred. Pitched too broadly, a top event produces a tree too large to ever finish; pitched too narrowly, it produces one too small to capture the insight the analysis was commissioned to find. Getting this one statement right is the highest-leverage step in the method, and the one most often rushed.

Once the top event is fixed, everything beneath it is generated by asking one question repeatedly: what is the immediate, necessary and sufficient cause of the event directly above it. Answering that question correctly, one level at a time, is the entire construction method.

Building the Tree One Level at a Time

A fault tree is built downward by immediate cause, never by intuition about the eventual basic failures, and the difference between the two habits is the difference between a tree that is auditable and one that only looks like it is.

Every event on a tree is either a state-of-component fault, meaning it can consist of a component failure, or a state-of-system fault, meaning it cannot and instead needs whatever gate captures its own minimum necessary and sufficient cause (NUREG-0492). Four event types carry their own symbols beneath the fault logic itself: a basic event is a component failure taken as given and not developed further; an intermediate event sits below a gate awaiting further development; an undeveloped event is deliberately left unexpanded because its consequence is minor, its data is unavailable, or it sits outside the declared scope; and a house event represents a condition expected to occur normally, used to switch part of the logic on or off rather than to represent a fault.

1. 1

   State the top event as a fault, specifying precisely what is wrong and under what system condition that state counts as a fault.

   A fault statement without a "when" cannot be evaluated, because the same physical state can be normal in one condition and a fault in another.

2. 2

   Ask only for the immediate, necessary and sufficient cause of the event above, never skip ahead to a cause you suspect lies further down.

   Skipping a level risks silently dropping an alternate path to the same fault, because an intermediate cause you never stated cannot be checked for completeness.

3. 3

   Classify each new event as state-of-component or state-of-system, and choose the gate that represents its minimum necessary and sufficient cause.

   A state-of-component fault opens onto primary, secondary and command causes through an OR gate; a state-of-system fault needs whatever gate actually reflects how its inputs combine, and guessing the wrong gate here is the single most common tree-construction error.

4. 4

   Complete every input to a gate before developing any single one of those inputs further.

   Developing one branch to its basic events before its siblings are even stated invites an incomplete, lopsided tree that looks finished long before it is.

5. 5

   Insert a properly defined fault event between any two gates; never connect a gate directly to another gate.

   A gate-to-gate shortcut usually means the analyst has skipped stating what the intermediate fault actually is, and that missing statement is exactly what a reviewer needs to check the logic.

6. 6

   Assume a component functions normally unless its normal function is what the fault sequence needs defeated, in which case model the faults required to defeat it explicitly.

   This is the "no miracles" rule: a fault sequence should never be blocked in the model by the unexplained, miraculous failure of some other unrelated component.

7. 7

   Stop developing a branch at the declared limit of resolution, and record why each undeveloped event was not taken further.

   Every tree has a resolution limit; the discipline is not in avoiding one but in choosing it deliberately and being able to defend the choice later.

The Arithmetic Two Gates Actually Need

Every fault tree, however large, reduces to only two pieces of arithmetic: direct applications of the probability rules governing any two-outcome event.

An OR gate's output occurs if at least one of its inputs occurs, which makes it a union. For independent inputs the exact probability is one minus the probability that none of them occur:

Take the demand side of this page's worked scenario: an inlet control valve failing open, probability 0.02, or a discharge pump failing to run, probability 0.05, either one leaving the vessel with no controlled way to shed an uncontrolled inflow. P(OR) = 1 − (1 − 0.02)(1 − 0.05) = 1 − (0.98)(0.95) = 0.0690, a 6.90% chance that this demand condition exists at all. When every input probability is small, a shortcut holds: the exact union is closely approximated by simple addition, P(OR gate) ≈ Σpᵢ, and the approximation is always conservative, reading slightly high rather than low, to within roughly 10% at input probabilities under 0.1 (NUREG-0492). This rare event approximation is what makes hand quantification of a real tree practical, and it is used again shortly at the level of whole minimal cut sets.

An AND gate's output occurs only when every input occurs together, which makes it an intersection. For independent inputs the exact probability is the plain product:

Independence is doing real work in both formulas, worth naming where it can fail: two valves from the same manufacturing batch, two instruments on a shared power supply, or two tasks performed by the same technician on the same day are not independent, and a tree that quietly assumes they are will understate the true top event probability.

Minimal Cut Sets: The Real Output of the Analysis

The diagram is not the deliverable. A cut set is any combination of basic events whose joint occurrence causes the top event; a minimal cut set is one that contains no event that could be removed while the top event is still guaranteed (NUREG-0492). The minimal cut sets, not the tree drawing, are what an engineer reads, reports and acts on.

Finding them is a mechanical exercise once the tree is written as one Boolean equation per gate. Starting either at the top event and substituting downward, or at the basic events and substituting upward, every gate equation is expanded by the distributive law and reduced by the law of absorption until only combinations of basic events remain (NUREG-0492). Both directions land on the same minimal cut sets, because the minimal cut sets are a property of the tree's logic, not of the direction it was reduced from; the top-down route was later automated as the MOCUS algorithm and the bottom-up route as MICSUP, each performing exactly this manual Boolean reduction by computer.

The size of a minimal cut set, its order, is itself a ranking before a single probability is calculated. A single-component minimal cut set is a single point of failure: one component failure alone defeats the entire system, and that finding needs no arithmetic to justify acting on it. A double-component cut set requires two specific, simultaneous failures, already a materially rarer event; a triple-component cut set rarer again. Listing the minimal cut sets from smallest to largest is therefore a legitimate first-pass importance ranking, well before a single input probability has been looked up, and it is often enough by itself to tell a design review where the redundancy actually is and where it only appears to be.

An Original Fault Tree, Built and Quantified End to End

Building the Tree

Consider a process vessel with a level protection layer, general enough to describe a mining process tank, an oil and gas separator, or a petrochemical reactor. The top event is "vessel overflows to atmosphere while in normal charging service."

Overflow occurs one of two structurally different ways. Either a single bypass valve around the protection layer fails open or is left open (basic event B0, probability 0.0012), which alone leaves the vessel one failure from atmosphere, or a demand for protection arises at the same time the protection layer itself fails to respond. The demand, gate G1, is an OR of the inlet control valve failing open (D1, 0.02) or the discharge pump failing to run (D2, 0.05). The protection failure, gate G2, is an OR of the sensing and logic path failing, itself gate G3, an OR of the level transmitter failing to detect the high level (B1, 0.01) or the logic solver failing to execute the trip (B2, 0.004), or the shutdown valve failing to close on demand (B4, 0.02). The top event is T = B0 + (G1 · G2).

Finding the Minimal Cut Sets

Writing every gate as a Boolean equation and reducing bottom-up, G3 = B1 + B2 is already minimal. G2 = G3 + B4 becomes B1 + B2 + B4, three single-component terms once substituted. G1 = D1 + D2 is already minimal. The compound term G1 · G2 then expands by the distributive law into six double-component terms: D1·B1, D1·B2, D1·B4, D2·B1, D2·B2, D2·B4. Adding the standalone B0 term gives the top event in full minimal cut set form, seven minimal cut sets in total: one single-component set and six double-component sets. No further reduction is possible, because no term is a superset of another.

Quantifying the Top Event and Ranking the Findings

Each double-component cut set's probability is the AND-gate product of its two members. B4·D2, the largest, is 0.02 × 0.05 = 1.0 × 10⁻³. The full set, ranked from largest to smallest: B0 at 1.2 × 10⁻³, B4·D2 at 1.0 × 10⁻³, B1·D2 at 5.0 × 10⁻⁴, B4·D1 at 4.0 × 10⁻⁴, B1·D1 and B2·D2 tied at 2.0 × 10⁻⁴, and B2·D1 at 8.0 × 10⁻⁵.

Summing all seven under the rare event approximation gives a top event probability of 3.58 × 10⁻³ over the stated assessment period. Composing the same tree exactly, gate by gate (P(G1) = 6.90 × 10⁻², P(G2) = 3.368 × 10⁻², their product 2.324 × 10⁻³, combined with B0 through the top-level OR), gives 3.521 × 10⁻³, confirmed independently by enumerating all 64 combinations of the six basic events. The rare event approximation reads 1.7% high here, comfortably inside its usual accuracy band and conservative in exactly the direction that favours caution. Gate-by-gate composition landed on the exact answer here for a specific reason: no basic event appears in more than one branch of this tree. Where a component is genuinely shared across branches that shortcut breaks down, and the minimal cut set method, which handles repetition correctly by construction, is the one to trust.

Ranking each cut set's share of the total tells the more useful story. B0 alone accounts for 33.5% of total top event probability, more than any double-component cut set, despite its own probability being smaller than either individual demand-side basic event. That is the single-point-of-failure finding stated earlier, now confirmed rather than merely asserted: an unmitigated single failure can dominate total risk even in raw arithmetic terms, and the fix, removing or interlocking that bypass path, is obvious the moment the cut set list is read, before any double-component cut set is even considered. Ranking by component instead of by cut set tells a second, complementary story: the discharge pump (D2) contributes to 47.5% of total probability across three cut sets, the shutdown valve (B4) to 39.1%, each a stronger case for engineering or maintenance attention than its standalone probability would suggest, because each appears in more than one path to the same top event.

Two Views of the Same System: Fault Trees and Reliability Block Diagrams

A fault tree and a reliability block diagram are not two different tools for two different problems; they are the same system described from opposite directions, and the arithmetic proves it.

Writing both gate formulas next to the series and parallel reliability formulas already established earlier in this series makes the equivalence exact rather than approximate:

An OR gate is the failure-side description of a series structure, because with no redundancy any single component failing is enough to cause the fault, exactly what an OR gate expresses. An AND gate is the failure-side description of a parallel, redundant structure, because full redundancy is only defeated once every path has failed, exactly what an AND gate expresses. The mapping runs opposite to the first guess most engineers make: OR corresponds to series, not parallel, and AND corresponds to parallel, not series, because a fault tree reasons in failure logic while a block diagram reasons in success logic (MIL-HDBK-338B 1998).

The formal version of this idea is the dual tree: complementing every event and swapping every AND for an OR and every OR for an AND turns a fault tree into the tree of its own minimal path sets, the smallest combinations of non-occurrences that guarantee the top event does not occur (NUREG-0492). A reliability block diagram and a fault tree of the same system are, in this sense, duals of each other, and an engineer fluent in both can move between them at will rather than treat one as a translation of the other.

Where Fault Tree Analysis Earns Its Place

Fault tree analysis and FMECA are not competing methods that happen to overlap; they reason in opposite directions on purpose, and a mature programme runs both.

FMECA starts at a component and a specific failure mode, then works forward to ask what effect that mode has at the next level up the equipment hierarchy (IEC 60812:2018). Fault tree analysis starts at a consequence and works backward to ask what combination of causes could produce it. The two meet in the middle rather than compete: a fault tree's basic events are exactly the failure modes an FMECA has already catalogued for the same equipment, and a fault tree that turns up a single-component cut set an FMECA missed is a direct finding for that FMECA to absorb, not a contradiction between the two methods.

Fault tree analysis earns its cost specifically where the combination logic is not obvious from a system drawing and the consequence is severe enough to justify the analytical effort: loss of containment, a safety function failing on demand, a process excursion with few independent layers of protection standing between a routine deviation and an unacceptable outcome. It is not the right tool for routine, low-consequence failure modes best handled by an FMECA line item and a maintenance task, and using it there mostly produces an expensively documented version of what a component list already showed.

Return to where this page started: a vague top event guarantees a wasted tree, and a precise one, built one immediate cause at a time, reduced to its minimal cut sets and quantified honestly, turns "what could cause this to happen" into a short, ranked, defensible list. That list is the actual product of a fault tree analysis, and it is worth exactly as much as the discipline that went into building it.