Types of FMEA: Definitions, Differences, and When to Use Each
The Essential Guide to Requirements Management and Traceability
Types of FMEA: Definitions, Differences, and When to Use Each
Failure Mode and Effects Analysis (FMEA) gives engineering teams a structured way to find potential failures early, while fixes are cheap and design changes are still on the table. Each FMEA type targets a different failure domain, and choosing the right one means your analysis matches what you’re actually building and how it could fail.
With five major types and several specialized variants, knowing which FMEA to run and when saves teams from duplicated effort or missed risks. This guide covers the major types (DFMEA, PFMEA, SFMEA, FMEA-MSR, and FMECA), their practical differences, and how they connect to the core FMEA workflow and traceability.
What is FMEA?
Failure Mode and Effects Analysis (FMEA) is a proactive method for finding potential failures before they happen. For each failure mode, teams evaluate what effect it would have and what’s causing it, then prioritize corrective actions based on risk. The most widely referenced methodology is the 2019 AIAG-VDA FMEA Handbook.
FMEA is standard practice across automotive, aerospace, medical device, and industrial manufacturing. The core value is the same in every domain. It forces teams to make failure assumptions explicit while there’s still time to change the design or the process.
Why FMEA Matters for Product Development
For teams building regulated products, FMEA is often part of the evidence trail for regulatory submissions and audits. The FDA explicitly lists FMEA among commonly used risk analysis techniques. Beyond the compliance angle, teams also get practical engineering value from running FMEAs early and maintaining them through the program lifecycle:
- Late-stage cost avoidance: Catching a failure mode during design review costs a fraction of catching it at integration or in the field.
- Feedback into future programs: Field issues and nonconformances feed back into severity assumptions and control effectiveness for the next product.
- Cross-functional alignment: The FMEA process pulls design, manufacturing, quality, and test engineers into the same structured conversation about risk.
Teams get the most value when FMEA is treated as a living analysis that gets updated with each design change, not as a one-time compliance exercise.
Types of FMEA
Five major FMEA types cover different failure domains. The right choice depends on whether you’re analyzing a design, a manufacturing process, a system-level interaction, an in-use monitoring response, or a mission-critical application.
Design FMEA (DFMEA)
DFMEA examines what could fail in the design itself. The analysis covers component functions, material properties, geometric tolerances, and interfaces with connected parts.
DFMEA should start during concept and architecture and keep getting updated as design details mature. Its primary outputs include a Design Verification Plan and prevention actions that feed directly into process planning as outlined in this FMEA guide.
Process FMEA (PFMEA)
PFMEA analyzes how the manufacturing or assembly process itself could introduce defects. The analysis often covers six source categories known as the 6M factors (human factors, equipment, materials, methods, measurement, and environment).
PFMEA’s most important output is the Control Plan, which specifies process control strategies for day-to-day production. The Control Plan bridges PFMEA findings to the production floor by defining how to monitor product and process characteristics during manufacturing.
System FMEA (SFMEA)
System FMEA is the highest-level analysis. It focuses on interfaces and interactions between subsystems. These are failures you can’t find by analyzing individual elements on their own.
SFMEA is most valuable when the failure mode is “the system doesn’t deliver the intended feature,” even though each element meets its own requirements. It should start during early conceptual phases and iterate as architecture decisions mature.
FMEA-MSR (Monitoring and System Response)
FMEA-MSR is a supplemental methodology introduced in the AIAG-VDA FMEA Handbook. It evaluates how automotive systems detect faults during customer operation and respond appropriately to maintain safe or compliant states.
This type is commonly applied to safety-relevant automotive electrical/electronic (E/E) systems where diagnostic coverage and fault reactions are part of the safety concept. The analysis typically covers warning indicators, limp-home modes, and automatic shutoffs that activate when onboard diagnostics identify a fault condition.
FMECA (Failure Mode, Effects, and Criticality Analysis)
FMECA extends standard FMEA by adding a mathematical Criticality Analysis (CA) that uses validated failure rate data and probability calculations. Where standard FMEA relies on qualitative severity-occurrence-detection ratings, FMECA produces quantitative criticality numbers.
This type of FMEA is typically used when contracts mandate it or when catastrophic failures are possible and validated failure rate databases are available. It’s most common in military, space, and mission-critical applications.
Other FMEA Types
Several additional FMEA variants apply to narrower contexts:
- Software FMEA: Applies to software-intensive products and gets special attention in regulated environments because software failures tend to be systematic, not random, like many hardware failures.
- Concept FMEA: Validates design concepts at the earliest stages before committing to detailed design.
- Service FMEA: Identifies risks in service delivery processes like patient care workflows.
- Machinery FMEA: Commonly used for machinery safety risk reduction and safeguarding.
Teams typically choose one of these when their product or process falls outside the scope of the five primary FMEA types.
Ready to Find Out More?
Our team of experts is here to answer any questions and learn how we can help enable your continued success. Get started with a free 30-day trial, or book a demo!
How the FMEA Process Works
All FMEA types follow the same seven steps from the AIAG-VDA FMEA Handbook. What changes is the input: design characteristics for DFMEA, process parameters for PFMEA, and system-level interfaces for SFMEA. The handbook also introduced Action Priority (AP) tables, which use severity-weighted logic to assign High, Medium, or Low priority levels.
Here’s how the seven steps work:
- Planning and Preparation: The team sets the project scope, analysis boundaries, team composition, and timeline. The analysis should begin while the design or process is still flexible enough to change.
- Structure Analysis: The team maps how the system, subsystems, and components relate to each other. In a DFMEA, this means breaking a product into its parts. In a PFMEA, it means mapping each step in the manufacturing process.
- Function Analysis: The team documents what each element is supposed to do under normal conditions. This step matters because you can’t identify a failure mode without first defining what success looks like.
- Failure Analysis: For each function, the team identifies what could go wrong (failure mode), why it could happen (cause), and what the impact would be (effect).
- Risk Analysis: Each failure chain gets rated on three factors, each scored 1 to 10. Severity measures how serious the effect is, occurrence measures how likely the cause is, and detection measures how likely current controls are to catch it before it reaches the customer. These ratings feed into the AP tables to determine which failure modes need action first.
- Optimization: The team assigns each high-priority failure mode a corrective action, a responsible person, and a target date. After implementation, they re-score to confirm the risk was actually reduced. A test management workflow can help track this verification.
- Results Documentation: The team records its findings, the actions taken, and how the ratings changed. This becomes the official FMEA artifact for audits and future programs, and it should be updated whenever the design or process changes.
The same seven steps apply whether you’re running a DFMEA on a braking system or a PFMEA on a welding line. What makes the analysis useful is connecting it back to requirements and verification evidence so nothing falls through the cracks.
FMEA Example
Consider a simplified car battery DFMEA. The battery’s function is to provide electrical power to start the vehicle, and the failure mode is that it goes dead, so the car won’t start (severity = 5). The cause is the driver failing to turn headlights off (occurrence = 7), and with no current controls in place, detection is rated 10.
The initial RPN is 350 (5 x 7 x 10 = 350). Many organizations set their action threshold around 100 to 200, so 350 clearly needs corrective action. The recommended action is to automatically turn headlights off after a set time period. After implementation, occurrence drops to about two, and the revised RPN falls to 100, a significant reduction from a simple design change. Detection stays at 10 because the auto shutoff prevents the failure from happening, but it doesn’t detect it. That’s the difference between a prevention control and a detection control in FMEA.
How DFMEA and PFMEA Work Together
DFMEA and PFMEA are the two types most teams run together on every program because they share a direct handoff. Critical product characteristics identified in DFMEA are communicated to process planning so PFMEA and the Control Plan address how those characteristics will be produced and controlled. Teams that manage this handoff through a risk management system can trace each design risk directly into its corresponding process control. A bracket weld example shows how the three outputs connect:
- DFMEA output: Identifies a bracket fracture risk under load and increases the weld area in the design to mitigate it.
- PFMEA output: Identifies weak welds due to poor current as a process risk and adds weld parameter controls.
- Control Plan output: Specifies PLC real-time monitoring and visual inspection for weld quality during production.
A requirements traceability matrix (RTM), a document that links every requirement to its design elements, test cases, and risk controls, is what makes DFMEA-to-PFMEA-to-Control Plan traceability possible. Once you can trace a design risk into a process control and then into a Control Plan check, you have the foundation for running the core FMEA workflow consistently. The next section breaks down that workflow using the standard step structure most teams apply across FMEA types.
Industry Standards That Reference FMEA
Several major industry standards reference or require FMEA as part of quality and safety compliance:
- International Automotive Task Force (IATF) 16949 (Automotive Quality): Widely expected as part of core tools deployment, typically through DFMEA and PFMEA artifacts.
- ISO 26262 (Automotive Functional Safety): References FMEA and Failure Modes, Effects, and Diagnostic Analysis (FMEDA) as common work products for failure mode analysis and diagnostic coverage analysis per the ISO 26262 standard.
- ISO 14971 (Medical Device Risk Management): FMEA is one accepted technique within a flexible framework, and the ISO 14971 process itself is mandatory as defined in the ISO 14971 standard.
- AS9100 (Aerospace Quality): FMEA is widely used as part of broader risk management and product assurance programs, though it’s not mandated as a single specific method.
All of these standards expect teams to show how they identified and mitigated failure risks, and FMEA is the most widely accepted way to do that.
Common Mistakes When Conducting an FMEA
In highly regulated industries, FMEAs are formal records that can be scrutinized long after the program ends. These are the mistakes that show up most often:
- Relying on RPN thresholds alone: The AIAG-VDA shift to Action Priority happened for a reason. RPN can rank a low-severity failure above a safety-critical one.
- Inconsistent rating scales: When teams use subjective severity, occurrence, and detection scales without group calibration, the resulting priorities become unreliable.
- Missing cross-functional representation: Some failure modes only surface through multi-disciplinary analysis. A DFMEA run by design engineers alone will miss manufacturing-related causes.
- Treating FMEA as a one-time document: FMEA reviews should be triggered by design changes, process changes, and shifts in functional requirements or hazard assessments.
Every recommended action needs a named responsible person and a target completion date, with re-evaluated ratings after implementation.
How Requirements Management Supports FMEA
Every failure mode traces back to a requirement, and every risk control must link forward to verification evidence. The RTM maps those connections. When a requirement changes, teams trace forward to find affected artifacts, and when a field issue appears, they trace backward to assess whether risk controls were adequate.
Jama Connect® is a requirements management system built to formalize the bidirectional links between failure modes, requirements, and verification evidence. With Live Traceability™, when a requirement changes, every downstream artifact linked to it is flagged as suspect so teams can run impact analysis before gaps propagate. Start your free 30-day trial to see how Jama Connect connects FMEA findings to requirements and verification evidence in one place.
Frequently Asked Questions About Types of FMEA
What is the difference between FMEA and FMECA?
FMEA prioritizes failure modes with qualitative severity, occurrence, and detection ratings. FMECA goes further by applying mathematical Criticality Analysis to validated failure rate data. It’s most common in military, space, and mission-critical contexts where quantitative prioritization is contractually required.
When should FMEA be performed in the product lifecycle?
The earlier the better. Most teams begin during concept and architecture with whatever information is available, then refine as the design matures through validation and post-launch field data.
What is a good RPN score?
There is no universal RPN threshold that mandates action. Many organizations now use Action Priority tables instead of RPN alone to make sure high-severity failure modes don’t get deprioritized. Any failure mode with safety or regulatory implications requires action regardless of the overall score.
Is FMEA required for ISO 13485 or ISO 26262 compliance?
ISO 13485 references ISO 14971 for risk management, which is methodology-agnostic. FMEA is one accepted technique, but on its own it doesn’t satisfy the full risk management requirement. ISO 26262 commonly includes FMEA and FMEDA as functional safety work products in analysis and verification activities.
In this Video, Learn About The Seven Steps to Performing FMEA
Book a Demo
See Jama Connect in Action!
Our Jama Connect experts are ready to guide you through a personalized demo, answer your questions, and show you how Jama Connect can help you identify risks, improve cross-team collaboration, and drive faster time to market.