Functional Safety (FuSa)

ASIL is a risk classification scheme defined by ISO 26262. It determines the necessary rigor for mitigating hazards, based on three factors:

• Severity of potential injury
• Exposure probability of the operational scenario
• Controllability by the driver or system

ASIL D represents the highest integrity requirement. For an edge AI system like automatic emergency braking, its perception component would typically require ASIL B or higher, mandating specific architectural patterns like redundancy and extensive fault injection testing.

A Safety Goal is the top-level safety requirement derived from hazard analysis, stating the function to be maintained or the hazardous event to be prevented (e.g., "Prevent unintended acceleration"). The Functional Safety Concept then translates this goal into technical safety requirements allocated to system elements. For an AI-based system, this defines how the AI component's safe state and fault detection mechanisms integrate with the broader vehicle architecture.

These are the fundamental causal chain events in safety engineering:

• Fault: A defect in hardware (e.g., a stuck-at-bit in memory) or software (e.g., a bug).
• Error: A deviation from the correct service state caused by a fault.
• Failure: The inability of a system to perform its required function.

Functional safety aims to prevent faults from propagating into errors and ultimately system failures. For AI hardware, this involves techniques like ECC memory, lockstep cores, and safety monitors to detect and mitigate faults.

FMEDA (Failure Modes, Effects, and Diagnostic Analysis) is a quantitative analysis to compute hardware safety metrics required by ISO 26262:

• Single-Point Fault Metric (SPFM): Measures coverage against single faults causing a violation of a safety goal.
• Latent Fault Metric (LFM): Measures coverage against undetected faults.
• Probabilistic Metric for Random Hardware Failures (PMHF): The probability of a residual random hardware failure causing a safety goal violation.

For an NPU, FMEDA analyzes failure modes of its compute cores, memory, and interconnects to prove compliance with a target ASIL.

Safety Mechanisms are technical solutions implemented to detect faults, control errors, or mitigate failures. Common patterns in edge AI hardware include:

• Dual-Core Lockstep (DCLS): Two cores execute identical instructions in lockstep; a comparator checks outputs for mismatches.
• Built-In Self-Test (BIST): On-chip logic to test the processor itself at startup or periodically.
• Diverse Redundancy: Executing the same function with two different algorithms or hardware types (e.g., a primary AI model and a simpler, deterministic safety checker).
• Watchdog Timers: Monitor for system hangs or timing violations.

Safety mechanisms are specific technical solutions implemented in hardware or software to detect, control, or mitigate faults to prevent hazardous events. For Edge AI systems, these are critical due to the non-deterministic nature of neural networks and harsh operating environments.

Key mechanisms include:

• Dual-Core Lockstep (DCLS): A redundant core executes the same instructions in lockstep, with a comparator checking for divergence to detect random hardware faults.
• Error Correcting Code (ECC) Memory: Detects and corrects single-bit errors in memory, protecting model weights and activations.
• Built-In Self-Test (BIST): On-chip circuitry that tests the processor and memory for faults at startup or during operation.
• Watchdog Timers: Monitor system activity and trigger a safe state (e.g., system reset) if the AI application fails to respond.
• Plausibility Checks: Using simpler, deterministic algorithms or sensor fusion to cross-verify the output of a complex neural network.

Edge AI chips designed for FuSa applications integrate specialized hardware features to meet stringent reliability targets. These go beyond raw TOPS performance to ensure deterministic operation.

Essential features include:

• FuSa-Certified IP Cores: CPU, GPU, or NPU cores that have been developed and verified to a specific ASIL or SIL level.
• Safety Manuals & FMEDA: The chip vendor provides detailed documentation, including a Failure Modes, Effects, and Diagnostic Analysis (FMEDA), which quantifies the diagnostic coverage and residual failure rates of hardware components.
• Separate Safety Island: A physically or logically isolated subsystem (often with its own simple CPU, memory, and I/O) dedicated to running critical safety monitors and managing the main processor's power and reset states.
• Clock & Power Monitoring: Independent circuits to detect clock glitches or voltage drops outside safe operating margins.
• Protected Memory Regions: Hardware-enforced memory protection units (MPUs) to isolate safety-critical code and data from non-critical software.

A core FuSa challenge for Edge AI is transforming statistically-based neural network inference into a time-deterministic and value-deterministic process. Non-determinism can arise from caches, dynamic scheduling, or floating-point non-associativity.

Techniques to achieve determinism include:

• Static Memory Allocation: Pre-allocating all buffers for model weights, activations, and intermediate tensors to avoid non-deterministic heap operations.
• Cache Locking/Pinning: Locking critical sections of code and data into the cache to guarantee worst-case execution time (WCET).
• Fixed-Point/Quantized Execution: Using integer-only arithmetic (e.g., INT8) eliminates the non-associativity of floating-point operations, ensuring bit-exact reproducibility across runs and hardware.
• Deterministic Scheduling: Using a Real-Time Operating System (RTOS) with fixed-priority preemptive scheduling to guarantee task timing.
• Compiler Guarantees: Using a model compiler that generates predictable, straight-line code without branches whose timing depends on data.

Developing FuSa-compliant Edge AI software requires a rigorously documented and controlled process, as important as the technical safety mechanisms themselves.

Key process elements include:

• Safety Plan: Defines the activities, responsibilities, and deliverables for the entire project lifecycle.
• Tool Qualification: Development tools (compilers, static analyzers, testing frameworks) must be qualified for use in safety-critical development to prove they do not introduce errors.
• Coding Standards: Adherence to strict standards like MISRA C/C++ or AUTOSAR C++14 to avoid error-prone language constructs.
• Requirements Traceability: Every safety requirement must be bi-directionally traceable to its source (e.g., HARA), its design implementation, its test cases, and its verification results.
• Independent Safety Assessment (ISA): A separate, independent team reviews the work products (requirements, design, code, tests) to provide objective assurance that safety goals are achieved.

Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by ISO 26262, ranging from ASIL A (lowest risk) to ASIL D (highest risk). The ASIL is determined via Hazard Analysis and Risk Assessment (HARA), evaluating:

• Severity of potential harm.
• Exposure probability of the operational scenario.
• Controllability by the driver or system. An ASIL D rating for a function like automatic emergency braking dictates the most stringent safety requirements, impacting system architecture (e.g., need for hardware redundancy), software development processes, and testing coverage. Edge AI components must be developed to meet the ASIL targets of the functions they enable.

A Safety Element out of Context (SEooC) is a component (e.g., an AI accelerator chip or vision software stack) developed without knowledge of a specific vehicle application. To be integrated into a safety-critical system, the SEooC must be developed under assumptions about its future use. The development process includes:

• Defining explicit Assumptions of Use.
• Implementing safety mechanisms (e.g., error-correcting code (ECC) memory, built-in self-test).
• Providing a Safety Manual detailing residual risks and integration requirements. This model is crucial for semiconductor vendors supplying NPUs and SoCs to multiple automotive OEMs, enabling pre-certified hardware for integration into various ASIL-rated systems.

Hardware Safety Mechanisms are dedicated circuits and architectural features designed to detect and mitigate random hardware faults (e.g., bit flips from cosmic radiation) in safety-critical silicon. Common mechanisms for AI accelerators and SoCs include:

• Error-Correcting Code (ECC) Memory: Detects and corrects single-bit errors in SRAM.
• Lockstep Cores: Duplicate CPU cores execute identical instructions in parallel, with comparators checking for divergence.
• Built-In Self-Test (BIST): On-chip logic for testing memory and logic structures at startup or periodically.
• Watchdog Timers: Monitor system activity and trigger a reset if the software fails to respond.
• Parity Protection: For internal buses and registers. These mechanisms are quantitatively evaluated via probabilistic metric for random hardware failures (PMHF) analysis to meet ASIL targets.

Fail-Operational and Fail-Safe define a system's behavior upon a fault.

• Fail-Safe: The system transitions to a safe state (e.g., controlled shutdown) upon failure. This is sufficient for many ASIL B/C functions.
• Fail-Operational: The system must maintain its critical function despite a single point of failure. This is required for ASIL D functions like steering or braking in autonomous vehicles. Achieving this typically requires redundant architectures:
  • Homogeneous Redundancy: Duplicate identical channels (e.g., dual NPUs) with comparison.
  • Heterogeneous Redundancy: Diverse channels (e.g., a vision AI system cross-checked by a radar-based system) to avoid common-cause failures. Edge AI systems for autonomous driving are architected to be fail-operational, often using diverse sensor modalities and compute paths.