Functional Safety (ISO 26262)

The Automotive Safety Integrity Level (ASIL) is a risk classification scheme central to ISO 26262. It determines the necessary rigor of safety activities. ASIL is assigned based on three factors:

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

ASIL levels range from QM (Quality Management, no specific safety requirements) to ASIL A, B, C, and the most stringent ASIL D. A system controlling electric power steering, for example, would typically be classified as ASIL D. This classification dictates the required testing coverage, design methodologies, and documentation throughout the development lifecycle.

ISO 26262 prescribes a structured safety lifecycle mapped onto a V-model. This ensures safety is systematically addressed from concept to decommissioning.

Left Side (Definition & Design):

• Concept Phase: Item definition, hazard analysis and risk assessment (HARA), and ASIL determination.
• Product Development:
  • System Level: Technical safety concept, system design.
  • Hardware Level: Hardware safety requirements, design, and analysis (e.g., FMEDA).
  • Software Level: Software safety requirements, architectural and unit design.

Right Side (Integration & Verification):

• Software Level: Unit testing, integration testing.
• Hardware Level: Integration and testing.
• System Level: Vehicle integration, safety validation.

The V-model ensures traceability, where each requirement on the left is verified by a corresponding test on the right.

The Functional Safety Concept (FSC) is a top-level specification of the safety measures needed to achieve the required ASIL. It is derived directly from the safety goals established during hazard analysis.

Key elements include:

• Safety Goals: Top-level safety requirements, each with an assigned ASIL (e.g., "Prevent unintended vehicle acceleration").
• Functional Safety Requirements: How to achieve each safety goal, often specifying fault detection, fault handling, and fault mitigation strategies.
• Safe States: Defined system states to enter upon detecting a fault (e.g., "gradual torque ramp-down" for a motor fault).
• Fault Tolerance Time Interval (FTTI): The maximum time allowed between fault detection and entry into a safe state.

The FSC bridges the gap between abstract safety goals and the technical system architecture.

ISO 26262 employs a dual strategy to manage systematic and random hardware faults.

Fault Avoidance (Systematic Faults): Aims to prevent faults introduced during development (e.g., specification errors, software bugs). Techniques include:

• Rigorous coding standards (e.g., MISRA C)
• Detailed design reviews and audits
• Comprehensive requirement tracing
• Qualified development tools

Fault Tolerance (Random Hardware Faults): Aims to control random failures in hardware during operation. This involves architectural metrics and safety mechanisms:

• Single-Point Fault Metric (SPFM): Measures coverage against single faults causing a violation.
• Latent Fault Metric (LFM): Measures coverage against undetected faults.
• Safety Mechanisms: Redundancy, monitoring circuits (watchdogs, voltage supervisors), plausibility checks, and diagnostic software (e.g., memory tests, CPU core self-tests).

The Technical Safety Concept (TSC) refines the Functional Safety Concept into a hardware and software architecture. It allocates safety requirements to specific architectural elements.

Critical architectural patterns include:

• Fail-Operational vs. Fail-Safe: A fail-safe architecture enters a safe state upon failure. A fail-operational architecture maintains functionality (often via redundancy) despite a failure, required for functions like steer-by-wire.
• Safety Mechanisms: Specific technical implementations like lockstep cores (two CPU cores executing in lockstep for immediate error detection), End-to-End (E2E) communication protection (e.g., CRC, sequence counters), and periodic memory built-in self-test (MBIST).
• Independence: To avoid common-cause failures, safety mechanisms should be sufficiently independent from the elements they monitor (e.g., separate hardware watchdog IC, software partitions with memory protection).

ISO 26262 mandates rigorous, multi-layered testing and independent review.

Verification: Confirms that work products meet their specified requirements ("Did we build it right?").

• Methods: Reviews, static analysis, unit/integration testing, hardware-in-the-loop (HIL) testing.

Validation: Confirms the system meets the safety goals in the final vehicle ("Did we build the right thing?").

• Methods: Vehicle-level testing, including fault injection tests to verify safety mechanisms trigger correctly.

Confirmation Measures: Independent assessments to ensure the standard is correctly applied.

• Functional Safety Audit: Checks the safety process.
• Functional Safety Assessment: Evaluates the achieved functional safety of the item before release.
• Confirmation Reviews: Conducted at key lifecycle milestones by personnel not directly involved in the work product's creation.

The Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined within ISO 26262. It quantifies the necessary rigor of safety activities based on severity, exposure, and controllability of potential hazards. ASIL levels range from QM (Quality Management, no safety requirements) to ASIL D (the most stringent).

• Determination Process: A Hazard Analysis and Risk Assessment (HARA) assigns an ASIL to each safety goal.
• Impact on Design: ASIL dictates requirements for architectural metrics (e.g., single-point fault metric, latent fault metric), fault tolerance, diagnostic coverage, and verification effort.
• Decomposition: A higher ASIL requirement can be decomposed into multiple lower-ASIL elements, provided independence is maintained, to reduce implementation complexity.

Failure Mode and Effects Analysis (FMEA) is a systematic, bottom-up risk assessment methodology used to identify potential failure modes of components, their causes, and their effects on the system. While not exclusive to ISO 26262, it is a foundational technique used throughout the safety lifecycle.

• Types: Includes Design FMEA (DFMEA) for systems and components and Process FMEA (PFMEA) for manufacturing.
• Role in ISO 26262: Informs the Hazard Analysis and Risk Assessment (HARA) and supports the derivation of technical safety requirements. It is crucial for evaluating hardware architectures and calculating diagnostic coverage.
• Output: A prioritized list of failures based on Risk Priority Number (RPN), guiding mitigation efforts like adding diagnostics or design changes.

Fault Tree Analysis (FTA) is a top-down, deductive failure analysis technique. It starts with a defined undesired top-level event (e.g., "unintended acceleration") and uses logical gates (AND, OR) to graphically model the combination of lower-level failures and events that could cause it.

• Quantitative Analysis: When failure rate data is available, FTA can calculate the probability of the top-level event.
• Role in ISO 26262: Used to verify that safety goals are met, to evaluate the effectiveness of safety mechanisms, and to support the calculation of probabilistic metrics for random hardware failures (PMHF).
• Complement to FMEA: While FMEA is inductive (component failure -> system effect), FTA is deductive (system failure -> root causes).

Automotive SPICE (Software Process Improvement and Capability Determination) is a process assessment model for automotive software development. It focuses on process capability and maturity, whereas ISO 26262 focuses on functional safety assurance.

• Synergistic Relationship: ISO 26262 often prescribes what safety activities must be done (e.g., "perform software unit testing"). Automotive SPICE provides a framework for how to perform those activities in a high-quality, managed process.
• Process Reference: Many ISO 26262 work products (like verification reports) align with Automotive SPICE process outcomes. A mature Automotive SPICE process base is highly beneficial for efficiently achieving ISO 26262 compliance.
• Joint Audits: Organizations are frequently assessed concurrently for both Automotive SPICE capability and ISO 26262 compliance.