The Numbers and Documents ISO 26262 Expects From a Chip Team

Sooner or later, an automotive customer sends a chip team a list of requests: an FMEDA, a safety manual, a dependent failure analysis, and a statement of which ASIL the part can support. ISO 26262 sits behind that list, and it was written for road vehicle systems, not for silicon. A semiconductor team has to work out what the standard means for a block of RTL that has no vehicle attached to it yet.

This post goes through what Part 5 and Part 11 ask of that team: the metric targets, a small FMEDA you can redo by hand, what ASIL decomposition does and does not buy, how to build a Safety Element out of Context, and the documents customers expect. It is general background and is not legal, compliance or functional safety certification advice.

Key takeaways

• Part 5 holds the hardware requirements. Part 11 is informative and offers possible interpretations for semiconductors.
• Vendor papers restating Part 5 give SPFM targets of 90%, 97% and 99% and LFM targets of 60%, 80% and 90% for ASIL B, C and D.
• At ASIL D, everything that escapes your diagnostics has to fit inside about 1% of the safety-related failure rate. The weakest covered block usually decides the result, not the strongest.
• Decomposition lowers the ASIL of redundant requirements, but it depends on independence, and it does not relax the evaluation of random hardware failures.
• A part built out of context is only as useful as its assumptions of use.

What each part is for

ISO's summary of Part 5 lists its scope as hardware safety requirements, hardware design, evaluation of the hardware architectural metrics, evaluation of safety goal violations from random hardware failures, and hardware integration and verification. Those are requirements. Part 11, by ISO's own description, is informative only and contains possible interpretations of the other parts for semiconductor development. Other interpretations can be valid, which matters when a customer treats a Part 11 example as a rule.

Both current texts date from December 2018, and neither is the last word for long. ISO lists both as due to be replaced by draft international standards. The record for ISO/DIS 26262-5 shows a 12-week ballot opened on 14 October 2026. This post works from the 2018 edition, and a programme starting now should ask its customer which edition the contract names.

The published targets

The figures below are as restated by NXP, Synopsys and TI, whose tables agree.

Metric	ASIL B	ASIL C	ASIL D
Single-point fault metric (SPFM)	90%	97%	99%
Latent fault metric (LFM)	60%	80%	90%
Probabilistic metric for random hardware failures (PMHF)	10-7 per hour (100 FIT)	10-7 per hour (100 FIT)	10-8 per hour (10 FIT)

Not every vendor summary agrees on every cell, and the sources also differ on whether the limit is written as "greater than" or as a bare figure, so check the boundary in the licensed text.

A single FIT is one failure in 10⁹ device hours. The metrics themselves are simple ratios. NXP's paper writes them in this form:

• SPFM = 1 - (residual and single-point FIT) / (total safety-related FIT)
• LFM = 1 - (latent multi-point FIT) / (total safety-related FIT - residual and single-point FIT)

Siemens EDA and Renesas describe the difference in purpose. SPFM measures protection against faults that can violate a safety goal alone. LFM concerns faults that matter only in combination, which is why the safety mechanisms themselves appear in it. If failure mode analysis is new to you, our introduction to FMEA covers the method that an FMEDA extends with failure rates and diagnostic coverage.

A worked FMEDA

Every number in this section is an illustrative assumption, not data from any device, foundry or handbook. The block is a small control subsystem with permanent and transient faults merged into one rate, which a real analysis would not do. Residual is rate x (1 - safe share) x (1 - diagnostic coverage). Latent is the covered part x (1 - latent coverage).

First pass

Element and mechanism	Rate (FIT)	Safe share	Diagnostic coverage	Residual (FIT)	Latent coverage	Latent (FIT)
CPU pair, lockstep	40	20%	99%	0.32	100%	0
SRAM, ECC	25	0%	99%	0.25	90%	2.475
Interconnect, parity	20	10%	90%	1.80	100%	0
Clock and reset, monitor	5	0%	90%	0.50	100%	0
Safety mechanism logic, no self-test	10	0%	Not applicable	0	0%	10
Total	100			2.87		12.475

Caught lockstep, parity and clock faults raise an alarm, so they are not latent. Some corrected SRAM errors are assumed to go unreported. The safety mechanism logic cannot violate the goal alone, so its faults are multi-point, and with no test they are all latent.

• SPFM = 1 - 2.87 / 100 = 97.13%
• LFM = 1 - 12.475 / (100 - 2.87) = 1 - 12.475 / 97.13 = 87.16%

Against the table above, both clear ASIL B and ASIL C. Both miss ASIL D. Notice where the problem sits. The CPU is the largest block but contributes only 0.32 FIT of residual. The interconnect is half its size and contributes 1.80 FIT, and the 10 FIT of untested checker logic accounts for most of the latent total.

Second pass

Now raise the interconnect and clock coverage to 99% and add a start-up self-test that gives the safety mechanism logic 90% latent coverage. New logic has its own failure rate, so that row rises from 10 to an assumed 12 FIT.

Element	Rate (FIT)	Residual (FIT)	Latent (FIT)
CPU pair	40	0.32	0
SRAM	25	0.25	2.475
Interconnect	20	0.18	0
Clock and reset	5	0.05	0
Safety mechanism logic	12	0	1.20
Total	102	0.80	3.675

• SPFM = 1 - 0.80 / 102 = 99.22%, above the 99% ASIL D target
• LFM = 1 - 3.675 / (102 - 0.80) = 1 - 3.675 / 101.2 = 96.37%, above the 90% ASIL D target

1. The small block counts. Fix the interconnect alone and leave the clock monitor at 90%, and residual is 1.25 FIT, which gives 98.77%. A 5 FIT block can still hold you below the line.
2. The margin is thin. Suppose fault simulation shows the interconnect at 97% and not the 99% you assumed. Its residual becomes 0.54 FIT, the total becomes 1.16 FIT, and SPFM falls to 98.86%. Two points of coverage on one row lose the target.
3. Conventions move results. Safe faults stay in the total here. Remove the 10 FIT of safe faults from the first pass and SPFM drops from 97.13% to 96.81%, below the ASIL C line. Agree the convention with your assessor before comparing numbers with anyone.

PMHF is left out because it needs lifetime and multi-point terms. To try your own rows, the Hardware Safety Metrics Calculator on The Semiconductor Hub rolls up SPFM, LFM and a simplified PMHF from an FMEDA-style list. It does not replace a safety assessment.

Where the inputs come from

Failure rates. TI's analysis summary for the TCAN4550-Q1 (August 2022) notes that neither IEC 61508 nor ISO 26262 mandates one estimation method. Common choices include IEC/TR 62380, SN 29500, IEC 61709 and field data. TI says IEC/TR 62380 has been withdrawn, but that its equations live on in Part 11. TI also claims its field data shows package and silicon permanent rates at least two orders of magnitude below those estimates, so TI treats the handbook figure as a conservative input. That is a vendor claim.

Do not leave out the package. In TI's default example for that small CAN controller, the package accounts for 8.07 of 9.33 raw FIT, and the mission profile has a large effect on it. For transient faults, TI says it knows of no estimation standard and relies on radiation testing of test chips.

Diagnostic coverage. As Siemens EDA's Chuck Battikha explains in a 2021 post, the standard's labels map to about 99% for high, 90% for medium and 60% for low, and Part 5 Annex D and Part 11 Clause 5 offer recommended values to cite. Annex D is not exhaustive, so other techniques are allowed with evidence. Overstated coverage flatters the metrics, and understated coverage leads to over-engineering.

Typical mechanisms, as listed by Synopsys in a 2022 paper, include dual-core lockstep, temperature and voltage monitors, built-in self-test and software checks, with triple redundancy and SEC-DED ECC able to keep a design running through a fault. Lockstep can also bring physical requirements, such as temporal or physical diversity between the cores.

Measurement. Early FMEDA numbers are estimates. The Synopsys paper describes updating them as the design matures: static analysis at RTL, fault injection once the testbench exists, and fault simulation on the netlist. Fault lists are built from models such as stuck-at, open and bridging faults, and our post on stuck-at and transition delay fault models explains how a fault must activate and propagate before it can be observed. The paper puts a typical SoC's fault count in the billions, so reduction and sampling are not optional.

Sampling brings its own uncertainty. A March 2026 preprint from Robert Bosch authors (Armato, Kehl and Fischer) propagates the error in coverage and failure mode estimates through the SPFM formula. In their processor case study, the total uncertainty was 0.53%, which they say can cancel out reaching an ASIL B target. This is a preprint, but the point fits the example above: a result about 0.2 points over the line is not comfortable.

ASIL decomposition: what it buys

Decomposition splits a safety requirement into redundant requirements on sufficiently independent elements, each with a lower ASIL, while keeping the original goal in brackets. TI's April 2019 white paper tabulates the allowed splits from Part 9. ASIL D can become D(D) + QM(D), C(D) + A(D) or B(D) + B(D). ASIL C and ASIL B have their own, shorter lists.

Two points catch teams out.

Independence has to be real. TI's steering lock example shows a second MCU that receives vehicle speed through the first one. A common cause failure in the first MCU can then feed bad data to its supposed checker, so the split fails. Inside one die, the same question applies to shared clocks, power and reset. Arm describes its dependent failure analysis as covering common cause sources in the IP and the mitigations that it or its partner must apply.

The hardware metrics do not shrink. A May 2025 preprint from the University of Stuttgart (Zaheri and Reuss) states that decomposition leaves hardware metric evaluation and random failure assessment unchanged, so B(D) elements still answer to the metrics for ASIL D. TI's paper says the split enables two ASIL B MCUs to serve an ASIL D function, and the two views fit only if you check the random hardware numbers at the level of the original goal. In our reading, decomposition mainly relaxes systematic rigour. Confirm this against Part 9 before you plan a schedule around it. Our post on automotive microcontrollers shows how lockstep and related mechanisms appear in real parts.

Building out of context

A Safety Element out of Context is developed without a specific vehicle in view. TI's safety information for the TPS3704 family (2022) describes the method plainly: develop against assumptions about how the part will be used, then verify those assumptions at system level. These are the assumptions of use.

The consequence is that SEooC does not mean finished. Synopsys's white paper on confirmation measures points out that functional safety can only be achieved at item level, and a supplier's assessment has a limited scope that feeds the next integration level.

In practice, a good assumption of use is something the integrator can test: a required response time, a software routine that has to run, a monitor that must sit outside the chip. Tailoring follows from this. TI ships an FMEDA workbook in which users edit the mission profile and diagnostics, and Renesas offers a tool for per-goal tailoring that warns if a mechanism is too slow to prevent a failure.

What a customer will ask for

The exact list comes from your Development Interface Agreement, which sets out roles between supplier and integrator. Arm offers a standardised Development Interface Report in its place. This table combines what Arm, Synopsys and TI describe publicly, so treat it as a typical set.

Item	What the customer does with it
Safety manual	Reads the mechanisms, assumptions of use and assessment results, and checks they fit the system
FMEDA report or workbook	Feeds its own system-level metrics, tailored to the blocks and mission profile in use
Dependent failure analysis	Checks common cause sources and which mitigations fall to the integrator
FIT rate, failure mode distribution and pin analysis	Builds board-level analysis, especially for simpler parts
Safety plan and technical safety concept	Confirms the planned activities and the architecture behind the claims
Fault injection and verification reports	Looks for evidence behind the coverage figures
Confirmation review and assessment reports, safety case, certificate	Judges independence and how far the claims have been examined

Ask early what level of claim you are making. Arm's 2022 portfolio separates a standard level, with a full safety package but no independent assessment, from an extended level assessed by a third party. TI's categories run from FIT data through to a product certificate on select parts. Decide this before the customer asks, because evidence is much harder to create after tape-out.

Sources

• ISO, catalogue summaries for ISO 26262-5:2018 and ISO 26262-11:2018 (December 2018), and the stage record for ISO/DIS 26262-5, ballot initiated 14 October 2026.
• NXP (Lopez and Clairet), "Safe and Robust Functional Safety System Basis Chip (SBC) For Future Transportation Systems", June 2016. Vendor, written against the 2011 edition.
• Synopsys (Nitzan and Land), "Leveraging Lessons Learned from Automotive Design Reliability and Functional Safety for Aerospace and Defense Applications", GOMACTech 2022. Vendor.
• Synopsys (Chonnad, Litovtchenko and Sargsyan), "The Role of Confirmation Measures in ISO 26262 Functional Safety Automotive Products", undated. Vendor.
• TI vendor documents: mmWave radar functional safety design guide, SWRU598A, April 2024; TCAN4550-Q1 analysis report summary, SFFS246, August 2022; TPS3704 safety information, SFFS169A, 2022.
• TI (George), "C2000 MCU SafeTI control solutions: An introduction to ASIL decomposition and SIL synthesis", April 2019. Vendor.
• Arm, "Arm Safety Ready Portfolio", 2022. Vendor document.
• Renesas (Richards and Cefalo), "Renesas Functional Safety Support for Automotive (2)", March 2021. Vendor blog.
• Siemens EDA (Battikha), "Is Engineering Best Judgement really 'Best'? (Part 1)", 16 March 2021. Vendor blog.
• Armato, Kehl and Fischer, "Quantifying Uncertainty in FMEDA Safety Metrics: An Error Propagation Approach for Enhanced ASIC Verification", arXiv:2603.21770, March 2026. Preprint.
• Zaheri and Reuss, "ASIL-Decomposition Based Resource Allocation Optimization for Automotive E/E Architectures", arXiv:2505.07881, May 2025. Preprint.

The FMEDA tables use illustrative numbers, not data from any real device. Vendor figures are the companies' own claims, as published on the dates shown. Target values are as restated by the vendors named. This post is not legal, compliance or functional safety certification advice.