BMS Hardware Architectural Metrics (SPFM, LFM, PMHF)

A BMS safety case does not stop at assigning an ASIL to a function like contactor control or isolation monitoring. Once that target is set, ISO 26262 Part 5 requires the hardware design to prove, with numbers, that random hardware failures — not systematic design errors, but the ordinary failure rate of resistors, comparators, ADC channels and microcontroller silicon — are caught and controlled often enough to justify the ASIL. That proof takes the form of three hardware architectural metrics: the Single-Point Fault Metric (SPFM), the Latent-Fault Metric (LFM), and the Probabilistic Metric for random Hardware Failures (PMHF). This page covers what each metric means, the target values ASIL B/C/D hardware has to clear, and the architectural choices — dual-core lockstep, diverse dual-microcontroller pairs, and diagnostic coverage on the sensing and actuation paths — used in practice to hit ASIL-C/D targets in a BMS.

The Three Hardware Architectural Metrics

All three metrics start from the same input: a Failure Modes, Effects and Diagnostic Analysis (FMEDA) of the hardware, which classifies every component failure mode as safe, single-point, residual, multiple-point detected, or multiple-point latent, and assigns each a failure rate. The metrics then roll those classifications up into the coverage figures a safety case has to report.

SPFM — the proportion of the hardware’s overall failure rate that is either inherently safe or covered by a safety mechanism, out of everything that isn’t. A single-point fault is one that, on its own, can violate the safety goal with no diagnostic to catch it — an undetected short in the contactor drive path, for example. SPFM measures how much of the design has been engineered so that this class of fault either can’t happen or gets caught.
LFM — the same idea applied to latent multiple-point faults: failures that don’t violate the safety goal by themselves, but that sit undetected until a second, independent fault combines with them to do so. A failed redundant voltage-sense channel that nobody notices because the primary channel is still reporting correctly is a latent fault; LFM measures how well the design surfaces faults like this before they can combine with anything else.
PMHF — a single probabilistic figure, expressed in failures in time (FIT, failures per 10⁹ hours), for the violation of the safety goal from any combination of hardware failures over the item’s operating life. Where SPFM and LFM are architecture-coverage percentages, PMHF is the bottom-line residual risk number a safety case ultimately has to clear.

ISO 26262-5:2018 sets the pass/fail bar for each metric against the ASIL of the safety goal in question:

Metric	ASIL B	ASIL C	ASIL D
SPFM	≥ 90%	≥ 97%	≥ 99%
LFM	≥ 60%	≥ 80%	≥ 90%
PMHF	< 100 FIT	< 100 FIT	< 10 FIT

These are targets, not automatic outcomes — a design has to be architected deliberately to reach them. For a BMS, that mainly means engineering diagnostic coverage into the two paths a hardware fault can actually hurt someone through: the measurement path (cell voltage, current, temperature, isolation resistance) and the actuation path (contactor drive), plus the microcontroller that sits between them.

Getting There: Redundant Microcontroller Architectures

ASIL D’s 99% SPFM and 90% LFM targets are difficult to reach with a single microcontroller core and software diagnostics alone — the residual undiagnosed fraction of the silicon itself tends to dominate the budget. Two architectural patterns are used in practice to close that gap, and they are not the same thing even though both get shortened to “lockstep” in casual use:

Dual-core lockstep (DCLS) — two CPU cores inside a single microcontroller execute the identical instruction stream in parallel (often with one core’s clock delayed by a few cycles, “time diversity”, so the same transient noise pulse can’t hit both cores in the same state at once), and dedicated comparator logic checks their outputs agree on every cycle. A mismatch is flagged immediately as a core-level fault. This is the dominant pattern in automotive-grade MCUs qualified to ASIL D, and it primarily raises diagnostic coverage on the CPU core itself — it does not, on its own, cover faults in the shared silicon around the cores (a single power rail, a single crystal oscillator, a single die).
Diverse dual-microcontroller pairs — two physically separate microcontrollers, sometimes from different vendors or process nodes, cross-check each other’s outputs over a communication link (a “1-out-of-2” or monitor/actuator arrangement). Because the two devices don’t share a die, a power domain, or (if genuinely diverse) even a design house, this pattern is what actually addresses common-cause failure risk that a single-chip lockstep core can’t — the scenario the to-do item’s “dual-microcontroller” phrasing points at specifically, as distinct from dual-core lockstep within one chip.

Many production BMS designs combine both: a lockstep-capable microcontroller as the primary safety MCU handling contactor and isolation logic, backed by a smaller, independent monitor microcontroller (sometimes integrated into the safety-rated system basis chip alongside watchdog and power-supervision functions) whose only job is to check the primary MCU is still behaving plausibly and to force the contactors open independently if it isn’t. The monitor path is deliberately kept simple, because a complex monitor just relocates the single-point-fault problem rather than solving it.

→ Dual-Core Lockstep vs. Dual-Microcontroller Architectures for ASIL D BMS — a closer look at how these two patterns differ, where each falls short on its own, and how ASIL decomposition and common-cause independence factor into the choice.

Alongside core redundancy, the other diagnostic mechanisms that typically get credited in the FMEDA for a BMS safety MCU are error-correcting code (ECC) on RAM and flash, a windowed watchdog timer that both cores/MCUs must service correctly and on schedule, memory protection units that catch a runaway task from corrupting safety-relevant data, and ADC/sensor plausibility checks (range checks, cross-checking redundant sense channels) on the voltage, current and temperature inputs — this last category is the hardware-diagnostics counterpart to the sensor redundancy and plausibility checking covered on BMS Sensors and BMS Testing.

Where the Numbers Come From

In practice, an automotive-grade MCU vendor supplies its own FMEDA report and pre-calculated SPFM/LFM/failure-rate figures for the silicon as qualified out of the box (Infineon’s AURIX and NXP’s S32K3 families, among others, publish these for exactly this reason), so a BMS hardware team is not deriving the microcontroller’s own numbers from scratch. What the team still has to do is extend that FMEDA to the rest of the safety-relevant hardware — the contactor drive circuit, the current-sense shunt and amplifier chain, the isolation monitor, the communication path to the monitor MCU — and combine it with the vendor figures to arrive at an item-level SPFM, LFM and PMHF for the safety goal as a whole, since the standard’s targets apply to the complete hardware architecture, not to the microcontroller in isolation.