Fault tree analysis: building the tree from the top event, gates and minimal cut sets, and where it sits beside FMECA and RCA
How fault tree analysis works: the symbols, defining a top event with a boundary, building the tree through OR and AND gates to basic events, reducing it to minimal cut sets and turning them into action, putting probabilities through it and the common cause trap, and how it differs from FMECA and root cause analysis. With a worked example.
Key takeaways
- Fault tree analysis starts from one undesired event and works down through the combinations of failures that can cause it. OR gates mean any one cause is enough. AND gates mean all of them have to happen together.
- The tree is only as good as its top event. 'The crusher fails' has no edge. 'The crusher stops on low lube oil flow' has one, and the tree can be built and finished.
- The useful output is the minimal cut sets: the smallest combinations of basic events that cause the top event. A cut set of one event is a single point of failure, and it is where the effort goes first.
- Fault trees handle what FMECA handles badly, which is combinations, such as a duty pump failing while the standby is out for maintenance. The two methods are used together, not as alternatives.
- Probabilities can be put through the tree when the data support it, but a tree without numbers still does most of its work by showing the structure of the failure.
A crusher trips on low lube oil flow three times in a year. The first investigation finds a blocked filter, the second a pump motor trip, the third a flow switch that tripped with the flow normal. Each investigation fixed what it found. None of them asked how the system as a whole could lose flow, which combinations of failures would do it, and which of those the site had no protection against. That is the question a fault tree answers.
This guide sets out how fault tree analysis works: the symbols, how a tree is built from a well-defined top event down to basic events, how it reduces to minimal cut sets, when to put numbers through it, and how it sits beside FMECA and root cause analysis. The worked example is the crusher lube oil system drawn in the P&ID guide, and the method follows IEC 61025 and the NRC's Fault Tree Handbook. The scope is equipment reliability and maintenance. Safety instrumented systems have their own methods and standards, which this guide does not cover.
The tree and its symbols
A fault tree is drawn from the top. The top event is the undesired event, stated precisely. Below it, a gate joins its immediate causes. An OR gate says any one cause is enough. An AND gate says all of them are needed together. Each cause is an intermediate event, developed further in the same way, until the tree reaches basic events, drawn as circles, which are component failure modes that are not broken down further. A house event, drawn as a house, is a condition that is either true or not, such as a pump being out for maintenance.
The example has three paths to the top event under the first OR gate. The filter blocks. The flow switch trips with the flow normal. Or the pumps fail to deliver, which under its AND gate needs the duty pump to fail and the standby to fail to start. The duty pump fails by its motor tripping or its coupling failing. The standby fails to start because its auto-start fails or because it is out for maintenance. Read as a whole, the tree says the system has redundancy against pump failures and none against the filter or the switch.
| Symbol | How it is drawn | What it means |
|---|---|---|
| Top event | Rectangle at the top | The undesired event the tree explains. One per tree, stated precisely |
| Intermediate event | Rectangle | An event that is the output of a gate and has causes below it |
| Basic event | Circle | A failure that is not developed further: a component failure mode with data behind it |
| Undeveloped event | Diamond | An event not developed further for lack of information or because it is minor |
| House event | House shape | A condition that is either on or off, such as a pump out for maintenance |
| OR gate | Curved base, pointed top | The output occurs if any one input occurs |
| AND gate | Flat base, rounded top | The output occurs only if all inputs occur together |
| Transfer | Triangle | The branch continues on another sheet |
Building a tree
The top event decides whether the tree can be finished. It has to say what system, from what state, to what condition, so it has a boundary. 'The crusher fails' could include a liner failure, a power outage and an operator stopping it, and the tree would never end. 'The crusher stops on low lube oil flow, while running' has a boundary the tree can be built inside.
The tree is then built one level at a time, asking at each event what immediate causes could produce it, and whether one is enough or all are needed. The discipline is to name the immediate cause, not the root cause. 'Pumps fail to deliver' sits between the top event and 'motor trips' for a reason: it is where the redundancy lives, and skipping it would lose the AND gate that is the most important feature of the tree. The tree stops at basic events that have failure data, or at least a clear maintenance or design action.
| Step | What is done | What to watch |
|---|---|---|
| Define the top event | State the failure precisely, with its boundary: what system, from what state, to what condition | A tree for 'the crusher fails' has no edge. A tree for 'crusher stops on low lube oil flow' has one |
| Set the boundary and the resolution | Decide what is inside the system, which interfaces are assumed to work, and how deep to go | Stop at the level where failure data and actions exist |
| Build the tree downwards | For each event ask what immediate causes could produce it, and whether one is enough (OR) or all are needed (AND) | Immediate causes only. Jumping straight to a root cause skips the logic the tree is for |
| Stop at basic events | A basic event is a failure mode of a component that has data or a clear action | Develop no further than the data and the decisions need |
| Find the minimal cut sets | Reduce the tree with Boolean logic to the smallest combinations of basic events that cause the top event | A cut set of one event is a single point of failure |
| Quantify, if the data support it | Combine basic event probabilities through the gates | AND multiplies, OR adds for small probabilities. Common cause breaks both |
| Act and record | Turn the cut sets into tasks, design changes or spares, and keep the tree with the asset records | A tree in a report nobody opens changes nothing |
Minimal cut sets
A fault tree reduces with Boolean logic to its minimal cut sets, the smallest combinations of basic events that each cause the top event. For the example the reduction is short. The OR gate at the top gives three terms. The filter and the flow switch are each a cut set on their own. The pump branch is the duty pump failing, by either cause, combined with the standby failing to start, by either cause, which gives four pairs.
The cut sets are where the analysis turns into action. Single event cut sets are single points of failure and come first: the filter needs a differential pressure alarm and a change-out interval that is actually met, and the flow switch is a candidate for a transmitter or voting, so that one faulty device cannot stop the crusher. The pairs say the redundancy only works if the standby actually starts, and most sites prove that at commissioning and never again. The house event says something else again: running the crusher on one pump while the other is out for maintenance turns a two event cut set into a one event cut set, and that should be a decision someone makes, not a default.
| Order | Cut set | What it means | A response |
|---|---|---|---|
| 1 | Filter blocked | One event. A single point of failure | Differential pressure alarm and a timed change-out in the PM program |
| 1 | Flow switch fails and trips | One event. A spurious trip, not a real loss of flow | Two out of three voting, or a transmitter in place of the switch |
| 2 | Duty pump motor trips, and standby fails to auto-start | Two events together | Prove the auto-start on a routine, not only at commissioning |
| 2 | Duty pump coupling fails, and standby fails to auto-start | Two events together | Coupling inspection in the PM, and the same auto-start test |
| 2 | Duty pump fails, and standby out for maintenance | A failure during a known condition | A rule that the crusher does not run on one pump without a decision |
A cut set of one is a single point of failure. A house event that turns a pair into a single is a decision the site should make on purpose.
Putting numbers through it
When the basic events have probabilities, or failure rates and exposure times, the tree can be quantified. For independent events an AND gate multiplies its inputs and an OR gate, for small probabilities, adds them. The top event probability is close to the sum of the minimal cut set probabilities. The numbers come from the site's own failure history, kept against ISO 14224 failure modes, or from industry databases where the site has none.
Two cautions. The arithmetic assumes the events are independent, and common cause failures break that: two pumps on the same motor control centre, two transmitters on the same impulse line, or the same maintenance error made on both. Common causes are modelled as their own basic events, often under an OR gate above the redundancy they defeat. And the numbers are only as good as the data. A tree with rough numbers is still useful for ranking cut sets. It is not useful for a claim that the event will happen once in a given number of years.
Beside FMECA and root cause analysis
The three methods are often confused, and they answer different questions. FMECA takes every failure mode of a system and asks its effect, which is how a maintenance strategy is built across a plant. Fault tree analysis takes one event and finds every path to it. Root cause analysis takes one event that happened and finds the causes that actually acted. A fault tree is a good tool inside an RCA when the failure has several possible paths, and a good check on an FMECA where redundancy is meant to protect a function.
| Fault tree analysis | FMECA | Root cause analysis | |
|---|---|---|---|
| Direction | Top down, from one undesired event to its causes | Bottom up, from each component failure mode to its effects | Backwards from one failure that happened to why it happened |
| Scope | One event, all the paths to it | All failure modes of a system | One event, the causes that actually acted |
| Handles combinations | Yes, that is what AND gates are for | Poorly. Each failure mode is considered alone | Yes, through the causal chain |
| Output | Cut sets, and a probability if the data allow | A ranked list of failure modes and maintenance tasks | Causes, and corrective actions |
| When | Design, a critical system, or a recurring event to explain | Design, and building the maintenance strategy | After a failure |
| Standard | IEC 61025 | IEC 60812 | IEC 62740 |
Where fault trees go wrong
- A top event with no boundary, so the tree grows without end and is never finished.
- Jumping from the top event straight to component failures, losing the intermediate events where the redundancy and the logic live.
- OR used where AND is meant, or the reverse, which turns redundancy into a single point of failure on paper or hides one.
- Common cause failures left out, so redundant equipment looks far more reliable than it is.
- Numbers presented to several decimal places from data that support one significant figure.
- Human actions, such as maintenance leaving a standby unavailable, left out because they are not equipment failures.
- A tree finished, filed in a report and never turned into PM tasks, alarms or design changes.
Common questions
What is fault tree analysis?
A top down method for analysing how an undesired event can happen. The event is placed at the top of a tree and its immediate causes are drawn below it, joined by logic gates that say whether any one cause is enough (an OR gate) or all of them are needed (an AND gate). Each cause is developed the same way until the tree reaches basic events, which are component failures with data or a clear action. IEC 61025 sets out the method.
What is a minimal cut set?
The smallest combination of basic events that, if they all occur, causes the top event. Smallest means that removing any event from the set would stop it causing the top event. A cut set with one event is a single point of failure. A cut set with two events needs two failures together. Finding the minimal cut sets is the main analytical output of a fault tree, because it shows which failures and combinations matter.
What is the difference between an AND gate and an OR gate?
An OR gate's output occurs if any one of its inputs occurs. An AND gate's output occurs only if all of its inputs occur together. Redundancy shows up as AND gates: with a duty and standby pump, losing flow needs the duty pump to fail and the standby to fail to start. Single points of failure show up as basic events under OR gates near the top of the tree.
What is the difference between FTA and FMEA?
Direction and scope. FMEA and FMECA work bottom up, taking each component failure mode in turn and asking what its effect is, which covers the whole system but treats each failure alone. Fault tree analysis works top down from one event and finds every path to it, including combinations of failures. FMECA builds a maintenance strategy across a system. A fault tree explains one important event in depth. They are often used together, with the FMECA identifying the events that deserve a tree.
How do you calculate the probability of a fault tree?
From the basic events upward through the gates. For an AND gate of independent events, multiply the probabilities. For an OR gate, add them when they are small, which is called the rare event approximation, or use one minus the product of the complements for an exact result. The top event probability is then the sum of the minimal cut set probabilities, for small values. The calculation assumes independence, and common cause failures, such as both pumps on one supply, break that assumption and have to be modelled explicitly.
When should you use fault tree analysis?
When one event matters enough to understand in depth: a failure with serious consequences, a critical system with redundancy whose real protection is uncertain, or a recurring event that a root cause analysis keeps attributing to different causes. It is also useful in design, to check that redundancy does what it is meant to. It is not the tool for building a maintenance strategy across a whole plant, which is the job of FMECA and RCM.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
- IEC 61025:2006 Fault tree analysis (FTA) (IEC)
- Fault Tree Handbook, NUREG-0492 (US Nuclear Regulatory Commission)
- IEC 60812:2018 Failure modes and effects analysis (FMEA and FMECA) (IEC)
- IEC 62740:2015 Root cause analysis (RCA) (IEC)
- ISO 14224:2016 Collection and exchange of reliability and maintenance data for equipment (ISO)
Related case studies and tools
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.