Automobil · Die Hürde aus Safety und Validierung überwinden, bevor Sie KI ausliefern

Ein Fahrer schläft. Das Auto fährt in der Abenddämmerung 70 mph auf der Autobahn. Ein Lkw vorne verliert eine Matratze, die auf die Fahrspur rollt. Die KI-Fahrfunktion hat etwa eine Sekunde, um das Objekt zu erkennen, zu klassifizieren, seine Bewegung zu prognostizieren, ein Manöver zu planen und eine Bremsung oder einen Spurwechsel auszuführen. Wenn sie es richtig macht, merkt es niemand. Wenn sie es falsch macht, steht ein Unternehmen vor einem Todesfall, einem Rückruf und einem Gerichtssaal.

Die harte Frage für jedes Automotive-Team, das KI ausliefert, lautet nicht „funktioniert es im Demo?“. Sie lautet: „Können wir belegen, dass es sicher genug ist, um es zu verkaufen, zuzulassen und zu verteidigen?“ Dieser Nachweis hat in dieser Branche einen Namen: Homologation (die formale Genehmigung, die Ihnen den legalen Verkauf eines Fahrzeugs in einem Markt erlaubt) plus ein belastbarer Safety Case.

Diese Lektion geht die drei Säulen durch, mit denen Teams diese Hürde überwinden.

Säule 1: ISO 26262 und funktionale Sicherheit

ISO 26262 ist die internationale Norm für funktionale Sicherheit in Straßenfahrzeugen. „Funktionale Sicherheit“ bedeutet, dass sich das System auch beim Ausfall einer Komponente sicher verhält. Denken Sie an einen Sensor, der ausfällt, einen Chip, der ein Bit kippt, oder Software, die abstürzt.

Das zentrale Werkzeug ist ASIL, das Automotive Safety Integrity Level. Jede Gefährdung wird von A (niedrigste) bis D (höchste) eingestuft, auf Basis von drei Faktoren:

• Severity: Wie schwer ist der Schaden?
• Exposure: Wie oft befindet sich das Fahrzeug in dieser Situation?
• Controllability: Kann ein Fahrer oder das System den Schaden vermeiden?

Ein Ausfall von Brake-by-wire bei Autobahngeschwindigkeit ist ASIL D. Eine klemmende Innenraumleuchte wird qualitätsgemanagt und überhaupt nicht safety-eingestuft.

Hier liegt die Reibung mit KI. ISO 26262 wurde für Systeme geschrieben, die Sie vollständig spezifizieren kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen. Sie können eine Anforderung für einen Antiblockier-Algorithmus schreiben und jeden Zweig testen. Ein neuronales Netz, das auf Millionen Bildern trainiert wurde, hat keine so saubere Spezifikation. Sie können nicht alles aufzählen, was es gelernt hat.

Also zertifizieren Teams nicht das Netz selbst nach klassischer 26262. Sie umgeben es mit Architektur, die sie zertifizieren *können*:

• Ein redundanter, regelbasierter Safety-Monitor, der die KI übersteuert, wenn sie etwas Gefährliches anfordert.
• Eine einfachere, verifizierbare „Safety Envelope“, die garantiert, dass das Auto physikalische Grenzen nie überschreitet, unabhängig davon, was die KI will.

Die KI schlägt vor. Die zertifizierte Ebene entscheidet.

Säule 2: SOTIF, für den Fall, dass nichts kaputt war und trotzdem Schaden entstand

ISO 26262 deckt Ausfälle ab. Aber KI hat einen beängstigenderen Fehlermodus: alles funktioniert genau wie entworfen, und trotzdem tut es das Falsche.

Das ist die Domäne von SOTIF (Safety Of The Intended Functionality), normiert als ISO 21448. SOTIF existiert, weil ein Perception-System mit null Hardwarefehlern trotzdem einen weißen Lkw gegen einen hellen Himmel falsch lesen oder einen Fußgänger in ungewöhnlicher Haltung nicht erkennen kann.

SOTIF teilt die Welt in vier Kästen:

1. Known safe Szenarien (die, für die Sie entworfen haben).
2. Known unsafe Szenarien, die Sie gefunden und behoben haben.
3. Unknown unsafe Szenarien: die, die Ihnen wehtun.
4. Unknown safe Szenarien (harmlose Überraschungen).

Die gesamte Engineering-Arbeit besteht darin, Kasten 3 zu verkleinern. Das tun Sie, indem Sie Edge Cases aufspüren, strukturierte Szenarioanalysen fahren und unknown-unsafe Fälle in die Spalte „bekannt und mitigiert“ schieben.

Das UNECE World Forum for Harmonization of Vehicle Regulations veröffentlicht den regulatorischen Rahmen, den viele Märkte übernehmen, und es verweist für Zulassungen automatisierten Fahrens zunehmend auf beide Normen.

Warum Edge Cases das Budget dominieren

Die unangenehme Wahrheit: das letzte 1 Prozent der Szenarien verbraucht den größten Teil des Validierungsaufwands. Normale Autobahnfahrt ist einfach. Was Systeme bricht, ist der Long Tail: ein Pferd auf der Straße, eine überflutete Unterführung, ein Bauarbeiter, der widersprüchliche Handzeichen gibt, Einsatzfahrzeuge mit ungewöhnlichen Lichtmustern.

Sie können das nicht vorab wegdesignen. Sie müssen diese Fälle finden und dann belegen, dass Ihr System sie beherrscht.

Säule 3: Milliarden simulierter Meilen

Wie findet man seltene Ereignisse? Man kann sie nicht wirtschaftlich erfahren. Eine viel zitierte RAND-Analyse argumentierte, dass der Nachweis, ein autonomes System sei sicherer als Menschen, allein durch Fahren in der realen Welt hunderte Millionen oder sogar Milliarden Meilen erfordern könnte, was Flotten Jahrzehnte kosten würde. Behandeln Sie diese konkreten Zahlen als Schätzungen, aber die Richtung ist nicht umstritten: echte Meilen sind zu langsam und zu teuer für die seltenen Ereignisse, die am meisten zählen.

Also wandert die Arbeitslast in die Simulation.

Szenariobasierte Simulation. Teams bauen eine Bibliothek parametrisierter Szenarien (ein Einscheren, ein Fußgänger, der die Straße kreuzt, ein liegengebliebenes Fahrzeug) und variieren jede Größe: Geschwindigkeit, Abstand, Beleuchtung, Wetter, Reibwert. Ein Szenario wird zu tausenden Tests.

Resimulation (Log-Replay). Jede Meile, die eine echte Flotte fährt, wird zum Asset. Sie zeichnen die Sensordaten auf und spielen sie gegen neue Softwareversionen ab, um Regressionen zu prüfen. Hat das Update, das das Auffahren auf die Autobahn behoben hat, das Verhalten auf dem Parkplatz kaputtgemacht?

Synthetische Edge-Case-Generierung. Wo echte Daten dünn sind, erzeugen Sie sie: seltenes Wetter, seltene Objekttypen, adversariale Anordnungen, an die ein menschlicher Tester nie denken würde.

Das Ergebnis ist nicht „wir sind viel gefahren“. Es ist ein Coverage-Argument: wir haben die Operational Design Domain systematisch erkundet und gezeigt, dass die Funktion darin sicher bleibt.

Die Operational Design Domain (ODD) ist der genaue Rahmen, in dem das System zum Betrieb zugelassen ist: welche Straßen, Geschwindigkeiten, Wetterlagen und Tageszeiten. Ein System, das nur für baulich getrennte Autobahnen bei klarem Wetter unter 60 mph freigegeben ist, hat eine enge ODD, und das ist oft ein Feature, keine Schwäche. Eine enge ODD ist leichter zu validieren und leichter zu verteidigen.

🎬 [VIDEO: „How Waymo Uses Simulation to Test Self-Driving Cars“ - youtube.com - ein Blick in großskalige Fahrsimulation und Szenariotests]

Alles zusammengeführt: der Safety Case

Alle drei Säulen münden in ein Deliverable: den Safety Case. Das ist eine strukturierte, auditierbare Argumentation, dass das System hinreichend sicher ist, gestützt durch Evidenz. Regulierer wollen sie. Ihre eigene Rechtsabteilung will sie. Versicherer wollen sie.

Ein verbreiteter Aufbau ist ein Baum aus Claim, Argument, Evidence. In Pseudocode sieht das so aus:

CLAIM: The lane-keeping function is acceptably safe within its ODD.
  ARGUMENT: All identified hazards are mitigated to target ASIL.
    EVIDENCE: HARA (Hazard Analysis and Risk Assessment) document
    EVIDENCE: ASIL-D safety monitor verification results
  ARGUMENT: Residual SOTIF risk is acceptably low.
    EVIDENCE: 4.2M scenario-simulation runs, pass rate + failure triage
    EVIDENCE: field monitoring plan for unknown-unsafe cases
  ARGUMENT: The ODD is enforced at runtime.
    EVIDENCE: geofence + weather-degradation handover logic tests

Beachten Sie, was Ihnen das in einem Haftungsfall bringt. Wenn etwas schiefgeht, ist die Frage selten „war das System perfekt?“. Kein System ist das. Die Frage ist „hat das Unternehmen angesichts des Stands der Technik verantwortungsvoll gehandelt?“ Ein nachvollziehbarer Safety Case, der zeigt, dass Sie die Gefährdung identifiziert, eine Mitigation entwickelt und sie validiert haben, ist Ihr stärkster Beleg dafür.

Was das für Ihre Bauweise bedeutet

Die Validierungshürde formt die gesamte Produktorganisation um, nicht nur das Safety-Team.

Data Pipelines werden zur Safety-Infrastruktur. Jede Flottenmeile, die abgespielt werden kann, ist ein Validierungs-Asset. Teams, die reich und abrufbar loggen, validieren schneller.

Field Monitoring endet nie. SOTIF ist ein Lifecycle, kein Launch-Gate. Sie liefern aus, dann halten Sie Ausschau nach den unknown-unsafe Fällen, die erst im MaMaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßstab auftreten, dann beheben und revalidieren Sie. Over-the-Air-Updates machen diese Schleife enger, aber jedes Update öffnet die Validierungsfrage neu.

Eng schlägt breit. Eine eng gefasste ODD, die Sie vollständig verteidigen können, geht oft Jahre früher in Serie als eine ambitionierte, die Sie nicht verteidigen können. Viele Serien-Assistenzfunktionen sind gerade deshalb erfolgreich, weil sie sich weigern, außerhalb ihres Rahmens zu arbeiten.

Der Safety Case ist ein Geschäftsdokument. ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → reguliert den Marktzugang, prägt Versicherungskonditionen und begrenzt das Haftungsrisiko. Führungskräfte, die ihn als Papierkram behandeln, bepreisen Risiko falsch.

Key Takeaways

• ISO 26262 behandelt Ausfälle; SOTIF behandelt korrektes-aber-falsches Verhalten. KI braucht beides, denn ein fehlerfreies neuronales Netz kann die Welt trotzdem falsch wahrnehmen.
• Sie können ein neuronales Netz nicht direkt zertifizieren, also umgeben Sie es. Ein verifizierbarer Safety-Monitor und eine physikbasierte Safety Envelope erlauben Garantien, die die KI selbst nicht liefern kann.
• Simulation ist der einzige wirtschaftliche Weg zu den seltenen Ereignissen, die zählen. Szenariovariationen, Log-Replay und synthetische Edge Cases bauen ein Coverage-Argument, nicht nur eine Meilensumme.
• Eine enge, durchgesetzte ODD ist ein Wettbewerbsvorteil. Genau zu definieren, wo das System funktioniert, macht es schneller validierbar, genehmigungsfähig und verteidigbar.
• Der Safety Case ist Ihr Homologationsschlüssel und Ihr Haftungsschild. Nachvollziehbare Claim, Argument, Evidence schlagen ein perfektes Demo, wenn ein Regulierer oder ein Gericht fragt, woher Sie wussten, dass es sicher ist.