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

Wahl der Testdaten

Für alle Arten der Software-Entwicklung, egal ob sicherheitsrelevant oder nicht, ist anerkannt, dass Programme nicht mit allen möglichen Daten getestet werden können. Es entspricht dem Stand der Technik, Äquivalenzklassen von Eingangs- und Ausgangsdaten zu bilden und dann für den Test nur wenige Vertreter dieser Klassen zu wählen. Am besten nimmt man Grenzwerte der verschiedenen Klassen und kombiniert diese geschickt mit Grenzwerten anderer Klassen (Grenzwertanalyse).

Gelingt dem Hersteller einer Software der Nachweis, dass ein unfallverursachender Compilerfehler trotz Modultest mit 100 % Verzweigungsabdeckung und gewissenhafter Testdatenwahl gemäß einer Grenzwertanalyse nicht zu finden war, so haftet er aller Wahrscheinlichkeit nach nicht, weil der Fehler nicht mit Testmethoden zu finden war, die dem Stand der Technik entsprechen.

In puncto Test von Software Eingebetteter Systeme hat die EN 61508 durch ihre Anwendbarkeit für Hardware einiges mehr zu bieten als die anderen Standards. Sie erwähnt die notwendige Verifikation der Toleranz des Versagens von Sensoren und Aktoren (oder die Einleitung von entsprechenden Maßnahmen) sowie das Erkennen von verfälschten Daten an Kommunikationsschnittstellen der Software.

Nachdem für Hardware die Ausfallarten- und Effektanalyse (Failure Mode and Effect Analysis, FMEA) als wichtiges Instrument zur Bestimmung des Diagnosedeckungsgrads und in weiterer Folge zur Bestimmung der Sicherheitsintegrität gefordert ist, ist diese Forderung des Einbezugs für die auf der Hardware operierende Software nur naheliegend. Von einem amerikanischen Kfz-Hersteller ist uns bekannt, dass er wegen des Haftungsrisikos daher im Rahmen von Tests die FMEA seiner Steuergerätezulieferer überprüft. Dabei wird im serienreifen Fahrzeug während der Fahrt jeder einzelne Pin am Steuergerät mit dem Pluspol der Batterie kurzgeschlossen, mit dem Minuspol kurzgeschlossen oder seine Verbindung unterbrochen und offen gelassen. Danach wird geprüft, ob die Software adäquate Ersatzreaktionen anbietet, ob die Fahrsicherheit gefährdet wurde und ob die Diagnosefunktion des Steuergeräts den Fehler erkannte und für das Werkstättenpersonal die richtigen Fehlercodes gespeichert hat.

Die EN 61508 spricht eine sehr klare Sprache, was die Wiederverwendung von Software angeht. Für fertig übernommene Software wird das gleiche Testausmaß gefordert wie für neu geschriebene Software. Schlussfolgerung: Das bedeutet, dass ein Hersteller von sicherheitsrelevanter Software bei der Einbindung von Open-Source-Code alle Verifikationsschritte selbst durchführen muss und damit auch für Fehler des Codes so haftet, als hätte er ihn selbst geschrieben.

Achtung: Es gibt unter den IT-Juristen aktuell die verbreitete und gut begründete Auffassung, dass der Einsatz von Open-Source-Software, jedenfalls im Bereich sicherheitsrelevanter Software, an sich bereits ein grob fahrlässiges Verhalten darstellt, weil bei Open Source der Herstellungsprozess intransparent ist und zudem nicht aufgeklärt werden kann, ob nicht einer der (Vor-)Autoren illegal Code kopiert hat und so Schutzrechte Dritter verletzt.

Wird sicherheitsrelevante Software geändert, so muss nachweislich analysiert werden, welche Teile der Software neu getestet werden müssen. Im Sinne der Produkthaftung ist es ratsam, alle sicherheitsrelevanten Funktionen neu zu testen. Dies ist zum Beispiel bei der Herstellung von Software für Motorsteuergeräte gelebte Praxis.