Der Einsatz neuronaler Netze in sicherheitskritischen Automobil-, Industrie- und eingebetteten Systemen erfordert die Versöhnung zweier grundlegend verschiedener Ingenieurphilosophien: der probabilistischen, datengetriebenen Welt des maschinellen Lernens und der deterministischen, evidenzbasierten Welt der funktionalen Sicherheit. Dieser Leitfaden erläutert die Normen, die diese Umgebungen regeln — ISO 26262, SOTIF/ISO 21448, IEC 61508 und IEC 62443 — und wie sich ein ML-Einsatz so strukturieren lässt, dass ein Sicherheitsingenieur ihn akzeptieren kann.
Zuletzt geprüft: Mai 2026
Funktionale Sicherheit ist der Teil der Gesamtsicherheit eines Systems, der vom korrekten Betrieb elektrischer, elektronischer und programmierbar elektronischer Komponenten abhängt. Wird eine KI- oder ML-Komponente in einem sicherheitskritischen System eingesetzt — autonome Notbremsung, industrielle Notabschaltung, robotische Bewegungsplanung — verlangen die Normen der funktionalen Sicherheit den Nachweis, dass das System sicher ausfällt, sich innerhalb seiner definierten Betriebsbedingungen korrekt verhält und Hardware- und Softwarefehler toleriert. Die Herausforderung für das maschinelle Lernen besteht darin, dass diese Normen für deterministische Software konzipiert wurden und neuronale Netze im herkömmlichen Sinne nicht deterministisch sind.
Die Normen der funktionalen Sicherheit, die Automobil- und Industriesysteme regeln — ISO 26262, IEC 61508, IEC 62061 — wurden für deterministische Software entwickelt: Code, der Eingaben über eine definierte Logik verarbeitet und Ausgaben erzeugt, die formal spezifiziert, anhand von Strukturüberdeckungskriterien getestet und als korrekt innerhalb der Betriebsbedingungen des Systems verifiziert werden können.
Neuronale Netze passen nicht in dieses Modell. Sie werden trainiert — nicht programmiert — und ihr Verhalten entsteht aus Millionen gelernter Parameter statt aus expliziter Logik. Dieselbe Eingabe kann bei zweimaliger Präsentation je nach Gleitkommaverhalten der Hardware und Thread-Scheduling leicht unterschiedliche Ausgaben erzeugen. Ihre Fehlerarten sind statistisch, nicht deterministisch: Sie schneiden im Durchschnitt gut ab, können aber bei bestimmten, in den Trainingsdaten unterrepräsentierten Eingaben versagen. Und sie lassen sich nicht erschöpfend gegen eine formale Spezifikation verifizieren, weil keine formale Spezifikation existiert — die Spezifikation ist implizit in den Trainingsdaten enthalten.
Dies erzeugt eine grundlegende Spannung, die jeder Ingenieur lösen muss, der KI in einem sicherheitskritischen System einsetzt: Wie erstellt man einen Sicherheitsnachweis für eine Komponente, deren Verhalten im herkömmlichen Sinne weder formal spezifiziert noch verifiziert werden kann? Die Antwort — die nun aus Normungsgremien, Industriekonsortien und ersten Programmerfahrungen hervorgeht — kombiniert architektonische Muster (Sicherheitsmonitore, ODD-Definition, Rückfallpfade) und statistische Nachweise (große Validierungsdatensätze, Robustheitstests), die zusammen einen vertretbaren Sicherheitsnachweis bilden.
Die sechs Kernspannungen unten stellen die ingenieurtechnischen Herausforderungen dar, die jeder sicherheitskritische ML-Einsatz bewältigen muss.
Normen der funktionalen Sicherheit (ISO 26262, IEC 61508) setzen deterministisches Verhalten voraus: Bei gleichen Eingaben erzeugt eine Sicherheitsfunktion jedes Mal dieselben Ausgaben. Mit stochastischem Gradientenabstieg und Dropout trainierte neuronale Netze bieten diese Garantie nicht. Selbst identische Eingaben können je nach Hardware-Gleitkommaimplementierung und Thread-Scheduling leicht unterschiedliche Ausgaben erzeugen.
Sicherheitsnachweise erfordern Rückverfolgbarkeit — man muss erklären können, warum ein System eine Entscheidung trifft, und nachweisen, dass innerhalb der definierten Operational Design Domain (ODD) keine unsichere Entscheidung möglich ist. Tiefe neuronale Netze sind grundsätzlich intransparent. Erklärbarkeitsmethoden (SHAP, LIME, Attention-Maps) liefern Näherungen, keine Beweise.
Ein auf einer Verteilung von Trainingsdaten trainiertes Modell kann sich bei Eingaben außerhalb dieser Verteilung unerwartet verhalten — ein Problem, das als Verteilungsverschiebung (Distribution Shift) bekannt ist. Sicherheitsnormen verlangen, dass sich das System über seinen gesamten definierten Satz von Betriebsbedingungen korrekt verhält. Verteilungsverschiebung steht grundlegend im Widerspruch zu dieser Anforderung.
Herkömmliche sicherheitskritische Software wird mithilfe von Strukturüberdeckungsmetriken (MC/DC für ASIL D) gegen formale Spezifikationen verifiziert. Neuronale Netze lassen sich so nicht verifizieren — die „Spezifikation“ ist implizit in den Trainingsdaten enthalten. Statistische Validierung an großen, zurückgehaltenen Datensätzen ersetzt die formale Verifikation, doch die Sicherheitsbehörden sind sich uneinig, was als ausreichender Nachweis gilt.
Sicherheitszertifizierte Software unterliegt einem strengen Änderungsmanagement: Jede Modifikation erfordert eine erneute Bewertung. Neuronale Netzmodelle können mit zunehmenden Daten feinabgestimmt, aktualisiert oder ersetzt werden. Jede Aktualisierung kann den bestehenden Sicherheitsnachweis ungültig machen und eine erneute Validierung erfordern — was eine Spannung zwischen betrieblicher Verbesserung und Aufrechterhaltung der Zertifizierung erzeugt.
Edge-Sicherheitssysteme haben enge Ende-zu-Ende-Latenzbudgets — oft unter 10ms für Echtzeit-Regelkreise. Die Inferenz neuronaler Netze auf beschränkter Hardware (MCUs, FPGAs, kleine SoCs) muss in dieses Budget passen und dabei Reserve für den Rest des Steuerpfads lassen. Quantisierung und Pruning helfen, bringen aber eigene Fehlerarten mit sich.
ISO 26262 ist die Norm für funktionale Sicherheit im Automobil, anwendbar auf Straßenfahrzeuge mit einer zulässigen Gesamtmasse (MGVM) bis 3.500 kg. Sie definiert das Rahmenwerk Automotive Safety Integrity Level (ASIL) — vier Stufen (A bis D), die die Strenge des für eine bestimmte Sicherheitsfunktion erforderlichen Sicherheitsengineering-Prozesses festlegen. ASIL D ist am strengsten; ASIL A am geringsten.
Die ASIL-Stufe einer Funktion wird durch eine Gefährdungsanalyse und Risikobewertung (HARA) bestimmt, die drei Faktoren berücksichtigt: die Schwere (S) des möglichen Schadens, die Exposition (E) gegenüber der Gefährdungssituation und die Beherrschbarkeit (C) durch Fahrer oder Bediener. Die Kombination aus S, E und C bestimmt die ASIL-Zuordnung.
Das V-model ist das Rahmenwerk des Entwicklungsprozesses: Anforderungen werden auf dem linken Ast des V spezifiziert und zerlegt; die Implementierung befindet sich unten; Integration, Verifikation und Validierungstests befinden sich auf dem rechten Ast und spiegeln jedes Artefakt des linken Astes wider. Jede Sicherheitsanforderung muss vom Sicherheitsziel auf Fahrzeugebene über System-, Hardware- und Softwareebene rückverfolgt und auf der entsprechenden Ebene des rechten Astes verifiziert werden.
SOTIF (ISO 21448:2022) erweitert ISO 26262 um Gefährdungen, die aus den Grenzen der bestimmungsgemäßen Funktion selbst entstehen — nicht aus Ausfällen, sondern aus Situationen, in denen sich das System genau wie ausgelegt verhält, die Auslegung aber für die tatsächlichen Betriebsbedingungen unzureichend ist. Das ist für ML unmittelbar relevant: Ein Wahrnehmungsmodell, das einen Fußgänger bei ungewöhnlicher Beleuchtung falsch klassifiziert, „versagt“ nicht im herkömmlichen Sinne — es arbeitet wie trainiert, aber das Training war für diese Bedingung unzureichend. Die SOTIF-Analyse erfordert, diese auslösenden Bedingungen zu identifizieren und systematisch zu testen.
Niedrigste Anforderung an die funktionale Sicherheit. Anwendbar auf Systeme, bei denen die Gefährdungsschwere gering oder die Exposition selten ist.
Implikation für den ML-Einsatz
Statistische Validierung an moderaten Testmengen kann akzeptiert werden. Grundlegende Laufzeitmonitore genügen.
Moderate Sicherheitsanforderung. Häufig bei Fahrerassistenzfunktionen mit moderatem Gefährdungspotenzial angewandt.
Implikation für den ML-Einsatz
Erfordert eine dokumentierte ODD, Leistungskennzahlen an den ODD-Grenzfällen und Überwachung auf Eingaben außerhalb der Verteilung.
Hohe Sicherheitsanforderung. Gilt für Systeme, bei denen Ausfälle ohne externe Abschwächung zu schweren Verletzungen führen könnten.
Implikation für den ML-Einsatz
Umfassender Sicherheitsnachweis erforderlich. Runtime-Assurance-Monitore, expliziter Rückfallpfad und SOTIF-Analyse zwingend. Eine Drittprüfung wird in der Regel erwartet.
Höchste Stufe der funktionalen Sicherheit im Automobil. Gilt für Systeme, bei denen ein Ausfall zu lebensbedrohlichen Gefährdungen führen kann.
Implikation für den ML-Einsatz
Komponenten neuronaler Netze werden in der Regel auf Wahrnehmungs-/Beratungsrollen beschränkt, niemals im finalen sicherheitskritischen Steuerpfad. Redundante deterministische Monitore sind erforderlich. Aktueller Branchenkonsens: Reine ML-Komponenten sind als alleinige Sicherheitsfunktion nicht zu ASIL D zertifizierbar.
IEC 61508 ist die generische Norm für funktionale Sicherheit elektrischer, elektronischer und programmierbar elektronischer (E/E/PE) sicherheitsbezogener Systeme. Sie ist die Mutternorm, von der sektorspezifische Normen abgeleitet sind: IEC 62061 (Maschinen), EN 50128 (Bahn), IEC 61511 (Prozessindustrie) und IEC 61513 (Kerntechnik). Das Rahmenwerk Safety Integrity Level (SIL) ist das Pendant von IEC 61508 zum ASIL — vier Stufen (SIL 1–4), definiert durch die erforderliche Ausfallwahrscheinlichkeit bei Anforderung (PFD) für eine Sicherheitsfunktion.
Bei KI-Einsätzen in Industriesystemen lautet die Schlüsselfrage: Welche SIL-Stufe wird der Sicherheitsfunktion zugewiesen, zu der die KI-Komponente beiträgt? Dies bestimmt die Strenge der erforderlichen Validierungsnachweise und die Beschränkungen dafür, wie die KI-Komponente innerhalb dieser Funktion eingesetzt werden kann.
Das allgemeine Prinzip ist dasselbe wie in ISO 26262: Komponenten neuronaler Netze können zu Funktionen niedrigerer SIL als beratende oder auslösende Elemente beitragen, doch die Sicherheitsfunktionen höchster Integrität erfordern deterministische Implementierungen oder deterministische Sicherheitsmonitore, die die Ausgaben der ML-Komponente überstimmen.
Niedrigstes Sicherheits-Integritätslevel. Gilt für Funktionen, bei denen ein Einzelfehler ohne mehrere beitragende Faktoren unwahrscheinlich ein gefährliches Ereignis verursacht.
ML-Hinweis
ML-basierte beratende Systeme, die in eine SIL-1-Sicherheitsfunktion einfließen, müssen statistische Zuverlässigkeit innerhalb der definierten Betriebsbedingungen nachweisen.
Mittlere Stufe. Üblich bei sicherheitstechnischen Funktionen der Prozessindustrie: Notabschaltungen, Auslösung von Druckentlastung, Brand- und Gaserkennung.
ML-Hinweis
ML-Anomalieerkennung, die eine SIL-2-Abschaltung speist, muss als auslösendes Element in der Sicherheitsschleife behandelt werden — ihre Wahrscheinlichkeit für eine ungewollte Auslösung (gefährlicher Ausfall) muss nachgewiesen werden.
Hohes Integritätslevel. Zu finden in Notfallsystemen von Chemieanlagen, in der Eisenbahnsignaltechnik und in nuklearen Instrumentierungs-Unterstützungsfunktionen.
ML-Hinweis
Komponenten neuronaler Netze werden derzeit von den meisten Zertifizierungsstellen nicht als SIL-3-Implementierungen von Sicherheitsfunktionen akzeptiert. ML kann Diagnosen oder nicht sicherheitskritische Datenpfade neben einer bewährten deterministischen Sicherheitsschicht unterstützen.
Höchste Stufe von IEC 61508. Reaktorschutzsysteme, sicherheitsrelevante Bahnfunktionen. In der Praxis äußerst selten.
ML-Hinweis
Derzeit wird keine ML-Komponente auf SIL 4 als Teil der Sicherheitsfunktion selbst akzeptiert.
IEC 62443 ist die internationale Normenreihe für die Cybersicherheit industrieller Automatisierungs- und Steuerungssysteme (IACS). Sie definiert ein Zonen-und-Conduit-Modell: Das OT-Netz wird nach der Kritikalität der enthaltenen Anlagen in Zonen unterteilt, und die Kommunikation zwischen Zonen muss durch definierte Conduits mit angemessenen Sicherheitskontrollen verlaufen.
Bei KI-Einsätzen lautet die IEC-62443-Frage: In welcher Zone sitzt der KI-Inferenzserver, und welche Sicherheitskontrollen regeln seine Kommunikation mit dem Steuerungsnetz? Einen KI-Inferenzserver zu platzieren, der ohne angemessene Conduit-Kontrollen direkt mit SPS (PLC) oder Feldgeräten kommuniziert, verletzt das Zonenmodell und schafft ein Cybersicherheitsrisiko — ein Angreifer, der den KI-Server kompromittiert, erlangt einen Weg in die Steuerungszone.
Darüber hinaus sind KI-Systeme eine neuartige Angriffsfläche: Adversariale Eingaben — sorgfältig gestaltete Eingaben, die das Modell zu falschen Ausgaben veranlassen — können sicherheitsrelevante Ausfälle verursachen. Die IEC-62443-Cybersicherheitsanalyse für KI-Systeme sollte neben herkömmlichen IT-Sicherheitskontrollen auch Tests der adversarialen Robustheit umfassen.
Geschäfts-IT-Netze — ERP, Unternehmens-E-Mail, Cloud-Anbindung. Hier eingesetzte KI-Modelle haben die breiteste Angriffsfläche und bei Kompromittierung die geringste OT-Auswirkung, aber auch die geringste Datenaktualität und die höchste Latenz.
Leitlinie zur KI-Platzierung
Geeignet für Reporting-KI, Dokumentzusammenfassung, Geschäftsanalytik. NICHT geeignet für Echtzeitsteuerung oder sicherheitsnahe Inferenz.
Leitsteuerungssysteme, Historian-Datenbanken, SCADA-Server. Hier eingesetzte KI-Inferenz kann über OPC-UA oder OSIsoft PI auf Echtzeit-Prozessdaten zugreifen, ohne direkten Zugriff auf Feldgeräte.
Leitlinie zur KI-Platzierung
Geeignet für vorausschauende Wartung, beratende Prozessoptimierung, Anomalieerkennung. Erfordert IEC-62443-3-3-Conduit-Kontrollen zur Zone 2.
SPS (PLC), DCS, Feldcontroller. Sicherheitskritische Regelkreise laufen hier. KI-Inferenz in Zone 2 ist ungewöhnlich und erfordert eine Härtung auf SL (Security Level) 2: Authentifizierung, verschlüsselte Kommunikation, Audit-Protokollierung.
Leitlinie zur KI-Platzierung
Runtime-Assurance-Monitore und Detektoren für Eingaben außerhalb der Verteilung können hier betrieben werden, sofern die Hardwarebeschränkungen es zulassen. Direkte Verantwortung für eine Sicherheitsfunktion erfordert eine Analyse der funktionalen Sicherheit (ISO 26262 / IEC 61508).
Sensoren, Aktoren, intelligente Instrumente. Äußerst beschränkte Geräte — in der Regel MCUs oder einfache RTUs. KI-Inferenz ist hier auf TinyML-Modelle (INT8-quantisiert, unter 1MB) auf dedizierten Inferenz-Coprozessoren begrenzt.
Leitlinie zur KI-Platzierung
Anomalieerkennung auf rohen Sensordatenströmen. Machbar mit Hardware der MCU-Klasse auf SL 1. Verantwortung für eine Sicherheitsfunktion auf dieser Ebene erfordert eine formale IEC-61508-Bewertung.
Hyperion berät zur KI- und Edge-Architekturebene: wo ML in die Sicherheitsarchitektur passt, wie Sicherheitsmonitor und Rückfallpfad zu strukturieren sind, welche Edge-Toolchain für Ihre Hardware geeignet ist und wie das Sicherheitsnachweispaket vorzubereiten ist. Wir sind keine Zertifizierungsstelle — aber wir helfen Ihnen, eine Architektur aufzubauen, die eine Zertifizierungsstelle akzeptieren kann.
Ein Sicherheitsnachweis ist eine strukturierte, durch Evidenz gestützte Argumentation, dass ein System für eine gegebene Anwendung in einer gegebenen Umgebung hinreichend sicher ist. Für ML-Komponenten muss der Sicherheitsnachweis die spezifischen Fehlerarten neuronaler Netze — Verteilungsverschiebung, Intransparenz, Nichtdeterminismus — mit architektonischen Mustern und statistischen Nachweisen statt mit formaler Verifikation adressieren. Die folgenden sechs Elemente bilden den Kern eines vertretbaren Sicherheitsnachweises für eine ML-Komponente am Edge.
Definieren Sie die genauen Bedingungen, unter denen die ML-Komponente gültig ist: Umgebungsbedingungen, Eingabedatenbereiche, Sensor-Betriebsbereiche, Geschwindigkeits-/Lasthüllkurven. Die ODD ist der Vertrag zwischen dem ML-System und dem Sicherheitsnachweis. Jede Eingabe außerhalb der ODD muss einen sicheren Zustand auslösen — das ML-System darf bei Eingaben außerhalb des Bereichs nicht stillschweigend unsichere Ausgaben erzeugen.
Ein paralleler deterministischer Monitor — in herkömmlicher Software oder Hardware implementiert — überwacht die Ausgaben der ML-Komponente und blockiert oder überstimmt jede Ausgabe, die die Sicherheitsbeschränkung verletzt. Dies ist das Standardmuster für den Einsatz von ML in sicherheitskritischen Systemen: Die ML-Komponente ist beratend, der deterministische Monitor ist maßgeblich. Der Monitor selbst muss auf das erforderliche ASIL/SIL-Level zertifiziert sein.
Ein OOD-Detektor — in der Regel basierend auf dem Rekonstruktionsfehler der Eingabe, Ensemble-Uneinigkeit oder Mahalanobis-Distanz — kennzeichnet Eingaben, die außerhalb der Trainingsverteilung liegen. Bei OOD-Erkennung wechselt das System in den Rückfallpfad, statt weiter zu inferieren. OOD-Detektoren müssen hinsichtlich ihrer eigenen Falsch-Negativ-Rate im Sicherheitsnachweis validiert werden.
Jeder sicherheitskritische ML-Einsatz muss einen definierten Rückfall besitzen: einen sicheren Zustand, in den das System wechselt, wenn die ML-Komponente ausfällt, vom Sicherheitsmonitor überstimmt wird oder eine OOD-Eingabe erkennt. Der Übergang in den sicheren Zustand muss selbst ASIL/SIL-bewertet sein. Übliche Rückfallmuster: Begrenzungs-/konservativer Modus (geringe Geschwindigkeit, erhöhte Sicherheitsmargen), Übernahmeaufforderung an Fahrer/Bediener, kontrolliertes Anhalten.
Da formale Verifikation (MC/DC-Überdeckung) nicht auf neuronale Netze angewandt werden kann, tritt an ihre Stelle die statistische Validierung an einem großen, unabhängigen, repräsentativen Testsatz. Größe und Zusammensetzung des Testsatzes, die Leistungskennzahlen und die Konfidenzintervalle müssen dokumentiert und von der Sicherheitsbehörde akzeptiert werden. ISO PAS 21448 (SOTIF) und die kommende ISO 8800 liefern entstehende Leitlinien.
Die gesamte Sicherheitsfunktion wird in Teilelemente zerlegt, denen jeweils ein ASIL/SIL-Level zugewiesen wird. Der ML-Komponente wird in der Regel ein niedrigeres ASIL/SIL-Level zugewiesen, wobei der deterministische Sicherheitsmonitor die Differenz ausgleicht. Diese ASIL-Dekomposition muss formal dokumentiert und geprüft werden. Das Gesamtsystem muss die ASIL/SIL-Anforderung der obersten Ebene erfüllen.
Hinweis zu Normen: Die Methodik zur Erstellung von Sicherheitsnachweisen für ML-Komponenten entwickelt sich aktiv weiter. ISO/TR 4804, UL 4600 und die in Entwicklung befindliche ISO 8800 (KI und Straßenfahrzeuge) liefern die aktuellsten Leitlinien. Zertifizierungsstellen und Automobil-OEMs legen ihre Akzeptanzpositionen zu bestimmten Techniken noch fest — was als ausreichender statistischer Nachweis gilt, welche OOD-Erkennungsansätze akzeptabel sind und wie die ASIL-Dekomposition auf ML-konventionelle Softwarepaare anzuwenden ist. Stimmen Sie sich stets frühzeitig mit Ihrer Zielzertifizierungsstelle über das Nachweispaket ab.
Sicherheitskritische Edge-Systeme erlegen Beschränkungen auf, die die meisten Allzweck-KI-Einsatzmuster ausschließen. Im Folgenden die ingenieurtechnischen Beschränkungen, die jeden Edge-KI-Einsatz in einem sicherheitsrelevanten Automobil- oder Industriekontext prägen, sowie die Toolchain-Entscheidungen, die ihnen begegnen.
Automobile Sicherheitssysteme erfordern in der Regel eine Ende-zu-Ende-Latenz unter 10–50ms. Industrielle Regelkreise können enger sein: 1–10ms für harte Echtzeitfunktionen. Die Edge-KI-Inferenz muss bei der Worst-Case-Latenz (99. Perzentil), nicht bei der durchschnittlichen Latenz, gegen die verfügbare Zeitmarge profiliert werden.
Sicherheitskritische Edge-Systeme dürfen für die Echtzeit-Inferenz nicht von Cloud-Konnektivität abhängen. Die Cloud kann für Modelltraining, Überwachung und Orchestrierung von Over-the-Air-Updates genutzt werden, doch der Inferenzpfad muss vollständig offline funktionieren. Netzpartitionen sind eine Auslegungsbedingung, kein Randfall.
Automobile Steuergeräte (ECUs) und industrielle SPS/Edge-Controller laufen in der Regel auf ARM-Cortex-M/R- oder RISC-V-Kernen mit 256KB–4MB RAM. Vollständige Deep-Learning-Modelle passen nicht hinein. Techniken: INT8-Quantisierung (TensorFlow Lite Micro, ONNX Runtime für MCUs), strukturiertes Pruning, Wissensdestillation zu kleineren Architekturen (MobileNet, EfficientNet-Lite, maßgeschneiderte CNNs).
Der dominierende Produktiv-Einsatzpfad für Edge-KI in beschränkten Umgebungen: in PyTorch trainieren → nach ONNX exportieren → mit TensorRT (NVIDIA Jetson / Drive) oder ONNX Runtime mit XNNPACK/NNAPI-Delegate (ARM-SoC) optimieren. ONNX Runtime unterstützt auch den MCU-Einsatz über ONNX Runtime for Microcontrollers. Diese Toolchains haben ein dokumentiertes Verhalten, das im Sicherheitsnachweis validiert werden muss.
Sicherheitssysteme verlangen, dass dieselbe Eingabe stets dieselbe Ausgabe erzeugt. Dies erfordert: Festkommaarithmetik (INT8 statt FP32), Deaktivierung von Laufzeitoptimierungen, die zwischen Durchläufen variieren, feste Thread-Affinität, keine dynamische Speicherzuweisung während der Inferenz. Bitgenauen Determinismus über alle Einsätze hinweg zu erreichen, erfordert eine sorgfältige Toolchain-Konfiguration und Hardwarevalidierung.
Edge-Sicherheitscontroller haben feste Speicherhüllen — oft nicht mehr als 4–16MB Flash und 1–4MB RAM, die über die gesamte Anwendung geteilt werden. Energiebudgets bei batteriebetriebenen oder thermisch beschränkten Geräten begrenzen die Inferenzfrequenz. Modellquantisierung und geplante (statt kontinuierliche) Inferenz sind übliche Lösungen.
Physical-AI-Deployment
Edge-KI-Architektur und eingebettete Inferenz-Toolchain für sicherheitsnahe Systeme
Domain-Expert-LLM-Lab
Modelltraining, Quantisierung und Validierungspipelines für beschränkte Hardware
Souveränes LLM (öffentlicher Sektor)
Air-Gapped-KI für kritische Infrastruktur und Verschlusssachen-Umgebungen
Das Folgende ist eine sachliche Darstellung des Hintergrunds von Hyperion in Bezug auf Edge-KI in sicherheitskritischen Systemen. Dies sind verifizierte Fakten, keine Marketingaussagen.
Offenlegung des Leistungsumfangs: Hyperion ist eine Beratung für KI- und Edge-Architektur. Wir beraten zur KI-/Edge-Ebene — Architektur, Toolchain-Auswahl, Entwurf des Sicherheitsmonitors, ODD-Definition, Struktur des Nachweispakets. Wir sind keine Zertifizierungsstelle, keine benannte Stelle und kein akkreditierter Sicherheitsgutachter. Wir stellen keine ASIL- oder SIL-Zertifizierungen aus. Formale Zertifizierungsarbeit erfordert einen akkreditierten Dritten.
Gründer Mohammed Cherifi verbrachte 17+ Jahre in der Automobil- und Embedded-Systems-Entwicklung, unter anderem bei Renault-Nissan-Mitsubishi Alliance, Cisco und ABB. Dieser Hintergrund umfasst direkte Berührung mit Prozessen der funktionalen Sicherheit in der Fahrzeugsoftwareentwicklung, eingebetteten Steuerungssystemen und den betrieblichen Beschränkungen sicherheitskritischer Umgebungen. Hyperion bringt diese Erfahrung in die KI-/Edge-Ebene ein — nicht als Zertifizierungsstelle, sondern als Ingenieurteam, das die Umgebung versteht.
Hyperions Flaggschiff-Venture Auralink ist eine am Edge eingesetzte Agentenplattform, aufgebaut auf 400+ Microservices mit etwa 20 KI-Agenten. Die Architektur von Auralink demonstriert die ingenieurtechnischen Muster, die für KI-Inferenz auf beschränkter Edge-Hardware erforderlich sind — Inferenzpfade mit geringer Latenz, deterministische Steuerungsgrenzen und die Trennung zwischen der beratenden KI-Ebene und der maßgeblichen Steuerungsebene. Dies ist ein übertragbarer Nachweis der architektonischen Disziplin, die für sicherheitsnahe Edge-KI erforderlich ist, und keine Sicherheitszertifizierung.
Die physical-ai-deployment-Leistung von Hyperion umfasst Edge-KI-Architektur, die Auswahl der eingebetteten Inferenz-Toolchain und die Integrationsebene zwischen KI-Inferenz und OT-/Embedded-Steuerungssystemen. Unsere Rolle ist die KI- und Edge-Architekturebene. Wir beraten dazu, wo ML-Komponenten in eine Sicherheitsarchitektur passen, wie Sicherheitsmonitor und Rückfallpfad zu strukturieren sind und welche Toolchains für die Hardware geeignet sind. Wir sind keine Zertifizierungsstelle und stellen keine ASIL/SIL-Zertifizierungen aus — diese Arbeit erfordert eine benannte Stelle.
Ein auf arXiv veröffentlichter Preprint behandelt autonome, am Edge eingesetzte KI-Agenten für physische Infrastruktur. Dies ist eine akademiknahe Arbeit — ein Preprint, keine in einer begutachteten Fachzeitschrift erschienene Veröffentlichung — doch sie spiegelt die architektonische Tiefe wider, die Hyperion bei Edge-KI-Einsätzen in physischen Systemen anwendet.
Mohammed Cherifi trägt das Prädikat KI-Botschafter aus dem Programm Osez l'IA der französischen Regierung und wurde von FranceNum anerkannt. Dies spiegelt das Engagement in der KI-Politik und den regulatorischen Herausforderungen des KI-Einsatzes in regulierten industriellen und automobilen Umgebungen wider.
Nicht als alleinige Sicherheitsfunktion — nicht mit der aktuellen Methodik und den Akzeptanzpositionen der meisten Zertifizierungsstellen. Der Standardansatz besteht darin, die ML-Komponente auf einem niedrigeren ASIL/SIL-Level (z. B. ASIL B oder QM) einzusetzen, wobei ein auf das höhere Level zertifizierter deterministischer Sicherheitsmonitor die Differenz durch ASIL-Dekomposition ausgleicht. Das Gesamtsystem kann dann ASIL D erfüllen, doch die ML-Komponente selbst trägt diese Bezeichnung nicht. Diese Position spiegelt die aktuellen Leitlinien von ISO 26262-6:2018 und IEC TR 63069:2019 wider — sie wird sich weiterentwickeln, sobald die Normungsgremien ML-spezifische Leitlinien entwickeln (ISO/TR 4804, ISO 8800).
SOTIF (Safety of the Intended Function), veröffentlicht als ISO 21448:2022, behandelt Gefährdungen, die nicht aus Systemausfällen, sondern aus den Grenzen der bestimmungsgemäßen Funktion selbst entstehen — Wahrnehmungslücken, unerwartete Umgebungsbedingungen und Verhalten an ODD-Grenzen. ISO 26262 deckt Ausfälle des Systems gegenüber seiner Spezifikation ab. SOTIF deckt Unzulänglichkeiten der Spezifikation selbst ab. Für ADAS- und autonome Funktionen gelten beide Normen: Sie müssen sowohl nachweisen, dass das System sicher ausfällt (ISO 26262), als auch dass sein bestimmungsgemäßes Verhalten über die gesamte ODD sicher ist (SOTIF/ISO 21448).
Ein Sicherheitsmonitor ist eine deterministische, unabhängig verifizierte Software- oder Hardwarekomponente, die parallel zur ML-Komponente läuft. Er prüft die ML-Ausgabe gegen eine Menge formaler Sicherheitsbeschränkungen — physikalische Grenzen, Änderungsraten-Schranken, Konsistenz mit Sensordaten — und blockiert oder überstimmt jede Ausgabe, die diese Beschränkungen verletzt. Der Sicherheitsmonitor wird unabhängig vom ML-Modell auf das erforderliche ASIL/SIL-Level zertifiziert. Diese Trennung ist das zentrale architektonische Muster für den Einsatz von ML in sicherheitskritischen Systemen: Die ML-Komponente ist beratend, der Monitor ist maßgeblich.
Die ODD definiert die spezifischen Bedingungen, unter denen das ML-System gültig ist: Umgebungsparameter (Temperatur, Beleuchtung, Wetter), Eigenschaften der Eingabedaten (Sensorbereiche, Datenformate, Signalqualität), Betriebszustände des Fahrzeugs oder der Maschine sowie geografische oder anwendungsspezifische Beschränkungen. Jede Eingabe, die außerhalb der ODD liegt, sollte nicht von der ML-Komponente verarbeitet werden — das System muss in einen Rückfallzustand wechseln. Das Definieren, Validieren und Überwachen der ODD-Grenze ist eine der wichtigsten ingenieurtechnischen Aufgaben in einem sicherheitskritischen ML-Einsatz.
IEC 62443 definiert ein Zonen-und-Conduit-Modell für die industrielle Cybersicherheit. KI-Inferenzserver müssen, wie jedes IT-Asset, in die richtige Zone platziert werden (in der Regel Zone 3 — Leitebene), und sämtliche Kommunikation mit Zone 2 (Steuerung) muss durch ein Conduit mit definierten Sicherheitskontrollen verlaufen: Authentifizierung, Verschlüsselung, Prüfung der Nachrichtenintegrität. Einen KI-Inferenzserver einzusetzen, der ohne Conduit-Kontrollen direkt mit SPS (PLC) oder Feldgeräten kommuniziert, verletzt das Zonenmodell. Der KI-Server selbst muss die Anforderungen des Sicherheitslevels (SL) seiner Zone erfüllen, einschließlich Patch-Management, Authentifizierung und Audit-Protokollierung.
Es gibt keine einzelne Liste akzeptierter Konfigurationen — es hängt vom Ziel-ASIL/SIL-Level, der Zertifizierungsstelle und dem konkreten Anwendungsfall ab. Allgemein: Mit TensorRT optimierte Modelle auf NVIDIA-Drive/Jetson-Plattformen werden in ADAS-Programmen bis ASIL B weithin eingesetzt, mit Runtime-Assurance-Monitoren. ONNX Runtime auf ARM-SoCs wird in industriellen Anwendungen auf SIL 1–2 eingesetzt. Für höhere Integritätslevel kann eine formale Qualifizierung der Inferenz-Laufzeitumgebung selbst (Werkzeugqualifizierung nach ISO 26262-8) erforderlich sein. Hyperion berät zur Toolchain-Auswahl und Qualifizierungsstrategie — die formale Qualifizierungsarbeit erfordert die Beteiligung des Toolchain-Anbieters.
Nein. Hyperion ist eine Beratung für KI- und Edge-Architektur. Wir beraten dazu, wo ML-Komponenten in Sicherheitsarchitekturen passen, wie Sicherheitsmonitore und Rückfallpfade zu strukturieren sind, welche Edge-Toolchains für beschränkte Hardware geeignet sind und wie Einsätze zu gestalten sind, die mit den Anforderungen der funktionalen Sicherheit und von IEC 62443 vereinbar sind. Die eigentlichen ASIL/SIL-Zertifizierungsbewertungen — die Konformitätsbewertungsarbeit, die ein Zertifikat hervorbringt — müssen von einem akkreditierten Drittgutachter oder einer benannten Stelle durchgeführt werden. Hyperion kann Sie auf diese Bewertung vorbereiten und die Architektur so gestalten, dass sie praktikabel wird, doch wir stellen keine Zertifizierungen aus.
Die funktionale Sicherheit (ISO 26262, IEC 61508) fragt: Fällt das System sicher aus? Sie konzentriert sich auf Hardware- und Software-Fehlerarten, Fehlertoleranz und die Integrität von Sicherheitsfunktionen beim Ausfall von Komponenten. IEC 62443 fragt: Ist das System vor vorsätzlichen Angriffen geschützt? Sie konzentriert sich auf Cybersicherheitskontrollen — Authentifizierung, Verschlüsselung, Netzsegmentierung, Schwachstellenmanagement. Beide sind für industrielle KI-Systeme erforderlich: Ein System kann funktional sicher sein (es fällt anmutig aus), aber cybersicherheitstechnisch verwundbar (es kann angegriffen und zum Versagen gebracht werden). Speziell für KI-Systeme sind adversariale Angriffe ein Überschneidungspunkt — eine bewusst adversariale Eingabe kann unsicheres ML-Verhalten verursachen, das eine Bewertung der funktionalen Sicherheit allein nicht zutage fördern würde.
ISO 26262:2018 (2018). "Road vehicles — Functional safety (Parts 1–12)."
Kontext: Die primäre Norm für funktionale Sicherheit im Automobil. Teil 6 deckt Anforderungen an die Softwareentwicklung ab, einschließlich ASIL-spezifischer Strukturüberdeckungsmetriken. Teil 10 enthält Leitlinien zu KI-/ML-Komponenten (zum Zeitpunkt der Veröffentlichung nicht normativ, in nachfolgenden Ausgaben weiterentwickelt).
ISO 21448:2022 (2022). "Road vehicles — Safety of the intended functionality (SOTIF)."
Kontext: Behandelt Gefährdungen durch funktionale Unzulänglichkeiten in der Spezifikation oder Leistung der bestimmungsgemäßen Funktionalität, einschließlich Sensorgrenzen und ODD-Grenzverhalten in ADAS- und autonomen Fahrsystemen.
ISO/TR 4804:2020 (2020). "Road vehicles — Safety and cybersecurity for automated driving systems — Design, verification and validation."
Kontext: Technischer Bericht mit Leitlinien zur Kombination von Analyse der funktionalen Sicherheit und Cybersicherheit für das automatisierte Fahren. Deckt SOTIF, ISO 26262 und Querverweise auf SAE J3061 ab.
IEC 61508:2010 (2010). "Functional safety of electrical/electronic/programmable electronic safety-related systems (Parts 1–7)."
Kontext: Die generische internationale Norm für die funktionale Sicherheit von E/E/PE-Systemen. Definiert SIL 1–4, die Ausfallwahrscheinlichkeit bei Anforderung (PFD) und Anforderungen an Softwareentwicklung und -validierung.
IEC 62443 Series (2018–2024). "Industrial automation and control systems — Security."
Kontext: Mehrteilige Norm zur Cybersicherheit für die Betriebstechnik. IEC 62443-3-3 definiert Sicherheitslevel (SL) und das Zonen-/Conduit-Modell. IEC 62443-4-2 deckt Sicherheitsanforderungen an Komponenten ab, die auf KI-Inferenzserver in OT-Netzen anwendbar sind.
IEC TR 63069:2019 (2019). "Industrial-process measurement, control and automation — Framework for functional safety and security."
Kontext: Technischer Bericht zur Beziehung zwischen funktionaler Sicherheit (IEC 61508) und Cybersicherheit (IEC 62443). Unmittelbar relevant für KI-Einsätze, die beide Domänen umspannen.
UL 4600:2020 (2020). "Standard for Safety for the Evaluation of Autonomous Products."
Kontext: Erste umfassende Norm, die sich spezifisch mit ML-basierten autonomen Systemen befasst. Deckt den Aufbau des Sicherheitsnachweises, die ODD-Definition, die betriebliche Überwachung und die Runtime Assurance für ML-Komponenten ab. In nordamerikanischen Automobilprogrammen weithin referenziert.
ISO/IEC TR 24029-2:2023 (2023). "Artificial Intelligence — Assessment of the robustness of neural networks — Part 2: Methodology for use in formal methods."
Kontext: Liefert Leitlinien zu Robustheitstest-Methodiken für neuronale Netze, einschließlich adversarialer Robustheit — relevant sowohl für die funktionale Sicherheit als auch für die IEC-62443-Cybersicherheitsanalyse.
Sicherheitskritische ML-Einsätze erfordern mehr als gute Modellleistung — sie verlangen eine vertretbare Architektur, die richtige Toolchain für die Hardwarebeschränkungen und einen dokumentierten Sicherheitsnachweis, den eine Zertifizierungsstelle akzeptieren kann. Hyperion bringt 17+ Jahre Erfahrung in der Automobil- und Embedded-Systems-Entwicklung in die KI-/Edge-Ebene ein. Wir beraten zu Architektur und Nachweisstrategie; die formale Zertifizierung verbleibt bei der zuständigen akkreditierten Stelle. Beginnen Sie mit einem fokussierten Architektur-Review.
Gründer & Leiter KI-Strategie
Mohammed Cherifi ist der Gründer von Hyperion Consulting, mit 17+ Jahren in der Automobil- und Embedded-Systems-Entwicklung. Er hat bei Renault-Nissan-Mitsubishi Alliance, Cisco und ABB gearbeitet — Umgebungen, in denen Prozesse der funktionalen Sicherheit die Softwareentwicklung regeln. Er ist spezialisiert auf Edge-KI-Architektur für physische Systeme, einschließlich sicherheitsnaher Einsätze in automobilen und industriellen OT-Umgebungen.
Edge-KI-Architektur und eingebettete Inferenz für physische Systeme
Von der Simulation zum Produktiveinsatz in der Fertigungsrobotik
Souveräner, Air-Gapped-KI-Einsatz für industrielle Umgebungen
Der 6-schichtige Physical AI Stack für Robotik, Edge-KI und industrielle Automatisierung