Workshop am Whiteboard

5 Tipps für eine effiziente FMEDA/ quantitative FMEA

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).

1. Starten Sie mit dem grundlegenden Konzept und verlieren Sie sich nicht in den Details

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 FMEDA 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 FMEDA 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).

2. Sicherheit entsteht durch Diskussion und Zusammenarbeit

Noch vor der strukturierten Dokumentation ist es eine wichtige Aufgabe der Sicherheitsanalyse, alle involvierten Experten zu vernetzen. Einige Bespiele dafür sind:

  • Domänen-übergreifende Experten Teams: In komplexen Systemen bewähren sich FMEDA Workshops mit den Experten aller beteiligten Disziplinen, damit diese kompetent bewerten können, wie einzelne Fehlerarten sich durch das System fortpflanzen.
  • Entwickler der Sicherheitsfunktionen und der Diagnosefunktionen/ Sicherheitsmechanismen: Zur Detektion der Hardware Bauteilfehler werden oftmals Sicherheitsmechanismen in Software implementiert. Hier benötigt es eine enge Zusammenarbeit der Hardware- und Software-Entwickler bei der Spezifikation/ Design und der Bewertung des erreichten Diagnosedeckungsgrades.
  • Autor und Prüfer der FMEDA: Das Vier-Augen-Prinzip ist ein bewährtes Mittel zur Verifikation der Analyse (z.B., dass keine Fehler vergessen werden oder um einfache Copy-Paste Fehler zu vermeiden). Jedoch sollte der Aufwand für die Kommunikation zum Klären von Review Befunden nicht unterschätzt werden.

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 FMEDA als Hilfsmittel, um die Kommunikation zu strukturieren und eine gemeinsame Diskussionsgrundlage zu schaffen.

3. Metriken sind oberflächlich, aber trotzdem hilfreich

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.

4. Stellen Sie klar, was (und was nicht) analysiert wird

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:

  • Fehler beim Design der Schaltung (systematische Hardware-Fehler, z.B. Berechnungsfehler bei der Auslegung eines Widerstandes)
  • Fehler in der Softwareentwicklung (systematische Software-Fehler, z.B. Überlauf einer Variablen bei Festkomma-Arithmetik)
  • Fehler mit gemeinsamer Ursachen (z.B. Temperatur, Speisung, Takt, …)
  • Ausfall mehrerer Bauteile im Feld
  • Fehler während der Produktion

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.

5. Der Bericht ist die Analyse

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:

  • Referenz (inkl. Version) der analysierten Dokumente (wie Schema und Spezifikation der Sicherheitsfunktion)
  • Referenzen zu den verwendeten Standards (z.B. für die Ermittlung der Bauteilfehlerrate)
  • Zusammenfassung des Vorgehens
  • Team, das die Analyse erstellt hat
  • Zusammenfassung der erreichten Sicherheit

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.

Was sind Ihre Erfahrungen?

Welche Erfahrungen haben Sie in Ihrem Projekt gemacht? Lassen Sie es mich in den Kommentaren wissen…

Gerne unterstützen wir Sie bei Ihrem Projekt:

  • Wir beraten Ihr Projektteam von der Definition des Sicherheitskonzepts bis zur Erstellung der FMEDA
  • Wir leiten und dokumentieren als FMEA/ FMEDA Moderatoren Workshops mit Ihren Experten
  • Wir erstellen oder verifizieren die FMEA/ FMEDA für Sie, basierend auf Ihren Schemas und Ihren Sicherheitsanforderungen
  • Wir beraten Sie bei der Definition Ihres FMEA/ FMEDA Prozesses und der Erstellung der entsprechenden Vorlagen

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

Was ist Ihre Meinung? Kommentieren Sie hier!

Stichworte/ Tags

Keine Kommentare

Was ist Ihre Meinung?

Teilen auf

Lassen Sie uns Ihre Idee/ Ihr Projekt diskutieren