The FMEA and ISO 26262 Relationship
This article offers an in-depth look at topics related to Functional Safety.
For expert-level training—including certification-based programs—on these topics and more, explore our Automotive trainings. To learn how we support product development, compliance, and organizational safety goals with consulting support, visit our Functional Safety & Cybersecurity page—or contact us directly.
The Failure Mode and Effects Analysis (FMEA) is a cornerstone methodology in automotive engineering since the 1970’s, providing a systematic approach to identifying potential failure modes, assessing their effects, and prioritizing actions to mitigate risks.
As automotive systems become increasingly complex and safety-critical, the FMEA has evolved to encompass more targeted analyses, for example the FMEA for Monitoring and System Response (FMEA-MSR), aimed at evaluating the robustness of monitoring strategies and fault responses.
The FMEA Handbook and ISO 26262
This blog will explore the interrelationship between FMEAs and the ISO 26262 standard, across system, hardware, and software levels.
The FMEA Handbook, jointly published by the AIAG (Automotive Industry Action Group) and VDA (Verband der Automobilindustrie) in 2019, serves as a unified guide to industry best practices for developing FMEAs. It not only provides a systematic approach to FMEA but also outlines an alignment with the ISO 26262 standard. This synergy is particularly crucial as automotive systems become increasingly complex and more software driven.
Key Terminology Differences Between ISO 26262 and the FMEA Handbook
The FMEA Handbook highlights several terminology differences between the two standards, which are important for ensuring a clear understanding of their scope and application:
|
ISO 26262 term |
VDA-AIAG FMEA term |
Relationship |
|
Exposure (HARA) – duration or frequency of an operational situation |
Frequency – occurrence of a fault |
Related, but not equivalent |
|
FIT Rate – quantitative measure of electronic (PCB) component reliability |
Frequency – occurrence of a fault |
Related, but not equivalent |
|
Diagnostic Coverage – ability of the system to mitigate a fault |
Monitoring – ability of persons and/or the system to detect a fault |
Monitoring has a more general, wider scope. Relates only for specific causes |
System-Level Connections between FMEA and ISO 26262
The FMEA is frequently employed to support vehicle and component validation by identifying validation tests based on failure modes. ISO 26262 also highlights the FMEA as a possible tool to aid completeness of hazard identification and functional safety requirements (FSRs) at the system level.
At the system level, ISO 26262 mandates the use of inductive (bottom-up) and/or deductive (top-down) analyses to evaluate the system architecture.Â
Three qualitative FMEA types are listed by ISO 26262:
- SFMEA (System FMEA)
- DFMEA (Design FMEA)
- PFMEA (Process FMEA)
While ISO 26262 requires inductive analysis to identify potential failures and their impacts, it does not specify which FMEA type must be used. In practice, DFMEA and PFMEA are the most commonly applied methods across the industry.
In summary, while FMEA does not replace dedicated safety analyses, ISO 26262 mandates support of FMEA aspects at the system level to enhance the completeness and robustness of safety documentation.
FMEAs can be applied at all abstraction levels but are most effective at the system level.
Hardware-Level Analysis: FMEDA vs. FMEA
Failure Modes, Effects, and Diagnostic Analysis (FMEDA) is a quantitative methodology in ISO 26262, distinct from the VDA-AIAG FMEA approach.
- FMEDA targets the mitigation of risks associated with safety goal violations due to random hardware failures.
- FMEA, in contrast, is generally applied at the system level. While these analyses are largely independent, FMEA can serve as a precursor to FMEDA.Â
For example, an FMEA can be conducted early in the design process—before detailed schematics are available—at the hardware block level to assess its potential to violate safety goals. Once the FMEDA is performed, it would add reliability data and diagnostic coverage to the earlier FMEA findings.
The FMEDA’s objective is robustness against safety goal violations specific to hardware whereas FMEA addresses broader system-level concerns. SRES provides a specialized training and workshop on the FMEDA.
Software-Level Analysis: Safety-Oriented Software Analysis (SSA) vs. FMEA-MSR
The relationship between Safety-Oriented Software Analysis (SSA) in ISO 26262 and FMEA-MSR is an area of interest, particularly given the increasing role of software in automotive systems.
- FMEA-MSR evaluates fault monitoring and system responses at the system level. It focuses on mitigating E/E faults (e.g., Diagnostic Trouble Codes, or DTCs) and ensuring appropriate system responses.
- SSA verifies the robustness of the software architecture, identifying gaps and driving improvements to software safety requirements and architecture.
Key differences:
- The purpose of SSA is to validate and refine the software architecture.
- The purpose of FMEA-MSR is to ensure the system responds effectively to faults.
Thus, FMEA-MSR is not a substitute for SSA.
What’s Next?
For those looking to dive deeper into software-focused methodologies, the next blog will explore Software-FMEA (Sw-FMEA) and its role in safety-oriented software analysis. Stay tuned!
