[lwptoc]
FMEA Einführung
Die Abkürzung FMEA
Die Abkürzung bedeutet Failure Mode and Effects Analysis bzw. auf deutsch Fehlermöglichkeits- und –einflussanalyse.
Neben der FMEA gibt es auch noch weitere Abkürzung, z.B. die FMEDA. Diese wird definitiv einen eigenen Blogpost erhalten, da es hier schon in Richtung sicherheitskritischer Systeme bzw. funktionale Sicherheit gehen wird. Die Abkürzung FMEDA wiederum steht für Failure Modes, Effects and Diagnostic Coverage Analysis.
Was macht eine FMEA?
Die FMEA ist eine Analysetechnik, mit der durch systematische Verfahren versucht wird, schon am Anfang und während der Entwicklung Fehler zu vermeiden. Es geht also um ein Analyseverfahren, mit dem ein/e Gerät/System/Schnittstelle/Software vor bzw. während der Entwicklung auf mögliche Fehler und deren Auswirkung analysiert wird. Sollten Fehler gefunden werden, die nur schwer oder schlecht entdeckt werden, können entsprechende Vermeidungsmaßnahmen definiert werden.
FMEA Arten
Wir unterscheiden zwischen folgenden FMEA Arten:
- System FMEA
- Design FMEA
- Prozess FMEA
- Hardware/Software FMEA
System FMEA
In einer System FMEA wird das große Ganze betrachtet und auf mögliche Schwachstellen untersucht. Dazu gehört es, die Zusammenarbeit der darunter liegenden Teilsysteme bzw. Komponenten eines Teilsystems zu analysieren. Auch hier spielen Schnittstellen eine große Rolle, aber auch die Interaktion des gesamten Systems mit der Umwelt. Es werden nach systematischen Fehlern und nach zufälligen Fehlern gesucht und dazu Abstellmaßnahmen definiert.
Ein weiteres Ziel der System FMEA ist Analyse, ob mögliche Fehler zur Nicht-Erfüllung von Anforderungen (die an das System gestellt wurden) führen.
Design FMEA
Die Design FMEA betrachtet einzelne Teile genauer und wird meist in der Entwicklung dazu genutzt, die Eignung für die Fertigung oder Montage von Produkten einzuschätzen. Diese Analyse fokussiert stärker auf die Konstruktion eines Teils und versucht so systematische Fehler aus der Konstruktionsphase zu erkennen und abzustellen.
Prozess FMEA
Was mit Objekten gemacht werden kann, kann eben so gut auch mit Prozessen durchgeführt werden. Die Prozess FMEA betrachtet mögliche Schwachstellen im Produktionsprozess und nutzt hierbei auch die Erkenntnisse aus der Design FMEA.
Hardware/Software FMEA
Sowohl die Hardware, als auch die Software kann durch eine FMEA auf mögliche Schwachstellen analysiert werden, um rechtzeitig Abstellmaßnahmen zu definieren. Bei der Hardware werden neben systematischen Fehlern auch zufällige Fehler gesucht. In der Software hingegen sind nur systematische Fehler Ziel der Analyse.
FMEA Durchführung
System FMEA
Einzelschritte bei der Durchführung
Schritt 1: Funktionale Durchsprache des zu untersuchenden Systems.
Das System wird im FMEA-Team durchgesprochen und seine Funktionen herausgearbeitet. Diese Funktionen werden im nächsten Schritt benötigt. Auch Schnittstellen und ähnliche Zusammenhänge zwischen Teilsystemen werden hier betrachtet.
Schritt 2: Strukturaufbruch
Die herausgearbeiteten Funktionen werden in einer Struktur eingetragen, die als Baum aufgebaut ist. Diese Darstellung hilft später auch der Übersichtlichkeit.
Schritt 3: Definition von Funktionen
Die einzelnen Funktionen werden genauer beschrieben und definiert, das bedeutet, es wird explizit für jede zu untersuchende Funktion beschrieben, was diese bewirkt. Es muss darauf geachtet werden, dass Funktionsgruppen sauber aufgetrennt werden.
Schritt 4: Definition von Fehlfunktionen und deren Ursachen
Für jede Funktion werden die möglichen Fehlfunktionen definiert und deren mögliche Ursache bestimmt.
Schritt 5: Bewertung der Auftretenswahrscheinlichkeit der Fehlerursachen im Feld
Im FMEA-Formblatt wird nun für die Auftretenswahrscheinlichkeit der jeweiligen Fehlerursache eine Zahl zwischen 1 und 10 eingetragen. 10 bedeutet, dass die Wahrscheinlichkeit sehr hoch sein wird, 1 hingegen, dass das Auftreten fast unmöglich ist.
Schritt 6: Beschreibung und Bewertung der Fehlererkennungsmechanismen des Systems
Dieser Schritt dient der Beschreibung der Fehlererkennungsmechanismen innerhalb des System und einer Bewertung im FMEA-Formblatt. Auch hier gibt es eine Bewertung mit einer Zahl zwischen 1 und 10. In diesem Fall wird die Bedeutung des Fehlers bewertet.
Schritt 7: Beschreibung der tatsächlichen Fehlerfolge unter Berücksichtigung der implementierten Fehlerreaktion
Wenn eine Fehlerreaktion implementiert wurde, lässt sich meist schon ein niedriger Wert für die Erkennung des Fehler annehmen. Sollte eine Erkennung nicht so einfach möglich sein, kann es gut sein, dass noch andere Methoden implementiert werden. Auch hier gibt es wieder eine Bewertung mit einer Zahl zwischen 1 und 10.
Schritt 8: Auswertung und Bewertung der Ergebnisse
Die Auswertung erfolgt zum einen über die Risiko-Prioritätszahl (RPZ), als auch über eine textuelle Beschreibung. Über die Zahl lassen sich die tatsächlich kritischen Fehler herausfiltern und gezielt zuerst beseitigen.
Schritt 9: Optimierungsmaßnahmen zur Reduzierung des Risikos
Zuletzt wird noch festgelegt, wie das Risiko für einen solchen Fehler weiter verringert werden kann, das bedeutet, es können weitere oder andere Maßnahmen definiert und bewertet werden.
Design FMEA
Die Durchführung ist quasi identisch zur System FMEA, mit dem Unterschied, dass insbesondere Versagensarten der Einzelkomponenten bzw. Einzelbauteile eines Systems untersucht werden. Es geht also darum, welche einzelnen Bauelemente oder Komponenten bei einer bestimmten Funktion zu Ausfällen führen können. Und wie diese Ausfälle erkannt und vermieden werden können.
Das FMEA Template
Wie auch bei Review Template gibt es für eine FMEA ebenfalls ein Template. Dieses ist allerdings sehr allgemein gehalten und sollte entsprechend auf die eigenen Bedürfnisse angepasst werden. Aus diesem Grund möchte ich in diesem Teil nun den Inhalt beschreiben, den ein FMEA Template enthalten soll.
Aufbau der Tabelle
Im oberen Teil sollte sich als erstes der Dokumentenkopf befinden, ähnlich wie auch im Review Template. Dieser beinhaltet neben dem Projektnamen auch den Namen des Autors der Tabelle, welchen Status diese hat oder auch in welcher Version diese Tabelle vorliegt.
Anschließend sollte eine Übersicht erfolgen, wer an der Analyse teilgenommen hat und aus welcher Abteilung/Firma diese Person stammt. Damit lässt sich später nachvollziehen, wie es zu der Analyse kam. Die Liste der verwendeten Dokumente (mit Angabe der Version bzw. des Datums) kann auch an dieser Stelle angelegt werden.
Nun kommt die eigentliche FMEA Analysetabelle. Diese behandelt nun für jedes Element im System/Gerät die spezifischen Ausfallmöglichkeiten. Dazu gehören auch die mögliche Fehlerursache und die daraus resultierende Fehlerfolge.
Um nun eine Art Quantifizierung zu ermöglichen, wird nun jeder Eintrag mit folgenden drei Kennzahlen versehen:
- A = Möglichkeit des Auftretens
- B = Beurteilung der Bedeutung
- E = Möglichkeit der Entdeckung
Jede Kennzahl kann im Wertebereich von 1 bis 10 liegen. Die Werte ergeben folgende Abstufungen:
Bedeutung:
| 10 | Verstoß gegen ein Gesetz |
| Störung einer kritischen Sicherheitsfunktion | |
| 9 | Verletzung einer Sicherheitsanforderung mit Warnung |
| Totalausfall Hauptfunktionalität | |
| 8 | Hauptfunktionalität stark eingeschränkt |
| Entfall einer Redundanz | |
| 7 | Hauptfunktionalität mäßig eingeschränkt |
| Totalausfall Komfortfunktionalität | |
| 6 | Hauptfunktionalität geringfügig eingeschränkt |
| Komfortfunktionalität stark eingeschränkt | |
| 5 | Hauptfunktionalität kaum merklich eingeschränkt |
| Komfortfunktionalität mäßig eingeschränkt | |
| 4 | Komfortfunktionen geringfügig eingeschränkt |
| 3 | Komfortfunktionalität kaum merklich eingeschränkt |
| 2 | Sehr geringe Funktionseinschränkungen Hauptfunktionen, die nur von Fachpersonal erkennbar sind |
| 1 | Sehr geringe Funktionseinschränkungen Komfortfunktionen, die nur von Fachpersonal erkennbar sind |
Auftreten:
| 10 | Sehr häufiges Auftreten zu erwarten |
| Neue Technologie ohne Erfahrungen | |
| 9 | Sehr häufiges Auftreten zu erwarten |
| Neue Technologie mit geringen Erfahrungen | |
| 8 | Häufiges Auftreten zu erwarten |
| Technologie mit mäßigen Erfahrungen, Einsatz mäßig bewährter Technologie in völlig neuer Umgebung | |
| 7 | Häufiges Auftreten zu erwarten |
| Einsatz bewährter Technologie in völlig neuer Umgebung | |
| 6 | Mäßige Häufigkeit |
| Einsatz bewährter Technologie mit wesentlichen Änderungen der Umgebung | |
| 5 | Mäßige Häufigkeit |
| Einsatz bewährter Technologie mit mäßiger Änderung der Umgebung | |
| 4 | Mäßige Häufigkeit |
| Einsatz bewährter Technologie mit geringfügiger Änderung der Umgebung | |
| 3 | Geringe Häufigkeit |
| Einsatz bewährter Technologie mit mäßigen Spezifikationsänderungen | |
| 2 | Geringe Häufigkeit |
| Einsatz bewährter Technologie mit geringen Spezifikationsänderungen | |
| 1 | Sehr geringe Häufigkeit |
| Einsatz bewährter Technologie ohne Spezifikationsänderungen |
Entdeckung:
| 10 | im allgemeinen nicht erkennbar |
| 9 | Erkennung durch Werkstatt Diagnose mit DC>=60% |
| Systematische Fehler: Erkennung mit geringer Wahrscheinlichkeit | |
| 8 | Erkennung durch Werkstatt Diagnose mit DC>=90% |
| Systematische Fehler: Erkennung durch Analysen während der Entwicklung | |
| 7 | Erkennung durch Werkstatt Diagnose mit DC>=99% |
| Systematische Fehler: Erkennung durch Simulationen während der Entwicklung | |
| 6 | Erkennung durch Power-up/Power-down Diagnose mit DC>=60% |
| Plausibilitätsprüfungen zur Laufzeit | |
| Systematische Fehler: Erkennung durch detaillierte Reviews | |
| 5 | Erkennung durch Power-up/Power-down Diagnose mit DC>=90% |
| Teilweise funktionale homogene Redundanz | |
| Systematische Fehler: Erkennung durch detaillierte Reviews (Walkthrough) | |
| 4 | Erkennung durch Power-up/Power-down Diagnose mit DC>=99% |
| Vollständige funktionale homogene Redundanz | |
| Systematische Fehler: Erkennung durch systematische Reviews (inspection) | |
| 3 | Erkennung durch zyklische Diagnose mit DC>=60% |
| kurze Zykluszeit | |
| Teilweise funktionale inhomogene Redundanz | |
| Systematische Fehler: Erkennung durch komplexe Entwicklertests | |
| 2 | Erkennung durch zyklische Diagnose mit DC>=90% |
| kurze Zykluszeit | |
| Vollständige funktionale inhomogene Redundanz | |
| Systematische Fehler: Erkennung durch Fehlerinjektionstests während der Entwicklung | |
| 1 | Erkennung durch zyklische Diagnose mit DC>=99% |
| kurze Zykluszeit | |
| Systematische Fehler: Erkennung durch Funktionstest während der Entwicklung |
Danach kann das Produkt dieser drei Werte gebildet werden und ergibt eine Risiko-Prioritäts-Zahl (RPZ). Je höher der Wert, desto höher die Priorität, mit der man sich um diesen Fehler kümmern sollte. Nun kann man gleich noch als Ergänzung eintragen, was mögliche Vermeidungs- und Entdeckungsmaßnahmen sein können.
Hat man das Design überarbeitet, lässt sich in weiteren Spalten der Tabelle ein neuer Durchlauf zu diesem Punkten erstellen und man kann erkennen, wie sich die RPZ verändert hat. Der Wert sollte nun natürlich wesentlich geringer sein, als noch zuvor.
Download des Templates
Du kannst Dir gerne mein praxiserprobtes Template herunterladen.
Ich habe es für Dich in meiner Online Bibliothek hinterlegt.
Und falls Du noch keinen Zugriff haben solltest, dann hole dir schnell einen.