FMEDA Explained: Failure Modes, Effects, and Diagnostic Analysis for Functional Safety

FMEDA stands for Failure Modes, Effects, and Diagnostic Analysis. It is a quantitative, bottom-up analysis that takes each component in a safety function, assigns every failure mode a failure rate, and classifies that failure as safe or dangerous and as detected or undetected. Those classified failure rates are what feed diagnostic coverage, safe failure fraction, and ultimately the SIL calculation. Without FMEDA, those higher-level numbers have nothing underneath them.

Most engineers meet FMEDA the same way they meet diagnostic coverage: as a column of numbers in a reliability spreadsheet that someone else built. The spreadsheet produces a SIL rating, and the analysis behind it stays opaque until an assessor asks where a particular failure rate came from.

This post explains what FMEDA actually is, how it differs from FMEA and fault tree analysis, what it produces, what it needs as input, and where teams get it wrong.

What FMEDA Actually Is

FMEDA is a structured, component-level reliability analysis. You work through the safety function part by part. For each component, you ask three things: how can this part fail, how often does each failure mode occur, and does the failure push the system toward a dangerous state or a safe one?

Then you ask one more question that gives FMEDA its name. For each dangerous failure mode, will the system's diagnostics detect it before it can cause harm?

That last question is what separates FMEDA from a plain reliability study. It does not just count failures. It sorts them into four buckets:

• Safe detected: the failure moves the system toward a safe state, and diagnostics see it

• Safe undetected: the failure is safe, but diagnostics do not catch it

• Dangerous detected: the failure is dangerous, and diagnostics catch it in time to respond

• Dangerous undetected: the failure is dangerous, and nothing detects it (this is the bucket that drives residual risk)

Engineers usually write these category failure rates as lambda values: lambda safe detected, lambda safe undetected, lambda dangerous detected, lambda dangerous undetected. Sum them and you have the total failure rate for the component. Split them the way FMEDA splits them, and you have the raw material for every metric that follows.

How FMEDA Differs From FMEA and FTA

FMEDA gets confused with FMEA constantly, and it gets contrasted with FTA almost as often. The three are related, but they answer different questions and run in different directions.

FMEA (Failure Mode and Effects Analysis) is the older, broader method. It is qualitative. You identify failure modes, judge their severity and likelihood, often combine those into a risk priority number, and use that to decide where to focus attention. FMEA is excellent for surfacing what could go wrong and ranking it. What it does not do is produce calibrated failure rates. It tells you a failure mode is high risk; it does not tell you it occurs at a specific rate per hour.

FMEDA takes the failure-mode thinking from FMEA and adds the two things safety math needs: real failure rates and a diagnostic classification. It is quantitative where FMEA is qualitative, and it is narrower on purpose. FMEA spreads across the whole design to find problems. FMEDA drills into the safety function to produce numbers.

FTA (fault tree analysis) runs the other way. It is top-down and deductive. You start with a defined top event, usually a hazardous outcome, and decompose it into the combinations of lower-level faults that could produce it. FMEDA is bottom-up and inductive. It starts at the components and builds upward to their effect on the function.

Here is how the three line up:

The pairing that matters most is FTA and FMEDA together. FTA frames the problem from the top: it tells you which failures, and which combinations of failures, lead to the hazard you care about. FMEDA supplies the bottom: the component failure rates that quantify how likely each of those contributing failures actually is. One gives you structure, the other gives you numbers. Run them as a pair and the safety argument has both a shape and a magnitude. Run only one and you are missing half the picture. The hazard analysis sets the top events that FTA decomposes and that FMEDA ultimately quantifies, which is why these analyses belong in the same connected model rather than separate documents.

What FMEDA Produces and What It Feeds

The output of an FMEDA is a set of categorized failure rates per component, rolled up to the safety function. From there, the numbers travel.

Diagnostic coverage comes directly out of the dangerous-failure split. DC is the fraction of dangerous failures that are detected: lambda dangerous detected divided by total lambda dangerous. If your FMEDA classification is wrong, your DC is wrong, and the error propagates.

Safe failure fraction draws on all four buckets. SFF is the fraction of total failures that are either safe or detected. It depends on the safe-versus-dangerous split and the detected-versus-undetected split that FMEDA produces.

The SIL and PFH calculation sits on top of both. Probability of dangerous failure per hour weights the undetected dangerous failures most heavily, because those sit dormant and accumulate exposure. The lambda dangerous undetected value from your FMEDA is one of the biggest single drivers of whether the function meets its SIL target.

This is the chain: component failure modes feed FMEDA, FMEDA feeds DC and SFF, DC and SFF feed the SIL calculation, and the SIL calculation determines whether the architecture is acceptable. Standards in the IEC 61508 family expect this chain to be explicit and traceable. An assessor reading the safety case wants to follow a number from the SIL claim all the way back down to the FMEDA line item it came from.

The Inputs an FMEDA Depends On

FMEDA is only as good as the data going into it. Two things matter most: the failure rate for each component, and the failure mode distribution that says how that total rate splits across the ways the component can fail.

Failure rate data comes from a few places:

• Manufacturer reliability data: vendor-published failure rates for a specific part, often the most accurate source when it exists and matches your use case

• SN 29500: a widely used reliability database that provides base failure rates for electronic components under defined reference conditions

• IEC 61709: a standard that defines reference conditions and stress models for converting base failure rates to your actual operating conditions

The catch is that none of this data is unconditional. Every source assumes a set of operating conditions: temperature, electrical stress, duty cycle. A failure rate quoted at 40 degrees C means something different for a part running at 85 degrees C. Pulling a number from a database without checking the conditions behind it is one of the fastest ways to build an FMEDA that looks rigorous and is quietly wrong.

Where FMEDA Goes Wrong

The same handful of mistakes show up across teams.

Mismatched failure mode distributions. A component's total failure rate is one number. How that number splits across failure modes is a separate assumption, and it is often borrowed from a generic source that does not match the specific part or how it is used. Get the distribution wrong and the safe-versus-dangerous split is wrong, which makes DC and SFF wrong even when the total failure rate is fine.

Unverified vendor data. A manufacturer failure rate is a starting point, not a finished input. It was generated under specific test conditions and assumptions. If those do not match your application, the number does not transfer cleanly. Treating a datasheet figure as gospel without checking what produced it is a common gap assessors find.

Not updating the FMEDA when the design changes. This is the quiet one. The FMEDA gets done early, the SIL number turns green, and the analysis gets filed. Then the design moves. A component is swapped, a diagnostic is added or modified, a part gets used in a new way. The FMEDA still describes the old design, and every number derived from it, DC, SFF, SIL, is now describing a system that no longer exists.

That last problem is structural, not careless. When the FMEDA lives in a spreadsheet disconnected from the architecture it describes, nothing forces the two to stay in sync. This is part of why roughly 60% of safety engineering time goes to documentation rather than design work. Every change means manually reconciling the same failure data across multiple disconnected documents.

How ASAP Keeps FMEDA Connected

A platform built for the full safety lifecycle treats FMEDA outputs as live inputs to the architecture, not as a static attachment.

ASAP ties FMEDA failure rates to the architecture and the SIL calculation they support. When a component's failure rate or diagnostic configuration changes, the affected diagnostic coverage, safe failure fraction, and SIL figures update with it. The fault tree and the FMEDA share the same underlying model, so the top-down and bottom-up views describe one system rather than two documents that drift apart. The analysis stays current across the lifecycle instead of going stale the moment the design moves.

This matters at scale. A single autonomous system can carry dozens of safety functions, each with its own FMEDA, each contributing to an overall safety argument. Tracking that by hand is where failure rates fall out of sync with the design and where assessors find the gaps.

Fennec's specified ASAP tools are qualified by TÜV Rheinland as Tool Class 2 (T2) offline support tools under IEC 61508-3:2010, Clause 7.4.4. Reliability UI 0.5.181 is within the reported scope. The qualification does not replace review of the FMEDA, its calculations, or its project-specific assumptions.