Tool-Qualifizierung (ISO 26262)
Tool-Qualifizierung ist der Nachweis nach ISO 26262-8, dass ein Softwarewerkzeug für den Einsatz in der sicherheitsrelevanten Entwicklung ausreichend vertrauenswürdig ist. Ob sie nötig ist, bestimmt der Tool Confidence Level (TCL) aus Tool Impact und Tool Error Detection. Geregelt ist das Verfahren in Kapitel 11 der ISO 26262-8 — es betrifft Compiler und Codegeneratoren ebenso wie Modellierungs-, Test- und Analysewerkzeuge.
Wann muss ein Werkzeug qualifiziert werden?
Die Norm verlangt keine pauschale Qualifizierung, sondern eine präzise Risiko- und Vertrauensbewertung entlang zweier Fragen:
- Fehlereinschleusung (Tool Impact): Kann ein Fehler im Werkzeug selbst einen sicherheitsrelevanten Fehler in das Produkt einschleusen — oder verhindern, dass ein bereits existierender Fehler im Prozess entdeckt wird?
- Fehlererkennung (Tool Error Detection): Wie wahrscheinlich ist es, dass ein solcher Werkzeugfehler durch den umgebenden Prozess erkannt oder verhindert wird?
Aus der Kombination ergibt sich der Tool Confidence Level:
| Einstufung | Ergebnis |
|---|---|
| Kein Einfluss auf das Sicherheitsergebnis (TI1) | TCL 1 — keine Qualifizierung nötig |
| Einfluss möglich, Fehler wird mit hoher Sicherheit erkannt (TD1) | TCL 1 — keine Qualifizierung nötig |
| Einfluss möglich, Fehlererkennung nur mittel wahrscheinlich (TD2) | TCL 2 — Qualifizierung erforderlich |
| Einfluss möglich, Fehlererkennung unwahrscheinlich (TD3) | TCL 3 — Qualifizierung mit höchster Strenge |
Die vier Qualifizierungsmethoden
Für TCL 2 und TCL 3 nennt die ISO 26262-8 vier Methoden, deren Empfehlungsgrad vom ASIL der entwickelten Funktion abhängt: gesteigertes Vertrauen aus der Nutzung (belegte, einschlägige Betriebshistorie), Bewertung des Werkzeug-Entwicklungsprozesses, Validierung des Softwarewerkzeugs (gezielter Nachweis gegen die Anforderungen des Use Case) und Entwicklung nach einem Sicherheitsstandard. Für hohe ASIL-Einstufungen in Kombination mit TCL 3 werden Validierung oder normkonforme Entwicklung bevorzugt.
Der oft übersehene Hebel: prozessuale Absicherung
Bevor ein Werkzeug qualifiziert wird, lohnt der Blick auf den Prozess darum herum: Häufig reicht bereits die Absicherung durch redundante Prüfungen oder Reviews in nachgelagerten Entwicklungsschritten aus. Wird jeder generierte Code ohnehin durch qualifizierte Tests oder unabhängige Reviews geprüft, steigt die Fehlererkennung — und der TCL sinkt, im besten Fall auf TCL 1. Die günstigste Qualifizierung ist die, die ein gut gestalteter Prozess überflüssig macht.
Make or Buy: Die Qualifizierungsfrage als Engineering-Entscheidung
Mit zunehmender Automatisierung im Safety-Lifecycle wird die Tool-Qualifizierung von der seltenen Compliance-Pflicht zur wiederkehrenden, strategischen Entscheidung:
- Buy (qualifiziertes Produkt): Bei Standardaufgaben und tief integrierten Entwicklungswerkzeugen — etwa Compilern — liefert der Hersteller das Qualifizierungs-Kit mit und spart immense interne Validierungsaufwände.
- Make (eigenes Werkzeug qualifizieren): Bei hochspezifischen, proprietären Inhouse-Skripten oder passgenauen Toolchains sichert die eigene Qualifizierung den hocheffizienten Workflow des Teams.
Tool-Qualifizierung in der Praxis
Verwandte Konzepte existieren auch außerhalb des Automotive-Umfelds — die IEC 61508 etwa klassifiziert Werkzeuge in die Klassen T1 bis T3. Die praktische Leitlinie ist in allen Fällen dieselbe: erst den realen Einfluss des Werkzeugs auf das Sicherheitsergebnis bewerten, dann die Fehlererkennung im Prozess ausschöpfen und nur das qualifizieren, was danach übrig bleibt. So bleibt der Grundsatz erreichbar: so viel Automatisierung wie möglich bei so wenig Qualifizierungsaufwand wie nötig — im Rahmen der funktionalen Sicherheit eine der wirtschaftlich folgenreichsten Weichenstellungen.