Failure Modes, Effects, and Diagnostic Analysis (FMEDA): An Overview as per IEC 61508

In a world of rapidly advancing technological complexity, ensuring that products are safe for users and environmentally responsible is more critical than ever. Companies must rely on rigorous safety assessment methods to mitigate potential risks—and one such method is FMEDA. For professionals in the functional safety domain, FMEDA is yet another essential acronym in their daily vocabulary.

In this post, we’ll explore the origins of FMEDA, what it entails, and the critical factors to consider when performing one. While navigating the FMEDA process is not straightforward, this blog will offer a glimpse into its complexity and highlight the valuable insights it can deliver.

Note: This blog is intended for engineering professionals who are already involved in safety analysis or have a general understanding of hardware safety principles. We assume familiarity with key terminology, and will not be defining every concept or standard from scratch.

The Inception and Evolution of FMEDA

FMEDA emerged as an evolution of traditional Failure Modes and Effects Analysis (FMEA) and Failure Mode Effect and Criticality Analysis (FMECA) , which performs quantitative analysis through RPN (Risk Priority Numbers). As systems grew more complex—particularly with the rise of embedded electronics—the need for comprehensive quantitative safety analysis other than RPN became apparent.

FMEDA was introduced in the context of IEC 61508, the foundational standard for functional safety of electrical and electronic systems. Interestingly, despite its widespread use, the term “FMEDA” does not explicitly appear in any of the seven parts of IEC 61508. It likely originated from the engineering community itself, describing the nature of the analysis it performs.

FMEDA is implicitly defined through hardware safety requirements outlined in Part 2, Section 7.4.3, and further supported by Annexes C and D of IEC 61508. These sections confirm that FMEDA is to be conducted during the hardware development phase, providing a framework and expected outcomes for the analysis.

What is FMEDA and its importance in quantitative safety analysis

FMEDA, or Failure Modes, Effects, and Diagnostic Analysis, is a structured methodology used to systematically analyze potential failure modes within electronic systems, evaluate their impact on system behavior, and assess the ability of diagnostics to detect and mitigate these failures. It builds upon the foundation of traditional Failure Modes and Effects Analysis (FMEA) but extends it by introducing a novel quantitative dimension based on which architecture of the safety-critical system can be further analyzed and improved.

FMEDA incorporates quantitative reliability data and places equal emphasis on functional safety and diagnostic effectiveness. It introduces two major enhancements over traditional FMEA: first, the use of standardized failure rate data sourced from reliability databases such as SN 29500 and MIL-HDBK-217; and second, the evaluation of diagnostic coverage, which measures how effectively a system can detect dangerous faults through implemented diagnostic measures.

These enhancements make FMEDA a important tool in domains where system failures can result in serious harm or operational disruption—such as the automotive, industrial automation, railway, and medical device industries. Today, FMEDA is a core component of the safety lifecycle as outlined in internationally recognized standards like IEC 61508, ISO 26262, and others. It provides a rigorous, data-driven foundation for demonstrating that safety requirements are met, and that risk has been reduced to an acceptable level, both of which are essential for compliance with regulatory and certification expectations.

Now that we’ve established what FMEDA is and why it’s so essential for quantitative safety analysis, let’s explore the core components that make up an FMEDA and how they contribute to determining a system’s safety performance.

Getting Started: Key Components of FMEDA

As noted earlier, FMEDA is not a plug-and-play exercise; it requires a well-structured starting plan rooted in a solid understanding of the system’s architecture and its components. The process typically begins with defining the system architecture—whether it follows a 1oo1, 1oo2, 2oo2 configuration, or some variant thereof. This architectural structure determines how faults are tolerated and what redundancy or diagnostics might be necessary, as it directly impacts the system’s ability to meet Safety Integrity Level (SIL).

A critical early task in FMEDA is categorizing the system’s elements into either Element A or Element B, based on their complexity and transparency. IEC 61508 Part 2, Sections 7.4.4.1.2 and 7.4.4.1.3, provides guidelines on this classification. Element A refers to simple components with well-defined failure modes and fully understood behavior—for example, a pushbutton or a resistor. On the other hand, Element B includes complex components like microcontrollers, communication buses (e.g., CAN), or ASICs, where the internal behavior and potential failure modes are less predictable or not fully known. This distinction is important because the reliability modeling and fault analysis approach can differ significantly depending on the element type.

Once the system’s architecture is established and its elements are categorized, the required Safe Failure Fraction (SFF) and Hardware Fault Tolerance (HFT) levels must be determined based on the allocated Safety Integrity Level (SIL) for the specific safety function. Table 2 in IEC 61508 Part 2 outlines the minimum SFF and HFT thresholds required to achieve compliance for each SIL level. These targets serve as design constraints and influence the architecture of the design. If FMEDA results is not meeting the assigned targets, the architecture will need a revision.

With the structural groundwork in place, the FMEDA activity can proceed. At this stage, several core components of the analysis come into focus:

• Failure Modes: Each component is analyzed for potential failures (e.g., short circuit, open circuit, parameter drift).

• Effects of Failures: These failure modes are traced to understand how they impact system-level functions. Do they lead to a hazardous state? Are they detected and mitigated?

• Diagnostic Coverage (DC): This measures how well the system can detect and respond to specific faults. It's expressed as a percentage of detectable dangerous failures.

• Failure Rates (λ): FMEDA relies on standardized libraries (e.g., SN 29500 or MIL-HDBK-217) to assign statistical failure rates to components or the manufacturers data sheets.

• Failure Categorization (Safe vs. Dangerous Failures): Failures are categorized as safe detected, safe undetected, dangerous detected, or dangerous undetected. Where dangerous failures are the one which directly impacts the safe operation of the Equipment Under Control (EUC).

• Safe Failure Fraction (SFF): A critical metric in determining SIL, SFF represents the proportion of failures that are either safe or detectable.

• Hardware Fault Tolerance (HFT): Refers to the number of faults a system can tolerate without loss of safety function—essential for determining if redundancy is needed.

Table: Maximum allowable safety integrity level for a safety function carried out by a type A safety-related element or subsystem, as per IEC 61508

Safe failure fraction of an element	HFT - 0	HFT - 1	HFT - 2
<60%	SIL 1	SIL 2	SIL 3
60% - <90%	SIL 2	SIL 3	SIL 4
90% - <99%	SIL 3	SIL 4	SIL 4
≥99%	SIL 3	SIL 4	SIL 4

How FMEDA is performed: A High-Level Overview

Once all system-level data and functional safety requirements have been defined, the FMEDA process begins by breaking down the system into individual hardware components or functional blocks. Each block is associated with a specific architecture—such as 1oo1, 1oo2, or 2oo2—which plays a critical role in influencing how the FMEDA calculations are performed. IEC 61508 Part 6, Section B.3.3.1 provides detailed guidance on how different architectures affect reliability formulas and system-level fault tolerance, making it essential to establish this upfront.

With the architectural structure in place, the next step involves assigning failure modes to each component and assessing the effects these failures could have at the system level. This includes analyzing whether a specific failure could result in a hazardous event (dangerous failure), whether it is detectable through diagnostics, and whether it can be effectively mitigated. Reliability failure rate data is essential for this analysis, and is typically sourced from standardized libraries such as SN 29500 or MIL-HDBK-217, or from manufacturer data sheets when standardized data is unavailable.

Diagnostics are then evaluated for their ability to detect these failure modes. Common techniques may include watchdog timers, voltage and range plausibility checks, redundant sensors, or software-based consistency checks. To support this evaluation, IEC 61508 Part 2 Appendix A (specifically Table A.14) provides a comprehensive list of diagnostic techniques, while Part 6 Table C.2 offers indicative values to help assign appropriate diagnostic coverage percentages for each method used. These tables serve as reference points to ensure that assumptions about diagnostic effectiveness are aligned with industry-accepted benchmarks.

In addition to component-level diagnostics, FMEDA also considers the impact of common cause failures, or CCFs—failures that may occur simultaneously in multiple channels due to a shared cause, such as environmental factors or design weaknesses. These are quantified using the Beta (β) factor in FMEDA calculations. IEC 61508 Part 6 Appendix D includes a structured questionnaire designed to help safety engineers estimate the β value by evaluating factors such as physical separation, functional independence, and diversity in redundant elements.

By the end of this process, all the gathered information is consolidated into a detailed FMEDA matrix, which documents each identified failure mode, its effects, detection method, diagnostic coverage, and associated failure rate. This matrix forms the basis for determining key safety metrics—such as Safe Failure Fraction (SFF), Diagnostic Coverage (DC), and Hardware Fault Tolerance (HFT)—which in turn determine whether the system satisfies the requirements of the allocated SIL. These metrics provide not only a quantitative justification for compliance, but also insight into potential design improvements.

Challenges in Performing FMEDA

Despite its value, FMEDA is far from straightforward. One of the most common challenges lies in the availability and accuracy of failure rate data. Many custom-built or newly introduced components do not have detailed failure mode data available in public reliability libraries, forcing safety engineers to make conservative assumptions or rely on limited manufacturer information. This uncertainty can affect the precision of the analysis, particularly in systems that aim for higher SIL levels.

Another frequent issue arises from overestimating diagnostic coverage. It's not uncommon for engineers to assign overly optimistic detection percentages to diagnostic mechanisms without robust evidence to support those claims. Doing so may lead to an inflated Safe Failure Fraction or Diagnostic Coverage value, which in turn could result in non-compliance or inadequate safety margins during certification audits.

System complexity also plays a significant role in complicating FMEDA efforts. As systems grow more interconnected, the number of dependencies and interactions between components increases. This makes it more difficult to trace the effects of individual failure modes and may result in overlooked failure paths or misclassified effects. Capturing the full scope of these interactions requires deep system knowledge, thorough design documentation, and often collaboration across multiple engineering disciplines.

One particularly challenging aspect of modern systems is the presence of communication interfaces and the need for Black Channel Analysis. A black channel refers to a communication path where the internal behavior and integrity mechanisms are not fully known or controlled by the system designer—such as third-party CAN networks, Ethernet links, or proprietary protocols within ECUs. Since FMEDA primarily focuses on known hardware components, incorporating communication-related failure modes—such as data corruption, delays, or loss—requires a complementary black channel safety analysis. This analysis must ensure that diagnostic mechanisms like CRC checks, sequence counters, timeouts, and plausibility checks are appropriately designed and accounted for in the overall safety case. The other way is getting an already certified element of the black channel which can be then taken credit for while conducting the FMEDA.

Finally, while various FMEDA tools and software platforms exist to assist with modeling and calculations, they often fall short when applied to nuanced or custom architectures. These tools may not account for domain-specific details or emerging design patterns, meaning that engineering judgment and expert validation remain indispensable throughout the process. In essence, tools can support FMEDA—but they cannot replace the critical thinking and domain expertise required to do it correctly.

Why FMEDA Matters

By conducting a rigorous FMEDA, designers and stakeholders gain confidence in the safety integrity of the overall system. The process not only identifies dangerous failure modes but also highlights areas where diagnostics can be introduced or redundancy may be required to reduce risk to acceptable levels. While FMEDA can be a tedious and detail-intensive activity, it plays a vital role in meeting the expectations of regulatory bodies, where detailed FMEDA reports are often a prerequisite for certification. For manufacturers, this offers reassurance that their product meets safety standards and is less likely to pose hazards in the field—demonstrating adherence to state-of-the-art practices in functional safety. Ultimately, this contributes to increased consumer confidence in both the product and the manufacturer’s commitment to safety and reliability.

FMEDA is far more than just another acronym—it is a cornerstone of functional safety engineering in today’s complex, technology-driven landscape. By systematically analyzing potential failure modes, their effects, and the effectiveness of diagnostic mechanisms, FMEDA provides the quantitative evidence required to design safer systems and achieve compliance with industry standards.

The intent of this blog was to offer a glimpse into the depth and complexity involved in performing FMEDA according to IEC 61508. Evidently, navigating its requirements is challenging—and actually conducting a full analysis is anything but straightforward. In a future blog, we’ll explore how FMEDA expectations differ between IEC 61508 and ISO 26262, and what additional factors must be considered in each case.

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.