SOTIF (Safety of the Intended Functionality, ISO 21448)
SOTIF (Safety of the Intended Functionality, ISO 21448) adressiert Gefährdungen ohne Fehlfunktion: Das System arbeitet exakt wie spezifiziert, aber Spezifikation oder Sensorleistung reichen für die reale Situation nicht aus — zentral für Fahrerassistenz und KI-basierte Funktionen. Das klassische Beispiel: Eine Kamera erkennt ein Hindernis bei tief stehender Sonne oder starkem Schneefall nicht, obwohl das System vollkommen intakt ist.
Wovon grenzt sich SOTIF ab?
Die klassische funktionale Sicherheit nach ISO 26262 fragt: Was passiert, wenn das System nicht tut, was es soll? SOTIF fragt: Reicht das, was das System tun soll, in jeder erdenklichen Situation aus? Wer beide Disziplinen vermischt, greift zum falschen Werkzeugkasten:
| Disziplin | Kern-Gefahr | Richtige Werkzeuge |
|---|---|---|
| Klassische Safety (ISO 26262) | Fehlfunktionen: Hardware-Ausfälle, Software-Bugs | Diagnosen, Diversität, Hardware-Redundanz, degradierte Betriebsmodi |
| SOTIF (ISO 21448) | Funktionale Unzulänglichkeiten: Performance-Grenzen, unvorhergesehene Szenarien | Szenarienanalyse, geschärfte Spezifikation, komplementäre Sensorik (Fusion), Validierung im realen Betriebskontext |
Eine gleichartige Redundanz — etwa eine zweite, baugleiche Kamera — hilft gegen eine Performance-Grenze nicht: Sie verdoppelt nur dieselbe Schwäche. Und in einer rein fehlerorientierten Analyse wie einer klassischen FMEA bleiben Gefährdungen ohne klares Fehlerbild komplett unsichtbar.
Die Szenario-Systematik der ISO 21448
Der methodische Kern von SOTIF ist die systematische Aufteilung der möglichen Betriebsszenarien in vier Bereiche: bekannt oder unbekannt, kombiniert mit sicher oder unsicher. Ziel der SOTIF-Aktivitäten ist es, die unsicheren Bereiche systematisch zu verkleinern: Bekannte unsichere Szenarien werden durch Funktionsverbesserungen, geschärfte Spezifikationen oder Einsatzbeschränkungen entschärft; der Bereich der unbekannten unsicheren Szenarien wird durch Szenarienanalyse, Simulation und Validierung im realen Betriebskontext so weit wie möglich ausgeleuchtet. Ein Restrisiko unbekannter Szenarien bleibt — die Norm verlangt, es argumentierbar klein zu machen.
Warum SOTIF für KI und Machine Learning zentral ist
Machine-Learning-Funktionen besitzen keine Spezifikation im klassischen Sinn: Ihr Verhalten entsteht aus Trainingsdaten, nicht aus einem Anforderungsdokument. Ihre Schwächen sind darum prinzipbedingte Performance-Grenzen, keine Fehlfunktionen — und damit genau die Klasse von Gefährdungen, für die die SOTIF-Systematik gemacht ist. Mit dem Einzug lernender Komponenten in sicherheitsrelevante Funktionen verschiebt sich das Schwergewicht der Sicherheitsarbeit branchenübergreifend von der reinen Fehlerbeherrschung hin zur systematischen Absicherung der Sollfunktion.
SOTIF in der Praxis: Trennung mit realen Konsequenzen
Die Unterscheidung zwischen Fehlfunktion und funktionaler Unzulänglichkeit ist keine akademische Übung. Teams ohne klare Trennung behandeln eine Performance-Grenze schnell wie eine Fehlfunktion und produzieren teure Maßnahmen, die das eigentliche Problem nicht adressieren. In der Praxis bewährt sich, SOTIF-Analysen eng mit der funktionalen Sicherheit zu verzahnen: Beide betrachten dasselbe System, dieselben Szenarien und dieselben Architekturelemente — und jede Änderung am Systemschnitt wirkt auf beide Analysen zugleich. Wer die Ergebnisse modellbasiert und über Trace-Links verknüpft pflegt, statt in getrennten Dokumenten, hält beide Nachweisstränge bei Änderungen konsistent.