Fault Tree Math: Turning AND/OR Gates Into a Single Failure Probability

Every safety case eventually becomes a tree

Somewhere in the paperwork behind every certified shutdown system, aircraft brake, or nuclear interlock, there's a diagram that looks like an upside-down family tree: a single Top Gate at the root, branching down through Intermediate Gates, ending in basic events with individual failure probabilities. That diagram is a fault tree, and the entire point of building one is to convert a qualitative story — "the pump fails, or both the sensor and the backup sensor fail" — into a single defensible number: the probability the top event happens at all.

Engineers who've only seen fault trees in a review meeting tend to think of them as flowcharts. They're not. Every gate is a Boolean operation, and every basic event carries a probability. The moment you commit to that, the tree stops being a picture and becomes an equation you can actually solve, and the numbers that fall out — Top Event Probability, System Availability, Min. Cut Set Count, Single-Point Failures — become the real deliverable.

Gates are logic, not arithmetic — until you convert them

An AND gate under a Top Gate means every input event has to occur simultaneously for the output to occur — that's redundancy, and it's good news reliability-wise. An OR gate means any single input is enough — that's a weak link, and it should worry you. The conversion from logic to probability is where people go wrong, because AND and OR don't map onto simple multiplication and addition once events aren't independent, or once probabilities aren't small.

For independent events A and B:

P(A AND B) = P(A) * P(B)
P(A OR B)  = P(A) + P(B) - P(A) * P(B)

That subtracted cross-term matters more than it looks. For small probabilities (say, under 1%) it's negligible and people drop it; for anything larger, dropping it silently overstates the top event probability. A good fault tree calculator keeps the exact inclusion-exclusion form rather than the sloppy "just add them up" shortcut, specifically so the Top Event Probability output doesn't drift as component reliabilities degrade over a system's service life.

Minimal cut sets: the shortest paths to failure

A cut set is any combination of basic events that, if they all occur, guarantee the top event occurs. A minimal cut set is one with no redundant members — remove any single event from it and it stops guaranteeing failure. The Minimal Cut Sets list is arguably the most actionable output of the whole analysis, because each one is literally a failure scenario you can hand to an operator: "if this AND this happen together, the system goes down."

The Min. Cut Set Count tells you how many distinct ways the system can fail. A tree with two minimal cut sets is a fundamentally simpler risk picture than one with two hundred, even if the top-level probability happens to be identical — more cut sets generally means more independent maintenance items to track. And any minimal cut set with exactly one member is a Single-Point Failure: one component whose failure alone takes down the entire system, with no redundancy to catch it. Regulators specifically look for these because they represent the cheapest possible fix with the largest possible risk reduction — add redundancy to that one component and the single-point failure disappears entirely.

A worked example: a two-out-of-three shutdown system

Consider a simplified emergency shutdown system with three basic events:

• A — the primary shutdown relay fails, probability q_A = 0.010 (1.0%)
• B — sensor channel 1 fails, probability q_B = 0.020 (2.0%)
• C — sensor channel 2 fails, probability q_C = 0.015 (1.5%)

The Top Gate is an OR between the relay (A) and an Intermediate Gate (2 branches) that ANDs the two sensor channels together (B AND C) — the sensors are redundant, the relay is not.

Top event: Top = A OR (B AND C)

Top event probability, using the exact OR formula:

P(B AND C) = 0.020 * 0.015 = 0.00030
Top Event Probability = q_A + P(B AND C) - q_A * P(B AND C)
                       = 0.010 + 0.00030 - (0.010 * 0.00030)
                       = 0.010297  ->  1.03%

System Availability is just the complement:

System Availability = 1 - 0.010297 = 0.9897  ->  98.97%

The Minimal Cut Sets are {A} and {B, C} — Min. Cut Set Count = 2. Because {A} is a cut set of size one, it's flagged as a Single-Point Failure: the relay alone, with no backup, can take the whole shutdown system down. The redundant sensor pair, by contrast, needs both channels to fail together — a much less likely event at 0.03% versus the relay's 1.0%.

Importance measures: two different questions about the same component

This is where fault tree tools earn their keep over a back-of-envelope calculation. Two components can have very different failure probabilities and still be roughly equally "important" to the system, or vice versa, and two different importance measures answer two genuinely different engineering questions.

Birnbaum importance answers: "if this component's reliability moved by a small amount, how much would the top event probability move?" It's a sensitivity, not a probability — it ignores how likely the component actually is to fail and just asks how structurally critical its position in the logic is.

Birnbaum(A) = d(Top)/d(q_A) = 1 - P(B AND C) = 1 - 0.00030 = 0.9997
Birnbaum(B) = d(Top)/d(q_B) = q_C * (1 - q_A) = 0.015 * 0.990 = 0.01485

A's Birnbaum importance is nearly 1.0 — essentially every unit of unreliability in A passes straight through to the top event, because nothing backs it up. B's is two orders of magnitude smaller, because C has to also fail before B's failure matters.

Fussell-Vesely importance answers a different question: "of all the ways the system actually failed, what fraction of the time did this component participate?" It's normalized by the actual top event probability, so it blends structural position with real-world likelihood:

FV(A) = q_A / Top Event Probability = 0.010 / 0.010297 = 0.971  ->  97.1%
FV(B) = P(B AND C) / Top Event Probability = 0.00030 / 0.010297 = 0.029  ->  2.9%

Both measures agree here — the Most Critical Event (max FV) is A — but they won't always agree, and when they diverge is exactly when the two questions matter most. A component can have a modest Birnbaum score but a huge Fussell-Vesely score if it's just inherently unreliable, or the reverse if it's structurally critical but extremely well-built.

What trips people up

The most common analysis error is treating basic events as independent when they share a common cause — two sensors from the same manufacturing batch, or two systems that both lose power in the same outage. Ordinary cut-set math assumes independence; if a shared cause exists, it needs its own basic event feeding both branches, or the calculated Top Event Probability will be optimistic in a way that doesn't show up until the shared cause actually happens.

The second common error is stopping at the top-level probability and never checking the Single-Point Failures list. A system can have an acceptably low top event probability overall and still be carrying one component that, alone, could take everything down — that's precisely the scenario Min. Cut Set Count and single-point-failure flags exist to surface.

Try it yourself

Building this by hand for anything beyond three or four basic events gets unwieldy fast, and it's exactly the kind of bookkeeping a calculator should be doing instead of you. You can lay out your own Top Gate and Intermediate Gate (2 branches) structure and watch the Top Event Probability, Minimal Cut Sets, and importance rankings update live in the Fault Tree Analysis & Cut Set Calculator.

If your reliability work also involves tracking process drift over time rather than static failure logic, the control chart tool and the bathtub curve simulator cover the complementary statistical side of reliability engineering.