Systembasierte Design FMEA – Ein systemtechnischer Ansatz für DFMEA

In einem mechatronischen Produkt basiert das Design auf der Kombination mechanischer, elektrischer, chemischer und regelungstechnischer Disziplinen. Diese Vermischung erzeugt eine hohe Komplexität und führt zu verborgenen Wegen, auf denen sich Fehler ausbreiten können. Die zunehmende Komplexität im Design steigert das Ausfallrisiko und macht es erforderlich, DFMEA als festen Bestandteil der Entwicklungsmethodik einzusetzen.

System Engineering (SE), auch bekannt als V-Modell, ist die vertrauenswürdigste Methode, um die Designkomplexität zu steuern und Entwürfe von Komponenten, oft aus verschiedenen Ingenieurdisziplinen, mit der Entwicklung von Produkten zu integrieren, die den Kundenanforderungen entsprechen. Der Anforderungskatalog, der mit DFMEA verbunden ist, sind Anforderungen an die Produktzuverlässigkeit, die als Treiber robusten Designs dienen.

Zuverlässigkeit ist nicht mehr das Prestige einer einzelnen Marke, sondern eine unverzichtbare Eigenschaft, um in allen Bereichen zu bestehen. Von älteren Produkten wie Automobil-, Luft- und Raumfahrt- und Haushaltsmaschinen bis hin zu neuen Produkten wie Wind- und Solarenergie ist die Definition eines robusten Produkts für Kunden heute das "Produkt ohne ungeplante Wartung". Diese Änderung erfordert eine Änderung der DFMEA-Methodik.

Warum? Weil die bestehende DFMEA-Methodik nicht an die Veränderung der Produktkomplexität und Kundenerwartungen angepasst wurde. Oft wird es als komplexer und zeitaufwändiger Prozess wahrgenommen, der vom gängigen Denken der Ingenieure losgelöst ist und die Produktveröffentlichung auf den Markt verlangsamt. Daher sehen Ingenieurexperten und Projektleiter DFMEA eher als Pflichtaufgabe statt als notwendiges Entwicklungswerkzeug. Es braucht eine Veränderung. Die Kernursache dafür liegt in der fehlenden Harmonie zwischen der gängigen DFMEA-Methodik und der robusten Designmethodik, obwohl das gemeinsame Ziel beider Methoden darin besteht, die Ausfallwahrscheinlichkeit von Produktfunktionen zu verringern.

Seit 20 Jahren sehe ich, dass DFMEA teilweise und im Eiltempo durchgeführt werden, z. B. an kritischen Komponenten und vor der Gate-Überprüfung, und dass Maßnahmen geparkt werden, um das Produkt rechtzeitig zu veröffentlichen. Diese Situation lässt sich durch die Modernisierung der DFMEA-Methodik verbessern, sodass sie den Anforderungen des Marktes tatsächlich gerecht wird.

Systemtechnik & Risikobewertung

Der DFMEA-Prozess ist üblicherweise Teil der Qualitätskontrolle, die parallel zu SE erfolgt, wobei beide Produkte auf die Produktqualität abzielen. Wir müssen diese Lücke schließen. Die DFMEA-Methodik konzentriert sich ebenfalls auf die Produktfunktionalität mit dem Ziel, die Robustheit eben dieser Funktionen zu verbessern. Dazu werden zunächst alle möglichen Risiken von Fehlern identifiziert und anschließend eine Reihe von Vermeidungs- und Entdeckungsmaßnahmen definiert, um die höchsten Risiken zu mindern.

Die SE-(V-Modell)-Methodik konzentriert sich darauf, die Produktfunktionalität entsprechend den gewünschten Kundenanforderungen zu definieren. Dazu teilt sie Produktfunktionen in eine Menge von System-, Teilsystem- und Komponentenfunktionen auf. In diesem Prozess beginnt das Design bei Produktfunktionen und materialisiert sich mit Komponentenspezifikationen. Das Design wird von den Komponenten bis zum Produkt getestet.

Das fehlende Bindeglied zwischen SE und DFMEA liegt darin, dass:

1. beide Methoden nicht Funktions- und Fehlerdefinitionen verwenden. Tatsächlich beginnt die DFMEA-Diskussion oft mit möglichem Ausfall von Bauteilen, bevor die Funktion der Komponenten und deren Wechselwirkung mit anderen Komponenten im selben System/Produkt verstanden wird.
2. beiden Methoden nicht derselben Hierarchie von Funktionen und Fehlern von Komponenten zu Produkt folgen. Oft, wenn DFMEA auf einem physischen Produkt mit 3D-Darstellung der Baugruppe durchgeführt wird, wird für DFMEA die engi-neering7manufacturing Bills of Material (e/m-BoM)-Struktur verwendet.

Abbildung  2 verdeutlicht diese Problematik und zeigt, wie die Lücke zwischen beiden Methoden geschlossen werden kann.

Um das Motiv zu rechtfertigen, wurde eine mathematische Simulation durchgeführt, die die probabilistische Ausbreitung von Fehlern sowohl in der klassischen DFMEA als auch in der systembasierten DFMEA vergleicht. Die Simulation verspricht eine erhebliche Reduzierung der Anzahl möglicher Fehlerausbreitungspfade in der systembasierten DFMEA (siehe Abbildung 3).

In der systembasierten DFMEA wird nur die logische Schnittstelle zwischen Funktionen betrachtet, und das technische Wissen wird genutzt, um die sinnvollen möglichen Schnittstellen zwischen Funktionen zu erhalten.

Mit anderen Worten: Wenn Ausfall als jede mögliche Abweichung von der beabsichtigten Funktion definiert ist, sollte die Fehlerausbreitung (Failure-Net) zum Zeitpunkt der Entwurfsfertigstellung über die bekannte funktionale Schnittstelle (Function-Net) erfolgen. Durch die Festlegung dieser Regel, dass "Failure-Net logisch dem Funktionsnetz folgen sollte", wird die erste Verbindung zwischen DFMEA und SE hergestellt und die Systemingenieurarbeit kann für DFMEA verwendet werden.

So fügt die systembasierte DFMEA der klassischen DFMEA keine zusätzlichen Aufgaben hinzu, sondern kombiniert Systemtechnik und DFMEA und bringt sie in denselben Kontext. Der Kontext besteht darin, die hierarchische Struktur der Produktfunktionalität auch für die DFMEA zu verwenden. Dieser Schritt macht die DFMEA nicht nur effektiver, sondern bringt sie auch näher an die logische Denkweise der Ingenieurwissenschaften für die Teilnehmer.

Der Vorschlag lautet daher, die DFMEA-Struktur, Funktionen und das Funktionsnetz bereits vor der Fehleranalyse gezielt zu erweitern. Nach diesem Schritt können wir:

• die bestehende Produkthierarchie aus SE-Arbeit nutzen, um die DFMEA-Struktur zu gestalten. Wenn die SE-Arbeit nicht richtig ausgeführt wird, können wir dennoch dem bekannten SE-Weg folgen, Kernfunktionen des Produktdesigns definieren und Komponenten basierend auf ihren wichtigsten funktionalen Beiträgen gruppieren und die Systeme in der DFMEA-Struktur formen.
• die System-zu-System-Funktionsschnittstellen nur als mögliche Fehlerausbreitungspfade definieren. Wir können neue Wege hinzufügen, wenn es eine logische Schnittstelle dahinter gibt, um zu verhindern, dass die DFMEA durch rein hypothetische Szenarien überladen wird.
• die DFMEA anhand einer funktionalen Blaupause des Produkts durchführen, bei der funktionale Hierarchie und die logischen Schnittstellen bereits berücksichtigt sind. Gleichzeitig bleibt eine ständige Verbesserung von Struktur, Funktion und Funktionsnetz mit zunehmender Reife möglich.

Als Nächstes gehen wir von der Theorie zur Praxis über und zeigen, wie System-DFMEA auf einer einfachen Mechatronikmaschine implementiert werden kann.

Beispiel

BPGs unterscheiden sich in Größe, Leistung, Kosten und Zuverlässigkeit, teilen aber die gleichen Kernfunktionen, jene die wir für diese Übung brauchen. Wir beginnen zunächst mit der klassischen DFMEA.

Im klassischen Ansatz wird das Schnittstellendiagramm, das Komponenten verbindet, verwendet, um die DFMEA zu starten (siehe Abbildung 5). Komponenten repräsentieren Funktionen und Ausfälle sind mit ihnen als "Fehlerursache" verbunden.
Vorteil der klassischen Methodik ist, dass Moderatoren nicht von Anfang an die volle Produktkomplexität bewältigen müssen. Sie können mit Hilfe von Ingenieuren derselben Disziplin beginnen, Bauteilfehler zu erfassen, und die dokumentierte DFMEA zeigt einen schnellen Fortschritt.

Allerdings wird vorhandene oder vererbte Produktkomplexität dadurch oft verschoben oder umgangen, um das DFMEA‑Dokument nicht unnötig zu überladen. Die DFMEA wird durchgeführt und die Produktqualität sowie Robustheit werden nur geringfügig verbessert.

Schauen wir uns nun an, wie die vorgeschlagene systembasierte DFMEA den Ansatz und das Ergebnis verändern kann. Gibt es zusätzliche Arbeit und ist das gerechtfertigt? Oder wie sieht das Verhältnis von Nutzen zu Einsatz aus? Erinnern wir uns daran, dass die Methodik für multidisziplinäre mechatronische Produkte entwickelt wurde und grundlegende Kentnisse im System Engineering vorausgesetzt werden.

Hier sind die Voraussetzungen:

• Es existiert ein Produktanforderungsdokument
• Anforderungsmanagement wird durchgeführt
• Produkt, System- und Komponentenfunktionen sind definiert und strukturiert (oder zumindest ist das Wissen zur Gestaltung im Kontext von DFMEA verfügbar)
• Komponentenspezifikationen werden dokumentiert (aus denen Einschränkungen für Komponentenfunktionen abgeleitet werden können)
• Es existieren Verifikations- und Validierungsdokumente
• Die DFMEA-Moderation erfolgt in interdisziplinären Ingenieurteams.

Das Rückgrat der systembasierten DFMEA ist die Produktsystematik, die entweder existiert oder durch das Gruppieren von Komponenten und die Definition von Schnittstellen geformt werden kann. Das Ergebnis dieser SE-Übung für eine BPG ist in Abbildung 6 dargestellt.

HINWEIS:
Hier sehen wir grüne und blaue Funktionen. Grüne Funktionen (über den Komponenten) sind vererbte Funktionen der Gruppe von Komponenten (zuerst erkennbar) in jedem System, und blaue Funktionen (unter den Komponenten) sind Schnittstellenfunktionen, die von anderen Systemen angefordert werden.
Aus DFMEA-Sicht gibt es keinen Unterschied zwischen grünen und blauen Funktionen, und beide Mengen sind fehlerhaft. In der DFMEA-Struktur geben wir sie auf Systemebene ein und behandeln sie ähnlich. Aber sie unterscheiden sich bei der SE-Schnittstellenverwaltung, daher ist es hilfreich, ihnen unterschiedliche IDs zu geben, um zu wissen, wo der Ursprung jedes Funktionssets ist.
Ein weiterer Vorteil der Trennung von blauen und grünen Funktionen in der DFMEA besteht darin, Systemteams dazu zu leiten, mögliche Fehlerquellen zu betrachten, die jedes System bei anderen Systemen verursachen kann.
Zum Beispiel könnte System A robust gegenüber einem Komponentenausfall innerhalb von System A sein, aber wenn System A sich der Auswirkungen auf andere Systeme bewusst wird, sichert die Designänderung von System A die Robustheit benachbarter Systeme. Diese Übung allein öffnet die Tür, Schnittstellenausfälle systematisch in DFMEA einzubeziehen.

Zurück zum BPG-Beispiel: Wir können nun die Systematik des Schnittstellendiagramms implementieren und ein zweidimensionales Schnittstellendiagramm erstellen, in dem wir eine System-zu-System-Schnittstelle hinzugefügt haben. Nun wird die DFMEA in der Sprache des Systems Engineering durchgeführt und die vererbte Komplexität kann kontrolliert ohne Chaos hinzugefügt werden, siehe Abbildung 7.

Praktisch haben wir durch das Management von Schnittstellen sinnvolle Ausbreitungspfade für Fehler identifiziert und eine hierarchische Struktur zur Komplexitätsverwaltung geschaffen, bevor wir mit der DFMEA beginnen, siehe Abbildung 8. Das neue Schnittstellendiagramm und die Systematik-Excel-Datei werden nun verwendet, um Komponentenausfälle in der funktionalen Struktur zu erfassen und zu platzieren.

Horizontale und vertikale Ausbreitungspfade:
Zur vollständigen Umsetzung wird das IQ-FMEA-Tool von APIS eingesetzt, um die funktionale Struktur des BPG abzubilden, siehe Abbildung 9.

In diesem Tool verläuft die Fehlerkette von Ursache -> Art -> Folge von rechts nach links. Funktions- und Fehlerursachen von Komponenten werden Systemfunktionen zugeordnet. Systemfunktionen wiederrum sind mit den Funktionen und Fehlern des BPG verknüpft.

Diese 3 Ebenen entsprechen dem horizontalen Fehlerausbreitungspfad. Wie bereits besprochen, gibt es auch einen vertikalen Fehlerausbreitungspfad über die System-zu-System-Schnittstellen.

HINWEIS:
Im horizontalen Ausbreitungsweg entspricht die Systemebene in der Regel der Fehlerfolgeebene in der DFMEA, aber im vertikalen Ausbreitungsweg kann die Funktionsfolge von System A die Funktionsursache für benachbarte Systeme B sein. Das bedeutet, dass die Fehlerursache von System B mit dem System-B-Team auf Systemebene diskutiert werden kann und Vermeidungs- oder Entdeckungsmaßnahmen auf Systemebene hinzugefügt werden können, ohne dass Komponenten von System A in das Fehlernetz einbezogen werden.

Die systembasierte DFMEA ermöglicht:

• Das Systems Engineering liefert die funktionale Zerlegung vom Produkt über die Systeme bis hin zu den Komponenten (linke Seite des V‑Modells). Die DFMEA nutzt diese Struktur als horizontalen Ausbreitungspfad von links nach rechts.
• Eine Reduzierung der DFMEA-Komplexität, indem sowohl horizontale als auch vertikale Fehlerausbreitungspfade berücksichtigt und multidisziplinäre Systemteams gebildet werden. Moderatoren können DFMEA-Sitzungen entlang des technischen Entwicklungsprozesses durchführen, also nach SE, und erhalten gleichzeitig ein klares Verständnis darüber, welches ingenieurfachliche Know-How in jeder Sitzung erforderlich ist.
• Eine einheitliche Basis für die ersten beiden Schritte der AIAG/VDA-Methodik, also Struktur- und Funktionsanalyse, durch die direkte Verknüpfung dieser Schritte mit dem Entwicklungsprozess im SE. Dadurch können DFMEA und SE auf derselben methodischen Grundlage aufbauen.

Autor: Dr. Saéd Ehsani