Claudio Seitz, Solution Field Head Portfolio bei ETAS
„Eine Diagnose, die primär auf Komponenten schaut, reicht nicht mehr aus“
Mit dem SDV stößt die klassische Fahrzeugdiagnose zunehmend an ihre Grenzen. Im Interview erklärt Claudio Seitz, Solution Field Head Portfolio bei ETAS, wie breitere Fahrzeugdaten, KI-gestützte Ursachenanalysen und ein „Human in the Loop“ helfen sollen, Softwarefehler schneller zu finden und unnötigen Teiletausch zu vermeiden.
Claudio Seitz, Solution Field Head Portfolio bei ETAS, sieht die Fahrzeugdiagnose vor einem grundlegenden Wandel: Statt einzelne Komponenten zu prüfen, muss sie zunehmend das Zusammenspiel von Software, Fahrzeugdaten und E/E-Architektur erfassen. KI hilft dabei, mögliche Fehlerursachen einzugrenzen, die endgültige Absicherung bleibt beim Werkstatttechniker.
ETAS
Herr Seitz, ETAS hat auf der IAA Transportation 2026 die nächste Generation der Fahrzeugdiagnose in den Mittelpunkt gestellt. Was ändert sich gegenüber der klassischen Diagnose grundlegend?
Wir kommen aus einer Welt, in der der Aftersales sehr hardware-, bauteil- und komponentenorientiert war. Das prägt auch die klassische Diagnose: Man betrachtet den Zustand einer Komponente, wartet auf ein bestimmtes Ereignis – beispielsweise einen überschrittenen Schwellenwert oder einen Kurzschluss – und leitet daraus den Zustand des Bauteils ab. Das ist stark zustands- und steuergeräteorientiert. Mit dem Software-defined Vehicle verändert sich das. Wir haben stark verteilte Softwaresysteme, sehr viel mehr Code und eine zunehmende Entkopplung von Hardware und Software. Deshalb reicht eine Diagnose, die primär auf Komponenten und deren Zustand schaut, nicht mehr aus. Wir müssen zunehmend auch das dynamische Verhalten der Software betrachten. Software „verschleißt“ schließlich nicht. Ich würde deshalb weniger von einem Bruch sprechen als von einer konsequenten Weiterentwicklung der Fahrzeugdiagnose.
Dann stößt auch die klassische DTC-basierte Diagnose an Grenzen. Können Sie das an einem konkreten Fehlerbild zeigen?
Ein einfaches Beispiel ist ein Blackscreen im Infotainment. Dafür muss es nicht einmal einen eindeutigen DTC geben. Oder nehmen wir einen Radarsensor, bei dem ein „Lost Communication“-Problem angezeigt wird. Klassischerweise prüft der Werkstatttechniker dann die Kommunikationswege, etwa über CAN oder Ethernet, kontrolliert die Verbindung und tauscht im Zweifel die Komponente aus. Die eigentliche Ursache kann aber ganz woanders liegen: Vielleicht erzeugt ein Softwarecontainer gerade eine hohe Last am I/O oder am Prozessor, sodass ein Signal für ein oder zwei Millisekunden nicht durchkommt. Dann entsteht ein Kommunikationsfehler, obwohl die Hardware völlig in Ordnung ist. Genau das ist die Herausforderung: Die klassische Diagnose kann in so einem Fall zu einem Teiletausch führen, obwohl tatsächlich ein Softwareproblem vorliegt.
Wenn sich die Ursache nicht mehr sauber einem einzelnen Bauteil zuordnen lässt – wie muss sich dann die Diagnosemethodik verändern?
Wir müssen mit einer deutlich breiteren Datenbasis arbeiten. Neben den klassischen Fahrzeugdaten betrachten wir beispielsweise die E/E-Architektur, vorhandene Softwarestände und Informationen, die im Fehlerfall aus einem Ringpuffer verfügbar sind – also Kommunikationsdaten, Logs und Traces. Diese Informationen können wir wiederum mit einem DTC oder einem beschriebenen Symptom verbinden. Damit schauen wir nicht mehr nur auf ein einzelnes Bauteil, sondern stärker auf das Gesamtsystem. Ein Softwareproblem kann schließlich eine ganze Kette von Folgefehlern erzeugen. Dann haben Sie vielleicht 15 DTCs, obwohl dahinter nur eine Ursache steckt. Genau diese Informationsflut müssen wir für den Werkstatttechniker auflösen. Generative KI kann dabei helfen, daraus Fehlerhypothesen abzuleiten. Für den Techniker muss das Ergebnis anschließend aber wieder in einen linearen, deterministischen Prüfplan übersetzt werden, mit dem sich die tatsächliche Ursache absichern lässt. Die Datenbasis wird also breiter – der Diagnoseprozess für die Werkstatt soll trotzdem klar und strukturiert bleiben.
Damit sind wir schon beim Thema KI. An welchen Stellen setzen Sie sie bei ETAS konkret ein?
Wir sehen im Wesentlichen drei Einsatzbereiche. Der erste liegt onboard bei der Anomalieerkennung. Mit unserem Grade-X Diagnostic-Core betrachten wir beispielsweise das typische Netzwerkverhalten und Abhängigkeiten zwischen Softwarekomponenten. Dabei hilft uns auch unsere Cybersecurity-Expertise, denn methodisch liegt Intrusion Detection gar nicht so weit von der Erkennung anderer Anomalien entfernt. Der zweite Bereich ist die Ursachenanalyse mit unserer Grade-X Vehicle Health Intelligence. Dafür kombinieren wir Serviceinformationen wie Reparaturanleitungen, Benutzerhandbücher, Ersatzteilkataloge und Reparaturhistorien mit Informationen über E/E-Topologie und Softwarestände. Daraus können wir Hypothesen ableiten: Welche Fehlerursache ist mit welcher Wahrscheinlichkeit relevant? Durch die anschließenden Prüfschritte lässt sich diese Hypothese weiter absichern. Der dritte Bereich ist die Aufbereitung für den Techniker. Heute können Reparaturinformationen Tausende Seiten umfassen, dazu kommen sehr komplexe Schaltpläne. KI und unser Grade-X ActiveSchematics kann helfen, diese Informationen so aufzubereiten, dass der Techniker fahrzeug-, VIN- und fehlerspezifisch genau die Inhalte sieht, die für seinen konkreten Fall relevant sind.
Sobald KI mögliche Fehlerursachen priorisiert, stellt sich aber die Frage nach der Absicherung. Wie verhindern Sie, dass eine plausible, aber falsche Empfehlung zu einer falschen Reparatur führt?
Für uns ist ein „Human in the Loop“ entscheidend. Der Werkstatttechniker validiert die Hypothese der KI Schritt für Schritt über konkrete Prüfungen. Die KI liefert also nicht einfach eine Reparaturempfehlung, die ungeprüft umgesetzt wird. Gleichzeitig entsteht daraus wieder wertvolles Feedback für das System: Welches Teil wurde tatsächlich ausgebaut? War die vermutete Fehlerursache richtig? Hat die Reparatur funktioniert? Solche Informationen können genutzt werden, um die KI weiterzuentwickeln und ihr beispielsweise über einen Knowledge Graph zusätzliche Zusammenhänge und Randbedingungen bereitzustellen. So kann das System sowohl aus erfolgreichen als auch aus nicht erfolgreichen Reparaturen lernen.
Wenn dafür Daten aus so vielen Quellen zusammenkommen: Wo sitzt künftig eigentlich die Diagnoseintelligenz – im Fahrzeug, am Edge oder im Backend?
Es wird ein verteiltes System bleiben. Bestimmte Funktionen, beispielsweise die Anomalieerkennung, müssen direkt im Fahrzeug stattfinden. Die zentrale Diagnoseintelligenz sehen wir aber auch im Backend. Dort können Informationen aus unterschiedlichen Fahrzeugen und Reparaturverläufen zusammengeführt werden, und dort steht auch eine andere Rechenleistung für die Datensynthese zur Verfügung. Darauf können dann unterschiedliche Anwendungsfälle zugreifen: die Produktion, eine Remote-Diagnose während des Fahrzeugbetriebs oder die Werkstatt, wenn ein Techniker eine Diagnose anstößt. Die konkrete Ausführung kann also unterschiedlich sein – im Hintergrund greifen diese Anwendungen zunehmend auf dieselbe Wissens- und Datenbasis zurück.
Wenn ein größerer Teil dieser Komplexität im Hintergrund verarbeitet wird, was bedeutet das für den Werkstatttechniker? Verändert sich seine Rolle?
Seine Expertise bleibt für uns unverzichtbar. Die Kernkompetenz des Werkstatttechnikers liegt im physischen Prüfen, in der mechatronischen Reparatur und schließlich in der Verifikation: Ist das Fahrzeug tatsächlich repariert und funktioniert das Gesamtsystem wieder korrekt? Unser Ziel ist deshalb nicht, diese Expertise zu ersetzen, sondern die softwareseitige Komplexität so weit wie möglich zu abstrahieren. Am Ende wollen wir wieder zu einem linearen, deterministischen Prüfplan kommen. Damit kann der Techniker verifizieren, dass die von der KI vorgeschlagene Hypothese stimmt, und zugleich vermeiden, dass ein Teil ausgetauscht wird, obwohl es gar nicht defekt ist. Er soll sich nicht durch 15 DTCs arbeiten und dabei zum forensischen Detektiv werden müssen, sondern sich auf Diagnose, Reparatur und Validierung konzentrieren können.
Ein wichtiger Gradmesser dafür ist bei ETAS die First-Time-Fix-Rate. Warum rückt diese Kennzahl gerade jetzt so stark in den Mittelpunkt?
Die First-Time-Fix-Rate war schon immer wichtig. Durch die zunehmende Softwarekomplexität wird das Problem heute aber deutlich sichtbarer. Ein Kunde kommt beispielsweise mit einer Beanstandung oder einem Fehlercode in die Werkstatt. Dort wird das Infotainmentsystem oder ein Steuergerät ausgetauscht. Wenn die eigentliche Ursache aber in der Software liegt, kann derselbe Fehler später wieder auftreten. Dann haben Sie unnötige Teilekosten, einen weiteren Werkstattbesuch und einen unzufriedenen Kunden. Gleichzeitig nehmen „No Trouble Found“-Fälle zu – also Fälle, in denen ein Teil ausgetauscht wird, obwohl es gar nicht defekt war. Im Nutzfahrzeugbereich kommt noch hinzu, dass jeder ungeplante Werkstattaufenthalt direkt auf Uptime und Total Cost of Ownership einzahlt. Deshalb müssen wir die tatsächliche Ursache schneller finden und den Fehler möglichst beim ersten Werkstattbesuch beheben.
Mit „Full Circle Diagnostics“ denken Sie noch über die einzelne Werkstatt hinaus. Was steckt hinter diesem Ansatz?
Wir wollen Informationen über Entwicklung, Produktion und Aftersales hinweg nutzbar machen. Das ist nicht nur eine technische, sondern auch eine organisatorische und kulturelle Herausforderung, weil diese Bereiche heute häufig sehr eigenständig arbeiten. Dabei entstehen große Vorteile, wenn wir die Informationen miteinander verbinden. Im Aftersales hilft es beispielsweise, auf Engineeringdaten und Softwarestände zugreifen zu können. Umgekehrt können Diagnoselogiken bereits in Software-Build-Prozessen und virtuellen Tests eingesetzt werden, um mögliche Fehler früher zu erkennen. Auch in der Produktion entstehen wichtige Erkenntnisse, etwa über Manufacturing Diagnostics und End-of-Line-Tests. Gleichzeitig müssen Informationen aus dem Feld zurück ins Engineering fließen, damit Software-Fixes schneller erfolgen können. Und wenn sich die Funktionslogik eines Fahrzeugs verändert, müssen sich auch Serviceinformationen und Reparaturanleitungen anpassen. „Full Circle Diagnostics“ bedeutet für uns deshalb, diese Informationen über den gesamten Lebenszyklus des Fahrzeugs hinweg in beide Richtungen nutzbar zu machen.
Zum Abschluss der Blick auf Pkw und Nutzfahrzeuge: Wo kann der eine Bereich vom anderen lernen?
Bei der Telemetrie war die Nutzfahrzeugindustrie aus meiner Sicht schon sehr früh weiter als der Pkw-Bereich. Standardisierte Flottenmanagement-Schnittstellen gibt es dort seit vielen Jahren, und Flottenbetreiber nutzen Fahrzeugdaten längst, um ihre Operations zu optimieren. Da war die Nutzfahrzeugindustrie klar ein Vorreiter. Auf der anderen Seite ist der Pkw-Bereich beim Software-defined Vehicle, bei zentralisierten E/E-Architekturen und bei der zunehmenden Softwarefunktionalität heute weiter. Davon kann der Nutzfahrzeugbereich profitieren – gerade weil dort Uptime eine besonders große Rolle spielt. Interessanterweise haben wir zugleich etwa im Bereich Cybersecurity gesehen, dass sich die Truckindustrie schon früh sehr konsequent mit bestimmten Anforderungen beschäftigt hat. Der Technologietransfer läuft also nicht nur in eine Richtung. Beide Bereiche können an unterschiedlichen Stellen voneinander lernen.
