Zwei identische Fahrzeuge müssen diagnostisch nicht mehr identisch sein
Werkstätten identifizieren Fahrzeuge traditionell über Hersteller, Modell, Baujahr, Motorisierung und Ausstattung. Stehen zwei ähnlich ausgestattete Fahrzeuge desselben Modells nebeneinander, erwartet man daher zunächst, dass sich ihre Steuergeräte bei der Diagnose gleich verhalten. Bei modernen Fahrzeugen ist diese Annahme nicht mehr immer zuverlässig.
Hersteller aktualisieren Fahrzeugsoftware inzwischen während des gesamten Lebenszyklus. Eine Aktualisierung kann beim Besuch eines Vertragspartners, im Rahmen einer Servicemaßnahme oder zunehmend Over-the-Air erfolgen. Volkswagen beschreibt beispielsweise für die MEB-Plattform eine OTA-Architektur, über die Software in mehreren Dutzend Steuergeräten erreicht werden kann. BMW beschreibt Remote Software Upgrades über verschiedene Funktionsbereiche hinweg, darunter Infotainment, Fahrerassistenz sowie Body- und Komfortfunktionen.
Das physische Steuergerät muss sich dabei überhaupt nicht ändern. Die Teilenummer kann gleich aussehen. Der Stecker bleibt identisch. Das Steuergerät kommuniziert weiterhin über dasselbe Netzwerk. Für den Mechaniker wirkt das Fahrzeug unverändert. Intern läuft jedoch eine andere Softwareversion.
Und die Software bestimmt einen erheblichen Teil des Diagnoseverhaltens des Steuergeräts.
Was ist eine ECU-Variante?
Professionelle Diagnose arbeitet nicht nur mit einer einfachen Datenbank nach dem Muster „Bosch-Motorsteuergerät vorhanden“. Das Diagnosesystem muss die konkrete diagnostische Implementierung im Steuergerät kennen.
ODX, Open Diagnostic Data Exchange nach ISO 22901-1, ist ein Industriestandard für die Beschreibung von Diagnosedaten. Er kann Diagnosedienste einschließlich Requests und Responses, Diagnostic Trouble Codes, Messwerte, Flash-Programmierung, Variant Coding und weitere Diagnosefunktionen beschreiben.
Entscheidend ist, dass ODX ausdrücklich verschiedene ECU-Varianten unterstützt.
ASAM beschreibt einen Mechanismus, bei dem ein Diagnosetester Identifikationsdaten aus dem Steuergerät über normale Diagnoseanforderungen ausliest und die zurückgegebenen Informationen anschließend mit den Identifikationsmustern der bekannten ECU-Varianten vergleicht. Erst nach einer Übereinstimmung weiß das Diagnosesystem, welche Diagnosebeschreibung verwendet werden soll.
Hinter einer scheinbar einfachen Werkstattmeldung wie „Steuergerätevariante unbekannt“ steckt also ein durchaus komplexer technischer Prozess.
Warum „es ist doch dasselbe Steuergerät“ nicht ausreicht
Weil Diagnose nicht nur daraus besteht, Datenpakete zu senden und zu empfangen. Eine Antwort vom Steuergerät zu erhalten ist relativ einfach. Zu wissen, was diese Antwort exakt bedeutet, ist deutlich schwieriger.
Angenommen, das Diagnosegerät fordert einen Messwert an und erhält zwei Bytes zurück. Ohne die passende Diagnosebeschreibung weiß der Techniker nicht, ob diese Zahl einen Druck, eine Temperatur, Drehzahl, Spannung, einen Prozentwert oder einen Status repräsentiert. In der Diagnosedatenbank befinden sich Umrechnungsregeln, Skalierungen, Einheiten und Beschreibungen, durch die aus einer Rohantwort ein verständlicher Messwert wird.
Softing beschreibt ODX genau in diesem Zusammenhang: Hexadezimale Diagnosedaten werden mit Hilfe der entsprechenden Beschreibungen in physikalische und für Menschen lesbare Werte übersetzt. Die Datenstruktur berücksichtigt dabei einzelne Varianten der Steuergeräte.
Deshalb führt die Auswahl einer falschen Variante nicht zwangsläufig zu einer eindeutigen Fehlermeldung. Problematischer ist die Situation, in der das Steuergerät tatsächlich antwortet, das Diagnosegerät diese Antwort aber mit den Definitionen einer anderen Softwarevariante interpretiert. Dann kann auf dem Display ein Wert erscheinen, der durchaus plausibel aussieht, in der real verwendeten Software aber eine andere Bedeutung hat.
Auch bei DTCs können Unterschiede beispielsweise die Beschreibung, Untertypen, Snapshot-Daten oder erweiterte Diagnoseinformationen betreffen.
Bei Servicefunktionen wird der Unterschied noch deutlicher
Bei aktiven Diagnosefunktionen ist die Abhängigkeit von der richtigen Variante noch größer. Ein Stellgliedtest, eine Kalibrierung, Anpassung, Grundeinstellung oder Codierung besteht normalerweise nicht aus einem universellen Befehl wie „Ventil einschalten“. Hinter der Schaltfläche im Diagnosetester kann eine exakte Abfolge aus Diagnose-Session, Sicherheitszugriff, Service-Identifiern, Parametern, Bedingungen und Auswertung der ECU-Antwort stehen.
Wenn eine neue ECU-Softwarevariante eine Routine, einen Identifier, Parameter oder Voraussetzungen verändert, kann eine ältere Diagnosebeschreibung nicht mehr funktionieren. Das Ergebnis kann eine negative Antwort des Steuergeräts, eine Meldung wie „Funktion nicht unterstützt“ oder eine Routine sein, die nicht mehr wie erwartet ausgeführt wird. Dabei muss weder das Fahrzeug noch das Diagnoseinterface defekt sein.
Die Diagnosedatenbank kennt möglicherweise lediglich die neue Softwarevariante noch nicht.
Kann ein Herstellerupdate die Diagnose also „kaputt machen“?
Technisch präziser lautet die Aussage: Ein Softwareupdate des Fahrzeugherstellers kann einen neuen ECU-Zustand beziehungsweise eine neue Variante erzeugen, die eine bestehende Aftermarket-Diagnosedatenbank noch nicht kennt oder nicht eindeutig identifizieren kann.
Nicht jedes Update verändert die Diagnoseschnittstelle. Viele Aktualisierungen korrigieren interne Algorithmen, ohne den Diagnoseumfang relevant zu verändern. Eine Änderung ist jedoch möglich. Softing weist darauf hin, dass Diagnosedatenbanken moderner Fahrzeuge während ihres Lebenszyklus gerade durch zusätzliche Varianten, Wartungsmaßnahmen und Funktionserweiterungen immer komplexer werden.
Ein weiteres gutes Beispiel für das Grundprinzip liefert Mercedes-Benz. Das Unternehmen erklärt, dass Qualität und Übertragungsverhalten von Daten einer Telematic Control Unit vom Softwarestand abhängen können und veraltete Software zu fehlerhaftem oder inkonsistentem Übertragungsverhalten führen kann. Dabei geht es zwar nicht direkt um klassische Werkstattdiagnose, der technische Grundsatz ist aber derselbe: Software kann das Kommunikationsverhalten eines Steuergeräts verändern, ohne dass sich dessen Hardware ändert.
Was DevCom unter automatischer Erkennung der ECU-Softwarevariante versteht
Genau dieses Problem adressiert DevCom mit einer Funktion, die intern als Autodetektion der SW-Variante einer ECU bezeichnet wird.
Das Ziel besteht nicht nur darin festzustellen, dass sich beispielsweise ein Motorsteuergerät, ABS-Steuergerät oder Karosseriemodul im Fahrzeug befindet. Das Diagnosesystem versucht anhand der Identifikationsdaten des Steuergeräts die konkrete Softwarevariante zu bestimmen und anschließend die passenden Diagnosedaten zuzuordnen. Das ist besonders wichtig, wenn eine Hardwarefamilie mit zahlreichen verschiedenen Softwareversionen existiert.
DevCom dokumentiert öffentlich, dass bei Diagnoseupdates Identifikatoren vorhandener Steuergeräte und Funktionen zur Erkennung von Steuergeräten erweitert werden. Für bestimmte Marken nennt das Unternehmen die automatische Steuergeräteerkennung auch direkt als Bestandteil des Diagnoseumfangs.
Nach der technischen Erklärung von DevCom besteht das Ziel darin, jede Steuergerätevariante möglichst eindeutig zu bestimmen. Ist eine eindeutige Erkennung nicht möglich, müssen dem Benutzer teilweise mehrere bekannte Varianten zur manuellen Auswahl angeboten werden. Genau dann ist Vorsicht erforderlich. Eine Variante nur deshalb auszuwählen, weil „damit eine Verbindung funktioniert“, ist kein sauberer Diagnoseprozess.
Warum eine falsche Auswahl schlimmer sein kann als gar keine
Wenn das Diagnosegerät ein Steuergerät überhaupt nicht erkennt, ist das Problem wenigstens offensichtlich. Der Techniker weiß, dass weitere Prüfung notwendig ist. Wird dagegen manuell eine sehr ähnliche Variante gewählt, kann die Diagnose teilweise funktionieren. Messwerte erscheinen. Einige DTCs werden beschrieben. Vielleicht reagiert sogar eine Servicefunktion.
Dadurch entsteht leicht falsche Sicherheit. Eine falsch zugeordnete Variante kann dazu führen, dass Parameter falsch dekodiert oder Diagnoseabläufe einer anderen Softwareversion ausgeführt werden. Bei reinen Lesefunktionen kann dies zu einer falschen Diagnose führen. Bei Schreibfunktionen, Codierung oder Parametrierung ist entsprechend deutlich mehr Vorsicht erforderlich.
„Gestern ging es noch, heute nicht“ – wie sollte die Werkstatt reagieren?
Die erste Schlussfolgerung sollte nicht automatisch lauten: „Das Diagnosegerät ist defekt.“ Ebenso wenig sollte automatisch davon ausgegangen werden, dass definitiv ein Herstellerupdate verantwortlich ist. Kommunikationsprobleme können auch durch Spannungsversorgung des Steuergeräts, CAN- oder DoIP-Netzwerke, Gateway-Probleme, SGW/SFD-Autorisierung, Steuergerätetausch, geänderte Codierung oder das Diagnoseinterface selbst entstehen.
Hat dasselbe Diagnosesystem das konkrete Fahrzeug früher aber problemlos unterstützt, und war das Fahrzeug zwischenzeitlich beispielsweise beim Vertragspartner oder hat ein OTA-Update erhalten, ist eine neue Softwarevariante eine der Ursachen, die frühzeitig geprüft werden sollten.
Hilfreich ist dabei die vollständige Identifikation des Steuergeräts: Hardware-Nummer, Software-Nummer, Softwareversion, gegebenenfalls Kalibrierkennungen und VIN. Existiert ein älterer Diagnosebericht, kann ein Vergleich der ECU-Identifikationen vor und nach Auftreten des Problems besonders wertvoll sein. Wenn die Diagnosedatenbank die neue Variante tatsächlich nicht kennt, sind genau diese Informationen für die Entwickler entscheidend.
Warum technische Unterstützung hier wirklich wichtig wird
Dieses Beispiel zeigt gut, warum technische Unterstützung bei modernen Diagnosesystemen weit mehr ist als Hilfe für Anwender, die einen Menüpunkt nicht finden. Eine Werkstatt kann auf eine ECU-Softwarevariante treffen, die der Fahrzeughersteller erst wenige Wochen zuvor veröffentlicht hat. Das ist möglicherweise ein Daten- und Entwicklungsproblem und kein Fehler des Mechanikers.
DevCom weist öffentlich auf seine eigene Diagnosedatenbank, regelmäßige Aktualisierungen und technische Unterstützung für TSPro und Troodon hin. Im Supportbereich werden Kunden ausdrücklich gebeten, bei Problemen möglichst detaillierte Informationen bereitzustellen.
In einer solchen Situation ist es deshalb sinnvoll, dem Support VIN, ECU-Identifikation, Hardware- und Softwarestände, Screenshots und Informationen zu einem möglichen vorherigen Händler- oder OTA-Update zu übermitteln. Diese Daten können den Entwicklern helfen, eine neue Variante zu identifizieren und anschließend in die Diagnosedatenbank zu integrieren.
Erfahrungen aus der Praxis zeigen, dass das Thema nicht nur theoretisch ist
In Fachforen finden sich Fälle, bei denen ungewöhnliche oder aktualisierte ECU-Software dazu geführt hat, dass die Steuergerätevariante nicht mehr korrekt erkannt wurde.
Auf MHH Auto wurde beispielsweise ein Mercedes-Benz W205 beschrieben, bei dem nach einem Softwareupdate des Motorsteuergeräts die Variante sowohl von XENTRY als auch von einer Aftermarket-Diagnose nicht mehr korrekt erkannt wurde. Es handelt sich um einen einzelnen Community-Bericht und nicht um ein offizielles technisches Bulletin, weshalb daraus keine allgemeine Regel abgeleitet werden darf. Der Fall zeigt jedoch gut, welche Art von Problem auftreten kann.
Auch in einzelnen Fällen mussten Diagnosedaten ergänzt oder aktualisiert werden, bevor für eine bestimmte Modulvariante wieder die korrekten Beschreibungen und Funktionen verfügbar waren. Auch hierbei handelt es sich um Einzelfälle und nicht um einen Beleg dafür, dass jedes Herstellerupdate Diagnoseprobleme verursacht.
Moderne Diagnose ist deshalb eine lebende Datenbank
Ein professionelles Diagnosegerät ist kein abgeschlossenes Messinstrument wie ein klassisches Multimeter. Die Hardware kann viele Jahre verwendet werden. Die Diagnosedaten müssen sich jedoch gemeinsam mit den Fahrzeugen weiterentwickeln.
Ein neues Fahrzeug kommt auf den Markt – neue Steuergeräte entstehen. Ein neues Modelljahr folgt – weitere Varianten entstehen. Der Hersteller veröffentlicht eine Softwaremaßnahme – möglicherweise entsteht eine weitere Softwareversion.
Deshalb sind Aktualisierungen professioneller Diagnosesysteme so wichtig. Es geht nicht nur darum, einen weiteren Fahrzeugnamen in das Menü aufzunehmen. Ein großer Teil der Entwicklungsarbeit findet unsichtbar darunter statt: bei der Identifikation von Steuergeräten, der Zuordnung einzelner Softwarevarianten und der Prüfung, ob DTCs, Messwerte und Serviceabläufe tatsächlich zu der Software passen, die im Fahrzeug läuft.