Functional Safety (ISO 26262)

ISO 26262 is the international standard for functional safety of electrical and electronic systems in production road vehicles. It covers the entire safety lifecycle from concept to decommissioning, addressing safety management, system/hardware/software development, production, and operation. It was first published in 2011 (Edition 1) and updated in 2018 (Edition 2) to include motorcycles, trucks, buses, and semiconductors.

Part 1: Vocabulary. Part 2: Management of functional safety. Part 3: Concept phase. Part 4: Product development at the system level. Part 5: Product development at the hardware level. Part 6: Product development at the software level. Part 7: Production, operation, service, decommissioning. Part 8: Supporting processes. Part 9: ASIL-oriented and safety-oriented analyses. Part 10: Guidelines. Part 11: Semiconductor guidelines. Part 12: Adaptation for motorcycles.

The V-model structures development into a left side (specification/design, top-down) and a right side (testing/validation, bottom-up). For safety: Concept → System Design → HW/SW Design on the left, and HW/SW Testing → System Integration Testing → Safety Validation on the right. Each design level has a corresponding test level. Requirements flow down, verification flows up, with bidirectional traceability throughout.

ASIL (Automotive Safety Integrity Level) represents the level of risk reduction required. It is determined through HARA by evaluating three factors: Severity (S0-S3) - how bad the injury could be; Exposure (E0-E4) - how often the hazardous situation occurs; and Controllability (C0-C3) - how well the driver can manage the situation. The combination maps to ASIL A (lowest), B, C, or D (highest), or QM (no safety requirement).

Each ASIL level requires increasingly stringent development processes, verification methods, and safety mechanisms. ASIL D requires the most rigorous approach: formal methods, MC/DC coverage, highest diagnostic coverage (≥99% SPFM, ≥90% LFM), independent confirmation review, and more extensive safety analysis. ASIL A has the least stringent requirements. The effort and cost increase roughly 2-3x per ASIL level.

A Safety Goal is the top-level safety requirement that prevents or mitigates a hazard identified during HARA. It is assigned an ASIL level, specifies the safe state, and defines the fault tolerant time interval. Example: 'Unintended acceleration shall not occur' (ASIL D). All technical safety requirements, safety mechanisms, and verification activities trace back to Safety Goals.

A Safe State is a state of the system where no unreasonable risk exists, even if the function is degraded or disabled. Examples: electric power steering defaults to manual steering assist (degraded), emergency braking system deactivates with driver warning (off), and engine management limits torque output (limp mode). The safe state must be reached within the Fault Tolerant Time Interval (FTTI).

FTTI is the minimum time from a fault occurrence to a potential hazardous event. It defines how quickly the system must detect the fault and transition to a safe state. FTTI = Diagnostic Test Interval + Fault Reaction Time + Safe State Transition Time. For steering: FTTI might be 50ms. For headlights: FTTI could be seconds. FTTI drives the design of diagnostic coverage and safety mechanisms.

The Safety Concept defines how safety goals are achieved through technical measures. It includes: safety mechanisms (fault detection, reaction, indication), ASIL allocation to system elements, degradation strategies, diagnostic requirements, and fault tolerance time specifications. The Functional Safety Concept (Part 3) defines 'what' at a functional level, while the Technical Safety Concept (Part 4) defines 'how' at the system level.

The Safety Manager oversees the functional safety process: planning, scheduling, resource allocation, and ensuring compliance with the safety plan. The Safety Engineer performs technical safety activities: HARA, safety analysis (FMEA/FTA), deriving safety requirements, reviewing designs, and verifying safety mechanisms. ISO 26262 Part 2 defines organizational roles and independence requirements between them.

Hazard Analysis and Risk Assessment (HARA) identifies hazards from malfunctioning behavior of the item and determines ASIL levels. Steps: 1) Define the item and its functions. 2) Identify malfunctioning behaviors (e.g., unintended activation, loss of function). 3) Identify hazardous events (malfunction + operational situation). 4) Rate S, E, C for each event. 5) Determine ASIL. 6) Define Safety Goals. HARA is performed during the concept phase.

Severity rates the potential injury to vehicle occupants or road users: S0 - no injuries. S1 - light to moderate injuries. S2 - severe to life-threatening injuries (survival probable). S3 - life-threatening to fatal injuries (survival uncertain). The rating considers the worst reasonable consequence. Example: loss of power steering at highway speed = S3 (potential loss of vehicle control leading to fatal collision).

Exposure rates how frequently the operational situation occurs: E0 - incredible. E1 - very low probability (e.g., specific rare road condition). E2 - low probability (e.g., icy mountain road). E3 - medium probability (e.g., heavy rain driving). E4 - high probability (e.g., normal highway driving, every trip). Exposure considers the driving population, not just one driver.

Controllability rates how well the driver or other road users can manage the hazardous situation: C0 - controllable in general. C1 - simply controllable (>99% of drivers). C2 - normally controllable (>90% of drivers). C3 - difficult to control or uncontrollable (<90% of drivers). Example: gradual loss of power assist = C1 (noticeable, correctable), sudden unintended acceleration = C3 (difficult to control quickly).

ASIL Decomposition splits a safety requirement into redundant independent requirements at lower ASIL levels. Decomposition rules: ASIL D → D(D) or D(C+A) or D(B+B); ASIL C → C(C) or C(B+A); ASIL B → B(B) or B(A+A). Both elements must implement the requirement independently with proven independence (no common cause failures). Decomposition reduces development cost but requires demonstrating freedom from interference.

FFI means that a fault in a lower-ASIL or QM element cannot cause a failure in a higher-ASIL element. It is required when elements of different ASIL levels share resources (CPU, memory, I/O). FFI is achieved through: spatial isolation (MPU/MMU partitions), temporal isolation (time partitioning, watchdogs), and communication isolation (E2E protection). FFI must be demonstrated through analysis or testing.

Failure Mode and Effects Analysis systematically identifies potential failure modes, their causes, effects, and mitigations. For each component/function: list failure modes (open, short, stuck, drift), determine local and system-level effects, assess severity, identify detection methods, and calculate RPN (Risk Priority Number = Severity × Occurrence × Detection). FMEA is performed at system, hardware, and software levels per ISO 26262.

Fault Tree Analysis is a top-down deductive method: start with an undesired event (top event = hazard), decompose into combinations of lower-level faults using AND/OR gates. FTA identifies the minimum cut sets - smallest combinations of faults causing the top event. FMEA is bottom-up (component to system effect), FTA is top-down (system effect to component cause). Both are required by ISO 26262 Part 9.

DFA identifies failures that can affect multiple elements simultaneously, defeating redundancy or independence assumptions. Categories: Common Cause Failures (same root cause, e.g., temperature), Common Mode Failures (same failure mode in similar elements), and Cascading Failures (failure in one element triggers failure in another). DFA is critical for validating ASIL decomposition and safety mechanism independence.

A Single Point Fault (SPF) directly leads to a safety goal violation without being detected by any safety mechanism. A Latent Fault is a hidden fault that alone doesn't cause a hazard but could in combination with another fault - it is not detected during normal operation. Both are addressed by safety mechanisms: SPFs by diagnostic coverage, latent faults by periodic testing or monitoring.

Three metrics evaluate hardware safety: SPFM (Single Point Fault Metric) = percentage of single-point faults covered by safety mechanisms (ASIL D requires ≥99%). LFM (Latent Fault Metric) = percentage of latent faults covered (ASIL D requires ≥90%). PMHF (Probabilistic Metric for Hardware Failure) = residual failure rate for random hardware failures (ASIL D requires <10⁻⁸/hour). These are calculated using failure rates and diagnostic coverage.

Diagnostic Coverage (DC) = (failure rate of faults detected by safety mechanism) / (total failure rate of the element). Example: if a sensor has a total failure rate of 100 FIT and the monitoring detects 90 FIT worth of faults, DC = 90%. IEC 61508 categorizes: Low (60-90%), Medium (90-99%), High (≥99%). DC values are estimated from safety analysis or taken from standardized tables in ISO 26262 Part 5 Annex D.

Part 6 covers: software safety requirements specification, architectural design (modularity, encapsulation), detailed design and coding (coding guidelines, naming), unit testing (with specified coverage metrics), integration testing, and qualification testing. Higher ASIL levels require more rigorous methods - ASIL D requires MC/DC coverage for unit tests, formal verification methods, and semi-formal notation for design.

Requirements depend on ASIL: Statement coverage - highly recommended for ASIL A/B, recommended for C/D. Branch coverage - recommended for ASIL B, highly recommended for C/D. MC/DC (Modified Condition/Decision Coverage) - recommended for ASIL C, highly recommended for ASIL D. MC/DC ensures each condition in a decision independently affects the outcome, providing the most thorough structural testing.

MC/DC requires that every condition in a decision is shown to independently affect the decision's outcome. For 'if (A && B)': test cases must show A changing the outcome with B fixed (true→false while B=true), and B changing the outcome with A fixed. MC/DC needs N+1 test cases for N conditions (vs 2^N for full combination). It provides high assurance with manageable test effort.

Part 6 requires enforcement of coding guidelines that: promote safe coding practices, avoid undefined behavior, ensure deterministic execution, and enable static analysis. MISRA-C:2012 is the de facto standard for C code. Additionally, CERT-C for security. Tools like Polyspace, LDRA, or QAC verify compliance. Deviations from guidelines must be formally documented and justified.

ISO 26262 recommends: Modular design with well-defined interfaces. Encapsulation and information hiding. Restricted access to global data. No dynamic objects or memory allocation. Limited use of interrupts with proper management. Hierarchical structure. Defensive programming with assertion checks. Error detection and handling at module interfaces. These enable analyzability, testability, and fault containment.

Tools used in safety development must be classified by Tool Confidence Level (TCL 1, 2, or 3) based on Tool Impact (TI) and Tool Error Detection (TD). TI1+TD1 = TCL1 (no qualification needed). Higher TCL requires qualification methods: increased confidence from use (1a), development process evaluation (1b), validation of tool (1c), or third-party certification. Code generators (e.g., Embedded Coder) typically need TCL3 qualification.

Verification confirms that the output of a development phase meets its input specification (did we build it right?). Validation confirms that the safety goals are met by the implemented system (did we build the right thing?). Verification includes reviews, testing, and analysis at each V-model level. Validation is performed at the vehicle/system level against safety goals and is the final confirmation of safety.

Methods graded by ASIL level include: Walk-through (informal review), Inspection (formal review with checklists), Semi-formal verification (using models), Formal verification (mathematical proof), Simulation, and Testing. Higher ASIL levels require more formal methods. For software, unit testing with MC/DC coverage, back-to-back testing, and static analysis are standard verification activities.

A Confirmation Review is an independent assessment that safety activities comply with ISO 26262 requirements. Reviews cover: the safety plan, HARA, safety concepts, safety analyses, and safety case. Independence requirements increase with ASIL: ASIL A/B allow same team/different person, ASIL C recommends different team, ASIL D requires different department or external assessor. Reviews are documented and findings must be resolved.

Software unit testing (Part 6, Clause 9) requires: requirements-based test cases with defined coverage, structural coverage metrics (statement/branch/MC/DC per ASIL), methods to derive test cases (equivalence classes, boundary values, error guessing), test execution in a defined environment (host or target), and documented test results with pass/fail verdicts traceable to requirements.

A safety mechanism is a technical solution that detects, indicates, or mitigates faults to prevent hazardous events. Examples: plausibility checks (compare redundant sensors), watchdog timers (detect software hangs), E2E protection (detect communication errors), voltage monitoring (detect power faults), and MPU configuration (detect memory violations). Every identified single-point fault needs a safety mechanism.

Hardware: dual-core lockstep (compare CPU outputs), ECC memory (correct single-bit errors), watchdog timers, voltage/temperature monitors, redundant sensors. Software: range checks, plausibility monitoring, program flow monitoring, stack overflow detection, CRC checks, alive/deadline supervision. Communication: E2E protection (counter, CRC), timeout monitoring, SecOC authentication.

Lockstep uses two CPU cores executing the same instructions simultaneously. A comparator checks outputs cycle-by-cycle - any mismatch triggers an immediate fault reaction. This achieves very high diagnostic coverage (>99%) for CPU permanent and transient faults. Common in safety MCUs: Infineon AURIX (lockstep TriCore), TI TMS570 (lockstep ARM). Some implementations add cycle delay to detect common-cause timing faults.

Error Correcting Code memory adds redundancy bits that can detect and correct single-bit errors (SECDED - Single Error Correction, Double Error Detection). Critical for safety because cosmic rays, EMI, and aging can cause bit flips in RAM. ECC is mandatory for ASIL C/D. Flash ECC protects stored code and calibration data. ECC faults trigger safety mechanisms and are logged as hardware errors.

The Memory Protection Unit restricts memory access per task/partition. It prevents: a QM task from corrupting ASIL data (spatial FFI), stack overflow from overwriting other memory, accidental writes to flash or peripheral registers. MPU violations trigger exceptions caught by safety mechanisms. AUTOSAR OS uses MPU for OS-Applications. For ASIL D, MPU is essential for demonstrating Freedom from Interference.

PMHF sums the residual failure rate contributions from all hardware elements: PMHF = Σ(λ_element × (1 - DC_element)) for single-point faults, plus contributions from dual-point faults (residual latent × residual detected, weighted by exposure time). Failure rates (λ) come from standards like SN 29500, IEC 62380, or manufacturer data. ASIL D target: PMHF < 10⁻⁸/h (10 FIT). The calculation is typically done in spreadsheets or specialized tools.

SEooC is a safety-related element developed without knowledge of the specific vehicle/system it will be used in. The developer assumes safety requirements and usage context, documents assumptions, and develops to the assumed ASIL. The integrator must verify that actual requirements match or are less stringent than the assumptions. Common for semiconductor suppliers and Tier-2 BSW providers developing generic AUTOSAR modules.

The HSI defines the contract between hardware and software: register descriptions, interrupt assignments, timing constraints, diagnostic capabilities, safety mechanisms, and configuration requirements. ISO 26262 requires HSI documentation to ensure hardware provides what software assumes. It covers: I/O pin assignments, ADC characteristics, memory map, clock frequencies, and safety-relevant hardware features.

A Safety Case is the structured argument, supported by evidence, that a system achieves adequate functional safety. It contains: safety goals and ASIL assignments, safety concept, evidence of compliance (reviews, test reports, analyses), residual risk evaluation, and a conclusion of safety. The Safety Case is maintained throughout the lifecycle and updated for any changes. It is the primary artifact reviewed during audits.

Part 7 requires: production processes that maintain safety properties (testing, calibration, verification), field monitoring and failure tracking, service procedures that maintain safety, and change management for post-production modifications. Production testing must verify safety-critical components. Field data must be analyzed for emerging safety issues. Updates must follow the safety change management process.

Key changes: extended scope to trucks, buses, and motorcycles; added Part 11 for semiconductor guidelines; improved ASIL decomposition rules; added cybersecurity considerations; refined hardware metric calculations; better guidance on SOTIF interface; added requirements for model-based development; and refined software tool qualification process. Edition 2 also improved practical applicability based on industry experience.

When a change is proposed: 1) Identify all affected safety requirements and work products. 2) Determine if safety goals or ASIL levels are impacted. 3) Assess whether existing safety mechanisms remain valid. 4) Evaluate potential new hazards introduced by the change. 5) Determine required re-verification and re-validation scope. 6) Update the safety case. ISO 26262 Part 8 defines the change management process.

Both are required for automotive software but address different aspects. ISO 26262 defines safety-specific technical requirements (what to do for safety). ASPICE defines process quality (how well development is performed). They complement each other: ASPICE provides the process framework, ISO 26262 adds safety-specific activities. Many work products serve both: requirements documents, test reports, and traceability matrices satisfy both standards simultaneously.