What Is FMEA? Failure Mode and Effects Analysis Explained + Example
FMEA explained — what Failure Mode and Effects Analysis is, the RPN (Severity x Occurrence x Detection), the step-by-step process, and a worked example.
FMEA (Failure Mode and Effects Analysis) is a structured, proactive risk-assessment method used to identify every way a system, process, or component can fail, determine what effect each failure has, and prioritize corrective actions before failures occur in the field.
In plain terms: FMEA answers three questions for every potential failure — What can go wrong? What happens if it does? How likely is it to slip through undetected? — and combines those answers into a single priority score called the Risk Priority Number (RPN).
What Is FMEA?
FMEA is both a methodology and a living document. The output is an FMEA worksheet — a structured table that catalogues failure modes, their effects, their causes, and the controls already in place, then scores each combination on three dimensions to produce an RPN.
The process is intentionally systematic. Engineers work through every function of a system or step in a process, asking "what could fail here?" for each one. Nothing is assumed to be too obvious or too unlikely to document. That discipline is precisely what makes FMEA valuable: it forces cross-functional teams to surface institutional knowledge and hidden assumptions before they become production incidents or safety events.
FMEA is closely associated with reliability engineering, root cause analysis, and reliability centered maintenance. In industrial automation, it connects directly to control-system design: the corrective actions that come out of an FMEA worksheet frequently take the form of alarms, interlocks, redundant sensors, or automated shutdown sequences implemented in the PLC or DCS.
Types of FMEA
There are three primary FMEA types, each aimed at a different phase of the product or process lifecycle.
Design FMEA (DFMEA)
Design FMEA examines a product or component design before it enters manufacturing. The focus is on design-related failure modes — material selection, tolerance stack-ups, interface mismatches — and their effects on the end user. DFMEA is typically performed during the design and development phase and is owned by the design engineering team.
Process FMEA (PFMEA)
Process FMEA examines a manufacturing or assembly process. The focus is on process steps that could be performed incorrectly, out of sequence, or with defective inputs, and the effect those process failures have on product quality or safety. PFMEA is one of the core deliverables in IATF 16949 (automotive quality) and is widely used in food, pharma, and industrial manufacturing.
System FMEA (SFMEA)
System FMEA examines interactions between subsystems within a larger system. It sits above DFMEA and PFMEA in scope, addressing interface failures and emergent behaviors that only appear when subsystems are combined. In industrial automation, a System FMEA might cover how the PLC, HMI, field instruments, and safety relay interact — not just the individual components.
A fourth variant, FMECA (Failure Mode, Effects, and Criticality Analysis), is covered separately below.
The FMEA Process Step by Step
A well-executed FMEA follows a consistent sequence regardless of type. The steps below reflect current industry practice aligned with the AIAG & VDA FMEA Handbook (2019), which is the reference standard in automotive and widely adopted outside it.
Step 1 — Define the Scope
Identify what is being analyzed: a specific assembly, a manufacturing process, a control loop, or an entire system. Define the boundaries clearly. An FMEA with an undefined scope drifts and never reaches actionable conclusions.
Step 2 — Assemble the Cross-Functional Team
FMEA works best as a team exercise. Pull in design engineers, process engineers, quality, maintenance, and operations. In an automation context, include the controls engineer and, where relevant, the safety engineer. Each discipline surfaces failure modes that others would miss.
Step 3 — Identify Functions and Requirements
For each element in scope, document what it is supposed to do and under what conditions. A pump should deliver 150 L/min of coolant at 3 bar. A PLC input card should read a 24 VDC discrete signal within 10 ms. Functions are the baseline against which failure modes are defined.
Step 4 — Identify Failure Modes
A failure mode is the way in which a function fails to be performed. For the pump example: fails to start, delivers insufficient flow, delivers flow at wrong pressure, runs continuously when commanded off. List every credible failure mode for each function — erring on the side of completeness.
Step 5 — Identify Effects of Each Failure Mode
An effect is what happens to the system or the end user when the failure mode occurs. Effects are rated at the system level (what the customer or operator experiences), not just locally. A pump that fails to start may cause a production line shutdown, product spoilage, or an unsafe temperature buildup downstream.
Step 6 — Identify Causes of Each Failure Mode
A cause is the mechanism that produces the failure mode. One failure mode can have multiple causes; each cause gets its own row in the worksheet. For pump failure to start: motor winding failure, blown fuse, broken coupling, loss of control-circuit voltage, stuck check valve. Causes drive the selection of corrective actions.
Step 7 — List Current Controls
Document the prevention controls (design features, process controls, standard operating procedures) and detection controls (tests, inspections, alarms) already in place for each cause and effect. Controls affect the Occurrence and Detection ratings described in the next section.
Step 8 — Calculate the RPN
Assign Severity, Occurrence, and Detection ratings, then multiply them. Full detail is in the section below.
Step 9 — Prioritize and Assign Actions
High-RPN items, and any item with a Severity of 9 or 10 regardless of RPN, require corrective action. Assign an owner and a target completion date for each action.
Step 10 — Implement Actions and Re-evaluate
After actions are implemented, re-rate Occurrence and Detection (Severity only changes if the design is changed to eliminate the failure's effect). Calculate the revised RPN to confirm risk has been adequately reduced. The FMEA is a living document — it should be updated whenever designs, processes, or operating conditions change.
Severity, Occurrence, Detection, and the RPN
The three rating scales are the heart of FMEA. Each is scored 1–10, and the three scores are multiplied to produce the RPN.
Severity (S)
Severity rates the seriousness of the effect of the failure mode on the end user or process. It is assessed at the highest level of impact and does not account for how likely the failure is to occur.
| Rating | Effect Description |
|---|---|
| 1 | No discernible effect |
| 2–3 | Minor effect, slight inconvenience |
| 4–6 | Moderate effect, some degradation of performance |
| 7–8 | High effect, loss of primary function, customer dissatisfied |
| 9 | Very high — potential safety issue, non-compliance with regulation |
| 10 | Hazardous — failure occurs without warning, risk to personnel |
Severity is fixed by the effect. The only way to reduce a Severity score is to change the design so the failure mode either cannot occur or its effect is less severe.
Occurrence (O)
Occurrence rates how frequently the cause of the failure mode is expected to occur over the product's lifecycle or process run. It is informed by historical failure data, engineering judgment, and the effectiveness of prevention controls.
| Rating | Frequency Description |
|---|---|
| 1 | Failure is unlikely; no known occurrences |
| 2–3 | Low occurrence; isolated incidents |
| 4–6 | Moderate occurrence; occasional failures |
| 7–8 | High occurrence; repeated failures |
| 9–10 | Very high; failure is almost certain |
Improving prevention controls (adding redundancy, using more reliable components, tightening tolerances) reduces the Occurrence rating.
Detection (D)
Detection rates how likely the current controls are to detect the failure cause or failure mode before it reaches the customer or results in a safety event. Counter-intuitively, a higher Detection score means the control is worse at detecting the failure.
| Rating | Detection Description |
|---|---|
| 1 | Control will almost certainly detect the failure |
| 2–3 | High likelihood of detection |
| 4–6 | Moderate likelihood of detection |
| 7–8 | Low likelihood; control may miss the failure |
| 9 | Very low; control is unlikely to detect |
| 10 | No detection control exists |
Adding or improving detection controls (automated sensors, functional tests, process monitoring) reduces the Detection rating.
Calculating the RPN
RPN = Severity × Occurrence × Detection
RPN values range from 1 (lowest risk) to 1,000 (highest risk). In practice, organizations set a threshold — commonly 100 or 125 — above which corrective action is mandatory. However, any item with Severity ≥ 9 requires action regardless of RPN, because even a low-probability, easily detected catastrophic failure mode demands mitigation.
The RPN is a prioritization tool, not an absolute risk metric. Two failure modes with identical RPNs can have very different risk profiles (S=10, O=1, D=10 versus S=5, O=5, D=4). Always review the individual ratings alongside the composite score.
Worked Example: Conveyor Motor Overtemperature Failure in a PLC-Controlled System
The following example covers a Process FMEA for a PLC-controlled conveyor system carrying product through a drying oven. The conveyor motor runs continuously during production and is monitored by the plant's SCADA system.
FMEA Worksheet — Conveyor Motor Overtemperature
| Item | Function | Failure Mode | Effect | S | Cause | O | Current Controls | D | RPN | Recommended Action | Resp. | Target Date |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Conveyor drive motor | Deliver continuous belt motion at 0.5 m/s | Motor overtemperature (thermal shutdown) | Conveyor stops mid-cycle; product trapped in oven; potential product damage or fire risk | 8 | Blocked ventilation grilles on motor housing | 5 | Weekly visual inspection of motor area | 6 | 240 | Add motor thermistor wired to PLC AI; configure high-temp alarm at 120 °C and automatic shutdown interlock at 140 °C | Controls Engineer | 2026-07-15 |
| Conveyor drive motor | Deliver continuous belt motion at 0.5 m/s | Motor overtemperature (thermal shutdown) | Conveyor stops mid-cycle; product trapped in oven; potential product damage or fire risk | 8 | Motor bearing wear increasing friction | 4 | Annual motor replacement PM | 7 | 224 | Reduce PM interval to 6 months; add vibration monitoring via accelerometer on motor housing | Maintenance | 2026-07-30 |
| Conveyor drive motor | Deliver continuous belt motion at 0.5 m/s | Motor overtemperature (thermal shutdown) | Conveyor stops mid-cycle; product trapped in oven; potential product damage or fire risk | 8 | Overloaded belt (product jammed) | 3 | Operator visual check at line startup | 5 | 120 | Add motor current monitoring to PLC; configure overcurrent alarm at 110% FLA | Controls Engineer | 2026-07-15 |
Reading the worksheet:
- The first row scores RPN = 240 (S=8, O=5, D=6). Blocked ventilation is a credible, moderately frequent cause, and the existing weekly visual inspection is only a moderate detection control. The recommended action — adding a thermistor input to the PLC with a two-stage alarm/interlock — directly improves Detection from 6 to an estimated 2, dropping the revised RPN to approximately 80.
- The second row (RPN = 224) addresses bearing wear. The annual PM interval is long relative to the expected wear rate, and there is no condition monitoring. Adding vibration monitoring and shortening the PM interval attacks both Occurrence and Detection.
- The third row (RPN = 120) sits below many organizations' mandatory-action threshold but above 100. The motor current monitoring recommendation is low-cost and provides a continuous detection control in the PLC, reducing Detection from 5 to an estimated 2.
The automation connection: All three recommended actions are implemented at the PLC or SCADA layer — thermistor analog inputs, current monitoring, alarm setpoints, and shutdown interlocks. This is the pattern in industrial FMEA: high-consequence failure modes on automated equipment are almost always mitigated through control-system changes rather than procedural controls alone. For more on designing reliable control systems, see the guide to industrial control systems and PLC programming best practices.
FMEA vs FMECA
FMECA (Failure Mode, Effects, and Criticality Analysis) is an extension of FMEA that adds a formal Criticality Analysis step. Where FMEA uses the RPN as a composite priority score, FMECA produces a separate Criticality Number (Cm) based on failure mode ratio, failure rate (lambda), and operating time. This produces a criticality matrix that plots failure mode severity category against criticality number, giving a visual representation of risk concentration.
| Feature | FMEA | FMECA |
|---|---|---|
| Priority metric | RPN (S × O × D) | RPN + Criticality Number (Cm) |
| Failure rate data required | No | Yes (or probability estimates) |
| Output | Ranked action list | Action list + criticality matrix |
| Common standards | AIAG/VDA, SAE J1739 | MIL-STD-1629A, IEC 60812 |
| Typical use | Automotive, manufacturing, pharma | Defense, aerospace, nuclear |
FMECA is more quantitatively rigorous but requires failure rate data that is often unavailable in early design phases. For most industrial automation applications, FMEA with well-calibrated RPN ratings provides sufficient risk resolution. Use FMECA when regulatory requirements mandate it (MIL-STD-1629A compliance, nuclear safety cases) or when quantitative reliability predictions are needed for contractual purposes.
Common FMEA Mistakes
Even experienced teams make predictable errors when executing FMEA. These are the most common ones and how to avoid them.
1. Confusing failure modes with causes or effects
A failure mode is the manner of failure (motor fails to start). A cause is why (broken coupling). An effect is what happens as a result (conveyor stops). Mixing these up produces worksheets that are difficult to act on. Keep the three columns strictly separate.
2. Treating FMEA as a one-time exercise
An FMEA completed at design review and never revisited is nearly worthless. The document must be updated when designs change, when new failure data becomes available from field incidents, and when corrective actions are verified complete. Schedule FMEA reviews alongside design changes and major PM cycles.
3. Inconsistent rating scales across teams
If the mechanical team rates Occurrence on a different mental scale than the controls team, the RPN comparisons are meaningless. Establish and document your organization's rating criteria before the analysis begins, and calibrate the team with reference examples.
4. Gaming the RPN to avoid action
Optimistic Detection ratings — assigning a 2 because "we could add a sensor if we wanted to" rather than because the sensor actually exists — artificially deflate RPN scores. Rate controls on what is currently in place. Proposed controls belong in the Recommended Action column, not the Current Controls column.
5. Ignoring high-Severity items with low RPN
An S=10, O=1, D=1 failure mode has RPN=10 and looks benign. It is not. A failure with catastrophic consequences demands a design review even if it is extremely rare and easily detected. Always flag any Severity 9 or 10 item for special review regardless of composite RPN.
6. Over-scoping the team size
FMEAs with more than seven or eight active participants become unmanageable in a workshop setting. Keep the core team small; bring subject matter experts in for specific sections rather than including everyone for the full analysis.
7. Skipping the re-evaluation after actions close
The revised RPN after corrective actions are implemented is the only evidence that the FMEA process produced a measurable risk reduction. Without re-evaluation, the organization cannot demonstrate improvement to auditors, customers, or regulators.
FMEA in Predictive Maintenance and PLC-Controlled Systems
In an industrial automation context, FMEA is not just a quality tool — it is a direct input to predictive maintenance strategy. The failure modes and causes identified in the FMEA worksheet map directly onto the sensor measurements, alarm thresholds, and interlock logic that a controls engineer implements in the PLC program.
A motor overtemperature failure mode calls for a thermistor input and a temperature alarm rung. A conveyor jam failure mode calls for motor current monitoring and a drive fault interlock. A pump low-flow failure mode calls for a flow transmitter, a process variable alarm, and potentially an automatic backup pump start sequence.
For a detailed look at how FMEA outputs translate into PLC-based maintenance strategies, see the guide to PLC predictive maintenance. For the control-system implementation of alarms and interlocks, the industrial control systems guide covers hardware and software architecture in depth.
Frequently Asked Questions
What is FMEA?
FMEA (Failure Mode and Effects Analysis) is a proactive risk assessment method that identifies how systems, processes, or components can fail, evaluates the effects of each failure, and prioritizes corrective actions using a Risk Priority Number (RPN) calculated as Severity × Occurrence × Detection.
What is RPN in FMEA?
RPN stands for Risk Priority Number. It is calculated by multiplying three scores — Severity (S), Occurrence (O), and Detection (D) — each rated 1–10. RPN = S × O × D, producing a value between 1 and 1,000. Higher RPNs indicate higher risk and greater urgency for corrective action. Any item with Severity ≥ 9 requires action regardless of RPN.
What is the difference between FMEA and FMECA?
FMEA produces a Risk Priority Number based on Severity, Occurrence, and Detection ratings. FMECA extends FMEA by adding a quantitative Criticality Analysis (Criticality Number) based on failure rate data, producing a criticality matrix. FMECA is more rigorous but requires failure rate data and is most common in defense and aerospace applications under MIL-STD-1629A.
What are the types of FMEA?
The three primary types are Design FMEA (DFMEA, focused on product design), Process FMEA (PFMEA, focused on manufacturing or assembly processes), and System FMEA (SFMEA, focused on subsystem interfaces within a larger system). Each type addresses a different phase and scope of analysis.
When should FMEA be performed?
FMEA is most effective when performed early — during design or process development — before changes become expensive. It should also be updated whenever a design changes, a new failure mode is discovered in the field, or corrective actions are implemented and need to be re-evaluated for effectiveness.
How long does an FMEA take?
A scoped FMEA on a single assembly or process step with a focused team of four to six people typically takes one to three workshop sessions of two to four hours each. Larger system-level FMEAs can take weeks of team time. Scope control at the outset is essential to keeping the analysis practical and actionable.
