Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Fehlerwahrscheinlichkeit bei Software

Dienstag 11. Oktober 2016

Ob in einer Software ein – möglicherweise gefährlicher – Fehler schlummert, läß sich schwer abschätzen. So schwer, dass die „alte“ DIN EN IEC 62304:2006 schrieb: „Es gibt jedoch keine Übereinstimmung, wie die Wahrscheinlichkeit des Auftretens von Software-Ausfällen unter Verwendung von traditionellen statistischen Methoden bestimmt werden kann.“

Die Norm schlussfolgerte, dass „die Wahrscheinlichkeit einer solchen Fehlfunktion als 100 Prozent angenommen werden muss“. Die hochproblematische Forderung ist in der „neuen“ IEC 62304:2015 gestrichen.

Dieser Artikel verrät Ihnen, wie Sie die Fehlerwahrscheinlichkeit bei Software realistischer abschätzen können und wann Sie das müssen.

Fehlerwahrscheinlichkeit bei Software: Wie läßt sie sich abschätzen?

Probleme mit der „alten“ DIN EN IEC 62304:2006

Die DIN EN IEC 62304:2006 (Medical Device Software – Software Life Cycle Processes) verlangt: die Wahrscheinlichkeit eines Software-Fehlers, der zu einer Gefährdung führen kann, muss mit 100% angenommen werden. Eigentlich wollten die Autoren damit ausdrücken: man soll nicht mit der Fehlerwahrscheinlichkeit bei Software argumentieren.

Ein gewichtiges Problem, das man sich damit einhandelt, ist offensichtlich: Unterstellt man bei einer standalone Software 100% Fehlerwahrscheinlichkeit, dann ist das daraus bestimmte Risiko selten akzeptabel (Abbildung 1):

Fehlerwahrscheinlichkeit bei Software

Abb 1.: Bei eine standalone Software kann eine 100% Fehlerwahrscheinlichkeit zu einer hohen Wahrscheinlichkeit eines Schadens führen.

Ein Software-Fehler (hier angenommen mit 100% Wahrscheinlichkeit) könnte wie folgt Schaden anrichten:

  • Die Software arbeitet inkorrekt: Sie zeigt fast immer (in ca. 100% der Fälle) ein falsches Medikament an.
  • Die Wahrscheinlichkeit, dass dies tatsächlich zu einer Gefährdungssituation führt (z.B. Einnahme eines falschen Medikaments), hängt davon ab, wie wahrscheinlich der Fehler entdeckt wird. Diese Wahrscheinlichkeit beträgt ≤ 100%.
  • Die Wahrscheinlichkeit wiederum, dass deshalb auch ein Schaden mit einem bestimmten Schweregrad (z.B. anaphylaktischer Schock) eintritt – und damit die Höhe des Risikos(!) – hängt in diesem Fall davon ab, wie gut der Patient die Fehldosierung verträgt. Sie dürfte definitiv kleiner als 100% betragen.

Je nach Kontext ergibt sich eine Schadenswahrscheinlichkeit zwischen 1% und weniger als 100%. In aller Regel jedoch dürfte das damit verbundene Risiko nicht akzeptabel sein.

Sie können in solchen Fällen also nicht sinnvoll mit einer 100%-igen Wahrscheinlichkeit agieren. Stattdessen wollen Sie die wirkliche Wahrscheinlichkeit von Software-Fehlern abschätzen und daraus das Risiko bestimmen.

Die „neue“ IEC 62304:2015 streicht den fatalen Passus

Die gute Nachricht lautet hier: In Amendment I der „neuen“ IEC 62304:2015 ist der Stein des Anstoßes entfernt (Abbildung 2).

IEC 62304:2015 streicht den Absatz zur Fehlerwahrscheinlichkeit

Abb. 2: IEC 62304:2015 streicht den Absatz zur Fehlerwahrscheinlichkeit

Dafür schreibt die Norm jetzt: „There is no known method to guarantee 100 % SAFETY for any kind of software.“ Dieser Trivialaussage kann man in den für Medizinproduktehersteller relevanten Fällen zustimmen. (Anmerkung: Den Begriff der Safety in diesem Zusammenhang zu nutzen, könnte man in einer nächsten Version der Norm überdenken.)

Die „neue“ IEC 62304 schreibt zwar auch noch: „Probability of a software failure shall be assumed to be 1“. Doch macht die Norm klar, dass sie dies nur für einen ganz bestimmten Kontext meint: „In determining the software safety classification of the software system“.

Die IEC 62304:2015 sagt somit nicht, dass für Software stets eine 100% Fehlerwahrscheinlichkeit anzunehmen ist. Für Risikoeinschätzungen beispielsweise dürfen Sie mit realistischeren Fehlerwahrscheinlichkeiten agieren.

Was unter der Fehlerwahrscheinlichkeit bei Software zu verstehen ist

Bei Fehlern gilt es zwischen Fehlerzuständen und Fehlerwirkungen zu unterscheiden.

Definition: Fehlerzustand

Fehlerhafter Programmteil, Anweisung oder Datendefinition, die ursächlich für eine Fehlerwirkung verantwortlich ist.

ISTQB Glossar

Und hier die Definition von Fehlerwirkung:

Definition: Fehlerwirkung

Die Wirkung eines fehlerhaften Zustands, der während der Ausführung des zu testenden Programms nach außen für den Anwender sichtbar auftritt.

ISTQB Glossar

Nicht jeder Fehlerzustand führt auch zu einer Fehlerwirkung. Beispielsweise führt der Aufruf einer Methode auf einem nicht initialisierten Objekt nicht zu einer Fehlerwirkung, wenn dieser Code nie durchlaufen wird oder wenn eine Fehlerbehandlung diesen Fehler fängt und neutralisiert.

In diesem Artikel verstehen wir unter Fehlerwahrscheinlichkeit die Wahrscheinlichkeit einer Fehlerwirkung.

Welche Fehlerwahrscheinlichkeit bei Software erreicht werden muss

Es gibt mehrere Varianten, um die maximale Wahrscheinlichkeit abzuschätzen, mit der eine Software eine (kritische) Fehlerwirkung aufweisen darf.

Variante 1: Produktspezifische Risikoakzeptanzkriterien anwenden

Welche Fehlerwahrscheinlichkeit bei einer Software erreicht werden muss, lässt sich aus der Risikoakzeptanzmatrix ableiten: Dazu geht beginnt man mit einem angenommenen Schaden, liest aus der Akzeptanzmatrix dessen maximale Wahrscheinlichkeit ab und verfolgt die Ursachenkette rückwärts bis zum Software-Fehler (FTA-Ansatz).

In anderen Worten: Man geht die in Abbildung 1 gezeigten Schritte in umgekehrter Reihenfolge und schließt von der maximalen Schadenswahrscheinlichkeit auf die maximale Wahrscheinlichkeit eines Software-Fehlers.

Variante 2: Andere Akzeptanzkriterien anwenden

Manche Industrien verlangen sehr niedrige Fehlerwahrscheinlichkeiten, etwa 10E-9 pro Betriebsstunde (zivile Luftfahrt) oder 10E-12 pro Betriebsstunde (Eisenbahn). Doch bedeutet dies keineswegs, dass die Software diese Güte erreichen kann und muss. Die verlangten geringen Fehlerwahrscheinlichkeiten erreichen die Hersteller meist erst durch in Hardware implementierte risikominimierende Maßnahmen (z.B. Redundanz).

Wie man die tatsächliche Fehlerwahrscheinlichkeit bei Software abschätzen kann

Eine maximale Wahrscheinlichkeit als Zielwert festzulegen, ist eine Sache. Herauszufinden, ob man diesen erreicht hat, eine andere.

Variante 1: Literaturdaten

Literatur können beim Abschätzen von Fehlerwahrscheinlichkeiten helfen:

  • Pro 1000 Zeilen eines sicherheitskritischen Systems fanden sich 1,4 kritische und 23 unkritische Fehler.
  • Bei kommerzieller Software wie Windows XP geht man von 30 Fehlern pro 1000 Zeilen aus, was bei 35 Mio. Zeilen mehr als 1 Mio. Fehlern entspricht. Dennoch hat Windows XP eine MTBF (mean time between failure) von 300 Stunden.
  • Bei Autos und Flugzeugen geht man von 10E-7 Software-Fehlern pro Stunde aus. (Diese Zahlen stehen, wie oben erkärt, nicht im Widerspruch zu den o.g. Forderungen an die Fehlerwahrscheinlichkeit von ganzen Verkehrsmitteln.)

Es bleibt das Problem: Diese Daten helfen zwar bei der Abschätzung von Fehlerwahrscheinlichkeiten, stellen aber keinen Beweis dar, dass diese tatsächlich erreicht werden.

Variante 2: Ausprobieren

Die tatsächliche Wahrscheinlichkeit, auf Fehlerzustände zu stoßen, liefert erst die Praxis bzw. das Ausprobieren. Hierfür gibt es zwei Ansätze:

  1. Testen
  2. Im Produktiveinsatz beobachten.

Ad a. Testen

Testen hilft, zumindest eine obere Grenze der Wahrscheinlichkeit von Fehlern abzuschätzen. Selbstredend muss dazu beim Testen der Code überhaupt durchlaufen werden. Eine möglichst vollständige Testabdeckung (lesen Sie hier mehr über Code Coverage) ist eine notwendige Voraussetzung, um belastbare Zahlen (MTBF, Fehlerwahrscheinlichkeit, Fehler pro 1000 Zeilen Code (kLoC)) abzuleiten.

Die Mutation von Code gibt weitere Hinweise darauf, wie sensitiv die gewählten Testfälle tatsächlich Fehler aufspüren.

In jedem Fall sollten alle Benutzungsszenarien getestet werden.

Vorsicht: die Testdauer ist insbesondere bei automatisierten Tests kein aussagekräftiges Maß für die Güte bzw. Vollständigkeit (wie an anderer Stelle behauptet).

Ad b. Produktiveinsatz

Die „repräsentativsten Testfälle“ und damit die belastbarsten Zahlen erhalten Sie aus dem Feld. Nutzen Sie dazu:

  • Rückmeldungen der Anwender
  • Eigene Beobachtungen
  • Auswertungen von Fehler- und Audit-Logs
  • Befragungen der Anwender
  • Auswertung der eingegebenen Daten

Nutzungsstatistiken helfen Ihnen zu überprüfen, ob Ihre Tests alle tatsächlichen Benutzungsszenarien abdecken.

Allerdings: Bei der Zulassung eines neuen Produkts stehen diese Daten i.d.R. nicht zur Verfügung.

Variante 3: Modellierung und Berechnung

Mathematische Modelle wie Markov-Ketten helfen, die Wahrscheinlichkeiten zu berechnen, mit denen sich Fehler fortpflanzen. Diese Wahrscheinlichkeiten lassen sich oft gerade nicht als das Produkt der Einzelwahrscheinlichkeiten berechnen.

Eine Übersicht und kurze Einführung verschafft Ihnen die IEC 61508-3 im Anhang D, insbesondere in den Teilkapiteln D.3 bis D.7.

In der Praxis finden diese Verfahren bei Software(!) allerdings kaum Anwendung. Das liegt u.a.

  • begründet in deren Komplexität,
  • in der schwierigen Übertragbarkeit auf Software und
  • an der mangelnden Abbildung der Software auf ein Modell.

Fazit

Das Abschätzen der Wahrscheinlichkeit ist schwer. Na und?

Die Wahrscheinlichkeit von Software-Fehlern ist in der Tat sehr schwer zu schätzen. Doch können Sie anhand von Literaturdaten und eigenen Messungen zumindest die Größenordnung abschätzen.

Auch andere Wahrscheinlichkeiten sind schwer abzuschätzen, etwa die von Nutzungsfehlern. Allerdings käme hier niemand auf die Idee, deshalb eine Worst-Case-Annahme von 100% zu fordern, wie das die IEC 62304 tat. Zumindest konnte / musste man die „alte Norm“ so (miss-)verstehen.

Eine Faustregel zur Beruhigung

Wer seine Software nach den Regeln der Kunst (wie sie die IEC 62304, mehr noch die IEC 61508-3 vorstellt) entwickelt und die Software mit einem Code-Coverage (zumindest der relevanten Teile) nahe 100% testet, sollte von einer Fehlerwahrscheinlichkeit seiner Software von ≤ 10E-2 pro Anwendungsfall ausgehen können, selbst wenn die Software neu entwickelt wurde. Die Fehlerwahrscheinlichkeiten von produktiver und bewährter Software dürften mindestens eine Größenordnung kleiner sein.

Wie man niedrige Fehlerwahrscheinlichkeiten bei Software erreicht

Die wirksamste Möglichkeit, eine Software mit wenigen Fehlern zu entwickeln, besteht darin, Fehler konsequent zu vermeiden – und nicht (nur) zu versuchen, diese Fehler beim Testen zu finden und dann zu beseitigen. Deshalb fokussiert die IEC 61508-3 genau darauf: Sie gibt an, welche Maßnahmen Hersteller ergreifen müssen, um ein festgelegtes Security Integrity Level (SIL) zu erreichen.

Lesen Sie hier mehr über die Aspekte der konstruktiven Qualitätssicherung.

Argumentation mit Auditoren

Manche Auditoren und „Technical File Reviewer“ klammern sich noch an den Satz in der (alten) IEC 62304, der die Fehlerwahrscheinlichkeit auf 100% festlegt. Vielleicht helfen Ihnen bei der Argumentation folgende Überlegungen:

  • Dass die Fehlerwahrscheinlichkeit 100% beträgt, ist dadurch widerlegt, dass Sie einen Test durchführen, der zu den spezifizierten Ergebnissen führt. Die Annahme in der „alten“ IEC 62304 ist damit widerlegt.
  • Die „alte“ IEC 62304 stellt nicht mehr den Stand der Technik dar. Diesen repräsentiert (eher) die IEC 62304:2015.
  • Die unsägliche 100%-Aussage traf bereits die alte Norm im Kontext der Sicherheitsklassifizierung. Es ging darum, dass man bei dieser Klassifizierung keine Wahrscheinlichkeiten diskutiert. Genau das stellt die neue IEC 62304 klar, und das ist auch sinnvoll.
  • Die ISO 14971 erlaubt und verlangt sogar, Wahrscheinlichkeiten zu bestimmen. Anders lassen sich Risiken nicht quantifizieren und bewerten.
  • Die wohl wichtigste Norm für sicherheitskritische Systeme, die IEC 61508-2, schreibt vor, wie man Software professionell entwickelt. Und daran haben Sie sich (hoffentlich) gemäß Ihrem „SIL“ orientiert.

Der beste Schutz vor Software-Fehlern besteht in der konstruktiven Qualitätssicherung und in Maßnahmen, die außerhalb des Software-Systems implementiert sind. Beides sollten Sie primär anstreben. Bei stand-alone Software funktioniert der Ansatz „externer Maßnahmen“ allerdings nicht. Aber auch hier können Sie zumindest die Größenordnung von Fehlerwahrscheinlichkeiten abschätzen.


Kategorien: Risikomanagement & ISO 14971, Software & IEC 62304
Tags: ,

Kommentar schreiben