DFMEA – Design Failure Mode and Effects Analysis

Die DFMEA (Design-FMEA) ist eine strukturierte Methode zur vorausschauenden Identifikation und Bewertung potenzieller Fehlerarten im Produktdesign, die zu Funktionsausfällen, Sicherheitsrisiken oder Qualitätsmängeln beim Endkunden führen können. Sie ist ein Pflichtdokument im PPAP-Prozess nach IATF 16949, wird in der Produktentwicklungsphase erstellt und folgt seit 2019 dem harmonisierten AIAG-VDA FMEA-Handbuch mit Action Priority-Bewertung.

Abgrenzung zur PFMEA: Dieselbe Methode, andere Verantwortung

Die DFMEA analysiert das Produkt. Die PFMEA analysiert den Prozess, der das Produkt herstellt. Diese Trennung klingt einfach, verschwimmt in der Praxis aber regelmäßig – mit konkreten Konsequenzen.

Ein Beispiel: Ein Kunststoffgehäuse bricht unter Betriebslast. Liegt die Ursache in einer zu geringen Wandstärke laut Zeichnung, ist das ein DFMEA-Thema – das Design hat versagt. Liegt die Ursache darin, dass die Wandstärke durch Prozessschwankungen beim Spritzguss unterschritten wurde, obwohl die Zeichnung korrekt ist, ist das ein PFMEA-Thema – der Prozess hat versagt.

Wer diese Trennung nicht konsequent zieht, riskiert, dass Maßnahmen auf der falschen Ebene definiert werden: Prozessoptimierungen für ein Designproblem lösen das Problem nicht, und Designänderungen für ein Prozessproblem sind teuer und unnötig.

Aufbau der DFMEA nach AIAG-VDA 2019

Wie die PFMEA folgt auch die DFMEA seit 2019 dem 7-Schritte-Ansatz des harmonisierten AIAG-VDA Handbuchs:

Der entscheidende Unterschied zur PFMEA liegt in Schritt 6: Maßnahmen in der DFMEA sind Designänderungen, zusätzliche Berechnungen, Simulationen oder Validierungstests – keine Prozess- oder Prüfanweisungen.

Severity, Occurrence und Detection im Design-Kontext

Die drei Bewertungsdimensionen haben in der DFMEA eine andere inhaltliche Bedeutung als in der PFMEA:

Severity (S) bewertet die Auswirkung des Fehlers auf den Endkunden oder Fahrzeugnutzer – nicht auf den Fertigungsprozess. Severity 9–10 ist reserviert für Fehler mit sicherheitsrelevanter Auswirkung ohne Vorwarnung, zum Beispiel Versagen eines tragenden Strukturbauteils oder Ausfall einer sicherheitskritischen Elektronikfunktion.

Occurrence (O) bewertet die Wahrscheinlichkeit, dass die Fehlerursache im Design unter den vorgesehenen Einsatzbedingungen auftritt – also die Zuverlässigkeit der Designlösung selbst, nicht die Prozessstabilität.

Detection (D) bewertet, wie sicher das Design und der Entwicklungsprozess in der Lage sind, die Fehlerursache oder Fehlerart vor dem Serienstart zu erkennen – durch Berechnungen, Simulationen, Prototypentests oder Validierungsprüfungen.

Praxis-Warnung: Detection in der DFMEA bezieht sich auf Entwicklungsaktivitäten vor der Serienfreigabe – nicht auf Fertigungsprüfungen. Wer einen niedrigen Detection-Wert mit dem Verweis auf 100%-Prüfung in der Fertigung begründet, bewertet falsch. Fertigungsprüfungen sind Gegenstand der PFMEA, nicht der DFMEA.

Typische Fehler bei der DFMEA-Erstellung

Fehlerursachen auf Symptomebene beschreiben: „Materialermüdung" ist keine Ursache – es ist ein Mechanismus. Die verwertbare Ursache lautet: „Sicherheitsfaktor bei zyklischer Wechsellast unter Berücksichtigung von Temperatureinflüssen zu gering dimensioniert." Nur auf dieser Ebene lassen sich sinnvolle Gegenmaßnahmen ableiten.

DFMEA und PFMEA vermischen: Fertigungstoleranzen, Prozessparameter oder Prüfanweisungen haben in einer DFMEA nichts zu suchen. Sie gehören in die PFMEA. Eine DFMEA, die beides enthält, ist in keinem der beiden Bereiche vollständig.

Keine Verbindung zur Systemstruktur: Die DFMEA nach AIAG-VDA 2019 erfordert eine explizite Strukturanalyse, die das Produkt hierarchisch in System, Subsystem und Komponenten zerlegt. Viele ältere DFMEA-Dokumente springen direkt zur Fehleranalyse ohne diese Strukturierung – das macht die Analyse unvollständig und die Fehlerketten schwer nachvollziehbar.

DFMEA wird nach Projektabschluss nicht mehr gepflegt: Wenn im Feldbetrieb Fehlerbilder auftreten, die in der DFMEA nicht erfasst sind, muss das Dokument aktualisiert werden. Eine DFMEA, die den Stand der Erstentwicklung dokumentiert, aber keine Felderfahrung integriert, verliert ihren Wert als Wissensbasis für Folgeprojekte.

Praxisbeispiel: DFMEA für ein elektronisches Steuergerät

Ein Tier-1-Lieferant entwickelt ein Motorsteuergerät für den Einsatz im Motorraum.

Fehlerart: Prozessorausfall bei Betriebstemperaturen über 105 °C

Fehlerfolge: Motorabschaltung während der Fahrt ohne Vorwarnung (Severity: 9)

Fehlerursache: Thermisches Design berücksichtigt keine ausreichende Wärmeableitung bei kombinierten Last- und Umgebungstemperaturspitzen

Aktuelle Erkennungsmaßnahmen: Keine thermische Simulation im Entwicklungsprozess vorgesehen, nur Raumtemperaturtests geplant (Detection: 7), Occurrence: 5

AP-Ergebnis: H – sofortiger Handlungsbedarf

Maßnahme: Thermische Simulation unter Worst-Case-Bedingungen (105 °C Umgebung + Vollast), Neubewertung der Komponentenspezifikation, Validierungstest im Klimaschrank

Nach Maßnahmenumsetzung: Occurrence reduziert auf 2, Detection auf 2, AP: L

Zusammenhang mit Design Verification Plan (DVP) und Kontrollplan

Die DFMEA steht nicht isoliert – sie ist Teil einer Dokumentenkette:

Die aus der DFMEA abgeleiteten Erkennungsmaßnahmen fließen direkt in den Design Verification Plan and Report (DVP&R) ein, der beschreibt, welche Tests und Berechnungen zur Verifikation der Designanforderungen durchgeführt werden. Kritische Merkmale, die in der DFMEA als sicherheits- oder funktionsrelevant eingestuft werden, müssen als Special Characteristics gekennzeichnet und in der PFMEA sowie im Kontrollplan weitergeführt werden. Diese Verbindung zwischen DFMEA, PFMEA und Kontrollplan ist ein explizites Prüfkriterium bei IATF-Audits.

FAQ: DFMEA in der Produktentwicklungspraxis

1. Ab wann im Entwicklungsprozess sollte eine DFMEA gestartet werden? So früh wie möglich – idealerweise sobald erste Designkonzepte vorliegen. Eine DFMEA, die erst kurz vor dem PPAP-Einreichungstermin erstellt wird, ist rückwärtsgerichtet und kann keine präventive Wirkung mehr entfalten. Der Wert der Methode liegt in der frühen Phase, wenn Designänderungen noch kostengünstig umsetzbar sind.

2. Muss die DFMEA vom Lieferanten oder vom OEM erstellt werden? In der Regel erstellt der Entwicklungslieferant die DFMEA für seine Komponenten und Subsysteme. Der OEM erstellt die Fahrzeugsystem-DFMEA. Bei der Integration müssen beide Ebenen konsistent sein – Fehlerfolgen auf Komponentenebene müssen mit den Fehlerursachen auf Systemebene verknüpft sein.

3. Was sind Special Characteristics und wie entstehen sie aus der DFMEA? Special Characteristics (SC) sind Merkmale, deren Streuung oder Abweichung einen überproportionalen Einfluss auf Sicherheit, Funktion oder Regulatorik hat. Sie entstehen in der DFMEA, wenn ein Merkmal mit hoher Severity bewertet wird. Diese Merkmale werden mit Symbolen (z. B. Dreieck für sicherheitsrelevant, Kreis für funktionskritisch) gekennzeichnet und müssen in Zeichnung, PFMEA und Kontrollplan konsistent übernommen werden.

4. Wie unterscheidet sich eine System-DFMEA von einer Komponenten-DFMEA? Die System-DFMEA analysiert Fehlerarten auf der Ebene des Gesamtsystems und seiner Subsystem-Schnittstellen – typischerweise beim OEM oder Systemlieferanten. Die Komponenten-DFMEA geht tiefer und analysiert einzelne Bauteile. Beide müssen miteinander verknüpft sein: Fehlerfolgen auf Komponentenebene werden zu Fehlerursachen auf Systemebene.

5. Kann die DFMEA für Folgeprojekte wiederverwendet werden? Ja – und das ist einer der wichtigsten strategischen Vorteile einer gut gepflegten DFMEA. Wenn eine DFMEA konsequent mit Felderfahrungen aus der laufenden Serie aktualisiert wird, wird sie zur Wissensbasis für Nachfolgeentwicklungen. Unternehmen, die das systematisch betreiben, reduzieren den Analyse-Aufwand bei ähnlichen Folgeprojekten erheblich und vermeiden die Wiederholung bekannter Designfehler.

Strategischer Mehrwert

Eine konsequent durchgeführte DFMEA verlagert Qualitätskosten von der teuersten Phase – Feldrückruf und Gewährleistung – in die günstigste Phase: die Entwicklung. Eine Designänderung vor dem Erstmuster kostet einen Bruchteil einer Änderung nach Serienanlauf. Der ROI einer DFMEA ist damit nicht primär ein Qualitäts-ROI, sondern ein Entwicklungskosten-ROI – und das ist das Argument, das Führungskräfte außerhalb der Qualitätsabteilung überzeugt.