Dual-Core Lockstep vs. Dual-Microcontroller Architectures for ASIL D BMS

BMS Hardware Architectural Metrics covers the SPFM, LFM and PMHF targets an ASIL-C/D hardware design has to clear, and notes that reaching them for a BMS’s contactor-control and isolation-monitoring functions usually means adding redundant microcontroller hardware rather than relying on a single core and software checks. This page goes deeper on the two architectural patterns used to do that, dual-core lockstep and diverse dual-microcontroller pairs. They are frequently talked about as interchangeable and they are not: they defend against different failure classes, and most production ASIL-D BMS designs end up using both together rather than choosing one.

Hardware Fault Tolerance: Why Redundancy Is Needed at All

ISO 26262 expresses this as Hardware Fault Tolerance (HFT). A function with HFT = 0 has no ability to tolerate a single dangerous fault — if the one channel implementing it fails, the function is lost. A function with HFT = 1 survives a single fault, because a second, sufficiently independent channel can still perform it, or can force the system to a safe state on the first channel’s behalf. A single microcontroller running safety software is an HFT = 0 design: whatever coverage its internal diagnostics achieve, there is only one channel, and the SPFM/LFM math on BMS Hardware Architectural Metrics gets progressively harder to satisfy at ASIL C and D as a result. Both patterns below exist to move a BMS from HFT = 0 to HFT = 1 on its safety-relevant functions — they just add the second channel in different places.

Dual-Core Lockstep

In a lockstep pair, two CPU cores inside the same microcontroller execute the identical instruction stream, and dedicated comparator logic checks their outputs agree every cycle. A mismatch is flagged as a core fault immediately, with no software involved in the detection path. This is a hardware mechanism aimed squarely at random hardware failures in the core itself — a bit flip from a cosmic-ray strike, a transistor degrading, a transient glitch on the clock or supply — and it is why lockstep cores are the default way automotive MCU vendors get a core qualified for ASIL D.

Two limits matter for a BMS design relying on it:

It does not cover systematic software faults. Both cores run the same code, so a bug in that code produces the same wrong answer on both cores at once — lockstep comparison sees agreement, not correctness. Software safety mechanisms (requirements-based testing, code coverage, the discipline covered on BMS Testing) are a separate line of defence, not something lockstep substitutes for.
Sharing a die is itself a common-cause failure risk. Because both cores sit on the same piece of silicon, share a power domain and a clock tree, a fault that hits the die broadly — supply noise, thermal stress, a manufacturing defect near both cores — can in principle affect both in the same way at the same time, which is exactly the scenario lockstep is meant to catch. Vendors mitigate this with diverse lockstep: physically separating the two cores’ layout on the die and offsetting their clock phase (“time diversity”) so the same transient event is less likely to disturb both cores identically. Texas Instruments’ Hercules/TMS570 family is a concrete example of this — the two Cortex-R4F cores aren’t simply duplicated side by side; one is mirrored, rotated, and kept upwards of 100 µm away from the other on the die, purely so that a localized physical disturbance (a particle strike, a supply glitch confined to one area of the silicon) is unlikely to hit both cores’ logic in the same way at the same moment.

In practice, lockstep coverage is bought as a feature of the safety MCU itself rather than designed from scratch: Infineon’s AURIX TC3xx family, for instance, can pair up to four of its six TriCore cores into lockstep configurations, and NXP’s S32K3 Cortex-M7 family offers single, dual-independent and lockstep core configurations of the same silicon depending on which variant is ordered — the BMS hardware team is selecting a pre-qualified core configuration, not building the comparator logic itself.

Diverse Dual-Microcontroller Architectures

The second pattern uses two physically separate devices instead of two cores on one die: a primary microcontroller running the main BMS application, monitored by a second, independent device whose job is narrower — check the primary is still behaving plausibly, and force the contactors open or otherwise drive the system to a safe state if it isn’t. Because the monitor is a different piece of silicon, typically on its own power rail and clock source, and often a much simpler design than the primary MCU, this pattern addresses exactly the shared-die and shared-power common-cause risk that dual-core lockstep can only partially mitigate through layout diversity.

In production BMS hardware, the “second microcontroller” is frequently not a second general-purpose MCU at all, but the monitoring function built into an automotive safety system basis chip (SBC) — the same device that already supplies the primary MCU’s regulated power rails. NXP’s FS26 and Infineon’s TLF35584 are both ASIL-D-rated SBCs of this kind: alongside power supply, both implement independent voltage monitoring, a watchdog the primary MCU must service correctly and on schedule, and a safe-state controller that can act on the power and reset lines directly if the primary MCU stops responding correctly — giving the “dual-microcontroller” independence without the cost and complexity of a second full application processor.

This pattern also maps directly onto ASIL decomposition, the ISO 26262 mechanism that lets a single ASIL D safety requirement be apportioned across two independent elements each carrying a reduced ASIL B(D) rating, provided the independence between them can be argued. A primary safety MCU and an independent monitor SBC, each developed and assessed as its own element, is a common way a BMS safety case implements exactly that decomposition — but the independence argument is the hard part: it has to address every failure mode that could take out both channels together (a shared connector, a shared ground fault, a shared firmware update path), not just note that the parts are different.

Comparing the Two

	Dual-core lockstep	Diverse dual-microcontroller
What it primarily catches	Random hardware faults in the CPU core	Faults anywhere in the primary MCU, including ones the primary’s own diagnostics miss
Common-cause exposure	Shared die, power domain, clock — mitigated, not eliminated, by physical/time diversity	Low, if the two devices genuinely don’t share power, clock or silicon
Covers systematic software faults?	No — same code runs on both cores	Only if the monitor’s logic is independently developed, not a copy of the primary’s
Added BOM / design cost	Usually built into the safety MCU part choice; limited extra cost	A second device (or SBC monitor function) plus the cross-checking interface between them
Typical BMS role	Inside the primary safety MCU running contactor logic, SoX estimation, diagnostics	Independent watchdog/safe-state path, often via the SBC already supplying the primary MCU’s power

The two are complementary rather than competing choices, which is why most production ASIL-D BMS designs use both: a lockstep-capable microcontroller runs the primary application at the core level, and an independent monitor — usually the safety SBC’s own watchdog and safe-state path — provides the second, physically separate channel that a shared-die lockstep pair cannot fully provide on its own. Whether that combination is enough to clear the SPFM/LFM/PMHF targets for a given safety goal is exactly the FMEDA exercise described on BMS Hardware Architectural Metrics.