Functional Safety (FuSa)

The foundational process in functional safety that identifies potential hazards a system can cause and quantifies the associated risk. It determines the required Automotive Safety Integrity Level (ASIL) or Safety Integrity Level (SIL).

• Hazard: A potential source of harm (e.g., unintended vehicle acceleration).
• Risk: Combination of severity, exposure, and controllability of a hazard.
• Output: Defines safety goals and the required integrity level for the system.

A discrete level specifying the required risk reduction provided by a safety function. ASIL (Automotive) ranges from A (lowest) to D (highest). SIL (IEC 61508) ranges from 1 to 4.

• ASIL D requires the most rigorous processes and architectural measures.
• The level dictates requirements for fault tolerance, diagnostic coverage, and probabilistic metrics for random hardware failures.
• Determined via HARA based on severity, exposure, and controllability.

The core causality model in FuSa that distinguishes between different states of malfunction.

• Fault: A defect in hardware or software (e.g., a stuck-at-bit, coding bug). It is the root cause.
• Error: A deviation from correct service state within the system, caused by a fault.
• Failure: The system's inability to perform a required function. A failure observed at the system boundary is a hazard.

Safety mechanisms are designed to detect and mitigate errors before they propagate to failures.

Technical solutions implemented to detect, control, or mitigate faults to prevent failures. Diagnostic Coverage (DC) quantifies their effectiveness.

• Examples: Watchdog timers, memory parity/ECC, logic built-in self-test (LBIST), plausibility checks, redundant execution channels.
• Diagnostic Coverage: The proportion of dangerous random hardware faults a mechanism can detect. A key metric for calculating Probabilistic Metric for Random Hardware Failures (PMHF).
• High ASIL/SIL levels require high DC, often >99% for ASIL D.

The high-level technical specification derived from safety goals. It defines what the system must do to be safe, before detailed design begins.

• Translates abstract safety goals (e.g., "prevent unintended torque") into functional safety requirements.
• Allocates these requirements to system architectural elements (hardware/software).
• Specifies initial safety mechanisms and defines safe states (e.g., shutdown, limp-home mode).
• It is the crucial bridge between risk assessment and technical implementation.

The FuSa development lifecycle is structured around the V-Model, emphasizing that testing must be planned for each design phase.

• Left side (Verification): Confirms work products are correctly derived ("Are we building the product right?"). Includes reviews, static analysis, and unit testing.
• Right side (Validation): Confirms the final system meets safety requirements ("Are we building the right product?"). Includes Hardware-in-the-Loop (HIL) testing, field tests, and fault injection.
• Independence: Critical activities, especially for high ASIL, require independent reviewers or teams.

Fault Detection, Isolation, and Recovery (FDIR) is a systematic approach for handling faults in a system. It is a core technical implementation of functional safety requirements.

• Detection: Identifying that a fault or failure has occurred (e.g., via built-in self-tests, watchdog timers, or plausibility checks).
• Isolation: Determining the exact component or subsystem that is faulty to prevent fault propagation.
• Recovery: Taking action to maintain or restore a safe state. This can involve redundancy switching (failing over to a backup), entering a limp-home mode, or executing a controlled shutdown. FDIR architectures are designed based on the failure modes identified during the Hazard and Risk Analysis (HARA).

The Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by ISO 26262. It quantifies the necessary rigor of safety requirements for a system or component. ASIL is determined by evaluating three factors for a potential hazard:

• Severity (S): The potential harm to persons.
• Exposure (E): The probability of the operational scenario.
• Controllability (C): The ability of the driver or other actors to avoid harm. The combination yields an ASIL rating: QM (Quality Management, no special measures), A, B, C, or D (most stringent). ASIL D dictates the highest requirements for fault tolerance, design processes, and documentation. This drives architectural decisions like redundancy and diversity.

Hardware-in-the-Loop (HIL) testing is a critical verification and validation method in functional safety. It involves connecting the real electronic control unit (ECU) or embedded controller to a real-time simulator that models the vehicle dynamics, sensors, and actuators. This allows for:

• Deterministic, repeatable testing of safety-critical scenarios that are dangerous or impossible to perform physically (e.g., emergency braking at high speed).
• Fault injection to verify the system's FDIR mechanisms respond correctly.
• Validation of software and hardware integration under realistic, high-fidelity conditions. HIL testing provides essential evidence for ISO 26262 certification, proving that safety goals are met under defined operational conditions.