ISO 21448 SOTIF für ADAS kein Fehler, trotzdem eine Gefährdung.

1. SOTIF ist nicht ISO 26262 — und die Verwechslung kostet Sie eine erneute Bewertung

Dieses Missverständnis sehen wir bei rund der Hälfte der ersten ADAS-Programme, die auf unserem Tisch landen: Das Team hat einen sauberen Satz an ISO-26262-Arbeitsergebnissen, eine ordentliche HARA, eine ASIL-Dekomposition, die das Review übersteht — und nimmt dann an, der Sicherheitsnachweis sei fertig. Ist er nicht, denn eine andere Norm regelt eine andere Klasse von Gefährdung.

Bei ISO 26262 geht es um Fehlverhalten durch Ausfälle: Etwas geht kaputt. Ein Bit kippt im RAM, ein Transistor hält fest, ein CAN-Frame wird verfälscht, ein Sensorkanal fällt mit Kurzschluss nach Batterie aus. Darauf antworten Sie mit Sicherheitsmechanismen, Diagnosedeckungsgrad, FMEDA, Hardware-Metriken (SPFM, LFM, PMHF) und einem Beherrschbarkeitsargument. Der Fehler ist die Ursache, und Sie können auf ihn zeigen.

ISO 21448:2022 — die Sicherheit der Sollfunktion, SOTIF — behandelt den umgekehrten Fall: Nichts ist defekt, und Sie haben trotzdem eine Gefährdung. Die Hardware ist gesund, die Software läuft genau wie spezifiziert, jede Diagnose meldet grün — und die Funktion tut dennoch das Falsche, weil ihr beabsichtigtes Verhalten Leistungsgrenzen hat. Ein Radar, das ein stehendes Fahrzeug nicht von einer Schilderbrücke trennen kann. Ein Kamera-Klassifikator, der eine bestimmte Aufliegerbeklebung in der Dämmerung noch nie gesehen hat und sie selbstsicher falsch einordnet. Eine Notbremsfunktion, die auf eine Dampfschwade auslöst, weil die Wahrnehmungskette tatsächlich ein Hindernis sieht. Keine Komponente ist ausgefallen. Die Funktion hat getan, wofür sie gebaut wurde — und das war in diesem Szenario unsicher.

Zwei weitere SOTIF-Ursachen stehen neben den Leistungsgrenzen: vorhersehbarer Fehlgebrauch (der Fahrer verlässt sich auf ein Level-2-Assistenzsystem, als wäre es Level 3, und überwacht die Strasse nicht mehr) und unzureichende Spezifikation (die Anforderung hat diese Ecke der Realität nie erfasst). Keine davon wird durch einen ISO-26262-Sicherheitsmechanismus abgedeckt, denn es gibt keinen Fehler, den ein Mechanismus erkennen könnte. Genau das ist der Kern — und der Grund, weshalb eine SOTIF-Lücke in Ihrer FMEDA nicht auftaucht. Die Basis der funktionalen Sicherheit, auf der SOTIF aufsetzt, finden Sie in unserer Praxis für funktionale Sicherheit; die ASIL-Mechanik behandeln wir in unserem ASIL-D-FuSa-Leitfaden für Tier-1.

2. Die vier Bereiche — und wo Ihre eigentliche Arbeit liegt

ISO 21448 fasst das Problem in eine 2×2-Aufteilung aller möglichen Szenarien, geteilt auf zwei Achsen: sicher vs. unsicher und bekannt vs. unbekannt. Es ist das nützlichste Denkmodell der gesamten Norm, deshalb zeichnen wir es bei jedem SOTIF-Kick-off ans Whiteboard.

• Bereich 1 — bekannt, sicher. Szenarien, die Sie verstehen und in denen die Funktion akzeptabel arbeitet. Das ist Ihr spezifizierter, validierter Betriebsbereich. Gute Nachricht, keine weitere Aktion ausser ihn zu erhalten.
• Bereich 2 — bekannt, unsicher. Szenarien, die Sie als gefährlich erkannt haben — die Dampfschwade, die Schilderbrücke, das Ausbleichen der Kamera bei tiefer Sonne. Sie wissen davon, also können Sie handeln: den Algorithmus verbessern, eine Sensormodalität ergänzen, die ODD einschränken oder eine SOTIF-Massnahme hinzufügen.
• Bereich 3 — unbekannt, unsicher. Der gefährliche. Gefährdende Szenarien, an die im Programm noch niemand gedacht hat. Sie sind unsicher, und Sie wissen nicht, dass sie existieren — also können Sie sie nicht entschärft haben.
• Bereich 4 — unbekannt, sicher. Szenarien, die Sie nicht bedacht haben, die aber zufällig harmlos sind. Weniger interessant, aber vorhanden.

Die gesamte SOTIF-Tätigkeit reduziert sich auf ein einziges geometrisches Ziel: Bereich 2 und Bereich 3 verkleinern. Bereich 3 (unbekannt-unsicher) verkleinern Sie durch Entdecken von Szenarien — Analyse, Simulation, Erkundung auf der Erprobungsstrecke, Auswertung von Felddaten — und ziehen sie nach Bereich 2, wo sie bekannt werden. Bereich 2 (bekannt-unsicher) verkleinern Sie dann durch Engineering — indem Sie diese Szenarien über bessere Wahrnehmung, Sensorfusion, ODD-Grenzen oder Funktionseinschränkungen nach Bereich 1 verschieben.

Die Falle, die wir am häufigsten sehen: Teams stecken ihre Energie in Bereich 2, weil er sichtbar und greifbar ist, während Bereich 3 — das Restrisiko, das tatsächlich verletzt — unfinanziert bleibt. Das Akzeptanzargument am Ende eines SOTIF-Projekts ist im Kern eine Aussage darüber, wie klein Sie Bereich 3 getrieben haben und warum dieses Restrisiko vertretbar ist. Hat Ihr Plan keine ausdrückliche Strategie zur Reduktion von Bereich 3, haben Sie noch keinen SOTIF-Plan.

3. SOTIF in die bestehende Sicherheitsarbeit integrieren — wiederverwenden, nicht duplizieren

Die Befürchtung, die wir am häufigsten hören, lautet: SOTIF bedeute eine zweite, parallele Sicherheitsorganisation mit eigener HARA, eigenen Reviews und eigenem Papierkram. Tut es nicht — und es so aufzubauen, ist der sichere Weg, ein Quartal zu verlieren. ISO 21448 ist bewusst so geschrieben, dass sie mit dem ISO-26262-Lebenszyklus verzahnt; der effiziente Weg hängt die SOTIF-Tätigkeiten an Arbeitsergebnisse, die Sie ohnehin erzeugen.

In der Praxis verankern wir SOTIF an wenigen bestehenden Stellen:

• Item-Definition. Dieselbe Item-Definition speist beide Normen. Für SOTIF erweitern Sie sie um die ODD — die operative Auslegungsdomäne (Operational Design Domain) — und um die Wahrnehmungs- und Entscheidungsleistung, auf die sich die Funktion stützt. Diese eine Ergänzung treibt den Grossteil der nachgelagerten SOTIF-Analyse.
• Gefährdungsanalyse. Führen Sie die SOTIF-Gefährdungsidentifikation, wo möglich, im selben Workshop wie die HARA durch, mit demselben interdisziplinären Team. Die gefährdenden Ereignisse sind oft dieselben; was sich unterscheidet, ist die Ursache. Zu jeder Gefährdung stellen Sie die ISO-26262-Frage („Welcher Ausfall führt hierher?“) und die SOTIF-Frage („Welche Leistungsgrenze oder welcher Fehlgebrauch führt ohne Fehler hierher?“). Ein Workshop, zwei Ursachenklassen.
• Funktionales und technisches Sicherheitskonzept. SOTIF-Massnahmen — Sensorfusion, Plausibilitätsprüfungen, ODD-Überwachung und Degradation, Aufmerksamkeitsmanagement gegen Fehlgebrauch — stehen neben Ihren ISO-26262-Sicherheitsmechanismen in derselben Architektur, nicht in einem separaten Dokument.
• Verifikation und Validierung. Die V&V-Kampagne ist gemeinsame Infrastruktur. Derselbe HIL, dieselbe Simulations-Toolchain und dieselben Erprobungsstrecken-Slots dienen sowohl der Fehlerinjektion (26262) als auch der Szenarienabdeckung (21448).

Wo die beiden wirklich auseinandergehen, ist die Natur des Arguments. ISO 26262 liefert diskrete, zählbare Ziele — Metriken, Abdeckungsgrade, einen PMHF-Wert. SOTIF liefert ein statistisches und Vollständigkeitsargument über einen kontinuierlichen Szenarienraum, das schwerer zu schliessen ist und eine andere Nachweis-Denkweise verlangt. Wer das früh erkennt, vermeidet den teuersten Fehler: das SOTIF-Restrisiko in eine einzige ASIL-artige Zahl zu pressen, die es nie liefern sollte.

4. Auslösende Bedingungen und der Szenarienkatalog

Der Motor der SOTIF-Analyse ist die auslösende Bedingung (triggering condition): der konkrete Eingang oder Umweltumstand, der eine Leistungsgrenze freilegt und eine harmlose Funktion in eine gefährdende verwandelt. Nicht die Grenze selbst — die Bedingung, die sie aktiviert. Tiefe Sonne direkt hinter einem Fussgänger. Starke Gischt, die das Radarecho mindert. Ein Radfahrer, dessen Silhouette ein geparktes Auto überlagert. Retroreflektierende Strassenausstattung, die eine Fahrzeugsignatur nachahmt. Schnee, der Fahrbahnmarkierungen verdeckt. Jede davon ist eine auslösende Bedingung, und sie systematisch zu identifizieren, ist der Hauptteil der analytischen Arbeit.

Wir treiben das von der ODD nach aussen. Die operative Auslegungsdomäne — Strassentypen, Geschwindigkeitsbereiche, Wetter, Beleuchtung, Verkehrsdichte, geografischer Geltungsbereich — ist die Grenze dessen, wo die Funktion arbeiten darf. Jede Dimension der ODD ist eine Quelle auslösender Bedingungen: jeder Wetterzustand, jeder Beleuchtungsübergang, jeder Typ von Strassenausstattung, jedes Manöver eines umgebenden Verkehrsteilnehmers. Wir zerlegen die ODD methodisch und fragen für jede Zelle, welche Leistungsgrenzen der Wahrnehmungs- und Entscheidungskette sie anregen könnte.

Das speist den Szenarienkatalog — das lebende, strukturierte Verzeichnis von Szenarien, das definiert, was die Funktion beherrschen muss und wogegen sie getestet wird. Ein brauchbarer Katalog ist keine flache Liste; er ist so organisiert, dass Szenarien parametrisiert sind (Ego-Geschwindigkeit, Zielgeschwindigkeit, Time-to-Collision, Beleuchtung, Reibwert) und zurück zur ODD-Dimension und auslösenden Bedingung verfolgbar sind, die sie motiviert haben. Derselbe Katalog wird dann zur Testspezifikation aus Abschnitt 5.

Zwei Disziplinen trennen einen vertrauenswürdigen Katalog von einem unzuverlässigen. Erstens muss er gepflegt werden: jede neue auslösende Bedingung, die in der Simulation, auf der Erprobungsstrecke oder in Felddaten gefunden wird, fliesst zurück, sodass der Katalog zur Vollständigkeit hin wächst, statt zum SOP einzufrieren. Zweitens braucht er eine ausdrückliche Vollständigkeitsbegründung — wie argumentieren Sie, dass keine ganze Szenarienklasse fehlt? Wir kombinieren strukturierte ODD-Zerlegung, etablierte Szenario-Taxonomien, Experten-Befragungsworkshops und Felddaten-Analytik, gerade weil keine einzelne Quelle für sich vollständig ist. Diesen Katalog und die dahinterliegende Analyse aufzubauen, ist Kernarbeit im Sicherheits-Software-Engineering; die Methode früh richtig zu treffen, behandeln wir in unserem SOTIF-Training und Consulting.

5. Verifikation und Validierung — und die Frage „Wie viel Test ist genug?“

SOTIF-V&V ist szenarienbasiert und läuft über drei Stufen, die Abdeckung gegen Realitätstreue abwägen:

• Simulation. Hier bekommen Sie Skalierung. Sie können Tausende Parametervariationen einer auslösenden Bedingung durchfahren, Sensor- und Umweltmodelle rechnen und den unbekannt-unsicheren Raum weit schneller als jeder physische Test absuchen. Das ist Ihr primäres Werkzeug zur Erkundung von Bereich 3. Ihre Schwäche ist die Treue — ein Sensormodell ist nur so gut wie seine Validierung gegen die Realität.
• Erprobungsstrecke. Hier bekommen Sie kontrollierte, wiederholbare physische Wahrheit für die Szenarien höchster Schwere — AEB auf weiche Ziele, Einscheren ungeschützter Verkehrsteilnehmer, niedrige Reibwerte. Geringeres Volumen, hohe Konfidenz.
• Feld / Strasse. Hier überrascht die Realität und speist die Entdeckung von Bereich 3. In Open-Road- und Shadow-Mode-Daten tauchen die wirklich unvorhergesehenen auslösenden Bedingungen auf, die dann in den Katalog und die Simulationsläufe zurückfliessen.

Die Metrik, die das zusammenhält, ist die ODD-Abdeckung: Haben Sie die Funktion über jede Dimension und Kombination ihrer deklarierten Betriebsdomäne ausgeübt, gegen definierte Akzeptanzkriterien? Akzeptanzkriterien müssen vor dem Test festgelegt werden — eine messbare Schwelle je Szenarienklasse (z. B. geforderte Detektionsreichweite, Time-to-Brake, Fehlauslöserate unter definierten Bedingungen), die die Funktion erfüllen muss, damit das Restrisiko als vertretbar gilt.

Das führt zur Frage, die jedes Programm irgendwann stellt: Wie viel Test ist genug? Einen kontinuierlichen Szenarienraum können Sie nicht erschöpfend testen, und naive statistische Argumente verlangen unplausible Fahrleistungen, um Sicherheit allein durch rohe Gewalt zu zeigen. Die SOTIF-Antwort lautet nicht „mehr Kilometer“, sondern ein strukturiertes Vollständigkeitsargument. Sie kombinieren gezielte Szenarienabdeckung des bekannt-unsicheren Bereichs, simulationsgeführte Erkundung des unbekannt-unsicheren Bereichs, eine verteidigbare Vollständigkeitsbegründung aus der ODD-Zerlegung und ein Akzeptanzkriterium für das Restrisiko — und argumentieren mit Belegen, dass weiterer Test nur noch abnehmende Reduktion von Bereich 3 bringt. „Genug“ ist der Punkt, an dem Ihre Entdeckungsmethoden keine neuen gefährdenden Szenarien mehr zutage fördern und Ihr Restrisikoargument trägt. Das ist eine Ingenieur- und Nachweisbeurteilung, kein Kilometerzähler.

6. Der regulatorische Druck — SOTIF ist nicht mehr optional

Eine Zeit lang liess sich SOTIF als Reifegradziel behandeln — wünschenswert, unter Terminplandruck verschiebbar. Die Regulierung hat diese Tür geschlossen. Die EU-General Safety Regulation, Verordnung (EU) 2019/2144, macht eine Reihe fortgeschrittener Fahrerassistenzsysteme bei Neufahrzeug-Typgenehmigungen und, in ihrem gestuften Zeitplan, über Neuzulassungen hinweg verpflichtend: Notbremsassistent (AEB), intelligente Geschwindigkeitsassistenz, Notfall-Spurhalteassistent, Müdigkeits- und Aufmerksamkeitswarnung und weitere.

Die Folge ist unmittelbar. Schreibt eine Verordnung vor, dass eine ADAS-Funktion vorhanden sein muss, dann ist eine Leistungsgrenze in dieser Funktion — ein AEB, das nicht detektiert, oder das ungewollt auslöst — ein Sicherheitsproblem in einem regulierten, typgenehmigten System. Genau das ist die SOTIF-Domäne: kein Fehler, aber eine Gefährdung aus der Sollfunktion. Sie können die Funktion nicht mehr ausliefern und ihre Wahrnehmungsgrenzen als unspezifiziertes Restrisiko behandeln. Ein SOTIF-Argument — ODD, auslösende Bedingungen, Szenarienabdeckung, Akzeptanzkriterien, Restrisikobegründung — ist nun Teil des Nachweises, dass eine regulierte Funktion sicher genug für die Strasse ist.

Praktisch heisst das: OEM-Programme reichen SOTIF-Erwartungen zunehmend als vertragliche Liefergegenstände neben den ISO-26262-Arbeitsergebnissen an Tier-1-Zulieferer durch. Wir sehen heute SOTIF-Anforderungen in Lastenheften, wo vor zwei, drei Jahren keine standen. Ein Wahrnehmungs- oder AEB-Zulieferer, der kein glaubwürdiges SOTIF-Argument vorlegen kann, ist für diese Funktionen zunehmend kein tragfähiger Zulieferer. Die Norm ist zur Marktzugangsbedingung geworden, nicht zum Abzeichen.

7. Nachweis — das SOTIF-Argument neben dem funktionalen Sicherheitsnachweis

Alles oben Genannte existiert, um eine Sache zu erzeugen: ein SOTIF-Argument — einen strukturierten, mit Belegen unterfütterten Nachweis, dass das Restrisiko aus Leistungsgrenzen und vorhersehbarem Fehlgebrauch hinreichend gering getrieben wurde. Es steht neben Ihrem ISO-26262-Sicherheitsnachweis, nicht darin, denn es behauptet eine andere Aussage mit anderen Belegen.

Ein SOTIF-Argument, das die Bewertung übersteht, verknüpft eine Kette, die ein Assessor von Anfang bis Ende abschreiten kann:

1. Item-Definition und ODD — die Funktion, ihre Grenzen und die deklarierte Betriebsdomäne, in der sie validiert ist.
2. Gefährdungsidentifikation — die gefährdenden Ereignisse und die jeweils zugrunde liegenden Ursachen aus Leistungsgrenze und Fehlgebrauch, das Inventar von Bereich 2.
3. Auslösende Bedingungen — von der ODD-Zerlegung zu den konkreten Bedingungen verfolgt, die jede Grenze freilegen.
4. SOTIF-Massnahmen — die architektonischen und funktionalen Antworten (Fusion, Plausibilität, ODD-Überwachung und Degradation, Fehlgebrauchsbehandlung) und welche Szenarien jede adressiert.
5. V&V-Belege — die Simulations-, Erprobungsstrecken- und Feldergebnisse, die zeigen, dass die Akzeptanzkriterien über die ODD-Abdeckung erfüllt sind.
6. Vollständigkeits- und Restrisikobegründung — warum Bereich 3 klein genug getrieben wurde und warum das verbleibende Restrisiko vertretbar ist.

Zwei Eigenschaften entscheiden, ob dieses Argument trägt. Die erste ist Verfolgbarkeit: Jeder Test muss zu einer auslösenden Bedingung verfolgbar sein, jede auslösende Bedingung zu einer ODD-Dimension, jede Gefährdung zu einer Massnahme und ihrem Beleg. Lücken in dieser Kette sind genau dort, wo ein Assessor — oder ein Feldvorfall — das Loch findet. Die zweite ist Ehrlichkeit zum Restrisiko: Ein glaubwürdiges SOTIF-Argument behauptet kein Nullrisiko über einen kontinuierlichen Szenarienraum. Es nennt das Restrisiko klar und begründet, warum es gegen definierte Kriterien vertretbar ist. Wir haben Argumente scheitern sehen, nicht weil das Engineering schwach war, sondern weil das Restrisiko verborgen statt verantwortet wurde.

Zusammen mit dem funktionalen Sicherheitsnachweis gelesen, beantworten beide die vollständige Frage, die Regulator und OEM heute stellen: Das Ausfallrisiko ist beherrscht (ISO 26262), und das Sollfunktionsrisiko ist vertretbar (ISO 21448). Für ein Wahrnehmungs- oder AEB-Programm im Jahr 2026 steht keine der beiden Hälften für sich allein — und die SOTIF-Hälfte ist diejenige, deren Aufbau die meisten Teams noch lernen.

---

Möchten Sie einen 30-minütigen Walkthrough zu Ihrem Projekt?

Keine NDA nötig. Sagen Sie uns die Norm, das Item bzw. Asset, den Assessor und Ihre Deadline. Innerhalb von 48 Stunden erhalten Sie eine einseitige Diagnose, abgebildet auf die obigen Punkte — Ihre, ob Sie uns beauftragen oder nicht.

FuSa-Walkthrough buchen →

---

Autor: Adrian Valea, Gründer & Geschäftsführer, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Veröffentlicht 2026-05-30.