FMEA – Eine mächtige Methode, aber nicht für Software!
In der Funktionalen Sicherheit gibt es eine Methode, die immer zum Einsatz kommt – die FMEA (Failure Mode Effects Analysis).
Insbesondere auf System- und Hardwareebene unterstützt man damit systematische Analysen. Es gibt auch verschiedene Ausprägungen wie z.B. die FMECA und die FMEDA. In diesem Blogbeitrag verwende ich nur den Überbegriff FMEA.
In der Projektpraxis stellt sich oft die Frage, ob nicht auch auf Softwareebene eine FMEA Sinn macht und erstellt werden muss.
Um sich dieser Frage zu nähern möchte ich zunächst den Sinn und Zweck von System und Hardware FMEAs bei der Erfüllung der Forderungen von Funktionalen Sicherheitsstandards wie ISO 26262 oder IEC 61508 erläutern, um danach den Einsatzzweck in der Software zu betrachten.
Systemebene:
Der Name Failure Mode Effects Analysis (FMEA) ist schon sehr selbsterklärend. Zunächst einmal scjhreibt man denkbare Fehler eines Systems systematisch in Tabellenform auf. Im zweiten Schritt werden die Auswirkungen dieser Fehler auf das zu betrachtende System analysiert und auch in der Tabelle dokumentiert. Im dritten Schritt werden, für nicht akzeptable Fehlerauswirkungen, in das System zu implementierende Gegenmaßnahmen definiert. Auf Systemebene werden dabei zunächst die funktionalen Eigenschaften und die sich daraus ergebenden Fehlerzustände analysiert. Sobald eine Systemarchitektur vorliegt, wird dann auch diese auf mögliche Schwachstellen und sich daraus ergebende Fehlerzustände untersucht.
Das Ergebnis von beiden Analysen sind zu implementierende Gegenmaßnahmen, um die möglichen Fehler mit einem tolerierbaren Risiko beherrschen zu können. Bei manchen Systemen gibt es auch Fehlerzustände, für die keine Gegenmaßnahmen implementiert werden können. In diesen Fällen wird dann ein weitergehendes Risikomanagement betrieben. Dieses steht nicht im Fokus dieses Blogbeitrags.
FMEA auf Hardware Ebene:
Auf Hardware Ebene stehen die Ausfälle einzelner Bauteile im Mittelpunkt der Analyse. Zwei wesentliche Ergebnisse werden durch diese Analyse erreicht: Es werden Ausfallraten ermittelt und Requirements an den Power-On Built-InTests, den Continuous Built-In-Test und den Maintenance Built-In-Test abgeleitet. Diese Analyse leistet damit einen wesentlichen Beitrag zur Beherrschung der zufälligen Fehler in einem System.
FMEA auf Software Ebene:
Wie sieht es nun bei der Software aus? Ist hier auch eine FMEA möglich, sinnvoll oder sogar gefordert von den funktionalen Sicherheitsstandards?
Nun, eine Forderung für eine Software-FMEA lässt sich aus den Standards in keinem Fall ableiten. Warum ist das so? Wie bei Hardware und auf Systemebene schon beschrieben, ist der Sinn einer FMEA, mögliche Fehler und deren Auswirkungen systematisch zu entdecken und zu analysieren.
Dies ist problemlos möglich, wenn die Funktionalität analysiert wird. Auch bei der Hardware ist diese Analyse sinnvoll, da der Ausfall von Bauteilen auf physikalischen Effekten beruht und damit kann man mit statistischen Methoden Ausfallwahrscheinlichkeiten ermitteln.
Bei der Software sieht das allerdings anders aus. Softwarefehler werden durch die Programmierer unbeabsichtigt implementiert. Alle Ursachen, die zu solch einer falschen Programmierung führen können, liegen am Human Factor (menschliches Fehlverhalten). Es gibt bis heute keine Möglichkeit um die Fehlerwahrscheinlichkeiten menschlicher Fehler in der Softwareentwicklung zu berechnen.
Natürlich besteht die Möglichkeit eine Software systematisch zu analysieren und dafür die FMEA als Methode zu verwenden. Dies bedeute, dass man z.B. Requirements und der Code entsprechend analysiert.
Tatsächlich sehen die Normen der Funktionalen Sicherheit solche Analysen vor. Sie heißen Requirements Reviews und Code Reviews.
Allerdings ist es so, dass die Komplexität und der Umfang eines Requirements Reviews sowie eines Code Reviews sehr hoch sind. Es ist schlicht nicht praktikabel und sinnvoll mit einer FMEA Requirements- und Codereviews durchzuführen.
Was fordern die Normen auf Software Ebene?
Zusätzlich fordern die Normen noch deutlich mehr, z.B. eine Vielzahl von dynamischen Tests, die mit einer Analyse per Definition nicht abgedeckt werden können. Schon aus diesen Gründen kann man erkennen, dass eine FMEA in der Software nicht sinnvoll ist.
Hinzu kommt noch, dass es unmöglich ist, Gegenmaßnahmen für Softwarefehler zu definieren. Das liegt daran, dass Softwarefehler durch menschliche Fehler in das System einfließen und nicht, wie bei der Hardware auf physikalischen Effekten beruhen. Für die Vorhersage von Anzahl, Häufigkeit und Schwere von menschlichen Fehlern gibt es bis heute keine ausreichend guten, mathematischen Modelle.
Schlussfolgerungen:
Zusammenfassend lässt sich sagen, dass eine Software FMEA nicht zielführend ist, wenn sie als Ersatz für die in den funktionalen Sicherheitsstandards definierten Methoden und Prozessen des Software Entwicklungsprozesses gedacht ist.
Meiner Erfahrung nach wird in der Praxis der Begriff Software FMEA oft verwendet, wenn eigentlich eine funktionale System FMEA gemeint ist. Dies hat seine Ursache darin, dass ein Großteil der Funktionalität von modernen Embedded Systemen in Software realisiert wird. Dadurch hat man das Gefühl, dass man eine Software FMEA durchführt, sobald man die Systemfunktionen systematisch analysiert.
Darüber hinaus gibt es noch den Einsatzzweck einer FMEA für die Analyse von Prozessen. Wenn man Schwachstellen eines Software Entwicklungsprozesses analysieren will, kann man eine sogenannte Prozess FMEA durchführen. In diesem Fall ist das Ziel aber „nur“ Schwachstellen des Prozesses zu identifizieren. Methoden und Prozesse der funktionalen Sicherheitsnormen sollen nicht ersetzt werden.
Ihre individuellen Fragen zur Funktionalen Sicherheit beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).
Diese Behauptung ist so nicht richtig.
Hallo Herr Heininger,
zunächst mal Respekt für Ihren Mut, diese provokannte These einem großen Fachpublikum vorzutragen.
Sicher gibt es Einsatzbereiche wo die FMEA das falsche Werkzeug darstellt, wer aber die moderne FMEA beherrscht, wird auch bei Softwareanalysen bezüglich der Anforderungen der funktionalen Sicherheit, einen Nutzen erzeugen, der weit über dem Aufwand steht.
Ihre Erkenntniss, Herr Heininger, kommt auch daher, dass Sie die FMEA als Requirement-Analyse kennen. In dem Fall haben Sie recht, dass dazu die FMEA das falsche Werkzeug darstellt.
Die FMEA kann, als präventive bidirektionale Analyse, Zeit und Geld in der Entwicklung sparen. Tut sie das nicht, sollten Sie die Methode und deren Prozesse in Ihrer Organisation optimieren.
Gerne können wir uns darüber unterhalten. (Ich habe Ihnen auch einige Beispiele).
Viele Grüße
Martin Werdich
Hallo Herr Heininger,
ich stimme Ihnen zu dass eine SW FMEA nicht dazu geeignet ist um Methoden im Functional Safety-Bereich zu ersetzen. Dazu nimmt auch der Standard DO-178C explizit Stellung und stellt die FMEA als ungeeignet dar.
Jedoch können FMEA-Methoden durchaus im Softwareumfeld sich als hilfreich und sinnvoll erweisen. Wir setzen die FMEA als Werkzeug ein um Fehlanwendung und interne Funktionsmodelle der Software systematisch zu erfassen und Maßnahmen abzuleiten.
Letztendlich verlangt die zulassende Stelle bei IEC61508 Projekten in aller Regel eine FMEA – auch für die Software. Also sollte man diese Methode dann auch wirkungsvoll – und entsprechend angepasst – anwenden.
Grüße
Thomas Amann
Hallo Herr Amann,
Hallo Herr Werdich,
vielen Dank für Ihre Kommentare.
Mir ist durchaus bewusst, dass der Titel des Blogs etwas provokant gewählt ist. Allerdings, auch schon im Titel steht, dass eine FMEA eine mächtige Methode darstellt. Ich stelle also das Potential von FMEAs in keinster Weise in Frage.
Mein Punkt ist, dass immer wieder versucht wird, die in den Normen beschriebenen Software Entwicklungsprozesse (Req, Architektur, Test, Analysen, Reviews etc.) zu „umgehen“, in dem man Software FMEAs macht. Das macht keinen Sinn und dient nicht der Safety. Eine FMEA, auch im Softwareumfeld, als flankierdende Maßnahme ist natürlich nur zu begrüßen.
Viele Grüße
Martin Heininger
Hallo Herr Heininger,
Sie sprechen mir aus der Seele!
Die Methode der FMEA (und ich bleibe jetzt einfach mal bei der Design-FMEA) ist im Rahmen der Automobilindustrie von rein mechanisch orientierten „Blechbiegern“ eingeführt worden. Zu diesem Zeitpunkt hat sich noch kein einziger Ingenieur darüber Gedanken gemacht, wie eine solche Methode auf Hardware oder sogar Software umgesetzt werden könnte.
Dazu hatte ich auch schon mal einen Artikel / Leserbrief in der FMEA-Konkret (Alles rein in die FMEA) hinterlassen.
In der Mechanik gehen wir im Rahmen der Design-FMEA auf konkrete Produktmerkmale wie Länge, Breite, Höhe, Radius, Durchmesser, Oberflächenbeschaffenheit oder Material ein. Das sind also die kleinsten Größen, die wir in der Mechanik beeinflussen können und in einer entsprechenden Zeichnung auch spezifizieren.
In der Hardware gehen wir dann im Rahmen der Design-FMEA auf Merkmale wie Widerstand, Kapazität oder Induktivität als kleinste Größe ein. Diese Daten halten wir dann in einem Schaltplan und natürlich dann auch in einem Layout fest. Und im Rahmen dieser Hardware-FMEA bedienen wir uns auch an Maßnahmen, die aus dem Bereich der Software kommen. Dabei handelt es sich um Entdeckungsmaßnahmen für nicht mehr funktionierende Hardware!
Wenn wir jetzt in der Software auf die kleinste zu definierende Einheit gehen wollen, dann sehe ich da nur die Parameter „0“ und „1“! Und jetzt kann mir doch bitte keiner erzählen, dass ich in einer Software-FMEA bei jedem einzelnen Bit untersuchen soll, was passieren würde, wenn dieses Bit falsch sein sollte!
1) Es gibt bei Software keine Alterungsprozesse wie bei der Mechanik oder Hardware
2) Die möglicherweise falschen Bits resultieren einzig und allein aus menschlichem Fehlverhalten
3) Und so gibt es zum Beispiel in der Produktion auch keine Möglichkeit einen vom Menschen hauptsächlich beeinflussten Prozess unter statistische Überwachung zu bringen!!!! Das wird zwar gerne immer wieder von OEMs gefordert ist aber vollkommener Quatsch.
Daher halte ich eine Software-Design-FMEA für ziemlich an den Haaren herbeigezogen und würde persönlich damit auch nicht anfangen wollen.
Wenn wir dann auf die System-Ebene gehen, dann sind wir wieder bei den Entdeckungsmaßnahmen durch Software für elektronische Systeme.
Mit freundlichen Grüßen
Jörg Schacht (FMEA-Moderator und AFSE)
PS: Umgekehrt halte ich es auch für wenig sinnvoll, Vorgehensweisen wie SPICE oder ASPICE, die speziell für Software entwickelt worden sind (weil es eben keine adäquaten Methoden gab) jetzt r
Hallo Herr Schacht
Das mit dem 0 und dem 1 lasse ich nicht gellten. Es kommt halt darauf an ob an der Richtigen Stelle eine Null oder Eins steht und ob zum richtigen Zeitpunkt aus einer aus der 0 die Eins wird (oder umgekehrt).
Ich selbst habe einen SW Lastiges Studium hinter mir und auch in der Entwicklung gearbeitet. Später habe ich im Mechanischen Bereich FMEA Kennen und schätzen lernen dürfen. Die Systematik begeistert mich und ich bin sicher das es mit den richtigen Kriterien und Beurteilungen auch in der SW anwendbar und hilfreich ist.
Da fehlte noch was! Bitte ergänzen – DANKE!
rückwärts wieder unbedingt auch auf die Mechanik anwenden zu wollen! Aber daraus können wir sicherlich noch ein ganz neues Diskussionsthema machen 😉
Sehr geehrte Kollegen
MIL-HDBK-338B Abschnitt 9.8.5 beschreibt, wie eine Software-FMEA sinnvoll durchgeführt warden kann.
Die Idee ist die Unterteilung der Software in ihre Komponenten und Units, wobei die FMEA dann für jedes Unit anhand der spezifizierten Soll-Funktion des Units die möglichen Failure Modes und ihre Effekte auf die höheren Ebenen (hoch bis zum System) bestimmt und deren Kritikalität bewertet.
Das Ergebnis kann dann beispielsweise verwendet werden, um diejenigen Units zu identifizieren, deren „Failure modes“ kritisch für das Gesamtsystem sind um entweder diese Failure Modes zu eliminieren (und dies durch entsprechende Tests nachzuweisen) oder sie auf der Komponenten-, Subsystem- oder Systemebene zu mitigieren (aus Gründen der Safety), oder ganz einfach um die begrenzten Review/Testaufwände auf die wirklich kritischen Units zu fokussieren (aus Gründen der Wirtschaftlichkeit).
Eine solche Software-FMEA lässt sich mit überschaubarem Aufwand durchführen, aber wie Hr.Heininger bereits festgestellt hat, kann sie keinesfalls als Ersatz für die klassischen Software-Qualitätssicherungs-Methoden dienen, sondern allenfalls als deren Ergänzung.
Mich interessieren praktische Beispiele zur Software-FMEA, könntet Ihr mir Referenzen nennen?
Sehr geehrter Herr Müller,
wie Sie dem Artikel entnehmen können, stehe ich sehr kritisch zur Software FMEA.
Der Begriff wird häufig verwendet, wenn man Funktionen eines Systems analysiert, welche in Software implementiert werden.
Die FMEA beginnt hier meisst mit der Frage, was passiert wenn die betrachtete Funktion nicht das tut wofür Sie gedacht ist. Oder was passiert, wenn die Funktionalität zwar gegebebn ist, aber das zeitliche Verhalten nicht stimmt. Ich würde in dem Fall aber eher von einer System FMEA reden und nicht einer SW FMEA.
Aus meiner Sicht macht es keinen Sinn, wenn man eine Software als Betrachtungsgegenstand hernimmt und dann folgende Frage stellt: Was passiert wenn ein Fehler in Code Zeile xy enthalten ist.
Viele Grüße
Martin HEininger
Interessant, dass die FMEA Methode zu einer Hardware und zu einer Software verbunden ist. Diese Möglichkeiten sollen definitiv hilfreich sein. Wie du schreibst, kann man damit systematischen Analysen unterstützen. Ich habe viel von FMEA gehört und informiere mich zum Thema, um einen besseren Überblick zu bekommen. Danke für den Beitrag!