ISO 26262 FMEDA - Automotive Functional Safety Implementation

This blog post continues our exploration of Failure Modes, Effects, and Diagnostic Analysis (FMEDA) from our previous post on FMEDA under IEC 61508. There, we covered what FMEDA is, how it differs from traditional FMEA, and the IEC 61508 approach to failure mode analysis for functional safety.

In this second part, we dive into how the ISO 26262 automotive functional safety standard—derived from IEC 61508—defines and implements FMEDA. While the core concept remains similar, ISO 26262 tailors it to automotive hardware development, emphasizing quantitative metrics, failure classification, and integration with safety concepts. Follow along as we unpack the automotive-specific flow, intricacies, and practical challenges.

FMEDA Recap from Part 1

FMEDA is a structured analysis method used to identify hardware failure modes, evaluate their local and system-level effects, and determine whether safety mechanisms can detect, control, or tolerate them. Unlike a conventional FMEA, FMEDA extends the exercise by attaching failure rates and diagnostic assumptions to the analysis, which allows it to support quantitative safety evaluation. In the IEC 61508 world, that quantitative view is often tied to Safe Failure Fraction and dangerous detected versus dangerous undetected failure categories.

That earlier terminology is still useful when entering the ISO 26262 discussion because the basic thinking remains similar. Failures are still judged in terms of whether they are safety-relevant, whether they are detected, and whether they can lead to a hazardous effect. However, ISO 26262 does not stop at the simple safe and dangerous split. Instead, it refines the classification into categories that are specifically intended to support automotive hardware metrics such as SPFM and LFM. In other words, the concepts are inherited from the same FMEDA foundation, but the derived measures and compliance expectations are different.

ISO 26262 Flow to FMEDA

ISO 26262 structures FMEDA within the hardware product development lifecycle outlined in Part 5 of the standard. The process begins at the system level with hazard analysis and flows downward into detailed hardware analysis. It follows the familiar V-model of development, where analysis on the left side (design) informs verification on the right (testing).

The high-level flow looks like this: Item Definition leads to Hazard Analysis and Risk Assessment (HARA), which produces safety goals. These feed into the Functional Safety Concept (FSC), then the Technical Safety Concept (TSC), hardware safety requirements, and finally hardware design. FMEDA primarily enters during hardware design in Part 5 (Clause 7) and supports the evaluation of hardware architectural metrics (Clause 8) and random hardware failure analysis (Clause 9). This integration ensures that failure analysis isn't an isolated exercise but a core part of proving ASIL compliance.

ISO 26262 from FSC to TSC to Hardware Safety Analysis

The Functional Safety Concept (FSC), detailed in ISO 26262-4 Clause 6, defines top-level safety goals emerging from HARA. It focuses on high-level functions needed to avoid hazardous events without delving into specific implementations. From here, the Technical Safety Concept (TSC) refines these into actionable technical safety requirements. The TSC allocates responsibilities between hardware and software, specifies safety mechanisms like redundancy or diagnostics, and sets targets such as the Fault Tolerant Time Interval (FTTI) or Probabilistic Metric for random Hardware Failures (PMHF).

Hardware safety requirements are derived directly from the TSC. These include properties for detecting internal and external failures, tolerating faults within FTTI limits, and meeting quantitative targets apportioned to hardware elements. This leads into hardware design, where safety analyses like FMEDA come into play. ISO 26262 mandates both inductive (bottom-up, such as FMEDA or FMEA) and deductive (top-down, such as Fault Tree Analysis or FTA) methods during this phase. Inductive analysis starts from individual component failures and traces their effects upward through the system, while deductive traces backward from safety goal violations. FMEDA serves as the cornerstone inductive tool, populating worksheets with elements, failure modes, rates, effects, and diagnostic coverage to enable precise calculations.

ISO 26262 Failure Mode Classification

A foundational concept in ISO 26262 FMEDA is how each failure mode is characterized in terms of its safety impact. Failures are broadly labeled as Dangerous (they can cause or contribute to a hazardous event), Safe (they do not lead to a violation of a safety goal), or Not Applicable (the failure mode is irrelevant to the item's safety function under analysis). This Dangerous/Safe/Not Applicable framework is inherited from IEC 61508 thinking but is refined significantly by ISO 26262 to drive specific derived metrics.

Building on this foundation, ISO 26262 Part 10 Clause 8.1 introduces a precise taxonomy of random hardware failure classifications:

• Safe Faults: Failures that have no impact on the safety function. They do not contribute to any safety-relevant metric.

  
  

• Single-Point Faults (SPF): Dangerous failures of a single element that directly violate a safety goal in the absence of any safety mechanism. These are the most critical class and drive the Single Point Fault Metric (SPFM).

  
  

• Residual Faults: The portion of single-point faults that remain undetected (or uncontrolled) by a safety mechanism. They represent the gap left by imperfect diagnostic coverage.

  
  

• Dual-Point Faults: Failures that only violate a safety goal when combined with an independent second fault. They are further subdivided into:

  • Detected Dual-Point Faults: Detected by a diagnostic mechanism before a second fault occurs.

  • Perceived Dual-Point Faults: Perceived by the driver or operator, allowing a mitigating action.

  • Latent Dual-Point Faults: Undetected and unperceived faults that remain dormant until a second fault occurs, making them particularly insidious. These drive the Latent Fault Metric (LFM).

FMEDA worksheets explicitly categorize each failure mode into these buckets, assigning associated failure rates and diagnostic coverage levels. It is important to note that FMEDA does identify dual-point failures—it does so by evaluating whether a safety mechanism exists that would detect or perceive a first fault before a second fault can combine with it to violate a safety goal. The worksheet captures each element's failure modes, their safety impact classification, the applicable safety mechanism, and the resulting coverage level. This structured approach is what enables the direct calculation of SPFM and LFM from the FMEDA output.

Failure Rate Rankings and Diagnostic Coverage

At the heart of FMEDA are failure rates, typically expressed in FIT (failures in 10^9 hours), sourced from databases like SN 29500 or MIL-HDBK-217 and adjusted for the vehicle's mission profile—think operating hours, temperature, and vibration. These rates (λ) are distributed across failure modes based on available industry standards or engineering judgment or historical data.

Diagnostic coverage (DC) then quantifies how effectively a safety mechanism mitigates the safety impact of a given failure—meaning it either prevents the failure from propagating to a safety goal violation or ensures the failure is detected and acted upon within the Fault Tolerant Time Interval. It is not merely about detecting that a failure occurred; the mechanism must provide sufficient control to neutralize the hazardous effect. ISO 26262 provides tables rating coverage as high (≥99%), medium (90–99%), or low (<90%), with strong recommendations for higher levels at elevated ASILs.

In FMEDA worksheets, applying DC to the failure rate of each mode yields classified values such as λ_SAFE, λ_SPF, and λ_RESIDUAL. These per-element values roll up into the overarching architectural metrics. The rigor here ensures that claims are defensible through fault injection testing, simulation, or documented rationale—all of which may be required as evidence during functional safety audits.

Hardware Architectural Metrics

ISO 26262 requires quantitative evaluation of hardware architecture for ASIL B–D via two key metrics defined in Clause 8.

• Single Point Fault Metric (SPFM) measures the proportion of single-point fault failure rate that is either made safe or detected by a safety mechanism, relative to the total failure rate of all elements contributing to the safety function. Targets rise from 90% for ASIL B to 99% for ASIL D, reflecting the increasing rigor required at higher integrity levels.

  
  

• Latent Fault Metric (LFM) assesses what fraction of latent dual-point faults are either detected or perceived within the Fault Tolerant Time Interval, again relative to the relevant total failure rate. Targets range from 60% for ASIL B to 90% for ASIL D.

FMEDA supplies the raw classified failure rate data—organized by fault class—that feeds directly into these formulas as defined in Annex C of ISO 26262-5. When SPFM or LFM targets are not met, one of three paths forward exists: architectural redesign to add or strengthen safety mechanisms, justification using the Probabilistic Metric for random Hardware Failures (PMHF, target <10 FIT for ASIL D), or an Evaluation of Each Cause (EEC) approach. This tight coupling between FMEDA output and architectural metric calculation makes FMEDA indispensable for proving architecture effectiveness.

Challenges and Difficulties

Implementing ISO 26262 FMEDA isn't without hurdles. Data gaps in failure rates often force expert judgment, introducing uncertainty that must be documented and justified. Proving high diagnostic coverage demands evidence like fault injection simulations, which can be resource-intensive for complex SoCs. Component-level FMEDA must also accurately roll up to item-level behavior, accounting for system interactions that might mask or amplify faults.

Identifying dual-point and multiple failures adds a further layer of complexity. For each latent fault, the engineer must reason about which independent second fault could combine with it to violate a safety goal, assess the independence of the relevant safety mechanisms, and account for common-cause failures where elements share power, buses, or physical enclosures. This reasoning must be systematic and documented in the worksheet, and often requires complementary Fault Tree Analysis (FTA) to validate the dual-point fault cut sets deductively. Multi-core processors and complex SoCs compound this further, requiring partitioning analysis per ISO 26262-11 guidance.

ISO 26262 transforms FMEDA from a general tool into a metrics-driven pillar of automotive hardware safety, deeply integrated with FSC, TSC, and quantitative evaluations. Its Dangerous/Safe/Not Applicable classification framework, combined with the precise fault taxonomy of single-point, residual, and dual-point faults, enables engineers to generate defensible, auditable evidence of ASIL compliance. At Quiddity Technology Solutions, we guide teams through this—from FSC derivation to PMHF verification—delivering compliant designs efficiently.

FMEDA is a task best undertaken by experienced professionals familiar with its intricacies. At QTSI, we bring that experience and a rigorous, detail-oriented approach to every FMEDA we perform—ensuring your safety goals are not just met, but exceeded.