ISO 26262

The Automotive Safety Integrity Level (ASIL) is a risk classification scheme at the core of ISO 26262. It quantifies the necessary rigor of safety measures based on three factors:

• Severity of potential harm
• Exposure probability of the operational scenario
• Controllability by the driver or other systems

ASIL ratings range from QM (Quality Management, no specific safety requirements) to ASIL A, B, C, and D (the most stringent). An ASIL D requirement, for a critical function like electronic power steering, demands the highest level of verification, fault tolerance, and process rigor.

ISO 26262 prescribes a safety lifecycle structured around the V-model, which tightly couples development phases with corresponding verification and validation activities.

Left side of the V (Development):

• Concept Phase: Hazard Analysis and Risk Assessment (HARA) to derive safety goals and ASILs.
• Product Development: System, hardware, and software-level design, each with specific safety requirements.

Right side of the V (Verification/Validation):

• Integration Testing: Hardware-software and system integration.
• Safety Validation: Confirming the system meets its safety goals in the vehicle.

This model ensures traceability from high-level safety goals down to individual software modules and hardware components, and back up through testing.

The Functional Safety Concept (FSC) is the pivotal output of the concept phase. It translates abstract safety goals (e.g., "prevent unintended acceleration") into technically actionable functional safety requirements.

Key elements defined in the FSC include:

• Safety Mechanisms: Technical solutions to detect, control, or mitigate faults (e.g., a watchdog to reset a frozen microcontroller, a redundant sensor channel).
• Fault Tolerance Time Intervals: The maximum allowable time between a fault occurrence and the system reaching or maintaining a safe state.
• Allocation of Requirements: Distributing safety requirements to specific system elements (e.g., ECU, sensor, software function).

The FSC serves as the primary specification for all subsequent system, hardware, and software development.

ISO 26262 defines quantitative metrics to objectively evaluate hardware architectural safety:

• Single-Point Fault Metric (SPFM): Measures the robustness against single-point faults, which are faults that directly cause a violation of a safety goal without a safety mechanism. A high SPFM (e.g., >99% for ASIL D) indicates good coverage by safety mechanisms.
• Latent-Fault Metric (LFM): Measures the robustness against latent faults, which are undetected faults that, combined with a second fault, could cause a hazard. A high LFM indicates effective diagnostic coverage for multi-point faults.
• Probabilistic Metric for Hardware Failures (PMHF): Estimates the probability of a random hardware failure causing a violation of a safety goal per hour of operation. It must be below a target value (e.g., <10⁻⁸/h for ASIL D).

These metrics drive design choices like redundancy, diversity, and diagnostic coverage.

Software development under ISO 26262 is governed by derived software safety requirements, which are traced from the system and functional safety concepts. The standard mandates specific techniques based on the assigned ASIL:

• Coding Standards: Use of enforceable guidelines like MISRA C/C++ to avoid error-prone constructs.
• Software Unit Design & Testing: Techniques include control flow analysis, data flow analysis, and unit testing with high statement and decision coverage (MC/DC for ASIL D).
• Software Integration Testing: Verification that software components interact correctly.
• Verification of Safety Mechanisms: Specific testing to confirm that implemented software safety mechanisms (e.g., plausibility checks, alive monitoring) function as specified in the FSC.

Beyond technical work products, ISO 26262 mandates rigorous supporting processes to ensure systematic safety engineering:

• Safety Management: Oversight by a safety manager, planning via a safety plan, and independent functional safety audits and assessments.
• Confidence in Use of Software Tools: Evaluation of development tools (compilers, debuggers) to justify that their potential malfunctions do not introduce safety violations.
• Qualification of Software Components: Process for integrating pre-existing or externally developed software (e.g., an OS or library) with evidence of its suitability for the safety context.
• Configuration Management: Tracking of all safety-relevant items and their versions.
• Change Management: Formal impact analysis for any modifications after initial release.
• Documentation: Creation of the Safety Case, a structured argument supported by evidence, to demonstrate that safety goals have been achieved.

Hardware-in-the-Loop (HIL) testing is a critical validation technique in the ISO 26262 V-model. It involves connecting a physical hardware component (e.g., an Electronic Control Unit - ECU) to a real-time simulator that provides realistic sensor inputs and receives actuator commands. For robotic systems, HIL testing:

• Verifies that embedded controllers function correctly with simulated plant models.
• Enables stress testing of safety mechanisms under fault conditions (e.g., sensor failure injection).
• Allows for repeatable and exhaustive scenario testing that would be dangerous or costly in the real world.
• Is a key method for providing evidence for ASIL certification.

Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined within ISO 26262. It determines the necessary rigor of safety measures. ASIL is assigned based on:

• Severity of potential injury.
• Exposure probability of the operational scenario.
• Controllability by the driver or other road users. The four levels are ASIL A (lowest) to ASIL D (highest). An ASIL D requirement, such as for a steering system, mandates the most stringent development processes, architectural constraints (e.g., high fault coverage), and testing evidence. Systems with no safety impact are classified as QM (Quality Management).

Fault Detection and Diagnostics (FDD) is a core capability mandated by functional safety standards. It involves continuously monitoring a system to:

• Detect anomalies, errors, or deviations from expected behavior.
• Diagnose the root cause of the fault (e.g., which sensor has failed).
• Initiate a safe state or mitigation strategy, as defined by the safety concept. In ISO 26262, this is realized through safety mechanisms like plausibility checks, range monitoring, and end-to-end communication protection (e.g., CRC checksums). For robots, FDD is essential for triggering fallback behaviors or safe stops.