Was ist eine FMEA?

FMEA steht für Failure Mode and Effects Analysis, zu Deutsch: Auswirkungsanalyse. Eine FMEA sorgt während der Entwicklung dafür, dass die Zuverlässigkeit des Produkts akzeptabel ist. Als Systems Engineer gehört die FMEA in unseren Werkzeugkasten. Wie sie genau funktioniert beschreibe ich im Folgenden.

Was ist eine akzeptable Zuverlässigkeit?

Wenn es um Sicherheit geht, dann gibt in der Regel der Gesetzgeber vor, was eine akzeptable Zuverlässigkeit ist. Diese muss dann aber auch nachgewiesen werden und die FMEA ist ein Werkzeug für qualitative Aussagen dazu. Es gibt natürlich auch noch weitere Techniken.

Neben dem Gesetzgeber haben manche Kunden selbst Zuverlässigkeitsanforderungen, die über die gesetzlichen Vorgaben hinausgehen können. Auch ohne gesetzliche Vorgaben kann eine FMEA Sinn machen, doch dabei müssen in der Regel die Kosten gerechtfertigt werden. Ein gutes Beispiel sind Satelliten. Hier hat der Betreiber ein hohes Interesse an der Zuverlässigkeit.

Minimale FMEA

Eine FMEA wird typischerweise als Tabelle dargestellt. Von links nach rechts lesen wir in jeder Zeile einen „Failure Mode“ (Versagensart) und deren Effekt ab. Es gibt zahlreiche Varianten der FMEA mit teilweise alternativen Namen, wie DFMEA oder PFMEA. Doch selbst die einfache FMEA besteht oft aus vielen Spalten, um entsprechende Informationen festzuhalten. Im Folgenden zeige ich eine minimales Beispiel eines Systems, in dem es einen Kühlkreislauf gibt.

Eine Ausfallart ist das Stoppen der Pumpe. Dies könnte bspw. vom Stromausfall verursacht werden. Wenn die Pumpe stoppt, dann überhitzt das System, allerdings nicht sofort. Daher wurde hier der Schweregrad als „Mittel“ eingestuft. Der Wert (3) quantifiziert den Schweregrad auf einer Skala von bspw. Leicht (1) bis Fatal (5). Dies kann später für Berechnungen benutzt werden (siehe „Risiken bewerten“).

Jeder kreative Ingenieur könnte nun diese Tabelle sofort erweitern: Gibt es noch andere Ursachen, neben einem Stromausfall? Gibt es andere Auswirkungen, bspw. in anderen Betriebsphasen? Ein anderer „Ausfall“ der Pumpe könnte ein Laufen der Pumpe zum falschen Zeitpunkt sein. Und zuletzt: Wir haben nur die Pumpe betrachtet. Was ist mit den anderen Systemkomponenten, die ausfallen können? Selbst für ein System moderater Größe können sich hier schnell Dutzende von Zeilen ansammeln.

Mehr Metadaten

In der Praxis ist die gezeigte Tabelle kaum brauchbar, wir brauchen weitere Metadaten. Typische weitere Spalten sind:

• Komponente – Auf welche Komponente bezieht sich die Analyse? Im gezeigten Beispiel wäre das die Pumpe.
• Wahrscheinlichkeit – Wie oft erwarten wir diese Ausfallart? Dies kann ebenfalls mit einer numerischen Skala (1-5) verknüpft werden.
• Effekt-Differenzierung – Es kann sinnvoll sein, hier zu unterscheiden. Im Beispiel: Der lokale Effekt ist zunächst das Stoppen des Kühlmittelstroms. Der globale Effekt ist die Überhitzung
• Detektion – Wie leicht kann diese Ausfallart festgestellt werden? Auch hier kann eine numerische Skala (1-5) nützlich sein.

Risiken bewerten

Die Metadaten, die den Effekt bewerten, können quantifiziert werden. Oft wird dazu einfach jedem Wert eine Zahl zugewiesen, wie wir oben bereits gezeigt haben. Eine einfache Methode der Bewertung ist das Ausmultiplizieren der mit Skalen verknüpften Werte, also Schweregrad mal Wahrscheinlichkeit mal Detektion. Viele Anforderungsmanagementwerkzeuge können dies auch automatisch ausrechnen. Hier ein Screenshot aus Jama Connect:

Risiken Entschärfen

Ziel der Übung ist es, ein zuverlässiges System zu bauen. Eine Vorgabe könnte sein, einen Höchstwert für die Risk Priority Number festzulegen. Falls der Wert zu hoch ist, müssen wir das Risiko entschärfen. Das bedeutet konkret, dass die FMEA um weitere Spalten erweitert wird. In der Regel wird die Entschärfung in der Form von Anforderungen festgehalten. Beim Beispiel der Pumpe könnte als entschärfende Anforderung hinzugefügt werden: „Das System muss sich bei einer Überhitzung automatisch abschalten“. Ob diese Anforderung angemessen ist, ist eine andere Frage.

Typischerweise wird nach der Entschärfung die Risk Priority Number neu berechnet um sicherzustellen, dass die Entschärfung ausreicht.

FMEA ist Fleißarbeit

Wie Eingangs gesagt enthält diese Beschreibung viele Vereinfachungen. Eine FMEA-Analyse aus der Praxis kann schnell dutzende von Spalten haben und hunderte von Zeilen. Die Analyse ist nicht schwer, es ist eigentlich nur Fleißarbeit.

Umso wichtiger ist es, die Arbeitsumgebung richtig aufzusetzen. Eine FMEA kann problemlos in Excel realisiert werden. Allerdings gehe ich davon aus, dass Entwicklungen, die eine FEMA erfordern, in einem vernünftigen Anforderungsmanagementwerkzeug dokumentiert werden. Und in dem Fall würde ich dringend empfehlen, die FMEA auch in dem selben Werkzeug zu verwalten.

FMEA im Anforderungsmanagementwerkzeug

Im oben gezeigten Screenshot stellt jede Zeile der FMEA ein eigenes Element vom Typ „Risiko“ dar. Das bedeutet, dass Jama jede Zeile der FMEA versioniert. Weiterhin können wir die Traceability von Jama nutzen. Das bedeutet, dass die Entschärfung nicht Teil der FMEA ist, sondern eine eigene Anforderung. Damit haben wir die Traceability zwischen Risiko und entschärfenden Anforderungen. Wenn sich das Risiko ändert, dann markiert Jama automatisch die verknüpften Anforderungen als „suspekt“. Ebenso können wir eine Traceability von Komponente zu Risiko erstellen und Pflegen.

Ich vermute, dass andere Werkzeuge ähnliche Mechanismen zur Verfügung stellen. Gerade weil es um Sicherheit geht, sollten wir getrennte Datenhaltungen (Excel) möglichst vermeiden.

Photo by Damian Zaleski on Unsplash