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

In the previous blog, we talked about the mathematics behind different gates in a Fault Tree Analyses. In this blog, we talk about what the results from an FTA mean.

Which failures matter most: importance measures

Once you can compute the top-event probability, you can ask the next question: Which basic event is actually driving the risk? This is what importance measures quantify, and they're how engineers prioritize.

The Fussell-Vesely (FV) measure: the most commonly used, tells you what fraction of the total risk a given component contributes. Take Example 1, where P(top) ≈ 0.0298:

FV(A) = P(A) / P(top) = 0.01 / 0.0298 ≈ 33 % 

FV(B) = P(B) / P(top) = 0.02 / 0.0298 ≈ 67 %

The controller (B) is responsible for roughly two-thirds of the risk of losing the cooling function. If you can only afford to upgrade one component, the FV measure says it should be B: halving P(B) to 0.01 drops the top event from ~3% to ~2%, while halving P(A) only gets you to ~2.5%.

The Birnbaum measure asks a slightly different question: how much would the system's risk change if this component's probability moved? It's the sensitivity of the top event to each input. For the OR gate in Example 1:

Birnbaum(A) = 1 − P(B) = 0.98

Birnbaum(B) = 1 − P(A) = 0.99

Both are close to 1, which tells you the top event responds almost one-for-one to any change in either component, there is no redundancy shielding the system.

Contrast that with Example 2, where,

Birnbaum(Pump 1) = P(Pump 2) = 0.01:

A change in one pump's reliability is damped a hundredfold by its partner. That damping is redundancy, expressed as a number.

Together, these measures let you stop guessing about where to invest and instead target the handful of events that actually move the overall failure probability of the system.

The trap of assumed independence: common-cause failure

Return to the two pumps in Example 2 and their reassuring 1-in-10,000 number. That number relied on a hidden assumption baked into Step 3: Pump 1 and Pump 2 fail independently, for unrelated reasons.

In the real world, they often don't. If both pumps draw from the same power supply, share the same contaminated fuel, were installed by the same technician on the same day, or sit in the same flood-prone room, then a single root cause can take out both at once. This is a common-cause failure, and it quietly destroys the benefit of redundancy.

Engineers model it with a beta factor: the fraction of a component's failures that stem from a shared cause. Suppose just 10% of pump failures are common cause (β = 0.1). The system can now fail two ways:

1. Independent path - both pumps fail for separate reasons:

(1 − β)² × P(A) × P(B) = 0.9² × 0.01 × 0.01 ≈ 0.00008

2. Common-cause path - one shared root cause kills both at once:

β × P(single pump) = 0.1 × 0.01 = 0.001

The common-cause path alone contributes 0.001, ten times larger than the 0.0001 we computed assuming independence. The honest answer isn't 1-in-10,000; it's closer to 1-in-1000. One modest, realistic assumption about shared vulnerability wiped out more than 90% of the benefit the AND gate appeared to deliver. This is why quantitative FTA done well always asks what the "redundant" elements secretly share.

Living with uncertainty

Failure data is never exact, so a single point estimate can mislead. Mature analyses treat each input as a distribution rather than a fixed number and propagate that uncertainty through the tree, often with Monte Carlo simulation: running the calculation thousands of times with sampled inputs to produce a range rather than a false-precision single value. A companion sensitivity analysis then shows which uncertain inputs most affect the result, telling you where better data would be worth collecting.

Comparing against a target

A probability only becomes meaningful next to a requirement. Functional-safety standards define exactly these targets. IEC 61508 assigns Safety Integrity Levels (SILs), each tied to a maximum allowable failure probability; ISO 26262 does the equivalent for automotive systems with ASILs. Quantitative FTA is how you demonstrate that a design's computed top-event probability actually meets the SIL or ASIL it's required to hit.

For the small two-event trees in this post, the arithmetic fits on a napkin. Real trees don't: hundreds of basic events, thousands of cut sets, importance measures for every component, common-cause groups, and Monte Carlo runs on top. That's the computation SLIKWORKS is built for, it handles cut-set generation, top-event quantification, Fussell-Vesely and Birnbaum rankings, beta-factor common-cause modeling, and uncertainty propagation, so the analysis you saw above scales from a napkin sketch to a certification-ready safety case.

The takeaway

Qualitative FTA shows you the shape of failure; quantitative FTA tells you its size. With two simple rules: add at OR gates, multiply at AND gates, plus important measures to rank what matters, common-cause modeling to stay honest about redundancy, and uncertainty analysis to avoid false precision, you can turn a fault tree into something a manager or regulator can act on.