FMECA applied to engineering: failure modes, effects, criticality, severity, prioritization, controls, and residual risk.
Check it out!
FMECA — Failure Modes, Effects and Criticality Analysis — is an extension of FMEA that adds an explicit criticality assessment to the failure modes analyzed. The objective is to identify how functions can fail, understand the effects of those failures, and establish technically grounded prioritization to guide design, maintenance, operation, testing, or mitigation actions.
The essential difference lies in criticality. While FMEA organizes functions, failure modes, effects, causes, and controls, FMECA adds criteria to distinguish which failures deserve greater attention. This criticality may be assessed through severity and other measures of importance, probability, or frequency, depending on the method, data availability, and application context.
FMECA is not merely FMEA with one more column. To create value, the analysis needs to define its boundary, function, criticality criteria, data quality, and decision rule. The result should make it possible to determine which failure modes truly threaten system objectives, which controls are insufficient, and where engineering resources should be concentrated.
What FMECA Is
IEC 60812:2018 treats FMEA and FMECA within the same methodological framework. FMEA provides a systematic method for identifying failure modes and their local and system-level effects; when prioritization formally incorporates criticality — at least the severity of consequences and, frequently, other measures of importance — the analysis is characterized as FMECA.
This means that FMECA combines two questions:
- How can the item or process fail, and what effects does that produce?
- How critical is that failure relative to the others, and what treatment should it receive?
The second question requires clear criteria. Without them, a criticality score may appear objective while merely reproducing subjective judgments in numerical form.
FMECA adds value only when criticality changes the decision. The score should indicate where to change the design, strengthen controls, deepen testing, or prioritize treatment — not merely sort a spreadsheet.
FMEA and FMECA: What Is the Difference?
The methodologies share the same foundation but have different responsibilities.
| Aspect | FMEA | FMECA |
| Functions and requirements | Yes | Yes |
| Failure modes | Yes | Yes |
| Local and system-level effects | Yes | Yes |
| Causes and mechanisms | May include | May include |
| Existing controls | Frequently | Frequently |
| Prioritization | May use different methods | Includes formal criticality assessment |
| Typical use | Identify and structure failure risks | Prioritize failure modes by criticality |
In practice, every FMECA contains the logic of an FMEA, but not every FMEA needs to evolve into FMECA. If the decision only requires identifying risks and actions, FMEA may be sufficient. When it is necessary to compare modes, select priorities, define redundancy levels, guide critical spare-parts inventory, or focus testing, the criticality layer becomes relevant.
Why Criticality Must Be Defined Before Scoring
Criticality does not have a universal meaning independent of context. The same equipment may be critical in one facility and secondary in another.
The assessment needs to reflect system objectives. Possible consequences include:
- people safety;
- environmental impact;
- process downtime;
- loss of production or service;
- quality;
- regulatory compliance;
- secondary damage to other assets;
- recovery time;
- intervention cost;
- reputation or institutional continuity.
The method should clarify which dimensions are included in criticality, how they are weighted, and which conditions trigger risk escalation.
Function, Failure Mode, Effect, and Cause
FMECA quality depends on the same logical chain used in FMEA.
Function describes what the item must perform and the required standard.
Failure mode describes how the function can be lost or degraded.
Effect describes the observable consequence locally and at higher system levels.
Cause or mechanism describes the phenomenon that produces the failure mode at the level being analyzed.
Consider a critical-load power-supply system. Its function is to provide power within defined parameters. One failure mode may be “output unavailable.” The local effect is loss of supply; the system-level effect may be process interruption. Causes may involve component failure, control, protection, upstream supply, or connection.
Criticality should be applied to this properly structured chain, not to vague descriptions such as “panel fails.”
Qualitative and Quantitative Criticality Methods
IEC 60812 allows different prioritization approaches because criticality has no universal formula. The method should be selected according to the decision, type of consequence, data maturity, and ability to distinguish failure modes that require different treatment.
In conceptual design, qualitative categories may be sufficient to separate intolerable modes from routine risks. In a facility with reliable history, it may make sense to incorporate observed frequency, failure rate, or exposure time. Between these extremes, semi-quantitative matrices are useful for standardizing judgments, provided the scales have explicit technical meaning.
The choice needs to be made before observing which modes rise to the top of the list. Adjusting weights, limits, or scales after seeing the ranking creates circular prioritization. It is also advisable to document uncertainty: when frequency is only estimated by specialists, the result should not be presented with the same confidence as a measure derived from representative history.
Qualitative Approach
The qualitative approach uses categories such as low, medium, high, or critical, but these words produce consistency only when objective classification criteria exist. “High severity” may mean risk to life, prolonged loss of an essential function, significant environmental damage, or another consequence defined by the organization.
It is appropriate when frequency data are limited but sufficient engineering knowledge exists to distinguish impacts. In this situation, it is preferable to explicitly acknowledge that probability is uncertain rather than invent a numerical frequency without an observational basis.
A well-designed qualitative method may also use escalation rules. For example: any mode with the potential for fatal consequences is automatically critical; modes that interrupt an essential function for more than eight hours are at least high; modes with no operational impact and simple local repair remain low. Consistency comes from the rules, not from the number of decimal places.
Semi-Quantitative Matrix
A semi-quantitative matrix combines consequence and probability or frequency scales to place a failure mode into criticality classes. Its main advantage is creating a common language among engineering, operations, maintenance, safety, and management without requiring a complete probabilistic model.
Quality depends on calibration. A frequency scale may use orders of magnitude — for example, more than one event per year, between one per year and one per ten years, less than one per ten years — instead of abstract scores such as 1, 2, and 3. Likewise, consequences should be linked to verifiable criteria for safety, environment, production, quality, cost, or continuity.
It is also necessary to decide how non-compensable dimensions will be treated. If safety receives the maximum score, low financial impact should not “dilute” the classification through a simple average. In many cases, using the highest impact among critical dimensions is more coherent than adding everything into a single score.
Multiplying arbitrary numbers does not turn the matrix into quantitative analysis. The result remains a class-based ordering useful for prioritization, provided the organization preserves the interpretation of the categories and does not confuse the score with real physical probability.
Quantitative Approach
The quantitative approach may use failure rates, mode proportions, conditional probabilities, mission time, exposure, and measurable consequences to estimate criticality measures. It is especially useful when a decision depends on comparing alternatives whose residual risks are close or when the organization needs to connect FMECA with RAM, availability, or LCC models.
A simplified example is to decompose an item’s failure rate by modes. If the estimated total rate is 2 × 10−5 failures/h and a given mode represents 25% of occurrences, the rate associated with that mode would be 5 × 10−6 failures/h, before considering conditional probability of effect or control effectiveness. The calculation already shows why the quality of the distribution by mode matters as much as the total value.
This approach requires data compatible with the population, operating conditions, and system boundary. Manufacturer rates may have been obtained under a different usage profile; field history may mix hardware revisions, environments, or different loads; rare events may generate substantial statistical uncertainty.
Quantitative results should therefore state the source, period, exposure, population size, exclusions, and assumptions. When uncertainty is material, intervals or scenarios — optimistic, base, and conservative — are more informative than a single number with many decimal places.
Severity Should Not Be Diluted
One risk of numerical methods is allowing a very severe consequence to receive low priority because another factor received a small score.
In applications involving safety, environment, or regulatory requirements, escalation rules may exist independently of the final mathematical product. Certain severity levels should remain visible and be treated even when their estimated occurrence is low.
FMECA governance should define these exceptions in advance. This prevents the team from adjusting scales after seeing the results to obtain the desired classification.
FMECA and RPN
RPN — Risk Priority Number — is widely associated with FMEA through multiplication of severity, occurrence, and detection. It can be useful in certain methodologies, but it is not synonymous with FMECA.
FMECA may use other criticality methods, including matrices, categories, and calculations based on reliability data. In addition, the same RPN can result from very different combinations of severity, occurrence, and detection.
The decision should therefore not be reduced to the final value. The team needs to keep consequence, uncertainty, controls, and technical justification visible.
Criticality is not a self-sufficient number. Severity, uncertainty, existing controls, and consequences need to remain visible so that prioritization is technically defensible.
How to Perform FMECA Step by Step
A robust sequence can be structured in ten steps:
- Define the objective of the analysis and the decision it must support.
- Establish the system, boundaries, interfaces, and decomposition level.
- Identify functions and performance standards.
- Identify functional failures and failure modes.
- Describe effects locally, at subsystem level, and at system level.
- Identify relevant causes or mechanisms.
- Record existing prevention, detection, and mitigation controls.
- Define and apply the criticality method.
- Prioritize actions, owners, and completion evidence.
- Reassess residual criticality after implementing the actions.
Order matters. Scoring before defining effects and criteria turns the analysis into intuitive classification rather than reliability engineering.
Simplified FMECA Example
Consider two fans in an N+1 configuration responsible for keeping a technical room below the design temperature limit. The mere existence of redundancy does not eliminate criticality: it is necessary to analyze modes that can remove one unit, prevent transfer, or affect both units simultaneously.
| Failure mode | Effect | Probability/frequency | Consequence | Criticality interpretation |
|---|---|---|---|---|
| Mechanical failure of one fan | Operation continues with the standby unit | Medium | Low if transfer is effective | Moderate; requires repair before another failure |
| Common controller failure | Both units unavailable | Low | High loss of cooling | High despite low frequency |
| Single sensor indicates incorrect temperature | Control may fail to activate redundancy | Low to medium | High | High due to common control failure |
| Clogged filter | Degraded airflow in both units | Medium | Medium to high depending on load | Relevant for condition-based maintenance |
This example shows that FMECA needs to assess the system-level effect. Failure of one redundant unit may have low immediate consequence but creates a degraded state in which the next failure produces total loss of function. A common controller or sensor, however, may dominate criticality even with lower price and lower failure rate.
The analysis also guides different actions. For individual mechanical failure, spare parts and repair time may be sufficient. For the common controller, the response may require control segregation or local fallback. For a clogged filter, differential pressure and condition-based maintenance may be more appropriate than replacement on a fixed calendar.
After the actions, the FMECA should be reviewed to estimate residual criticality. A mitigation measure deserves credit only if its implementation and effectiveness are verifiable. Adding an alarm that depends on the same sensor whose failure is being analyzed, for example, does not create real independence.
The example demonstrates that criticality does not derive from component price. A simple item may be decisive when its function, its position in the architecture, or a common dependency causes its failure to control system performance.
FMECA Applied to Engineering Design
During design, FMECA can identify vulnerabilities before they are incorporated into the installation. It can support decisions on architecture, redundancy, segregation, fault tolerance, accessibility, diagnostics, and test criteria.
In a Design Review, critical modes can be traced to requirements and verification activities. If the analysis shows that a common-cause failure eliminates two redundancies, for example, the solution may require an architecture change rather than a new maintenance task.
This application is especially valuable when the cost of change increases significantly after manufacturing, installation, or commissioning.
FMECA Applied to Maintenance
For existing assets, FMECA helps distinguish modes that justify condition-based maintenance, inspection, scheduled replacement, critical spares, contingency planning, or redesign.
It can also be used as input to a Reliability-Centered Maintenance — RCM analysis. FMECA helps organize modes and criticality; RCM adds the logic of consequences and selection of technically applicable and effective policies.
When the team already has historical data, those data need to be normalized. Records such as “equipment failure” without mode, cause, and exposure time have little value for quantitative analysis.
FMECA and Asset Criticality Analysis
FMECA and asset criticality operate at different levels.
Asset criticality classifies equipment or systems according to the consequence of losing their functions for the organization. It helps determine where to concentrate resources and analytical depth.
FMECA goes inside the asset or system and compares specific failure modes. An asset classified as critical may have dozens of modes with very different criticalities.
Using these two layers avoids a common mistake: applying the same level of maintenance and control to every component of an asset simply because the equipment was classified as critical.
FMECA and Reliability Data
When failure rates are used, their origin needs to be verified. Manufacturer data, generic databases, and internal history are not automatically interchangeable.
Important questions include:
- population and sample size;
- exposure hours;
- mission profile;
- environment;
- configuration;
- failure definition;
- maintenance policy;
- censoring and incomplete data;
- design changes during the period.
When uncertainty is relevant, it should be recorded. The decision can still be made, but with awareness of the quality of the evidence.
How to Treat Existing Controls
Controls should be classified according to their function.
Prevention reduces the probability that the mode will occur.
Detection increases the chance of identifying degradation or failure before a given consequence.
Mitigation reduces the effect after occurrence.
Redundancy, for example, does not necessarily prevent a component from failing; it may mitigate loss of system function. An alarm does not prevent failure; it improves detection and response capability.
Separating these roles avoids overestimating control effectiveness.
Actions and Residual Criticality
An FMECA does not end when the team assigns scores. Each priority mode needs to generate a decision.
Actions may involve design review, new protection, condition monitoring, procedure changes, functional testing, spare parts, training, frequency changes, or formal risk acceptance.
After implementation, the team should reassess residual criticality or risk. The reduction needs to be linked to an actual change in prevention, detection, or consequence, not merely a new score in the spreadsheet.
Common FMECA Mistakes
The most recurring problems are:
- starting with scoring instead of function;
- using scales without objective definitions;
- confusing asset criticality with failure-mode criticality;
- using generic frequency as if it were local probability;
- diluting high severity in an aggregated number;
- recording controls that are not tested;
- failing to consider common-cause failures;
- assigning a cause that is too generic to guide action;
- failing to define an owner and deadline for actions;
- failing to review the analysis after design or operational changes.
A good FMECA needs to be readable by someone who did not participate in the workshop and still reveal the logic behind the decision.
When to Use FMECA
FMECA is particularly useful when an organization needs to prioritize failure modes in critical systems, compare design alternatives, guide maintenance strategies, define tests, select spare parts, review redundancies, or focus reliability resources.
In new projects, it can be incorporated into Design Reviews and gates. In existing facilities, it can integrate asset criticality analysis, failure history, inspections, RCM, and modernization planning.
The value does not come from producing more documentation. It comes from converting technical knowledge about failures into verifiable priorities and decisions proportional to the consequences.
A completed FMECA needs to change a technical decision. Priority modes should result in controls, design changes, tests, maintenance, spare parts, or formal risk acceptance with traceable evidence.
Technical references
[1] IEC. IEC 60812:2018 — Failure modes and effects analysis (FMEA and FMECA). Geneva, 2018.
[2] ISO. ISO 31000:2018 — Risk management — Guidelines. Geneva, 2018.
[3] ISO. ISO 55000:2024 — Asset management — Vocabulary, overview and principles. Geneva, 2024.
Frequently asked questions
FMECA is Failure Modes, Effects and Criticality Analysis. It starts from FMEA logic and adds a formal criticality assessment to prioritize failure modes.
FMEA identifies and structures functions, modes, effects, and causes. FMECA adds criticality criteria to distinguish which failure modes require greater priority.
No. RPN is only one possible prioritization method associated with some FMEAs. FMECA can use matrices, categories, or quantitative criticality methods.
Yes. It helps prioritize failure modes and can guide RCM, monitoring, inspections, spare parts, redesign, and maintenance strategies.
Asset criticality classifies systems or equipment. FMECA assesses the criticality of specific failure modes within those assets or systems.
Whenever relevant changes occur in functions, architecture, operation, controls, environment, failure data, or evidence that changes the criticality of the modes analyzed.
Related technical materials
Related solutions
- Field Applications, Inspection, and Technical Data Collection
- Technical Knowledge Management and Lessons Learned
- Requirements, Evidence, and Acceptance Criteria Management
Related engineering services
- Reliability and Availability Engineering
- Maintenance Engineering
- Engineering Asset Management
- Design Review
Related technical content
- FMEA in Engineering
- Reliability Engineering
- Reliability-Centered Maintenance — RCM
- Asset Criticality Analysis
- Asset Management
Guides, frameworks, and references
