Software-FMEA: Die häufigsten Fehler

Dienstag 22. September 2015

Viele Medizinproduktehersteller erstellen eine „Software-FMEA„. Allein der Begriff lässt mich Ungutes ahnen. In diesem Beitrag möchte ich Sie auf die größten Fallen hinweise, die Sie beim Erstellen einer „Software-FMEA“ vermeiden sollten.

Software-FMEA — was das sein könnte

Eine FMEA ist eine Failure Mode and Effect Analysis, also ein Verfahren in der Risikoanalyse, das zu bekannten oder angenommen Fehlern unbekannte Folgen — hier Gefährdungen oder Schäden — sucht. Mehr zur FMEA finden Sie im verlinkten Beitrag.

Mit einer Software-FMEA möchten die Hersteller Risiken identifizieren, die durch Software-Fehler verursacht sind. D.h. sie untersuchen die Software — genauer gesagt die Software-Komponenten und Software-Einheiten — daraufhin, was passiert, wenn eben einer dieser Komponenten oder Einheiten fehlerhaft implementiert wird. Die Medizinprodukte-Hersteller versprechen sich davon eine Aufgabenteilung und eine modularere und damit besser „wartbare“ Risikomanagementakte.

Typische Fallen

Falle 1: Die falschen Personen

Die Software-FMEA wird häufig den Software-Entwicklern übertragen. Doch das Risikomanagement, insbesondere die Risikoanalyse bedarf entsprechender Kompetenzen. Software-Entwickler haben ihre Kompetenz in der Software-Entwicklung und nicht in der Risikoanalyse. Ich spreche von Rollen, nicht von Personen.

Besonders verfügen Software-Entwickler nicht 

  • über die Ausbildung, um eine FMEA überhaupt systematisch durchführen zu können
  • über Kontextwissen, wie sich ein sich fehlerhaft verhaltendes Medizinprodukt bis zum Patienten auswirken kann
  • das medizinische Wissen, mit welcher Wahrscheinlichkeit Gefährdungen zu Schäden eines bestimmten Schweregrads  führen.

Falle 2: Falscher Granularitätsgrad

Die Software-FMEA — wie alle Bottom-Up-Verfahren — kann nicht entscheiden, auf welcher Granularitätsstufe die Risikoanalyse durchgeführt werden muss. Diese Entscheidung kann nur Top-Down z.B. mit einer FTA erfolgen. Übrigens spezifisch für jeden Teilbaum des Komponentenbaums, in dem die Software ebenfalls nur einen Teilbaum darstellt.

Als Folge analysieren die Hersteller die Fehlerursachen viel zu granular, was sich rächt:

  • Die Akte wird zu umfangreich, was die Effizienz senkt und die Kosten erhöht.
  • Die Akte wird zu umfangreich, was den Überblick und damit die Wahrscheinlichkeit erhöht, die wirklichen Risiken zu übersehen.
  • Die Software-Architektur muss bis auf diese Granularitätsstufe modelliert sein und zwar als präzises Komponentendiagramm, das nicht nur die Komponenten, sondern deren Interaktion und Abhängigkeiten erkennen lässt.

Falle 3: Unpräzises Zusammenspiel der Software-FMEA mit dem Rest der Risikomanagementakte

Die Ergebnisse der Software-FMEA müssen in die Gesamtrisikoanalyse mit einfließen. Doch häufig ist nicht einmal die Dokumentenstruktur dazu geeignet, die Ursachenketten sauber zusammenzuführen. Das liegt teilweise auch daran, dass in der Systemarchitektur zwar physische Komponenten existieren, die Software jedoch als die Gesamtheit aller Software, d.h. diese physische Komponenten übergreifend verstanden wird.

Tipps für eine Software-FMEA

Software FMEA: Tabellarisch beschreiben

Wenn Sie eine Software-FMEA erstellen möchten, empfehlen wir Ihnen:

  1. Machen Sie Ihren Software-Entwicklern klar, dass Sie nicht Risiken analysieren können und dürfen, sondern das Fehlverhalten des Software-Systems beschreiben müssen. Das bedingt, dass die externen Schnittstellen des Software-Systems präzise in den Software-Anforderungen spezifiziert wurden. Weiter ist es legitim, wenn gleich sehr schwer, dass die Softwerker die Wahrscheinlichkeit dieser Fehlverhalten abschätzen.
  2. Nicht für alle Software-Systeme: Führen Sie eine detaillierte Software-FMEA nur für Software-Systeme durch, bei denen
    1. Risiken durch einen Software-Fehler nicht außerhalb des Software-Systems aber innerhalb des Medizinprodukt beherrscht werden können oder
    2. SOUP-Komponenten enthalten sind.
  3. Modellieren Sie eine präzise Software-Architektur.
  4. Definierte Schnittstelle der Dokumente: In der „Gesamt-FMEA“ sollte das Software-System als ganzes untersucht sein. Die möglichen Fehlverhalten und Wahrscheinlichkeiten können Sie der Software-FMEA entnehmen. Dieses „Andocken“ der beiden Dokumente bedarf aber Verstand und ein konsistentes Vorgehen oder/und Werkzeug-Unterstützung.
Prof. Dr. Christian Johner
Sind Sie unsicher, ob Ihre Software-FMEA und Ihre Risikomanagementakte den Forderungen der ISO 14971 genügen und Sie wirklich alle Risiken (richtig) identifiziert haben? Professor Johner und sein Team helfen gerne! Nehmen Sie Kontakt auf!
War dieser Artikel hilfreich? Bitte berwerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Autor des Beitrags " Software-FMEA: Die häufigsten Fehler

Johner Institut GmbH

Logo Johner Institut klein

Bewertung 0 von 5 bei 0 Bewertungen


Kategorien: Risikomanagement & ISO 14971
Tags:

3 Kommentare über “Software-FMEA: Die häufigsten Fehler”

  1. Ralf Gütlein schrieb:

    Hallo Herr Prof. Johner,
    es scheint mir sie haben in dem obigen Text einen logischen Fehler eingebaut:
    Statt „was […] die Wahrscheinlichkeit senkt, die wirklichen Risiken zu übersehen“ müsste es heißen „was […] die Wahrscheinlichkeit senkt, die wirklichen Risiken zu erkennen“. Richtig?

    Gruß,
    R. Gütlein

  2. Prof. Dr. Christian Johner schrieb:

    Sie haben absolut Recht, lieber Herr Gütlein!

    Ich habe den Text Dank Ihrer Hilfe gleich korrigieren können. Danke für Ihren Hinweis!

    Viele Grüße, Christian Johner

  3. Martin Heininger schrieb:

    Hallo Herr Prof. Johner,

    Ihr Statement, dass schon der Name „SW-FMEA“ ungutes erahnen lässt, möchte ich voll und ganz bestätigen.
    Alle Kunden, die mir in meiner Tätigkeit (sichere SW-Prozesse in: Luftfahrt, Bahn, Industrie, Automotive), bisher begegnet sind, welche ernsthaft eine SW FMEA erstellen wollten, war nicht wirklich klar was Sie da tun wollten und was Sie mit dem Ergebniss anfangen wollen.

    Ich würde mich sehr über einen Branchenübergreifenden Erfahrungsaustausch freuen. Ich habe auch einen Blog verfasst zu dem Thema, welcher ziemlich viel kontroverse Diskussion ausgelöst hat.

    Viele Grüße
    Martin Heininger
    Geschäftsführer HEICON – Global Engineering GmbH

Kommentar schreiben