Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26262-11:2018 Road Vehicles — Functional Safety — Part 11: Guidelines on Application to Semiconductors
Semiconductor Functional Safety Guide — Fault Models, Failure Rate Estimation, IP Integration, DFA for Automotive ICs
1. Semiconductor Functional Safety — A New Frontier in ISO 26262
ISO 26262-11:2018 is a first edition, published as part of the significant expansion of the ISO 26262 series in 2018. This part addresses the critical need for semiconductor-specific guidance in automotive functional safety. Modern vehicles contain dozens of complex semiconductor components — microcontrollers, SoCs, memories, sensors, power management ICs, and ASICs — each of which must be developed to the required ASIL level. Part 11 provides the specialized knowledge required to apply ISO 26262 to these components effectively.
The semiconductor industry faces unique challenges in functional safety: complex fault models, the need for base failure rate estimation, intellectual property (IP) integration, dependent failure analysis at the silicon level, and the interaction between hardware and software safety mechanisms. Part 11 addresses all of these topics with detailed technical guidance that bridges the gap between the general requirements of ISO 26262-5 (hardware) and ISO 26262-6 (software) and the specific realities of semiconductor design and manufacturing.
Part 11 is essential reading for any engineering team developing a semiconductor component for ASIL-rated applications, as well as for system integrators who need to understand the capabilities and limitations of semiconductor safety mechanisms.
| Topic | Clause | Key Technical Content |
|---|---|---|
| Semiconductor Partitioning | 4.1–4.2 | How to decompose a semiconductor component for safety analysis |
| Fault Models & Failure Modes | 4.3 | Stuck-at, transition, coupling faults; failure mode distribution |
| IP Development & Integration | 4.5 | IP lifecycle, categories, black-box IP integration, work products |
| Base Failure Rate Estimation | 4.6 | IEC TR 62380, SN 29500, permanent failure rate calculation |
| Dependent Failure Analysis | 4.7 | Cascading failures, common cause failures, DFA workflow for semiconductors |
| Fault Injection | 4.8 | Simulation-based and emulation-based fault injection techniques |
| Digital Components & Memories | 5.1 | Fault models for logic, SRAM, DRAM, flash, register files |
| Analog & Mixed-Signal | 5.2–5.6 | ADCs, DACs, power management, sensors, actuators |
| Programmable Logic (FPGA) | 5.7 | Configuration memory, SEU considerations, synthesis safety |
2. Key Technical Concepts for Semiconductor Functional Safety
Part 11 introduces semiconductor-specific fault models that go beyond the general fault classification in ISO 26262-5. For digital components, fault models include stuck-at faults (SA0/SA1), transition faults (slow-to-rise/slow-to-fall), and coupling faults (for memories). The standard provides detailed guidance on failure mode definitions for common digital blocks such as CPUs, DMA controllers, interrupt controllers, and memory controllers. Each failure mode must be evaluated with its associated failure rate distribution to support quantitative analysis.
Base failure rate estimation (Clause 4.6) is a critical topic for semiconductor safety analysis. Part 11 provides detailed guidance on using industry reliability standards such as IEC TR 62380 (RDF 2000) and SN 29500, adapted for semiconductor-specific considerations. The standard explains how to account for technology node effects, operating temperature, voltage stress, and mission profile when calculating failure rates. This guidance is essential for producing credible quantitative safety analyses (PMHF calculations) for semiconductor components.
Failure rate estimation for semiconductors requires careful consideration of the mission profile. A component used in a passenger car engine compartment (high temperature, high vibration) will have a fundamentally different failure rate than the same component used in a cabin infotainment system. Always use the actual use-case mission profile, not generic assumptions.
Dependent failure analysis (DFA) at the semiconductor level (Clause 4.7) addresses the specific failure mechanisms that can affect multiple functions within a single chip. These include: substrate coupling, power supply distribution, thermal coupling, clock distribution, and reset distribution. The DFA workflow described in Part 11 provides a systematic approach to identifying dependent failure initiators, defining mitigation measures, and demonstrating sufficient independence between safety-related elements on the same die.
3. Practical Engineering Design Insights
For semiconductor designers implementing functional safety, several practical insights emerge from Part 11. IP integration (Clause 4.5) requires careful attention to the safety requirements of both the IP provider and the IP integrator. The standard defines three IP categories: safety element out of context (SEooC), safety-related IP with assumed safety requirements, and non-safety IP. Each category has specific requirements for the IP lifecycle, work products, and integration evidence.
For best results with IP integration: Require your IP providers to deliver a safety manual with each IP block. The safety manual should document: assumed safety requirements, fault models, failure modes with rates, diagnostic features, and integration constraints. Without this information, integrating IP into a safety-related design is extremely difficult to justify.
Fault injection (Clause 4.8) is a key verification technique for semiconductor safety mechanisms. Part 11 describes both simulation-based fault injection (e.g., Saber, Spectre, or custom simulation environments) and emulation-based approaches (FPGA-based fault injection for faster throughput). The standard specifies the characteristics or variables to be controlled during fault injection campaigns: fault type, fault location, fault timing, and operational conditions. Proper statistical coverage of the fault space is essential for meaningful results.
A critical insight often missed: Fault injection results must be evaluated not just for whether the safety mechanism detects the fault, but for how long it takes. A safety mechanism that correctly detects a fault but exceeds the FTTI is a non-compliant mechanism. Always include timing measurements in fault injection campaigns.
The specific technology sections (Clause 5) provide detailed guidance for different semiconductor types. For memories, the standard covers ECC (error correction codes), parity, built-in self-test (BIST), and redundancy. For analog/mixed-signal components, it addresses ADC/DAC testing via loopback, power supply monitoring, and comparator-based diagnostics. For FPGAs, it covers configuration memory protection, SEU (single-event upset) mitigation, and the safety implications of synthesis and implementation tools.
Frequently Asked Questions
Q1: What is the minimum failure rate that can be claimed for a semiconductor component?
There is no fixed minimum. The base failure rate must be derived from recognized industry standards (IEC TR 62380, SN 29500) or from field data with appropriate statistical confidence. The standard cautions against using arbitrarily low failure rates without supporting evidence. For modern deep-submicron processes, realistic base failure rates typically range from 10 FIT to 1000 FIT per million gates depending on technology, voltage, and temperature.
There is no fixed minimum. The base failure rate must be derived from recognized industry standards (IEC TR 62380, SN 29500) or from field data with appropriate statistical confidence. The standard cautions against using arbitrarily low failure rates without supporting evidence. For modern deep-submicron processes, realistic base failure rates typically range from 10 FIT to 1000 FIT per million gates depending on technology, voltage, and temperature.
Q2: How should a safety mechanism implemented in software for a hardware fault be classified?
Software-based safety mechanisms for hardware faults can be credited for diagnostic coverage, but the standard requires that the software diagnostic itself be free from systematic faults (developed to the appropriate ASIL). The diagnostic coverage of a software-based mechanism is typically lower than a hardware-implemented mechanism for the same fault, and this must be reflected in the quantitative analysis.
Software-based safety mechanisms for hardware faults can be credited for diagnostic coverage, but the standard requires that the software diagnostic itself be free from systematic faults (developed to the appropriate ASIL). The diagnostic coverage of a software-based mechanism is typically lower than a hardware-implemented mechanism for the same fault, and this must be reflected in the quantitative analysis.
Q3: Can an IP block be developed as a “Safety Element out of Context” (SEooC)?
Yes, and this is the most common approach for semiconductor IP. An SEooC is developed with assumed safety requirements that are documented in a safety manual. The integrator is responsible for verifying that the IP’s assumed safety requirements are consistent with the actual safety requirements of the system. The IP developer must provide sufficient evidence (safety manual, analysis reports, verification results) for the integrator to perform this verification.
Yes, and this is the most common approach for semiconductor IP. An SEooC is developed with assumed safety requirements that are documented in a safety manual. The integrator is responsible for verifying that the IP’s assumed safety requirements are consistent with the actual safety requirements of the system. The IP developer must provide sufficient evidence (safety manual, analysis reports, verification results) for the integrator to perform this verification.
Q4: How does Part 11 address emerging technologies like AI accelerators and neural processing units?
Part 11 provides general guidance that applies to digital components, which covers most AI accelerator architectures (digital compute, memory, data paths). However, the unique aspects of AI/ML safety (e.g., correctness of neural network computations, data path integrity for tensor operations) may require additional analysis beyond the scope of Part 11. The general fault model and DFA approaches remain applicable and provide a starting point for AI accelerator safety analysis.
Part 11 provides general guidance that applies to digital components, which covers most AI accelerator architectures (digital compute, memory, data paths). However, the unique aspects of AI/ML safety (e.g., correctness of neural network computations, data path integrity for tensor operations) may require additional analysis beyond the scope of Part 11. The general fault model and DFA approaches remain applicable and provide a starting point for AI accelerator safety analysis.
