Software-FMEA nach SAE J1025: eigener Rahmen für Softwarerisiko
In Fahrzeugen, Steuergeräten und Medizinprodukten steckt der größte Teil des Funktionsumfangs heute in Software. Viele Teams bewerten diese Software aber weiter mit Fehlerarten, wie Bruch, Verschleiß und Ausfallrate, die eigentlich für Bleche und Wellen gedacht sind. Software kennt keinen Verschleiß. Sie trägt latente Defekte, die erst unter bestimmten Eingaben und Zuständen auslösen und braucht deshalb eine eigene Risikologik.
Nach dem Beitrag wissen Sie, warum SAE J1025 die Software-FMEA als eigenen Typ führt, wie das Auftreten für Software strukturiert bewertet wird und wie die Analyse den Nachweis für ISO 26262 und MIL-STD-882E stützt.
Warum Software eine eigene FMEA-Art braucht
Hardware versagt, weil Bauteile sich verändern. Der Ausfall folgt einer Ausfallrate, mischt zufällige und systematische Anteile und wird über Prüfung und Messung entdeckt. Alterung über die Zeit dominiert das Bild. Für diese Welt ist die klassische DFMEA gebaut.
Software kennt keinen Verschleiß. Was in ihr steckt, sind latente Defekte, die vom ersten Tag an vorhanden sind und erst durch bestimmte Eingaben und Zustände ausgelöst werden. Das AIAG-VDA-Handbuch nimmt Software in die DFMEA auf. SAE J1025 geht den anderen Weg und schneidet sie als eigenen Analysetyp heraus, damit Zustand, Ablauf, Zeitverhalten und Daten zu den Leitkategorien werden. Wie weit die beiden Denkweisen auseinanderliegen, zeigt die Gegenüberstellung in Bild 1.
Das Auftreten wird zur strukturierten Schätzung
Der Kern von SAE J1025 steckt in der Bewertung des Auftretens (A). In der klassischen FMEA sagt ein Team oft „das ist eine 4" und meint damit ein Gefühl. Für Software definiert SAE J1025 das Auftreten stattdessen als zusammengesetzte Größe aus vier einzeln bewertbaren Faktoren:
Auftreten = Existence × Manifestation × Prevention × Detection / 4
Existence fragt, ob der Defekt im Code plausibel existiert. Manifestation fragt, unter welchem Anteil der Eingaben und Zustände er sich zeigt. Prevention steht für die Vermeidungsmaßnahmen aus Codierrichtlinien, Reviews und statischer Analyse. Detection steht für die Entdeckungsmaßnahmen aus Unit-, Integrations- und Systemtest. Das Ergebnis liegt auf einer Skala von 1 bis 5 und wird mit der Bedeutung (B) in einer [SO]-Matrix aus Severity und Occurrence zusammengeführt. Keine Risikoprioritätszahl (RPZ), keine Aufgabenpriorität (AP): Die Kritikalität wird Faktor für Faktor belegbar.
Der Sechs-Schritte-Prozess: gleiche Form, anderer Inhalt
Wer die FMEA nach AIAG-VDA kennt, findet sich in der SwFMEA schnell zurecht.
SAE J1025 führt durch die sechs Schritte:
- Planung
- Vorbereitung und Umfang
- Technische Risikoanalyse
- Kritikalitätsanalyse
- Maßnahmen zur Risikominderung
- Updates und Versionskontrolle
Die Form ähnelt der DFMEA, der Inhalt ist ein anderer.
In die Analyse fließen die Design-Flows aus Zustand, Ablauf, Zeitverhalten und Daten ein, dazu die Softwarearchitektur mit ihren Schnittstellen, das Software Operating Environment (SOE) und die CWE. Heraus kommen Fehlerarten je Design-Flow-Element, eine [SO]-Kritikalität mit Bändern in Hoch, Mittel und Niedrig, empfohlene Maßnahmen für Design, Test und Prozess sowie ein Nachweispfad für ISO 26262 und MIL-STD-882E. Dieser Nachweispfad ist für viele Projekte der eigentliche Gewinn, weil die SwFMEA die Belege liefert, die eine Sicherheitsargumentation später ohnehin verlangt.
CWE als Quelle der Fehlerarten: die Brücke zu Safety und Security
SAE J1025 verweist ausdrücklich auf die Common Weakness Enumeration (CWE) von MITRE als Quelle für Software-Fehlerarten. Die Fehlerarten müssen also nicht erfunden werden. Die CWE ist ein gepflegter, von der Fachgemeinschaft kuratierter Katalog von Softwareschwächen. Das Team arbeitet nicht mehr an der Frage, welche Fehler es überhaupt geben kann, sondern konzentriert sich auf Relevanz, Bedeutung und Entdeckung.
Damit verbindet die SwFMEA zwei Welten, die in vielen Organisationen getrennt laufen. Auf der Seite der funktionalen Sicherheit liefert sie die Nachweisebene für den Level of Rigor nach MIL-STD-882E und für die ASIL-Zerlegung nach ISO 26262. Auf der Seite der Schwachstellen bringt die CWE den Security-Fall und den Safety-Fall in dieselbe Bewertung.
Drei Muster, die eine Software-FMEA scheitern lassen
Auftreten aus dem Bauchgefühl. Wird das Auftreten als einzelne Zahl geschätzt, bleibt die Bewertung unbelegt. Die Gegenmaßnahme steckt in der Zerlegung in Existence, Manifestation, Prevention und Detection.
Mechanische Fehlerarten auf Code übertragen. Bruch, Verschleiß oder Kurzschluss passen nicht auf Softwarefunktionen. Softwarefehlerarten kommen aus der CWE und aus der Analyse der Design-Flows in Zustand, Ablauf, Zeitverhalten und Daten.
Die SwFMEA nebenbei erledigen. Das Hardware-DFMEA-Team kann die Softwareanalyse nicht im Vorbeigehen mitnehmen. Software braucht ein eigenes, funktionsübergreifendes Team aus Softwarearchitekten, Testingenieuren und einem Sicherheitsexperten.
Beispiel
Ein Team bewertet eine Eingabevalidierung nach SAE J1025. Existence ist hoch, weil der betroffene Pfad nachweislich ungeprüfte Werte annimmt. Manifestation ist niedrig, weil nur ein schmaler Wertebereich den Fehler auslöst. Prevention liegt im Mittelfeld, weil eine Codierrichtlinie greift, ein statischer Analyselauf aber fehlt. Detection richtet sich nach der Testtiefe, die den Pfad abdeckt. Aus diesen vier begründeten Einzelurteilen entsteht ein Auftretenswert, den ein Auditor nachvollziehen kann, statt eine einzelne Zahl aus dem Bauchgefühl hinnehmen zu müssen.
Ein zweites Beispiel zeigt die Herkunft der Fehlerarten. Ein Zähler, der bei einem ungewöhnlich großen Eingabewert überläuft, ist keine mechanische Fehlerart, sondern eine bekannte Schwäche aus der CWE (Ganzzahlüberlauf). Das Team wählt sie aus dem Katalog aus und bezieht sie auf die eigene Funktion, statt ein neues Versagensbild zu erfinden.
Ergebnis
Software fällt anders aus als Hardware. Wer sie mit einer eigenen FMEA nach SAE J1025 behandelt, findet Risiken, die eine DFMEA allein übersieht, und liefert zugleich den Nachweis für die funktionale Sicherheit.
Sie wollen Softwarerisiko methodensicher in Ihre FMEA einbinden? Sprechen Sie mit uns über eine SwFMEA-Pilotanalyse oder das passende DC-Modul: www.dietz-consultants.com
Autor: Winfried Dietz, CEO Dietz Consultants GmbH
Winfried Dietz ist CEO der Dietz Consultants GmbH und begleitet seit über 30 Jahren Entwicklungsorganisationen weltweit bei der Einführung und Reifung der FMEA-Methodik. Er ist Trainer, Autor und Referent für FMEA nach AIAG-VDA. Mehr von der FMEA-Quick-Tip-Reihe finden Sie auf LinkedIn.