ISO 26262 & ASIL.
Sicherheit, nachweisbar.
Die ISO 26262 ist der Standard für funktionale Sicherheit elektrischer/elektronischer Systeme im Straßenfahrzeug. Sie klassifiziert sicherheitsrelevante Funktionen über ASIL-Stufen (A bis D, plus QM) — abgeleitet aus Schwere, Eintrittswahrscheinlichkeit und Beherrschbarkeit einer Gefährdung. ASIL D ist die strengste Stufe (Bremse, Lenkung). Die geforderten Nachweise — Testabdeckung, Traceability, Audit-Reports — lassen sich in der CI/CD-Pipeline automatisieren.
Von QM bis ASIL D
Wie wird die ASIL-Stufe bestimmt?
Die ASIL-Einstufung entsteht in der Gefährdungsanalyse und Risikobewertung (HARA, Hazard Analysis and Risk Assessment) aus drei Parametern: Schwere der möglichen Verletzung (S), Eintrittswahrscheinlichkeit der Fahrsituation (E) und Beherrschbarkeit durch den Fahrer (C). Die Kombination der drei Werte ergibt nach der Zuordnungstabelle in ISO 26262-3 die Stufe — von QM bis ASIL D.
Wie schwer sind die möglichen Verletzungen? S0 = keine Verletzungen, S3 = lebensbedrohliche bis tödliche Verletzungen.
Wie häufig tritt die Fahrsituation auf, in der die Fehlfunktion gefährlich wird? E1 = sehr selten, E4 = hohe Wahrscheinlichkeit im Normalbetrieb.
Kann ein durchschnittlicher Fahrer die Situation noch abfangen? C1 = einfach beherrschbar, C3 = schwer oder gar nicht beherrschbar.
Beispiel elektrische Servolenkung: Fällt die Lenkunterstützung bei Autobahngeschwindigkeit schlagartig aus, drohen lebensbedrohliche Unfälle (S3), die Fahrsituation ist alltäglich (E4), und ein durchschnittlicher Fahrer kann den plötzlichen Kraftsprung kaum kompensieren (C3) — Ergebnis: ASIL D. Eine fehlerhafte elektrische Sitzverstellung im Stand landet dagegen bei QM: Sie verletzt niemanden, der Fahrer kann jederzeit loslassen.
Wichtig für die Architektur: Über ASIL-Dekomposition lässt sich eine ASIL-D-Anforderung auf redundante, unabhängige Pfade niedrigerer Stufe aufteilen — das reduziert den Methodenaufwand pro Komponente, verlangt aber den Nachweis der Rückwirkungsfreiheit (Freedom from Interference).
Was gehört in eine ISO-26262-konforme CI/CD-Pipeline?
Eine ISO-26262-konforme Pipeline verankert die geforderten Verifikationsmethoden als automatische Quality Gates: statische Analyse nach MISRA C, Unit-Tests mit struktureller Coverage (bis MC/DC für ASIL D), Integrations- und HiL-Tests, eine generierte Traceability-Matrix und signierte Reports. Jeder Merge erzeugt damit auditierbare Nachweise — statt einer Dokumentationswelle kurz vor dem Assessment.
pipeline (vereinfacht, Ziel: ASIL D) ├── 01 static-analysis MISRA-C-Prüfung — 0 offene Violations als Gate ├── 02 unit-tests MC/DC-Coverage gegen Zielwert, Report archiviert ├── 03 integration-tests Schnittstellen gegen die Software-Architektur ├── 04 hil-tests Fehlerinjektion am HiL-Prüfstand (nightly) ├── 05 trace-matrix Anforderung → Code → Test, automatisch generiert └── 06 sign-and-archive Reports signieren, Build reproduzierbar ablegen
Entscheidend ist die Reihenfolge der Gates: Statische Analyse und Unit-Coverage laufen bei jedem Commit und brechen den Build hart ab, teure HiL-Läufe mit Fehlerinjektion nightly. Die Traceability-Matrix wird nicht in Excel gepflegt, sondern aus Anforderungs-IDs in Commits und Test-Annotationen generiert — so kann sie gar nicht erst veralten.
Dazu kommt die Tool-Qualifizierung nach ISO 26262-8: Jedes Werkzeug der Kette wird klassifiziert, ob ein Werkzeugfehler unentdeckt einen Produktfehler verursachen könnte. Eine Pipeline mit redundanten, voneinander unabhängigen Prüfungen senkt das nötige Tool Confidence Level — ein oft übersehener Vorteil der Automatisierung. Wie sich solche Nachweis-Pipelines mit Security-Gates kombinieren lassen, zeigt unsere Seite zu DevSecOps & Compliance.
ASIL über Gefährdungsanalyse bestimmen
Aus Schwere (S), Eintrittswahrscheinlichkeit (E) und Beherrschbarkeit (C) der Gefährdung ergibt sich die ASIL-Einstufung A–D je sicherheitsrelevanter Funktion.
Anforderungen versionieren
Sicherheitsanforderungen in Git ablegen und mit Tests verknüpfen, damit jede Änderung nachvollziehbar und auditierbar bleibt — Grundlage für Traceability.
Testabdeckung automatisieren
Unit-, Integrations- und HiL-Tests in der CI/CD-Pipeline mit ASIL-gerechten Coverage-Zielen (z. B. MC/DC für ASIL D) als Quality Gate verankern.
Traceability-Matrix generieren
Verknüpfung Anforderung → Design → Code → Test automatisiert aus der Pipeline erzeugen, statt sie manuell in Excel zu pflegen.
Audit-Artefakte signieren
Reports, Coverage-Nachweise und Trace-Matrix als signierte, reproduzierbare Build-Artefakte ablegen — bereit für das Assessment.
Was ist die ISO 26262?
Die ISO 26262 ist der internationale Standard für funktionale Sicherheit (Functional Safety) von elektrischen und elektronischen Systemen in Straßenfahrzeugen. Sie leitet sich aus der allgemeinen Sicherheitsnorm IEC 61508 ab und definiert einen Sicherheitslebenszyklus über Entwicklung, Produktion und Betrieb — mit nachweisbarer Testabdeckung, Traceability und Dokumentation.
Was bedeuten die ASIL-Stufen A bis D?
ASIL (Automotive Safety Integrity Level) klassifiziert das Risiko einer Funktion. Die Einstufung ergibt sich aus Schwere, Eintrittswahrscheinlichkeit und Beherrschbarkeit einer Gefährdung. ASIL A ist die niedrigste, ASIL D die höchste Stufe — letztere gilt für Funktionen wie Bremse, Lenkung oder Airbag und verlangt die strengsten Nachweise. Funktionen ohne Sicherheitsrelevanz laufen als QM.
Was bedeutet ASIL D konkret für die Entwicklung?
ASIL D fordert die höchste Methodentiefe: strukturelle Code-Coverage bis MC/DC, Fehlererkennungsmechanismen, oft Redundanz, strikte Reviews und lückenlose Traceability zwischen Anforderungen, Design, Code und Tests. Genau diese Nachweise lassen sich am wirksamsten automatisiert in der CI/CD-Pipeline erzeugen.
Wie passt ISO 26262 mit dem V-Modell zusammen?
ISO 26262 folgt einem V-Modell: Auf der linken Seite Anforderungen und Design, auf der rechten Seite die zugehörigen Verifikations- und Validierungsschritte. Jede Anforderung braucht einen korrespondierenden Test. CI/CD automatisiert die rechte Seite und macht die Verknüpfung über eine Traceability-Matrix sichtbar.
Lassen sich ISO-26262-Nachweise in CI/CD automatisieren?
Ja — und das ist der größte Hebel. Testabdeckung, statische Analyse (MISRA), Traceability-Matrix und signierte Audit-Reports lassen sich als Quality Gates in die Pipeline integrieren. So entsteht der Sicherheitsnachweis bei jedem Build, statt mühsam vor dem Assessment zusammengetragen zu werden.
Was ist der Unterschied zwischen ISO 26262 und ASPICE?
ISO 26262 adressiert die funktionale Sicherheit (was ein System sicher macht), Automotive SPICE (ASPICE) bewertet die Reife des Entwicklungsprozesses (wie diszipliniert entwickelt wird). In der Praxis greifen beide ineinander: ASPICE-konforme Prozesse liefern die Disziplin, ISO 26262 die sicherheitsspezifischen Anforderungen.
Was ist ASIL-Dekomposition?
ASIL-Dekomposition (ISO 26262-9) teilt eine hohe Sicherheitsanforderung auf mehrere redundante, ausreichend unabhängige Elemente mit niedrigerer Stufe auf — etwa ASIL D in zwei Pfade ASIL B(D) + ASIL B(D). Das senkt den Methodenaufwand pro Element, verlangt aber den Nachweis der Unabhängigkeit (Freedom from Interference), sonst gilt weiterhin die ursprüngliche Stufe.
Müssen CI/CD-Tools wie Jenkins nach ISO 26262 qualifiziert werden?
Nicht pauschal. ISO 26262-8 (Kapitel 11) verlangt eine Tool-Klassifizierung: Kann ein Werkzeugfehler einen Fehler ins Produkt einbringen oder dessen Entdeckung verhindern, ergibt sich daraus ein Tool Confidence Level (TCL 1–3). Orchestrierer wie Jenkins oder GitLab CI kommen oft mit TCL 1 davon, wenn nachgelagerte Gates (Tests, Reviews, Prüfsummen) Werkzeugfehler aufdecken würden — Compiler oder Codegeneratoren brauchen dagegen meist eine Qualifizierung.
Verwandte Artikel
DevSecOps für die Industrie & IEC 62443
Security-Gates und Zonen-Modell in industriellen CI/CD-Pipelines.
ASPICE: Automotive SPICE einfach erklärt
Prozessreife-Bewertung für die Automotive-Softwareentwicklung.
TIA Portal mit Git versionieren
Mergefähige SPS-Quelltexte als Basis für Traceability und Audits.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance