Fault tree analysis, or FTA, is a deductive method that starts with a clearly defined undesired event and develops the combinations of events that can produce it. Its output is a logical model. It shows where one failure can defeat the barriers, where two conditions must coexist, and where apparent redundancy shares the same weakness.
IEC 61025:2006 describes fault tree analysis and its application, including assumptions, events, failure modes, rules and symbols. Its public summary supports the general method. The complete conventions belong to the licensed publication and are not reproduced here.
When fault tree analysis is the right question
FTA is useful when the question starts with a system effect: loss of containment, loss of cooling, spurious protective action, failure to start, or unavailability of a critical function. It works from the top down by asking which individual events or combinations are sufficient for the top event.
FMEA and FMECA make the complementary move from item functions and failure modes to their higher-level effects. Root cause analysis investigates a real event using evidence. An FTA can support that investigation, but a logically possible path does not prove which path actually occurred. RCM uses the understanding of functions, failures and consequences to select maintenance policies.
Elements that must be technically correct
Top event
The top event is the undesired condition the tree explains. It needs an object, state, boundary and operating condition. Pump failure is too broad. Cooling-water header flow below the required minimum for longer than the response time while the reactor is in production is analyzable.
The definition also decides what is outside the tree. A tree for physical pressure loss differs from a tree for failure of the protective system to detect that loss. Combining both objectives creates branches that do not answer the same question.
Intermediate and basic events
An intermediate event is a condition that will be developed through lower events. A basic event is the lowest level developed in this tree because it already has technical meaning, data or a possible action. Auxiliary pump failure may be basic in a system study and intermediate in a detailed study that separates motor, power supply, coupling and hydraulic element.
Decomposition should follow the decision. A tree that reaches every bolt without changing control, data or ownership is too detailed. A tree that ends every branch at human error or electrical failure has not gone far enough.
OR gate
An OR-gate output occurs when at least one input occurs. It represents alternative sufficient paths. If low reservoir level, a blocked common filter or an incorrectly open bypass can each remove pressure, they enter through an OR gate.
AND gate
An AND-gate output requires all inputs to occur jointly. In a duty and standby pump arrangement in which the standby can assume the function, loss of pumping may require failure of the duty pump AND unavailability of the standby function. Joint occurrence must respect the time window and system state. It does not merely mean both events appeared in the same month.
The public NRC Fault Tree Handbook, NUREG-0492, systematizes tree construction and evaluation, including logical relationships and cut sets. It is a historical reference and its use in an industrial plant must be adapted to current systems and governance.
How to build an FTA without drawing a preferred conclusion
- Define the decision and top event. Record condition, boundary, operating mode, duration and observed consequence.
- Describe the system before drawing logic. Use diagrams, control logic, states, redundancies, utilities and interfaces.
- Ask for immediately sufficient causes. At each event, determine whether inputs are alternatives or must coexist.
- Select AND or OR from physics and logic. Do not choose a gate to produce a desired priority.
- Mark assumptions and undeveloped events. Missing evidence must remain visible.
- Stop at a useful level. A basic event should allow evidence, data, ownership or treatment.
- Review dependencies. Look for common power, environment, simultaneous maintenance, configuration error, software and shared isolation.
- Validate with operations and maintenance. Engineering confirms logic, while field knowledge tests states, access, symptoms and recovery.
Minimal cut sets: the smallest sufficient paths
A cut set is a combination of basic events whose occurrence causes the top event according to the modeled logic. A minimal cut set is minimal in the strict sense: removing any one event makes that combination insufficient.
First-order minimal cut sets contain one event and reveal single points of failure within the model boundary. Second-order sets require two events, and so on. Order helps structural interpretation, but it does not determine risk by itself. A second-order set containing frequent, dependent events may matter more than an extremely remote single event.
Minimal cut sets help teams locate common failures that defeat redundancy, identify combinations that rely on protection or standby functions, determine where failure and test data are needed, compare design and maintenance changes, and check whether an action truly removes a path.
Qualitative and quantitative analysis
What qualitative analysis provides
Qualitative analysis checks tree coherence and identifies minimal cut sets, single points, dependencies, common modes and barriers. Many maintenance decisions improve at this stage. Finding that two pumps share a filter, reservoir and power source can matter more than calculating six decimal places from weak data.
Qualitative priority should consider consequence, detectability, recovery capability, cut-set order, control quality and plausibility in the defined operating mode. It neither turns every single event into an immediate action nor permits severe combinations to be ignored.
What quantification requires
For independent events expressed as probabilities over the same horizon, a simple AND gate can be calculated as the product of input probabilities. For an OR gate, the exact union accounts for intersections. When events are rare and independent, their sum is used as an approximation. These relationships are invalid when independence does not hold or when the inputs mix event frequency, probability of failure on demand and unavailability.
Quantification must declare:
- data source, population and quality;
- operating interval or mission time;
- repairable, nonrepairable or standby state;
- test interval and repair time for hidden failures;
- dependencies, common cause and shared maintenance;
- parameter uncertainty and result sensitivity;
- treatment of overlapping cut sets.
The NASA Probabilistic Risk Assessment Procedures Guide presents procedures for probabilistic assessment and selecting an appropriate level of analysis. Calculation should support the decision, not conceal assumptions. Applying a catalog failure rate to a different population, environment or duty produces only the appearance of precision.
Industrial case: loss of compressor lube-oil pressure
This case is hypothetical. Compressor C-201 operates continuously and must maintain oil pressure at its bearings. The shaft drives the main pump. An electric auxiliary pump should take over when pressure falls. Both pumps share the reservoir, suction filter and discharge header.
Top event T: bearing-header pressure below 2.2 bar for more than 5 seconds while the compressor is above 80% load. The values only close the example boundary and are not reference limits for another machine.
The tree is structured as follows:
- T = C OR U. The top event results from common-path failure C or joint pumping unavailability U.
- C = B1 OR B2 OR B3 OR B4. B1 is reservoir level below minimum suction; B2 is a functionally blocked common filter; B3 is a relief or bypass valve stuck open; B4 is a significant header rupture.
- U = M AND A. M is the main pump unable to provide pressure; A is the auxiliary function unavailable on demand.
- A = A1 OR A2 OR A3. A1 is auxiliary-pump mechanical failure; A2 is unavailable electrical supply; A3 is automatic-start control failure.
The resulting minimal cut sets are {B1}, {B2}, {B3}, {B4}, {M, A1}, {M, A2} and {M, A3}.
Qualitative interpretation
The four first-order sets bypass pump redundancy. Duplicating pumps does not protect the shared tank, filter, relief path or header. The first technical review must confirm whether every event is sufficient under the stated conditions and whether an unmodeled barrier exists.
The sets {M, A1}, {M, A2} and {M, A3} show how standby protection can fail on demand. A test that merely starts the auxiliary motor covers part of A1, but does not prove power in all configurations, automatic command, suction alignment, valve position and delivered pressure. The maintenance task must test the complete function.
The team also identifies a dangerous assumption: auxiliary electrical power is treated as independent of main-pump failure. If a general power loss or common maintenance action can affect both functions, the tree needs an additional common-cause event. Without this revision, multiplying probabilities would understate risk.
Actions derived from the tree
- B1: review level measurement, alarm independence, limit, testing and operator response.
- B2: measure filter differential, define a limit and response time, and review sizing and cleaning strategy.
- B3: establish a functional test or inspection compatible with the valve mechanism and evaluate position indication.
- B4: review damage mechanisms, inspection, supports and header protection.
- A1 through A3: periodically test the complete automatic chain and record delivered pressure and response time.
- common cause: confirm electrical segregation, valve positions, permissives and simultaneous-maintenance exposure.
The example completes qualitative analysis but does not invent a final interval or probability. Quantifying T still requires coherent operating-failure data, standby failure-on-demand probability, test interval, repair time and common-cause treatment. Improving the shared controls does not need to wait for an unsupported number.
How the tree returns to maintenance execution
Every basic event needs ownership and treatment. Design changes follow engineering change control. A protective or standby function may generate a failure-finding task when applicable. Condition-based inspection needs a parameter and limit. An observed failure may trigger RCA and update the tree. The final strategy connects to reliability engineering and RCM.
In SAP PM, engineering structures approved tasks in task lists, strategies and plans linked to the technical object. Resulting orders must carry execution and acceptance criteria. Maintenance planning schedules resources and constraints. Field execution returns as-found condition, test result, measurement, notes and evidence.
PM Run operates over this existing flow. Planning organizes orders, capacity and sequence integrated with SAP PM. Mobility delivers work to the field and returns operation-level confirmations, technical notes, images, PDFs and measurements when applicable. Tree logic, probabilities and strategy decisions remain engineering responsibilities.
Errors that invalidate an FTA
- Defining a top event without operating condition or measurable boundary.
- Confusing temporal sequence with AND logic.
- Using OR when inputs must coexist, or AND to make a probability artificially smaller.
- Treating dependent events as independent.
- Ignoring standby, maintenance, startup and contingency states.
- Quantifying before validating structure and data.
- Presenting a possible path as the proven cause of an occurrence.
- Ending branches in generic labels that cannot receive action.
Technical references
- IEC 61025:2006, official page with the public scope of fault tree analysis.
- NRC NUREG-0492, Fault Tree Handbook, public handbook for construction and logical evaluation.
- NASA Small Spacecraft Systems Virtual Institute, Mechanical Fault Tree Analysis, an official overview of the top-down approach and its relationship to FMEA.
- NASA Probabilistic Risk Assessment Procedures Guide, a public reference for probabilistic analysis and risk-informed decisions.
Frequently asked questions
What is fault tree analysis?
It is a deductive logical model that starts with an undesired event and identifies individual events or combinations that can cause it within declared boundaries and assumptions.
What is the difference between AND and OR gates?
For an OR gate, any input is sufficient for the output. For an AND gate, all inputs must occur within the defined temporal condition. Physics, control logic and system states determine the gate.
What is a basic event?
It is an event at the lowest level developed in that tree. It should have enough technical meaning to receive data, evidence, ownership or treatment. The suitable level depends on the decision.
What is a minimal cut set?
It is the smallest combination of basic events sufficient to cause the top event according to the tree logic. Removing any event makes that path insufficient.
Does every fault tree need quantification?
No. Qualitative analysis already identifies single points, combinations, dependencies and common failures. Quantification adds value only when structure, evidence, horizon and assumptions are fit for the decision.
Does FTA find the root cause of an event?
It identifies logically possible paths. To state which path occurred, the team needs preserved evidence and a causal investigation. The tree helps formulate and test hypotheses.
How does FTA connect to SAP PM?
Engineering-approved actions may generate design changes, plan tasks, functional tests and inspections. SAP PM orders execute and record this work, and the history returns to update tree events, data and controls.
To make sure tests, inspections and orders derived from the analysis reach the field and return to SAP PM with evidence, see PM Run planning and mobility. Tree logic and risk decisions remain with engineering.
