Functional Safety Island (FSI)
Jak działa
(1) FSI integruje 2+ rdzenie Lockstep z dedykowanym schedulerem, ECC memory, watchdogs i izolacją zasilania/zegara w obrębie głównego SoC. (2) Krytyczne dla bezpieczeństwa funkcjonalnego zadania (np. limity prędkości, e-stop, nadzór sensoryczny) są uruchamiane wyłącznie na FSI z safety-rated runtime (np. Halos OS, QNX, AUTOSAR Adaptive). (3) Komunikacja z aplikacjami na głównych rdzeniach odbywa się przez safety-aware shared memory lub bezpieczne kanały IPC z weryfikacją integralności. (4) Awaria głównego SoC nie wpływa na FSI — robot wchodzi w bezpieczny stan awaryjny (safe state) sterowany z FSI.
Rozwiązany problem
FSI rozwiązuje problem niezdolności klasycznych SoC application-grade (Linux + GPU + NPU) do osiągnięcia certyfikacji bezpieczeństwa funkcjonalnego na poziomie SIL 3 / ASIL D. Bez FSI lub osobnego safety MCU robot pracujący obok ludzi nie może uzyskać certyfikatu, więc wymaga fizycznych barier (workcells) ograniczających wdrożenia. FSI redukuje też koszty BOM eliminując zewnętrzny MCU safety.
Kluczowe mechanizmy
Mocne strony i ograniczenia
Komponenty
Dwa identyczne rdzenie procesora wykonujące dokładnie te same instrukcje równolegle, z porównywarką detekującą rozbieżność w wynikach (sygnatura awarii sprzętowej lub błędu pamięci). Standard dla ASIL D w motoryzacji (np. ARM Cortex-R52, Cortex-R82 w trybie split-lock).
Pamięć z korekcją błędów (Error Correcting Code, np. Hamming + SECDED) i parzystością na magistralach danych. Wykrywa i koryguje błędy pojedynczych bitów (single-event upset), detekuje błędy wielobitowe jako awarie.
Niezależny od głównego CPU timer wymagający okresowego kicku od oprogramowania. Brak kicka w wyznaczonym oknie czasowym oznacza zawieszenie software i wywołuje przejście do safe state lub reset systemu. Często windowed watchdog z dolnym i górnym oknem.
Oficjalna
Osobne domeny zasilania i zegara dla FSI vs główne rdzenie SoC. Awaria zasilania głównego (np. zwarcie GPU) nie wyłącza FSI — robot bezpiecznie się zatrzymuje. Klucz dla wymogu independence w IEC 61508.
Implementacja
Wymóg independence w IEC 61508 / ISO 26262 wymaga że awaria głównego SoC nie może propagować do FSI. Współdzielone zasilanie, magistrala lub zegar narusza tę zasadę i unieważnia certyfikację SIL 3 / ASIL D.
Zwykły Linux uruchomiony na FSI nie czyni systemu certyfikowanym SIL 3 — wymagany jest safety-rated runtime (QNX, VxWorks Cert, NVIDIA Halos OS) z dedykowaną walidacją toolchainu i konfiguracji.
FSI to budulec, nie kompletne rozwiązanie. Pełna certyfikacja wymaga też redundantnych certyfikowanych sensorów, safety-rated software stack, safe state machines, audytowanej dokumentacji i procesów rozwoju zgodnych z funkcjonalną kulturą safety (IEC 61508 Part 1).
Ewolucja
Pierwsza wersja IEC 61508 ustanawia framework SIL 1-4 dla systemów elektrycznych/elektronicznych. Choć nie wspomina FSI explicite, definiuje wymogi niezależności i fault detection, które staną się fundamentem dla FSI.
Infineon wprowadza rodzinę AURIX TC27x z TriCore Lockstep i zintegrowaną Safety Management Unit. Pierwszy szeroko stosowany SoC z FSI dedykowany dla motoryzacji w klasie ASIL D. Wzorzec adoptowany przez NXP S32 i TI TDA.
Druga edycja ISO 26262 wprowadza szczegółowe wymogi dla mixed-criticality SoC, w których FSI współistnieje z application cores. Definiuje SoTIF (Safety of the Intended Functionality), pożyczany później w robotyce.
ARM Cortex-R82 wprowadza 64-bitową architekturę z Split-Lock mode, łącząc wymagania safety z performance dla nowej generacji autonomous driving i robotyki przemysłowej.
NVIDIA IGX Thor (premiera 28.10.2025) integruje FSI z architekturą Blackwell, łącząc 5581 TFLOPS AI compute z certyfikowalnym fault-tolerant safety island. Pierwszy SoC AI-grade dedykowany robotyce z FSI klasy SIL 3.
Piąta generacja humanoida Digit od Agility Robotics (planowana na 4Q 2026) wykorzystuje FSI na NVIDIA IGX Thor uruchamiając NVIDIA Halos OS. Pierwsze komercyjne wdrożenie humanoida pracującego obok ludzi bez fizycznych barier opiera się na FSI jako fundament certyfikacji.
Wąskie gardło obliczeniowe
FSI nie jest projektowane jako wąskie gardło wydajnościowe — typowo 100-500 MHz dla rdzeni Lockstep ARM Cortex-R52 vs 2-3 GHz dla głównych application cores. Wyzwanie to nie ilość operacji per sekunda, lecz deterministyczna latencja worst-case (WCET) i certyfikowalność narzędzi deweloperskich. Toolchain (kompilator, scheduler, OS) wymaga osobnej certyfikacji TÜV/exida — koszt rozwoju przekracza ten dla zwykłych SoC o rząd wielkości.
Równoległość
FSI z założenia działa pojedynczo wątkowo (deterministycznie sekwencyjnie) na rdzeniach Lockstep. Wielowątkowość lub asynchroniczne operacje wprowadzają non-determinism, który jest sprzeczny z wymogami safety-critical execution. Możliwy jest model master-slave między FSI a application cores (FSI nadzoruje, AC liczą), ale nie współbieżność na samej FSI.
Wymagania sprzętowe
FSI z definicji jest częścią SoC. Klasyczne przykłady: Infineon AURIX, NXP S32, NVIDIA IGX Thor, Tesla FSD HW4, Mobileye EyeQ Ultra.
Wczesna alternatywa dla FSI — osobny chip TI Hercules, Infineon AURIX standalone. Wciąż używana w warstwowych systemach ASIL D + ISO 13849.
GPU/NPU są NIEZGODNE z wymogami functional safety bez FSI nadzorującego. Mogą realizować zadania AI, ale wymagają safety supervisor na FSI weryfikującego ich decyzje.