A fault tree starts with a failure that has already happened or that must not happen, and works backwards: what would have to be true for this to occur, and what would have to be true for each of those things. The result is a diagram of causes joined by AND and OR gates, and it is the tool a maintenance team reaches for when the same breakdown keeps coming back and nobody agrees why. This page explains what is fault tree analysis in practical terms, how to draw one for an asset, and what to do with the branches once they are on paper.
The top event and the gates beneath it
The top event is the failure you care about: the compressor tripped, the conveyor stopped, the chiller lost cooling. Beneath it sit the immediate causes, joined by a gate. An OR gate means any one of the causes is enough on its own; an AND gate means all of them had to happen together. Each cause is then expanded the same way until you reach basic events that cannot usefully be broken down further: a relay failed, a filter blocked, a setpoint was changed. The tree is finished when every branch ends in something you can inspect, measure or prevent.
Why it is different from an FMEA
An FMEA starts at the parts and asks how each could fail; a fault tree starts at one failure and asks what caused it. The FMEA is broad and is done before failures happen; the fault tree is narrow and is usually done after one has. Teams use both: the FMEA to build the schedule in the first place, the fault tree to find out why a scheduled task did not stop a particular failure, and to add the task or the inspection that would have.
Drawing one from work order history
The best evidence for a fault tree is the work order history for the asset: what was found each time, what was replaced, what the technician wrote. Lay the failures out, group the causes that appear more than once, and the OR gate beneath the top event usually draws itself. Causes that appear only in the technician's memory and never in a work order are the reason the history has to be written down at the time, not reconstructed in the meeting.
What the tree changes
Each basic event at the bottom of the tree is a candidate for a preventive task, an inspection point, a spare, or a change to the operating procedure. The ones under an AND gate are the cheap wins, because breaking any one of them stops the top event. The actions go onto the asset's schedule with an interval, and the next occurrence of the top event, if there is one, is the test of whether the tree was right.
Questions people ask about fault tree
Do I need software to draw a fault tree?
No. A whiteboard and the work order history are enough for a single asset. Software helps when the tree is large or when you want to put probabilities on the basic events, which most maintenance teams do not need.
What is the difference between a fault tree and a root cause analysis?
A fault tree is one method of root cause analysis. The five whys and the fishbone diagram are others. The fault tree is the one that handles causes that combine, which is why it suits equipment with interlocks and redundancy.
How far down should the branches go?
Until each basic event is something you can act on: inspect, replace on an interval, redesign, or change a procedure. A branch that ends in a cause nobody can do anything about has gone one level too far.