Rechtliche Belange des Software-Tests bei eingebetteten Systemen
Fortsetzung des Artikels von Teil 2
Rechtliche Belange des Software-Tests bei eingebetteten Systemen
Beispiel: Ein Tankwagen mit elektronischer Abfüllvorrichtung verliert durch einen Software-Fehler im Steuergerät der Vorrichtung während der Fahrt eine beträchtliche Menge Heizöl. In Folge kommt es zu einem Unfall mit zwei Verletzten. Die Geschädigten können nun vom Tankwagenhersteller Schmerzensgeld und Schadenersatz verlangen. Diese Forderung kann der Tankwagenhersteller nicht zurückweisen. Der Tankwagenhersteller kann sich dieses Geld aber vom Hersteller des Steuergeräts für die Abfüllvorrichtung zurückholen, soweit im Vertrag zwischen Tankwagenhersteller und dem Steuergerätehersteller die Haftung für Software-Fehler nicht beschränkt worden ist. Wenn sich herausstellt, dass weitere in Betrieb befindliche Tankwagen einen Personenoder Sachschaden verursachen können, muss der Tankwagenhersteller zudem eine Rückrufaktion starten. Die Rückrufkosten kann der Tankwagenhersteller wiederum – vorbehaltlich einer wirksam vereinbarten Haftungsbeschränkung – gegenüber dem Hersteller des Steuergeräts geltend machen. Der Hersteller haftet im Rahmen der Produkthaftung jedoch nicht für Vermögensschäden, also z.B. wegen eines entgangenen Großauftrags infolge des Imageverlusts.
Das Beispiel zeigt, dass die durch einen Software-Defekt entstehenden Kosten schnell die Größenordnung des gesamten Firmenwerts eines kleinen bis mittleren Steuergerätelieferanten erreichen können. Geht der Zulieferer durch die Forderungen Bankrott, so muss der Tankwagenhersteller die Kosten selbst übernehmen. Einige Automobilhersteller verlangen daher von ihren Steuergeräte-/Software-Zulieferern die Abgabe der Testprotokolle, selbst wenn der Zulieferer die volle Haftung übernimmt. Schlussfolgerung: Ein Hersteller von sicherheitsrelevanter Software benötigt einen ausreichenden Versicherungsschutz für Betriebshaftpflicht- und Rückrufschäden.
Jobangebote+ passend zum Thema
Sorgfaltspflicht des Software-Herstellers
Bei der Erstellung der Software erwartet der Gesetzgeber die Befolgung des Stands der Wissenschaft und Technik, um Fehler weitgehend und angemessen auszuschließen. Das heißt, es sind zumindest die applikablen Normen zu beachten. Für den Fall von sicherheitsrelevanten Systemen ist das die Europäische Norm 61508. Eine Befolgung der Normen ist zwar notwendig, aber nicht hinreichend. Bis Entwicklungs- und Testmethoden in Normen Einzug halten, müssen sie sich erst bewähren. Die Erstellung einer Norm benötigt viel Zeit. Der Software-Hersteller ist daher gefordert, neben der Befolgung der Normen auch den aktuellen Stand der Wissenschaft und Technik zu beurteilen und seine Entwicklungs- und Testvorgänge danach auszurichten. Die ausgewählten qualitätssichernden Maßnahmen sind zu dokumentieren. So müssen Protokolle von Design-Reviews, Aufzeichnungen von Code-Inspections oder Testprotokolle zum Nachweis der Durchführung der Maßnahmen aufbewahrt werden. Ohne eine saubere Dokumentation und ohne korrektes Konfigurationsmanagement hat man als Software-Hersteller schlechte Karten im Falle einer Haftungsklage. Diese Protokolle müssen aus haftungsrechtlicher Sicht so lange aufgehoben werden, solange Ansprüche der Produktnutzer geltend gemacht werden können, d.h. solange durch die Produkte Schäden entstehen können plus die jeweils geltenden Verjährungsfristen der möglichen Ansprüche. Diese Verjährungsfristen können – je nach Haftungsgrund – sehr unterschiedlich lang sein.
Aber nicht nur die Dokumentation der qualitätssichernden Maßnahmen, auch die Überprüfung von deren Wirksamkeit ist vorzunehmen und gegebenenfalls zu verbessern. Dieser „Regelkreis“ erinnert schon stark an Reifegradmodelle wie CMM oder SPICE [4].
Beispiel: Im folgenden Fall konnte der Software-Hersteller durch einen guten und sorgfältig eingehaltenen Entwicklungsprozess einen Anspruch des Kunden auf Rückabwicklung des Vertrags abwehren [15]: Der Kunde hatte eine Software-Lösung bestellt, die auf einem Standardprodukt basiert, jedoch waren starke individuelle Anpassungen und Ergänzungen gewünscht. Der Lieferant erstellte eine detaillierte Spezifikation, in Ermangelung von Kundenmitwirkungen sowohl Lasten- als auch Pflichtenheft. Dabei hielt er sich an seinen wohldefinierten und dokumentierten Prozess, ließ sich die Spezifikation vom Kunden in einer Review bestätigen und realisierte die spezifizierten Anforderungen. Während der Realisierung veränderte sich die Situation beim Kunden, wobei der Kunde jedoch den Lieferanten darüber nicht informierte. Bei Lieferung der Software wurde diese vom Kunden abgelehnt und der Kunde stellte Ansprüche gegen den Lieferanten bzw. wollte vom Vertrag zurücktreten. Der Lieferant verwies auf seine klar definierte Vorgehensweise und seine entsprechend diesem Vorgehen erstellten Dokumente. Es waren alle Schritte von der ersten Kommunikation mit dem Kunden über die Realisierung und den Test bis zur Auslieferung nachweisbar. Vor Gericht wurde daher dem Lieferanten Recht gegeben.
- Rechtliche Belange des Software-Tests bei eingebetteten Systemen
- Rechtliche Belange des Software-Tests bei eingebetteten Systemen
- Rechtliche Belange des Software-Tests bei eingebetteten Systemen
- Produzentenhaftung bei Software
- Rechtliche Belange des Software-Tests bei eingebetteten Systemen
