What Is Failure Mode and Effects Analysis (FMEA)?

Failure mode and effects analysis (FMEA) is a systematic method for identifying the ways each item of a system, design or process can fail, and determining the effect of each of those failure modes. An item may be a part, a function or a process step. Each failure mode's effect is traced at three levels: on the item itself, on the assembly that contains it, and on the system as a whole. The failure modes are then ranked, by the severity of their effects and sometimes also by their likelihood and detectability, so that corrective action goes first to the most serious.

The method is preventive: it is intended to find weaknesses during design, while the design or process can still be changed at reasonable cost, rather than in test or in service. A completed FMEA is also a record of the failure modes identified, the actions decided and the assumptions the analysis rests on.

FMEA is a core task in reliability, safety and quality engineering. In quality engineering it is applied to manufacturing processes as well as to products. In systems engineering it is one of the specialty engineering analyses that inform design decisions.

This guide covers the method's vocabulary, the direction in which it reasons, how an analysis is carried out, how failure modes are ranked, what the worksheet records, and the method's limits. It closes with Qantas Flight 72, a case that shows the method's central limit.

The vocabulary

The method depends on keeping several closely related terms distinct.

• Failure: the loss of a function under stated conditions. The item no longer performs as required.
• Failure mode: the manner in which a failure is observed. An axle can fracture fully or deform; an electrical contact can stick open, stick short or become intermittent. Each is a separate failure mode of the same item, and each may have different consequences. When the analysis is applied to functions rather than hardware, failure modes are usually expressed as a generic set: no function, partial or degraded function, intermittent function, excessive function and unintended function.
• Failure cause: the reason a failure mode occurs, for example a physical or chemical process, a design defect, a manufacturing defect, misapplication of a part, or an error in handling or operation. One failure mode can have several causes.
• Failure mechanism: the process by which a cause develops into the failure mode over time. Fatigue, corrosion and creep are mechanisms; the fractured beam or open contact they produce is the failure mode.
• Failure effect: the consequence of a failure mode for the operation, function or status of the system.
• Severity: the seriousness of the worst credible consequence of a failure mode, judged by injury, property damage, system damage or loss of mission.
• Detection: how, and how quickly, a failure mode is discovered once it has occurred: by the operator in normal use, by a maintainer through a diagnostic action, or by built-in test. A failure mode that would not be discovered is recorded as undetectable, which is itself a significant finding.
• Single failure point: a failure of one item that would cause the system to fail and is not compensated for by redundancy or an alternative operating procedure. Identifying single failure points is one of the principal purposes of an FMEA.

Indenture levels

Failure effects are traced upwards through the system's breakdown structure, whose levels are called indenture levels:

• the local effect, on the item being analysed;
• the next higher level effect, on the assembly or subsystem that contains it;
• the end effect, on the system as a whole.

An FMEA states the indenture level at which it starts and the lowest level to which it is taken.

How the analysis reasons: forward, one failure mode at a time

With those terms defined, the method's logic can be stated simply. FMEA is an inductive, or forward-logic, analysis: it starts from a postulated failure mode of one item and determines its effects. Fault tree analysis (FTA) works in the opposite direction. It is deductive, starting from one specified undesired event at system level and working back to the combinations of lower-level failures that could cause it.

The two methods are complementary. FMEA identifies the failure modes of individual items and their local and system effects. FTA shows how combinations of faults, including external events, lead to one specified outcome. Where both are used, FMEA records can supply the basic events of a fault tree.

Each failure mode is normally analysed as though it were the only failure in the system. This single-failure assumption keeps the analysis tractable, and it is also its main limitation. It is supplemented in two cases:

• where a failure mode would remain undetected, the analysis considers the effect of a second failure occurring while the first is still undetected;
• where safety devices, redundant channels or back-up items exist, the analysis considers the failures that made them necessary, to confirm that a single failure cannot defeat the protection itself.

Hardware or functional approach

The items to be analysed can be listed in two ways. The hardware approach lists physical items from drawings, schematics and parts lists, and analyses the failure modes of each. It is normally worked from part level upwards and requires a design mature enough for the parts to be identified.

The functional approach lists the functions, or outputs, each item exists to provide and analyses how each function could fail. It is normally worked from system level downwards, so it can be applied before the hardware is defined, to concept designs, and to software as well as hardware.

Complex systems are often analysed with a combination of the two. Either approach can begin at any indenture level and proceed in either direction. FMEA is therefore defined more accurately by its direction of reasoning, from failure mode to effect, than by the term "bottom-up".

How to carry out an FMEA

Applying that reasoning to a real design or process is a team activity. The failure modes of a design or process are rarely known in full to one person, so the analysis draws on design, manufacturing, test, reliability, maintenance and operations, and where possible suppliers and users. Its quality depends on that breadth of experience, on data from similar products and processes, and on test and field data fed back as it becomes available.

Ground rules and assumptions

Before the analysis starts, the team agrees its ground rules and assumptions and records them with it. These define the approach (hardware, functional or combined), the indenture levels covered, what constitutes a failure in terms of performance limits, what hardware is included and excluded and why, and the operating conditions assumed. Typical assumptions are that only one failure mode exists at a time, that all inputs to the item are present at nominal values, and that power and consumables are available. Ground rules may be added as requirements change, but each is documented, because the conclusions of an FMEA are valid only within them.

The sequence

1. Define the scope and boundaries of the analysis, often with a block diagram of the system or a flow diagram of the process, and set the ground rules and the rating scales to be used in step 7.
2. List the functions of the system and of each item within scope.
3. For each item or function, identify the potential failure modes. Every later step depends on this one.
4. For each failure mode, trace the effects through the indenture levels and assign a severity to the worst end effect.
5. Identify the causes of each failure mode and estimate their likelihood.
6. Identify the existing controls that prevent the cause or detect the failure, and assess the effectiveness of detection.
7. Rank the failure modes, using one of the schemes described in the next section.
8. Decide and assign actions, implement them, and re-assess the ranking.

The preferred response to a serious failure mode is to change the design or process so that the failure mode is eliminated or its cause removed. Where that is not possible, the options are to reduce its likelihood, to add redundancy so that it no longer causes a system failure, to improve detection so that it is found before it has an effect, or to provide an operator procedure that compensates for it.

Start early and keep it current

Timing is probably the most important consideration. An FMEA is most valuable when started early in design, as soon as preliminary design information exists, and extended to lower indenture levels as the detailed design matures. Performed after the hardware is built, it can still record risk, but it can no longer influence the design at reasonable cost.

An FMEA is also a living document. It is updated when the design changes, when operating conditions or the way the product is used change, when an existing design is applied in a new way, when new regulations apply, and when failures in test or service reveal something the analysis missed.

Ranking failure modes: severity, criticality, RPN and action priority

Step 7, ranking, is needed because an analysis of a real system may identify hundreds or thousands of failure modes. Four schemes are described below.

By severity alone

The long-standing US military standard for the method, MIL-STD-1629A, defines four severity categories:

• Catastrophic: a failure that may cause death or loss of the system.
• Critical: severe injury, major damage or loss of the mission.
• Marginal: minor injury or damage resulting in delay, loss of availability or degraded mission.
• Minor: no injury or damage, but unscheduled maintenance or repair.

The first priority for corrective action is always the most severe failure modes, regardless of how rare they are thought to be.

By criticality (FMECA)

Criticality analysis adds likelihood. Each failure mode is ranked by the combined influence of its severity and its probability of occurrence, often by placing it on a criticality matrix. The result is a list of failure modes ordered by their contribution to risk, and a critical items list of the items whose failure modes rank highest. Probability may be estimated on a ranked qualitative scale, or calculated from reliability prediction data and catalogues of the typical distribution of failure modes for each part type.

When the ranking step is formalised as a separate criticality analysis in this way, the combined method is called failure mode, effects and criticality analysis (FMECA). The two names are often used interchangeably. Strictly, FMEA identifies failure modes and their effects, and FMECA adds a systematic ranking of each failure mode by criticality.

By risk priority number (RPN)

In quality engineering, particularly in the automotive and process industries, ranking has long used the risk priority number (RPN): the product of three ratings, for severity, occurrence and detection, each typically scored from one to ten. The RPN is simple to calculate and gives a single value to sort by, but it has recognised weaknesses:

• The three ratings are ordinal: they indicate that one score is worse than another, not by how much. Multiplying them treats them as true quantities, which they are not.
• As a result, the product can rank a less serious failure mode above a more serious one.
• Using an RPN threshold to trigger action encourages teams to adjust scores to fall below the threshold, rather than to reduce the underlying risk.

By action priority

For these reasons, the harmonised automotive FMEA handbook published in 2019 replaced the RPN with an action priority: a rule-based rating of how urgently each combination of severity, occurrence and detection requires further action. Many practitioners also treat any high-severity failure mode as requiring action, whatever its other ratings.

What an FMEA worksheet records

Every step of the sequence is recorded on the FMEA worksheet, one row per failure mode. Formats vary between standards, industries and organisations, but a typical row records:

• the item and its function;
• the failure mode;
• its possible causes or mechanisms;
• the phase of operation in which it applies, where relevant;
• the local, next higher level and end effects;
• the severity of the end effect;
• an estimate of the likelihood of the failure mode or its cause;
• the means of detection, and how long the failure could remain undetected;
• existing provisions that compensate for or mitigate it;
• the resulting risk ranking;
• recommended actions and their owners.

Further columns record the actions taken and the re-assessed ranking, so the worksheet shows the risk before and after action.

What the results are used for

The completed worksheet serves several purposes beyond the ranked list of failure modes:

• Design decisions. FMEA identifies single failure points and interface problems early, and gives a documented basis for comparing design options and evaluating the effect of proposed changes on safety and mission success.
• Requirements. The mitigations it identifies become requirements on the design, on suppliers or on the process: a redundant channel, a part classified as critical, a tolerance to be controlled.
• Checking redundancy. It verifies that switching between redundant elements cannot itself be defeated by a single failure.
• Test planning. It provides criteria for planning tests and identifies the failure modes testing must cover.
• Diagnostics and monitoring. It indicates where to place performance monitoring, fault-detection devices and built-in test, and provides a basis for troubleshooting procedures.
• Maintenance. It identifies critical functions and items, and feeds reliability-centred maintenance, in which each failure mode is assessed for whether preventive maintenance is justified or the design must change.
• Other analyses. Its records are inputs to fault tree analysis, hazard analysis and reliability prediction.

Types of FMEA

The same method is applied to different subjects, giving several variants:

• Functional FMEA analyses a system's functions before, or independently of, the detailed design, and is used to derive "design to" requirements early.
• Design FMEA (DFMEA) analyses a product design, from concept level down to individual parts. The most detailed form, covering every part, is called piece-part or hardware FMEA.
• Process FMEA (PFMEA) analyses the steps of a manufacturing, assembly or service process: how each step could fail, and the effect on the product or the customer.
• Software FMEA identifies failure modes that originate in software requirements, design, code or interfaces, working from known categories of software defect rather than treating the software as a black box.
• Failure modes, effects and diagnostic analysis (FMEDA) extends a design FMEA with quantitative data: each component's failure rate and distribution of failure modes, and the effectiveness of automatic diagnostics and periodic tests in detecting each one. It is used in functional safety, where each failure mode is classified by its effect on the safety function (for example, safe or dangerous). The functional safety standard IEC 61508 includes it as a method for determining a device's failure rates, failure modes and diagnostic coverage.

Related methods apply the same logic to human error in operation and maintenance, and to failure mechanisms, where the physical processes leading to failure are modelled explicitly.

A short history

Procedures for the method originated with the US military; the earliest document usually cited is MIL-P-1629 of 1949. The long-standing US defence standard, MIL-STD-1629A, was issued in November 1980. By the early 1960s NASA's contractors were using variations of the method on space programmes.

Civil aviation was an early adopter. SAE published an aerospace recommended practice for the method, ARP926, in 1967; it has since been replaced by ARP4761, now broadly used in civil aviation. Use spread to other industries during the 1970s. The automotive industry had adopted it by the mid-1970s, extended it to manufacturing processes, and later standardised it through its own handbooks, harmonised in 2019.

The international standard for the method is IEC 60812, current edition 2018. It applies to hardware, software, processes including human action, and the interfaces between them, and is written generically rather than for a single application. FMEA is now used in defence, space, civil aviation, automotive, semiconductor processing, plastics, food, software and healthcare, among other industries.

Limits of FMEA

The method's strengths and its limits arise from the same features.

• Its coverage is set by the team and the scope. The analysis covers the failure modes the team identifies, at the indenture levels and within the ground rules it has set. Failure modes known from similar products and from the physics of failure are the most likely to be included. A failure mode nobody anticipated, or an item or interface outside the scope, is not analysed. In healthcare settings, FMEA used on its own has been found to have limited validity, with scoping and organisational boundaries a major factor.
• It is weak on combinations. Because each failure mode is normally considered alone, FMEA does not by itself reveal failures that matter only in combination, or the effects of external events. Fault tree analysis is normally used alongside it for the combinations of most concern.
• Its rankings are judgements. Severity, occurrence and detection ratings are often estimates, sometimes made with little data, and scoring schemes such as the RPN can distort priorities.
• It is laborious. A thorough analysis of a complex system is large, difficult to read and difficult to keep up to date. The effort can lead organisations to treat it as a document to complete rather than an analysis to use, and an FMEA completed after the design is fixed has lost most of its value.

For these reasons FMEA is used alongside other analyses, test and feedback from real failures, not in place of them.

Case study: Qantas Flight 72 (2008)

The first of those limits can be seen in a real investigation. On 7 October 2008 an Airbus A330, registered VH-QPA and operating as Qantas Flight 72 from Singapore to Perth, was cruising at 37,000 ft when one of its three air data inertial reference units (ADIRUs) began sending intermittent, incorrect values, or spikes, on all its flight parameters to other aircraft systems. About two minutes later the flight control primary computers, responding to spikes in angle-of-attack data, commanded the aircraft to pitch down. A second, less severe pitch-down followed. At least 119 of the 315 people on board were injured, 12 of them seriously, and the aircraft diverted to Learmonth, Western Australia.

The Australian Transport Safety Bureau (ATSB) found two factors in combination:

• An unidentified failure mode. The ADIRU had a data-spike failure mode that had "not been previously encountered, or identified by the ADIRU manufacturer in its safety analysis activities". The unit's built-in test equipment was designed to detect almost all potential problems, including the failure modes the aircraft manufacturer had identified, but none of its tests was designed to detect this one. The spikes were passed on as valid data, without a fault message.
• An unconsidered effect. The flight computers' algorithm for rejecting erroneous angle-of-attack values could not correctly handle multiple spikes 1.2 seconds apart. The peer reviews, system safety assessment, testing and simulation carried out when the flight control system was developed had not found that limitation.

The failure mode was observed three times in over 128 million hours of unit operation.

The principle. A failure-mode analysis can address only the failure modes and effects it contains. Detection, mitigation and design protection are all designed against that list. A failure mode that was never identified has no detection designed for it, and an effect that was never considered has no protection designed against it.

Summary

FMEA identifies the failure modes of each item, determines the effect of each at the item, the next higher assembly and the system, ranks the failure modes so that the most serious are addressed first, and records the actions taken. It is most effective when started early in design, carried out by a team with broad experience, governed by explicit ground rules, and kept current as the design changes. Its results are only as complete as the list of failure modes and effects it contains.

Sources

• US Department of Defense, MIL-STD-1629A: Procedures for Performing a Failure Mode, Effects and Criticality Analysis, 24 November 1980.
• IEC 60812:2018, Failure modes and effects analysis (FMEA and FMECA), publication abstract, IEC Webstore.
• American Society for Quality, FMEA (asq.org/quality-resources/fmea), reviewed November 2024.
• Australian Transport Safety Bureau, In-flight upset, Airbus A330-303, VH-QPA, 154 km west of Learmonth, Western Australia, 7 October 2008, AO-2008-070, final report, 19 December 2011.
• Quality-One International, Failure Mode and Effects Analysis (FMEA).
• J. Kovacevic, The Failure Mode Effect Analysis, Accendo Reliability, 2021.
• B. S. Blanchard, Systems Engineering Management.
• Wikipedia, Failure mode and effects analysis and Failure modes, effects, and diagnostic analysis (accessed 30 September 2026).