ISO 26262 und statische Analysetools

Die ISO 26262 basiert auf der allgemeiner gefassten IEC-Norm 61508, enthält aber automobilspezifische Verfeinerungen. Sie wurde im Jahr 2011 als internationale Norm für die Entwicklung sicherheitskritischer elektronischer Systeme für Automobile veröffentlicht und findet weltweit immer breitere Anwendung. Diese risikobasierte Norm erkennt zwar die Unmöglichkeit an, das Risiko auf null zu reduzieren, verlangt aber, dass die Risiken qualitativ bewertet und Maßnahmen ergriffen werden, um sie so weit zu reduzieren, wie es vernünftigerweise praktikabel ist („as low as reasonably practicable“ – ALARP).

Zentralelement ASIL

Die in der ISO 26262 verwendete Terminologie enthält die Begriffe „fault“, „error“ und „failure“, deren Übersetzung ins Deutsche wegen der begrifflichen Überschneidungen nicht ganz einfach ist. Ein fault (Mangel) kann zu einem error (Fehler) führen, der letztendlich einen failure (Ausfall) verursachen kann. Der wichtigste Begriff, den es zu verstehen gilt, ist jedoch der „Automotive Safety Integrity Level“ (ASIL). Hierbei handelt es sich um eine Risikoklassifizierung eines Elements der Elektronik. Level D steht für Teile mit dem höchsten Risiko, während A das niedrigste Risiko kennzeichnet. (Als zusätzliche Bezeichnung kommt das Label QM hinzu, das ein Risikoniveau unter ASIL A bezeichnet.) Die Zuweisung der Risikoklasse erfolgt nach einem Bewertungsprozess, dem die Gefahren unterzogen werden. Jedes potenziell gefährliche Ereignis wird nach der Severity (S), das heißt nach der Schwere der Verletzungen klassifiziert, die es verursachen kann. Dabei steht S0 für „keine Verletzungen“ und S3 für „Lebensgefahr“. Die weiteren wichtigen Faktoren in der Bewertung sind die „Exposure“ (E) mit einem Bereich von E0 (extrem geringe Wahrscheinlichkeit) bis E4 (sehr wahrscheinlich) und die „Controllability“ (C). Letzte gibt an, inwieweit der Fahrer eingreifen kann, um Verletzungen abzuwenden (C0 steht für „einfach“ und C3 für „schwierig oder unmöglich“).

Der ASIL-Wert wird ermittelt, indem alle diese Faktoren gemeinsam berücksichtigt werden. Es versteht sich, dass eine Gefahr, die hohe Werte für S, E und C aufweist, in die Kategorie ASIL D eingestuft wird. Dennoch kann eine Gefahr mit einem hohen S-Wert in die Kategorie ASIL A eingeordnet werden, wenn sie nur mit sehr geringer Wahrscheinlichkeit eintritt. Ist für eine Gefahr ein ASIL-Wert ermittelt, wird dieser Wert auf die Sicherheitsziele, die die Gefahr mindern, und auf die davon abgeleiteten Sicherheitsanforderungen übertragen. Der ASIL-Wert bestimmt dann die Mindest-Testanforderungen für die Software.

Tools unterstützen bei der Zertifizierung

Die ISO 26262 erkennt ausdrücklich an, dass Softwarevalidierungs-Tools entscheidend für das Erfüllen der Testanforderungen sind. Konsequenterweise verlangt die Norm, dass die Tools ihrerseits ebenfalls qualifiziert sind. Wichtig ist in diesem Zusammenhang der Hinweis darauf, dass die verwendeten Tools Mängel aufweisen können, die die Sicherheit des gesamten Systems unterminieren können. Deshalb verlangt die Norm die Ermittlung des „Tool Confidence Level“ (TCL), also des Vertrauensgrads für das Tool. Dieser wird durch Bewertung zweier Kriterien bestimmt:

• Die Möglichkeit, dass die Prüfanforderungen nicht erfüllt werden, wenn das Prüftool versagt, und
• die Wahrscheinlichkeit, dass der Ausfall des Tools von seinen Anwendern bemerkt wird.

Der TCL kann zwischen TCL1 (geringstes Vertrauen) und TCL3 (höchstes Vertrauen) liegen. Bestimmt wird er anhand zweier Faktoren, nämlich der Auswirkungen des Tools (Tool Impact – TI) und der Fehlererkennung des Tools (Tool Error Detection – TD). TI beschreibt die Folgewirkungen eines möglichen Funktionsfehlers im Tool, wobei TI1 zum Einsatz kommt, wenn es zweifelhaft ist, das ein Funktionsfehler im Tool selbst a) zu keinem Versagen des Systems führen kann und b) das Erkennen eines Versagens verhindern kann. Ansonsten wird TI2 verwendet.

TD bewertet das Vertrauen darin, wie gut das Tool einen Funktionsfehler melden kann. TD1 steht für das geringste und TD3 für das höchste Vertrauen. Sind das Vertrauen in das Tool und die Fehlererkennung bewertet, lässt sich der TCL-Wert anhand der folgenden Tabelle bestimmen:

Anhand dieser Tabelle lässt sich der TCL-Wert bestimmen. Grammatech

Zu beachten ist, dass sich der TCL-Wert stets auf einen bestimmten Anwendungsfall für das Tool bezieht.

Als Beispiel sei das fiktionale dynamische Analysetool Cov betrachtet, mit dem sich die Codeüberdeckung beim Überprüfen der Software mit einem bestimmten Testpaket messen lässt. Der ASIL soll D (höchste Risikostufe) betragen, und die entsprechende Sicherheitsanforderung soll vom Testpaket eine Verzweigungs-Überdeckung von 100 % verlangen. Eindeutig ist der TI-Wert von Cov TI2, denn wenn das Paket die Überdeckung nicht korrekt meldet, wird die geforderte Codeüberdeckung möglicherweise nicht eingehalten. Der Beurteilung des TD-Werts kann sich knifflig gestalten. Angenommen, Cov sei mit dem Mangel behaftet, dass es gelegentlich einige Abschnitte des Codes nicht instrumentiert und daher die Codeüberdeckung für diese Teile nicht messen kann. Anstatt aber in einem solchen Fall einen Alarm auszulösen, soll es diese Information einfach aus seinem Report auslassen. Ein unerfahrener Nutzer des Tools könnte diese Unterlassung möglicherweise nicht bemerken, sodass die Nichterfüllung der Überdeckungs-Vorgabe unter Umständen nicht bemerkt wird. In einem solchen Fall könnte dem Tool der Wert TD2 zugewiesen werden. Gemäß der obigen Tabelle würde Cov also mit TCL2 bewertet.

Vier Arten zur Tool-Qualifikation

Nach der ISO 26262 benötigen Tools mit TCL1 keine weitere Qualifikation, während bei TCL2 und TCL3 die Anwendung von mindestens einer Toolqualifikations-Methode erforderlich ist, bevor das Tool korrekterweise als qualifiziert bezeichnet werden darf. Dies sind die vier Qualifikationsmethoden, wobei für die höheren ASILs die beiden letztgenannten Methoden dringend empfohlen werden, da sie ein hohes Vertrauensniveau ergeben:

• Gesteigertes Vertrauen aus praktischer Anwendung: Das Tool wurde bei ähnlichen Projekten erfolgreich eingesetzt.
• Evaluierung des Toolentwicklungs-Prozesses: Die Toolentwickler haben sorgfältig einen qualitativ hochwertigen Softwareentwicklungs-Prozess angewendet.
• Validierung des Softwaretools: Das Tool wurde mit strikten Validierungsprotokollen konfrontiert.
• Entwicklung gemäß einem Sicherheitsstandard: Bei der Entwicklung wurde ein rigoroser Entwicklungsstandard (zum Beispiel die ISO 26262 selbst) eingehalten.

Die keineswegs triviale Toolqualifikation sprengt in der Regel den Rahmen der meisten Embedded-Software-Projekte. Da ist es vorteilhaft, dass der Großteil der Toolanbieter, die Wert auf die ISO 26262 legen, die Qualifikation bereits eingeholt haben. Im besten Fall haben die Anbieter eine Qualifikation durch eine unabhängige, auf dieses Gebiet spezialisierte Zertifizierungsstelle erhalten. Eine unabhängige Zertifizierung verleiht den Anwendern des Tools nicht nur Vertrauen in dessen Qualität, sondern erspart ihnen auch einen großen Umfang an Zertifizierungsaufwand.

Um die ISO 26262-Zertifizierung für ein bestimmtes Embedded-System zu erhalten, müssen Entwickler eigene Belege liefern, zu denen auch sämtliche Tool-Qualifikationen gehören. Als Unterstützung stellen die meisten Anbieter eine Art Zertifizierungssatz zur Verfügung, der sämtliche Unterlagen in leicht verwendbarer Form enthält.

Statische Analysetools und die ISO 26262

Die Norm ISO 26262 verlangt nicht die Verwendung von Tools einer ganz bestimmten Klasse, sondern gibt lediglich die Eigenschaften an, die der Code aufweisen sollte. Meist werden jedoch nur Methoden aufgelistet, mit denen sich der Nachweis erbringen lässt, dass der Code diese Eigenschaften tatsächlich aufweist. In vielen Fällen ist überdeutlich erkennbar, dass der Einsatz von Tools praktisch zwingend ist (es wäre also ohne die Verwendung eines modernen Tools praktisch unmöglich, präzise Codeüberdeckungs-Werte einzuholen). In anderen Fällen ist es dagegen möglicherweise nicht klar, dass es Tools zur Hilfestellung gibt.

Abschnitt 8 (Software Unit Design and Implementation) ist derjenige Teil der Norm, für den statische Analysetools am wichtigsten sind. Zu den augenfälligsten Anwendungen statischer Analysetools gehört die Validierung, dass die Software den Codierungsstandards entspricht, die in Abschnitt 5.4.7 angegeben sind und in Abschnitt 8.4.3.d verlangt werden. Das beste derartige Beispiel aus dem Automotive-Bereich ist Misra C. Seit jeher lag die Stärke von statischen Analysetools im Aufdecken solcher Regelverletzungen, wobei die neueste Generation darüber hinaus eine Menge weiterer Funktionen bietet: Zusätzlich zu ihrer Hauptaufgabe – das Finden gravierender Programmierfehler, die dafür sorgen könnten, dass ein Programm beispielsweise abstürzt oder in ein undefiniertes Verhalten abdriftet – wurden diese Tools so flexibel konzipiert, dass sich mit ihnen auch verschiedene andere Anforderungen der ISO 26262 erfüllen lassen.

Zu den sachdienlichsten Passagen gehört der Abschnitt 8.4.4, der „Prinzipien für das Design und die Implementierung von Softwaremodulen auf der Quellcode-Ebene“ auflistet, um bestimmte Eigenschaften zu erreichen wie etwa die korrekte Verarbeitungsreihenfolge, Robustheit und die Lesbarkeit des Codes. Daran anknüpfend, listet Abschnitt 8.4.5 Techniken auf, die zum Überprüfen der Konformität der Software genutzt werden sollten. Eine der dabei aufgeführten Techniken ist die statische Codeanalyse.

Pfadüberdeckung und Robustheit

In der Norm ISO 26262 ist an mehreren Stellen von „Robustheit“ die Rede. Im Zusammenhang mit dem Design und der Implementierung von Softwaremodulen versteht man darunter das Vermeiden von „unplausiblen Werten“ Verarbeitungsfehlern, Divisionen durch null sowie von Fehlern im Daten- und Kontrollfluss (8.4.4). Zu den Robustheitsmerkmalen, die für Software-Modultests (9.4.2), die Integration und das Testen von Software (10.4.3) angeführt werden, gehören das Nichtvorhandensein unzugänglicher Software sowie eine effektive Fehlererkennung und -behandlung. Vernünftig zusammenfassen lässt sich die Forderung nach Robustheit in der Aussage, dass die Zahl der vermeidbaren gravierenden Softwaredefekte minimiert werden sollte. Und genau hierin liegt die größte Stärke fortschrittlicher statischer Analysetools.

Grob gesagt beginnt die Arbeit dieser Tools damit, dass der Code geparst wird, bevor ein originalgetreues Modell des gesamten Programms erstellt wird. Die zum Aufdecken von Fehlern dienenden Analysen durchlaufen das Modell anschließend auf unterschiedliche Weise und suchen dabei nach Anomalien. Die ausgefeiltesten Algorithmen nehmen eine Art Simulation der Programmausführung vor, indem sie die durch den Code führenden Pfade untersuchen. Anstatt den Stand der Verarbeitung dabei jedoch mit konkreten Werten anzugeben, wenden sie einen Satz abstrakter Gleichungen an, die die Eigenschaften des Programms nachbilden. Das wichtigste Merkmal dieser Tools ist, dass sie eine weit größere Zahl von Verarbeitungspfaden untersuchen, als es selbst mit den raffiniertesten Tests möglich wäre. Selbst wenn der Code nach einer strengen Überdeckungsvorgabe wie etwa full MCDC (die strengste Vorgabe der ISO 26262) geprüft wurde, kommt dies bei weitem nicht an die Garantie einer vollen Pfadüberdeckung heran.

(ah)