Stellen Sie sich folgendes Szenario vor: Ein KI-gestütztes Wahrnehmungssystem besteht alle Gate-Reviews mit grünen Ampeln. Simulationen laufen stabil, Track-Erprobung ohne Auffälligkeiten. Dann, nach wenigen Wochen im Feld, treten drei Vorfälle auf, die sich wiederholen: tiefstehende Sonne, nasse Fahrbahn, ein bestimmtes Reflexmuster auf der Straßenoberfläche. Eine Konstellation, die in der Validierungs-Suite schlicht nicht vorgesehen war.
Das ist kein Bug im klassischen Sinne. Der Code ist korrekt, das Modell verhält sich nach Spezifikation. Es ist exakt das Phänomen, für das ISO 21448, die Norm für „Safety of the Intended Functionality (SOTIF)“, geschrieben wurde: funktionale Unzulänglichkeiten ohne klassischen Fehler, ausgelöst durch Betriebsbedingungen, die niemand explizit ausgeschlossen hat.
KI-basierte Fahrzeugfunktionen sind bewegliche Ziele. Jede neue Sensorgeneration, jeder neue Markt, jede neue Fahrzeugvariante erweitert die Operational Design Domain (ODD): die Gesamtheit aller Betriebsbedingungen, unter denen das System sicher funktionieren soll. Diese Erweiterung ist kein einmaliges Projekt, sondern ein Dauerprozess, der im 18- bis 24-Monats-Rhythmus neuer Sensor-Generationen läuft.
Das grundlegende Problem dabei: Klassische Code-Coverage-Metriken wie Branch Coverage, MC/DC und Statement Coverage sind für algorithmischen Code konzipiert. Ein neuronales Netz hat keine Verzweigungen im herkömmlichen Sinne, sondern Gewichte. Selbst eine vollständige Überdeckung des Wrapper-Codes prüft das eigentliche Modellverhalten nicht.
Was tatsächlich geprüft werden muss, sind die sogenannten Triggering Conditions: jene Eingabeklassen, die ein sicherheitsrelevantes Fehlverhalten des Machine-Learning-Modells auslösen können. Triggering Conditions kombinieren sich kombinatorisch. Vier Wetterzustände, fünf Lichtsituationen, drei Reflexmuster: Das ergibt bereits 60 Basisvariationen, und das ist ein stark vereinfachtes Modell. Ohne eine wiederverwendbare Szenarien-Suite startet jede neue Validierungsrunde bei null. Nicht weil das Team schlechte Arbeit leistet, sondern weil kein strukturiertes Instrument vorhanden ist, das ODD-Änderungen in bewertbare Szenarien übersetzt.
Die „Zehnerregel der Qualitätssicherung“ ist im Embedded-Umfeld bekannt: Ein Fehler, der erst im Feld entdeckt wird, kostet ein Vielfaches gegenüber einem, der in der Konzeptphase erkannt wird. In Projekten mit KI-basierten Fahrzeugfunktionen ist dieser Faktor besonders spürbar, weil Szenarien-Lücken selten isolierte Einzelprobleme sind.
Ein Late Finding kurz vor dem Gate-Review erzwingt Re-Tests. Wenn die Szenarien-Suite nicht modular gepflegt ist, starten diese Re-Tests von vorne, mit entsprechendem Aufwand und Termindruck. Verschobene Produktionsbeginn-Termine haben messbaren Einfluss auf Programmrendite und OEM-Vertrauen.
Hinzu kommt der Druck durch die Type Approval: Die SOTIF-Argumentation muss den Safety Case lückenlos erreichen. Fehlt diese Brücke, entstehen Audit-Findings in den Räumen zwischen Safety-FMEA, TARA und SOTIF-Analyse. Und nach dem Serienstart droht ein weiteres Risiko: Wer kein Drift-Monitoring etabliert, betreibt seinen Safety Case mit einem unausgesprochenen Auslaufdatum. Die UN R155 und UN R156 sind seit Juli 2024 typgenehmigungsrelevant. Ab dem 2. August 2027 greifen die Hochrisiko-Anforderungen des EU AI Act für KI als Sicherheitskomponente, mit Anforderungen an Post-Market-Monitoring und einem Strafrahmen von bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes.
Die Antwort auf eine wachsende ODD ist keine vollständige Abdeckung aller denkbaren Szenarien, das wäre weder wirtschaftlich noch technisch realisierbar. Die Antwort ist eine strukturierte Validierungspyramide, in der jede Ebene beantwortet, was die andere nicht leisten kann.
Das ODD-Modell selbst sollte kein statisches Dokument sein, sondern ein lebendes Engineering-Artefakt, das Sensor-Generationswechsel, Markterweiterungen und Release-Zyklen abbildet. Wiederverwendbare Szenarien-Suites auf Basis von Standards wie ASAM OpenSCENARIO schaffen die Grundlage, dass neue Varianten nicht jedes Mal bei null beginnen müssen.
Eine perfekte Validierungspyramide schützt nicht vor jedem Edge-Case. Aber sie macht ihn bewertbar, und genau das verlangen UN R155, UN R156 und der EU AI Act.
Wie das in KI-Projekten mit sicherheitsrelevanten Fahrzeugfunktionen konkret aussieht und wo der Hebel mit dem besten Aufwands-Nutzen-Verhältnis liegt, zeigt das 20-minütige Webinar „Sichere KI im Fahrzeug: SOTIF auf den Punkt“ live, mit anschließender Q&A-Session.
Termin: 23. Juni 2026, 11:00 UhrDauer: 20 Minuten + Fragen
Nicht jede Ebene muss gleich stark ausgebaut werden. Simulation übernimmt die kombinatorische Breite, HIL prüft das Systemverhalten unter Echtzeitbedingungen, Track liefert Ground-Truth für die kritischsten Szenarien. Wer eine Ebene ganz weglässt, hinterlässt eine Lücke in der Beweisbarkeit, die keine andere Ebene vollständig schließen kann.
Ein Edge Case ist selten, aber bekannt. Eine Triggering Condition ist eine spezifische Eingabekonstellation, die ein sicherheitsrelevantes Fehlverhalten auslösen kann, auch ohne dass sie selten wäre. ISO 21448 (SOTIF) adressiert genau diese Klasse: Risiken aus dem normalen Betrieb, nicht aus Hardwarefehlern.
ISO 26262 behandelt Risiken durch zufällige Hardwarefehler und systematische Softwarefehler. ISO 21448 (SOTIF) ergänzt sie um Risiken aus funktionalen Unzulänglichkeiten ohne klassischen Fehler. Für KI-basierte Fahrzeugsysteme sind beide Normen relevant und müssen gemeinsam argumentiert werden.
Ja. Wer heute KI-basierte Fahrzeugfunktionen entwickelt oder plant, legt jetzt die Grundlage für Validierungsstrategie und Safety Case. Die Entscheidungen, die heute über Szenarien-Suites und ODD-Modellierung getroffen werden, bestimmen den Audit-Aufwand in 12 bis 18 Monaten.
Vorname:
Nachname:
E-Mail-Adresse:
Telefonnummer:
Betreff:
Ihre Nachricht:
Ja, ich bin einverstanden, dass meine personenbezogenen Daten elektronisch erhoben und gespeichert werden. Meine Daten werden nur zum Zweck der Beantwortung meiner Anfragen verwendet. Die Datenschutzhinweise habe ich zur Kenntnis genommen.
Sie sehen gerade einen Platzhalterinhalt von OpenStreetMap. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie müssen den Inhalt von hCaptcha laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Sie sehen gerade einen Platzhalterinhalt von HubSpot. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Hubspot Meetings. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Google Maps. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.