MVCI-Server
Wenden wir uns jetzt dem eigentlichen Diagnosetester zu. Die Grundidee von ASAM war, standardisierte Datenformate und ein Laufzeitsystem für die Implementierung eines Applikations- und Diagnosesystems zu entwerfen. Die Implementierung eines solchen Laufzeitsystems für den Bereich der Diagnose stellt der sogenannte MCD 3D-Server dar. Das D steht für Diagnose. Daher sagt man auch oft D-Server oder auch ODX-Kernel. Es ist standardisiert in der ISO 22900 und läuft dort unter den Namen MVCI-Server, der auch hier verwendet wird.
|
| Standardisiertes Diagnoselaufzeitsystem nach ISO 22900 |
In der Abbildung sehen wir den Aufbau eines solchen Laufzeitsystems im Detail. Nach oben, zur eigentlichen Diagnoseapplikation also der graphischen Oberfläche des Diagnosetesters, bietet das MVCI-Laufzeitsystem eine standardisierte Programmierschnittstelle, eine API (Application Programming Interface). Nach unten zum Fahrzeug verwendet die Laufzeitumgebung die D-PDU-API, um auf das Bus-Interface (VCI) zuzugreifen. Die Konfiguration des Laufzeitsystems erfolgt über den entsprechenden ODX-Datensatz.
|
| Innerer Aufbau eines MVCI-Diagnosesystem nach ISO 22900 |
Innerhalb des Laufzeitsystems ist dafür der sogenannte Data-Processor zuständig, der auf den eigentlichen Datensatz zugreift. Das heißt, der Programmierer interagiert nicht direkt mit den ODX-Daten, sondern benutzt Funktionen, um auf den Datensatz zugreifen zu können. Die Kommunikation mit dem Bus-Interface wird durch den sogenannten Communication-Processor innerhalb des Laufzeitsystems ausgeführt. Der Ablauf von Single-ECU-Jobs erfolgt im Job-Processor, während Flash-Jobs durch den sogenannten Flash-Data-Processor abgewickelt werden. Für alle diese Elemente gibt es in der Server-API entsprechende Funktionsgruppen und entsprechende Funktionsaufrufe.
Klassenstruktur
Betrachten wir nun die Klassenstruktur des MCD-Laufzeitsystems soweit sie für die Programmier-API, also den Anwender von Bedeutung ist. Sie sehen dabei eine Zweiteilung. Auf der einen Seite gibt es Datenobjekte, also Klassen, die ODX-Daten kapseln. Auf der anderen Seite gibt es die Laufzeitobjekte, die im Wesentlichen die Methoden und Aktivitäten enthalten, um auf diesen Daten bestimmte Funktionen auszuführen. Zwischen den Datenobjekten und den Laufzeitobjekten steht die Logical-Link-Table, welche die Information über die logischen Verbindungen des Diagnosetesters zu den einzelnen Steuergeräten enthält. Die Logical-Links können auf drei verschiedene Klassenstrukturen zugreifen. Für den Bereich der Applikation gibt es die sogenannten Collector-Klassen, das sind Klassen, die Messdaten und den Umgang mit den Messdaten kapseln. Für die Verstellung von Daten sind die Characteristics vorgesehen, die verstellbare Parameter, Kennlinien, Kennfelder enthalten. Für die Diagnose ist es die Klassenstruktur MCD Diag-Com-Primitives, die die Diagnosedienste und Diagnoseabläufe wie Single-ECU-Jobs, Multiple-ECU-Jobs etc. kapselt.
|
| Grundstruktur eines MVCI-Diagnosesystem nach ISO 22900 |
Wir beschäftigen uns hier nicht mit dem Bereich Messen und Kalibrieren (MC) sondern ausschließlich mit der Diagnose (D). Obwohl ASAM mit MCD 3 eigentlich den Anspruch erhebt sowohl die Diagnose als auch den Bereich Messen und Kalibrieren, also den Applikationsbereich abzudecken, gibt es hier historisch begründet zwei verschiedene Welten. Bislang ist hier eine Harmonisierung nicht gelungen.
|
| Timeline ASAM AE MCD |
Beispielablauf im Job-Processor
Als erstes Beispiel, wie eine Diagnoseanwendung das Laufzeitsystem verwendet, soll hier der Aufruf eines MULTIPLE-ECU-Jobs betrachtet werden. Die Anwendung verwendet beispielsweise den Aufruf der Methode ExecuteSync mit dem MULTIPLE-ECU-Job als Argument. Das Laufzeitsystem wird, falls noch nicht geschehen, die Java-Virtual-Machine initialisieren. Dann wird sie auf die Klassendatei zugreifen, in der der eigentliche Job, der Programmcode dieses Jobs gespeichert ist. Dieser Programmcode wird dann die entsprechenden Diagnosedienste über das Laufzeitsystem ausführen und so mit dem Steuergerät kommunizieren. Das Laufzeitsystem nimmt die entsprechende Antwort vom Steuergerät entgegen, verarbeitet diese und liefert das Ergebnis über ein MCDResult-Objekt an die Anwendung zurück.
|
| Beispielablauf im JOB-PROCESSOR |
Typischer Programmablauf
Ein typischer Programmablauf sieht wie folgt aus, siehe Abbildung links: Zuerst muss man das MCD-System initialisieren. Dann lädt man ein bestimmtes Projekt. Damit wird der Datensatz aus der ODX-Datenbank geladen. Danach wird ein Fahrzeug ausgewählt, also Typ, Modelljahr und anschließend ein Logical-Link geöffnet. Jetzt können die Diagnosedienste erzeugt und ausgeführt werden. Die Ergebnisse werden typischerweise in einer Schleife verarbeitet und am Ende wird die ganze Objektstruktur wieder aufgeräumt. In der Abbildung rechts finden Sie den stark reduzierten Programmcode für obiges Beispiel.
|
| Schematischer Programmierablauf |
Entwicklung von Diagnoseanwendungen
Die zuvor beschriebenen Standards für die Beschreibung der Diagnosedaten und für ein Diagnoselaufzeitsystem sind sicher ein Weg in die richtige Richtung und vor dem Hintergrund der wachsenden Komplexität in der Fahrzeugdiagnose nicht ersetzbar. Dies ist jedoch nur eine Seite der Medaille. Moderne Fahrzeugdiagnose setzt sich nicht allein aus einzelnen Services zusammen, sondern viele tausende Abläufe, die mit dem MVCI-Server und ODX nicht abbildbar sind.
|
| OTX-Designer der Firma emotive GmbH & Co. KG |
Diese Lücke schließt das in der ISO 13209 standardisierte Austauschformat für Diagnosesequenzen OTX, auf welches im nächsten Kapitel ausführlich eingegangen wird.
Siehe auch
Einführung in die Anwendungen für Diagnose (ASAM MCD)
