In vielen ISO-26262-Programmen erklären Teams selbstbewusst:
„Wir haben AEBS validiert.“
Bei der Prüfung der Nachweise zeigt sich jedoch häufig, dass umfangreiche Tests vorgelegt werden – nicht unbedingt eine Validierung im Sinne der funktionalen Sicherheit. Verifikation und Validierung sind keine Synonyme. Sie beantworten unterschiedliche technische Fragen und erfordern unterschiedliche Nachweise. Ihre Verwechslung führt nicht nur zu begrifflichen Problemen – sie schwächt die Sicherheitsargumentation, die die Gefährdungsanalyse mit einem sicheren Fahrzeugverhalten verbindet. Verdeutlichen wir dies anhand von AEBS als Referenz-Item.
1. Definitionen im Kontext der ISO 26262
1.1 Verifizierung
Verifizierung ist die Bestätigung, dass festgelegte Anforderungen erfüllt sind. Sie beantwortet die Frage:
Entwickeln wir das System richtig?
Die Verifizierung stellt sicher, dass:
- Sicherheitsanforderungen werden korrekt abgeleitet
- Anforderungen sind korrekt zugeordnet
- Konstruktionselemente setzen diese Anforderungen um
- Die Umsetzung verhält sich wie spezifiziert
Verifikation ist anforderungsorientiert und erfolgt auf System-, Hardware-, Software- und Integrationsebene. Sie liefert einen Nachweis für die Konformität des Designs.
1.2 Validierung
Validierung ist die Bestätigung, dass die Sicherheitsziele im vorgesehenen betrieblichen Kontext erreicht werden. Sie beantwortet die Frage:
Entwickeln wir das richtige System, um die identifizierte Gefährdung zu mindern?
Die Validierung stellt sicher, dass:
- Die in der HARA ermittelten Gefährdungen werden wirksam gemindert
- Safety Goals werden auf Item-Ebene erreicht
- Das Fahrzeug bleibt unter realen Betriebsbedingungen sicher
Die Validierung ist gefährdungsorientiert und findet überwiegend statt auf Item-Ebene (Fahrzeugebene). Sie liefert Nachweise für die Sicherheitswirksamkeit.
1.3 Gegenüberstellung der Definitionen
2. Ihre Position im Lebenszyklus nach ISO 26262
Ein vereinfachter Ablauf der Funktionalen Sicherheit sieht so aus:
- Item-Definition
- HARA
- Sicherheitsziele
- Funktionales Sicherheitskonzept
- Technisches Sicherheitskonzept
- System-, HW- und SW-Entwicklung
- Integration und Prüfung
- Sicherheitsvalidierung
Verifikationsaktivitäten sind in die Stufen 4 bis 7 eingebettet. Die Validierung erfolgt in Stufe 8 und bestätigt, dass die aus der HARA abgeleiteten Sicherheitsziele auf Fahrzeugebene erreicht werden. Die Verifikation begleitet die Entwicklungskette. Die Validierung schließt den Kreis zurück zur Gefährdung.
3. AEBS-Referenzfall
Gefährdung: Unbeabsichtigte Vollbremsung bei Autobahngeschwindigkeit.
Safety Goal: Unbeabsichtigtes autonomes Bremsen verhindern.
Aus diesem Safety Goal werden funktionale Sicherheitsanforderungen und technische Sicherheitsanforderungen abgeleitet und den Systemelementen zugeordnet. Nun wird der Unterschied zwischen Verifizierung und Validierung sichtbar.
4. Wie Verifizierung bei AEBS aussieht
Die Verifizierung bestätigt, dass abgeleitete Anforderungen korrekt umgesetzt wurden. Typische Verifizierungsaktivitäten sind:
- Bestätigen, dass FSR korrekt aus dem Sicherheitsziel abgeleitet wurden
- Bestätigen, dass TSR angemessen zugeordnet sind
- Die Softwarelogik zur Auslösung des Bremsvorgangs prüfen
- Verifizierung der diagnostischen Überwachung von Sensoren
- Das Verhalten im sicheren Zustand bei Fehlererkennung bestätigen
- Prüfung der Einhaltung der FTTI
- Korrektheit der ASIL-Dekomposition verifizieren
Typische Nachweise umfassen:
- Matrizen zur Anforderungsrückverfolgbarkeit
- Entwicklungsreviews
- Statische Analyse
- Unittests
- Integrationstests
- Fehlerinjektionstests
- Bewertung von SPFM und PMHF
Die Verifizierung weist nach, dass das Sicherheitsdesign wie spezifiziert umgesetzt wurde. Sie weist noch nicht nach, dass das Fahrzeug im tatsächlichen Betrieb sicher ist.
5. Wie Validierung bei AEBS aussieht
Die Validierung bestätigt, dass das Sicherheitsziel auf Item-Ebene erreicht wird. Beim AEBS-Beispiel weist die Validierung Folgendes nach:
- Unter realen Fahrbedingungen tritt kein unbeabsichtigtes Bremsen auf
- Bei eingespeisten Fehlern wechselt das System in einen sicheren Zustand
- Der Fahrereingriff funktioniert korrekt
- Die in der HARA ermittelte Gefährdung wird wirksam gemindert
Typische Nachweise umfassen:
- Validierungstests auf Fahrzeugebene
- Integrierte Fehlerkampagnen
- Erprobungen auf dem Prüfgelände
- Sicherheitsbestätigung auf Systemebene
Die Validierung schließt den Kreis zwischen:
Gefährdung → Sicherheitsziel → Sicheres Fahrzeugverhalten.
6. Direkter Vergleich
7. Häufige Mythen
Mythos 1: Die Validierung findet nur am Ende statt. Realität: Die Validierungsstrategie muss bereits ab der Phase des Sicherheitskonzepts geplant werden.
Mythos 2: Wenn alles verifiziert ist, erfolgt die Validierung automatisch. Realität: Selbst eine fehlerfrei umgesetzte Konstruktion kann die Gefährdung in der realen Welt unzureichend mindern.
Mythos 3: Systemtests sind gleichbedeutend mit Validierung. Realität: Wenn Prüfungen lediglich die Erfüllung von Anforderungen bestätigen, bleiben sie Verifikation.
8. Die technische Kernaussage
- Verifikation stellt sicher, dass der AEBS-Entwurf korrekt umgesetzt wird.
- Die Validierung stellt sicher, dass das Fahrzeug im realen Einsatz nicht unbeabsichtigt bremst.
- Verifizierung liefert Nachweise der Entwicklungskonformität. Validierung liefert Nachweise für die Minderung von Gefährdungen.
- Beide sind in ISO 26262 verpflichtend. Keine ersetzt die andere.
- Die Unterscheidung ist nicht bloß begrifflich. Sie ist strukturell und für eine belastbare Sicherheitsargumentation entscheidend.