Viele Medizinproduktehersteller erstellen eine „Software-FMEA„. Doch es gibt kein einheitliches Verständnis dessen, was eine Software-FMEA ist.
Dieser Beitrag verschafft Klarheit und gibt Tipps, um die häufigsten Fehler zu vermeiden.
1. Software-FMEA — was das sein könnte
a) Software-FMEA eine Ausprägung der FMEA bei Software
Eine FMEA ist eine Failure Mode and Effect Analysis, also ein Verfahren der Gefährdungsanalyse, das zu bekannten oder angenommen Fehlern unbekannte Folgen sucht, beispielsweise Gefährdungen oder Schäden.
Ein Beitrag zur FMEA beschreibt die Methode genauer und gibt Tipps zu deren Dokumentation.
Beachten Sie auch den übergeordneten Beitrag zur Software-Risikoanalyse.
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.
b) „Scope“ der Software-FMEA
Bei den Hersteller besteht nicht immer Einigkeit darüber, bis zu welchen Endpunkten die Software-FMEA die Auswirkungen untersuchen soll. Es gibt mehrere Alternativen: Die Analyse der Auswirkungen („Effects“) endet
- an den äußeren Schnittstellen der Software,
- an den äußeren Schnittstellen des Medizinprodukts (wenn es keine Standalone-Software ist) oder
- bei den tatsächlichen Risiken, d.h. Wahrscheinlichkeiten und Schweregraden von Schäden.
Hersteller sollten hierüber Klarheit haben. Mehr dazu im Abschnitt „Fehler 1“.
c) Vorteile der Software-FMEA
Die Medizinprodukte-Hersteller versprechen sich von dieser Form der FMEA
- unbekannte Folgen von Software-Fehlern systematischer zu finden,
- die Aufgaben im Risikomanagement nachvollziehbar aufzuteilen (auf die Software-Entwicklung und auf das Risikomanagement),
- die Risikomanagementakte modular aufzuteilen und damit besser „wartbar“ zu gestalten.
2. Typische Fehler
Fehler 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. Wir sprechen 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.
Daher empfiehlt das Johner Institut die Software-FMEA auf die Software zu beschränken (s. Abb. 1).
Fehler 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.
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.
Fehler 3: Unpräzises Zusammenspiel mit 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.
Um diesen Fehler zu vermeiden, müssen die Endpunkte der Software-FMEA als Startpunkte der Risikoanalyse fungieren.
Beispielsweise ergibt sich aus der Software-FMEA, dass die Software über ihre äußere Schnittstelle ein falsches Kommando auf den Bus des Medizinprodukts absetzt.
In der Risikoanalyse müsste dann untersucht werden, was die Folgen für die Patienten, Anwender und Dritte sind, wenn auf dem Bus des Produkts ein falsche Kommando abgesetzt wird.
3. Tipps für eine Software-FMEA
Tipp 1: Dokumentation vorgeben
Eine einheitliche Dokumentation hilft, durchgehende, konsistente und konforme Risikoanalysen zu erstellen. Die Software-Entwicklung könnte beispielsweise Tabellen wie in Abb. 2 ausfüllen.
Tipp 2: Software-FMEA auf Software beschränken
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.
Tipp 3: Nicht für alle Software-Systeme verwenden
Führen Sie eine detaillierte Software-FMEA nur für Software-Systeme durch, bei denen
- Risiken durch einen Software-Fehler nicht außerhalb des Software-Systems aber innerhalb des Medizinprodukt beherrscht werden können oder
- SOUP-Komponenten enthalten sind.
Tipp 4: Software-Architektur modellieren und Schnittstellen präzise spezifizieren und dokumentieren
Modellieren Sie eine präzise Software-Architektur. Denn ohne eine Architektur können Sie die Fehlerketten nicht nachvollziehen und die Auswirkungen von Software-Fehlern auf die Schnittstellen der Software erkennen.
Wenn Sie das mögliche externe Fehlverhalten der Software erkennen und beschreiben wollen, müssen Sie wissen, wie sich die Software über ihre Schnittstellen falsch verhalten kann. Das setzt präzise definierte und dokumentierte Schnittstellen voraus.
Tipp 5: Werkzeuge verwenden
Um die Ursachenketten (s. Abb. 1) nahtlos aneinanderketten und mit Änderungen sicher umgehen zu können, empfehlen sich Werkzeuge für das Risikomanagement. Und das sollte nicht immer Excel sein.
4. Fazit und Zusammenfassung
Für Medizinprodukte, die Software enthalten oder Software sind, ist die Software-FMEA in den meisten Fällen die adäquate Methode. Dazu sollten die Hersteller ein einheitliches Verständnis haben, was darunter zu verstehen ist.
Wie jede Methode bedarf auch die Software-FMEA der notwendigen Kompetenzen.
Nutzen Sie die Unterstützung der Software- und Risikomanagementexperinnen und -experten des Johner Instituts. Damit stellen Sie sicher, dass Ihre Risikomanagementakte den Anforderungen der Gesetze und der ISO 14971 genügen und Ihre Produkte sicher sind und genauso sicher und schnell in den Markt kommen.
Änderungshistorie
- 2023-05-23: Artikel grundlegende überarbeitet, Abbildung 1 ergänzt
- 2015-09-22: Erste Version des Artikels publiziert
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
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
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
Hallo Herr Prof. Johner,
die Beschreibung der Fehler teile ich. Wie bei den Folgen verfällt sich das auch bei den Ursachen. Das scheint mir hier etwas kurz, darum schildere ich hier etwas aus der Erfahrung.
Die Mechanik spricht hier von Merkmalen bzw. Characteristics. Hier muss man SW-Entwickler erst einmal richtig abholen, weil sie schlichtweg den Begriff nicht kennen und nicht auf ihre Arbeit beziehen. Tatsächlich geht es bei jedem Merkmal (Durchmesser, Form, Material, Vergütung der Oberfläche etc.) im Design um die Entscheidungen von Entwicklern. Die eigentliche Fehlerursache sind hier falsche Entscheidungen bei der Wahl oder Ausgestaltung der Merkmale. Und das ist auch der Kern einer sinnvollen SW-FMEA: hier werden genauso Entscheidungen getroffen, wie bei einem 3D-Modell oder einer Platine. Für oder gegen Protokolle, für oder gegen Datenbank X oder Y, Formate, Datentypen, Algorithmen etc. Und diese soll eine FMEA in Form einer kleinen „Crowd“ hinterfragen. Strukturell ist das Verfahren bei Software dann kaum anders als bei Hardware.
Allerdings ist die Story damit nicht fertig. Wieder genauso wie im Design ist Software nach code- oder modell-getriebener Programmierung ja nicht fertig. Sie ist dann ja nur fertig programmiert und liegt erst einmal auf irgendeinem internen System.
Auch hier gibt es regelmäßig Tätigkeiten, die man in der Hardware-Welt in einer Prozess-FMEA behandeln würde. Und auch hier ist „die“ Prozess-FMEA so eine Dozenten-Abkürzung, die etwas zu kurz greift (… bitte nicht als Spitze missverstehen – in Trainings sage ich das ja auch schnell mal, ist eben so im Sprachgebrauch). In der der Praxis hat man es hier in Wirklichkeit aber – je nach Schwerpunkt und Phase – mit einer Herstellungs-FMEA (Teile produzieren) zu tun, mit einer Montage-FMEA (Teile integrieren) oder auch mit einer Verpackungs-FMEA zu tun. Und natürlich können diese Ausprägungen – je nach Business-Segment – auch wieder auf Software angewendet werden. Wer Simulink-Modelle zu Ende coded wird nicht von allem etwas merken – und wer nur ein paar Zeilen node.js hat, aber ganze Cloud-Infrastrukturen damit steuert, ebenfalls nicht. Man wird aber eine Software-FMEA sicher eher vom DevOps-Blickwinkel aus anstelle von Embedded-C-Feinheiten in Abstimmung mit MISRA C betrachten. Solche Prozess-FMEAs sind dann eben die Analyse einer ggf. recht komplexen Build-Strecke, also die Betrachtungen von Packaging und Deployment. Wenn dann noch Over-The-Air-Updates mit benötigter/geschuldeter Zuverlässigkeit dazu kommen, sollte man solche FMEAs dann genauso durchführen wie die zur Korrektheit der Programmierung. Auch hier geht es dann wieder um die Entscheidungen, die man für ein erfolgreiches Zusammenspiel der Komponenten gewählt hat, um deren Verifikation und ggf. um die benötigten Monitoring-Response-Mechanismen, die ein System auch im Falle einzelner Hardware-bedingter Fehler stabil halten.
Über das letzte Jahrzehnt haben wir hierzu zahlreiche Erfahrungen aufgebaut und freuen uns über einen Austausch. Danke für das Anstoßen.
Vielen Dank, Herr Dr. Gellner, für diese wertvollen Ergänzungen.