ASIL-D Funktionale Sicherheit: vom Konzept bis zur Tool-Qualifizierung.

1. Warum ASIL-D anders ist

Die meisten ASIL-Diskussionen beginnen am falschen Ende. Teams entwerfen ein Item, führen eine HARA durch, sehen ein „D“ herauskommen und greifen sofort zur ASIL-Dekomposition, um die Teile auf etwas Handhabbareres herunterzubrechen. Das ist oft legitim. Aber dort liegt nicht der eigentliche ASIL-D-Aufwand.

Der eigentliche Aufwand liegt in der Prozessdisziplindie ISO 26262 auf ASIL-D-Arbeitsprodukte anwendet: die zusätzlichen Bestätigungsreviews gemäß Tabelle 1, die höheren Abdeckungsziele gemäß Teil 6, die strengeren Unabhängigkeitsanforderungen zwischen erstellenden und prüfenden Teams sowie die Werkzeugqualifizierungs-Nachweise für jedes Tool, dessen Ausgabe im Safety Case landet.

Aus unserer Erfahrung mit Tier-1-Antriebsstrang-Programmen (BMS, PTC, EV-Steuergeräte, Lenkung) scheitern die Projekte, die das ASIL-D-Audit nicht bestehen, nicht am Design der Sicherheitsmechanismen. Sie scheitern an der Werkzeugqualifizierung, an fehlenden Bestätigungsreviews und daran, dass der Safety Case ein Ordner voller Dokumente ist statt einer kohärenten Argumentation im GSN-Stil.

2. Was die Konzeptphase tatsächlich verlangt

Item-Definition (ISO 26262-3 §5)

Das am stärksten unterinvestierte Arbeitsprodukt im gesamten Safety Case, und dasjenige, das Sie nachgelagert am meisten kostet, wenn es dünn ausfällt. Die Norm verlangt vier Dinge:

• Funktionalität & Verhalten des Items (einschließlich fehlerhaften Verhaltens).
• Grenze und Schnittstellen zu anderen Items / Fahrzeugsystemen.
• Betriebsumgebung (einschließlich Annahmen über Fahrer, Straße, Klima).
• Abhängigkeiten von anderen Items.

Der häufigste Fehler, den wir sehen: Die Item-Definition behandelt das Steuergerät als Black Box, die „die Funktion erfüllt“. Die HARA muss dann Kategorien fehlerhaften Verhaltens aus dem Nichts erfinden. Der Assessor wird das zurückweisen. Investieren Sie hier in einen Katalog fehlerhaften Verhaltens, verankert an den tatsächlichen Fehlermodi der Hardware (z. B. Stuck-at, Oszillation, Drift, falsche Größe, falsches Vorzeichen, falsches Timing), und Sie sparen nachgelagert Wochen.

HARA (ISO 26262-3 §6)

Drei Größen bestimmen den ASIL: Schweregrad (S0-S3), Eintrittswahrscheinlichkeit/Exposition (E0-E4), Beherrschbarkeit (C0-C3). Die Tabelle in 3-Anhang A bildet diese auf den ASIL ab. ASIL-D erfordert das Schlimmste aller drei. Zwei häufige Fehldeutungen:

• Exposition mit der Häufigkeit der Fahrzeugnutzung verwechseln. Die Exposition ist die Dauer, während der die Betriebssituation vorliegt. Schnelles Fahren auf der Autobahn ist E4 (hoch), weil Fahrzeuge routinemäßig große Anteile ihrer Betriebszeit bei Autobahngeschwindigkeit verbringen. Exposition ist nicht „fährt dieses Fahrzeug jemals auf der Autobahn?“
• Beherrschbarkeit als „durchschnittlicher Fahrer“ auslegen. ISO 26262 definiert Beherrschbarkeit gegenüber einer repräsentativen Fahrerpopulation einschließlich Nicht-Experten. Wenn Sie Ihrer Großmutter nicht zutrauen würden, die Situation in 99 % der Fälle zu beherrschen, ist es kein C2.

Funktionales Sicherheitskonzept (ISO 26262-3 §7)

Drei Teil-Arbeitsprodukte:

• Sicherheitsziele (aus der HARA, eines pro Gefährdungsereignis, das Sie zu mindern beschlossen haben).
• Sichere Zustände & fehlertolerante Zeitspannen (FTTI).
• Funktionale Sicherheitsanforderungen (FSR), zugeordnet zu Architekturelementen.

Das Arbeitsprodukt, das Assessoren tatsächlich zuerst lesen, ist die FTTI-Argumentation. Wenn Ihre FTTI lautet „200 ms, weil uns das vernünftig erscheint“, werden Sie aufgefordert, das zu belegen. Dokumentieren Sie die Analyse (typisch: Reaktionszeit des Fahrers + Fahrzeugdynamik + Periode der Regelschleife).

3. Wo ASIL-Dekomposition legitim ist

ISO 26262-9 §5 legt die Regeln fest. Die Dekomposition teilt eine ASIL-D-Anforderung auf zwei hinreichend unabhängige Elemente auf, sodass jedes auf einem niedrigeren ASIL entwickelt werden kann (typisch D → B + B oder D → C + A). Das Zauberwort ist Unabhängigkeit.

In der Praxis stellt der Assessor drei Fragen:

1. Was bedeutet „unabhängig“ für diese Elemente? (Unterschiedliche Kerne? Unterschiedliche Spannungsdomänen? Unterschiedliche Codepfade? Unterschiedliche Sicherheitsmechanismen?)
2. Zeigen Sie mir die Analyse abhängiger Ausfälle (DFA, ISO 26262-9 §7), die beweist, dass kein Ausfall gemeinsamer Ursache die Dekomposition aushebelt.
3. Zeigen Sie mir die Architekturargumentation, dass die beiden dekomponierten Anforderungen zusammen die ursprüngliche ASIL-D-Anforderung erfüllen.

Wenn Sie nicht alle drei beantworten können, hält die Dekomposition nicht stand. Wir sehen das bei rund 60 % der erstmaligen ASIL-D-Einreichungen scheitern, in die wir zur Audit-Vorbereitung hineingerufen werden.

4. Hardware: FMEDA und die Metriken

ISO 26262-5 führt drei für ASIL-D relevante Hardware-Metriken ein:

• SPFM (Single Point Fault Metric), ≥ 99 % für ASIL-D.
• LFM (Latent Fault Metric), ≥ 90 % für ASIL-D.
• PMHF (Probabilistic Metric for random Hardware Failure), < 10⁻⁸ /h.

Alle drei ergeben sich aus der FMEDA. Die FMEDA selbst ist nicht schwierig, sobald Ihr Inventar der Sicherheitsmechanismen und Ihre Annahmen zur Diagnoseabdeckung gut dokumentiert sind. Die Falle: Die Werte der Diagnoseabdeckung stammen aus den Annahmen Ihres Hardware-Entwicklers und müssen belegt werden. Ein Auditor pickt sich drei zufällige Sicherheitsmechanismen heraus und bittet Sie, den zugewiesenen DC-Wert zu verteidigen. Wenn Ihre Antwort lautet „das Datenblatt des Lieferanten nennt 90 %“, ist das oft akzeptabel. Wenn sie lautet „wir haben angenommen“, nicht.

5. Software: die SWE.x-Klauseln, die Sie nicht überspringen können

ISO 26262-6 schreibt strukturelle Abdeckungsziele je ASIL vor. Bei ASIL-D:

• Anweisungsüberdeckung (Statement Coverage): dringend empfohlen → faktisch erforderlich.
• Zweigüberdeckung (Branch Coverage): dringend empfohlen.
• MC/DC (Modified Condition / Decision Coverage): dringend empfohlen.

Die Kombination aus Zweigüberdeckung + MC/DC ist der Punkt, an dem die meisten Teams zu wenig investieren. Tools wie Matlab / Simulink Test oder kommerzielle Formal-Verifikations-Suiten bewältigen das auf der Modellseite; für handgeschriebenen C-Code benötigen Sie ein Tool für strukturelle Abdeckung, das in Ihre Verifikations-Toolchain integriert ist. Die Werkzeugqualifizierung des Abdeckungstools ist ein verpflichtender Nachweis in Ihrem Safety Case.

6. Werkzeugqualifizierung, der stille Killer

ISO 26262-8 §11 behandelt die Werkzeugqualifizierung. Für jedes Tool, dessen Ausgabe im Safety Case landet (Autocoder, Tools für statische Analyse, Tools für Testgenerierung, Anforderungsmanagement-Tools, die Traceability speisen), müssen Sie den Tool-Vertrauensgrad (TCL1, TCL2, TCL3) auf Basis von Tool Impact (TI) und Tool error Detection (TD) klassifizieren.

• TCL1keine Qualifizierung erforderlich.
• TCL2 oder TCL3Qualifizierung erforderlich, mit Methoden, die mit dem ASIL skalieren.

Der häufigste Audit-Befund, den wir in 8 Jahren FuSa-Arbeit gesehen haben: Autocoder in der Serie eingesetzt, ohne Werkzeugqualifizierungs-Nachweis im Safety Case. Entweder lieferte der Tool-Hersteller des Kunden ein Tool Qualification Kit (TQK), das im Safety Case des Projekts nicht referenziert wurde, oder der Autocoder war für einen anderen ASIL qualifiziert als das Projekt erfordert. Beides sind Befunde, die der Auditor beanstanden wird.

7. Bestätigungsreviews, Tabelle 1 der ISO 26262-2

ISO 26262-2 §6.4.7 schreibt eine Matrix von Bestätigungsmaßnahmen vor (Konfigurationsreview, Verifikationsreviews, Bestätigungsreviews, Funktionale-Sicherheits-Audit, Funktionale-Sicherheits-Assessment) mit dem jeweils erforderlichen Unabhängigkeitsgrad je ASIL. Bei ASIL-D erfordern mehrere Reviews eine „I3“-Unabhängigkeit, durchgeführt von einer Organisation, die sich von der entwickelnden unterscheidet.

Wir sehen zwei häufige Kompromisse:

• Der Kunde (OEM) führt das I3-Review durch, und Sie nehmen an, das genüge. Oft tut es das, aber Sie brauchen es schriftlich in der Kundenvereinbarung.
• Eine interne „unabhängige Abteilung“ führt das Review durch, doch dieselbe Person hat eine gestrichelte Berichtslinie zum Projektleiter. Das ist bestenfalls I2, nicht I3.

8. Der Safety Case, Argumentation, kein Ordner

Der Safety Case ist das Dokument, mit dem der Assessor die meiste Zeit verbringt. Behandeln Sie ihn als Ordner voller Arbeitsprodukte, und Sie erhalten eine lange Liste von Befunden; behandeln Sie ihn als strukturierte Argumentation, und Sie kommen schneller durch.

Die Struktur, die wir verwenden:

• Top-Level-Claim: „Item X ist für seine definierte Betriebsumgebung gemäß ISO 26262 hinreichend sicher.“
• Zerlegung in Teil-Claims: Sicherheitsziele erreicht, Gefährdungen gemindert, Restrisiko akzeptabel.
• Für jeden Teil-Claim: eine explizite Argumentation (warum die Nachweise ausreichen) und Verweise auf die Nachweise (HARA, FSC, TSC, FMEDA, Verifikationsberichte, Bestätigungsreviews).

Goal Structuring Notation (GSN) ist hierfür der De-facto-Standard. ISO 26262 verlangt sie nicht, aber Assessoren akzeptieren sie als das sauberste Argumentationsformat.

9. Wo wir ASIL-D-Programme scheitern gesehen haben

Fünf wiederkehrende Muster aus unseren letzten 12 Tier-1-Audit-Vorbereitungen:

• Dekomposition ohne DFA (~60 % der Einreichungen). Die Dekomposition liest sich auf dem Papier gut, aber die DFA fehlt oder deckt die tatsächlichen Ausfälle gemeinsamer Ursache nicht ab.
• Lücken bei der Werkzeugqualifizierung (~50 %). Besonders bei Autocodern und Tools für strukturelle Abdeckung.
• Annahmen zur Diagnoseabdeckung nicht belegt (~45 %). Die FMEDA-Arithmetik stimmt, aber die DC-Werte je Mechanismus lassen sich unter Nachfragen nicht verteidigen.
• Unabhängigkeit der Bestätigungsreviews nicht dokumentiert (~40 %). Reviews fanden statt, aber der I-Grad lässt sich aus der Organisationsstruktur nicht nachweisen.
• Safety Case ist ein Ordner, keine Argumentation (~70 %). Nachweise existieren, sind aber nicht zu einer verteidigbaren Top-Level-Claim-Struktur synthetisiert.

10. Was in den nächsten 30 Tagen zu tun ist, wenn Sie auf ein ASIL-D-Audit zusteuern

1. Lesen Sie Ihre Item-Definition und HARA erneut. Wenn Sie den Katalog fehlerhaften Verhaltens nicht benennen und die E- und C-Einstufungen nicht verteidigen können, beheben Sie das zuerst.
2. Auditieren Sie Ihre Werkzeugqualifizierungs-Nachweise. Listen Sie jedes Tool, seinen TCL, seinen Qualifizierungsstatus, seine TQK-Referenz. Finden Sie die Lücken jetzt.
3. Prüfen Sie die Unabhängigkeit der Bestätigungsreviews auf dem Papier. Ordnen Sie jede Zeile aus Tabelle 1 einer realen Person oder Organisation zu; prüfen Sie, ob der I-Grad hält.
4. Verteidigen Sie drei zufällige FMEDA-DC-Werte. Wenn Sie das nicht können, wartet bereits ein Befund auf Sie.
5. Strukturieren Sie den Safety Case als Argumentation. Wenn Sie GSN haben, auditieren Sie sie. Falls nicht, schreiben Sie den Top-Level-Claim und 5-7 Teil-Claims und verknüpfen Sie die Nachweise mit jedem.

---

Möchten Sie einen 30-minütigen Walkthrough zu Ihrem Projekt?

Keine NDA nötig. Sagen Sie uns, welcher ASIL, welches Item, welcher Assessor, welche Deadline. Innerhalb von 48 Stunden erhalten Sie eine einseitige Diagnose, abgebildet auf die obigen Klauseln, Ihre, ob Sie uns beauftragen oder nicht.

FuSa-Walkthrough buchen →

---

Autor: Adrian Valea, Gründer & Geschäftsführer, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Veröffentlicht 2026-05-25.