Kosteneffektive Modul- und Integrationstests gemäß ISO 26262

Das moderne Automobil ist ein Konglomerat aus miteinander interagierenden elektromechanischen Systemen. Viele diese Systeme, wie zum Beispiel Bremsen, Lenkung, Antriebsstrang und Fahrassistenzsysteme, sind entscheidend für die Sicherheit und für Menschenleben, während dies für andere Anwendungen wie etwa die Unterhaltungselektronik nicht in so hohem Maße gilt. Alle Systeme aber stützen sich auf Software, deren Umfang exponentiell zunimmt, und in vielen Designs nutzen die Teilsysteme auch dieselbe interne Kommunikations-Infrastruktur. Dies führt dazu, dass bei der Entwicklung und Prüfung des Codes die funktionale Sicherheit berücksichtigt werden muss, und zwar sowohl für das System insgesamt als auch für die unabhängigen Teilmodule.

Zweck und Geltungsbereich der ISO 26262

Die ISO 26262 ist eine Norm für die funktionale Sicherheit von Straßenfahrzeugen. Sie definiert die Anforderungen und Prozesse zur Sicherstellung der funktionalen Sicherheit über ein Spektrum von Klassifizierungsstufen, die als „Automotive Safety Integrity Levels“ (ASIL) bezeichnet werden. Die ASILs legen die Maßnahmen zur Wahrung der funktionalen Sicherheit von Level A (geringste Gefährlichkeit) bis Level D (höchste Gefährlichkeit) fest. Der von der ISO 26262 spezifizierte Prozess beginnt bei den allgemeinen Anforderungen und umfasst die Spezifikation der eigentlichen Sicherheitsanforderungen, das Design der Softwarearchitektur sowie die eigentliche Codierung und Implementierung der Funktionsmodule. Hinzu kommen Schritte zum Testen und Verifizieren dieser Module.

Die notwendige detaillierte Spezifikation der Anforderungen an das Systemdesign und der Sicherheitsanforderungen kann auf einer recht abstrakten Ebene erfolgen, nämlich mit Spreadsheet- und Textverarbeitungs-Programmen, aber auch mit formelleren Anforderungsverwaltungs-Tools. Allerdings müssen diese Anforderungen Eingang in die einzelnen Softwarekomponenten finden, mit denen sie umgesetzt werden, sowie in die Verifikations-Aktivitäten, mit denen sie geprüft werden. Gemäß der ISO 26262 ist die bidirektionale Rückverfolgbarkeit entscheidend zur Gewährleistung eines transparenten und offenen Entwicklungs-Lebenszyklus. Wenn Code umgeschrieben werden muss, ist es außerdem wichtig zu verstehen, aus welcher übergeordneten Anforderung er abgeleitet wurde.

Design und Prüfbarkeit von Softwarearchitekturen

Auch wenn die Bezeichnung „Design for Testability“ ein oftmals überfrachteter Begriff ist, wird das zugrundeliegende Konzept in der ISO 26262 klar formuliert. Das in Abschnitt 7 der Norm behandelte Design der Softwarearchitektur zielt auf eine Softwarearchitektur, die den Anforderungen an die Softwaresicherheit genügt. In dieser frühen Phase werden häufig Modellierwerkzeuge genutzt, um den Lösungsraum für die Softwarearchitektur abzustecken. Einige Unternehmen setzen beim übergeordneten Design noch auf manuelle Methoden, das heißt auf Dokumente und abstrakte Codierung unter Weglassung des detaillierten Verhaltens.

Unabhängig von der verwendeten Methode ist es während des Designs und der Implementierung erforderlich, das Architekturdesign zu verifizieren. Bei niedrigeren ASILs wie A oder B können Techniken wie zum Beispiel informelle Begutachtungen und Inspektionen ausreichen. Geht es aber um die höheren ASILs C oder D, ermöglichen Automatisierungs-Techniken den Entwicklern kosteneffektive Architekturanalysen und -prüfungen, zu denen auch gründliche Kontroll- und Datenfluss-Analysen gehören. Letztendlich sollte das Architekturdesign gemäß der Norm ISO 26262 zu einer gut ausgearbeiteten Softwarearchitektur hinführen, die prüfbar ist und sich zu ihren Funktionssicherheits-Anforderungen zurückverfolgen lässt.

Die ISO 26262 verlangt ferner nach einer hierarchischen Strukturierung der Softwarekomponenten, und zwar für alle ASILs. Hinsichtlich der Qualität enthält die Norm exemplarische Richtlinien wie die folgenden:

• Softwarekomponenten sollten in ihrer Größe beschränkt und lose mit anderen Komponenten gekoppelt sein.
• Sämtliche Variablen müssen initialisiert werden.
• Es sollten keine globalen Variablen verwendet werden, solange ihre Nutzung nicht gerechtfertigt ist.
• Es sollte keine impliziten Typumwandlungen, unbedingten Sprünge oder verdeckte Daten- oder Kontrollflüsse geben.
• Dynamische Objekte oder Variablen sind zu prüfen, sofern sie überhaupt verwendet werden.

Ohne Automation wäre es sehr mühsam, teuer und fehleranfällig, das jeweils implementierte Modul nach diesen Regeln und Empfehlungen zu prüfen.

Codierstandards und -richtlinien

Im Rahmen der Anforderungen der Norm ISO 26262 trägt die Implementierung der Softwaremodule zum Entstehen einer qualitativ hochwertigen Applikation bei, die sich besser prüfen lässt. Die ISO 26262 verlangt die Verwendung eines Codierstandard, ohne aber einen bestimmten Standard vorzuschreiben. In Frage kommende Standards und Richtlinien wie MISRA C:2012, MISRA C++:2008, SEI CERT C oder CWE haben alle das Ziel, potenzielle Safety- und Security-Risiken zu beseitigen. Sie werden dabei durch automatisierte Toolpakete unterstützt. Regelmäßig überprüfen und durchsetzen lassen sich die Codierrichtlinien mithilfe eines integrierten statischen Analysetools, das den Quellcode untersucht und alle Abweichungen vom gewählten Standard markiert.

Bild 1: Zuordnung der Fähigkeiten einer automatisierten Toolchain zu den Prozessrichtlinien der ISO 26262. LDRA

Über die Einhaltung der Codierstandards hinaus, können vollintegrierte Softwaretools auch Richtlinien für das Qualitätsdesign von Softwaremodulen prüfen und durchsetzen und deren Integration und Prüfung gemäß der definierten Softwarearchitektur und den Systemanforderungen erleichtern. Die Anwendung und Durchsetzung solcher Prinzipien beim Codieren der einzelnen Module erhöht die Sicherheit, dass die Module innerhalb der definierten Softwarearchitektur zusammenpassen und miteinander funktionieren. Im Idealfall sollte ein integriertes Toolpaket diese automatisierten Funktionen so miteinander abgleichen, dass sie sich auf alle Entwicklungsstufen nach dem standardmäßigen V-Modell (Bild 1) anwenden lassen und in der Lage sind, die Rückverfolgbarkeit der Anforderungen, die Analyse und das Testen über alle Phasen der Produktentwicklung hinweg zu koordinieren.

Statische Analyse und Softwaremodul-Test

Bild 2: Die statische Analyse kann die Kontroll- und Datenkopplung eines Softwaremoduls untersuchen. LDRA

Aus einem breiteren Blickwinkel betrachtet, zielen die in der ISO 26262 beschriebenen Vorgehensweisen darauf, den Code besser verständlich, zuverlässiger, weniger fehleranfällig, sowie einfacher prüf- und pflegbar zu machen. Durch Einschränken des Umfangs der Softwarekomponenten und ihrer Schnittstellen erreicht man beispielsweise, dass sie einfacher zu lesen, zu pflegen und zu prüfen und damit von Anfang an weniger fehleranfällig sind. Die statische Analyse kann eine Vielzahl von Richtlinien überprüfen, um sicherzustellen, dass Variablen initialisiert werden und auf die Benutzung von globalen Variablen und Rekursionen verzichtet wird. Die Existenz globaler Variablen zum Beispiel kann in einem großen Programm Verwirrung stiften und das Prüfen erschweren. Wendet man die statische Analyse während der gesamten Codeimplementierungs-Phase an, werden Regelverletzungen sofort bei ihrem Auftreten markiert und man erhält am Schluss die Bestätigung, dass keine mehr vorliegen. Darüber hinaus können Tools Komplexitäts-Maßzahlen generieren, mit denen es möglich ist, Umfang, Komplexität, Zusammenhalt und Kopplung von Softwarekomponenten zu messen und zu kontrollieren (Bild 2).

Das Testen der Softwaremodule liefert den Nachweis, dass jedes Softwaremodul (das heißt jede Funktion oder Prozedur) die Designspezifikationen für das jeweilige Modul erfüllt und keinerlei unerwünschtes Verhalten birgt. Ist dieser Nachweis erbracht, wird mit Modulintegrationstests die fortlaufende Korrektheit dieses Verhaltens demonstriert, wenn die Module als Bestandteil eines Systems eingesetzt werden, und anschließend gezeigt, dass diese Integration die zuvor auf einer höheren Ebene geplante Softwarearchitektur umsetzt. Möglicherweise handelt es sich bei dem ultimativen Integrationstest um einen Systemtest, in dem die gesamte Software als ein zusammenhängendes Ganzes ausgeführt wird.

Modultests und Modulintegrationstests nutzen diesen Rahmen als Grundlage, um eine Teilmenge dieser Codebasis auszuführen und den Nachweis zu erbringen, dass die Funktionalität der Softwareschnittstellen mit den Spezifikationen und Anforderungen des Softwaredesigns in Einklang steht. In diesem Zusammenhang muss unter anderem sichergestellt werden, dass nur diese Anforderungen erfüllt werden und dass die Software keine nicht benötigten (und somit auch keine unerwünschten) Funktionalitäten enthält. Die gleichen Modultest-Ressourcen lassen sich nutzen, um Fehlereinstreuungs-Tests für die funktionale Sicherheit zu erstellen, die Ressourcennutzung zu messen und falls angebracht auch sicherzustellen, dass sich automatisch generierter Code gemäß dem Modell verhält, von dem es abgeleitet wurde.

Die statische Analyse kann eine automatisierte „Inspektion“ des Quellcodes vornehmen, um die Einhaltung der ISO 26262-Richtlinien für die Codierung und Modulimplementierung zu verifizieren. Darüber hinaus lassen sich die aus der statischen Analyse abgeleiteten Informationen jedoch auch nutzen, um ein Gerüst für die dynamische Analyse (also die Analyse des ausgeführten Codes) zu schaffen. Im Idealfall sollte die gesamte dynamische Analyse unter Verwendung der Zielhardware erfolgen, damit etwaige Probleme, die aus deren Einschränkungen resultieren, so früh wie möglich zu Tage treten. Ist die Zielhardware in den frühen Phasen eines Projekts nicht verfügbar, sollte der Code in einer simulierten Umgebung auf der Basis der Verifikations-Spezifikation verarbeitet werden. Auf diese Weise kann die Entwicklung weiter voranschreiten – wenn auch unter dem Vorbehalt, dass Tests auf der tatsächlichen Zielhardware zum Schluss immer noch erforderlich sind.

Gesicherte Rückverfolgbarkeit

Die Integrationstests sollen sicherstellen, dass alle Module reibungslos sowie im Einklang mit dem Architekturdesign und den Anforderungen zusammenarbeiten. Im Fall eines ISO-26262-konformen Projekts schließt dies die Verifikation der Funktionen, die mit den Softwaresicherheits-Anforderungen gemäß ISO 26262 zusammenhängen, ebenso ein wie die allgemeiner gehaltenen funktionalen Anforderungen. Auch diese Tests können zunächst eine simulierte Umgebung nutzen, jedoch verlangt die ISO 26262 dann eine Analyse der Unterschiede zwischen Quell- und Objektcode sowie zwischen Test- und Zielumgebung, um zusätzliche Tests für die ultimative Verwendung in der Zielumgebung zu spezifizieren. Bevor die Zertifizierung erfolgen kann, sind Tests auf der Ziel-Hardware unter allen Umständen notwendig.

Wann immer Tests fehlschlagen, muss wahrscheinlich Code überprüft werden. Ebenso kann es sein, dass sich mitten in einem Projekt die Anforderungen ändern. In beiden Fällen sind alle betroffenen Module zu identifizieren, und die zugehörigen Modul- und Integrationstests sind zu wiederholen. Glücklicherweise lassen sich derartige Regressionstests automatisieren und systematisch erneut anwenden, um sicherzustellen, dass neu hinzugekommene Funktionalitäten keine negativen Auswirkungen auf bereits implementierte und erprobte Module haben.

Bild 3: Entwickler geben Inputs und erwartete Outputs in die LDRA-Tools-Suite. Die tatsächlichen Outputs werden dann erfasst und mit den erwarteten Outputs verglichen. LDRA

Die fortlaufende Sicherstellung, dass der Code die Anforderungen genau wiedergibt, ist besonders für Modultests und die Integration von Bedeutung. Die Inputs und erwarteten Outputs dieser Tests werden ebenso von den Anforderungen abgeleitet wie die Tests für Fehlerprüfung und Robustheit (Bild 3). Wenn Module in den Kontext ihrer jeweiligen Aufrufbäume integriert werden, können die gleichen Prüfdaten erneut benutzt werden.

Modul- und Integrationstests mit dynamischer Analyse stellen auf korrekte Weise die Softwarefunktionen sicher – sowohl als Modul als auch im Zusammenspiel mit den anderen Modulen des Gesamtprogramms. Allerdings ist es im letzteren Kontext auch notwendig, einerseits die Vollständigkeit solcher Tests zu evaluieren und sich andererseits zu vergewissern, dass keine nicht gewünschten Funktionalitäten vorhanden sind. Funktions- und Aufrufüberdeckungs-Analysen ermitteln, ob alle Aufrufe ausgeführt und alle Funktionen aufgerufen wurden. Allerdings bedarf es einer gründlicheren Untersuchung der Struktur, indem die Anweisungs- und Verzweigungs-Überdeckung ermittelt wird. Diese gewährleistet, dass jede Anweisung mindestens einmal ausgeführt wurde und dass jede mögliche Verzweigung an jedem Entscheidungspunkt mindestens einmal gewählt wurde.

Wenn an einem solchen Entscheidungspunkt mehrere Bedingungen betrachtet werden müssen, kann die Anzahl möglicher Kombinationen schnell dazu führen, dass das Testen aller Möglichkeiten nicht mehr praktikabel ist. Mit der MC/DC-Technik (Modified Condition/Decision Coverage) lässt sich die Zahl der in einer solchen Situation erforderlichen Testfälle reduzieren, indem nur der Nachweis erbracht werden muss, dass jede Kombination das Ergebnis unabhängig beeinflussen kann.

Bild 4: Die strukturelle Überdeckungsanalyse der Applikation korreliert die internen Funktionen der Module und deren Schnittstellen mit dem Architekturdesign des Systems. LDRA

Die Überdeckungsanalyse auf der Modulebene verifiziert die Bedingungen innerhalb des betreffenden Moduls, führt aber offensichtlich keine Aufrufe außerhalb dieses Moduls aus. Modul-, Integrations- und Systemtests können gemeinsam zum Überdeckungsgrad des gesamten Projekts beitragen (Bild 4).

Um dies in den richtigen Zusammenhang zu bringen: Die Funktionen der Softwaremodule werden durch das Design der Softwarearchitektur vorgegeben, die wiederum durch die Anforderungen bestimmt wird. Die Anforderungen und die Architektur, die somit die Module definieren, legen auch fest, welche Tests durch die einzelnen Module benötigt werden. Bei der Integration der Module werden diese wiederum auf ihre funktionale Interaktion sowie daraufhin geprüft, ob sie dem Design der Softwarearchitektur und (im Fall von ISO 26262) auch den Funktions- und Sicherheits-Anforderungen entsprechen.

Bild 5: Die Traceability-Funktion von LDRA zeigt ein detailliertes Design, das in Upstream-Richtung mit den Software-Anforderungen verknüpft ist. LDRA

Die Anforderungen ganz oben im V-Modell (Bild 1) werden häufig mit besonderen Anforderungs-Werkzeugen wie IBM Rational DOORS oder Modellier-Tools wie Mathworks Simulink definiert. Die Verwendung eines Softwaretool-Pakets, das an solche Tools angeschlossen werden kann, kann sich als Vorteil bei der Verifikation der von der ISO 26262 verlangten bidirektionalen Rückverfolgbarkeit erweisen, selbst wenn Modelliertools zur automatischen Generierung des Quellcodes verwendet werden (Bild 5). Diese automatisch generierten Module unterliegen den gleichen rigorosen Test-, Verifikations- und Integrations-Prozeduren wie manuell codierte Module, Bestands-Code und Open-Source-Code.

Automatisierte Test- und Verifikations-Tools

Es ist einfach, sich die Entwicklung als einen schrittweisen Prozess vorzustellen, in dem das Testen irgendwann im Anschluss an die Codierung folgt. Allerdings ist regelmäßiges Testen schon während der Entwicklung im Verbund mit der bidirektionalen Anforderungs-Nachverfolgung entscheidend, denn der Zeit- und Kostenaufwand wird umso größer, je später ein Fehler aufgedeckt wird.

Angesichts all dieser gleichzeitig ablaufenden Aktivitäten ist es mit traditionellen Mitteln ein Alptraum, ständig über den Projekt- und Rückverfolgungs-Status auf dem Laufenden zu bleiben. Zum Beispiel kann die Ursache eines fehlgeschlagenen Integrationstests in widersprüchlichen Anforderungen liegen, mit denen sich bei frühzeitiger Entdeckung wesentlich einfacher umgehen lässt. Müssen die Anforderungen dagegen in einem späteren Stadium abgeändert werden, hat dies unweigerlich Folgewirkungen für das gesamte Projekt. Man muss sich fragen, welche anderen Teile der Software betroffen sind und wie weit zurück man modifizieren und testen muss, damit die Änderung sicher berücksichtigt wird.

Ein ähnlich ungünstiges Szenario entsteht bei der späten Aufdeckung eines Programmierfehlers. Welche anderen Module hängen von diesem Code ab? Was passiert, wenn eine der Anforderungen eine unkorrekte Spezifikation enthält, aber die Modultests schon durchgeführt wurden und damit nun zumindest verdächtig sind? Wie lässt sich die Gewissheit erlangen, dass alles korrigiert wurde?

In solchen Situationen stößt die manuelle Anforderungsverfolgung irgendwann an ihre Grenzen. Bestenfalls bleibt nur ein Gefühl der Unsicherheit zurück. Wie immer man die Anforderungen zusammenführt, welches Designkonzept man auch anwendet, ob man modellgenerierten oder manuell geschriebenen Code verwendet – automatisierte Prüf- und Verifikationswerkzeuge beschränken sich nicht darauf, nur den Status eines bestimmten Entwicklungsabschnitts zu melden. Ein integriertes Toolpaket kann vielmehr Rückverfolgbarkeit zwischen den Anforderungen, dem Design und dem Quellcode bieten – von den maschinennächsten Funktionen und ihren Testergebnissen bis zu den spezifizierten Anforderungen. Wenn man von der ersten Idee bis zum fertigen, zuverlässig und sicher arbeitenden System in Sachen ISO 26262 auf Kurs bleiben möchte, bedingt dies die ununterbrochene Aufmerksamkeit und einen Sinn fürs Detail – und damit etwas, womit nur automatisierte Tools aufwarten können.