Fehlermanagement: Ups – ein Fehler

(Gast) Birgit Feld

05/12/2016

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:

fehlersichten

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.

phasen

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:

anwendersichten
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:

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

 


Geschrieben von (Gast) Birgit Feld

Birgit Feld arbeitet seit 15 Jahren in der Medizintechnik und Laborautomatisierung. Nach dem Studium der Elektrotechnik an der RWTH Aachen widmete sie sich zunächst der Softwareentwicklung. Als Systemarchitektin bei der Entwicklung von Defibrillatoren genoss sie es den Überblick auf das Große und Ganze zu haben und Produktentwicklungen von der Idee bis zum Markt zu begleiten. Seit 2017 arbeitet sie als Projektleiterin bei der infoteam Software AG.


Weitere Beiträge

  • 05/12/2024
  • Allgemein, Systems Engineering, Unternehmen, Veranstaltungen

In einer sich ständig wandelnden Geschäftswelt ist Kreativität ein entscheidender Faktor für den Erfolg. Unternehmen, die innovative Lösungen entwickeln und sich kontinuierlich an neue Herausforderungen anpassen können, haben einen ...

Weiterlesen
  • 09/07/2024
  • Allgemein, Elektrostimulation, Systems Engineering, Unternehmen, Veranstaltungen

Liebe Ingenieurinnen und Ingenieure, technisch Interessierte und Familienangehörige, am 13. Juli 2024 findet der Familientag „Faszination Technik“ in Nürnberg statt! Das Event wird veranstaltet vom VDI-Bezirksverein Bayern Nordost e.V. und der Technischen Hochschule Nürnberg. ...

Weiterlesen
  • 30/04/2024
  • 3D Druck, Allgemein, Gastblogs, Hardware, Mechanik

Oder: wie man eine Idee ruckzuck in einen Prototyp verwandeln kann Ich weiß nicht, wie es Ihnen geht, aber ich habe immer mal wieder Ideen zu nützlichen Gadgets, die ...

Weiterlesen
Cookie-Übersicht

Die Internetseiten der MEDtech Ingenieur GmbH verwenden Cookies. Cookies sind Textdateien, welche über einen Internetbrowser auf einem Computersystem abgelegt und gespeichert werden.

Zahlreiche Internetseiten und Server verwenden Cookies. Viele Cookies enthalten eine sogenannte Cookie-ID. Eine Cookie-ID ist eine eindeutige Kennung des Cookies. Sie besteht aus einer Zeichenfolge, durch welche Internetseiten und Server dem konkreten Internetbrowser zugeordnet werden können, in dem das Cookie gespeichert wurde. Dies ermöglicht es den besuchten Internetseiten und Servern, den individuellen Browser der betroffenen Person von anderen Internetbrowsern, die andere Cookies enthalten, zu unterscheiden. Ein bestimmter Internetbrowser kann über die eindeutige Cookie-ID wiedererkannt und identifiziert werden.

Durch den Einsatz von Cookies kann die MEDtech Ingenieur GmbH den Nutzern dieser Internetseite nutzerfreundlichere Services bereitstellen, die ohne die Cookie-Setzung nicht möglich wären.

Mittels eines Cookies können die Informationen und Angebote auf unserer Internetseite im Sinne des Benutzers optimiert werden. Cookies ermöglichen uns, wie bereits erwähnt, die Benutzer unserer Internetseite wiederzuerkennen. Zweck dieser Wiedererkennung ist es, den Nutzern die Verwendung unserer Internetseite zu erleichtern. Der Benutzer einer Internetseite, die Cookies verwendet, muss beispielsweise nicht bei jedem Besuch der Internetseite erneut seine Zugangsdaten eingeben, weil dies von der Internetseite und dem auf dem Computersystem des Benutzers abgelegten Cookie übernommen wird.

Die betroffene Person kann die Setzung von Cookies durch unsere Internetseite jederzeit mittels einer entsprechenden Einstellung des genutzten Internetbrowsers verhindern und damit der Setzung von Cookies dauerhaft widersprechen. Ferner können bereits gesetzte Cookies jederzeit über einen Internetbrowser oder andere Softwareprogramme gelöscht werden. Dies ist in allen gängigen Internetbrowsern möglich. Deaktiviert die betroffene Person die Setzung von Cookies in dem genutzten Internetbrowser, sind unter Umständen nicht alle Funktionen unserer Internetseite vollumfänglich nutzbar.

Weitere Informationen erhalten Sie in unserer Datenschutzerklärung.

Unbedingt notwendige Cookies

Dieses Cookie wird benötigt, um Ihre Cookie-Einstellungen zu merken und weitere Hauptfunktionen zur Verfügung zu stellen

Um Ihnen eine Auskunft über Ihre gespeicherten personenbezogenen Daten hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) geben zu können, benötigen wir einen Cookie, um Sie bei der Datenabfrage identifizieren zu können. Dieser Cookie muss aus Sicherheitsgründen deshalb aktiviert sein. Ein weiterer Cookie wird gesetzt, um diesen Banner nicht erneut anzeigen zu müssen.

Cookie-Name Beschreibung
PHPSESSID Name: PHP session
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wir benötigt, um Sie bei der Anfrage von personenbezogenen Daten identifizieren zu können. Das Cookie wird nur gesetzt, wenn Sie eine Anfrage hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) stellen.
Laufzeit: Sitzungsende
Kategorie: Unbedingt notwendige Cookies
moove_gdpr_popup Name: Cookie-Box Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wird benötigt, um Ihre Cookie-Einstellungen zu speichern, um den Cookie-Banner nicht erneut anzeigen zu müssen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
comment_author_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_email_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_url_9c90e388e3e1be4a6c594fa6ac8a3eec
Name: Kommentar Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Cookie wird angelegt, wenn Sie ein Kommentar auf MEDtech Ingenieur veröffentlichen wollen, um Sie als Autor identifizieren und den aktuellen Status Ihres Kommentars anzeigen zu können. Das Cookie enthält den angegebenen Namen. Das Cookie wird erst gesetzt, wenn Sie der Speicherung Ihrer personenbezogenen Daten zustimmen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
rmp-rate Name: RMP Rate
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie eine Bewertung eines Blogbeitrags mithilfe des Sternebewertungssystems abgeben. Ihnen wird eine anonymisierte ID zugewiesen, um zu erkennen, ob Sie einen Artikel bereits bewertet haben oder nicht. Das Cookie wird nur verwendet, um zu verhindern, dass mehrfache Bewertung abgegeben werden und erst gesetzt, wenn Sie auf einen Stern klicken.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
medtech-download-page Name: Download Page
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie den Landing-Page Prozess erfolgreich durchlaufen haben. Dies geschieht nur, wenn Sie einen Content-Download von unserer Website anstreben.
Laufzeit: 1/2 Jahr
Kategorie: Unbedingt notwendige Cookies