Softwarelösungen spielen in sicherheitskritischen und sicherheitsrelevanten Anwendungen eine immer wichtigere Rolle. Der Anwendungsentwickler muss nachweisen, dass die Anwendungssoftware sowie die zum Einsatz kommenden Methoden, Prozesse und Toolketten den einschlägigen Normen zur funktionalen Sicherheit entsprechen. Wesentliche Teile der Toolkette liegen jedoch außerhalb der Kontrolle des Entwicklers. Die Compiler-Validierung ist für Entwickler sicherheitskritischer Systeme von entscheidender Bedeutung geworden. Da praktisch kein Compiler fehlerfrei ist, kommt es darauf an, zu wissen, wo ein Compiler nicht richtig funktioniert, damit sich Fehler vermeiden lassen.
Bibliotheken im Binärformat sind nicht unempfindlich
Ein Großteil des Quellcodes, der als kompilierte Binärdatei in einer Anwendung endet, durchläuft den Compiler nie unter genau demselben Anwendungsfall, Satz von Compiler-Optionen und derselben Zielhardware-Umgebung, die der Entwickler verwendet. Ein Teil des Codes, der in einer Anwendung endet, besteht aus vorkompilierten Bibliotheksfunktionen, wie sie z.B. in der C-Standardbibliothek (libc) enthalten sind, die oft im Binärformat als Teil eines Softwareentwicklungskits (SDK) bereitgestellt wird.
Es wird allgemein angenommen, dass eine Bibliothek, da im Binärformat bereitgestellt wird, unempfindlich gegenüber einem bestimmten Anwendungsfall ist – aber dem ist nicht so. Die Header-Dateien der Bibliothek werden mit der Anwendung kompiliert und enthalten viele Definitionen, einschließlich funktionsähnlicher Makros und (in C++) Vorlagen. Sie machen Bibliothekskomponenten anwendungsabhängig.
Selbst wenn die Bibliothek vom SDK-Lieferanten mit demselben Compiler, der mit dem SDK geliefert wird, vorqualifiziert wurde, ist es unwahrscheinlich, dass der entsprechende Anwendungsfall, die Compiler-Optionen und die Anforderungen an die Zielhardware-Umgebung erfüllt wurden. Dies erschwert den Nachweis, dass die Standards für funktionale Sicherheit eingehalten werden.
Qualifizierung nach ISO 26262
Der Anwendungsentwickler muss nachweisen, dass die Anwendungssoftware sowie die zum Einsatz kommenden Methoden, Prozesse und Toolketten den einschlägigen Normen zur funktionalen Sicherheit entsprechen. Die ISO 26262 sieht zwei Qualifizierungswege für Bibliotheken vor, die in Teil 8 und Teil 6 beschrieben sind. Prüfsoftwares erleichtern durch das Erstellen eines umfassenden Qualifizierungsberichts einen Großteil des Aufwands beim Nachweis von Bibliothekskomponenten für sicherheitskritische Anwendungen.
Testsuiten mit vollständiger Rückverfolgbarkeit
Aktuelle anforderungsbasierte Testsuiten mit vollständiger Rückverfolgbarkeit der einzelnen Testergebnisse bis hin zu Anforderungen, die aus der ISO-C-Sprachspezifikation abgeleitet wurden, helfen dabei, diese Einschränkung zu überwinden. Diese Lösungen können die Qualifizierung von C-Standardbibliothek-Implementierungen für sicherheitskritische Anwendungen sowohl für nicht modifizierte Bibliotheksimplementierungen von Drittanbietern als auch für selbstentwickelte oder selbstverwaltete Implementierungen unterstützen.
Die Qualifizierung von Softwarebibliotheken ist entscheidend, da Code aus der Bibliothek mit der Anwendung verknüpft und auf dem Target installiert wird. Ist eine Bibliothekskomponente fehlerhaft, ist die funktionale Sicherheit der gesamten Anwendung gefährdet. Die Normen zur funktionalen Sicherheit haben ein gemeinsames Ziel: zu überprüfen, ob die Bibliotheksimplementierung ihrer Spezifikation entspricht. ISO 26262 sieht zwei Qualifizierungswege für Bibliotheken vor, die in Teil 8 und Teil 6 beschrieben sind. Die neue Prüfsoftware, wie zum Beispiel die SuperGuard C Library Safety Qualification Suite, kann in beiden Verwendung finden.
ISO 26262 Teil 8, Abschnitt 12: Qualifizierung von Softwarekomponenten
Als kommerzielles Standardprodukt werden Bibliotheken in Teil 8, Abschnitt 12 der ISO 26262 (Qualifizierung von Softwarekomponenten) näher behandelt. Damit wird der Notwendigkeit Rechnung getragen, bestehende Softwarekomponenten wie Bibliotheken zu qualifizieren, „um deren Eignung zur Wiederverwendung nachzuweisen“. Der Abschnitt erwähnt ausdrücklich „Softwarebibliotheken von Drittanbietern“, gilt aber auch für Open-Source- und wiederverwendete interne Software.
Abschnitt 12 besagt, dass eine Qualifizierungsvoraussetzung eine Aussage über die Anforderungen an die Softwarekomponenten ist. Der Abschnitt schlägt auch vor, dass der Nachweis, dass eine Softwarekomponente diese Anforderungen erfüllt, „in erster Linie auf anforderungsbasierten Tests beruhen sollte“, dass dies durch die „Anwendung einer dedizierten Qualifizierungs-Testsuite“ erreichbar ist, dass „sowohl der Normalbetrieb als auch das Verhalten im Fehlerfall abzudecken sind“ und dass „keine bekannten Fehler auftreten dürfen, die zu einer Verletzung von Sicherheitsanforderungen führen würden“.
Die Bibliotheksspezifikation ist sowohl für C als auch für C++ öffentlich zugänglich und bildet den Ausgangspunkt für strenge anforderungsbasierte Tests. Die Sprachspezifikation ist jedoch nicht als Anforderungsliste verfasst. Alle Bibliothekstests in aktuellen Testsuiten basieren fest auf Anforderungen, die aus der ISO-C-Sprachdefinition abgeleitet sind.
Normal- und Fehlerbedingungen abdecken
Um die Anforderung zu erfüllen, dass die Testsuite sowohl Normal- als auch Fehlerbedingungen abdeckt, sollte sie jede Funktion sowohl innerhalb als auch außerhalb ihrer Randbedingungen ausführen und die Fehlerbehandlung der Funktion überprüfen. Die aus der ISO-C-Spezifikation abgeleiteten Anforderungen zum Erstellen von Testsuiten beinhalten die Verifikation des in der Spezifikation definierten erforderlichen Fehlerverhaltens.
Der zuverlässige Nachweis, dass keine bekannten Fehler vorhanden sind, die zu einer Verletzung von Sicherheitsanforderungen führen könnten, erfordert nicht nur effektive anforderungsbasierte Tests. Er stützt sich auch auf die strukturelle Codeabdeckung für Automotive Safety Integrity Level D (ASIL D). Um den Nachweis der Vollständigkeit zu gewährleisten, bietet die heutige Prüfsoftware eine hohe strukturelle Codeabdeckung und eine hohe Modified Condition/Decision Coverage (MC/DC).
Sie umfasst auch die Analyse und Prüfung von Äquivalenzklassen und Grenzwerten sowie Fehler-Raten auf der Grundlage der besten verfügbaren Kenntnisse und Erfahrungen über das Verhalten einer Bibliotheksfunktion.
ISO 26262 Teil 6: Produktentwicklung auf Softwareebene
Die Qualifizierung der C-Standardbibliothek, wie in Teil 6 beschrieben, ist aufwendiger als der Ansatz in Teil 8, da Teil 6 alle Phasen der Softwareentwicklung anspricht.
Teil 6, Tabelle 7: „Methoden zur Verifikation von Software-Units“ enthält anforderungsbasiertes Testen als Empfehlung für alle ASIL-Stufen. Aktuelle Prüfsoftware unterstützt anforderungsbasiertes Testen umfassend, obwohl Entwickler in der Praxis mehr als eine der aufgeführten Methoden verwenden sollten, um eine Implementierung der C-Standardbibliothek zu überprüfen.
Methoden zur Ableitung von Testfällen
Sie verwendet auch alle Methoden, die in Teil 6, Tabelle 8: „Methoden zur Ableitung von Testfällen für Software-Unit-Tests“ aufgeführt sind. Methode 1a, „Anforderungsanalyse“ zerlegt die Spezifikation der C-Standardbibliothek in testbare Anforderungen. Die Beschreibung der C-Standardbibliothek ist eine Mischung aus (manchmal impliziten) Definitionen, Einschränkungen bei der Verwendung von Funktionen und Definitionen des Funktionsverhaltens. Diese wurden in testbare Anforderungen übersetzt, die die Grundlage der Testsuite bilden, einschließlich der im Sprachstandard definierten Anforderungen zum Umgang mit Anomalien.
Die Methoden 1b, „Erzeugung und Analyse von Äquivalenzklassen“ und 1c, „Analyse von Grenzwerten“, beziehen sich auf die Aufteilung der Eingangswertbereiche der Funktionen und werden in den Testspezifikationen der Suite behandelt. Damit wird die Verbindung zwischen Anforderungen und Tests hergestellt.
Methode 1d, „Fehler-Raten aufgrund von Wissen oder Erfahrung“ basiert auf Expertenwissen über schwierige Implementierungsbereiche für die C-Bibliothek und auf den Regressionstests, die seit der ersten Entwicklung der Compiler-Test- und Verifikationssuiten vor mehr als 30 Jahren gesammelt wurden.
V-Modell für die Softwareentwicklung
Bei diesem Ansatz spielen die Testsuiten wie zum Beispiel SuperGuard von Solid Sands auf der rechten Seite des V-Modells für die Softwareentwicklung eine wesentliche Rolle. Das V-Modell organisiert den Softwareentwicklungsprozess in Phasen und definiert auch das Vorgehen beim Testen zur Qualitätssicherung.
In Bezug auf Teil 6, Abschnitt 9: „Software-Unit-Verifizierung“, wird Folgendes behandelt:
- Übereinstimmung der Standard-C-Bibliotheks-Implementierung mit ihren Anforderungen
- Überprüfung der Hardware-Software-Schnittstelle durch Ausführen der Tests auf der Zielhardware
- Vertrauen in das Fehlen unbeabsichtigter Funktionen durch Verifikation von Fehlerfällen und durch Überwachung der Codeabdeckung
- Überprüfung des Ressourcenbedarfs durch Ausführen der Tests auf der Zielhardware
Prüfsoftware wie zum Beispiel die SuperGuard C Library Safety Qualification Suite erleichtert durch das Erstellen eines umfassenden Qualifizierungsberichts, der auf Zertifizierungsstellen nach ISO 26262 zugeschnitten ist, einen Großteil des Aufwands beim Nachweis der Integrität von Bibliothekskomponenten, die in sicherheitskritischen Anwendungen zum Einsatz kommen. (na)