Einfuehrung ASAM MCD
In diesem Teil unseres Seminars über Diagnosesysteme im Automobil werden wir uns mit Anwendungen für das Messen, das Kalibrieren und die Diagnose beschäftigen. Im Blick auf das ISO/OSI Schichtenmodell bewegen wir uns oberhalb des eigentlichen Modells auf der Ebene der Anwendungen.
|
| Open System Interconnection (OSI) Schichtenmodell (ISO 1978) |
Eine wichtige Rolle spielt auf diesem Gebiet die ASAM e.V. (Association for Standardization of Automation and Measuring Systems). Gegründet wurde sie 1991 als eine Initiative von Fahrzeugherstellern in Verbindung mit deren wichtigsten Zulieferern. Mittlerweile hat ASAM über 120 Mitgliedsunternehmen, darunter alle wichtigen Fahrzeughersteller, ihre Zulieferer und eine ganze Reihe von Toolherstellern. Ziel der Vereinigung ist es, Standards für das Messen und Kalibrieren, das heißt für die Applikation und Diagnose zu schaffen.
Der Bereich der ASAM Standards lässt sich grob in zwei Themengruppen untergliedern:
Der erste Bereich ist ASAM AE – AE steht für Automotive Electronics. Hier geht es um den Teil der Applikations- und Diagnosewerkzeuge, die das eigentliche Interface zum Fahrzeug darstellen. Also im Wesentlichen die Busprotokolle und die darüber liegenden Schichten, mit denen appliziert und kommuniziert wird. Die dazu eingesetzten Werkzeuge – die Hauptgruppe dieser Standards – laufen unter dem Namen MCD (Measurement Calibration and Diagnosis).
Im folgenden Teil des Seminars werden wir näher insbesondere auf die die Diagnose betreffenden Teile von ASAM AE eingehen.
Der zweite große Bereich umfasst ASAM CAT – CAT steht für Computer Aided Testing. Dabei geht es um die Steuerung und Automatisierung von Prüfständen. Dieser Teil ist hier von untergeordneter Bedeutung.
Überblick ASAM AE MCD D (MVCI)
Die Grundidee lässt sich am besten beschreiben, wenn man sich auf dem folgenden Bild die Struktur eines typischen ASAM Applikations- und Diagnosesystems anschaut:
|
| Überblick MVCI-Server (ASAM AE MCD D) |
Ganz oben sind die Test- und Diagnoseanwendungen zu sehen, ganz unten die Steuergeräte im Fahrzeug, verbunden über ein Bussystem. Das Applikationssystem selbst ist über eine Hardware, das so genannte Vehicle Communication Interface, kurz VCI an das Bussystem und damit an das Fahrzeug angekoppelt. Die Schnittstelle zu diesem Businterface ist in der Ebene MCD 1 definiert. Als Programmierschnittstelle für das Businterfaces gibt es unter anderem die D-PDU API (API = Application Programming Interface), welche in der ISO 22900-2 standardisiert ist.
Darüber liegt ein Laufzeitsystem, das die Applikation und Diagnose von der darunter liegenden Hardware unabhängig machen soll. Dieses Laufzeitinterface ist in der ISO 22900 standardisiert und wird als MVCI Runtime System bezeichnet. Andere Bezeichnungen hierfür sind MVCI-Server, ASAM 3D-Server oder einfach nur D-Server.
Die für die Diagnose relevanten fahrzeug- und steuergerätespezifischen Daten sind nicht Bestandteil des Laufzeitsystems, sondern sind in einer Datenbank ausgelagert. Das Datenformat dieser Datenbank wird auf der Ebene MCD 2 beschrieben. Es ist in der ISO 22901-1 standardisiert und besser bekannt unter seiner Abkürzung: ODX (Open Diagnostics data eXchange).
Darüber liegt die ASAM Schicht MCD 3. Dies ist das Programmierinterface, über das das Laufzeitsystem programmiert wird. Diese Schicht wird im Allgemeinen als D-Server API bezeichnet.
Sehen wir uns nun an, wie eine typische Applikations- oder Diagnoseanwendung in diesem MCD-System ablaufen könnte. Es beginnt mit der Fragestellung, die auf der Ebene der Anwendung gestellt wird, zum Beispiel: „Wie groß ist die aktuelle Motordrehzahl?“. Dazu ruft die Test- und Diagnoseanwendung über die D-Server API auf Ebene MCD 3 eine Funktion auf, mit der diese Anfrage an das Testsystem gestellt wird. Das Testsystem weiß nun, dass es dazu eine Busbotschaft an das Steuergerät im Fahrzeug senden muss. Es weiß aber noch nicht welche. Deswegen wird in der Diagnosedatenbank nachgeschaut, wie die Busbotschaft kurz PDU (Protocol Data Unit) zum Auslesen der Drehzahl lautet. Diese Busbotschaft ist in der Datenbank beschrieben und wird an das Laufzeitsystem zurückgegeben. Das Laufzeitsystem wiederum gibt sie über die MCD 1 Schnittstelle (D-PDU API) an das Businterface weiter. Vom Businterface wird die Botschaft dann über das Bussystem als Diagnose-Request an das Steuergerät gesendet. Für den Applikationsbereich wäre es entsprechend der Applikations-Request. Das Steuergerät antwortet mit einer entsprechenden Response, die wiederum vom Fahrzeuginterface entgegengenommen und über die MCD 1 Schicht entpackt und als Antwortbotschaft aufbereitet wird. Typischerweise wird die Drehzahl als steuergerätespezifischer Hexadezimalwert zurückgeliefert. Der Anwender möchte aber die Drehzahl in Umdrehung pro Minute sehen. Es muss also eine Umrechnung stattfinden. Wie diese Umrechnung geschieht, wie die steuergerätespezifischen Hexadezimalwerte in den physikalischen Drehzahlwert umzurechnen sind, steht wiederum in der Datenbank. Daher wird die empfangene Antwortbotschaft über die Datenbank umgesetzt und in eine reale physikalische Drehzahl umgerechnet und schließlich über die MCD 3 Schicht an die Test- und Diagnoseanwendung nach oben gesendet.
Wir haben hier also vor allem drei verschiedene Ebenen oder Aufgabenbereiche, die ASAM abzudecken versucht. Der erste ist das Businterface zum Bussystem innerhalb des Fahrzeugs. Das ist die Schicht MCD 1. Die Idee dahinter ist, über standardisierte Schnittstellen verschiedene Businterfaces unterschiedlicher Herstellers einsetzen und/oder austauschen zu können.
Die zweite Ebene betrifft die Daten. Die Datenbank einer Fahrzeugbaureihe setzt sich aus den einzelnen Datensätzen der verschiedenen Steuergeräte zusammen. Diese werden meist von verschiedenen Zulieferern bereitgestellt und sollen über den gesamten Lebenszyklus eines Fahrzeugs konsistent und wiederverwendbar bereitstehen. Im weiteren Teil des Seminars wird detailliert auf den hier verwendeten Standard ODX eingegangen. Für den Bereich MC, also Applikation heißt das Datenformat ASAP 2.
Die dritte Ebene ist das Laufzeitsystem. Das Laufzeitsystem kapselt alle für das Versenden, Empfangen und Umrechnen nötigen Algorithmen. Die zugehörige API gibt der Diagnose- oder Applikationsanwendung Möglichkeiten zum Zugriff auf die Datenbank und die Laufzeitfunktionen.
Wir werden in den folgenden Abschnitten genauer auf die einzelnen Ebenen MCD 1 bis MCD 3 eingehen.
Timeline
Wie wir vorher gesehen haben existiert die ASAM-Initiative seit Anfang der 90er Jahre. Es gibt also eine entsprechend lange Historie und eine ganze Reihe von Versionen der einzelnen Protokollebenen, die mehr oder weniger parallel und seriell entstanden sind.
|
| ASAM Timeline |
Beginnen wir mit dem Applikationsprotokoll CCP (CAN Calibration Protocol), entstanden Anfang der 90er Jahre, als CAN zum ersten Mal für die Applikation eingesetzt wurde. Dies ist mittlerweile bei Version 2.2. Der designierte Nachfolger des CAN Calibration Protocols XCP (Extended Calibration Protocol), liegt heute in der Version 1.1 vor. Die Schnittstelle zum Bussystem ist nicht ganz so alt: Die D-PDU API ist in der zweiten Hälfte dieses Jahrzehnts entstanden.
Für die On-Board-Kommunikation hat man bei ASAM ebenfalls eine Spezifikationsschiene aufgemacht. Unter dem Stichwort FIBEX versucht man dort die Busbotschaften, die Signale und die Topologie des On-Board-Netzwerkes im Fahrzeug zu beschreiben. ASAP2 (A2L) gibt es mittlerweile in der Version 1.6. Die Datensätze für die Diagnose sind etwas jünger. Mit ODX liegt hier mittlerweile ein ISO Standard. In der Programmierebene zur Test- oder Applikationsanwendung wurde im Bereich MC bereits relativ früh standardisiert. Für die Diagnose (MCD 3D) erst in diesem Jahrzehnt.
Siehe auch
ODX – Datenformat für Diagnosedaten nach ISO 22901
