What is fault tree analysis in maintenance and reliability?
Fault Tree Analysis is a top-down deductive reliability method that defines an unwanted top event and models the lower-level events and logical conditions that can cause it, usually using AND and OR gates. It can be qualitative, identifying single-point and combined-event vulnerabilities, or quantitative when probability, dependency and event-boundary assumptions are defensible.
Describe exactly which system-level state counts as failure.
Start with one observable top event, a time window and a clearly defined system boundary. A useful example is 'the emergency cooling function is unavailable during a demand.' The top event must not silently alternate between failed start, inadequate flow, and loss of both power trains.
Document normal duty, redundancy, standby configuration, demand frequency, repair assumptions and whether the tree represents fault occurrence, unavailability on demand or failure over a mission. Different metrics cannot be treated as interchangeable.
Represent how lower events combine to produce the top event.
An OR gate means any one input event is sufficient under the stated logic. An AND gate means the modeled combination is required. A common-cause failure may disable redundant trains simultaneously, and should be represented explicitly rather than lost in two supposedly independent branches.
Basic events can include mechanical failures, control failures, utility loss, latent protective-function failures and conditional human or procedural events. Keep the tree consistent with the operating configuration and engineering drawings.
| Logic | Interpretation | Simple example |
|---|---|---|
| OR | Any listed input is sufficient | Either of two required series components fails |
| AND | All listed inputs are necessary for this branch | Both redundant duty-capable pumps unavailable |
| Common-cause input | One event affects more than one nominally separate branch | Shared suction header isolated or common power supply lost |
| Undeveloped event | Known relevant event with insufficient detail | External utility unavailability still being assessed |
A redundant cooling system reveals why AND gates matter.
Fictional example: either of two pumps can supply the required cooling flow. The top event is 'no available cooling supply.' The basic tree is an OR gate between 'shared suction unavailable' and the AND gate 'Pump A unavailable AND Pump B unavailable.' That structure immediately reveals that a shared suction header is a single-point vulnerability.
For illustrative independent fixed-demand unavailability values only, if Pump A unavailability is 0.02 and Pump B is 0.03, their AND-gate probability is 0.0006. If a separate shared-suction event has probability 0.01, the OR of that event and the dual-pump event is 0.010594 using 1 − (1 − 0.01) × (1 − 0.0006). These numbers are hypothetical and assume independence and a common time/demand basis; do not interpret them as a plant risk estimate.
Independence fails when both pumps share the same failed suction, electrical feed, controller, flooding exposure or maintenance practice. Quantification without explicitly modeling these dependencies can significantly understate risk.
Unavailability on demand, failure probability over a mission and hazard rate have different denominators. Do not substitute repair rates or raw failure counts without a defensible probabilistic model.
Identify the smallest combinations that can cause failure.
A minimal cut set is the smallest set of basic events sufficient to produce the top event. In the toy model, a shared-suction loss is one single-event cut set; the concurrent unavailability of both pumps is another two-event cut set.
Prioritize cut sets by consequence and credible occurrence evidence. A high-consequence single-point vulnerability deserves qualified engineering attention even where event frequency is sparse. A logically neat tree does not demonstrate that any basic event actually occurred during the incident.
Connect tree logic to controlled drawings, failure records and engineering review.
Review process and electrical diagrams, alarm history, maintenance records, operating sequences, proof-test coverage and latent-failure exposure. Have engineering verify gate structure, assumptions and common causes. If quantitative values are used, report sources, confidence, calculation horizon and sensitivity to dependency.
Use the analysis to recommend redundancy separation, condition monitoring, documented failure-finding, design changes or other controlled measures. Protective-system tests and bypass decisions require the site's authorized safety and engineering process.
What makes a credible fault tree?
A stable top-event definition, correct gate structure, explicit common causes, transparent uncertainty and a traceable engineering decision. It should reveal a system weakness without pretending that missing probabilities equal zero.
- Use one mission or demand basis throughout.
- Show common-cause dependencies.
- Distinguish qualitative fault logic from estimated probability.
- Refer protective-function decisions to qualified technical authority.
Technical references
- IEC 61025:2006, Fault Tree Analysis — Defines FTA application, event assumptions and standard analysis notation.
- SAE JA1011_202411: Evaluation Criteria for RCM — Evaluation criteria for genuine RCM processes.
Make system vulnerabilities visible.
Use the tree's cut sets to target engineering, control and maintenance measures with explicit consequences.
RCM learning path See facility-specific XRVE services