ASIL - Automotive Safety Integrity Level

ASIL als Treiber für Aufwand und Nachweistiefe

In Projektdiskussionen wird ASIL oft als reine Klassifizierungsfrage behandelt: Diese Funktion ist ASIL B, jene ASIL D. Hinter der Einstufung stehen jedoch konkrete Konsequenzen für Aufwand, Methoden, Reviews und Nachweistiefe - und damit für Termine, Budgets und die spätere Argumentation im Safety Case.

ASIL steht für Automotive Safety Integrity Level. In der ISO 26262 ist ASIL kein dekoratives Label für ein System, sondern ein Risikoklassifikations- und Steuerkonzept. Es gibt an, wie streng und aufwendig funktionale Sicherheitsmaßnahmen umgesetzt, verifiziert und nachgewiesen werden müssen, um ein unangemessenes Sicherheitsrisiko zu vermeiden.

ASIL beschreibt das erforderliche Sicherheitsintegritätsniveau eines Safety Goals. Je höher der ASIL, desto stärker steigen Tiefe, Strenge, Unabhängigkeit und Nachweisumfang der sicherheitsrelevanten Entwicklungsaktivitäten.

Diese praktische Konsequenz macht ASIL für Projektplanung und Architekturentscheidungen so relevant. Eine Einstufung beeinflusst unter anderem:

• welche Reviews unabhängig durchgeführt werden müssen,
• welche Analysen notwendig sind,
• wie viel Traceability erwartet wird,
• wie Tool Confidence bewertet wird,
• wie belastbar die Verifikation dokumentiert sein muss.

Was ASIL bedeutet: QM bis ASIL D

Die HARA kann zu QM oder zu ASIL A, B, C oder D führen. QM bedeutet, dass für das betrachtete Safety Goal keine Aktivitäten der funktionalen Sicherheit nach ISO 26262 weitergeführt werden müssen; klassische Qualitätsmaßnahmen bleiben weiterhin relevant. ASIL A ist die niedrigste ASIL-Stufe, ASIL D die höchste.

Ein grobes Praxisbild hilft bei der Einordnung:

• QM: Standard-Qualitätsentwicklung ohne fortgeführte FuSi-Aktivitäten für dieses Safety Goal,
• ASIL A/B: fokussierter Mehraufwand, oft als Lean-Safety-Pfad wahrgenommen,
• ASIL C: deutlich erhöhte Systematik, strengere Reviews und formalere Nachweise,
• ASIL D: maximale Strenge, vollständige Absicherung, hohe Unabhängigkeit und besonders robuste Nachweisführung.

ASIL sagt dabei nichts über Performance, Komfort oder allgemeine Produktqualität aus. Ein ASIL-D-Safety-Goal bedeutet nicht, dass ein System per se ein höheres Restrisiko trägt als ein anderes. Es bedeutet, dass ein bestimmtes Risiko mit besonders hoher methodischer Strenge beherrscht werden muss.

ASIL entsteht in der HARA

Der ASIL wird im Rahmen der HARA bestimmt. Bewertet wird ein konkretes Hazardous Event: ein Hazard in einer definierten Betriebssituation, verursacht durch fehlfunktionales Verhalten des Items. Interne Sicherheitsmechanismen des Items werden dabei nicht berücksichtigt.

Die Einstufung entsteht aus Severity, Exposure und Controllability. Das ist keine mathematische Rechnung, sondern eine klassifizierende Bewertung anhand normativer Kategorien und einer ASIL-Matrix. Das Ergebnis wird anschließend dem Safety Goal zugewiesen.

Severity, Exposure und Controllability

Die drei Parameter beschreiben unterschiedliche Dimensionen des Risikos. In methodisch sauberen HARA-Workshops werden sie unabhängig voneinander bewertet und jeweils begründet dokumentiert.

Severity

Severity beschreibt die Schwere möglicher Verletzungen, wenn das Hazardous Event eintritt.

Klasse	Bedeutung
S0	Keine Verletzungen, typischerweise nur Sachschaden
S1	Leichte bis mittlere Verletzungen
S2	Schwere, lebensbedrohliche Verletzungen; Überleben wahrscheinlich
S3	Lebensbedrohliche oder tödliche Verletzungen; Überleben unsicher

Exposure

Exposure beschreibt die Häufigkeit der Betriebssituation oder des Szenarios. Es geht ausdrücklich nicht um die Häufigkeit eines internen Fehlers.

Klasse	Bedeutung
E0	Kein bzw. unglaubwürdiges Auftreten
E1	Sehr selten
E2	Selten
E3	Gelegentlich
E4	Häufig

Controllability

Controllability beschreibt, in welchem Maß ein durchschnittlicher Fahrer oder Verkehrsteilnehmer die gefährliche Situation beherrschen kann, ohne technische Gegenmaßnahmen des Items anzunehmen.

Klasse	Bedeutung
C0	Allgemein beherrschbar
C1	Einfach beherrschbar
C2	Normalerweise beherrschbar
C3	Schwer oder nicht beherrschbar

Ein einfaches Beispiel: S3, E2 und C3 führt gemäß der verwendeten Matrix zu ASIL B. S3, E4 und C3 führt zu ASIL D. Gerade Grenzfälle sollten im Workshop nicht nur entschieden, sondern nachvollziehbar begründet werden.

ASIL-Matrix: Kombination aus S, E und C

Die ASIL-Matrix übersetzt Severity, Exposure und Controllability in den finalen ASIL eines Safety Goals. Die folgende Darstellung zeigt die in der Strategie vorgegebene Einstufungslogik für S1 bis S3, C1 bis C3 und E1 bis E4. S0, E0 und C0 führen in der Praxis nicht zu einem ASIL-Pfad für funktionale Sicherheit.

Severity	Controllability	E1	E2	E3	E4
S1	C1	QM	QM	QM	QM
S1	C2	QM	QM	QM	A
S1	C3	QM	QM	A	B
S2	C1	QM	QM	A	B
S2	C2	QM	A	B	C
S2	C3	A	B	C	D
S3	C1	QM	A	B	C
S3	C2	A	B	C	D
S3	C3	B	C	D	D

Die Matrix macht sichtbar, warum kleine Bewertungsverschiebungen große Konsequenzen haben können. Eine andere Controllability oder Exposure kann aus QM einen ASIL-Pfad machen oder aus ASIL B ein ASIL C. Deshalb ist die Begründung der Parameter mindestens so wichtig wie das finale Ergebnis.

Normative Regeln, die im Projekt oft entscheidend sind

Einige normative Grundregeln entscheiden in der Praxis darüber, ob eine ASIL-Einstufung später Bestand hat oder im Review zerpflückt wird.

Erstens erfolgt die Bewertung konservativ. Bei begründeten Zweifeln wird die höhere Klasse gewählt. Das verhindert, dass Risiken im Workshop klein argumentiert werden, nur weil ein niedrigerer ASIL später weniger Aufwand erzeugen würde.

Zweitens werden Sicherheitsmechanismen des Items bei der HARA nicht berücksichtigt. Eine vorhandene Diagnose, Redundanz oder Abschaltstrategie kann später eine Maßnahme im Sicherheitskonzept sein, sie reduziert aber nicht die ursprüngliche HARA-Einstufung.

Drittens wird der ASIL dem Safety Goal zugewiesen, nicht dem Item insgesamt. Ein Item kann mehrere Safety Goals mit unterschiedlichen ASIL-Einstufungen haben. Werden Safety Goals zusammengefasst, gilt für die gemeinsame Betrachtung der höchste ASIL.

Viertens wird der ASIL entlang der Anforderungsableitung weitergeführt. Vom Safety Goal wird er auf Functional Safety Requirements (FSR), Technical Safety Requirements (TSR) im Technischen Sicherheitskonzept und weiter auf Hardware- und Softwareanforderungen heruntergebrochen. Diese Traceability muss über die gesamte Entwicklung nachvollziehbar sein.

Was ASIL in der Praxis auslöst

ASIL ist in der Praxis ein Steuerparameter für den Entwicklungsprozess. Je höher der ASIL, desto höher sind Entwicklungs-, Verifikations- und Nachweisaufwand.

Der Aufwand steigt unter anderem in diesen Bereichen:

• Verifikationsnachweise und Testtiefe,
• Diagnoseanforderungen und Fehlertoleranzzeiten,
• Hardware-Metriken und Hardware-Sicherheitsanalysen,
• Softwareanforderungen und methodischer Rigor,
• Traceability zwischen Safety Goals, Requirements, Architektur, Implementierung und Tests,
• Sicherheitsmechanismen und deren Wirksamkeitsnachweis,
• Architekturentscheidungen, Schnittstellen und HW/SW-Integration,
• Unabhängigkeit von Reviews, Confirmation Measures und Assessments,
• Tool Confidence und bei Bedarf Tool Qualification,
• Tiefe und Struktur des Safety Case.

Das bedeutet nicht, dass jedes ASIL-D-Projekt automatisch mehr Dokumentation als Selbstzweck braucht. Es bedeutet, dass Entscheidungen, Anforderungen, Analysen und Nachweise einer höheren methodischen Strenge standhalten müssen. Für Engineering-Leads ist ASIL daher auch eine Planungsgröße. Er beeinflusst:

• benötigte Kompetenzen,
• Review-Rollen,
• Toolketten,
• Lieferantensteuerung,
• Termin- und Nachweisrisiken.

ASIL ist kein Bauteil-Label

Ein verbreitetes Missverständnis lautet: “Diese ECU ist ASIL D.” Als grobe Alltagssprache kann das vorkommen, fachlich ist es jedoch unscharf. Der ASIL gehört zunächst zum Safety Goal und wird dann auf Anforderungen und zugeordnete Elemente weitergeführt.

Diese Unterscheidung ist projektrelevant. Wenn ein Steuergerät mehrere Funktionen enthält, können unterschiedliche Safety Goals unterschiedliche ASIL-Anforderungen auslösen. Manche Anforderungen sind sicherheitsrelevant, andere nicht. Manche Anforderungen tragen ASIL D, andere ASIL B, wieder andere QM. Ohne saubere Zuordnung wird unklar, welche Nachweise für welche Funktion notwendig sind.

Deshalb ist ASIL-Traceability ein Kernthema. Sie zeigt, welches Safety Goal welche FSR, TSR, Hardwareanforderung, Softwareanforderung, Architekturentscheidung, Testfälle und Nachweise treibt. Ohne diese Kette wird der Safety Case schwach, auch wenn einzelne Dokumente formal vollständig wirken.

ASIL-Dekomposition: Aufteilen durch Architektur

ASIL-Dekomposition ist ein normativ erlaubtes Mittel, um einen hohen ASIL-Sicherheitszielwert auf mehrere unabhängige Sicherheitsmaßnahmen mit niedrigerem ASIL aufzuteilen. Ziel ist nicht, Sicherheit abzuschwächen. Ziel ist, durch Redundanz und Unabhängigkeit die gleiche oder bessere funktionale Sicherheit architektonisch zu erreichen.

Ein Safety Goal mit hohem ASIL, etwa ASIL D, kann unter geeigneten Bedingungen durch zwei oder mehr voneinander unabhängige Maßnahmen adressiert werden, deren kombinierte Wirkung das ursprüngliche Risiko beherrscht. Entscheidend sind Unabhängigkeit und Wirksamkeit. In der Praxis geht es dabei um Freedom from Interference und Common Cause Avoidance.

Belastbare Praxisbeispiele sind:

• getrennte Sensorprinzipien,
• getrennte Recheninstanzen,
• zeitlich oder logisch getrennte Softwarepfade,
• unabhängige Diagnosen,
• klare Schnittstellen und dokumentierte Annahmen zur gegenseitigen Beeinflussung.

ASIL-Dekomposition ist damit kein Trick, um Aufwand loszuwerden. Sie ist ein Architekturkonzept zur Risikokontrolle. Sie muss begründet, nachvollziehbar und später technisch nachgewiesen werden. Genau deshalb gehört die konkrete Dekomposition typischerweise in die Architektur- und Mechanismenebene, also in das Technische Sicherheitskonzept, nicht in eine unklare Vorwegnahme in der HARA.

Merksatz: ASIL-Dekomposition ist erlaubt, wenn unabhängige Sicherheitsmechanismen gemeinsam das ursprüngliche Risiko beherrschen.

Häufige Missverständnisse

Vier Missverständnisse begegnen einem in ASIL-Diskussionen besonders häufig.

Das erste Missverständnis: ASIL D ist keine Aussage über die Gefahrenstufe eines Systems. ASIL beschreibt, wie streng ein sicherheitsrelevantes Risiko beherrscht werden muss, nicht wie gefährlich ein System als Ganzes ist. Ein System mit mehreren nachvollziehbar beherrschten ASIL-D-Safety-Goals kann reifer sein als ein System mit unscharfen ASIL-B-Anforderungen.

Das zweite Missverständnis: ASIL vererbt sich nicht blind. Der ASIL wird von Safety Goals auf Anforderungen und zugeordnete Systemelemente weitergeführt, aber diese Weiterführung braucht klare Traceability und fachliche Zuordnung. Nicht jedes Bauteil in der Nähe einer ASIL-D-Funktion wird automatisch vollständig ASIL D.

Das dritte Missverständnis: Eine QM-Einstufung reduziert nicht die fachliche Verantwortung für eine nachvollziehbare Bewertung. QM bedeutet, dass aus ISO-26262-Sicht für dieses Safety Goal keine funktionalen Sicherheitsaktivitäten fortgeführt werden. Qualitätsprozesse, Produktanforderungen, Robustheit und klassische Verifikation bleiben weiterhin relevant.

Das vierte Missverständnis: Ein niedrigerer ASIL ist kein Projektziel. Ein Projekt sollte Risiken korrekt klassifizieren, nicht Bewertungen optimieren. Wer ASIL künstlich niedrig hält, verschiebt Aufwand in spätere Diskussionen, Audits oder Fehlerbehebungen.

Wie Teams zu belastbaren ASIL-Entscheidungen kommen

Belastbare ASIL-Einstufungen entstehen nicht durch Tabellenlesen allein. Sie brauchen eine klare Item Definition, präzise beschriebene Hazardous Events, fachlich passende Betriebssituationen und eine moderierte Bewertung von S, E und C.

Strukturierte Workshops dokumentieren nicht nur das Ergebnis, sondern auch die Begründung. Warum ist Exposure E3 und nicht E4? Warum ist Controllability C2 und nicht C3? Welche Annahmen wurden getroffen? Welche Szenarien wurden bewusst zusammengefasst oder getrennt? Solche Entscheidungen sind später wertvoll, wenn Anforderungen abgeleitet, Lieferanten eingebunden oder Assessments vorbereitet werden.

ASIL beeinflusst den Entwicklungsweg früh. Eine saubere Einstufung schafft Planungssicherheit. Eine schwache Einstufung erzeugt Scheinsicherheit und kann später teurer werden als ein konservativer, nachvollziehbar begründeter Safety-Pfad.

Fazit

ASIL ist das Bindeglied zwischen Risiko und Entwicklungsstrenge. Er entsteht in der HARA aus der klassifizierenden Bewertung eines Hazardous Events über Severity, Exposure und Controllability und wird dem Safety Goal zugewiesen.

In der Praxis steuert ASIL Aufwand, Methodenrigor, Verifikation, Unabhängigkeit, Tool-Betrachtung, Traceability und Safety Case. Er ist kein Bauteil-Label und keine Aussage über allgemeine Systemqualität, sondern ein Sicherheitsintegritätsniveau für ein konkretes Safety Goal.

Wer ASIL sauber bestimmt und konsequent weiterführt, schafft eine belastbare Grundlage für Functional Safety Requirements, technische Architektur, Sicherheitsmechanismen und Freigaben. Wer ihn unscharf behandelt, verliert genau dort Klarheit, wo ISO 26262 Nachvollziehbarkeit verlangt.

In der Projektrealität entscheidet die ASIL-Einstufung früh über Aufwand, Verantwortlichkeiten und Argumentationslinien. Je sauberer Bewertung, Begründung und Weiterführung dokumentiert sind, desto stabiler tragen Safety Goals, Architektur und Nachweise - und desto belastbarer wirkt der Safety Case im Audit oder Assessment.