D-Server – ISO 22900-3

Mit der Einführung von ISO 22900-3 (ASAM MCD-3 D) sollte eine universelle Programmierschnittstelle zur Fahrzeugdiagnose für unterschiedliche Anwendungen definiert werden. Zur Fahrzeugdiagnose gehören u.a. folgende Aufgaben:

• Auslesen der emissionsrelevanten Daten,
• Auswertung vom Fehlerspeicher einzelner Steuergeräte,
• Konfiguration und Kalibrierung von Steuergeräten,
• Software-Update.

In der Anfangszeit der Fahrzeugdiagnose (Ende der 1980er bis Mitte der 1990er Jahre) wurden all diese Szenarien durch OEM-spezifische Verfahren realisiert. Im Rahmen einer Normierung wurden zunächst zwei wesentliche Teilbereiche standardisiert. Fahrzeugbeschreibung (Datenbasis) und Datentransport (Transport- oder Protokollschicht).

• Die Fahrzeugbeschreibung wurde in ISO 22901-1 (ASAM MCD-2 D) mithilfe des neu eingeführten Formats ODX vereinheitlicht.
• Der Zugriff auf die Protokollschicht über eine universelle API wurde in ISO 22900-2 standardisiert.

Die Verbindungsstelle zwischen Fahrzeugbeschreibung und Transportschicht ist der in ISO 22900-3 eingeführte D-Server (auch MVCI-Server bzw. MVCI-Kernel genannt).

Das folgende Diagramm zeigt den vereinfachten Ablauf, mit dem der D-Server von einer Applikation zum Ausführen eines Diagnosedienstes genutzt werden kann.

Der Zugriff auf die einzelnen Elemente (Fahrzeugtypen, Steuergeräte, Diagnosedienste und deren Parameter) erfolgt über die in der ODX-Beschreibung festgelegten Namen dieser Elemente. Die Anwendung hat die Möglichkeit, direkt auf die einzelnen Request/Response-Parameter zuzugreifen. Diese liegen nicht nur als Rohdaten, sondern auch als passend konvertierte physikalische Werte inklusive Einheit vor. Die Umrechnung erfolgt durch den D-Server anhand der ODX-Daten. Ein D-Server kann auch ohne aktive Kommunikation mit einem Fahrzeug zum Durchsuchen und Anzeigen der ODX-Daten genutzt werden. D-Server-Objekte werden damit grob in zwei Gruppen unterteilt: Database-Objekte und Laufzeit-/Runtime-Objekte.

Database-Objekte werden aus den ODX-Daten erstellt und dienen als Templates. Laufzeit/Runtime-Objekte werden aus den entsprechenden Database-Templates erstellt und meistens nur dann, wenn eine Verbindung zu D-PDU API besteht. Diese Objekte werden für die aktive Kommunikation mit den Steuergeräten benötigt.

Merkmale

• Symbolischer Zugriff
• Unterstützt automatische Variantenerkennung von ECUs und Auswahl
• Hilfsklassen für Variantenkodierung von ECUs
• Hilfsklassen fürs Flashen von ECUs (Software-Update)
• Nachladbarkeit von Flashdaten und ECU-Konfigurationsdaten
• Laufzeitsystem zum Ausführen komplexer Abläufe/Jobs (siehe unten)
• Parallele Nutzung mehrere VCIs
• Parallele Kommunikation mit mehreren ECUs über ein VCI
• Synchrone, asynchrone, zyklische und Ausführung mit Wiederholung von Diagnosediensten
• Events
• Objektorientierte Programmierschnittstelle
• Fehlerbehandlung durch Abfangen von Exceptions

Neben den einfachen Diagnosediensten, die durch ein D-PDU-API-ComPrimitive abbildbar sind, bietet ein D-Server die Möglichkeit, komplexe Abläufe, z. B. das Flashen, in einem sogenannten Job zusammenzufassen. Die meisten Implementierungen erlauben es dem Anwender, solche komplexen Diagnoseabläufe in Java unter Benutzung der D-Server-JNI zu beschreiben. Dieser Ansatz ist in der ISO 22900-3 spezifiziert. Dabei kann ein D-Server während der Laufzeit eine Java-Virtual-Machine einsetzen, um die Java-Jobs zu interpretieren.

Die ISO 22900-3 (ASAM MCD-3 D) definiert eine objektorientierte Programmierschnittstelle für die Fahrzeugdiagnose. Die Definition der Programmierschnittstelle ist herstellerunabhängig, sodass sie in jeder beliebigen objektorientierten Programmiersprache umgesetzt werden kann. Typischerweise wird sie in Java und C++ implementiert.