FMEDA without the folklore: what SPFM and LFM actually demand

Every ASIL B and above program eventually arrives at the same table: single-point fault metric, latent fault metric, probabilistic targets. And every program I have joined mid-flight had the same problem — an FMEDA that was arithmetically correct and argumentatively empty. The spreadsheet multiplied FIT rates by diagnostic coverage and hit the target. Nobody could say where the coverage numbers came from.

Having built and defended FMEDAs at both microcontroller and system level — most recently for an ASIL B(D) high-performance computing platform spanning an Aurix TC39x and a Renesas RL78 — here is what the analysis actually has to deliver.

The metric is not the deliverable

SPFM and LFM are summary statistics. What an assessor examines is the chain underneath each number:

1. The failure mode is real. Not “resistor fails,” but the failure mode of the element in the context of the safety function — output stuck, drift, oscillation. Generic failure-mode catalogs are a starting point, not an answer.
2. The failure mode’s effect is traced. Does this failure mode violate the safety goal, and through which path? An FMEDA that has never met the technical safety concept produces effects nobody can defend.
3. The coverage claim has an owner. Every diagnostic-coverage percentage points at a real mechanism — a built-in self-test, a watchdog with a defined window, an E2E-protected CAN frame, a plausibility check in software — with evidence that the mechanism runs, in time, in the real configuration.

The third point is where programs stumble. It is remarkably common to claim coverage from a hardware self-test that the software integration team disabled for boot-time reasons two releases ago.

The SBC is half the argument

On multi-rail compute platforms the safety companion chip does more work than most FMEDA rows admit. Configuring a TLF35584 correctly — window watchdog, voltage monitoring, the error pin path to safe state — closed more system-level gaps on that HPC program than any amount of software mechanism tuning. If your FMEDA treats the SBC as “supervision, 90%, vendor figure,” you have not analyzed it. Read the vendor’s safety manual, map its assumptions of use to your schematic, and verify each one. The assumptions you cannot verify become open points — and finding them at confirmation review is far more expensive than finding them in the analysis.

Latent faults are a scheduling problem

Most latent-fault findings are not missing mechanisms — they are mechanisms that never get exercised. The self-test exists, but nothing guarantees it runs within the multiple-point fault detection interval. The claim “tested at every ignition cycle” fails quietly on platforms that stay powered for days. LFM work is largely about proving when diagnostics run, not whether they exist.

What I check first on an inherited FMEDA

• Do FIT rates come from a stated source (SN 29500, IEC 62380, vendor data) applied at a stated mission profile — or from copy-paste?
• Is there a dangling coverage claim: a percentage with no named mechanism, or a mechanism with no verification evidence?
• Has the FMEDA been updated since the last schematic revision? A quantitative analysis frozen against B-sample hardware is a historical document, not evidence.
• Do MCU-level and system-level analyses agree on the split of responsibilities, or do both silently assume the other side handles the failure mode?

None of this requires exotic tooling. It requires the analysis to be connected — to the safety concept, to the hardware design, to the verification evidence — and kept connected as the design moves. That connection is exactly what dies first in spreadsheet workflows, which is a subject for another post.