Einführung
Softwarelösungen spielen eine immer wichtigere Rolle in sicherheitskritischen und sicherheitsrelevanten Systemen im Allgemeinen, sodass Softwarefehlfunktionen eine Haftung und eine echte Bedrohung nach sich ziehen, die sich in Form von Verletzungen, Verlust von Leben, Unterbrechung wesentlicher Dienste oder Schäden an der Umgebung. Infolgedessen haben internationale Standardisierungsgremien wie ISO (International Organization for Standardization) und IEC (International Electrotechnical Commission) weithin anerkannte und angenommene Standards veröffentlicht, die Softwareentwicklern helfen, die Sicherheit ihrer Software zu zertifizieren. Einige Beispiele sind ISO 26262 (Straßenfahrzeuge – Funktionale Sicherheit) für das Automobil, EN 50128 (Kommunikations-, Signalisierungs- und Verarbeitungssysteme – Software für Bahnleit- und Sicherungssysteme) für den Schienenverkehr und IEC 61508 (Funktionale Sicherheit elektrischer, elektronischer und programmierbarer elektronischer Systeme) für industrielle Anwendungen.
Die Verantwortung für den Nachweis, dass die Anwendungssoftware und die zu ihrer Entwicklung eingesetzten Softwaremethoden, Prozesse und Toolchains die entsprechenden funktionalen Sicherheitsstandards erfüllen, liegt eindeutig beim Anwendungsentwickler. Tatsache ist jedoch, dass wesentliche Teile der Toolchain außerhalb der Kontrolle des Entwicklers liegen. Dies ist einer der Gründe, warum die Compiler-Validierung, ein Segment, in dem Solid Sands bereits weltweit führend ist, zu einem kritischen Thema für Entwickler sicherheitskritischer Systeme geworden ist. In der Praxis ist kein Compiler fehlerfrei, daher ist es äußerst wichtig zu wissen, wo ein Compiler fehlschlägt, um Kompilierungsfehler zu vermeiden.
Es ist auch wahr, dass ein erheblicher Teil des Codes, der Teil der vollständigen Anwendung wird, wahrscheinlich mit anderen Anwendungsfällen, Compiler-Optionssätzen und Build-Umgebungen kompiliert wird als die vom Entwickler verwendeten. Dies liegt daran, dass ein Teil des Codes, der häufig in einer Anwendung landet, aus vorkompilierten Bibliotheksfunktionen besteht, wie beispielsweise der Standardbibliothek von C (libc), die häufig in Binärform innerhalb einer Entwicklungskit-Software (SDK) bereitgestellt wird.
Entgegen der allgemeinen Meinung, dass eine im Binärformat bereitgestellte Bibliothek für einen bestimmten Anwendungsfall unempfindlich ist, dh dass der Code invariant ist, ist dies in der Praxis nicht der Fall. Das Einbinden generischer Typvorlagen und Makros macht Bibliothekskomponenten oft empfindlich für den Anwendungsfall. Selbst wenn die Bibliothek vom SDK-Anbieter unter Verwendung desselben Compilers, der mit dem SDK geliefert wird, vorab validiert worden wäre, wären die Anforderungen des Anwendungsfalls, die Compileroptionen und die Zielhardwareumgebung mit ziemlicher Sicherheit nicht übereinstimmend, und dies macht es schwierig, die Konformität nachzuweisen mit dem funktionalen Sicherheitsstandard.
Um diese Einschränkung zu überwinden, hat Solid Sands ein neues Bibliotheksvalidierungstool namens SuperGuard C Library Safety Qualification Suite eingeführt. Es ist ein anforderungsbasiertes Testpaket für die C-Standardbibliothek mit vollständiger Rückverfolgbarkeit von den Ergebnissen jedes Tests zu den Anforderungen, die aus der ISO-Sprachspezifikation C abgeleitet wurden.SuperGuard kann verwendet werden, um Implementierungen der C-Standardbibliothek in sicherheitskritischen Anwendungen zu validieren , sowohl in unveränderten als auch in selbst entwickelten und gepflegten Bibliotheksimplementierungen von Drittanbietern. Seine Rolle im Modell V für die Softwareentwicklung wird unten gezeigt.
Validierungsziel
Die Validierung einer Softwarebibliothek ist von entscheidender Bedeutung, da der Bibliothekscode mit der Anwendung verknüpft und auf dem Zielgerät installiert ist. Wenn eine Bibliothekskomponente fehlerhaft ist, ist die Funktionssicherheit der gesamten Anwendung gefährdet. Jeder funktionale Sicherheitsstandard hat seine eigenen spezifischen Ziele, wenn es um die Verwendung von Softwarebibliotheken geht, aber im Allgemeinen haben sie alle ein gemeinsames Ziel: die Verifizierung, dass die Bibliotheksimplementierung ihrer Spezifikation entspricht. ISO 26262 bietet zwei Möglichkeiten zur Validierung der Bibliothek, die separat in ISO 26262 Teil 8 und ISO 26262 Teil 6 beschrieben werden. Die SuperGuard C Library Safety Qualification Suite kann in beiden Fällen verwendet werden.
ISO 26262 Teil 8, Abschnitt 12: Validierung von Softwarekomponenten
Für die Einstufung als COTS-Produkte (commercial off-the-shelf) fallen Bibliotheken unter Part 8, Clause 12: „Validation of software components“. Diese Klausel befasst sich mit der Notwendigkeit, vorhandene Softwarekomponenten wie Bibliotheken zu validieren, „um nachzuweisen, dass sie für die Wiederverwendung geeignet sind“. Es erwähnt ausdrücklich „von Drittanbietern gelieferte Softwarebibliotheken“, was eindeutig die Standardbibliotheken umfasst, die mit kommerziellen SDKs geliefert werden. Die Klausel gilt auch für wiederverwendete interne Software und Open-Source-Software.
Teil 8, Abschnitt 12 besagt, dass eine Voraussetzung für die Validierung eine Angabe der Anforderungen an die Softwarekomponente ist. Es schlägt auch vor, dass sich das Testen, ob eine Softwarekomponente diese Anforderungen erfüllt, „in erster Linie auf anforderungsbasierte Tests beziehen sollte“, was durch die „Anwendung eines spezialisierten Validierungstestpakets“ erreicht werden kann, das „sowohl normale Betriebsbedingungen als auch die Reaktion abdecken sollte wenn ein Fehler auftritt“ und es sollte „keine Fehler aufweisen, die zur Nichteinhaltung von Sicherheitsanforderungen führen könnten“.
Glücklicherweise existiert die Bibliotheksspezifikation für die Sprachen C und C++ und ist öffentlich zugänglich, sodass bereits ein Ausgangspunkt für strenge anforderungsbasierte Tests vorhanden ist. Tatsächlich sind die Existenz und Testbarkeit sowohl der Sprache als auch der Bibliotheksspezifikation einer der Gründe, warum die Programmiersprachen C und C++ in der Entwicklergemeinschaft so weit verbreitet sind. Nun ist die Sprachspezifikation nicht als Anforderungsliste geschrieben. Ein Hauptmerkmal der Testsuite von Solid Sands SuperGuard ist, dass alle ihre Bibliothekstests fest auf den Anforderungen basieren, die aus der ISO-C-Sprachdefinition abgeleitet wurden.
Um die Anforderung zu erfüllen, dass das Testpaket sowohl Normal- als auch Fehlerbedingungen abdeckt, sollten Sie jede Funktion sowohl innerhalb als auch außerhalb ihrer Randbedingungen implementieren und die Fehlerbehandlung der Funktion überprüfen. Zu den aus der ISO C-Spezifikation abgeleiteten Anforderungen zur Erstellung von SuperGuard gehört die Überprüfung der erforderlichen Fehlerreaktion, wie in der Spezifikation definiert.
Ein zuverlässiger Nachweis der Fehlerfreiheit bei Nichteinhaltung von Sicherheitsanforderungen hängt nicht nur von effektiven anforderungsbasierten Tests ab, sondern auch von einer strukturellen Codeabdeckung nach ASIL D (Automotive Safety Integrity Level D), der höchsten Integritätsstufe für Automobilanwendungen . Um den Integritätsnachweis zu gewährleisten, bietet SuperGuard eine hohe strukturelle Codeabdeckung und eine hohe MC/DC (Modified Condition/Decision Coverage).
SuperGuard beinhaltet auch eine Äquivalenzklassen- und Grenzwertanalyse und -prüfung sowie eine Fehlerabschätzung, die auf den besten verfügbaren Kenntnissen und Erfahrungen bei der Reaktion auf eine Bibliotheksfunktion basiert.
ISO 26262 Teil 6: Produktentwicklung auf Softwareebene
ISO 26262 Teil 6 verfolgt einen parallelen Ansatz, indem Bibliothekscode genauso behandelt wird wie anderer Anwendungscode, der auf dem Zielsystem ausgeführt wird. Interessanterweise werden Bibliotheken nicht als separate Codekategorie erwähnt, und dies könnte der Grund dafür sein, dass die Notwendigkeit einer Bibliotheksvalidierung oft übersehen wird.
Die in ISO 26262 Teil 6 beschriebene Validierung der C-Standardbibliothek ist umfassender als die in Teil 8 beschriebene, da Teil 6 alle Phasen der Softwareentwicklung behandelt.
Teil 6, Tabelle 7: „Software Unit Verification Methods“ enthält die anforderungsbasierte Verifizierung als eine seiner Empfehlungen für alle ASIL-Stufen. Wie oben für die „Validierung von Softwarekomponenten“ (ISO 26262 Teil 8, Abschnitt 12) erwähnt, geht SuperGuard von allen anforderungsbasierten Tests aus, obwohl es in der Praxis empfohlen wird, dass Entwickler mehr als eine der in der Tabelle angegebenen Methoden verwenden, um eine zu verifizieren Implementierung der C-Standardbibliothek.
SuperGuard verwendet auch alle Methoden, die in Teil 6, Tabelle 8: „Methoden aus Testfällen zum Testen von Softwareeinheiten“ aufgeführt sind. Methode 1a, „Anforderungsanalyse“, wird verwendet, um die Spezifikation der C-Standardbibliothek in testbare Anforderungen zu zerlegen. Die Beschreibung der C-Standardbibliothek ist eine Mischung aus (manchmal impliziten) Definitionen und Einschränkungen für die Verwendung von Funktionen sowie Funktionsantwortdefinitionen. In SuperGuard sind sie auch testbare Anforderungen geworden, die die Grundlage des Testpakets bilden, einschließlich der im Sprachstandard definierten Anforderungen für den Umgang mit ungewöhnlichen Fällen.
Die Methoden 1b, „Erzeugung und Analyse von Äquivalenzklassen“, und 1c, „Grenzwertanalyse“, beziehen sich auf die Aufteilung der Domänen der Eingangswerte der Funktionen und werden in den SuperGuard-Testspezifikationen behandelt Verbindung zwischen Anforderungen und Tests.
Methode 1d, „Fehlerschätzung aus Wissen und Erfahrung“, basiert auf dem Wissen von Solid Sands über schwierige Implementierungsbereiche für die C-Bibliothek sowie auf Regressionstests, die seit der ursprünglichen Entwicklung des Pakets durchgeführt wurden, zum Testen und Verifizieren von Solid Sands SuperTest-Compiler vor über 30 Jahren.
Mit diesem Ansatz spielt SuperGuard eine herausragende Rolle auf der rechten Seite des Model V für die Softwareentwicklung. In Bezug auf ISO 26262 Teil 6, Abschnitt 9: „Software Unit Verification“ umfasst es Folgendes:
- Erfüllung der Implementierung der C-Standardbibliothek nach Ihren Anforderungen
- Verifizierung der Hardware-Software-Schnittstelle durch Testen auf der Zielhardware
- Vertrauen in das Fehlen unerwarteter Funktionen durch Überprüfung von Fehlerfällen und Überwachung der Codeabdeckung
- Überprüfung der notwendigen Ressourcen durch Tests auf der Zielhardware
Wie Tests mit SuperGuard entwickelt werden
Bei der Implementierung der anforderungsbasierten Prüfungen, die in Teil 8 und Teil 6 der Norm ISO 26262 für funktionale Sicherheit empfohlen werden, besteht das Hauptproblem der Spezifikationen der C- und C++-Standardbibliothek darin, dass sie zwar eine detaillierte Beschreibung der Reaktion für jede Funktion lieferten, aber keine davon sie definieren ein klares Anforderungsprofil. Daher müssen aus den Beschreibungen der Antworten die notwendigen Voraussetzungen für jede Funktion erstellt werden.
Die SuperGuard C Library Safety Qualification Suite enthält die bewährte Testsuite für die C-Standardbibliothek, die bereits in SuperTest enthalten ist, der weltweit führenden Compiler-Test- und Verifizierungssuite von Solid Sands, die sich seit mehr als 30 Jahren an die Sprachspezifikationen (ISO) hält. SuperGuard geht jedoch in seinen Berichtsfunktionen, Dokumentationsanforderungen, individuellen Tests und Testergebnissen in Übereinstimmung mit funktionalen Sicherheitsstandards wie ISO 26262, EN 50128 und IEC 61508 viel weiter als SuperTest.
Die Tests im SuperGuard-Testpaket sind nach den folgenden Prinzipien konzipiert, wodurch sie für eine Vielzahl von Entwicklungsumgebungen geeignet sind.
Die Tests von SuperGuard sind antwortbasiert, d. h. sie verifizieren, dass die Implementierung antwortet, indem sie die Bibliotheksspezifikation erfüllt. Jeder Test führt das getestete Konstrukt oder die getestete Funktion aus und vergleicht die Ergebnisse der Ausführung mit den erwarteten Ergebnissen („Modell“), die in der Bibliotheksspezifikation definiert sind. Der Test selbst zeigt an, ob er an den Controller bestanden wurde.
Diese Tests werden in einer Ausführungsumgebung kompiliert und ausgeführt, um das Verhalten der Implementierung zu überprüfen, was bedeutet, dass für jeden Test die gesamte Toolchain einschließlich des Zielprozessors beansprucht wird. Dadurch eignet sich SuperGuard für die Loopback-Hardwareüberprüfung von Bibliotheken.
Tests für den eigenständigen Teil der Bibliothek (normalerweise auf Bare-Metal-Systemen verwendet) erfordern nur minimale Ressourcen. Die meisten SuperGuard-Tests können auf Systemen mit weniger als 4 KB Arbeitsspeicher ausgeführt werden, sodass es möglich ist, SuperGuard auf sehr kleinen eingebetteten Systemen zu verwenden.
Um anforderungsbasierte Tests zu implementieren, bietet SuperGuard eine detaillierte Aufschlüsselung der Spezifikationen der C-Standardbibliothek in testbare Implementierungsanforderungen zusammen mit Testspezifikationen, die beschreiben, wie jede Anforderung getestet wird. Durch die Verknüpfung der Ergebnisse jeder Testausführung mit der entsprechenden Testspezifikation, Testanforderung und Standardbibliotheksfunktion bietet SuperGuard die vollständige Rückverfolgbarkeit, die für anforderungsbasierte Tests erforderlich ist. Um zu zeigen, dass es abgeschlossen wurde, bietet es nahezu 100 % strukturelle Codeabdeckung für mehr als 80 % der Funktionen mit einem hohen MC/DC (Modified Condition/Decision Coverage). Beachten Sie, dass dies die Bibliotheksimplementierung selbst betrifft, nicht die zugrunde liegende Betriebssystemschicht.
ein Beispiel
Jeder Bibliothekstest in SuperGuard wird gemäß einer konsistenten Methodik entwickelt, wie durch die Funktion veranschaulicht streng unten gezeigt. Dies ist die Spezifikation in Abschnitt 7.21.2.4 der C99-Sprachdefinition:
7.21.2.4 Die Funktion streng
Zusammenfassung
1. #enthaltenstring.h>
char * strncpy(char * s1 einschränken, const char * s2 einschränken, size_t n);
Beschreibung
2. Die Funktion streng nicht mehr kopieren als n Zeichen (Zeichen nach einem Nullzeichen werden nicht kopiert) aus dem Array, auf das gezeigt wird s2 zu der Matrix, auf die von gezeigt wird s1. Erfolgt die Kopie zwischen überlappenden Objekten, ist die Reaktion undefiniert.
3. Wenn die Matrix auf by zeigte s2 ist eine Zeichenfolge mit weniger als n Zeichen werden der Kopie in dem Array, auf das von gezeigt wird, Nullzeichen hinzugefügt s1 bis sie geschrieben sind n Zeichen.
Ergebnisse
4. Die Funktion streng liefert den Wert von s1.
Der merkwürdigste Aspekt dieser Spezifikation ist, dass Absatz 2 keine Untergrenze für die Anzahl der kopierten Zeichen festlegt. strncpy (). Sagt so: "nicht mehr kopieren als n Zeichen“. Die Spezifikation erfordert an keiner Stelle, dass irgendein Zeichen kopiert werden muss s2 a s1. In Absatz 3 wird eine Aktion angegeben, nämlich die s1 wird mit Nullzeichen aufgefüllt. Wörtlich genommen würde eine korrekte Implementierung nach dieser Spezifikation einfach aus dem Schreiben bestehen n Nullzeichen hinein s1.
Tatsächlich wurde die Funktion dafür weder erstellt, noch ist es das, was von ihr erwartet wird. Die allgemeine Interpretation ist, dass die Funktion so viele Zeichen wie möglich kopiert s2 a s1 bis zur Kette s2 o n sie sind verzehrt worden. Es gibt keine Verwirrung darüber und anscheinend hat sich seit ANSI C89 niemand über diesen Satz beschwert, weil dieselben Wörter immer noch in C18 vorhanden sind. Aber um die Anforderungen zu definieren, müssen wir etwas präziser werden.
Der erste Schritt in unserem Testentwicklungsprozess besteht darin, aus dieser Beschreibung eine Reihe von Anforderungen (REQ) zu extrahieren, wobei zu berücksichtigen ist, wofür das Feature tatsächlich gedacht ist:
REQ-Copystring: Si s2 zeigt auf einen String der Länge 'l2' (wie definiert durch strlen ()) was kleiner ist als n, strncpy () wird kopieren l2 Zeichen, der Reihe nach, aus dem Array s2 bis zum Mutterleib s1.
REQ-Kopie: Si s2 zeigt nicht auf eine Zeichenfolge mit einer Länge kleiner als n, strncpy () kopiert die erste n Zeichen, der Reihe nach, aus dem Array s2 bis zum Mutterleib s1.
REQ-kürzer: Si s2 zeigt auf einen String mit einer Länge kleiner als n, strncpy () fügt Nullzeichen hinzu ('\0') nach den in das Array kopierten Zeichen s1 bis sie geschrieben sind n Charaktere insgesamt.
REQ-nicht mehr: strncpy () schreibt nicht in das Zielarray s1 nach dem ersten n Zeichen.
REQ-keine Änderung: strncpy () ändert das Array nicht s2.
REQ-Rückgabe: strncpy () liefert den Wert von s1.
Die Anforderung REQ-keine Änderung folgen Sie der Aussage s2 als Matrix konstant, aber die Deklaration allein garantiert noch nicht, dass eine Umsetzung von strncpy () schreib nicht weiter s2.
Für jede dieser Anforderungen wurde eine Testspezifikation entwickelt. Die Testspezifikation definiert, wie ein Test überprüft, ob die Anforderung erfüllt ist. Eine einzelne Testspezifikation führt normalerweise zu einer Reihe von Anwendungsfällen, die die Eingabe- und Ausgabedomänen der Funktion abdecken. Testfälle werden durch den Test implementiert. Die Testspezifikation verknüpft die Anforderung mit den Tests.
Zum Beispiel die Testspezifikationen für die Anforderungen von ANFORDERUNG-kopieren y ANFORDERUNG-Nomore Sie sind wie folgt:
Prüfvorschrift für REQ-Copystring: Funktion anwenden strncpy () mit unterschiedlichen Parameterwerten n (inbegriffen n==0) gleich und größer als die Länge der Quellzeichenfolge. Überprüfen Sie, ob die Quellzeichenfolge bis zum letzten Nullzeichen in das Zielarray kopiert wurde.
Prüfvorschrift für REQ-nicht mehr: Überprüfen Sie in allen Fällen, ob das Zeichen mit Index n im Zielarray s1 wurde nicht geändert. Wenn dies mit dem Test übereinstimmt, überprüfen Sie, dass danach keine Zeichen geändert wurden n.
In diesem Fall wird die Testspezifikation implementiert REQ-nicht mehr in derselben Testdatei wie die anderen Testfälle zu strncpy (). Denn die Anforderung muss bei jeder Anwendung unbedingt eingehalten werden strncpy (), anstatt neue Tests für diese Testspezifikation zu erstellen, wird implementiert, indem einfach jeder Testfall für die anderen Anforderungen zusätzlich überprüft wird, anstatt neue Tests dafür zu erstellen.
Umgang mit Startdateien und Makros vom Funktionstyp
Die C-Sprache verkompliziert das Leben des Testers in mehrfacher Hinsicht. Aus diesem Grund sind nicht alle Funktionen in der C-Standardbibliothek nur in vorkompilierter Binärform implementiert. Viele verlassen sich auch stark auf die Informationen, die in den Boot-Quelldateien enthalten sind.
Diese Startdateien, die Dinge wie Typen, globale Variablen und Makros definieren, sind genauso Teil der Bibliothek wie die (vorkompilierten) Bibliotheksfunktionen. Viele Funktionen werden sowohl als echte Funktion als auch als Makro implementiert, und um ihre Geschwindigkeit und Effizienz zu erhöhen, ist es üblich, ihre Implementierung als Makro zu verwenden. Beide Fälle werden von SuperGuard geprüft.
Im Gegensatz zu den entsprechenden Binärdateien werden Makros vom Funktionstyp nicht vorkompiliert. Sie werden vom SDK-Compiler zusammen mit dem Quellcode der Anwendung kompiliert. Daher ist es wichtig, dass sie zusammen mit anderen Inhalten der Startup-Dateien auf die konkreten Anwendungsfälle einer sicherheitskritischen Anwendung geprüft werden. In der C++-Bibliothek wird die Verwendung von Makros auf eine noch höhere Ebene gehoben, indem generische Typvorlagen verwendet werden, die nur im Header vorhanden sind.
Wenn anforderungsbasiertes Testen zu ISO 26262 Teil 8 Abschnitt 12 passt
Dank dieser anforderungsbasierten Testmethoden stellt SuperGuard die Verfügbarkeit der folgenden grundlegenden Elemente sicher, die in ISO 26262: Teil 8, Abschnitt 12.4.1 enthalten sind, um ein Softwareelement als validiert zu betrachten:
12.4.1 a) die Softwarekomponentenspezifikation
Die Spezifikation der C- und C++-Standardbibliotheken basiert auf öffentlich verfügbaren ISO-Standards, und SuperGuard fügt den Antwortbeschreibungen, die diese Standards enthalten, klare funktionale Anforderungen hinzu.
12.4.1 b) Nachweis, dass die Softwarekomponente ihre Anforderungen erfüllt
Durch die Umwandlung der aus den Antwortbeschreibungen der Bibliotheksspezifikation extrahierten funktionalen Anforderungen in Testspezifikationen und Testdesigns und die Vereinigung der resultierenden Tests zu einem umfassenden Satz ausführbarer Tests liefert SuperGuard den Nachweis, dass eine Implementierung der Bibliothek C-Standardbibliothek die extrahierten Anforderungen erfüllt und also die Antwortbeschreibung.
12.4.1 c) Nachweis, dass die Softwarekomponente für den vorgesehenen Verwendungszweck geeignet ist
Wenn SuperGuard zum Testen einer Implementierung der C-Standardbibliothek verwendet wird, generiert es einen detaillierten Bericht des PASS/FAIL-Status aller Tests mit vollständiger Rückverfolgbarkeit zurück zu den funktionalen Anforderungen, die aus den Antwortbeschreibungen der Spezifikation extrahiert wurden.
SuperGuard erfüllt auch die Anforderungen von ISO 26262 Teil 8, Abschnitt 12, Absätze 12.4.2.2, 12.4.2.3 und 12.4.2.4, die sich auf 12.4.1b oben beziehen. Abschnitt 12.4.2.2 besagt, dass die Verifizierung einer Softwarekomponente mit einer anforderungsbasierten Prüfung und einem spezialisierten Testpaket durchgeführt werden kann, was SuperGuard bietet. Es heißt auch, dass die Verifizierung „decken sowohl normale Betriebsbedingungen als auch die Reaktion im Fehlerfall abund sollte nicht "Anzeigefehler, die zu Verstößen gegen die dieser Softwarekomponente zugeordneten Sicherheitsanforderungen führen könnten." SuperGuard prüft die funktionalen Anforderungen für alle Fehlfunktionen, die im ISO-C-Sprachstandard definiert sind.
Abschnitt 12.4.2.3 definiert eine zusätzliche Anforderung für die Verwendung von Softwarekomponenten in ASIL-D-Anwendungen und besagt, dass die strukturelle Abdeckung gemessen werden muss, um zu beurteilen, ob die Testfälle abgeschlossen wurden.
Abschnitt 12.4.2.4 besagt, dass der in Abschnitt 12 beschriebene Verifizierungsprozess nur auf eine unveränderte Implementierung der Softwarekomponente angewendet werden kann. Während einige Entwickler Bibliotheksfunktionen durch ihre eigenen spezialisierten Implementierungen ersetzen, gelten diese Änderungen normalerweise nur für einige wenige Funktionen. Da die C-Standardbibliothek hochgradig modular ist und praktisch alle Funktionsimplementierungen unabhängig vom Rest der Bibliothek sind, können die meisten Funktionen in der Bibliothek immer noch wie in Teil 8, Abschnitt 12 angegeben verifiziert werden, sodass sich der Anwendungsentwickler nur auf die Validierung konzentrieren kann diejenigen Funktionen, die gemäß den Bestimmungen von Teil 6 geändert wurden.
Codeabdeckungsanalyse
Während der Erstellung des SuperGuard-Testpakets wurde besonderes Augenmerk auf die Codeabdeckung gelegt, damit eine ausgereifte und bekannte Open-Source-Implementierung der C-Standardbibliothek die ASIL-D-Anforderung in Abschnitt 12.4.2.3 erfüllen würde. SuperGuard bietet 100 % Abdeckung für viele Bibliotheksfunktionen sowie eine hohe MC/DC-Abdeckung. Die Bereiche, in denen SuperGuard weniger abdeckt, beziehen sich häufig auf die durch die Implementierung definierte Antwort, für die es keine Anforderungen gibt, die aus der Sprachspezifikation abgeleitet werden können.
Obwohl jede Implementierung der Bibliothek anders ist, sollten letztendlich alle das Parsen ähnlicher Fälle handhaben. Das bedeutet, dass die hohe Codeabdeckung von SuperGuard der Codeabdeckung für alle Implementierungen der C-Standardbibliothek zugute kommt.
anomale Fälle
SuperGuard kann ungewöhnliche Fälle auf zwei Arten handhaben. Die erste bezieht sich auf die Reaktion, die von einer anomalen Eingabe definiert wird; Zum Beispiel bei der Eingabe einer negativen Zahl in die Funktion sqrt() das Ergebnis sollte der Wert sein NaN (unter der Annahme von IEC 60559-Arithmetik). Obwohl dies ein ungewöhnlicher Fall ist, ist die Antwort der Funktion vollständig definiert und kann wie jede andere überprüft werden.
Die zweite bezieht sich auf die Anforderungen, die vom Compiler verifiziert werden können. Zum Beispiel, wenn eine Funktion ein Ergebnis vom Typ zurückgeben soll leer, kann ein Test versuchen, den bereitgestellten Wert mit der Erwartung zu verwenden, dass er einen Compilerfehler generiert. Ein Test dieser Art wird als a bezeichnet x-Test in SuperGuard und der Dateiname dieser Tests beginnt mit a x. Die
X-Test PASS, wenn der Compiler einen Kompilierungsfehler anzeigt, und FAIL, wenn dies nicht der Fall ist. X-Tests werden nie durchgeführt.
Zusammenfassung und Fazit
Sicherheitskritische Anwendungen verlangen von Softwareentwicklern, alles in ihrer Macht Stehende zu tun, um sicherzustellen, dass ihre Entwicklungsprozesse, Toolchains und Anwendungscodes kein Risiko für Verletzungen, Todesfälle, Unterbrechungen wesentlicher Dienste oder Umweltschäden darstellen. Bei der Verwendung von Tools und Komponenten von Drittanbietern und/oder kommerziellen Standardprodukten (COTS), wie z. B. Compilern und Standardbibliotheken, sollten Entwickler nicht davon ausgehen, dass diese Tools und Komponenten fehlerfrei sind oder dass ihre Vorabvalidierung dies impliziert. . Validierung ist nur dann wirklich valide, wenn sie in der gleichen Entwicklungsumgebung und unter den gleichen Use-Case-Bedingungen wie in der Anwendung durchgeführt wird.
Unter Verwendung des gleichen Testpakets, das in SuperTest, der Lösung von Solid Sands für Compiler-Tests und -Verifizierung, enthalten ist, fügt die SuperGuard C Library Safety Qualification Suite die notwendige Rückverfolgbarkeit hinzu, um Testergebnisse basierend auf Anforderungen zu verknüpfen, empfohlene Methode zum Testen funktionaler Sicherheitsanforderungen wie ISO 26262, gegen die Spezifikation der C-Standardbibliothek.Die vollständige Rückverfolgbarkeit wird erreicht, indem die Funktionsspezifikationen der ISO-C-Standardbibliothek in klar definierte Anforderungen zerlegt werden, geeignete Testspezifikationen entwickelt werden, um solche Anforderungen zu verifizieren, und sie gemäß den Empfehlungen von ISO 26262 umzusetzen diese Tests in derselben Entwicklungsumgebung unter denselben Anwendungsfallbedingungen und auf derselben Zielhardware, die in ihrer Anwendung verwendet wird, mit nahezu 100 % struktureller Codeabdeckung durchzuführen . Durch die Generierung eines umfassenden Validierungsberichts, der speziell auf die Bedürfnisse von ISO 26262-zertifizierten Organisationen zugeschnitten ist, macht es SuperGuard viel einfacher, die Integrität von Bibliothekskomponenten nachzuweisen, die in sicherheitskritischen Anwendungen verwendet werden.
