Safety-certified MCUs and real-time control processors

Executive summary

A “safety-certified MCU” is not a generic microprocessor. It is a microcontroller whose CPU, memory, bus, clock, reset, I/O, and software stack are designed to fail in a predictable way and to expose those failures to the system so the system can reach a safe state. In practice, the value is created by four things: (1) hardware fault-detection mechanisms such as dual-core lockstep, ECC, windowed watchdogs, voltage/clock monitors, and built-in self-test; (2) design-process evidence under IEC 61508/ISO 26262, including safety manuals and FMEDA tables; (3) deterministic real-time control peripherals such as high-resolution PWM, fast ADCs, and low-latency interrupt paths; and (4) toolchain/certification evidence that lowers the system integrator’s qualification burden.

The economic moat is not just the silicon. It is the documentation trail, failure-rate tables, diagnostic coverage numbers, and the safety culture that an automotive or industrial customer must audit. A patent is evidence that an architecture was disclosed; it is not evidence that the product achieves any SIL or ASIL level. A safety manual is a supplier self-report; it is not an independent regulatory certification. The distinction matters for investment analysis.

Two source-tier warnings apply throughout:

1. Many vendor pages say “ASIL-D ready,” “ASIL-D capable,” or “SIL 3/4 capable.” These are supplier claims, not independent regulatory approvals. ISO 26262 certifies a safety element out of context or a system, not a standalone chip’s fitness for every customer application.
2. Company 10-K/20-F filings are legally risk-weighted and generally do not repeat the most aggressive product-level safety claims. That does not necessarily mean product claims are false, but it does mean they are not independent confirmation.

What “safety-certified” actually means

The governing standards separate risk levels and quantitative failure budgets.

IEC 61508-1:2010 defines Safety Integrity Levels (SIL 1–4). For low-demand modes, SIL is expressed as average probability of failure on demand, PFDavg. For high-demand/continuous modes, it is expressed as probability of a dangerous failure per hour, PFH [S1]. The commonly used quantitative boundaries are:

Source: IEC 61508-1:2010, functional safety standard, published 2010-04-30 [S1].

ISO 26262, the automotive adaptation, uses ASIL A–D. For ASIL D safety goals, ISO 26262-5:2018 specifies a single-point fault metric (SPFM) of at least 99% and a latent fault metric (LFM) of at least 90%, plus a probabilistic metric for random hardware failures, often expressed as 10 FIT or fewer for an ASIL D safety goal under the standard’s PMHF framework [S2]. One FIT is one failure per 10⁹ device-hours, so 10 FIT equals 1×10⁻⁸ failures per hour.

This is not the same as “the chip cannot fail.” It means the chip’s dangerous undetected failure contribution must be small enough that the system can still meet its safety goal after adding sensors, actuators, software, power supplies, and the end-use safety concept.

Peer-reviewed dependability literature makes the same point conceptually: fault prevention, fault tolerance, fault removal, and fault forecasting are distinct activities, and a system’s dependability cannot be reduced to a single hardware metric [S3][DOI: 10.1109/TDSC.2004.2].

Core safety hardware mechanisms

2.1 dual-core lockstep

The dominant architecture in safety MCUs is two CPUs executing the same instruction stream with deterministic comparison. If the two cores diverge, a hardware comparator raises a fault. This is often advertised as “cycle-by-cycle lockstep” by vendors, including Texas Instruments for its Hercules/TMS570/RM4 families [S5][S6].

Patent evidence shows that duplicated or redundant execution with comparison is an old and well-documented fault-tolerance technique. U.S. Pat. No. 5,923,834, granted 1999-07-13, discloses fault-tolerant processing that uses redundant execution and comparison [S4][patents.google.com . This supports the general technical feasibility claim, but it does not prove that any current MCU meets SIL 3 or ASIL D. Patents are legal disclosure documents, not test reports.

Lockstep is strong against single-event upsets and random transistor faults, but it can be defeated by common-cause failures: clock glitches, power-supply collapses, design errors, or software faults that affect both channels identically. Dependability literature explicitly treats common-cause failures as a separate risk and does not treat simple duplication as automatically sufficient [S3].

2.2 ECC, parity, and memory protection

Safety MCUs typically include:

• ECC or parity on SRAM and flash
• address/data bus parity
• memory protection units to enforce task isolation
• write protection for safety-relevant registers
• deterministic cache/TCM behavior

Vendor documentation describes these features for TI’s TMS570LC4x, NXP’s S32K3, Infineon’s AURIX, and STMicroelectronics’ SPC5 families [S5][S6][S8][S9][S10]. These are company technical documents, so they are Tier-2/self-reported for adoption and feature claims. The underlying requirement is standards-driven: IEC 61508 and ISO 26262 require systematic and random-hardware failure control, and memory corruption is a major contributor to systematic failure.

2.3 clock, voltage, watchdog, and self-test monitors

Safety MCUs cannot depend only on CPU logic. They include:

• windowed watchdogs
• internal/external oscillator monitors
• supply-voltage monitors
• temperature monitors
• logic built-in self-test, memory built-in self-test
• fault injection and error reporting paths

TI’s TMS570 safety manual describes a “safety island” approach with dedicated diagnostic modules and error-signaling peripherals [S5][S6]. Infineon’s AURIX family markets a Safety Management Unit and “TriCore lockstep” implementation [S9]. NXP’s S32K3 documentation likewise describes real-time fault collection and safe-state control [S8].

These mechanisms are not decorative. The standards require diagnostic coverage sufficient to meet the quantitative hardware failure budget. If a vendor cannot demonstrate diagnostics and coverage, the chip is not useful for a safety certificate.

Real-time control layer

Real-time control is separate from safety, but the two merge in motor drives, digital power, robotics, electric power steering, braking, and battery management. The technical requirements are:

• deterministic interrupt service latency
• high-resolution PWM with fault trip inputs
• fast, low-latency ADCs with hardware post-processing
• control-law accelerators such as trig/division or floating-point units
• cyclic redundancy-checked bus transactions
• low-jitter output for power stages

Texas Instruments’ C2000 platform is the clearest public example of a real-time control processor line that emphasizes low-latency ADC-to-PWM paths and control-law acceleration [S7]. TI markets C2000 for digital power, motor drives, and industrial real-time systems [S7]. STMicroelectronics positions SPC5 for automotive chassis and safety control [S10]. Infineon AURIX is widely marketed for powertrain, chassis, and advanced-driver-assistance safety controllers [S9].

The safety qualification and the real-time capability are often sold together because many safety functions are closed-loop control functions: a brake controller, an inverter torque loop, or a steering assist loop cannot tolerate unbounded interrupt latency.

Source assessment

Tier-1 sources in this note:

Tier-2/self-reported sources:

No SEO content farm or anonymous benchmark is used.

Cross-reference: marketing claims versus filed disclosures

This is where the source-tier discipline is most useful.

Claim: TI’s TMS570LC4357 can help customers achieve ISO 26262 ASIL D or IEC 61508 SIL 3 safety integrity.

Source: TI product page and safety manual; these are supplier self-reports, not independent regulator approvals [S5][S6].

Filed disclosure: Texas Instruments’ 10-K risk discussion identifies product defects, failure to meet customer specifications, long customer qualification cycles, and regulatory/industry standards as material operating risks [S14]. The 10-K does not state that any specific part number is independently certified to ASIL D. Product-level safety capability is documented outside the financial filing in data sheets and safety manuals.

Interpretation: This is not a direct contradiction. It is a standard separation between product marketing and securities-risk language. But an investor should treat “ASIL-D capable” as an engineering claim requiring the safety manual and FMEDA, not an independent seal. The same pattern applies to NXP [S15], STMicroelectronics [S16], and Microchip [S17].

Patent caveat: U.S. Pat. No. 5,923,834 shows that redundant execution/fault-tolerant hardware has been disclosed in the public patent record [S4]. It does not show that any current device’s diagnostic coverage meets a quantitative SIL or ASIL threshold. Patents support moat/feasibility arguments only weakly because they are evidence of recorded claims, not measured reliability.

Quantitative worked calculation

This calculation shows how a safety MCU’s dangerous undetected failure rate translates into a SIL for a proof-testable, low-demand function.

Model: single-channel 1oo1 with periodic proof test.

Formula:

\[

PFD_{avg} = \frac{\lambda_{DU} \times TI}{2}

\]

where:

• \(\lambda_{DU}\) = dangerous undetected failure rate per hour
• \(TI\) = proof-test interval in hours
• The factor \(1/2\) is the standard time-averaged unavailability approximation for a 1oo1 proof-tested system [S1].

Baseline input:

• \(\lambda_{DU}\) = 100 FIT = \(1.0 \times 10^{-7}\) per hour
• \(TI\) = 8,760 hours, one year

\[

PFD_{avg} = \frac{1.0 \times 10^{-7} \times 8760}{2} = 4.38 \times 10^{-4}

\]

That falls between \(10^{-4}\) and \(10^{-3}\), so the baseline is SIL 3 low-demand under IEC 61508-1:2010 [S1].

Sensitivity:

Continuous/high-demand control: If the safety MCU must operate continuously, the relevant metric is PFH. For a single channel with no automatic diagnostics beyond the proof test, PFH is approximately \(\lambda_{DU}\) [S1]. SIL 3 high-demand requires PFH below \(10^{-7}\) per hour, so the dangerous undetected rate must be below roughly 100 FIT under this simplified model. ASIL D’s 10 FIT PMHF target is more stringent by about one order of magnitude [S2].

This calculation is deliberately simplified. A real safety case would use a FMEDA with failure-mode distributions, diagnostic coverage, common-cause factors, and hardware/software systematic capability. The vendor safety manual provides the FMEDA assumptions [S5]; the standard provides the framework [S1][S2].

Parameter table

Unit economics / business model

The technology is monetized primarily through chip sales, but the value capture is unusually broad for MCUs because safety MCUs drag an ecosystem behind them:

• Silicon sale: The MCU itself, often with premium pricing versus catalog general-purpose MCUs. Tier-1 suppliers do not publish part-number-level gross margins; product-level gross margin needs primary source validation. TI’s 10-K reports results at the broader embedded-processing-segment level, not per product family [S14].

• Safety documentation and enablement: TI sells or bundles SafeTI compliance support packages, diagnostic libraries, safety manuals, and certification evidence [S5][S6]. NXP, Infineon, ST, and Microchip all maintain functional-safety package pages [S8][S9][S10][S11].

• Tools and software: Certified compilers, certifiable real-time operating systems, and diagnostic code reduce the integrator’s software certification burden. The economics are still mostly indirect: the chip vendor captures the value through higher silicon win rate and design-in stickiness.

• Certification/audit services: Independent bodies such as TÜV SÜD, TÜV Rheinland, UL, and exida provide assessment and certification services. These are not covered here by a Tier-1 public source, but they are an economically real layer of the value chain.

The largest value capture likely remains with the chip vendor because the safety MCU is the evidentiary anchor of the system safety case. Switching to a different MCU means rebuilding the FMEDA, failure-mode coverage, diagnostic libraries, and possibly requalification. That creates design-in stickiness and raises switching costs.

Disconfirming Evidence

The thesis that safety-certified MCUs and real-time control processors have a durable technology moat would be wrong if any of the following occur:

1. Standards commoditize the silicon: If IEC 61508/ISO 26262 compliance becomes so standardized that every general-purpose MCU includes equivalent safety diagnostics with negligible marginal cost, the pricing premium and documentation moat would erode.

1. Centralized autonomy reduces discrete safety MCU demand: If vehicle/robot architects shift safety functions into high-performance domain controllers with redundant software, lockstep accelerators, or dedicated safety islands integrated into application processors, standalone safety MCU attach rates could fall.

1. Common-cause failure evidence undermines lockstep: If independent testing shows that dual-core lockstep provides substantially lower diagnostic coverage in deployed systems than vendor FMEDA assumptions claim, safety MCU value would be overstated.

1. Open-source/portable safety evidence replaces vendor safety manuals: If neutral industry bodies publish portable FMEDAs and diagnostic libraries that make supplier switching low-cost, the design-in stickiness of incumbent vendor documentation would weaken.

1. Regulatory slowdown: If functional-safety mandates in automotive and industrial equipment are delayed or softened, the forced purchase of certified MCUs could decelerate even if the underlying technology remains superior.