ISO 26262 & ASIL.
Sicherheit, nachweisbar.
ASIL (Automotive Safety Integrity Level) ist die Risikoklassifizierung der ISO 26262 für sicherheitsrelevante Fahrzeugfunktionen. Es gibt vier ASIL-Level: ASIL A (niedrigstes Risiko), ASIL B, ASIL C und ASIL D (höchstes — z. B. Bremse, Lenkung, Airbag), ergänzt um QM für Funktionen ohne Sicherheitsrelevanz; die Einstufung ergibt sich aus Schwere, Eintrittswahrscheinlichkeit und Beherrschbarkeit einer Gefährdung. Die ISO 26262 selbst ist der internationale Standard für funktionale Sicherheit elektrischer/elektronischer Systeme im Straßenfahrzeug. Die von ihr geforderten Nachweise — Testabdeckung, Traceability, Audit-Reports — lassen sich in der CI/CD-Pipeline automatisieren.
Ist die ISO 26262 bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Welche ASIL-Level gibt es?
Die ISO 26262 kennt vier ASIL-Level — ASIL A, ASIL B, ASIL C und ASIL D — sowie die Einstufung QM für Funktionen ohne Sicherheitsrelevanz. ASIL A ist die niedrigste, ASIL D die höchste Stufe. Mit jedem Level steigen die verbindlich geforderte Testtiefe, die Methodik und der Umfang der Nachweisführung.
Wie funktioniert die ASIL-Einstufung?
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.
ASIL-Tabelle: S, E und C zum ASIL-Level
Die ASIL-Tabelle nach ISO 26262-3 ordnet jeder Kombination aus Schwere, Exposition und Beherrschbarkeit genau ein Ergebnis zu. ASIL D entsteht ausschließlich aus der schärfsten Kombination S3 / E4 / C3 — alle übrigen Felder liegen darunter.
| Schwere | Exposition | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| S1 | E2 | QM | QM | QM |
| S1 | E3 | QM | QM | ASIL A |
| S1 | E4 | QM | ASIL A | ASIL B |
| S2 | E1 | QM | QM | QM |
| S2 | E2 | QM | QM | ASIL A |
| S2 | E3 | QM | ASIL A | ASIL B |
| S2 | E4 | ASIL A | ASIL B | ASIL C |
| S3 | E1 | QM | QM | ASIL A |
| S3 | E2 | QM | ASIL A | ASIL B |
| S3 | E3 | ASIL A | ASIL B | ASIL C |
| S3 | E4 | ASIL B | ASIL C | ASIL D |
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. Wer das einmal erlebt hat, kennt die Szene: Drei Wochen vor dem Termin sitzt das Team abends über einer Excel-Trace-Matrix, deren Anforderungs-IDs auf einen Softwarestand zeigen, den es so längst nicht mehr gibt. Jede manuell rekonstruierte Zeile ist Entwicklungszeit, die dem Projekt verloren geht.
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. Falls Ihre Matrix heute noch in Excel lebt: Damit sind Sie nicht allein, fast jedes Automotive-Team startet genau dort. Und der erste Merge, der eine vollständige, aktuelle Trace-Matrix als Build-Artefakt auswirft, ist für die meisten der Moment, in dem aus der Compliance-Last ein Nebenprodukt wird.
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. Auch die Frage des Assessors, warum das Compiler-Update mitten im Projekt die Nachweise nicht berührt hat, beantwortet sich dann aus der Pipeline heraus — nicht aus dem Gedächtnis der Beteiligten. Wie sich solche Nachweis-Pipelines mit Security-Gates kombinieren lassen, zeigt unsere Seite zu DevSecOps & Compliance. Die Prinzipien dahinter — Versionierung, automatisierte Gates und Deployments unter den Randbedingungen physischer Systeme — sind im Leitfaden zu Industrial DevOps zusammengefasst.
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.
Für was steht ASIL?
ASIL steht für Automotive Safety Integrity Level, auf Deutsch etwa „Automobil-Sicherheitsintegritätsgrad". Der Begriff stammt aus der ISO 26262 und bezeichnet die Risikoklasse, die einer sicherheitsrelevanten Fahrzeugfunktion zugeordnet wird. Aus dem ASIL leiten sich die verbindlichen Anforderungen an Entwicklungsmethoden, Testtiefe und Nachweisführung ab — je höher die Stufe, desto strenger.
Was sind die funktionalen Sicherheitsstufen (ASIL)?
Die funktionalen Sicherheitsstufen im Automotive-Bereich sind QM, ASIL A, ASIL B, ASIL C und ASIL D. Sie sind das Automotive-Pendant zu den SIL-Stufen (Safety Integrity Level) der IEC 61508, aus der die ISO 26262 abgeleitet ist — anders als SIL wird ASIL jedoch nicht allein aus der Ausfallwahrscheinlichkeit bestimmt, sondern zusätzlich aus der Beherrschbarkeit durch den Fahrer. Eine Funktion ohne Sicherheitsrelevanz erhält kein ASIL, sondern die Einstufung QM.
Was bedeutet ASIL B?
ASIL B ist die zweitniedrigste der vier ASIL-Stufen und steht für ein mittleres Sicherheitsrisiko — typisch für Funktionen wie Rückfahrkamera, Instrumentenanzeige oder Teile der Beleuchtung. Gefordert werden unter anderem Anforderungs- und Code-Reviews, strukturelle Testabdeckung auf Zweigebene (Branch Coverage) sowie eine dokumentierte Traceability. Der Sprung zu ASIL C und D betrifft vor allem Methodentiefe und Coverage-Maß, nicht die grundsätzliche Systematik.
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 bedeutet ASIL B(D), gesprochen „ASIL B von D"?
Die Schreibweise ASIL B(D) bezeichnet ein Element, das nach ASIL B entwickelt wird, aber aus einer ursprünglichen ASIL-D-Anforderung hervorgegangen ist. Sie entsteht durch ASIL-Dekomposition nach ISO 26262-9: Eine hohe Sicherheitsanforderung wird auf mehrere redundante, ausreichend unabhängige Elemente niedrigerer Stufe aufgeteilt — 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); fehlt er, gilt weiterhin die ursprüngliche Stufe in Klammern.
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.
Eine solche Pipeline zu bauen ist das eine — sie über einen Produktzyklus hinweg nachweisfähig zu halten, das andere. Toolchain-Updates, Zertifikate, Build-Agents, ausgeschiedene Kolleginnen und Kollegen: Die Nachweiskette reißt selten am Tag des Assessments, sondern in den Monaten davor. Wer den laufenden Betrieb nicht intern vorhalten will, gibt ihn als Managed CI/CD per SLA ab — inklusive der Auditierbarkeit, die ISO 26262 und TISAX verlangen.
Wenn Sie einordnen möchten, wie weit Ihre Pipeline von auditierbaren ISO-26262-Nachweisen entfernt ist: Ein 30-minütiges Erstgespräch kostet nichts und verpflichtet zu nichts — Sie entscheiden danach, ob mehr daraus wird.
Wie geht es bei Ihnen mit der ISO 26262 weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
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