ISO 26262 in der Praxis — Was ASIL-B wirklich bedeutet für Embedded-C-Code

Wer im Automotive-Umfeld entwickelt, kennt die Stempel auf jedem Lastenheft: QM, ASIL-A, ASIL-B, ASIL-C, ASIL-D. Das Kürzel steht für „Automotive Safety Integrity Level" und stammt aus der ISO 26262 — der Norm für funktionale Sicherheit im Straßenfahrzeug. Zwischen QM und ASIL-D liegt ein Universum an Prozessaufwand, Dokumentationsumfang und Entwicklungskosten.

In der Praxis ist ASIL-B der häufigste Level, mit dem Seriensteuergeräte eingestuft werden. Motorsteuerungen, Bremsenelektronik, Kamera-Vorverarbeitung, Batteriemanagement — vieles davon ist ASIL-B. Und genau da wird es für den C-Entwickler konkret.

Dieser Artikel beschreibt, was ASIL-B in Projekten, an denen ich mitgearbeitet habe, tatsächlich bedeutet hat — jenseits der Norm-Zitate. Keine Theorie, sondern die Stolpersteine und das, was im Audit zählt.

Was ASIL-B aus der Norm heraus fordert

Die ISO 26262-6 (Product Development at the Software Level) definiert Tabellen mit „highly recommended", „recommended" und „no recommendation" je Aktivität und ASIL-Stufe. Für ASIL-B bedeutet das in Kurzform:

• Coding-Richtlinien: MISRA-C ist praktisch gesetzt (Tabelle 1 der Norm: „highly recommended")
• Statische Code-Analyse: highly recommended
• Code-Review: highly recommended, inklusive Reviewer mit geeignetem Know-how
• Unit-Tests mit Branch Coverage: highly recommended (Statement Coverage allein reicht nicht)
• Integrationstests: highly recommended
• Fehlerinjektion: recommended
• Defensive Programmierung: highly recommended

Und — wichtig — jedes verwendete Tool, das Einfluss auf den Code nehmen kann (Compiler, Code-Generator, Testframework), muss gemäß ISO 26262-8 qualifiziert oder klassifiziert werden. Dazu später mehr.

MISRA-C: Der unterschätzte Türsteher

MISRA-C ist kein Feind des C-Entwicklers — auch wenn die rund 170 Regeln und Direktiven der aktuellen MISRA-C:2012 anfangs überwältigend wirken. Die meisten Regeln sind schlicht vernünftig: keine impliziten Konvertierungen, keine goto-Sprünge rückwärts, kein Schatten von Variablennamen, kein Dynamic Memory.

Was die Sache in der Praxis schwierig macht, ist etwas anderes: MISRA unterscheidet zwischen Required, Advisory und Mandatory. Und jede Abweichung braucht eine formale Deviation — einen schriftlich begründeten, reviewten und vom Sicherheitsverantwortlichen abgesegneten Einzelfall.

„Wir hatten in einem Projekt etwa 400 Deviations zum Abschluss. Jede einzelne brauchte eine Begründung, eine Analyse der Auswirkung auf die Sicherheit und eine Gegenzeichnung. Das ist kein Papiertiger — das ist echte Arbeit."

Typische Fallen:

• Regel 10.x (Implizite Konvertierungen): In Bitmanipulation fast unvermeidbar. Jede uint8_t a = b & 0x0F;-artige Zeile wird kritisch geprüft.
• Regel 11.x (Pointer-Konvertierungen): Hardware-Zugriff braucht fast immer Pointer-Casting. Lösbar, aber dokumentationspflichtig.
• Regel 21.3 (kein dynamischer Speicher): Oft überraschend — auch statische Strukturen mit Pointern werden manchmal beanstandet, wenn der Lifecycle nicht sauber dokumentiert ist.

Praktische Empfehlung

Wer ASIL-B-Code von Grund auf plant, sollte MISRA von Anfang an mitdenken. Nachträglich eine bestehende Code-Basis MISRA-konform zu machen, ist drei- bis fünfmal teurer als es gleich richtig zu machen. Tools wie Polyspace, LDRA oder Helix QAC prüfen automatisch — aber 100% automatisch ist keine Regel prüfbar. Manche Regeln brauchen menschliches Urteil.

Statische Analyse ist mehr als ein grüner Haken

Die Norm verlangt statische Analyse — das wird oft falsch verstanden als „MISRA-Checker laufen lassen". Tatsächlich meint ISO 26262 deutlich mehr:

• Control-Flow-Analyse: Finde alle unerreichbaren Codepfade.
• Data-Flow-Analyse: Finde verwendete, aber nicht initialisierte Variablen.
• Abstrakte Interpretation: Finde potenzielle Array-Überläufe, Division durch Null, Integer-Overflows.
• Semantische Analyse: Finde Race Conditions in Interrupts, Datenabhängigkeiten über Modulgrenzen hinweg.

Tools wie Polyspace Code Prover machen die ersten drei Punkte formal beweisbar — nicht nur heuristisch. Das Werkzeug durchläuft alle möglichen Ausführungspfade und färbt jeden Operator grün (sicher), rot (Fehler) oder orange (konnte nicht entschieden werden). Orange ist der Feind: jede einzelne Stelle muss manuell analysiert werden.

Testabdeckung: Statement Coverage reicht nicht

ASIL-B fordert laut ISO 26262-6 Tabelle 12 mindestens Branch Coverage auf Unit-Ebene. Für ASIL-C und ASIL-D kommt MC/DC-Coverage (Modified Condition/Decision Coverage) dazu.

Der Unterschied ist wichtig:

Coverage-Typ	Was wird geprüft	ASIL-Level
Statement Coverage	Jede Anweisung wird mindestens einmal ausgeführt	QM, A
Branch Coverage	Jeder Zweig (if/else) wird in jede Richtung durchlaufen	B
MC/DC	Jede Bedingung in einer Verknüpfung wird unabhängig wirksam	C, D

Ein kleines Beispiel zur Verdeutlichung:

if (sensor_ok && (drehzahl > 1000)) {
    aktion_ausloesen();
}

Für Statement Coverage reicht ein Testfall, in dem beide Bedingungen wahr sind und aktion_ausloesen() gerufen wird.

Für Branch Coverage braucht man zusätzlich einen Testfall, in dem die Gesamtbedingung falsch ist — egal welcher der beiden Teile den Ausschlag gibt.

Für MC/DC muss man zeigen: Beide Teilbedingungen beeinflussen das Ergebnis unabhängig voneinander. Das braucht in diesem Fall drei Testfälle. Bei Verknüpfungen mit fünf, sechs Teilbedingungen explodiert die Zahl der nötigen Testfälle.

Praktische Konsequenz

ASIL-B-Unit-Tests sind umfangreich, aber handhabbar. Tools wie Cantata, VectorCAST oder TestWell CTC++ instrumentieren den Code und messen Coverage auf Objektcode-Ebene. Man braucht typischerweise 3–5 Testfälle pro Funktion.

Beim Sprung auf ASIL-D (Fahrspurhalte-Assistent, Airbag-Auslösung) wird es schmerzhaft: 8–20 Testfälle pro Funktion, viele davon mit kreativen Eingabewerten, um MC/DC-Lücken zu schließen.

Defensive Programmierung: Was heißt das konkret?

Die ISO 26262 fordert defensive Programmierung ohne genau zu sagen, was das ist. In der Automotive-Praxis haben sich einige Muster durchgesetzt:

Eingangsparameter prüfen

void set_drehzahl(uint16_t rpm)
{
    if (rpm > MAX_DREHZAHL) {
        rpm = MAX_DREHZAHL;   /* clamp statt fehlschlagen */
        /* Optional: Fehlerspeicher-Eintrag */
    }
    /* ... */
}

Nicht etwa einen Assertion-Fehler auslösen — das bringt das Fahrzeug zum Stillstand. In ASIL-B-Code wird fehlerhafte Eingabe meist maskiert und optional geloggt.

Plausibilitätsprüfungen zur Laufzeit

uint32_t temperatur_sensor_lesen(void)
{
    uint32_t t_raw = adc_read(TEMP_KANAL);

    if ((t_raw < TEMP_MIN_RAW) || (t_raw > TEMP_MAX_RAW)) {
        fehler_setzen(FEHLER_TEMP_SENSOR);
        return TEMP_DEFAULT;   /* Rückfallwert */
    }
    return t_raw;
}

Keine unendlichen Schleifen

Jede while(1)-Schleife (außer im Haupt-Task-Scheduler) braucht einen Timeout-Zähler. Jede do..while einen sauberen Ausgang.

Watchdog nicht nur am Anfang und Ende

Ein typischer Anfängerfehler: Watchdog-Trigger vor und nach dem Haupt-Task. Besser: innerhalb langer Operationen mit mehreren Triggerpunkten, sodass ein blockierter Task erkannt wird.

Tool-Qualifizierung: Der oft übersehene Aufwand

Jedes Werkzeug, dessen Ausgabe in das Produkt einfließt, muss nach ISO 26262-8 bewertet werden. Das betrifft:

• Compiler (GCC, IAR, Green Hills)
• Code-Generatoren (Simulink Embedded Coder, TargetLink)
• Assembler, Linker, Debugger
• Statische Analyse-Tools
• Testframeworks
• Versionsverwaltung (Git, PTC Integrity)

Die Klassifizierung erfolgt über TCL (Tool Confidence Level) 1, 2 oder 3. Ein Compiler erreicht typischerweise TCL3 — die höchste Stufe — und muss entweder qualifiziert sein (vom Hersteller, mit Safety-Manual) oder durch Ersatzmaßnahmen abgesichert werden (Rückwärtsübersetzung, Disassembly-Vergleich).

Aus einem realen Projekt

Ich erinnere mich an einen mechanisch geprägten Automotive-Zulieferer, der traditionell mechanische Bauteile liefert und sich entschlossen hatte, für seinen Parksperren-Aktuator auch die Steuerungs-Software selbst zu entwickeln. Das Softwareteam saß in Detroit, USA. Die Entwicklung lief monatelang planmäßig — bis kurz vor der Meilenstein-Lieferung an den europäischen Endkunden plötzlich die Frage nach dem Compiler-Safety-Manual aufkam.

Die Antwort: Der in Detroit eingesetzte C-Compiler war nicht für ISO 26262 qualifiziert. Keine TCL-Einstufung vom Hersteller, kein Safety Manual, keine Liste bekannter Compiler-Issues in Bezug auf Sicherheitsanforderungen. Die Panik war riesig. Die Parksperre ist kein Nebenfunktions-Feature — sie ist sicherheitskritisch, weil eine unerwünschte Freigabe der Parksperre bei stehendem Fahrzeug am Hang zu ungewollter Fahrzeugbewegung führen kann.

Was am Ende gemacht wurde, war ein klassisches Ersatzmaßnahmen-Paket: Disassembly-Vergleich ausgewählter Schlüsselfunktionen, zusätzliche Integrationstests mit erhöhter Fehlerinjektion, dokumentierte Tool-Anwendungsanalyse. Das alles, weil am Anfang des Projekts niemand die simple Frage gestellt hatte: „Ist unser Compiler eigentlich qualifiziert für den ASIL, den wir liefern müssen?"

Die Lektion: Wer ein Mechanik-Haus ist und erstmals Software macht, sollte die Tool-Qualifizierung nicht als Detail behandeln. Und wer Entwicklung in mehrere geografische Standorte verteilt, sollte sicherstellen, dass die Prozess-Anforderungen des Endkunden an jedem Standort bekannt und gelebt sind.

Was ASIL-B von QM konkret unterscheidet

Viele Einsteiger fragen: „Was ist der Unterschied zwischen QM-Code und ASIL-B-Code? Der gleiche C-Code tut doch dasselbe." Technisch stimmt das. Organisatorisch ist es ein Unterschied wie Tag und Nacht:

Aktivität	QM	ASIL-B
Anforderungs-Traceability	empfohlen	Pflicht (Tool-gestützt)
Code-Review	empfohlen	Pflicht, dokumentiert, mit definierter Reviewer-Qualifikation
MISRA-C Konformität	Nice-to-have	Pflicht, Abweichungen formal
Unit-Test Coverage	Statement	Branch
Tool-Qualifizierung	nicht gefordert	Pflicht
Fehlerinjektion auf HW-Ebene	nein	empfohlen
Dokumentation pro LOC	1×	5–10×

Der Faktor in der letzten Zeile ist keine Überzeichnung: Die Dokumentation, die ein ASIL-B-Projekt um den eigentlichen Code herum produziert, übersteigt den Code-Umfang um ein Vielfaches. Safety-Plan, Safety-Case, HAZOP-Analyse, FMEA, Validation-Plan, Verification-Plan, Integration-Plan, Test-Reports — jedes dieser Dokumente ist kein Formular, sondern ein eigenständiges Werk.

Was ich Einsteigern rate

1. Lies die Norm. Nicht komplett, aber ISO 26262-6 (Software Development) und -8 (Supporting Processes) gehören zur Grundausstattung. Wer nur das Lastenheft liest, versteht nicht, warum das Lastenheft so aussieht.
2. MISRA-C früh einführen. Am ersten Projekttag, nicht nach dem ersten Integrationstest.
3. Tool-Kette am Projektanfang fixieren. Compiler-Version, Build-Server, statisches Analyse-Tool — das sind Entscheidungen, die später kaum revidierbar sind.
4. Tests sind Pflicht, nicht optional. Wer sich das Testen „fürs Ende des Projekts" aufspart, wird das Projekt nicht liefern. Tests werden mit dem Code zusammen geschrieben.
5. Review-Kultur etablieren. Reviews sind keine Formalie. Ein Safety-Auditor schaut sich die Review-Protokolle genau an: wurden echte Fragen gestellt, oder nur Häkchen gesetzt?
6. Requirements sind der Anker. Ohne saubere, verlinkbare Requirements gibt es keinen Safety-Case. DOORS oder Polarion sind hier Standard.

Fazit

ASIL-B ist nicht schwer — es ist aufwendig. Wer den Mehrwert nicht sieht, empfindet den Prozess als Schikane. Wer einmal erlebt hat, wie statische Analyse einen echten Race-Condition-Fehler findet, der im Feldeinsatz einen Unfall verursacht hätte, versteht warum die Norm so ausführlich ist.

In 35 Jahren Automotive-Entwicklung habe ich gelernt: Qualität kommt nicht durch Testen am Ende, sondern durch Prozess, Werkzeuge und Disziplin während der gesamten Entwicklung. Die ISO 26262 ist dabei weniger ein Hindernis als eine Checkliste der Dinge, die ich auch ohne Norm für guten Automotive-Code erwarten würde.

Der größte Sprung für den Einsteiger ist nicht der Code — es ist das Verstehen, dass ASIL-B Qualität ist, und Qualität hat einen Preis: in Stunden, in Dokumentation und in der Verbindlichkeit jedes einzelnen Schritts. Dafür bekommt man Code, auf den man sich verlassen kann. Und das ist in der Automotive-Welt den Preis wert.