Platz 1 - Innovative Prozesse: Diagnostic Design Concept

Details zum Projekt

"Ich kann aus vielerlei Gründen Kopfschmerzen haben, und die Ursache dafür muss nicht notwendigerweise im Kopf liegen.“ Mit diesem medizinischen Vergleich illustriert Valentin Adam die Schwierigkeit, in interagierenden, miteinander vernetzten Systemen von einem Symptom auf die Ursache zu schließen. Hier wie dort gilt: Ein und dasselbe Symptom kann diverse Ursachen haben, und nur die diagnostische Qualität entscheidet darüber, ob die Ursache hier wie da aufgespürt wird.

Wie verwoben Fahrzeugkomponenten heutzutage miteinander sein können, dafür kennt der Daimler-Forscher aus dem Bereich Diagnostik unzählige Beispiele – eines verblüffender als das andere. Beispiel elektrischer Fensterheber: Da gab es früher einen Motor und einen Schalter. Tat die Scheibe keinen Mucks mehr, brauchte man nicht lange zu suchen, um etwa im Wackelkontakt an der Steckverbindung zum Schalter den Fehler dingfest zu machen.

Und heute? „Der Schalter redet über ein internes lokales Netz mit dem Motor, der Motor schaut, ob der richtige Klemmenstatus vorhanden ist, ob also der Fensterhebermotor überhaupt arbeiten darf. Im Zweifelsfall muss die Werkstatt erst drauf kommen, dass eine fehlende Größe vom Motor den Fensterheber lahmlegt.“ Valentin Adams Fazit zu dieser Entwicklung: „Der Weg vom Symptom zur Fehlerursache wird immer verschlungener.“ Diesen Handlungsbedarf haben die Daimler-Forscher erkannt und das Projektteam Diagnostic Design Concept (D2C) im Jahr 2004 gestartet.

Der Forschungspreis, den das Team für das D2C-Projekt im letzten Dezember erhalten hat, ist auch ein Beleg dafür, wie erst durch eine solche Kooperation tragfähige Ideen entstehen, die sich konsequent in eine gesteigerte Produktqualität ummünzen lassen. In diesem Projekt sind dabei nicht nur die Belange von Forschung und Entwicklung tangiert. Vielmehr wirkt sich das Projekt bis in den After-Sales-Bereich aus, und zwar bis in die Werkstätten von Mercedes-Benz, wo eine treffsichere Fehlersuche direkt dem Kunden zugute kommt.

Valentin Adam erinnert sich an die Ausgangslage im Jahr 2004: „Als größtes Problem haben wir im Team damals ausgemacht, dass sich das funktionale Zusammenwirken elektronischer Komponenten in der Diagnose relativ schlecht auflösen lässt.“ Im Grunde genommen, so erläutert Adam weiter, setzt die Fehlersuche in der Werkstatt vor allem auf empirisches Wissen, nämlich eine umfangreiche Fallsammlung, in der sich bestimmte Symptome aus zurückliegenden Praxisfällen letztlich auf einen konkreten Bauteilausfall zurückverfolgen lassen. Dieses kumulierte Erfahrungswissen in Kombination mit dem „richtigen Riecher“ des Technikers sind in dieser Situation die wichtigsten Berater. Wie vollständig dabei das Erfahrungswissen alle Fehlerursachen erfasst, hängt vom Einzelfall ab. Von einer systematischen Fehlersuche ist dieses Vorgehen jedoch weit entfernt. Oder wie Adam es zusammenfasst: „Der Servicetechniker in der Werkstatt verfügt nie über das systematische Wissen eines Entwicklers, der alle 200 Eingangsgrößen seiner Komponente aus dem Effeff kennt und daher ein Symptom einem Komponentenausfall zuordnen kann.“

Für das D2C-Team war mit dieser Problemanalyse die Richtung für das Projekt vorgezeichnet: Fehler müssen systematisch aufgespürt werden. Und das geht nur, wenn die Voraussetzungen dafür bereits dort geschaffen werden, wo durch das Festlegen einer neuen Fahrzeugfunktion, also der Spezifikation der dafür erforderlichen Komponenten, zugleich auch das Symptom-Ursachen-Netzwerk definiert wird – nämlich bei der Fahrzeugentwicklung.

Der Gedanke, diagnostische Belange auf diese Weise bereits während der Fahrzeugentwicklung zu berücksichtigen, war damals noch neu. Bislang war es in der Regel so, dass die Ingenieure aus dem After-Sales-Bereich, die die Diagnosewerkzeuge und -materialien für die Werkstätten zusammenstellten, relativ kurz vor Serienstart mit der Arbeit begannen. Eher kursorisch als systematisch suchten die „Diagnostiker“ Kontakt zu ihren Kollegen aus der Entwicklung – etwa, wenn eine Unklarheit auftauchte.

Die Ingenieure aus dem D2C-Projekt erkannten in diesem Nacheinander der Vorgehensweise zwei entscheidende Mängel: Stieß beispielsweise jemand aus der Diagnosedokumentation darauf, dass ein und dieselbe Fehlermeldung oder ein Fehlercode durch Defekte in zwei separaten Bauteilen generiert wird, war es längst zu spät, diesen Mangel an diagnostischer Präzision etwa durch simples Abändern der Steuerungssoftware zu beheben. Die Software hatte inzwischen alle Qualitätshürden übersprungen und kein Verantwortlicher hätte ohne Not den erreichten Reifegrad der Software aufs Spiel gesetzt, um erneut den Quellcode zu ändern. Auf den zweiten Punkt weist Valentin Adam hin: „In den Gesprächen mit den Entwicklungskollegen erkannten wir ziemlich schnell, dass die Kollegen dort mit der FMEA-Methodik eigentlich schon alles in der Hand haben, was wir für eine systematische und funktionsorientierte Diagnostik benötigen.“

Hinter dem Kürzel FMEA – es steht für die englische Methodenbezeichnung „Failure-Mode-Effect-Analysis“ – verbirgt sich eine gigantische Dokumentation. Darin wird nach festen formalen Regeln systematisch geprüft, wie sich ein bestimmter Bauteilausfall auf eine Komponente und auf das Gesamtsystem auswirkt, in das sie eingebettet ist. Die Untersuchung bewegt sich gewissermaßen von der Ausfallursache zu den sich daraus ergebenden Symptomen oder Auswirkungen. In der FMEA erkennt der Komponentenentwickler also sofort, ob eine „kleine Ursache große Wirkung“ haben kann oder ob sich der Defekt nur marginal bemerkbar macht oder bestenfalls keinerlei Funktionsverlust nach sich zieht.

Mit diesem Werkzeug prüfen die Entwicklungsingenieure letztlich, wie gut und wie robust die Komponenten und das Gesamtsystem ausgelegt, also spezifiziert sind. Prüft nun zusätzlich ein Diagnostiker die FMEA, indem er gewissermaßen die Pfade exakt in der entgegengesetzten Richtung vom Symptom zur Ausfallursache verfolgt, findet er dabei auch ganz genau heraus, welche Daten und Informationen er letztlich in der Werkstatt benötigt, um dieses Symptom eindeutig einem fehlerhaften Bauteil zuordnen zu können. „Wir haben die Prüfungsspezifikation als zusätzliche Analyseebene in die FMEA einbezogen“, erläutert Valentin Adam und ergänzt: „Erstmals kennen wir die Diagnoseabdeckung, also die Entdeckungsgüte unseres Servicetesters, exakt, weil wir die Diagnosespezifikation automatisiert überprüfen können.“ Das ist vor allem bei sicherheitsrelevanten Systemen ein großer Vorteil.

Eine hundertprozentige Diagnoseabdeckung ist allerdings nicht in jedem Fehlerfall sinnvoll: Bei billigen Tauschteilen sprechen Wirtschaftlichkeitsüberlegungen dagegen, den Diagnoseaufwand auf die Spitze zu treiben. Hier ist es im Zweifelsfall besser, zwei infrage kommende Billigteile zu tauschen. Oder unterschiedliche Ausfallwahrscheinlichkeiten bei möglichen Fehleralternativen sprechen dafür, den pragmatischen Weg zu gehen. Wenn man weiß, dass bei ein und demselben Symptom in 100 Fällen 99 Mal die Pumpe defekt ist und höchstens einmal das Steuergerät, kann es eben sinnvoll sein, zuerst die Pumpe zu tauschen, anstatt das Fahrzeug 30 weitere Minuten durchzuchecken.

Verblüffend ist, wie das enorme diagnostische Wissen, das das D2C-Team in den verschiedenen Pilotprojekten – sie beinhalten Komponenten beziehungsweise Funktionen im Antriebsstrang sowie im Interieur und Exterieur des Fahrzeugs – generiert hat, angenehm im Hintergrund bleibt. Im Grunde genommen reduziert es sich in der Werkstatt auf einfache Farbsymbole. Ralph Ricker aus dem D2C-Team demonstriert es am Beispiel eines Defekts am elektrisch betätigten Heckdeckel.

Die Ingenieure haben exemplarisch für das Symptom „Heckdeckel öffnet unvollständig“ die Diagnosesoftware im Werkstatttester so weiterentwickelt, dass das Prinzip der Vorgehensweise deutlich wird: Nach dem Anschließen des Diagnosesteckers ans Fahrzeug und der Auswahl eines Symptoms erscheinen auf dem Monitor alle beteiligten Komponenten, deren Ausfall dieses Symptom hervorrufen können. Im Hintergrund prüft der Diagnoserechner das Fahrzeug ab, das heißt, er liest alle für diesen Fall relevanten Fehlercodes oder sogenannten Bitfelder aus, die den Weg zur defekten Komponente weisen und die Ursache Zug um Zug eingrenzen.

Am Ende reduziert sich das Ergebnis auf drei Signalfarben: Grün leuchten alle beteiligten Komponenten auf, die in Ordnung sind und fehlerfrei arbeiten. Gelb erscheinen Komponenten, die technisch tadellos funktionieren, aber aufgrund einer Fahrzeugsituation – etwa eine geöffnete Tür – die Funktion blockieren. Mit einem kräftigen Rot schließlich verrät sich die fehlerhafte Komponente, deren Tausch die Fehlfunktion beseitigt.

„Unser Ziel“, so fasst es Ralph Ricker zusammen, „war es, das technische Wissen, das hinter der funktionsorientierten Diagnose steckt, so zu visualisieren, dass es auf lediglich einen Blick in der Werkstatt ankommt.“ Und dies wird schon bald geschehen: Mit der neuen Softwaregeneration „XENTRY“ für die Werkstatttester von Mercedes-Benz wird die Rasterfahndung nach dem Fehlerteufel für erste Anwendungen erstmals in die Praxis eingeführt.