Hintergrund und Motivation

Mit ODX (Open Diagnostic data eXchange) liegt ein vereinheitlichtes, in ISO 22901 (ASAM MCD 2D) standardisiertes Beschreibungsformat für Diagnosedaten vor. ODX beschreibt den Aufbau von Diagnosediensten mit den jeweiligen Parametern Umrechnungsmethoden, Einheiten, Varianten usw. Auf Grundlage eines standardisierten Diagnoselaufzeitsystems (MVCI-Server oder D-Server, ISO 22900) kann ein Diagnosetester aufgebaut werden, der durch diesen ODX-Datensatz konfiguriert wird. Der Anwender dieses Systems muss sich dadurch um den internen Aufbau der Diagnosekommunikation wie die verwendeten Transport- und Diagnoseprotokolle nichts mehr kümmern. Er sucht sich über die Datenbankschnittstelle der D-Server API (ISO 22900-3) zuerst die Steuergerätevariante, dann den entsprechenden Service, bedatet ihn, sendet ihn mit einem Funktionsaufruf an das Steuergerät und wertet die zurückgegebene Antwort aus, siehe Bild.

Aufbau und Wirkungsweise eines standardisierten Diagnoselaufzeitsystems (MVCI)

Derartige Diagnoselaufzeitsysteme werden von verschiedenen Herstellern angeboten, wie etwa: PRODIS.MCD von DSA, DTS-COS von Softing oder die Eigenentwicklungen einiger Fahrzeughersteller. Mit ODX lassen sich jedoch nur die Diagnosedaten beschreiben, die zur Kommunikation eines Diagnosetesters mit einem oder mehreren Steuergeräten notwendig sind.

In der Praxis hat ein Diagnosetester in Entwicklung, Produktion und Service jedoch deutlich mehr Aufgaben. Die Fehlersuche in der Werkstatt erfordert die Verknüpfung der Diagnosedaten mit den Fehlersuchanleitungen und Ersatzteildatenbanken des Fahrzeugherstellers. Sämtliche Diagnoseschritte und die Ergebnisdaten müssen protokolliert und verwaltet werden. Nur im Zusammenwirken mehrerer Diagnosedienste werden vollständige Funktionstests möglich, können Fahrzeugkomponenten nach einem Austausch angelernt oder Softwareupdates der Fahrzeugsteuergeräte durchgeführt werden. Eine Diagnosesequenz beschreibt daher die verschiedenen Interaktionen zwischen einem Anwender (Entwicklungs-, Produktions- oder Werkstattpersonal), dem Diagnosetester, den Steuergeräten und ggf. der externen Messtechnik, siehe Bild.

Diagnosesequenz in Zusammenspiel mit Nutzer- und Fahrzeuginteraktion

Derartige Diagnoseabläufe wurden in der Vergangenheit meist innerhalb des Steuergeräte-Lastenhefts in Prosa definiert. Ein Entwicklungsingenieur setzte dann diese Abläufe oft durch das Schreiben von Programmcode (beispielsweise als Java-Job innerhalb von ODX) Tester-spezifisch um. Aufgrund der abweichenden Anforderungen in Entwicklung, Produktion und Service wurden diese Abläufe häufig mehrfach implementiert. Zusätzlich wurden bei der Implementierung durch geänderte Randbedingungen oder aus der Erfahrung des Entwicklungsingenieurs nicht selten Änderungen an den zuvor spezifizierten Abläufen vorgenommen.

Beachtet man außerdem, dass heute pro Fahrzeugbaureihe viele hundert bis mehrere tausend teilweise sehr komplexe Diagnosesequenzen existieren, wird klar, dass das Wissen über die richtigen, praxiserprobten Diagnoseabläufe für ein Unternehmen von strategischer Bedeutung ist. Dieses Wissen muss prozesssicher und wiederverwendbar abgelegt werden. OTX soll hier als ein einheitliches, standardisiertes Austauschformat von der Spezifikation, über die Implementierung bis hin zur Ausführung von Diagnosesequenzen unterstützen. Es muss durchgängig vom Fahrzeughersteller über dessen Zulieferer von der Entwicklung über die Fertigung bis zur Werkstattorganisation verwendbar sein, siehe Bild.