Fehler sind unvermeidbar – das klingt unangenehm, ist es aber nicht unbedingt. Denn mit gutem Fehlermanagement schaffen wir einen bewussten Umgang mit Fehlern: Die besonders fiesen Burschen werden verhindert, manche kann man abfangen und Unkritische sogar zulassen. Fehler zulassen – das scheint gewagt, insbesondere in so einem sicherheitsrelevanten Umfeld wie der Medizintechnik. Aber wenn man klärt, welche Arten von Fehlern man zulässt, ist es möglich ein sicheres und fehlertolerantes System zu schaffen.
Für jede Fehlersituation die richtige Behandlung zu finden, das ist es, was ich unter dem Begriff Fehlermanagement verstehe.
Fehlermanagement im Projekt vs. Fehlermanagement des Produkts
Zunächst möchte ich erklären, dass der Begriff für zwei grundverschiedene Bereiche verwendet werden kann:
Fehlermanagement im Projekt: Das bedeutet, sich in allen Phasen eines Projektes Gedanken zu machen und Lösungsstrategien zu entwickeln für Fehler die im Projekt auftreten können. Projektrisiken, Changes aufgrund von erkannten Fehlern, Bugtracking etc… Diesen Zweig möchte ich aber in diesem Blogartikel nicht verfolgen.
Fehlermanagement des Systems: Hier geht es darum wie das Produkt – das medizintechnische Gerät oder die medizinische Software – mit Fehlern umgeht. Das wollen wir vertiefen und fragen daher…
…was sind eigentlich Fehler?
Die Frage klingt einfach. Aber sie hat viele verschiedene Antworten – je nachdem wen man fragt:
Es gibt eine Vielzahl von Situationen, die der Anwender wahrscheinlich als Fehler bezeichnen würde. Bei dem Gerät im obigen Bild könnten das zum Beispiel sein:
- der Akku ist fast leer
- und der WLAN-Partner nicht erreichbar.
Und der Erfinder (bzw. Entwickler) nennt es einen Fehler, wenn
- das Zulaufventil geschlossen ist oder
- der Anwender so lange die Messung neu startet, bis das Gerät überhitzen würde.
Aber für all diese Fälle muss das Gerät gerüstet sein. Sie bilden die Gruppe der Spezialfälle in der Fehlerliste.
Die nächst schlimmere Gruppe sind die erkennbaren Fehler: Hardwaredefekte und Softwarefehler, die das Gerät erkennen und anzeigen, aber nicht mehr behandeln kann.
Und schließlich gibt es noch die Katastrophen – Gerätedefekte – die vom Gerät entweder nicht erkannt oder zwar erkannt aber nicht mehr zur Anzeige gebracht werden können.
Es ergibt Sinn immer wieder auf diese Einteilung der Fehler zurückzugreifen und die Gruppenzuordnung in einer Fehlerliste festzuhalten.
Ran an die Fehler
Schon zu Beginn eines Projektes soll man das Systemverhalten bei Fehlern im Auge haben. In den ersten 3 Phasen müssen die Grundlagen für das Fehlermanagement des Produkts gelegt werden.
Requirements Engineering Phase
Beim Requirements Engineering gilt es, aus den Stakeholdern herauszukitzeln was das System wirklich leisten soll und was nicht.
User Stories:
Wenn man die ein oder andere User Story spinnt, bei der es um Fehler geht, kommt oft überraschendes (oder sogar widersprüchliches) zu Tage. Und schon hat sich die Arbeit gelohnt!
Beispiel von User Stories mit Bezug auf eine Fehlersituation:
„Der Betreiber möchte erkennen können, wenn ein Selbsttestfehler vorliegt, um das Gerät dann Instand zu setzen.“
„Wenn der Gerätespeicher voll ist, sollen alte Einsatzdaten gelöscht werden, um dem Anwender zumindest die Daten des aktuellen Einsatzes zur Verfügung zu stellen.“
„Wenn der Gerätespeicher voll ist, soll das Logging angehalten werden. Der Anwender kann dann entscheiden welche alten Einsatzdaten gelöscht werden sollen.“
Die letzten beiden Storys zeigen, dass es unterschiedliche Möglichkeiten gibt auf den Fall „Speicher ist voll“ zu reagieren. Und dass es sich daher lohnt, auch solche Themen mit den entsprechenden Stakeholdern zu besprechen.
Anwendersicht der Fehlerzustände:
Es kann sehr hilfreich sein, ein Bild zu zeichnen, das zeigt welche Ansichten der Anwender in verschiedenen Fehlersituationen zu sehen bekommt. Denn sonst ist nicht ersichtlich, wie sich ein Fehler nach außen hin darstellt. Im Folgenden einfachen Beispiel hat das Gerät eine rote / grüne LED um anzuzeigen, ob ein Fehler vorliegt.
Es gibt aber Fehler verschiedener Schwere, die alle zu einer roten LED führen sollen. So leuchtet die LED sowohl bei einer schwachen Batterie rot, als, auch wenn ein Geräteselbsttest fehlschlägt oder ein fataler Hardwaredefekt vorliegt.
Wie das Bild darstellt, führt dies dazu, dass am ausgeschalteten Gerät mit roter LED nicht erkennbar ist, was passieren wird, wenn das Gerät eingeschaltet wird. Vielleicht ist es noch lauffähig, vielleicht zeigt es einen Fehlercode. Eventuell ist es auch dazu nicht mehr in der Lage.
Durch so ein Bild kann zusammen mit dem Kunden sichergestellt werden, dass dies das gewünschte Geräteverhalten ist. Und nicht noch ein Zwischenzustand mit gelber LED für den schwachen Akku eingeführt werden muss.
Phase: System Architektur entwerfen
Die Systemarchitektur, also die Beschreibung des Aufbaus und des Verhaltens eines Systems soll ein (oder auch mal mehrere) Kapitel zum Thema Fehlerverhalten haben.
Das Sicherheitskonzept ist dabei die Zusammenfassung aller Kapitel und Teile aus der Systemspezifikation die sich mit dem Thema Sicherheit – also auch Umgang mit Fehlern – beschäftigen. Zusammen mit der ersten Risikoanalyse wird hierbei der Umgang im System mit Fehlern, bzw. Maßnahme gegen potentielle Fehler festgelegt.
Wichtig ist dabei zu beachten, dass jede Maßnahme zur Erkennung und Behandlung von Fehlern, Komplexität zum System hinzufügt und somit selbst wieder potentiell eine Fehlerquelle sein kann. Das folgende Schaubild zeigt die möglichen Auswirkungen einer Fehlererkennung:
Jede in der Architekturphase betrachtete Maßnahme zur Fehlererkennung und -korrektur muss also auch bezüglich ihrer eigenen Fehleranfälligkeit beurteilt werden, um zu entscheiden, ob sie implementiert wird.
Oben in der Einleitung habe ich davon gesprochen, dass man manche Fehler auch zulassen muss. Dies wird bei dieser Betrachtung deutlich. Es ist möglich, dass für einen bestimmten Fehler die Wahrscheinlichkeit, dass er eintritt und die Schadensauswirkung gering ist. Die zugehörige Fehlererkennung könnte aber eine hohe Anfälligkeit für falsche Alarme haben. Und die Fehlerbehandlung könnte schlimmer sein als die Auswirkung des Fehlers. In so einem Fall wäre die Einführung der Maßnahme kontraproduktiv.
Beispiel:
Ein bestimmter Hardwaredefekt kann dazu führen, dass die Systemzeit verloren geht. Es ist möglich eine Schaltung vorzusehen, die diesen Hardwarefehler entdeckt (Fehlererkennungsmaßnahme) und an den Controller meldet, sodass das System einen Fehlerbildschirm anzeigt und nicht weiterläuft (Fehlerbehandlung).
Wenn dieser Hardwaredefekt und die verlorene Systemzeit aber gar keine kritischen Auswirkungen haben – es wird eine falsche Uhrzeit dargestellt – und vielleicht auch noch sehr unwahrscheinlich sind, ist die Erkennung und Behandlung hier unzweckmäßig.
Design Phase
In die Systemspezifikation gehört eine Tabelle als Übersicht über alle Fehler. Alle!? Das sind aber viele!
Ja, alle! Damit dies möglich ist, müssen Fehlergruppen definiert und zusammengefasst werden. Gruppiert werden dabei Fehler, die zum selben Systemverhalten führen. Eigene Tabelleneinträge werden vorgenommen für behandelte Ausnahmen. In dieser Tabelle sollen sich die in der Einleitung aufgeführten Klassifizierungen – Spezialfall, erkennbarer Fehler und Gerätedefekt – wiederfinden.
Es empfiehlt sich neben der Beschreibung des Fehlers (kurz und lang) und dem Geräteverhalten, weitere Spalten einzuführen. Diese können zum Beispiel die folgenden Aspekte für jeden Fehler (jede Fehlergruppe) behandeln:
- Farbe der Fehler-LED / Fehlercode
- der den Fehler erkennende Systemteil / Controller
- Möglichkeit zur Fehlerbehebung
- Einstufung als permanenter / nicht permanenter Fehler
So überraschend es klingt, können Softwarefehler alle in einer Gruppe zusammengefasst werden. Unter Softwarefehler sind jene Fehler zu verstehen, die keine eigene Behandlung haben, da sie – prinzipbedingt – bei der Programmierung nicht vorhergesehen werden konnten. In einem guten SW-Design werden solche Fehler durch eine einheitliche Methode (z.B. Asserts) abgefangen.
Das einheitliche Abfangen birgt wenig Komplexität und ist einer eigenen Behandlung oft vorzuziehen, insbesondere wenn diese keine Vorteile (zum Beispiel für die Usability) bringt. Beispiele können hier (je nach System) korrupte Konfigurationsdateien, verlorene Datenpakete, ungültige Dateipfade… sein.
Beispiel:
Auf einem embedded System gibt es eine Konfigurationsdatei, die immer vorhanden sein muss. Der Anwender hat hierauf keinen Einfluss. Daher ist es u.U. rechtens das System außer Betrieb zu nehmen, wenn die Datei fehlt, anstatt weiterzulaufen und eine Backupdatei zu verwenden. Denn der Fehler deutet auf ein Problem hin: Ist das Dateisystem kaputt? Oder gibt es einen Programmierfehler, der die Datei am 29. Februar korrumpiert? Weiteren Code zu erzeugen, der sich nur um diese Ausnahmesituation kümmert, führt wieder zu potentiellen weiteren Fehlern.
Ein paar abschließende Worte
Fehlermanagement bedeutet sich den möglichen Fehlern und Spezialfällen bewusst zu werden, sie zu ordnen, zu klassifizieren und entsprechend ihrer Auswirkungen zu behandeln. Für jeden Fall wird geklärt wie das System sicher bleibt trotz Auftreten des Fehlers. Für die Spezialfälle wird festgelegt wie das System sogar trotzdem funktional bleibt. Gutes Fehlermanagement verhindert, dass unsinnige Maßnahmen implementiert werden und sorgt dafür, dass die Usability verbessert wird, ohne dass die Systemkomplexität unnötig ansteigt.
Fehler? Smile – you can’t kill them all.
Birgit Feld