ISO 26262

Die Arbeit nach ISO 26262 beginnt mit der Gefährdungs- und Risikoanalyse (HARA, Hazard Analysis and Risk Assessment). Das Team spielt für jede Fahrzeugfunktion durch, welche Fehlfunktion in welcher Fahrsituation Menschen gefährden kann. Jede Gefährdung bekommt drei Bewertungen: Schwere des möglichen Schadens (S), Häufigkeit der Fahrsituation (E, Exposure) und Beherrschbarkeit durch den Fahrer (C, Controllability). Aus der Kombination ergibt sich das ASIL (Automotive Safety Integrity Level) von A bis D. Gefährdungen unterhalb von ASIL A fallen unter QM, also normales Qualitätsmanagement ohne zusätzliche Safety-Anforderungen.

Das ASIL bestimmt, wie streng die Entwicklung sein muss. Ein ungewollter Eingriff in die Lenkung bei Autobahnfahrt landet schnell bei ASIL D, eine ausgefallene Innenraumbeleuchtung nicht. Je höher das ASIL, desto strenger die geforderten Methoden, Reviews und Testabdeckungen. Für die Unit-Tests auf ASIL D empfiehlt die Norm zum Beispiel ausdrücklich MC/DC-Abdeckung (Modified Condition/Decision Coverage), bei der jede Teilbedingung einer Verzweigung nachweislich das Ergebnis beeinflusst.

Die ISO 26262 regelt Safety, also den Schutz vor Fehlfunktionen. Den Schutz vor Angriffen auf Fahrzeuge regelt die ISO/SAE 21434, bei vernetzten Steuergeräten braucht man beide. Die Norm leitet sich aus der branchenübergreifenden Sicherheitsnorm IEC 61508 ab. Aktuell gilt die zweite Ausgabe von 2018, eine dritte Ausgabe ist in Arbeit und wird nicht vor 2027 erwartet.

Für Embedded DevOps prägt die Norm vor allem die Nachweisführung. Sie verlangt Traceability zwischen Anforderungen, Design, Code und Tests, festgelegte Abdeckungsmaße und lückenlose Dokumentation. In einer CI/CD-Pipeline lässt sich vieles davon bei jedem Build erzeugen: Die Pipeline aktualisiert die Verknüpfungen zwischen Anforderung, Code und Test, misst die Coverage und archiviert die Berichte. Liegt beim Assessment die Traceability-Matrix aus dem letzten Nightly-Build vor, muss niemand in der Woche davor Tabellen abgleichen.

Der teuerste Stolperstein ist nachträglich zusammengetragene Traceability. In der Praxis rekonstruiert ein Team wenige Wochen vor dem Assessment in Excel, welcher Test welche Anforderung abdeckt, und wiederholt das beim nächsten Release. Ebenso häufig fehlt die Werkzeugqualifizierung. Wirkt ein Tool auf den Sicherheitsnachweis ein, braucht es je nach Tool Confidence Level (TCL) eine Qualifizierung, sonst zählen seine Ergebnisse im Nachweis nicht. Und ein pauschal zu hoch angesetztes ASIL erzeugt Aufwand, den die Risikoanalyse nicht rechtfertigt.