Lesezeit 6 min
Die FMEDA (Failure Modes Effects and Diagnostic Analysis) ist eine bewährte, von allen gängigen Standards für funktionale Sicherheit geforderte Methode für die Analyse von ausfallsicheren Hardware Schaltungen. In einigen Industrien wird die Methode auch quantitative FMEA (Failure Modes and Effects Analysis) genannt.
Nachfolgend die wichtigsten Tipps für eine effektive und effiziente Nutzung dieses Werkzeugs basierend auf unseren Erfahrungen in Projekten aus den Bereichen Industrie (IEC 61508, ISO 13849), Automotive (ISO 26262) und Luftfahrt (DO-254, ARP4761).
Die FMEA geht induktiv vor, d.h. von der Ursache zum Fehler. Die Fragestellung ist dabei für jedes Subsystem/ Bauteil: Welche sicherheitsrelevanten "Effekte" können aus einem Fehler entstehen?
Z.B. wenn dieses Bauteil seinen Wert über die Zeit ändert (d.h. es altert): wie wirkt sich das auf die Funktion aus? Z.B. wenn sich ein Zustandsautomat um ein Bit verschluckt: wie wirkt sich das auf die Funktion aus?
Von der FMEA existieren zwei Varianten, eine rein qualitative und eine quantitative. Bei der letzteren werden der Analyse Ausfallwahrscheinlichkeiten für die verschiedenen Fehlerarten (Kurzschluss, Leerlauf, Drift, Stuck-At...) der Bauteile unterlegt.
Im industriellen und automobilen Umfeld wird ein Spezialfall einer quantitativen FMEA, die FMEDA, in der Regel für den elektronischen Teil, durchgeführt.
Bei einer FMEDA wird die Reduktion der Ausfallraten direkt für Diagnosemechanismen (z.B. Rücklesen von Ausgangssignalen) angerechnet.
Sicherheitsanalysen bewerten den momentanen Stand der Architektur/ des Designs. Sie ermitteln iterative Optimierungen, bis eine ausreichende funktionale Sicherheit gewährleistet ist. Verpassen Sie das Zeitfenster am Anfang des Projektlebenszyklus nicht, in dem grundlegende Änderungen am Design ohne grossen Aufwand vorgenommen werden können.
Das heisst: die FMEDA startet lange bevor das erste Schema steht. Die ersten Analysen starten auf höherem Abstraktionslevel, zum Beispiel auf der Grundlage der ersten Skizzen eines System-Blockdiagramms. Bereits in dieser Phase können Sicherheitsmechanismen entworfen werden, die Ausfälle gesamter Blöcke abdecken. Hier bieten die Normen mit bewährten Architekturen (z.B. Diagnosepfad oder Redundanz) und Sicherheitsmechanismen (z.B. Kreuzvergleich, CRC, …) entsprechende Hilfestellung. Dies kann informell, während des Designs erfolgen. Bei komplexeren Projekten führt man besser frühzeitig eine strukturierte Analyse der Funktionen von Blöcken durch (z.B. als System-FMEA).
Mit der Erstellung der detaillierten Fehleranalyse auf der Ebene von einzelnen Bauteilfehlern (wie von den Normen gefordert) empfiehlt es sich jedoch zuzuwarten. Erstellt man diese erst mit dem fertigen Schema, spart man sich den Aufwand für die spätere Nachpflege von Änderungen.
Wir sehen die FMEA sowohl als Entwurfsinstrument (linke Seite des V-Modells: Design/ Synthese der Funktion selbst und deren Sicherheitsmechanismen) wie auch als Verifikationsinstrument (rechte Seite des V-Modells: quantitative Bewertung der Ausfallssicherheit). Die FMEA zeigt auch, wie wichtig es ist, das System sauber zu strukturieren und möglichst einfache und klare Konzepte zu wählen (KISS – Keep it stupid simple).
Noch vor der strukturierten Dokumentation ist es eine wichtige Aufgabe der Sicherheitsanalyse, alle involvierten Experten zu vernetzen. Einige Bespiele dafür sind:
Eine Sicherheitsanalyse soll ein tieferes Verständnis der Schaltung schaffen, auch unter Gesichtspunkten, die im normalen Designprozess oft nicht betrachtet werden. Dies kann nur in der Diskussion unter Einbezug aller Beteiligten entstehen und ist letztendlich viel wichtiger als die eingesetzten Tools oder das Erreichen der Metriken. Wir sehen die FMEA als Hilfsmittel, um die Kommunikation zu strukturieren und eine gemeinsame Diskussionsgrundlage zu schaffen.
Die Normen definieren Ziel-Metriken (PFH, SFF, DC, MTTFD, SPFM, PMHF, etc.), da sie eine einfache und klare Definition des akzeptablen Restrisikos ermöglichen. Jede Metrik misst jedoch nur genau die Aspekte, die bei der Definition der Formel berücksichtigt wurden. Daher können Metriken leicht überlistet werden. Somit können sie eine ingenieurtechnische Bewertung und den gesunden Menschenverstand niemals ersetzen. Zusätzlich ist die Qualität der Datengrundlage (z.B. Ausfallraten von Bauteilen) oftmals begrenzt.
Während des Entwurfsprozesses helfen Metriken jedoch bei der Identifizierung und Priorisierung von Schwachstellen im Entwurf. Auch in der funktionalen Sicherheit gilt das Pareto Prinzip: der Fokus der Massnahmen soll bei den wichtigen Fehlerfällen liegen, da dort die grösste Risikominimierung erreicht wird. Da auch seltene Fehlerfälle/ Corner Cases betrachtet werden müssen, heisst dies jedoch auch, dass hier ein grosser Teil des Aufwandes liegt.
Unsere Erfahrung hat gezeigt, dass bei der detaillierten FMEDA die Metriken meist problemlos erreicht werden, ohne Optimierung in den Kommastellen, sofern die FMEDA frühzeitig gestartet wurde (wie oben empfohlen).
Eine haarscharfe Erfüllung der Metriken weist oft auch daraufhin, dass bei der Analyse manipuliert wurde, daher wird ein Auditor hier genauer hinsehen. Schwierig wird die Argumentation dann, wenn für zentrale Teile der Sicherheitsfunktion keine Sicherheitsmechanismen bestehen.
Wird die Metrik knapp nicht erreicht, lohnt es sich, dies im Gesamtkontext des Systems zu bewerten. Hier besteht oft Spielraum, so dass dies dennoch akzeptiert werden kann.
Die FMEDA ist nötig, aber nicht ausreichend, um die Sicherheit eines Hardware Designs zu gewährleisten. Die FMEDA analysiert das Verhalten der Schaltung beim Ausfall eines einzelnen Bauteils im Feld, d.h. zufällige Hardware Fehler. Nicht abgedeckt sind zum Beispiel:
Während der Analyse empfiehlt es sich, die Fehler, die entdeckt werden, aber nicht in den Bereich der FMEDA gehören, auf einem Parkplatz zu sammeln. Sie können danach in den entsprechenden Analysen- und Designaktivitäten behandelt werden.
Die Analyse erfolgt immer in Bezug auf ein spezifisches Sicherheitsziel. Dieses definiert, welche unsicheren Zustände nicht auftreten dürfen. Auch ist zu spezifizieren, welche sicheren Zustände in einem Fehlerfall anzustreben sind. Zu beachten ist, dass für die gleiche Schaltung je nach Anwendung unterschiedliche Sicherheitsziele denkbar sind.
Zum Start der Analyse sollen die Sicherheitsanforderung und der Umfang der analysierten Fehler im Report definiert werden. Diese Voraussetzungen müssen allen Beteiligten bekannt sein, damit nicht von unterschiedlichen Annahmen ausgegangen wird. Auch wenn eine bestehende Sicherheitsanalyse in einem neuen Projekt wiederverwendet wird, muss zuerst geprüft werden, ob die zugrundeliegenden Annahmen noch zutreffen.
Die FMDEA beinhaltet nicht nur die Tabelle zur Bewertung jeder Fehlerart und jedes Bauteils. Zur späteren Nachverfolgbarkeit sollte ein Bericht erstellt werden, der folgende Punkte abdeckt:
Siehe dazu auch die entsprechenden Checkpunkte im Blogbeitrag zur Software Sicherheitsanalyse.
Beachten Sie das Zielpublikum: Die FMEDA-Tabelle ist ein Instrument des Expertenteams, sie dient zur Bewertung, der Berechnung der Metriken und der Kontrolle, dass nichts vergessen geht. Der Bericht adressiert die Projektleitung (z.B. Safety-Manager), Auditoren und allfällige Auftraggeber oder Integratoren, die einen Nachweis und Evidenz benötigen, dass Sicherheitsrisiken ausreichend minimiert wurden.
Welche Erfahrungen haben Sie in Ihrem Projekt gemacht? Lassen Sie es mich in den Kommentaren wissen…
Gerne unterstützen wir Sie bei Ihrem Projekt:
Nutzen Sie unsere SolceptClinic und senden Sie mir Ihre konkreten Fragen zur FMEDA. Und das Beste ist: diese erste time-boxed Konsultation von 30 Minuten kostet Sie nichts.
Luzian Hürlimann (Originalbeitrag), die Seite wird betreut von Andreas Stucki
Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!
ist Elektroingenieur und Systemingenieur, Hardware-, System- und Safety-Spezialist. Er engagiert sich für Prozesse und effiziente funktionale Sicherheit. Er hält sich mit dem Mountainbike fit.
Projekte? Ideen? Fragen? Machen wir einen kostenlosen Erst-Workshop!
Keine Kommentare