Quantitative Fault Tree Analysis: Putting Numbers on Failure - Part 1

In a previous blog post, we have discussed how a fault tree is built, a top-down map of how a system can fail, starting from the worst outcome and branching down to root causes. A tree like that tells you how a system can fail and where its weak points are. But it leaves a crucial question unanswered: how likely is that failure, really? Is the top event a one-in-a-thousand risk or a one-in-a-billion one? Answering that is the job of quantitative fault tree analysis, and it's what turns a diagram into a decision.

From logic to numbers

The same fault tree can be used two ways.

Qualitatively, you study its structure, like the minimal cut sets, the single points of failure, etc. without any arithmetic.

Quantitatively, you feed in the failure probability of each basic event and calculate the probability of the top event.

You go quantitative when you have failure data and you need to compare against a target or decide which fix reduces the failure rate cheaply.

The inputs are numbers for each basic event: a probability of failure on demand, or a failure rate (failures per hour) combined with how long the component operates or sits unrepaired. These come from reliability databases, manufacturer data, field and warranty records, testing, or expert estimates. One principle dominates everything that follows: garbage in, garbage out. A beautifully computed top-event probability built on guessed inputs is still a guess.

The two rules that drive everything below are simple:

• OR gate: the top event occurs if any input fails → probabilities (approximately) add.

• AND gate: the top event occurs only if all inputs fail → probabilities multiply.

Let's see both in action.

Example 1: Top event with an OR gate

Consider a cooling function that is lost if either of two components fails: a temperature sensor (A) or a controller (B). The fault tree looks like this:

Fig 1: Example of an OR gate

Step 1 - Assign failure rates

Failure rates can be assigned from a reliability database (e.g. MIL-HDBK-217F). Lets suppose:

• λ_A = 1 × 10⁻⁵ failures per hour (sensor)

• λ_B = 2 × 10⁻⁵ failures per hour (controller)

Step 2 - Convert failure rates to probabilities. 

For a component with a constant failure rate λ operating for a mission time t, the probability of failure is:

P(t) = 1 − e^(−λt) ≈ λt  (when λt is small)

For a mission time of t = 1,000 hours:

• P(A) = 1 − e^(−0.00001 × 1000) ≈ 0.01

• P(B) = 1 − e^(−0.00002 × 1000) ≈ 0.02

What do P(A) and P(B) mean? 

P(A) = 0.01 means that over the 1,000-hour mission, there is a 1% chance the sensor fails; put another way, if you ran 100 identical missions, you'd expect the sensor to fail during about one of them.

P(B) = 0.02 is the same statement for the controller: a 2% chance of failure over the mission. These are per-mission probabilities, not per-hour rates, the conversion in Step 2 is what ties the two together.

Step 3 - Combine at the OR gate. 

For two independent events, the exact formula is:

P(top) = P(A) + P(B) − P(A) × P(B)

The subtraction removes the double-counted case where both fail. Plugging in:

P(top) = 0.01 + 0.02 − (0.01 × 0.02) = 0.0298 ≈ 3%

For small probabilities the cross-term is negligible, which is why the working shorthand is "add at OR gates": 0.01 + 0.02 ≈ 0.03.

Reading the result: 

The cooling function has roughly a 3% chance of being lost during a 1,000-hour mission, and notice the OR gate makes the system less reliable than its weakest component, because either failure alone is enough.

Further reading: the NRC Fault Tree Handbook (NUREG-0492) is the classic free reference for these calculations, and IEC 61025 is the formal standard for fault tree analysis.

Example 2: Top event with an AND gate

Now consider a system with redundancy: coolant flow is lost only if both of two identical pumps fail.

Fig 2: Example of an AND gate

Step 1 - Assign failure rates. 

Since the pumps are identical:

• λ_A = λ_B = 1 × 10⁻⁵ failures per hour

Step 2 - Convert to probabilities (same mission time, t = 1,000 hours):

• P(A) = 1 − e^(−0.00001 × 1000) ≈ 0.01

• P(B) ≈ 0.01

As before, P(A) and P(B) each say: this pump has a 1% chance of failing at some point during the 1,000-hour mission.

Step 3 - Combine at the AND gate. For independent events:

P(top) = P(A) × P(B) = 0.01 × 0.01 = 0.0001 = 1 × 10⁻⁴

Reading the result: 

The redundant pair fails only about once in 10,000 missions, a hundred times better than a single pump on its own. This is the mathematical payoff of redundancy, and it's why AND gates are where reliability is bought in a design. Hold on to that 1-in-10,000 figure, though; we're going to stress-test it shortly.

Which failures matter most: importance measures

continued in this blog post .....