Kostenlose DevOps-Analyse
Zurück zum Glossar
DevOps Glossar·Compliance

ISO 26262

// Direkte Antwort

Wofür steht ISO 26262?

Die ISO 26262 ist der Sicherheitsstandard für elektrische und elektronische Systeme in Straßenfahrzeugen. Sie fordert unter anderem nachweisbare Testabdeckung, Traceability zwischen Anforderungen und Tests sowie lückenlose Dokumentation — alles Aspekte, die sich in CI/CD-Pipelines automatisieren lassen.

ISO 26262 & ASIL in der CI/CD-Pipeline
// Im DetailISO 26262

Die ISO 26262 ist der internationale Standard für funktionale Sicherheit (Functional Safety) elektrischer und elektronischer Systeme in Straßenfahrzeugen. Sie leitet sich aus der allgemeinen Sicherheitsnorm IEC 61508 ab und konkretisiert deren Anforderungen für das Automobil. Ziel ist, das Risiko von Fehlfunktionen, die Personen gefährden könnten, über den gesamten Sicherheitslebenszyklus systematisch zu beherrschen — von der Konzeptphase über Entwicklung und Produktion bis zur Außerbetriebnahme. Wichtig zur Abgrenzung: Die ISO 26262 adressiert Safety (Schutz vor Fehlfunktionen), während die IEC 62443 die Security (Schutz vor Angriffen) industrieller Systeme regelt — beides ergänzt sich in modernen, vernetzten Fahrzeugen.

Zentrales Konzept ist das Automotive Safety Integrity Level (ASIL) von A bis D, das aus einer Gefährdungs- und Risikoanalyse abgeleitet wird. Es bewertet Schwere, Auftretenswahrscheinlichkeit und Beherrschbarkeit einer Fehlfunktion. ASIL D stellt die höchsten Anforderungen, etwa an sicherheitskritische Brems- oder Lenksysteme. Aus dem ASIL ergeben sich die geforderte Strenge von Entwicklungsmethoden, Testtiefe und Nachweisführung.

Für Embedded DevOps im Automotive-Umfeld ist die ISO 26262 stark prozessprägend. Sie verlangt durchgängige Traceability zwischen Anforderungen, Design, Code und Tests, definierte Testabdeckungsmaße (etwa MC/DC bei hohem ASIL) und lückenlose Dokumentation. Vieles davon lässt sich in CI/CD-Pipelines automatisieren: Anforderungs-Code-Test-Verknüpfungen werden bei jedem Build aktualisiert, Coverage-Metriken automatisch erhoben und Nachweise reproduzierbar archiviert — was den ansonsten enormen manuellen Dokumentationsaufwand drastisch reduziert.

Typische Stolpersteine: Traceability wird nachträglich von Hand zusammengetragen, was fehleranfällig und teuer ist. Oder Werkzeuge in der Toolchain sind nicht qualifiziert (Tool Confidence Level), sodass ihre Ergebnisse für den Sicherheitsnachweis nicht verwertbar sind. Außerdem wird ASIL gelegentlich pauschal zu hoch angesetzt, was unnötigen Aufwand erzeugt, statt die Einstufung sauber aus der Risikoanalyse abzuleiten.

// Beispiele aus der Praxis2 Szenarien
/01

Automatisierte Traceability in der Firmware-Pipeline

Ein Steuergeräte-Hersteller verknüpft Anforderungen, Code-Änderungen und Testfälle in der CI-Strecke, sodass die für ISO 26262 nötige Nachverfolgbarkeit bei jedem Build automatisch entsteht und als prüfbares Artefakt vorliegt.

/02

Coverage-Gate passend zum ASIL

Für ein ASIL-D-Modul erzwingt ein Quality Gate die geforderte MC/DC-Abdeckung. Unterschreitet ein Build die Schwelle, bricht die Pipeline ab — der geforderte Testumfang wird so kontinuierlich statt nur stichprobenartig sichergestellt.

// Häufige FragenFAQ
Was bedeuten die ASIL-Stufen A bis D?
Sie klassifizieren das Sicherheitsrisiko einer möglichen Fehlfunktion. Die Einstufung ergibt sich aus Schwere eines Schadens, Häufigkeit der Gefährdungssituation und Beherrschbarkeit durch den Fahrer. ASIL A ist die niedrigste, ASIL D die höchste Stufe mit den strengsten Anforderungen an Methoden und Nachweise.
Lässt sich ISO-26262-Konformität in einer CI/CD-Pipeline automatisieren?
Wesentliche Teile ja: Traceability, Coverage-Messung, statische Analyse und die Archivierung von Nachweisen lassen sich automatisieren und reproduzierbar machen. Die Risikoanalyse, ASIL-Einstufung und Sicherheitsargumentation bleiben jedoch fachliche, von Menschen verantwortete Tätigkeiten.
Wie hängt die ISO 26262 mit der Werkzeugqualifizierung zusammen?
Werkzeuge, deren Fehler einen Sicherheitsnachweis verfälschen könnten, müssen je nach Tool Confidence Level qualifiziert werden. Für CI/CD heißt das, dass auch Compiler, Test- und Analyse-Tools betrachtet werden müssen, damit ihre automatisiert erzeugten Ergebnisse im Sicherheitskontext verwertbar sind.
// Nächster Schritt

Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.

Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen
Seit 2006 · 47+ Projekte
Industrie · Automotive · Finance