Skip to main content
    QHSEtech
    Updated
    All glossary terms
    Content date: · No individual check logged· AI use

    Fault Tree AnalysisFTA

    Definition

    A top-down method that traces one undesired event to the combinations of faults and failures that could cause it, using logic gates.

    Editorial definition: The QHSE Standard, updated 3 October 2026 · https://qhsetech.com/glossary/fault-tree-analysis

    What the EPA, IEC and IChemE say about fault tree analysis

    EPA guidance describes fault tree analysis as a deductive technique aimed at one accident or main system failure, giving a way to find the causes of that event. The tree is drawn as a graphic of the equipment failures and human errors that, in combination, can produce the accident. The analysis starts with the accident, identifies its immediate causes, and examines each cause in turn until the basic causes are reached. EPA quotes AIChE that its strength is identifying combinations of basic equipment and human failures, which lets the analyst focus prevention on the significant basic causes, and that it suits highly redundant systems.

    The EPA text distinguishes failures, where a component needs repair, from faults, which clear when conditions change, and divides both into primary, secondary and command faults. An analysis needs close knowledge of the plant, process drawings and procedures at the same level of detail, and an understanding of how components fail. IEC 61025:2006 is the international standard on the technique; its published summary says it covers the technique, guidance on applying it, the assumptions, events and failure modes involved, and the rules and symbols used to identify them. An IChemE bulletin on LOPA adds that fault tree analysis uses Boolean algebra and minimum cut set analysis to allow for common cause failures, which LOPA cannot treat mathematically. Quantified use needs data for each basic event, and the source of every figure belongs in the record.

    In the United States, 29 CFR 1910.119(e) lists fault tree analysis as one methodology an employer may use for a process hazard analysis; it is not required by name. This is general information, not legal or engineering advice, and the IEC text is not reproduced.

    What a fault tree record holds in software

    • The top event, worded precisely, with the system boundary and the conditions assumed.
    • The tree itself: each event, the gate that combines it with others and the level in the tree.
    • The basic events with a description, the failure mode, the type of failure or fault and the source of any data attached.
    • Assumptions, exclusions and the reason for stopping the analysis at each basic event.
    • The minimum combinations of events that cause the top event, where the analysis produces them.
    • The analyst, the reviewers and the revision of the drawings and procedures used.
    • Actions from the analysis, with owner, due date and a check that they worked.

    Fault tree, FMEA, HAZOP and root cause analysis

    A fault tree starts from one unwanted event and works back to its causes. FMEA starts from an item and asks how it could fail, and a HAZOP starts from a process deviation. Root cause analysis works back from an event that has happened, while a fault tree can be built for an accident that an earlier study identified and that has not occurred. The structure of a fault tree does not by itself say how likely the event is, which needs data for the basic events. EPA says it is often used after another technique has identified an accident that needs more detailed analysis.

    A hypothetical example: loss of cooling to a reactor

    The plant and scenario here are invented and describe no real plant. A team has a scenario from an earlier study: loss of cooling to a reactor. They word the top event as loss of cooling water flow to the reactor jacket during a batch. Under it they place two branches joined by an or gate: the pump stops, or the flow path is blocked or closed. Under the pump branch an and gate joins the running pump stopping and its standby failing to start, so one failure alone does not cause the event.

    Reviewing the tree, a colleague points out that the pump and its standby share a power feed, so a power loss would stop both. The team adds that cause beneath the and gate, so that the redundancy no longer looks complete. The action is a separate supply for the standby. The record also notes the assumption that the cooling water supply itself is available, so a loss of supply is outside this tree. The record keeps both versions of the tree, the assumptions about the supply, the reviewer and the date, and the action is tracked to a check that the change was made and the tree updated.

    Common misunderstandings about fault tree analysis

    • A fault tree analyses one chosen event. EPA describes it as focused on one accident or main system failure, so it does not survey a whole process.
    • A tree does not show that redundancy is safe. Common causes can defeat it, which is why combinations and shared causes should be examined explicitly.
    • The top event wording decides what the tree can show. A vague top event leads to a vague tree, so boundaries and conditions should be written down.
    • A tree is only as good as its analysts. EPA notes that experienced analysts and review by others are needed.
    • Drawing the tree is not the same as quantifying it. Any numbers attached to basic events need a source and an owner.
    • Human error is in scope as well as equipment failure. EPA says the tree displays how equipment failures and human errors combine to cause the accident.

    How fault tree analysis relates to other glossary terms

    A fault tree usually follows another study or an event and feeds decisions about actions.

    • FMEA: starts from the item and its failure modes, where a fault tree starts from the event.
    • HAZOP: may identify the accident that then needs more detailed analysis.
    • Root cause analysis: traces causes backwards from something that actually happened.
    • LOPA: treats one scenario at a time and is not suited to common cause failure.

    Records and evidence that usually exist for a fault tree

    • The tree and its top event statement.
    • The drawings and procedures used, with revisions.
    • The data sources for any numbers.
    • The list of assumptions.
    • The study or event that raised the top event.
    • The review record with reviewer and date.
    • The action log and the check that actions worked.

    What a software tool needs to capture for fault tree analysis

    • A graphical editor that stores gates and events as structured records, not only as a picture.
    • Event fields for description, failure mode, data source and owner.
    • Version control, so each revision of the tree is kept with its reviewer.
    • Classification of each failure or fault as primary, secondary or command, if the organisation uses it.
    • A check that every gate has inputs and every basic event has a description.
    • A way to reuse a basic event across trees without losing its source.
    • Links to the HAZOP or incident record that raised the top event.
    • An export of the tree and its assumptions for a reviewer or regulator.

    Catalog profiles documenting root cause analysis

    The list follows the root cause analysis rule. Whether a product draws fault trees or finds cut sets is not shown by it and should be tested in a demonstration.

    Same rule for every product: tagged “Root Cause & Investigation”, “Incident Management”, “Incident Reporting”, “CAPA Management”, “Quality Management”, “Safety Management”, “EHS Management”, “Occupational Health”, “Risk Assessment”, “Risk Management”, “Food Safety”, “Audits & Inspections” or “Barrier Management”, with a sourced root cause analysis capability in its record, or one the vendor stated to us, labelled as vendor-stated. Documented and conditional capabilities qualify; check the linked scope before treating a module as included.

    Tekmon pays for a sponsored placement (above); its place in this list follows the same rule as every entry. How lists are ordered

    All 48 matching profiles are shown. Documentation review, not hands-on testing or a claim of compliance.

    Related software

    Frequently asked questions

    When is a fault tree used instead of a HAZOP?

    EPA guidance says an FTA is often chosen after another technique has flagged an accident needing closer analysis, and that FMEA or HAZOP suit systems vulnerable to single failures better. It is suited to analysing combinations of failures.

    Who builds a fault tree?

    EPA guidance says one analyst can develop it, but it needs input and review from others, well-trained and experienced analysts, and a thorough understanding of how the plant or system works.

    Does OSHA require fault tree analysis?

    No. 29 CFR 1910.119(e) lists it as one acceptable methodology for the process hazard analysis of covered processes, with what-if, checklist, HAZOP, FMEA and an appropriate equivalent.

    More safety terms