Why FMEDA Matters for ISO 26262: Five Practical Reasons

A controller can pass its functional tests and still leave an important safety question unanswered: what happens when its hardware fails?

A sensor can send a plausible but incorrect value. A monitoring circuit can stop working silently. A replacement component can change the assumptions behind an otherwise familiar design. FMEDA helps engineers understand how such failures affect a safety goal and whether the planned protections are sufficient.

Failure Modes, Effects and Diagnostic Analysis (FMEDA) combines failure modes, failure rates and the effectiveness of safety mechanisms.

ISO 26262 separates two kinds of failure. Systematic failures, such as a specification or design error, are prevented by a disciplined development process with reviews, verification and safety analyses. Random hardware failures occur in a correctly designed part during its service life. The design reduces them, for example by keeping the electrical and thermal stress on components well inside their ratings, and safety mechanisms detect and control them to the degree the ASIL requires. FMEDA addresses this second kind only.

Here are five reasons it matters for ISO 26262 projects.

1. It gives hardware safety claims a quantitative basis

“We have diagnostics” is a starting point. An engineering argument also needs to show which failures those diagnostics address and what remains uncontrolled.

FMEDA helps connect a team's confidence in its hardware to an analysis that others can examine. For an ISO 26262 project, that means a clearer explanation of the design's strengths, its remaining weaknesses and the assumptions behind the safety argument.

In ISO 26262 terms, FMEDA is the usual source for the hardware architectural metrics, which cover single-point faults and latent faults, and for the evaluation of random hardware failures against the safety goal. The required values depend on the ASIL, so a design that is acceptable for one safety goal can fall short for another.

The practical benefit is a better-informed engineering discussion. A completed spreadsheet alone does not establish compliance.

2. It reveals gaps behind reassuring diagnostic labels

Consider a controller that receives an incorrect sensor value while its software continues running normally. A watchdog may confirm that execution continues, yet provide no protection against that particular error.

FMEDA encourages a more useful conversation: does the selected mechanism address the relevant failure, and can the system detect and react within the fault tolerant time interval? The answer can expose missing monitoring or a diagnostic coverage claim that the design does not support, before those assumptions reach the safety case.

It also draws attention to the protections themselves. A failed safety mechanism may go unnoticed until a second fault occurs. ISO 26262 calls these latent faults and expects the analysis to account for them.

3. It helps teams spend design effort where it matters

Adding another check or selecting a more reliable component does not automatically solve the most important safety problem. Teams need to understand which failure contributions are driving the result.

FMEDA helps compare improvements against the safety goal: strengthen a diagnostic, reconsider an architecture, or investigate a component assumption. Used early, it can reveal weaknesses while the design is still flexible. That gives hardware, software and safety engineers a shared basis for deciding what to improve next.

When a result misses its ASIL target, there are two main levers: lower the failure rate, for example by reducing the stress on a part or choosing a more robust one, or catch more of the faults with a safety mechanism that has higher diagnostic coverage. They do not act on the same numbers. The single-point and latent fault metrics are ratios, so lowering every failure rate by the same factor leaves them unchanged, while it does lower the probability of violating the safety goal. FMEDA shows which lever a given result actually needs.

4. It makes supplier evidence useful in your application

FMEDA is done per safety goal, and safety goals come from the vehicle-level hazard analysis that a component supplier normally never sees. A supplier’s data is therefore an input to your FMEDA, not a replacement for it. For a simple part such as a resistor or capacitor, the supplier states failure rates for reference conditions, and you convert them to your own operating conditions, for example with the stress models of IEC 61709. For a complex part such as a microcontroller, the supplier may deliver its own FMEDA, built on assumed safety requirements and conditions of use, with failure rates and the diagnostic coverage of its on-chip safety mechanisms.

Either way, your system determines how the component is actually used. Enabled functions, operating conditions and implemented diagnostics all matter.

Bringing that evidence into the system analysis helps expose mismatches between the supplier’s assumptions of use, typically documented in a safety manual, and the real design. It also gives reviewers a clearer path from a claimed result to the evidence behind it.

5. It keeps safety reasoning connected to design changes

A component substitution, revised operating profile or changed diagnostic can invalidate an earlier conclusion even when the product’s intended function stays the same.

A maintained FMEDA helps identify which assumptions and results need another look. It becomes a practical input to change reviews, verification planning and release decisions. Starting it only when an assessment approaches loses much of that value.

Where FMEDA fits alongside other analyses

ISO 26262 also asks for qualitative hardware safety analyses: an inductive analysis such as FMEA at every ASIL, and a deductive analysis such as FTA, highly recommended for ASIL C and D. FMEDA builds on the FMEA view and adds failure rates and diagnostic coverage, which is what makes the hardware metrics computable. It works alongside these analyses and verification activities, not in place of them.

Its value depends on the quality of the engineering behind it. Good-looking results cannot compensate for an assumption that does not match the real product.

Build confidence in the decisions behind the numbers

The value of FMEDA is being able to explain why a hardware design meets its safety objectives, where its weaknesses lie and what evidence supports its protections.

Want to develop that skill? Explore FMEDA: Quantitative Hardware Safety Analysis on ISO 26262 Academy. The paid learning content takes you through the method, interactive explanations and worked examples so you can practise the reasoning behind an analysis.