computerwoche.de

Archiv

Es gibt Konstruktions-, Fabrikations-, Instruktions- und Beobachtungsfehler

Fehler im Produktionsprozeß: Ursache oft im der Software

02.03.1990

Unmöglich soll es sein, komplexe Programme vollständig auf Fehlerfreiheit zu testen. Aber genügt dies als Entschuldigungsrund? Jedenfalls müßte der Hersteller beweisen, daß er den Fehler nicht erkennen konnte, was selten möglich sein wird.

Der Gesetzesentwurf enthält in ° 3 Abs. 1 die bereits zitierte Definition des Fehlerbegriffs. Die bisherige Rechtsprechung unterscheidet zwischen folgenden Fehlerkategorien, die jeweils haftungsauslösend werden können:

- Konstruktionsfehler,

- Fabrikationsfehler,

- Instruktionsfehler und

- Produktbeobachtungsfehler.

Daran dürfte sich nichts wesentliches ändern, sieht man davon ab, daß es speziell für die Produktionsbeobachtungspflicht beim bisherigen Recht bleibt, nachdem sie in Gesetz und Richtlinie nicht ausdrücklich er. wähnt ist.

Beim Konstruktionsfehler ist das Produkt - hinsichtlich der Gefahrabwendungspflicht - beispielsweise vermeidbare Selbstentflammungsgefahr, unzulässige Isolierungen, fehlerhaft. Beim Fabrikationsfehler ist der Herstellungsprozeß fehlerhaft organisiert oder mit anderen Mängeln behaftet (beispielsweise Verwendung minderwertigen Materials statt Goldlegierung bei PIN-Steckern mit der Folge von Übertragungsfehlern), was dazu führt, daß einzelne Exemplare des Produkts mit Fehlern gesehen sind. Instruktionsfehler liegen von, wenn entweder die Bedienungsanleitung auf bestimmte Gefahren nicht aufmerksam macht (wie Datenverlustrisiken) oder aber sogar Anweisungen enthält, die solche Gefahren auslösen können.

Fabrikationsfehler bei Software sehr selten

Für Software typisch sind Konstruktionsfehler, sprich Programmierungsfehler, und Instruktionsfehler, während Fabrikationsfehler nur ganz ausnahmsweise auftreten werden. Denn komplex ist hier das "Design" des Produkts, während die Herstellung der Datenträger nicht besonders fehlerträchtig ist. Programmierungsfehler können allerdings zu Fabrikationsfehlern führen, wenn beispielsweise keine gleichbleibende Produktqualität hergestellt wird, oder wenn bei der Ausgangskontrolle Fehler unbemerkt bleiben. Soweit heilte im Produktionsprozeß überhaupt Fehler auftauchen, werden diese sehr häufig auf Softwarefehler zurückzuführen sein, da sowohl die Qualitätskontrolle als auch der eigentliche Produktionsprozeß aber die Regel- und Steuertechnik immer stärker mit Software durchsetzt werden, und sich selbst Materialfehler oft auf fehlerhafte Qualitätskontrollprogramme in der vorherigen Produktionsstufe zurückführen lassen.

Der "Entwicklungsfehler" ist in Wirklichkeit ein Entschuldigungsgrund: War der Fehler nämlich nach dem Stand von Wissenschaft und Technik zum Zeitpunkt des Inverkehrbringens für den Hersteller noch nicht erkennbar, so entfällt nach bisherigem Recht die Haftung. Gesetzesentwurf und Richtlinie haben den Entwicklungsfehler nunmehr als Entschuldigungsgrund akzeptiert, nachdem im ersten Richtlinienvorschlag von 1979 auch insofern noch eine strikte "Garantiehaftung" vorgesehen war. Allerdings können hier Produktbeobachtungspflichten verletzt sein. Der Hersteller ist nämlich verpflichtet, die Produkte auch nach ihrer Übereignung an Dritte auf Gefahren zu beobachten. Er muß gegebenenfalls die Nutzer und die Öffentlichkeit auch nachträglich auf solche Gefahren aufmerksam machen oder Rückrufaktionen durchführen. Richtlinie und Gesetzesentwurf verpflichten allerdings nicht zu Produktbeachtung und Rückruf, weswegen insoweit Schadensersatz nur aufgrund eines schuldhaften Fehlverhaltens nach Deliktsrecht verlangt werden kann.

Besonders bedeutsam scheint der Entwicklungsfehler bei Softwaremängeln zu sein. Denn nach einer weit verbreiteten Ansicht ist es grundsätzlich unmöglich, fehlerfreie Programme herzustellen, wenn diese eine bestimmte Komplexität haben. Viele Chips wie Logikbausteine haben beispielsweise eine sehr große Anzahl möglicher Eingangszustände. Nur ein Teil dieser möglichen Eingangszustände läßt sich mit vertretbarem Aufwand testen, und zwar häufig nur in einem Black-Box-Verfahren. Das führt zwangsläufig zu einer Möglichkeit nie getesteter Eingangs- und Ausgangszustände in der praktischen Anwendung. Besonders gilt dies bei der Kombination mit anderen Logikbausteinen. Auch sind bisweilen die IC's bereits physisch fehlerhaft, was ebenfalls zu Steuerungsfehlern führen kann. Ein solcher, vermutlich durch menschlichen Schweiß ausgelöster Defekt, verzögerte beispielsweise wochenlang den Start der Raumfähre Discovery.

Kann man sich nun mit dem Argument entschuldigen, ein aufgetretener Fehler hätte mit vertretbarem Aufwand nicht erkannt werden können.

Die allgemeine Aussage, daß Software nie fehlerfrei sei, reicht in ihrer Pauschalität als Entschuldigung sicher nicht aus. Es kommt vielmehr darauf an, ob das Austesten auf Fehlerfreiheit mit Hinblick auf den aufgetretenen Fehler möglich gewesen wäre. Dabei gilt: je gefährdender das Produkt, desto höher die Anforderungen an die Fehlerfreiheit und die Testung. Je näher die Möglichkeit beispielsweise von inkompatiblen Gebrauchsformen, umso stärker muß getestet werden. Auf die Größe des Herstellerbetriebs kommt es nach zutreffender Ansicht nicht an, da dies die individuelle Vorwerfbarkeit, die "Schuld" betrifft, die aber zumindest für das Haftungsregime des Gesetzes keine Rolle mehr spielen soll (etwas anderes mag für die weiterwirkende Haftung nach ° 823 BGB gelten).

Zu berücksichtigen ist auch, daß der Entwicklungsfehler in seiner klassischen Ausprägung ein anderes Problem zum Gegenstand hat: daß nämlich die Möglichkeit der schadensauslösenden Wirkungen zum Zeitpunkt des erstmaligen Inverkehrbringens des Produkts nicht bekannt waren. Bei der Software wird aber nun damit argumentiert, daß die "unvollständige Beherrschbarkeit" zum Zeitpunkt des Inverkehrbringens durchaus bekannt, aber mit wirtschaftlich und zeitlich vertretbarem Aufwand nicht ausgeräumt werden konnte.

Entwicklungsfehler sind typisch

Dennoch wird man den Entwicklungsfehler als typischen "Softwareentschuldigungsgrund" grundsätzlich anerkennen können. Allerdings sollte man sich über die Reichweite dieser Entschuldigung keinen Illusionen hingeben. Nach den Anforderungen der Rechtsprechung sind Großunternehmen, die ihre Produkte weltweit vertreiben, verpflichtet, Ergebnisse wissenschaftlicher Kongresse und Fachveranstaltungen sowie die Auswertung des gesamten internationalen Fachschrifttums zu verfolgen (Kullmann/Pfister/Veltins 4310, S. 7 mwN). Beim Austesten der Software besteht die Schwierigkeit darin, daß dies immer nur individuell geschehen kann, so daß ein solcher allgemeingültiger objektiver Maßstab nicht besteht (die Beachtung der DIN-Vorschriften beispielsweise reicht sicher nicht aus (Kullmann/Pfister/Veltins). Er zeigt aber, wie hoch die, hier zu stellenden Anforderungen sind. Die pauschale Entlastung mit der Nichterkennbarkeit des Fehlers wird daher in ganz seltenen Fällen möglich sein, wenn insbesondere die Testungen detailliert protokolliert wurden.

Ein weiteres Problem besteht hier in der Beweislast. Der Geschädigte muß nämlich nur beweisen, daß ihm ein Schaden durch das Produkt bei eine, Verwendung entstanden ist, mit welcher der Hersteller billigerweise rechnen nette. Er muß also nur beweisen, wie das Produkt/Programm funktionierte, wie es funktionieren sollte, und daß durch die Abweichungen der Schaden hervorgerufen wurde. Will er sich entlasten, so muß sodann der Hersteller nach ° 1 Abs. 4 des Gesetzentwurfs umgekehrt vollen Beweis für das Vorliegen eines - unschädlichen - Entwicklungsfehlers führen. Der Geschädigte kann seinen Beweis auch beispielsweise durch Zeugen erbringen.

Auswirkungen von Programmierfehlern

"Reproduzierbar" muß der Fehler also - entgegen einer oft geäußerten Forderung nicht sein. Das kann für den Hersteller bei sogenannten "intermittierenden" Fehlern zu erheblichen Problemen führen. Denn nun muß er der Fehler suchen und finden. Außerdem muß der Geschädigte nicht den eigentlichen Programmierfehler bezeichnen, sondern nur, wie er sich auswirkt. Wenn der eigentliche Programmierfehler aller nicht gefunden wird, dürfte es nur sehr selten möglich sein, ihn als Entwicklungsfehler anzuerkennen und zu entschuldigen.

Kann sich der Softwarehersteller dadurch entlasten, daß er kritische Daten durch einen fachkundiger Autor Korrektur lesen läßt? Für die bisher geltende Verschuldungshaftung wurde eine solche Entschuldigung durch ein allerdings umstrittenes Urteil akzeptiert (vgl. BGH, NJW 1970, S. 1963 ff.). In Zukunft dürfte dieser Einwand zumindest bei der Haftung nach dem Gesetz abgeschnitten sein.

Ob ein großer Entwicklungsfehler vorliegt, beurteilt sich ausschließlich nach den Erkenntnissen zum Zeitpunkt des Inverkehrbringens des Programms. ° 3 Abs. 2 des Gesetzentwurfs stellt dies eindeutig klar: "Ein Produkt hat nicht allein deshalb einen Fehler, weil später ein verbessertes Produkt in den Verkehr gebracht wurde". Allerdings bleibt der Hersteller verpflichtet, seine Erzeugnisse, auch nach ihrer Übereignung an Dritte auf Gefahren zu beobachten.

Er muß gegebenenfalls die Nutzer und die Öffentlichkeit auch nachträglich auf solche Gefahren aufmerksam machen und gegebenenfalls bei hohen Gefährdungen sogar Rückrufaktionen durchführen.

Entscheidend wird damit die Frage, wann ein Programmals "in den Verkehr gebracht" anzusehen ist. Kommt es auf den Zeitpunkt an, an dem "das Programm" (im Sinne eines Werks, eines Prototyps) erstmals ausgeliefert wurde oder auf den Zeitpunkt, an dem der konkrete Datenträger, also das Vervielfältigungsstück, das Softwarehaus verlassen hat? Wohl eindeutig letzteres, denn haftungsauslösend ist nicht die Information, sondern der konkrete Gegenstand (siehe oben). Das bedeutet aber auch, daß die Produktbeobachtung für die Softwarebranche eine ganz besondere Brisanz entfaltet. Denn jedes einzelne produzierte Vervielfältigungsstück wird an dem Stand von Wissenschaft und Technik zum Zeitpunkt seiner Auslieferung gemessen. Auch überlange Lagerzeiten können hier einmal zum Problem werden. Unter diesem Gesichtspunkt war es gar nicht nötig, die "Produktbeobachtungspflicht" eigens zu erwähnen. (wird fortgesetzt)