ISO 26262 Toolqualifikation – Eine praxisfähige Strategie!

ISO 26262 Toolqualifikation: In der ISO 26262-8 im Kapitel 11 sind die Anforderungen an Software Tools definiert, welche in einem ISO 26262 konformen Software Entwicklungsprozess zum Einsatz kommen.

In der praktischen Anwendung des Kapitel 11 der ISO 26262-8 ergeben sich oft viele Fragen, die teils zu sehr kreativen Vorgehensweisen bei der Toolqualifikation führen.

Der nachfolgende Beitrag versucht zur Klärung offener Fragen in dem Themenkomplex beizutragen und folgende 3 Fragen zu beantworten:

Warum fordert die ISO 26262 überhaupt einen Vertrauensnachweis in die verwendeten Tools?
Welche Forderungen stellt die ISO 26262?
Wie geht man sinnvoll mit dem Thema um?

Warum fordert die ISO 26262 überhaupt einen Vertrauensnachweis in die verwendeten Tools?

Alle Funktionalen Sicherheitsstandards lassen sich im Bereich der Entwicklungsprozesse auf den Einsatz des 4-Augen Prinzips verallgemeinern. Eine zweite Instanz/Person überprüft dabei jede im Sicherheitsstandard definierte Tätigkeit.

Der Einsatz von Softwaretools, kann dieses Prinzip verletzen. Anhand der statischen Codeanalysetools lässt sich das anschaulich darstellen. So ein Tool wird eingesetzt, um die Einhaltung der festgelegten Kodierrichtlinien im Source Code zu überprüfen. Sollte das Tool einen Fehler beinhalten, werden ggf. Verstöße gegen entsprechende Kodierrichtlinien nicht entdeckt, da keine weitere Überprüfung stattfindet.

Genau in diese Lücke stößt die Toolqualifikation von Softwaretools. Richtig angewendet, stellt sie das 4-Augen Prinzip auch für den Bereich der Softwaretools wieder her.

Die ISO 26262 formuliert das wie folgt (auf Deutsch übersetzter Normtext):

Ein Software-Werkzeug, das bei der Entwicklung eines Systems oder seiner Software- oder Hardware-Elemente verwendet wird, kann die von ISO 26262 geforderten Aktivitäten und Aufgaben unterstützen. In einem solchen Fall ist das Vertrauen erforderlich, dass das Software-Werkzeug die folgenden Ziele effektiv erreicht:

Das Risiko systematischer Fehler im entwickelten Produkt aufgrund von Fehlfunktionen des Software-Werkzeugs, die zu fehlerhaften Ausgaben führen, wird minimiert.
Der Entwicklungsprozess ist im Hinblick auf die Einhaltung der Normenreihe ISO 26262 angemessen, wenn die von der Normenreihe ISO 26262 geforderten Aktivitäten oder Aufgaben auf dem korrekten Funktionieren des verwendeten Software-Werkzeugs beruhen.

Welche Forderungen stellt die ISO 26262?

Zunächst muss gemäß ISO 26262 der sogenannten Tool Confidence Level für ein bestimmtes Tool festgelegt werden. Dazu definiert der Standard folgende Tabelle:

Als Eingangsparameter wird der Tool Impact Level und der Tool Error Detection Level festgelegt. Diese Parameter definiert die Norm wie folgt:

TI1: Toolfehlfunktion fügt keinen Fehler in ein sicherheits-relevantes Item ein und es wird auch nicht
verhindert einen Fehler in einem Item zu entdecken
TI2: Wenn TI1 nicht zutrifft

TD1: Großes Vertrauen, dass eine Fehlfunktion verhindert oder entdeckt wird
TD2: Mittleres Vertrauen, dass eine Fehlfunktion verhindert oder entdeckt wird
TD3: Wenn TD1 und TD2 nicht zutrifft

Wenn sich für ein bestimmtes Tool entweder ein TD1 oder TI1 ergibt, dann resultiert dies in einem TCL1. Für Tools die so eingestuft werden, müssen keine weitere Aktionen durchgeführt werden. Dies trifft meist für z.B. Texteditoren, Requirement Datenbanken und Konfigurationsmanagementtools zu.

Wenn sich für ein Tool ein TD2 und ein TI2 ergibt, dann resultiert dies in einem TCL2. Analog dazu ergibt ein TD3 und TI2 einen TCL3.

Von der ISO 26262 empfohlene Methoden

Für TCL2 und TCL3 definiert die ISO26262 nun folgende 4 mögliche Methoden, die zur Anwendung kommen können:

Für ASIL A und B werden von der Norm, unabhängig ob TCL2 oder TCL3, die Methoden „Increased confidence from use“ und Evaluation of the tool development process” bevorzugt.

Für Tools, welche einen TCL2 aufweisen, gilt diese Präferenz auch für ASIL C Projekte.

Für ASIL C und D werden für Tools, welche einen TCL 3 aufweisen, von der Norm die Methoden „Validation of the software tool“ und „Development in accordance with a safety standard“ empfohlen.

Für Tools, welche einen TCL 2 aufweisen gilt diese Präferenz für ASIL D Projekte.

Was bedeuten nun die einzelnen Methoden?

Increased confidence from use

Diese Methode bedeutet, dass ein Tool bereits in vergleichbaren Projekten eingesetzt wurde und langjährig auf dem Markt ist. Gleichzeitig müssen die aufgetretenen Fehler zugänglich und für den Anwendungsfall passend sein.

Evaluation of the tool development process

Hier evaluiert der Anwender des Software Tools den Entwicklungsprozess des Tools, ggf. beim Toolhersteller. In der Praxis hat sich durchgesetzt, dass diese Maßnahme fast nur zur Anwendung kommt, wenn eine unabhängige Stelle ein Zertifikat für die Evaluierung des Entwicklungsprozesses ausgestellt hat und dies zugänglich ist.

Validation of the software tool

Der Toolanwender oder Hersteller erstellt requirement basierte, funktionale Tests für die verwendeten Funktionen des Software Tools und er weist durch die Ausführung dieser Tests die korrekte Funktionsweise des Software Tools nach. Idealerweise finden diese Tests immer in genau der Umgebung statt in der auch das Tool zum Einsatz kommt.

Development in accordance with a safety standard

Bei Anwendung dieser Methode, wird das gesamte Software Tool nach einen Safety Standard wie ISO 26262, DO 331 etc. entwickelt. Als Kritikalitätslevel kommt der zur Anwendung, welcher auch für die Software gilt für deren Entwicklung das Software Tool zum Einsatz kommen soll. Der Hersteller einer Steuergeräte Software, welche er nach ISO 26262 ASIL D entwickelt, muss dementsprechend nachweisen dass, der Hersteller des im Entwicklungsprozess verwendete Software Tool, dieses auch nach ISO 26262 ASIL D entwickelt hat. Dies bedeutet, einen vielfach erhöhten Entwicklungsaufwand

Wie geht man sinnvoll mit der ISO 26262 Toolqualifikation um?

Die größte Herausforderung bei der Toolqualifikation nach ISO 26262 liegt am Beginn des Prozesses, bei der Bestimmung des Tool Confidence Levels. Die Norm lässt hier sehr viel Interpretationsspielraum. Im ersten Schritt empfehle ich daher folgendes Vorgehen:

Ersetzt oder automatisiert das betrachtete Tool einen in der ISO 26262 definierten Prozess und kann das Tool einen Fehler in die operationelle Software einfügen (denkbares Beispiel: Codegenerator)?
Ersetzt oder automatisiert das betrachtete Tool einen in der ISO 26262 definierten Prozess und kann das Tool Fehler, die in der operationellen Software drin sind, nicht finden (Beispiel: statische Codeanalysetools, Unit Testtool etc.)
Wenn beide Fragen unter 1) mit „Ja“ beantwortet werden, kommt nur die Maßnahme „Development in accordance with a safety standard“ in Frage. In der Praxis ist dies allerdings die absolute Ausnahme, da oft übersehen wird, dass auch Prozesse der ISO 26262 ersetzt werden müssen. Dies wäre z.B. der Fall, wenn man auf die Unittests und/oder die Code Reviews bei einem von einem Codegenerator erstellten Source Code verzichten würde. In der Regel ist die Erstellung dieser Artefakte um ein vielfaches günstiger, als die Entwicklung des Codegenerators nach einem ASIL Level der ISO 26262. Auch der Compiler muss nicht qualifiziert werden, da man keinen Prozess aus der ISO 26262 ersetzt wird. Details dazu gibt es im Blog Compiler für sicherheitsrelevante Software – Was ist zu tun?
Wenn beide Fragen unter 2) mit „Ja“ beantwortet werden, dann macht für ASIL C und D die Maßnahme „Validation of the software tool“ am Meisten Sinn. Die langjährige Erfahrung bei der Anwendung dieser Maßnahme zeigt, dass es die effizienteste Toolqualifikationsmethode ist. Der Aufwand ist auch in den meisten Fällen nicht übermäßig groß. Für viele kommerzielle Tools bieten viele Hersteller sogar ein sogenanntes Toolqualifikationspaket an. Für ASIL A und B Projekte ist diese Maßnahme grundsätzlich auch zu empfehlen, aus Sicht der Norm reicht aber ein Zertifikat des Herstellers über die Evaluierung des Tool development processes aus.
Wenn entweder bei 1) oder 2) jeweils die Frage nach der Automatisierung, bzw. dem Ersatz eines ISO 26262 Prozesses durch ein Tool verneint werden kann, dann ist keine weitere Maßnahme notwendig. Dies trifft in der Regel auf die überwältigende Mehrzahl der eingesetzten Tools zu, wie z.B. Texteditoren, Requirement Datenbanken, Konfigurationsmanagement Tools etc.

Weitere HEICON Blog Beiträge zum Thema

Ihre individuellen Fragen zur praktischen Umsetzung der ISO 26262 beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).