Fault tree analysis

The formula

The two gates that carry the whole method, for independent inputs:

P(A AND B) = P(A) · P(B)

Reading: an AND gate means every input has to fail, so the probabilities multiply and the result gets small fast — this is the arithmetic that makes redundancy worth buying.

P(A OR B) = 1 − (1 − P(A)) · (1 − P(B)) = P(A) + P(B) − P(A)·P(B)

Reading: an OR gate means any one input takes you down, so you compute the chance that none do and subtract from one.

The rare-event approximation that every fault tree code quietly uses:

P(A OR B) ≈ P(A) + P(B)        (good when each P < 0.1)

Reading: when failures are rare the cross terms are negligible, so just add — and since you dropped a negative term, the answer errs slightly high, which is the direction a safety analysis wants to err ^[8].

The cut-set form, which is how a real tree actually gets quantified:

TOP = C₁ ∪ C₂ ∪ … ∪ C_m         (each Cᵢ a minimal cut set)
P(TOP) ≤ Σᵢ P(Cᵢ),   where P(Cᵢ) = Π P(basic events in Cᵢ)

Reading: a minimal cut set is a smallest group of basic failures that is sufficient to cause the top event; multiply within each set (AND), sum across sets (OR), and the sum is a guaranteed upper bound on the top event probability.

Basic events over a mission time t with constant failure rate λ:

P = 1 − e^(−λt) ≈ λt            (for λt << 1)

Reading: the same exponential as radioactive decay — at λt = 0.001 the exact value is 0.0009995, so the shortcut costs you a twentieth of a percent.

Where you meet it

The safety review board for a flight termination or ordnance system. The board wants the tree for the top event "inadvertent initiation," and the first question is always the same: show me the order-1 cut sets. A minimal cut set with one member is a single-point failure, and no probability number talks anyone out of one.
Range safety and payload integration paperwork. Requirements arrive as numbers like "probability of inadvertent launch shall not exceed 1×10⁻⁶ per mission," and the fault tree is the accepted instrument for showing your design meets it — the method exists because the Air Force asked exactly that question about Minuteman in the early 1960s ^[1]^[2].
Failure investigation on the test stand. After an anomaly, the fault tree runs in reverse: the top event already happened, and the tree becomes a checklist of every branch that could have produced it, with branches closed out one by one as instrumentation data rules them out. This is how mishap boards keep from anchoring on the first plausible story.
Nuclear and chemical plant licensing. Probabilistic risk assessments pair fault trees (what combinations fail) with event trees (what happens next) to argue accident frequencies to the regulator — the structure WASH-1400 established in 1975 and the NRC has run on since ^[5]^[6].

How it works

The tree is Boolean algebra wearing a schematic. You define the top event precisely — "loss of hydraulic pressure at the actuator during boost," not "hydraulics bad" — then decompose through gates until you reach basic events you have failure data for: valve fails closed, relay contacts weld, operator skips a step. Qualitative payoff first: reduce the logic to minimal cut sets and read off the single-point failures and the shortest paths to disaster. Quantitative payoff second: put probabilities on the basic events and bound the top.

The mistake that actually bites people is repeated events. The same basic event — one power bus, one sensor, one software load — feeding two branches breaks gate-by-gate arithmetic, because Boolean algebra says A·A = A, not A². Take TOP = (A OR B) AND (A OR C) with all three events at 0.01. Multiply the two OR-gate outputs and you get 0.0199² ≈ 3.96×10⁻⁴. Reduce the Boolean expression first and it collapses to A OR (B AND C), which evaluates to 0.0101. The lazy answer is optimistic by a factor of 25 — on the unsafe side — because squaring the shared event pretends you have redundancy you don't. This is exactly why the codes compute minimal cut sets before touching probability ^[1]^[8].

Common cause failure is the second trap, and it is the one that kills redundancy claims at review. Two pumps at 10⁻³ each under an AND gate give 10⁻⁶ — if they fail independently. Same contaminated fluid, same maintenance tech, same freeze event, and they don't. The standard patch is a beta factor: model a shared-cause basic event at β · λ, and with a typical β = 0.05 that term sits at 5×10⁻⁵ — fifty times the independent number, and it now owns the answer. Any tree that shows 10⁻⁶ from redundant identical hardware with no common-cause term is advertising an unexamined assumption ^[1]^[8].

Limits of validity, plainly:

The tree models your understanding, not the system. It is top-down and enumerated by hand: a failure mode nobody drew is a failure mode the number doesn't include. FTA bounds the risk of the hazards you identified; it is silent about the ones you didn't.
It is static and binary. Events are failed or not; classic FTA doesn't natively handle sequence dependence, repair, or degraded states — that's what event trees, Markov models, and dynamic fault trees were bolted on for ^[8].
The output is only as good as the λ's. Basic-event rates come from handbooks, vendor data, and sparse field history, often with order-of-magnitude uncertainty. Treat the top-event number as a bound and a ranking tool — which cut sets dominate, where the next dollar of redundancy goes — not as a prediction with three significant figures.
Truncation. Big trees generate cut sets combinatorially; software drops sets below a probability cutoff. Fine, until common-cause coupling makes a "negligible" set not negligible. Check what got truncated.

History

The method has a Huntsville-adjacent birth certificate. In the early 1960s the Air Force Ballistics Systems Division needed an answer to an uncomfortable question about the Minuteman ICBM: what is the probability the launch control system launches when nobody told it to? H. A. Watson at Bell Telephone Laboratories, working the study under contract, organized the failure causes into a logic diagram — the first fault tree — around 1962 ^[1]^[2]^[3]. Boeing engineers, David Haasl prominent among them, picked the technique up and spread it from missiles into aircraft design, and by 1965 it was moving through the aerospace industry at large ^[1]^[3].

The mathematics matured in Idaho. William Vesely, at the Idaho nuclear labs around 1970, developed kinetic tree theory — the time-dependent quantification that turned a logic diagram into failure frequencies ^[2]. The cut-set machinery went out to everyone as computer codes; MOCUS, published in 1974 by Fussell, Henry, and Marshall at Aerojet Nuclear Company in Idaho Falls (report ANCR-1156), computed minimal cut sets top-down and became the pattern for the software still in use ^[4].

Nuclear power made it an institution. The 1975 Reactor Safety Study, WASH-1400, led by MIT's Norman Rasmussen, combined fault trees with event trees to estimate reactor accident risk — the founding document of probabilistic risk assessment, praised for its method and hammered by the 1978 Lewis committee for understating its uncertainties ^[5]^[6]. The NRC then codified the craft in the 1981 Fault Tree Handbook, NUREG-0492, written by Vesely, Goldberg, Roberts, and Haasl — the Bell-to-Boeing-to-NRC lineage in one author list ^[1]^[7].

NASA's path was stranger. An early Apollo-era risk calculation returned a mission success probability low enough that the agency backed away from quantitative risk analysis entirely and leaned on FMEA for two decades. Challenger, in 1986, ended that. NASA rebuilt its probabilistic risk practice and in 2002 published its own Fault Tree Handbook with Aerospace Applications, with Vesely again the lead author ^[1]^[8].

Related tools

/tools/bearing-life-l10 — component life statistics of the kind that feed basic-event probabilities
/tools/half-life-decay — the same e^(−λt) exponential that prices a constant-failure-rate basic event over mission time
/tools/arrhenius-rate — how failure rates get temperature-scaled before they go into the tree

Sources

Written by HE in our own words from the cited sources — engineering judgment included, your stamp still required. All entries →