Benutzer:Chrishecker/ODX

Dieser Artikel ist im Entstehen und noch nicht Bestandteil der freien Enzyklopädie Wikipedia.

Solltest du über eine Suchmaschine darauf gestoßen sein, bedenke, dass der Text noch unvollständig sein und Fehler oder ungeprüfte Aussagen enthalten kann. Wenn du Fragen zum Thema hast, nimm Kontakt mit dem Autor Chrishecker auf.

Bestandteile des Standards ODX

Der ODX-Standard besteht formal aus folgenden Dokumenten:

• Visio UML Model
• XML Schema
• Dokumentation in PDF
• Checkerregeln in PDF
• Beispiel XML-Dateien

Teile dieser Dokumente sind für den Einsatz und die Integration in Werkzeugen vorgesehen, andere für die Anwender als Lektüre. Die Checkerregeln beispielsweise werden typischerweise in Werkzeuge umgesetzt, da es zu aufwendig ist, alle Regeln auf eine ODX-Datenbasis manuell anzuwenden. Die Bestandteile des ODX-Standards werden in fünf Kategorien organisiert:

Kategorie	ODX-Begriff
Diagnose	DIAG-LAYER-CONTAINER
Flashdaten	FLASH
Fahrzeugtopologie	VEHICLE-INFO-SPEC
Kommunikationsparameter	COMPARAM-SPEC
Steuergeräteübergreifende Abläufe	MULTIPLE-ECU-JOB-SPEC

Die Notation des ODX-Standards und seiner Kategorien erfolgt in Unified Modelling Language (UML) und soll in folgendem Bild beispielhaft veranschaulicht werden. Die Wurzel des Objektmodells ist das Element ODX, welches genau ein Element einer Kategorie beschreibt.

Datei:Diagnosekommunikation 2005 04 17 stm 47.jpg

UML TopLayer

Der DIAG-LAYER-CONTAINER bildet die Ausnahme, da in einem Objekt dieser Kategorie mehr als ein Element vom Typ DIAG-LAYER enthalten sein darf. DIAG-LAYER werden auch Layer genannt. Die DIAG-LAYER-CONTAINER sind der Kern einer jeden ODX-Datenbasis, da in Elementen des Typs DIAG-LAYER die klassischen Diagnosedienste beschrieben werden. Die Kategorien werden nun im Detail erläutert.

Diagnosedaten

Die Elemente der Kategorie Diagnose enthalten Diagnoseprotokoll- und Steuergerätebeschreibungen, sowie Diagnosedienste, Diagnosevariable, komplexe Diagnoseabläufe und –Jobs, Datentypdefinitionen und können von einander erben sich beerben?. Die Vererbung ist aus dem ASAM MCD-2D Version 1.2.2 übernommen worden, d.h. ein Layer einer tieferen Schicht, kann von Layern höherer Schichten erben. Zusätzlich zur Vererbung der Vorgängerversion bietet ODX einen weiteren Datencontainer, die sog. ECU-Shared-Data. Dieser Layer stellt Bibliotheksobjekte bereit. Die einmalige Beschreibung von Diagnoseinformationen, die von anderen Layern (wieder-)verwendet werden ist somit möglich. Beispielsweise kann eine Fehlercodetabelle, die über mehrere Steuergeräte gleich aufgebaut ist, mehrmals verwendet werden, und zwar durch einfache Referenzierung des ECU-Shared-Data-Layers. Ein Diagnose-Layer enthält also immer genau ein Element der Typen:

• ECU-Shared-Data,
• Diagnoseprotokoll,
• Funktionale Gruppe,
• Basissteuergerät oder
• Steuergerätevariante.

Weitere Details der Vererbungsprinzipien in ODX sind im Abschnitt Redundanzvermeidung durch Vererbung beschrieben.

Flashdaten

Die Flashdaten beschreiben die Daten, die in ein Steuergerät geladen werden können. Sie enthalten eine strukturierte Festlegung der physikalischen Speicheradressen und Speichermodularität (Segmentierung) der einzelnen Flashbereiche von elektronischen Bauteilen (Speicherchips). Weiterhin wird in den Flashdaten die logische Speicherarchitektur beschrieben. In der logischen Speicherarchitektur der Softwaremodule wird die genaue Verteilung der Komponenten Code, Daten usw. auf die Speicherbausteine definiert. Damit bei Flashprozessen sinnvolle Softwarestände in dem Speicher der Steuergeräte erzeugt werden können, enthalten die Flashdaten Beschreibungen und Identifikationen von Steuergeräten und Softwaremodulen, sowie Tabellen, die diese Identifikationen in einer Art Kompatibilitätsmatrix für Programmieranwendungen nach ASAM MCD-3D zur Verfügung stellen. Es wird also festgelegt, welche Softwarekomponente zu welchem Steuergerät kompatibel ist; jedoch wird auch die Kompatibilität unter denSoftwaremodulen beschrieben.

Fahrzeuginformationen

Die Fahrzeuginformationen umfassen im wesentlichen zwei Bereiche. Einerseits sind dies die Kommunikationswege und -parameter zu den Steuergeräten (LogicalLink). Andererseits können Fahrzeugvarianten aus der Gesamtmenge aller Steuergeräte einer Fahrzeugbaureihe/-plattform zusammengestellt und die Verbindungstopologie der Steuergeräte beschrieben werden. Die Beschreibung erfolgt aus diagnosetechnischen Gesichtspunkten. Durch diese Festlegungen ergibt sich, dass die Konfiguration von Testwerkzeugen entfallen kann. Im Betrieb muss lediglich der Fahrzeugtyp und das zu untersuchendes Steuergerät ausgewählt werden. Die Diagnosehardware (Bus-Interface) wird automatisch vom D-System anhand der gewählten Datenbeschreibung gefunden und eingeschaltet. Die notwendigen Resourcen müssen allerdings vorhanden sein. Damit dienen die Fahrzeuginformationen der Bereitstellung einer passenden Laufzeitdatenbank für das D-System im Rahmen einer Diagnosesitzung.

Datei:Diagnosekommunikation 2005 04 17 stm 48.jpg

Fahrzeugkonfigurationen

Das Bild veranschaulicht, dass über die Fahrzeuginformationen Fahrzeugkonfigurationen aus der Menge aller Steuergeräte gebildet werden können. Alle Steuergeräte sind in der ODX-Datenbasis beschrieben, die in einer Fahrzeugplattform verbaut werden können. Im Beispiel enthält die Fahrzeugkonfiguration Sport vier Steuergeräte, wobei die Steuergeräte Soundsystem und Kombiinstrument auch in der Konfiguration Cabriolet enthalten sind. Die Steuergeräte Schiebedach und Dieselmotor sind in den beiden Konfigurationen Sport und Cabriolet jedoch nicht enthalten. Da der Maximalausbau der Topologie der Fahrzeugplattform festliegt, sind bei einer gewählten Konfiguration implizit auch die physikalischen Kommunikationswege über die Fahrzeugbussysteme definiert. Die Bildung dieser Fahrzeugkonfigurationen dient auch der Redundanzvermeidung in den Datenbasen, da die Steuergeräte nicht mehrmals – für jede Konfiguration einmal - beschrieben werden müssen.

Kommunikationsparameter

Die ODX-Kategorie Kommunikationsparameter (COMPARAM-SPEC) dient zur strukturierten Beschreibung von Kommunikationsparametern. Dies können z. B. Diagnoseadressen von Steuergeräten, Timings des Testwerkzeugs oder Steuergeräte-Timeouts sein. Das Kommunikationsverhalten des D-Systems, wie automatische Wiederholungen und Segmentierung, wird darüber hinaus in dieser Beschreibung festgelegt. Dabei wird zwischen standardisierten und fahrzeugherstellerspezifischen Kommunikationsparametern unterschieden. Diese Kategorie beschreibt die Kommunikationsparameter eines Diagnoseprotokolls und daher werden die Kommunikationsparameter auch Protokollparameter genannt. Über die Festlegungen der Kommunikationsparameter wird die werkzeugunabhängige Verwendung der ODX-Diagnosedaten erst ermöglicht, da in dieser Kategorie die Anhängigkeiten von der Hardware und dem Kommunikationsprotokoll gekapselt werden. Da die Festlegungen der Parameter tief in das D-System eingreifen, werden diese Spezifikationen von den Testwerkzeuganbietern beigestellt. Ein Satz von Kommunikationsparametern wird in einem speziellem Datenmodell COMPARAM-SPEC definiert.

Standardisierte ODX-Protokollparametersätze

Für einige weit verbreitete Diagnoseprotokolle sind standardisierte Protokollparametersätze von der ODX-Normierungsgruppe festgelegt worden. Diese Protokollparametersätze werden COMPARAM-SPEC genannt. Die Parameter in den COMPARAM-SPECs haben fest definierte SHORT-NAMEs und festgelegte Default-Werte.

Diagnoseprotokoll	ODX SHORT-NAME	Norm
KWP 2000 auf K-Leitung	KWP2000_CPS	ISO-14230
KWP 2000 auf CAN	KWP_on_CAN_CPS	ISO15765
Unified Diagnostic Services	UDS_CPS	ISO 14229-1
GMLAN	noch nicht definiert	GMW3110
Class 2	noch nicht definiert	GM Protokoll basierend J1850

Da nach ISO/OSI-Referenzmodell auf jeder Schicht ein oder mehrere Protokolle existieren können, ist der Begriff des Protokolls präzise anzuwenden. In ODX existiert der Layer-Typ Protocol, der die Diagnosedienste beschreibt. Diese Beschreibung muss jedoch keine Festlegung eines Kommunikationsparametersatzes enthalten. Was sie definieren muss, ist eine Vaterbeziehung (PARENT-REF) zu einer COMPARAM-SPEC, über welche die Kommunikationsparameter geerbt werden können. Eine sinnvolle Festlegung des Begriffes „ODX-Protokoll“ könnte die Zusammenfassung der Definition der Diagnosedienste in einem Layer des Typs Protocol mit einer durch diesen Layer verwendeten COMPARAM-SPEC sein. Die beiden Spezifikationen (Layer und COMPARAM-SPEC) sind in jeweils einer ODX-Datei zu finden (KWP_on_CAN_CPS.odx-c und ISOKwp15765.odx-d) oder können zum packed-ODX (PDX) „zusammengezippt“ werden.

Datei:Diagnosekommunikation 2005 04 17 stm 49.jpg

ODX Protokoll Aufbau

Das Beispiel zeigt einen Layer ISOKwp15765, der eine Vaterbeziehung auf die normierte COMPARAM-SPEC KWP_on_CAN_CPS hat. Diese COMPARAM-SPEC kann über die Verwendung durch den Layer ISOKwp15765 hinaus von weiteren Protokoll-Layern innerhalb einer ODX-Datenbasis verwendet, d. h. referenziert, werden.

Steuergeräteübergreifende Abläufe

Durch Vernetzung von Steuergeräten werden neue Software-Funktionen für Fahrzeuge realisierbar. Dies ist von besonderer Relevanz für alle aktiven und passiven Sicherheitssysteme im Fahrzeug. Die Überprüfung dieser Elektroniksysteme in der Entwicklung oder in den Werkstätten wird durch die Vernetzung jedoch immer komplexer. Deshalb sieht die Kategorie steuergeräteübergreifende Abläufe vor, Spezifikationen von komplexen Abläufen (sog. Jobs), die mehrere Steuergeräte einbeziehen, vornehmen zu können. Da die Abläufe mehrere Steuergeräte( d. h. Diagnose-Layer) involvieren, ist die Spezifikation innerhalb eines Diagnose-Layers nicht möglich und erfordert eine eigene Kategorie für diese Art der Abläufe.

Die Spezifikationen der steuergeräteübergreifenden Abläufe (MULTIPLE-ECU-JOBs) können mit Hilfe von ODX erstmals standardisiert definiert werden. Die Beschreibung umfasst u. a. Java-Jobs für die Spezifikation der Abläufe und Referenzen zu Diagnose-Layern, um die dort definierten Diagnosedienste in den Abläufen verwenden zu können.

Redundanzvermeidung durch Vererbung

Die Daten treiben das gesamte ASAM-System und sind deswegen von zentraler Bedeutung. Damit der Umfang an Daten nicht unnötig hoch und das Datenbanksystem pflegbar ist und bleibt, ist unbedingt auf Redundanzvermeidung zu achten. Deshalb wurden im ASAM MCD-2D vier Ebenen (Schichten) und die Bibliotheken eingeführt. Innerhalb dieser vier Ebenen wird automatisch von der jeweils darüber liegenden Schicht geerbt. Die Bibliotheken stehen als allgemein verwendbare Container für alle vier Schichten zur freien Verfügung und können über eine Referenzierung geerbt werden.

Die Schichten des ODX-Standards Das ODX-Schichtenmodell besteht aus vier Schichten:

1. Protokoll
2. Funktionale Gruppe
3. Steuergeräte-Basisvariante
4. Steuergerätevariante

Eine Protokollschicht enthält die protokollrelevante Information. Diese (Diagnosedienst-) Protokollspezifikation kann nach einer allgemeinen Norm – wie ISO 14229-1 – oder nach hausinternen Normen der Fahrzeughersteller und Steuergerätezulieferer erfolgen. Anwendung für zuliefererspezifische Protokolle sind u. a. im After-Market zu beobachten, beispielsweise für nachgerüstete Standheizungen. Eine Funktionale Gruppe beschreibt eine Gruppe von Steuergeräten mit ähnlicher oder gleicher Funktion. Diese Steuergeräte sind meist als Gruppe über eine funktionale Adresse zu erreichen, z. B. alle Türsteuergeräte in einem Fahrzeug. Die Steuergeräte-Basisvariante beschreibt die Grundversion eines Steuergerätetyps, z. B. das Diesel-4-Zylinder-Motorsteuergerät. Es bezieht sich also oft auf eine Hardware-Plattform. Die Steuergeräte-Basisvariante wird typischerweise über die physikalische Adresse angesprochen. Eine Steuergerätevariante ist eine spezielle Ausprägung der Steuergeräte-Basisvariante, z. B. ein bestimmter Software-Stand in eine Hardware-Plattform. Die Erkennung einer Steuergerätevariante erfolgt über sog. Variantenerkennung mit Hilfe der Variant Patterns. Dazu ist mind. ein Diagnosedienst als Steuergerätevariantenidentifikation (Variant Identification Service) in der ODX-Datenbasis zu bestimmen. Es darf nur entweder eine Variante der Steuergeräte-Basisvariante oder die Steuergeräte-Basisvariante selbst zur Laufzeit aktiv sein.

Die vier Schichten haben viele Gemeinsamkeiten, aber auch spezifische Merkmale. Die Schichten können enthalten:

• Sammlung von DIAG-COMM-Objekten und/oder -Referenzen (Diagnosedienste, Java Jobs)
• Sammlung von REQUEST-Objekten (Diagnoseanfragen)
• Sammlung von RESPONSE-Objekten (diagnoseantworten)
• Sammlung von FUNCTIONAL-CLASS-Objekten (Klassifizierungselemente)
• Sammlung von DIAG-DATA-DICTIONARY-SPEC-Objekten (Beschreibungen von Datenobjekten)
• Dokumentationsunterstützung durch ADMIN-DATA- und COMPANY-DATA-Objekte

Diese vier Schichten werden durch die Bibliotheksobjekte (ECU-SHARED-DATA) ergänzt, die in das Schichtenmodell eingefügt werden können.

Datei:Diagnosekommunikation 2005 04 17 stm 50.jpg

Hierarchie in UML

Das Bild zeigt ein typisches Vererbungsszenario. Von dem Protokoll UDS wird eine funktionale Gruppe für den Antriebsstrang abgeleitet. Die funktionale Gruppe Antriebsstrang beschafft sich per Import die Objekte aus der Einheiten-und-Fehler-Code-Bibliothek. Die beiden Steuergeräte-Basisvarianten für 6-Zylinder-Benzinmotor und 6-Zylinder-Dieselmotor erben nun die Objekte mit der Antriebsstrang-Gruppe komplett, inklusive der referenzierten Einheiten und Fehlercodes der ECU-SHARED-DATA. Schlussendlich existieren in dem Beispiel noch drei Steuergerätevarianten, die von ihren jeweiligen Steuergeräte-Basisvarianten erben. Daraus folgt, dass beispielsweise der Steuergerätevariante SW_v_0_1_1 auch die Units und die Einheiten, aber auch die Protokollspezifikation des UDS, bekannt sind.

Da die Importbeziehung anders gestaltet ist als die Vererbung, wird sie kurz beschrieben. Auch die Import-Beziehung dient der Reduzierung der Datenredundanz. Ein Import findet auf die ECU-SHARED-DATA-Objekte einer Datenbasis statt. Dadurch können ECU-SHARED-DATA Objekte prinzipiell als Bibliotheken betrachtet werden. Ein besonders wichtiger Aspekt ist, dass importierte Objekte eine Schicht nicht nur ergänzen dürfen, sondern dass importierte Objekte geerbte Objekte überschreiben, also in der Hierarchie zwischen den Schichten anzusiedeln sind. Bild

Datei:Diagnosekommunikation 2005 04 17 stm 51.jpg

Hierarchie_in_UML_ECU_SHARED_DATA

Eine Einheit Meter [m], die sowohl in dem UDS-Protokoll, als auch in der Unit_and_DTC_Library in dem vorangegangenen Beispiel enthalten ist, wird in den Schichten, welche die Motorsteuergeräte definieren, in der Form verwendet werden, wie sie in der Schicht Unit_and_DTC_Library festgelegt wurde.

Datenpool und Datenbasis

Als ODX Datenpool (Data Pool) wird eine Menge von ODX-Daten (Instanzen) bezeichnet, die über ODX-Links erreichbar sind. In einem Datenpool gelten Regelungen zum Namensraum, um Uneindeutigkeiten zu vermeiden. Ein Datenpool kann eine lauffähige Datenmenge umfassen, oder auch nur eine nicht-lauffähige Untermenge einer Datenbasis. Er kann konsistent oder nicht-konsistent sein. Um eine lauffähige Datenmenge (Laufzeit-Datenbasis) zu bilden, wird mindestens je eine Instanz folgender Kategorien benötigt:

• Kommunikationsparameter: (ComparamSpec)
• Diagnose: (DiagLayerStructure)
• Fahrzeuginformationen: (VehicleInfo)

Datei:Diagnosekommunikation 2005 04 17 stm 52.jpg

ODX Datapool Beispiel

Im Beispiel sind die Kommunikationsparameter in der Instanz KWP_on_CAN_CPS und das Diagnoseprotokoll ist in der Instanz ISOKwp15765 enthalten. Die Fahrzeuginformation ist in DieselModel spezifiziert und wird durch die ECU-SHARED-DATA-Instanz Unit_and_DTCs_Library ergänzt. Schlussendlich ist die Instanz MyDemoCar die benutzerspezifische Umsetzung eines Fahrzeugs in beispielsweise mehrere Funktionale Gruppen, Steuergeräte-Basisvarianten und Steuergerätevarianten. Meist wird in der Praxis der Begriff Datenbasis eingesetzt. Die exakte Differenzierung der Begriffe Datenbasis und Datenpool wird in dem Kapitel, das die Vererbung und den Aufbau von ODX-Datenbasen innerhalb des ODX-Standards [3] beschreibt, erläutert.

Autorensysteme

Die Bedeutung der Autorensysteme (Editoren) für die effiziente Anwendung von Austauschformaten begründet sich darin, dass die maschinenlesbaren Formate für den menschlichen Anwender oft nur schwer verständlich sind. Daher werden Formate wie XML vor dem Anwender von Autorensystemen „versteckt“.

Der folgende XML-Ausschnitt zeigt die Komplexität einer Datenbeschreibung anhand des „key“ Data Object Property des „securityAccess“-Diagnosedienstes. <DATA-OBJECT-PROP ID="DIAG-LAYER-CONTAINER.DiagCanTemplate.PROTOCOL.DiagCan.DATA-OBJECT-PROP.key"> <SHORT-NAME>key</SHORT-NAME> <LONG-NAME>key</LONG-NAME> <COMPU-METHOD> <CATEGORY>IDENTICAL</CATEGORY> </COMPU-METHOD> <DIAG-CODED-TYPE BASE-DATA-TYPE="A_BYTEFIELD" TERMINATION="END-OF-PDU" xsi:type="MIN-MAX-LENGTH-TYPE"> <MAX-LENGTH>8</MAX-LENGTH> <MIN-LENGTH>1</MIN-LENGTH> </DIAG-CODED-TYPE> <PHYSICAL-TYPE BASE-DATA-TYPE="A_BYTEFIELD"/> </DATA-OBJECT-PROP>

Ein leistungsfähiges Autorensystem liefert dem Anwender eine Präsentation der wesentlichen Informationen, die für die Diagnosekommunikation relevant sind. Dadurch wird der Autor durch das ODX-Modell geführt. Aus dem Autorensystem heraus können zu jedem gewünschten Zeitpunkt Papierkopien der elektronischen Spezifikation erstellt werden.

Konsistenzprüfungen

In Autorensystemen sind Datenüberprüfungen sinnvoll eingebettet. Da ist einerseits die Prüfung auf Konsistenz einer Datenbasis gegenüber dem ODX-Standard, andererseits die Überprüfung der Kommunikationsdateninhalte auf symbolische Interpretation (Semantik der Dateninhalte).

Die Prüfung auf ODX-Konformität prüft auf Pflichtelemente, Referenzen usw., letztendlich, ob die Datenbasis ODX-konform ist. Dabei kann allerdings nicht festgestellt werden, ob der Inhalt der Instanzen sinnvoll gefüllt ist. Die Semantik der Dateninhalte wird von einem symbolischen Interpreter überprüft. Dazu wird in dem Autorensystem die Kommunikation beispielhaft ohne reales Steuergerät getestet. Die Datenströme, die in der realen Kommunikation existieren würden, werden symbolisch interpretiert (Pre-Interpretation). Es erhöht damit die Qualität in der Fehlersuche, da bei überprüfter Spezifikation, ein Kommunikationsproblem in der realen Kommunikation eindeutig dem Steuergerät zuzuordnen ist.

MCD-Projekt

Das Autorensystem ist notwendig, um einen Datenpool und eine Datenbasis zu generieren. Weiterhin muss ein MCD-Projekt zusammengestellt werden, da ein MCD-Projekt die Basis jedes Diagnosevorganges nach ASAM MCD ist. Es ist erforderlich, um ODX-Daten anwenden zu können. Ein lauffähiges MCD-Projekt muss eine lauffähige und konsistente Datenbasis enthalten. Das MCD-Projekt stellt dem Communication Server (COS) die ODX-Daten im Laufzeitformat zur Verfügung. Das Laufzeitformat wird durch einen geeigneten Transformator vom Autorensystem oder zur Laufzeit generiert.

Austausch von ODX-Daten über PDX

Der Austausch von Datenbasen, die im ODX-Format spezifiziert werden, kann nach zwei Methoden erfolgen:

Austauschmethode	Datei-Extension
Austausch einzelner Dateien im XML-Format	.odx | .xml
Austausch einer Sammlung von Dateien über PDX	.pdx

ODX hat im Prinzip keine strengen Vorgaben für die Namensgebung der ODX-XML-Dateien formuliert. Jedoch ist es sinnvoll, die folgenden Namensvorgaben für die ODX-Dateien zu verwenden.

Tabelle ODX-Kategorien und ihre Speicherformate

Datei-Extension	ODX-Kategorie
.odx-d	DIAG-LAYER-CONTAINER
.odx-c	COMPARAM-SPEC
.odx-v	VEHICLE-INFORMATION-SPEC
.odx-m	MULTIPLE-ECU-JOB-SPEC
.odx-f	FLASH
.odx	alle ODX-Kategorien können enthalten sein (weniger restriktiv)

Bei der zweiten Methode, dem Austausch von ODX-Daten über sog. PDX-Packages, werden alle auszutauschenden Dateien in ein PDX-Package eingepackt. In der PDX-Datei können auch „Nicht-ODX-Dateien“ beliebiger Art (Texte, Bilder etc.) transportiert werden. Der Inhalt der PDX-Datei ist in einer separaten XML-Datei, dem sog. PDX package catalogue, aufgelistet. Der Katalog selbst enthält keine ODX-Daten. Er dient zur Aufnahme der Meta-Daten für den Austauschprozess. Technisch betrachtet ist ein PDX-Package ein Zip-Archiv mit der Extension .pdx.

Beispiel eines Datenaustausches mit kommerziellen Werkzeugen nach ODX

Anhand des folgenden Bildes wird die Umsetzung des ASAM MCD-Systems und seine Anwendung in an einem realem Besipiel erläutert.

Datei:Diagnosekommunikation 2005 04 17 stm 54.jpg

ODX-Austauschprozess 4

Das MCD-System besteht aus dem MCD-Laufzeitsystem und der Datenbasis nach ASAM MCD-2D (ODX). Die Datenbasis wird mit einem Werkzeug (ODX-Editor) erstellt und gepflegt. Diese Datenbasis wird für die Laufzeit zu einer binären Datenbasis durch einen Transformator aus dem XML-Austauschformat umgesetzt. Dieses geschwindigkeitsoptimierte Format kann eine auf der ASAM MCD-3D-Schnittstelle basierende Diagnose- und Analyse-Applikation, wie das DTS-Monaco, effizient einsetzen.

Terminologiezusammenfassung des ODX

Einige Fachbegriffe des ODX sind unbedingt erforderlich, damit die gesamte Fahrzeug- und Kommunikationsinformation zugeordnet werden kann.

PhysicalVehicleLink	Kommunikationskanal innerhalb des Fahrzeugs
VehicleConnector	Stecker zu den Kommunikationskanälen des Fahrzeugs
Interface	Benutzte Diagnosehardware
InterfaceConnector	Stecker der Diagnosehardware
LocalInterfaceLink	Bereitgestellte Kommunikationskanäle der Diagnosehardware
PhysicalInterfaceLink	Systemweit eindeutiger Name der LocalInterfaceLinks
PhysicalLink	Verknüpfung des PhysicalInterfaceLinks und des PhysicalVehicleLinks
LogicalLink	Logische Verbindung zwischen der Steuergerätebeschreibung in der Diagnosedatenbank und dem physischen Steuergerät
LogicalLinkTable	Die Liste aller LogicalLinks eines ASAM Projektes
VehicleInformation	Zusammenfassung der LogicalLinkTable und des VehicleConnectors

Datei:Diagnosekommunikation 2005 04 17 stm 55.jpg

Logical Link

Aus der Liste ist zu entnehmen, dass der LogicalLink der Kernbegriff für die Diagnosekommunikation mit Hilfe eines MCD-Systems ist. Der LogicalLink setzt sich aus Teil-Elementen zusammen:

• Auf der Testerseite ist das Interface, die Hardware, die den Diagnoserechner mit dem Fahrzeugstecker verbindet.
• Ein Interface hat einen eingebauten Stecker. Dieser Stecker wird InterfaceConnector genannt.
• Für die Durchführung von Diagnose sind Daten der ASAM Datenbank notwendig. Diagnoseanfragen und Diagnoseantworten sind in der Datenbank beschrieben, genau wie die Interpretationsvorschrift für Daten, die von einem Steuergerät geliefert werden. Auf der Fahrzeugseite gibt es den VehicleConnector, der die Verbindung zu den Bussystemen und Steuergeräten des Fahrzeuges bereitstellt.