Rechtliche Belange des Software-Tests bei eingebetteten Systemen – Teil 2

Sicherheitsrisiko C und C++

Eine der vielen hier weiter nicht erwähnten Forderungen der EN 61508 an das Design von Software ist die Auswahl der Programmiersprache im Hinblick auf ihre Sicherheit. Die Norm fordert nachdrücklich ab SIL 2 die Verwendung einer streng typisierten Sprache. Nun wird für die meisten Embedded- Prozessoren aber nur ein Coder C++-Compiler angeboten. Beide Sprachen haben nicht gerade den Ruf, typensicher zu sein. Als Abhilfe wird daher dringend empfohlen, durch erweiterte Testtiefe und statische Analyse gegenzusteuern. Gerade wegen dieser bekannten Schwäche von C und C++ existiert eine Reihe von automatischen Werkzeugen, die eine strengere Typenprüfung für C und C++ vornehmen [9].

Auch wird für die Programmiersprachen C und C++ gefordert, dass nur eine Teilmenge des Sprachangebots verwendet wird. „Gefährliche“ Befehle und Praktiken sind in einem anzuwendenden Software-Coding- Standard auszuschließen. Die Einhaltung des Coding-Standards ist in den verpflichtend durchzuführenden Code-Reviews zu prüfen. Das Thema Coding- Standards für C und C++ wurde in der Elektronik schon vor einigen Jahren ausführlich behandelt [10, 11, 12]. Der inzwischen im Automobilbereich etablierte MISRA-Standard genügt allen Anforderungen der Norm. Diese sind zum Beispiel die Limitierung der Verwendung der Befehle longjump und goto sowie die eingeschränkte Verwendung von Rekursionen und dynamischen Objekten.

Testplanung

Die EN 61508 übernimmt vom IEEE Std 1012 einige Forderungen. Dazu gehören z.B. die Erfordernis eines Phasenmodells für die Entwicklungs- und Testplanung, die Review der Software- Anforderungen bezüglich Testbarkeit und das Konfigurationsmanagement der Testpläne und -ergebnisse. Ebenso gibt es die Forderung, in Testfällen die erwarteten Ergebnisse und Toleranzen zwingend zu definieren und das Test- Ende-Kriterium schon im Planungsstadium für alle Teststufen zu definieren.

Die EN 61508 fordert „wo anwendbar“ den Einsatz automatisierter Testwerkzeuge. Der Einsatz von Analyse als Methode der Validierung anstelle von Tests wird gestattet, doch sei die bevorzugte Validierungs-Methode der Test an der Ziel-Hardware. Beim Thema nichtfunktionale Systemtests hat die EN 61508 höhere Anforderungen als die anderen erwähnten Standards. Funktionale Systemtests überprüfen die Erfüllung der Anforderungen. Nichtfunktionale Tests blicken auch links und rechts davon. In der Norm wird unter anderem ein Test mit zu hoher Last und einer mit zu hohem Datenvolumen vorgeschlagen. Auch wird gefordert, Irrtümer des Bedienungspersonals als Testfälle zu definieren, und auch „vernünftigerweise vorhersehbare abnormale Zustände“ müssen getestet werden. Weiter muss getestet werden, ob ungültige Eingaben oder unplausible Initialisierungswerte bzw. unerlaubte Datenmanipulation erkannt werden.

Ganz wichtige Planungsschritte sind für die EN 61508 die Dokumentation der notwendigen Schritte, wenn man beim Testen eine Abweichung findet, sowie die Dokumentation der Abweichung selbst. In Sachen Testdokumentation erweitert die EN 61508 die Forderungen des IEEE Std 829- 1998 um eine chronologische Aufzeichnung aller Validierungstätigkeiten und die Dokumentation aller Kalibrierungsdaten der verwendeten Testmittel.

Vor allem im Fall einer Klage ist diese Dokumentation für den Hersteller der Software essentiell, um die Durchführung der Tests im erforderlichen Umfang nachweisen und eventuelle Haftungsansprüche des Kunden abwehren oder zumindest mindern zu können.