Functional Safety Island (FSI)
How it works
(1) FSI integrates 2+ Lockstep cores with a dedicated scheduler, ECC memory, watchdogs, and isolated power/clock domains within the main SoC. (2) Functional-safety critical tasks (e.g., speed limits, e-stop, sensor supervision) run exclusively on the FSI with a safety-rated runtime (e.g., Halos OS, QNX, AUTOSAR Adaptive). (3) Communication with applications on the main cores happens through safety-aware shared memory or secure IPC channels with integrity verification. (4) A main SoC failure does not affect the FSI โ the robot enters a safe state controlled from the FSI.
Problem solved
FSI solves the inability of classical application-grade SoCs (Linux + GPU + NPU) to achieve functional safety certification at SIL 3 / ASIL D levels. Without an FSI or a separate safety MCU, a robot operating alongside humans cannot be certified, forcing physical barriers (workcells) that restrict deployments. FSI also reduces BOM costs by eliminating an external safety MCU.
Key mechanisms
Strengths & limitations
Components
Two identical CPU cores executing exactly the same instructions in parallel, with a comparator detecting divergence in results (a signature of hardware failure or memory error). Standard for ASIL D in automotive (e.g., ARM Cortex-R52, Cortex-R82 in split-lock mode).
Error-Correcting Code memory (e.g., Hamming + SECDED) and parity on data buses. Detects and corrects single-bit errors (single-event upsets), and detects multi-bit errors as faults.
An independent timer requiring periodic kicks from software. Missing a kick within the time window indicates a software hang and triggers a safe state or system reset. Often a windowed watchdog with lower and upper time bounds.
Official
Separate power and clock domains for the FSI vs main SoC cores. A main power failure (e.g., GPU short) does not disable the FSI โ the robot safely stops. Key for the independence requirement in IEC 61508.
Implementation
The independence requirement in IEC 61508 / ISO 26262 mandates that a main SoC failure cannot propagate to the FSI. Shared power, bus, or clock violates this principle and invalidates SIL 3 / ASIL D certification.
A regular Linux running on the FSI does not make the system SIL 3-certified โ a safety-rated runtime is required (QNX, VxWorks Cert, NVIDIA Halos OS) with dedicated toolchain and configuration validation.
FSI is a building block, not a complete solution. Full certification also requires redundant certified sensors, a safety-rated software stack, safe state machines, audited documentation, and development processes per a functional safety culture (IEC 61508 Part 1).
Evolution
The first IEC 61508 edition establishes the SIL 1-4 framework for electrical/electronic systems. While not explicitly mentioning FSI, it defines independence and fault-detection requirements that will become the FSI foundation.
Infineon introduces the AURIX TC27x family with TriCore Lockstep and integrated Safety Management Unit. The first widely deployed SoC with FSI dedicated to automotive ASIL D. The pattern is adopted by NXP S32 and TI TDA.
The second ISO 26262 edition introduces detailed requirements for mixed-criticality SoCs where the FSI coexists with application cores. Defines SoTIF (Safety of the Intended Functionality), later borrowed in robotics.
ARM Cortex-R82 introduces 64-bit architecture with Split-Lock mode, combining safety requirements with performance for the next generation of autonomous driving and industrial robotics.
NVIDIA IGX Thor (launched October 28, 2025) integrates an FSI with the Blackwell architecture, combining 5,581 TFLOPS of AI compute with a certifiable fault-tolerant safety island. The first AI-grade SoC dedicated to robotics with an SIL 3-class FSI.
The fifth-generation Digit humanoid from Agility Robotics (targeted Q4 2026) uses the FSI on NVIDIA IGX Thor running NVIDIA Halos OS. The first commercial humanoid deployment operating alongside humans without physical barriers relies on FSI as the certification foundation.
Compute bottleneck
FSI is not designed as a performance bottleneck โ typically 100-500 MHz for ARM Cortex-R52 Lockstep cores vs 2-3 GHz for main application cores. The challenge is not operations per second, but deterministic worst-case execution time (WCET) and certifiability of the developer toolchain. The toolchain (compiler, scheduler, OS) requires separate TรV/exida certification โ development cost exceeds that of regular SoCs by an order of magnitude.
Parallelism
FSI is intentionally single-threaded (deterministically sequential) on Lockstep cores. Multithreading or asynchronous operations introduce non-determinism, contrary to safety-critical execution requirements. A master-slave model between FSI and application cores is possible (FSI supervises, ACs compute), but not concurrency within the FSI itself.
Hardware requirements
FSI is by definition part of a SoC. Classic examples: Infineon AURIX, NXP S32, NVIDIA IGX Thor, Tesla FSD HW4, Mobileye EyeQ Ultra.
Early alternative to FSI โ a separate TI Hercules or Infineon AURIX standalone chip. Still used in layered ASIL D + ISO 13849 systems.
GPU/NPU are INCOMPATIBLE with functional safety requirements without an FSI supervisor. They can perform AI tasks but require a safety supervisor on the FSI to verify their decisions.