Every system has the potential to fail. The challenge for engineers is identifying how it could fail, what would happen if it did, and which potential failures deserve attention first.
That is where Failure Mode and Effects Analysis (FMEA) comes in.
Failure Mode and Effects Analysis is a structured risk analysis method used to identify potential failures before they occur, evaluate their possible effects, and prioritize actions to reduce risk. By proactively analyzing what could go wrong, engineering teams can make better-informed design decisions and improve system reliability, safety, and performance throughout the engineering lifecycle.
In this blog, we'll explain what FMEA is, how it works, the different types of FMEA, how risk is evaluated, and how FMEA can be incorporated into a model-based systems engineering approach.
FMEA stands for Failure Mode and Effects Analysis. It is a proactive method for identifying and evaluating potential failures within a product, process, or system.
According to the American Society for Quality (ASQ), FMEA is a systematic, step-by-step approach for identifying and prioritizing possible failures. It can be applied to designs, manufacturing and assembly processes, products, services, and other systems.
The name itself describes the two primary parts of the analysis:
Failure mode: The specific way in which a component, process, function, or system could fail to perform as intended.
Effects analysis: The evaluation of the consequences that could result from that failure.
For example, imagine a vehicle experiencing an engine failure. Potential effects could include the need for a tow truck, delays while waiting for assistance, transportation to a repair station, and additional towing or repair costs.
Rather than waiting for that failure to occur, FMEA helps engineers identify it in advance, assess its potential impact, and determine what actions could reduce the associated risk.
FMEA gives engineering teams a structured way to ask an essential question: What could go wrong? More importantly, it helps them determine what to do about it.
FMEA can help organizations:
Identify potential failures early in development
Understand the effects and causes of potential failures
Prioritize risks based on their significance
Improve system safety and reliability
Identify opportunities for design or process improvements
Document risk-related engineering decisions
Support verification and validation planning
Capture knowledge that can be reused on future projects
Performing FMEA early can be particularly valuable because potential problems may be easier and less expensive to address before a design or process has been finalized.
ASQ recommends beginning FMEA during the earliest conceptual stages of a design when possible and continuing to use it throughout the life of the product or service.
FMEA does not have to be reserved for a completed design. In fact, its proactive nature makes it particularly useful before failures have occurred.
Teams may perform an FMEA:
During early system or product design
When introducing a new process
When modifying an existing design or process
When applying an existing product or process in a new environment
When analyzing an existing system for opportunities to improve reliability
After engineering changes that could introduce new risks
When new failure data or lessons learned become available
An FMEA should also be treated as more than a one-time deliverable. As requirements, designs, components, processes, and operational conditions change, the analysis may need to change with them.
FMEA can be applied at different levels depending on what a team needs to analyze.
A System FMEA examines potential failures at the system or subsystem level. It considers how failures within different parts of a system could affect overall system performance, mission objectives, safety, or other critical outcomes.
This type of FMEA can be especially valuable in systems engineering because it provides a way to analyze failures in the context of the broader system.
A Design FMEA, or DFMEA, focuses on potential failure modes associated with a product or system's design.
Teams can use DFMEA to evaluate components, functions, interfaces, materials, design characteristics, and other factors that could contribute to failure.
The goal is to identify and reduce design-related risks before the product or system reaches later lifecycle stages.
A Process FMEA, or PFMEA, focuses on how a manufacturing, assembly, operational, or other process could fail.
Instead of asking only whether the design will work, PFMEA asks what could go wrong while that design is being produced or a process is being executed.
For example, a PFMEA might evaluate incorrect assembly, missing process steps, improper settings, or variations that could affect the resulting product.
Although these approaches have different scopes, they share the same fundamental objective: identify potential failures and reduce their associated risk before they create larger problems.
Different organizations and industries may structure their FMEA processes differently, but the fundamental process generally involves defining what is being analyzed, identifying potential failure modes and their effects, evaluating risk, and determining appropriate actions.
At a high level, an engineering team will:
Define the scope. Determine the system, subsystem, product, design, or process being analyzed and establish its boundaries.
Identify functions. Understand what each element is intended to do.
Identify potential failure modes. Determine the ways those functions, components, or processes could fail.
Identify failure effects. Determine what could happen if each failure occurs.
Identify potential causes. Analyze why each failure might occur.
Evaluate risk. Assess factors such as severity, occurrence, and detection.
Prioritize and take action. Determine which risks require attention and identify actions that can reduce them.
Reevaluate. Review the analysis after mitigation actions or engineering changes to determine whether the risk has been reduced.
Some FMEA methodologies formalize these activities differently. For example, the AIAG-VDA approach used in the automotive industry organizes FMEA into seven steps: planning and preparation, structure analysis, function analysis, failure analysis, risk analysis, optimization, and results documentation.
Regardless of the methodology used, the objective remains proactive risk identification and mitigation.
📖 Related Reading: How to Perform Risk Management
Traditional FMEA commonly evaluates potential failures using three factors: severity, occurrence, and detection.
Severity (S) represents the seriousness of the consequences if a failure occurs.
A failure that causes a minor inconvenience would typically receive a lower severity rating than one that could cause complete system loss or create a serious safety hazard.
Occurrence (O) represents how likely a cause of failure is to occur.
Failures that are expected to occur frequently receive a higher occurrence rating than failures considered highly unlikely.
Detection (D) evaluates the likelihood that existing controls will detect the cause or failure before the resulting effect occurs or reaches the end user.
A failure that is difficult to detect generally represents greater risk than one that existing controls can reliably identify.
Together, these factors give teams a structured way to compare potential failures and determine where mitigation efforts may have the greatest impact.
One traditional method for prioritizing failure modes is the Risk Priority Number (RPN).
RPN is calculated by multiplying the three FMEA ratings: RPN = Severity × Occurrence × Detection
For example, suppose a potential failure has the following ratings:
Severity = 8
Occurrence = 4
Detection = 5
The resulting RPN would be: 8 × 4 × 5 = 160
Teams can use RPN values to help compare potential failure modes and identify areas that may warrant additional investigation or mitigation.
However, RPN should not be treated as the only indicator of risk. Two failure modes can produce the same RPN despite having very different severity, occurrence, and detection ratings. A particularly severe failure, for example, may still warrant action even when its overall RPN is not among the highest.
Modern FMEA methodologies may use additional approaches for prioritizing action. The AIAG-VDA methodology, for example, introduced **Action Priority (AP)** to prioritize recommended actions based on combinations of severity, occurrence, and detection rather than relying solely on the multiplication of those scores.
Failure Mode, Effects, and Criticality Analysis (FMECA) expands on FMEA by incorporating a more detailed evaluation of the criticality of identified failure modes.
Both methods identify potential failures and their effects. FMECA adds criticality analysis to help teams further evaluate and prioritize those failures based on their importance or risk.
The appropriate approach depends on the project, organization, industry, and applicable requirements.
📖 Related Reading: Use Innoslate to Perform Failure Mode, Effects, & Criticality Analysis (FMECA)
FMEA and Fault Tree Analysis (FTA) are both methods used to identify and evaluate potential failures, but they approach failure analysis differently.
FMEA generally takes a bottom-up approach, starting with potential failure modes and examining their effects on the system. FTA takes a top-down approach, beginning with an undesirable event or system failure and analyzing the combinations of events that could cause it.
The two methods can complement one another in systems engineering. FMEA can help teams identify individual failure modes and their effects, while FTA can help engineers understand how multiple failures or conditions could contribute to a larger system-level event.
Consider a simplified unmanned aerial vehicle (UAV). One of its functions is to provide electrical power to the propulsion system.
A simplified failure chain might look like this:
.webp?width=910&height=134&name=FMEA%20Example%20(1).webp)
The engineering team could then investigate potential causes of the overheating, evaluate its severity, occurrence, and detection, and identify mitigations.
Potential actions might include changing the battery design, adding temperature monitoring, introducing redundant power capabilities, or defining additional verification activities.
This is a simplified example, but it demonstrates an important aspect of FMEA: a failure should be analyzed in the context of what it affects.
For complex systems, failures rarely exist in isolation. A failed component can affect a function. That function may support a requirement. The resulting effect may introduce a system-level risk, require a mitigation, or lead to additional verification and validation activities.
This makes FMEA particularly valuable when it is connected to the broader systems engineering process.
A model-based approach can establish relationships such as:
.webp?width=850&height=154&name=FMEA%20in%20systems%20engineering%20(1).webp)
These connections create traceability between the failure analysis and the rest of the system model.
For example, when a component changes, engineers can evaluate which failure modes are associated with it and what downstream requirements, functions, risks, or verification activities could be affected.
Instead of treating FMEA as an isolated document, the analysis becomes part of the evolving engineering model.
📖 Related Reading: 8 Systems Engineering Fails in Jurassic Park
Innoslate enables engineering teams to conduct FMEA within the same model-based environment used for systems engineering, requirements management, modeling and simulation, risk analysis, and verification and validation.
Rather than maintaining failure analysis separately from the rest of the project, teams can connect failure-related information to other elements of the system model.
In Innoslate, engineers can model failure modes and evaluate their impact on system behavior using simulation. Severity, occurrence, and detectability can be used to calculate Risk Priority Numbers, helping teams identify and prioritize potential risks.
Engineers can also use simulation to analyze how failures may affect project elements, including their potential impact on cost, schedule, and performance.
For a hands-on example, follow the Failure Modes & Effects Analysis (FMEA) Walkthrough to see how FMEA can be performed using Innoslate's simulation capabilities. The walkthrough also includes an FMEA project that you can download and explore in Innoslate.
Failure Mode and Effects Analysis is most valuable when it is not treated as a box to check at a single point in development.
Systems evolve. Requirements change. Designs mature. New test results become available. Components are replaced. New failure data emerges.
The corresponding failure analysis should be able to evolve with them.
Connecting FMEA with requirements, system architecture, risk management, simulation, and verification helps engineering teams maintain a clearer picture of how potential failures could affect the overall system.
By identifying those failures early and maintaining that knowledge throughout development, teams can make more informed decisions and proactively improve system reliability, safety, and performance.
Move beyond standalone failure analysis by connecting potential failures to the rest of your system model.
With Innoslate, you can use model-based systems engineering and simulation capabilities to analyze failure modes, understand their effects, evaluate risk, and maintain traceability across your engineering data.
Start Modeling in Innoslate's Free Forever Sandbox
%20(200%20%C3%97%20100%20px)%20(800%20%C3%97%20400%20px)%20(4).png)
.svg){kind=small}
Steven Dam : 6/9/22, 2:35 PM
“Failure Mode and Effects Analysis (FMEA) and Failure Modes, Effects and Criticality Analysis (FMECA) are methodologies designed to identify...
.svg){kind=small}
SPEC Innovations Team : 10/23/24, 1:14 PM
Don't feel like reading? Watch the webinar recording instead!
.png)