Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26262-5:2018 — Hardware-Level Functional Safety for Automotive Systems
Hardware Design, Architectural Metrics, PMHF, and Safety Mechanism Implementation for Road Vehicles
Introduction to ISO 26262-5:2018 Hardware Development
ISO 26262-5:2018 defines the requirements for product development at the hardware level within the automotive functional safety lifecycle. This standard is where abstract safety requirements meet physical implementation — specifying how hardware components such as microcontrollers, sensors, actuators, ASICs, FPGAs, and power supplies must be designed, analyzed, and verified to achieve the required Automotive Safety Integrity Level (ASIL).
What sets hardware development apart from software in functional safety is the need for quantitative evaluation. ISO 26262-5 introduces rigorous mathematical metrics to assess the hardware architecture’s ability to detect and control random hardware failures, making it one of the most technically demanding parts of the entire standard series.
For hardware engineers new to functional safety: the two most important metrics you need to understand are SPFM (Single-Point Fault Metric) and LFM (Latent-Fault Metric). These quantify how well your hardware design protects against dangerous failures.
Hardware Safety Requirements and Design Process
Clause 6 addresses the specification of hardware safety requirements, derived from the technical safety concept and system architectural design. The hardware safety requirements must specify attributes such as:
- Diagnostic coverage and fault detection latency for each hardware element
- Safe-state definitions and fault reaction times
- Hardware-specific constraints (temperature range, voltage tolerances, EMC immunity)
- Requirements inherited from the HSI specification
Clause 7 covers hardware design, divided into two sub-phases:
- Hardware architectural design — defining the high-level hardware structure, partitioning into elements, and allocating safety requirements
- Hardware detailed design — specifying each hardware element in detail, including schematics, bill of materials, and design justification
The design process must include safety analyses (FMEA, FTA, DFA) at the hardware level to identify failure modes, their causes and effects, and to define appropriate safety mechanisms.
When designing hardware for ASIL C or D, redundant safety mechanisms are typically required. For example, a dual-core lockstep CPU with a separate watchdog monitor provides both fault detection (via lockstep comparison) and fault reaction (via watchdog timeout).
Hardware Architectural Metrics: SPFM and LFM
Clause 8 specifies the evaluation of hardware architectural metrics using two key quantitative measures:
| Metric | Full Name | What It Measures | ASIL B Target | ASIL C Target | ASIL D Target |
|---|---|---|---|---|---|
| SPFM | Single-Point Fault Metric | Coverage against failures that directly violate a safety goal without being detected | ≥90% | ≥97% | ≥99% |
| LFM | Latent-Fault Metric | Coverage against failures that, in combination with another independent fault, violate a safety goal | ≥60% | ≥80% | ≥90% |
These metrics are calculated by analyzing each hardware element, classifying its failure modes (safe, detected single-point, detected latent, etc.), and summing the diagnostic coverage across all elements. The calculations follow the formulas in Annex C of the standard.
A common pitfall: achieving the SPFM/LFM targets through analysis alone is not sufficient. The diagnostic coverage claimed for each safety mechanism must be justified — either by quantitative FMEDA (Failure Modes, Effects and Diagnostic Analysis) using industry-recognized failure rate data (e.g., IEC TR 62380 or SN 29500), or by qualitative arguments supported by field data or testing.
PMHF Evaluation and Safety Goal Violation
Clause 9 addresses evaluation of safety goal violations due to random hardware failures, offering two alternative methods:
- Probabilistic Metric for random Hardware Failures (PMHF) — a global quantitative approach that calculates the average probability of violating a safety goal over the vehicle lifetime (typically 10-15 years). The target for ASIL D is <10-8 failures per hour (or <10-9 for some interpretations of the standard).
- Evaluation of Each Cause (EEC) — a cut-set analysis approach that examines each identified fault or fault combination that could violate a safety goal, and ensures the residual risk is acceptably low for each cause.
The PMHF calculation must account for:
- Failure rates of all hardware elements (λ values from industry reliability data)
- Diagnostic coverage of each safety mechanism
- Exposure time for latent faults (typically the driving/diagnostic interval)
- Fault handling times and safe-state transitions
PMHF budgeting is a critical design activity. If you know your hardware architecture early, create a PMHF budget table that allocates failure rate targets to each subsystem. This prevents late-stage surprises when the cumulative PMHF exceeds the ASIL D target and expensive redesign becomes necessary.
Hardware Integration and Verification
Clause 10 requires a structured approach to hardware integration and verification, ensuring that the implemented hardware satisfies the hardware safety requirements. Key verification activities include:
- Hardware integration tests (testing interactions between hardware elements)
- Hardware verification tests (testing each requirement against the implemented design)
- Environmental tests (temperature, vibration, humidity, EMC)
- Fault injection tests (verifying diagnostic coverage and fault reactions)
The verification depth depends on ASIL — higher ASILs require more rigorous test methods, broader test coverage, and more extensive documentation.
Frequently Asked Questions
Q: What is the difference between SPFM and LFM?
A: SPFM addresses single-point faults — failures that directly cause a safety goal violation without needing a second fault. LFM addresses latent faults — failures that remain undetected and, when combined with a second independent fault, cause a safety goal violation. For example, a stuck-at-zero fault in a brake sensor that directly triggers unintended braking is a single-point fault, while a fault in the diagnostic circuit that prevents detection of the sensor fault is a latent fault.
A: SPFM addresses single-point faults — failures that directly cause a safety goal violation without needing a second fault. LFM addresses latent faults — failures that remain undetected and, when combined with a second independent fault, cause a safety goal violation. For example, a stuck-at-zero fault in a brake sensor that directly triggers unintended braking is a single-point fault, while a fault in the diagnostic circuit that prevents detection of the sensor fault is a latent fault.
Q: How do I obtain failure rate data for hardware elements?
A: The standard does not mandate specific data sources. Commonly used reliability data standards include Siemens SN 29500, IEC TR 62380 / IEC 61709, and MIL-HDBK-217. For semiconductors, vendor-provided data or ISO 26262-11 guidance on semiconductor failure modes can be used. The key requirement is that the data source is justified and consistently applied.
A: The standard does not mandate specific data sources. Commonly used reliability data standards include Siemens SN 29500, IEC TR 62380 / IEC 61709, and MIL-HDBK-217. For semiconductors, vendor-provided data or ISO 26262-11 guidance on semiconductor failure modes can be used. The key requirement is that the data source is justified and consistently applied.
Q: Can I use software-based diagnostics to improve hardware metrics?
A: Yes, software-based diagnostics (e.g., CPU self-tests, RAM test libraries, communication checksums) can contribute to diagnostic coverage. The hardware-software interface (HSI) specification must document which diagnostics are implemented in software and their assumed coverage. However, the diagnostic test interval and fault reaction time must still meet the hardware safety requirements.
A: Yes, software-based diagnostics (e.g., CPU self-tests, RAM test libraries, communication checksums) can contribute to diagnostic coverage. The hardware-software interface (HSI) specification must document which diagnostics are implemented in software and their assumed coverage. However, the diagnostic test interval and fault reaction time must still meet the hardware safety requirements.
Q: What is FMEDA and how does it relate to ISO 26262-5?
A: FMEDA (Failure Modes, Effects and Diagnostic Analysis) is the primary analysis method used to calculate the SPFM, LFM, and PMHF values required by the standard. FMEDA extends traditional FMEA by incorporating quantitative failure rate data and diagnostic coverage factors to produce numerical metrics. Most functional safety certification efforts for hardware rely heavily on FMEDA results.
A: FMEDA (Failure Modes, Effects and Diagnostic Analysis) is the primary analysis method used to calculate the SPFM, LFM, and PMHF values required by the standard. FMEDA extends traditional FMEA by incorporating quantitative failure rate data and diagnostic coverage factors to produce numerical metrics. Most functional safety certification efforts for hardware rely heavily on FMEDA results.
