When something serious fails, the first question is "what happened?" and the second is "what else could have caused it?" A blame-room full of opinions is not an answer. Fault Tree Analysis (FTA) is the structured method that turns that question into a rigorous, testable picture of how a top event — the failure you want to prevent — can occur, by working backward from it through every contributing cause to the root events that must be true for it to happen.
It is the analytic engine behind serious root cause analysis, and it is the standard tool in safety engineering for asking "how likely is this catastrophic thing, and what would have to line up for it?" Once you can read and build one, your failure investigations stop being arguments and start being diagrams you can argue about precisely.
FTA vs FMEA — Top-Down vs Bottom-Up
These two are constantly confused because they both analyse failure. They work in opposite directions.
FMEA (Failure Mode and Effects Analysis) is bottom-up and exhaustive. Take every component, list every way it can fail, and ask what effect each failure has. It answers: "what could possibly go wrong, and how bad?" It is broad and speculative — a brainstorm of the failure space. (See our primer on what FMEA is.)
FTA is top-down and focused. Start with one specific undesired event — "the feed pump failed to start," "the pressure vessel ruptured," "the line stopped for more than 30 minutes" — and work downward to find every combination of causes that can produce it. It answers: "how could THIS specific thing have happened, or happen in future?"
Use FMEA to scope the failure space across an asset. Use FTA to dissect one serious event in depth. Mature programs use both.
Building a Fault Tree
A fault tree is a diagram of logic gates.
- The top event — the failure you care about — sits at the top.
- Below it, intermediate events — component or subsystem failures that contribute.
- At the bottom, basic events — the root causes, things that fail on their own: a relay sticks, a bearing seizes, an operator misreads a gauge, a sensor drifts.
- The events are connected by logic gates, almost always AND or OR.
The two gate types are the whole game:
- OR gate — the output happens if ANY input happens. A pump fails to start if there is no power OR the control signal fails OR the motor fails OR the coupling shears. Any single one is enough. OR gates multiply the failure probability and make the system fragile.
- AND gate — the output happens only if ALL inputs happen. A pressure vessel ruptures if the pressure exceeds design AND the relief valve fails AND the operator does not trip the system manually. AND gates are safeguards — each one you add dramatically cuts the top-event probability, because every input has to line up.
Reading a tree is reading the gates. A tree dominated by OR gates leading to the top event describes a fragile system with many single points of failure. A tree with AND gates layered in describes a defended system.
Minimal Cut Sets
The analytical payoff of an FTA is the minimal cut set — the smallest combination of basic events that, if they all occur, will produce the top event. Each minimal cut set is one pathway to failure. A tree usually has many.
The point of computing them is prioritisation. A cut set with one event (a single basic event that alone causes the top event) is a single point of failure — fix it first. A cut set requiring four independent events is far less urgent, because the chance of all four lining up is tiny. Minimal cut sets turn a sprawling diagram into a ranked to-do list of where to spend your reliability budget.
Quantitative FTA
Assign a probability (or failure rate) to each basic event — from historical data, vendor specs, or industry databases — and propagate them through the gates to get the probability of the top event. AND gates multiply probabilities (so 0.01 AND 0.01 = 0.0001); OR gates combine them closer to addition. The result is a number: "this top event has a probability of roughly 1 in 4,000 per year." Compare that against your tolerable risk, and you know whether you need to add a safeguard.
Even rough numbers are useful. The exercise of assigning probabilities forces honesty about which basic events are likely and which are vanishingly rare — and that is usually where the argument gets resolved.
A Worked Example
Top event: "feed pump P-101 failed to start on demand."
First level — an OR gate. The pump fails to start if any of: no power to the motor, the control circuit does not energise, the motor itself fails to start, or the mechanical shaft cannot turn (seized).
Drill into "motor fails to start": motor overload trips, OR winding short / insulation failure, OR bearing seizure.
Drill into "bearing seizure": lubrication lost AND contamination ingress AND no condition monitoring detected it. That last branch is an AND gate — three things had to line up. So bearing seizure is a relatively unlikely path; the lubrication-loss path alone, with monitoring in place, does not seize the bearing.
Meanwhile "no power to the motor" drills to: MCC breaker tripped, OR supply transformer failed, OR cable fault. All single events under OR gates — single points of failure on the electrical path.
The cut-set analysis tells you the electrical supply chain is the dominant contributor to the top event, and that is where to spend the reliability effort: redundancy on the supply, periodic breaker inspection, cable condition monitoring. The bearing path is defended; the power path is not. The diagram settled the argument without anyone needing to win a meeting.
When to Use It
- After a serious incident or near-miss, as the structured backbone of the investigation. FTA is the method behind a real root cause analysis, not the gut-feel version. (See root cause analysis.)
- For safety-critical and high-consequence systems, to demonstrate that the top-event probability is below a tolerable threshold — pressure systems, emergency shutdown, protective functions.
- When designing out a single point of failure, to model whether adding redundancy (an AND gate) actually brings the risk down enough to justify the cost.
- When the failure is complex, involving multiple systems and human actions that interact. Simple failures do not need a tree; complex ones cannot be reasoned about reliably without one.
How OpexMX Supports It
OpexMX does not draw fault trees for you — that work belongs to the engineer who understands the system — but it gives the analysis teeth. Each basic event in a tree can be linked to the asset and the failure history in the system, so the probabilities you assign are grounded in your actual failure data, not a guess. When a top event does occur, the incident's work-order chain, the asset's failure history, and the maintenance actions taken are all in one record, ready to feed the tree. And the corrective actions that fall out of the cut-set analysis become work orders against the specific basic events that need defending — so the analysis turns into prioritised work instead of a slide deck.
Link your failure data to fault-tree investigations in OpexMX →