FMEA and FTA compared

The questions differ

FMEA asks, “If this function fails in this way, what are the effects?” It moves from a selected failure mode toward its consequences. It is often called bottom-up, although a functional FMEA can begin at a high system level rather than at individual parts.

FTA asks, “What is sufficient to produce this specified outcome?” It works deductively from a top event toward contributing conditions. The public scopes of IEC 60812:2018 and IEC 61025:2006 describe the respective methods.

Neither question is complete without a boundary. The same component failure may have different consequences during startup, normal operation or maintenance. Two analyses cannot be meaningfully reconciled if they silently assume different configurations.

Choose the starting point by the decision

Start with a functional inventory and FMEA when the team needs to identify failure modes, understand local-to-system effects, examine interfaces or assign improvement actions across a design or process.

Start with FTA when the decision concerns a defined loss of function, a claimed redundant arrangement, a possible single-point vulnerability, or combinations that defeat a protective function. A qualitative tree may be enough to discover a structural weakness; numerical inputs are not a prerequisite for useful reasoning.

Use both when broad coverage and particular system-level concerns matter. The order is flexible. An FMEA can suggest a top event, and a fault tree can reveal a dependency that the FMEA missed. Do not make an automatic workflow rule out of one project's successful sequence.

One system, two useful views

Consider the same invented teaching cabinet used in the companion guides: two parallel fans, either sufficient for airflow, a shared supply and an indicator that does not control the fans. A valid start command and a clear air path are assumed. The example is conceptual and contains no equipment-specific instructions.

1. Build an FMEA view. “Fan A does not start” has a local effect of no flow from that fan. If B works as assumed, the cabinet retains airflow but loses redundancy. The shared supply's loss can affect both fans. An indicator stuck at normal can conceal a failure without causing the physical loss itself.

2. Select an FTA question. Define the top event as failure to establish required airflow on a start demand. With C for supply unavailability and A and B for the fans' intrinsic startup failures, the teaching logic is T = C OR (A AND B).

3. Reconcile the views. The FMEA's individual fan rows support the event definitions. The tree shows how their failures combine and why the shared supply alone is sufficient. The indicator row remains relevant to the wider analysis even though it does not cause this top event.

4. Ask a different question when needed. “Loss of airflow is not indicated” is a different top event. A simplified formulation would combine airflow loss with a detection-failure condition, but its exact logic depends on the indicator, timing and response requirements. Do not insert the indicator into the first tree simply to make every worksheet row appear somewhere.

5. Examine a proposed change. Adding another supply might remove one shared dependency but introduce switching or monitoring requirements. Revise both models and verify the actual arrangement before claiming improved performance.

The joint benefit is traceability: a reader can move from function to failure mode, from failure mode to system outcome, and from an identified concern to the evidence needed for a change.

Transfer definitions and evidence, not scores

A useful cross-reference records the FMEA row identifier, the relevant fault-tree event, operating phase, applicable configuration, failure criterion and data source. The mapping need not be one-to-one. One broad worksheet row may need several events; one shared event may explain effects recorded in multiple rows.

For example, a row labeled “fan unavailable” may combine failure to start, running failure and maintenance unavailability. A startup tree needs the startup event, with data appropriate to that condition. Copying the broad row's number without checking the definition creates a false correspondence.

NASA's fault-tree handbook, Section 4.8 cautions that assembling FMEA results is not sufficient to construct a fault tree. System relationships must be established through the deductive analysis.

Keep the outputs and units distinct

An FMEA or FMECA may report severity classes, priority categories or an RPN. FMECA adds criticality assessment; it can use qualitative or quantitative approaches appropriate to its procedure and evidence. Its name does not establish the statistical meaning of an output.

An ordinal RPN of 60 cannot be compared numerically with a fault-tree probability of 0.003. Nor can 60 be divided by the maximum possible RPN to obtain a probability. The underlying scales and questions differ. The known limitations of ordinal RPN arithmetic are discussed in Bowles's paper.

A quantified FTA might estimate probability per demand, unreliability over a stated interval, or unavailability under a defined model. Event frequency requires an appropriate time-based formulation. Label each output precisely. A probability by itself also does not describe the magnitude of consequences; system risk decisions need that context.

Use a shared evidence register without forcing one-to-one mapping

A small common register can hold function identifiers, configuration, operating state, failure criteria, evidence references and unresolved assumptions. FMEA rows and fault-tree events can then point to that register without pretending they are identical objects. A cause appearing in several FMEA effects may correspond to one shared event in the tree. Conversely, one broad failure-mode row may require several precisely defined events for different demands.

For an authored example, give the shared power supply the identifier SUP-1 and preserve it wherever referenced. The FMEA can record its consequences for both fan paths. The FTA retains one supply-unavailable event. Duplicating the identifier as two independent events would change the model’s meaning. A consistent identifier supports traceability, but it does not establish the event’s probability or independence from other causes.

Reconcile discrepancies as questions about the system

Suppose an FMEA says either fan can meet the function, while a fault tree uses an OR gate between fan failures. Under the same configuration and success criterion, those statements disagree: if either is sufficient, both path failures are needed in that branch. The right response is to check the function and state before editing the gate. Perhaps one document assumes full load and the other reduced load.

Alternatively, the tree may legitimately address a different top event, such as loss of redundancy rather than loss of airflow. That event can occur when one fan fails. The same diagram shape can therefore be correct or incorrect depending on the definition. Reconciliation should preserve these distinctions instead of making the documents visually match at the cost of meaning.

A maintenance scenario changes both views

In the invented two-fan system, take fan B out of service in an explicitly assumed maintenance state. The FMEA effect of fan A failing to start now changes from loss of redundancy to loss of the required airflow. The FTA must represent B’s known unavailability or use a configuration-specific reduced tree. Retaining both-fan availability while describing maintenance would overstate the remaining function.

This is not a recommendation to operate in that state. It shows why configuration is a shared input to both methods. A useful change review asks what happens during the transition into maintenance, throughout the work and during restoration. Proposed compensating measures remain proposals until their capability and implementation are supported by appropriate evidence.

Select the next method by the unresolved question

If the remaining concern is response order after an initiating event, an event tree may clarify the sequences. If the issue is changing state, repair or switching delay, a static fault tree may need a more suitable temporal model. If the issue is whether a failure mechanism was overlooked, returning to functional and interface analysis may be more useful than refining a probability to another decimal place.

The public scope of IEC 60812 describes a generic method and explicitly distinguishes it from application-specific safety guidance. That is a useful reminder for the combined workflow: neither FMEA nor FTA supplies all domain requirements. Choose the next analytical step because it closes an identified evidence gap, and keep the eventual conclusion bounded by what the methods actually established.

Close the loop with evidence

Keep one agreed configuration baseline and a shared vocabulary. Record unresolved dependencies, uncertain data, exclusions and assumptions. Assign proposed changes to owners, then distinguish implementation from verification. A promised test is not a passed test.

When evidence changes, revisit both the relevant failure effects and the tree logic or parameters. NASA's 2024 GSFC FMECA guidance emphasizes updating the analysis as design and operational knowledge develops.

Before relying on the pair, ask: do the analyses use the same boundary, represent shared causes consistently, preserve event identities, and explain the basis of every numerical result? Do the remaining uncertainties affect the decision? Neither method guarantees exhaustive hazard discovery, replaces domain-specific requirements, or establishes certification. Their strongest shared output is an inspectable argument about what can go wrong and why a proposed action should help.