Software-FMEA ist nicht einfach DFMEA mit Softwarebegriffen.
Deshalb ist SAE 1025 - 2026 eine interessante Norm, deren Entwicklung es zu verfolgen gilt.
Die meisten Teams in der Automobilindustrie kennen FMEA aus dem vertrauten Bereich der:
▪ Risiko der Produktentwicklung
▪ Prozessrisiko
▪ Ursache-Wirkungs-Analyse
▪ Vermeidungs- und Entdeckungsmaßnahmen
▪ Verbesserung anhand der Aufgabenpriorität
AIAG VDA FMEA hat in diesem Bereich eine konsequente Vorgehensweise etabliert.
Software versagt jedoch nicht immer wie ein Bauteil.
Software kann aus folgenden Gründen versagen:
▪ Falsche Logik
▪ Fehlende Bedingung
▪ Falscher Zeitpunkt
▪ Fehlerhafter Zustandsübergang
▪ Nicht übereinstimmende Schnittstellen
▪ Problem bei der Datenverarbeitung
▪ Diagnoselücke
▪ Fehler nicht erkannt
▪ Fehler erkannt, aber nicht richtig behandelt
Bei softwareintensiven Fahrzeugen lautet die Frage nicht nur:
„Was kann ausfallen?“
Die bessere Frage lautet:
„Was kann die Software falsch, gar nicht, zu spät, zu früh oder im falschen Zustand ausführen?“
Das ist eine andere Denkweise.
Der öffentlich verfügbare Anwendungsbereich von SAE 1025 umfasst ausdrücklich FMEA mit Kritikalitätsanalyse, Design-FMEA, Supportability-FMEA, Software-FMEA und Prozess-FMEA.
Dadurch wird sie nicht zu einem Ersatz für die AIAG VDA FMEA.
Es erinnert uns jedoch daran, dass sich FMEA-Denken weiterentwickeln muss, wenn Fahrzeuge zunehmend softwaredefiniert werden.
Bei SDV-, EV-, ADAS- und vernetzten Fahrzeugprogrammen sollte die Software-FMEA verknüpft sein mit:
▪ Anforderungen
▪ Architektur
▪ Schnittstellen
▪ Zustände und Modi
▪ Diagnosefunktionen
▪ Sicherheitsmechanismen
▪ Annahmen zur Cybersicherheit
▪ Verifikations- und Validierungsnachweise
▪ Feldüberwachung und Softwareaktualisierungsstrategie
Meine Sichtweise ist einfach.
AIAG VDA FMEA bleibt für die Qualitätsplanung in der Automobilindustrie äußerst relevant.
Softwareintensive Produkte benötigen jedoch ein stärker verhaltensbezogenes Denken über Fehler.
In der Zukunft der FMEA wird es nicht nur um bessere Vorlagen gehen.
Es wird um eine bessere Vorstellung möglicher Fehler gehen.
Sind unsere FMEA-Teams auf softwaredefinierte Fehlerarten vorbereitet?
#FMEA #SoftwareFMEA #SAE1025 #AIAGVDAFMEA #SDV #AutomotiveQuality #FunctionalSafety