Diagnoselayer und Diagnosedienste
DIAG-LAYER-CONTAINER
Wir wollen nun die Containerelemente der ODX-Struktur beschreiben und beginnen mit dem wichtigsten Containerelement, dem DIAG-LAYER-CONTAINER. Er ist Bestandteil jeder ODX-Bedatung und enthält sämtliche Diagnosedienste und Diagnoseabläufe eines Steuergerätes inklusiv der dazugehörigen Daten. Der DIAG-LAYER-CONTAINER selbst ist unterteilt in hierarchische Schichten, die sogenannten DIAG-LAYER, deren Zusammenhang wir uns auf der folgenden Abbildung veranschaulichen wollen.
|
| DIAG-LAYER-CONTAINER – Vererbung |
Ganz oben haben wir den sogenannten PROTOCOL-LAYER. Der PROTOCOL-LAYER beschreibt das generische Diagnoseprotokoll, das verwendet werden soll. Zum Beispiel UDS oder KWP 2000. Dann haben wir den BASE-VARIANT Diagnose-Layer. Der BASE-VARIANT Diagnose-Layer beschreibt eine bestimmte Geräte-Familie, zum Beispiel ein Türsteuergerät, von dem es typischerweise mehrere Varianten gibt, zum Beispiel ein Türsteuergerät für die Fronttüren, ein anderes Türsteuergerät für die Hecktüren. Diese Varianten werden in der sogenannten ECU-VARIANT Diagnose-Schicht beschrieben. Häufig ist es dabei sinnvoll, bestimmte Diagnosedienste zu gruppieren. Zum Beispiel in Dienste, die die Flash-Programmierung betreffen, in Dienste, die bestimmte Werkstatttestabläufe beschreiben etc. Das leistet der sogenannte FUNCTIONAL-GROUP-LAYER. Und schlussendlich Funktionen und Daten, die übergeordnet und in mehreren Projekten verwendet werden können, fasst man in der Regel im ECU-SHARED-DATA-LAYER zusammen. Dieser ECU-SHARED-DATA Container stellt eine Art Bibliothek dar. Zu den Kernkonzepten von ODX gehört es, Daten nur einmalig definieren zu müssen und dann innerhalb desselben Projekts oder in anderen Projekten einfach wiederzuverwenden. Dadurch wird die Datenmenge insgesamt reduziert und die Datensicherheit vergrößert, da immer nur Änderungen gegenüber einem Referenzdatensatz beschrieben werden müssen. Die ECU-SHARED-DATA Bibliothek ist dabei eine erste Möglichkeit, solche Daten wiederzuverwenden. Im Bereich ECU-SHARED-DATA definierte Daten, können von anderen Schichten importiert und somit verwendet werden. Das Importieren erfolgt durch ein Referenzieren, das heißt, innerhalb des PROTOCOL-LAYERS kann zum Beispiel ein Element aus der Bibliothek ECU-SHARED-DATA verwendet werden, indem im PROTOCOL-LAYER auf dieses Element verwiesen wird.
Referenzen und Vererbung
Für diese Referenzen kennt ODX zwei verschiedene Möglichkeiten, die wir nachfolgend betrachten wollen.
Zum einen ist der Verweis über die ID möglich. Sie haben vorher gesehen, jedes ODX-Element kann eine ID bekommen. Ein Verweis erfolgt, indem man in einem Element über einen ODX-LINK (ID-REF) auf die ID des anderen Elementes verweist. Die zweite Möglichkeit besteht darin, über den SHORT-NAME auf ein anderes Objekt zu verweisen. Das ist die sogenannte SHORT-NAME-REF (SN-REF).
Beim Importieren von Daten aus der ECU-SHARED DATA Bibliothek können die importierten Daten nicht verändert werden. Dies macht für häufig verwendete Bibliotheken, sie sich kaum ändern, Sinn. Eine leistungsfähigere Möglichkeit, Daten wiederzuverwenden, ist jedoch das Vererben.
Das Vererben ist ein Grundkonzept der Informatik. Beim Vererben definiert man auf einer höheren der so genannten Parent-Schicht, im Beispiel hier Protocol-Layer, Dienste und Daten in generischer Form. Die darunter liegenden Schichten, zum Beispiel der BASE-VARIANT Layer, erben diese Dienste. Das heißt, sie können alle Dienste, die auf der höheren Schicht definiert wurden, ebenfalls verwenden. Dies bezeichnet man als Erben. Die darunter liegenden Schichten können diese Dienste aber auch modifizieren. Beispielsweise können bei einzelnen Diensten andere Implementierungen, andere Parameter etc. nötig sein. Dies bezeichnet man als Überschreiben. Weiterhin kann auch die Verwendung einzelner Dienste oder Daten ausgeschlossen werden. Dies bezeichnet man als Enterben.
Praktisch erfolgt das Vererben durch Referenzen. Die zu erbende Schicht referenziert auf die Schicht, von der sie erben will. Im Unterschied zum Import, wo auf ein einzelnes Datenelement verwiesen wird, wird beim Erben auf eine ganze höher gelegene Schicht verwiesen. Das Überschreiben eines Elementes ist geschieht, in der man in der Schicht, die überschreiben möchte, ein gleiches Element mit dem gleichen SHORT-NAME definiert.
Die Sichtbarkeit der Elemente hängt davon ab, welche Verweise gewählt werden, ob mit ODX-LINK oder mit SHORT-NAME referenziert wird. Das Enterben, das heißt, das Unsichtbar-Machen geerbter Elemente, erfolgt mit einem speziellen Attribut, dem NOT-INHERITED-SHORT-NAME-REF Attribut.
Das Vererben und Enterben ist sehr leistungsfähig, was die Wiederverwendung der Daten angeht. Es ist allerdings auch fehlerträchtig, weil nicht immer eindeutig klar ist, welche Elemente auf welcher Ebene definiert werden.
Schauen wir uns nun zum Thema Vererben und zum Thema Sichtbarkeit beim Vererben verschiedene Beispiele an. Ein erstes Beispiel, in dem es drei verschiedene Schichten gibt, A, B und C. A ist die hierarchisch höchste, C die hierarchisch niedrigste Schicht. Innerhalb der höchsten Stufe A werden 2 Objekte definiert, Objekt O1 und Objekt O2, wobei das Objekt O1 über eine Short-Name-Reference auf das Objekt O2 referenziert. O1 sei zum Beispiel ein Diagnosedienst, O2 sei ein bestimmter Parameter dieses Diagnosedienstes. Die Schicht B erbt nun von dieser Schicht A, das heißt die Objekte O1 und theoretisch auch O2 sind in der Schicht B genauso verfügbar. Da die Schicht B allerdings den Parameter O2 umdefinieren möchte, definiert sie einen eigenen, von O2 abgeleiteten Parameter O2`. Das Objekt O1 in der Schicht B ist von der Schicht A geerbt und wird dort nicht verändert. Durch die Short-Name-Reference referenziert nun das Objekt O1 in der Schicht B, nicht O2, das es ja gar nicht geerbt hat, weil es ja überschrieben wurde, sondern referenziert das Objekt O2`. Das gleiche sehen wir nochmals auf der Schicht C. Die Schicht C erbt von der Schicht B. Diese wiederum von der Schicht A, das heißt das Objekt O1 ist auch in der Schicht C verwendbar. Das Objekt O2` würde die Schicht C theoretisch von der Schicht B erben (nicht O2), möchte das aber ebenfalls als O2`` selbst definieren. Die SHORT-NAME-REF von Objekt O1 zeigt nun in der Schicht C auf das Objekt O2``. Das heißt die SHORT-NAME-REF bleibt innerhalb derselben Schicht. Wenn dort ein Element überschrieben wird, zeigt die SHORT-NAME-REF auf das überschriebene Element in derselben Schicht.
|
| Referenzen und Vererbung – SHORT-NAME-REF (SN-REF) |
Schauen wir uns nun dieselbe Struktur mit den drei hierarchischen Ebenen A, B und C und den beiden Elementen O1 und O2 innerhalb einer Schicht an, wenn statt des Verweises über den SHORT-NAME ein Verweis über die ID, ein sogenannter ODX-Link, verwendet wird. In der Ebene A liegen wiederum die Objekte O1 und O2, wobei jetzt O1 auf O2 über einen ODX-Link verweist. In der Schicht B wiederum wird das Objekt O1 unverändert geerbt, während das Objekt O2 durch ein Objekt O2` überschrieben wird. Nun verweist das Objekt O1 in der Schicht B auf das Objekt O2, aber nicht in der Schicht B, sondern in Schicht A, auf dasselbe O2, auf das das O1 in A auch verwiesen hat. Grund: O2 und O2` haben unterschiedliche IDs. In Schicht C sieht es genauso aus: O1, das ja letztlich von A geerbt wurde, verweist in C immer noch auf die ID von O2 in A. Die überschriebenen Objekte O2` und O2`` in den Ebenen B und C sind zwar definiert, aber das O1-Objekt verwendet sie nicht, sondern verwendet immer noch das O2 aus A.
|
| Referenzen und Vererbung – OTX-LINK oder ID-REF |
Wir empfehlen daher bei Verweisen, grundsätzlich SHORT-NAMES zu verwenden, da SHORT-NAMES das Objekt in derselben Schicht referenzieren und Alle Änderungen somit automatisch übernommen werden. Den ODX-Link sollten Sie nur dann verwenden, wenn Sie bewusst auf ein eindeutiges Objekt in einer anderen Schicht verweisen möchten!
Enterben
Schauen wir uns als drittes Beispiel das Enterben an. Auch hier wieder 3 Ebenen. Die Ebenen A, B und C. A ist hierarchisch wieder die oberste Ebene. Dort ist ein Objekt O3 definiert. Die Ebene B erbt von der Ebene A, das Objekt O3 ist in der Ebene B ebenfalls sichtbar und verwendbar. Ebene B definiert selbst noch zwei weitere Objekte O1 und O2. Die Ebene C erbt ihrerseits wieder von B. Das heißt, die Objekte O1 und O2 wären dort sichtbar. O2 allerdings wird in C mit O2` überschrieben. Das Objekt O3 erhält auf C das NOT-INHERITED Attribut. Es ist somit auf der Ebene C weder sicht- noch verwendbar.
|
| Referenzen und Vererbung – Enterben |
DIAG-COMM-PRIMITIVES
DIAG-COMM-PRIMITIVES beschreiben die Diagnosedienste innerhalb des DIAGNOSTIC-LAYERs. Dafür gibt es das ODX-Beschreibungselement DIAG-SERVICE, das drei Unterelemente enthält. Einen REQUEST, eine oder mehrere positive Antwortbotschaften (POS-RESPONSE) und eine oder mehrere negative Antwortbotschaften (NEG-RESPONSE). Diese Elemente verweisen ihrerseits wieder auf Parameter. Die Parameter können wiederum sogenannte DATA-OBJECT-PROPERTIES (DOP), das sind Umrechnungsmethoden, enthalten und diese weiterhin können auf entsprechende physikalische Einheit verweisen, so genannte UNITS.
Abläufe, die die Ausführung mehrerer Diagnosedienste hintereinander, insbesondere in Abhängigkeit von Antwortdaten eines Dienstes erfordern, lassen sich als Makros, als sogenannte SINGLE-ECU-JOBS in ODX definieren. SINGLE-ECU-JOBS sind Java-Programme, das heißt das Datenelement in der ODX-Struktur verweist auf ein Java-Programm. In der ODX-Datenstruktur muss definiert werden, welches Java-Programm für diesen Ablauf aufzurufen ist, welche Parameter hineingehen, welche Parameter herausgehen und welche Rückgabewerte im Fehlerfall geliefert werden (INPUT-PARAMS, OUTPUT-PARAMS und NEG-OUTPUT-PARAMS). Die Detailbeschreibung der Parameter selbst erfolgt wieder über DATA-OBJECT-PROPERTIES mit den entsprechenden Einheiten (UNITS).
|
| Diagnostic Communication Primitives (DIAG-COMMS) |
ODX unterscheidet verschiedene Parametertypen, siehe Tabelle. Wir haben hier unter anderem die kodierten Konstanten (CODED-CONST). Dies sind beispielsweise SIDs, also fixe hexadezimale Zahlenwerte. Weiterhin gibt es Parameter, die einen physikalischen Wert darstellen, die PHYS-CONST.
Die eigentlichen Zahlenwerte (VALUE) verweisen immer auf das entsprechende DATA-OBJECT-PROPERTY, siehe unten und dann haben wir noch komplexe Parameterstrukturen, die über Tabellen beschrieben werden. Die Tabellen bestehen dabei aus einem Schlüssel, mit dem die Tabelle indiziert wird und der eigentlichen Datenstruktur. Diese enthält die entsprechenden Tabelleneinträge.
|
| Parameter-Typen für DIAG-SERVICES |
DATA-OBJECT-PROPERTY (DOP)
DOPs enthalten alle notwendigen Angaben, um die von einem Diagnosedienst gelieferten oder mit einem Diagnosedienst zu sendenden Daten für den Menschen interpretierbar zu machen. Wir unterscheiden zwei Arten von DOPs. Die einfachen SIMPLE-DOPs, die einen einzelnen Datenwert beschreiben und die COMPLEX-DOPs, die Strukturen von Datenwerten definieren. Ein DOP definiert im Wesentlichen die Umrechnungsmethode zwischen dem kodierten Wert, wie er letztlich ans Steuergerät übertragen wird und der physikalischen Größe.
|
| DATA-OBJECT-PROPERTY (DOP) |
Folgende Daten werden im DOP gespeichert:
- COMPU-METHOD
- Umrechnungsmethode zw. kodierten Wert und der physikalischen Größe
- Umrechnungsmethode zw. kodierten Wert und der physikalischen Größe
- DIAG-CODED-TYPE
- Datentyp des kodierten Wertes eines Parameters
- Datentyp des kodierten Wertes eines Parameters
- PHYSICAL-TYPE
- Datentyp des physikalischen Wertes eines Parameters
- Datentyp des physikalischen Wertes eines Parameters
- INTERNAL-CONSTR
- Gültigkeitsintervalle für den Parameter im kodierten Format
- Gültigkeitsintervalle für den Parameter im kodierten Format
- UNIT-REF
- Referenz zur physikalischen Einheit des Parameters
- Referenz zur physikalischen Einheit des Parameters
- PHYS-CONSTR
- Gültigkeitsintervalle für den physikalischen Parameter
- COMPU-METHOD
Umrechnungsmethoden (COMPU-METHOD)
ODX stellt eine Vielzahl von Umrechnungsmethoden für Datenobjekte bereit, siehe Abbildung. Für Fehler zum Beispiel verwendet man häufig die Texttable, mit der einem Fehlercode, der typischerweise hexadezimal kodiert ist, ein Klartext zugeordnet werden kann. Viele Werte sind überhaupt nicht kodiert, das heißt, der physikalische und der kodierte Wert sind identisch. Hier setzt man die Umrechnungsmethode Identical ein. Viele Sensorwerte verwenden eine lineare Zuordnung mit Steigung und Offset, die Linear Umrechnungsmethode. Mit Scale-Linear gibt es auch eine stückweise lineare Umrechnung, indem man eine Kennlinie durch stückweise lineare Funktionen beschreibt. Nahezu beliebige Funktionen lassen sich über den Quotienten zweier Polynome mit der Rat-Func Umrechnungsmethode abbilden. Wenn das alleine nicht reicht, kann man solche Quotienten von rationalen Funktionen auch stückweise zusammensetzen, siehe Scale-Rat-Func. Dann haben wir die üblichen Kennlinien, die linear interpretiert werden: Tab-Interp und Umrechnungsmethoden, die so komplex sind, dass man sie in Programme auslagern muss. Dafür besteht die Möglichkeit des Compucodes, der auf ein externes Java-Programm verweist, das diese Umrechnung dann durchführt.
|
| Umrechnungsmethoden (COMPU-METHOD) |
Datentypen für DOPs (Diag-Coded-Types)
Auch bei den Datentypen erweist sich ODX als recht flexibel. Für kodierte Datentypen gibt es beispielsweise den Standard-Length-Type. Wenn der Wert eine feste Länge hat, dann definiert man in der DOP die Anzahl der Bits die notwendig sind, um den Zahlenwert darzustellen. Für Daten, bei denen die Länge in einem bestimmten Bereich variiert, gibt es den Min-Max-Length-Type. Dort müssen in der ODX-Beschreibung die minimale, die maximale Bit-Länge und eine Ende-Kennzeichnung für den Datenwert angeben werden. Das ist eine typische Beschreibungsform für Strings, die typischerweise mit 0 als letztem Byte abgeschlossen werden. Bei manchen Diagnosediensten ist die Länge der Daten Teil der Antwortbotschaft. Dafür eignet sich der Leading-Length-Info-Type. Und nicht zuletzt gibt es noch den Param-Length-Info-Type. Das ist ein Datentyp für Daten, deren Länge durch einen anderen Datenwert beschrieben wird. Das heißt, es gibt einen Datenwert, der die Länge enthält und einen weiteren Datenwert, der dann die eigentlichen Werte beinhaltet. Das ist zum Beispiel bei der Ablage des Fehlerspeichers üblich. Sie erinnern sich an die Botschaft, mit der man die Anzahl der Fehler lesen konnte. Die ist aus ODX-Sicht ein Parameter, die Fehlercodes sind dann der zugehörige Datenwert.
|
| Datentypen für DOPs (DIAG-CODED-TYPES) |
Komplexe Datenelemente (Complex-DOP)
Wo einfache Datenelemente nicht ausreichen, lassen sich Complex-DOPs einsetzen. COMPLEX-DOPs sind aus einfachen Datenobjekten zusammengesetzte Strukturen. Sie werden u. a. verwendet, wenn die Art und Zusammensetzung der Parameter erst zur Laufzeit bestimmt werden kann. Ein typischer Anwendungsfall ist die Beschreibung des Fehlerspeichers. Er besteht aus Fehlercodes und sogenannten Freeze-Frames (Umgebungsdaten des Fehlers).
Mit den Multiplexer-Elementen MUX, stellt ODX eine Möglichkeit bereit, innerhalb der ODX-Daten eine Art Verzweigung zu implementieren. Das ist zum Beispiel sinnvoll, wenn man eine Messdatenanfrage abgeschickt hat und die Bearbeitung der Antwortbotschaft abhängig von den PIDs, die in der Antwort enthalten sind, erfolgen muss. Das kann über ein MUX-Element gelöst werden. Das MUX-Element selbst verzweigt dann auf verschiedene einfache DOPs oder Strukturen. Strukturen ihrerseits können einfach sein, sie können aber auch als Arrays mit einer festen oder einer dynamischen Anzahl wiederholt werden.
|
| COMPLEX-DOPs sind aus einfachen Datenobjekten zusammengesetzte Strukturen |
Variantenidentifikation
ODX kann verschiedene Varianten eines Steuergerätes handhaben. Aufgrund derselben physikalischen Adresse (PHYSICAL-VEHICLE-LINK), kann zur Laufzeit immer nur eine Variante aktiv sein (BASE-VARIANT oder ECU-VARIANT). Bevor eine Variante selektiert werden kann, wird normalerweise über das Diagnoselaufzeitsystem die jeweilige Basis-Variante ausgewählt. Jedes Steuergerät besitzt eine Identifikation, welches das Steuergerät und seine jeweilige Variante eindeutig beschreibt. Das Laufzeitsystem versendet nun ein oder mehrere Diagnoseservices (z.B.: ReadECUIdentification) welche im ECU-VARIANT-PATTERN-Element der ECU-VARIANT definiert sind und vergleicht die Antworten vom Steuergerät mit den ebenfalls dort konfigurierten Antworten (MATCHING-PARAMETERS). Stimmen dies überein, wurde die Variante korrekt erkannt. Normalerweise schaltet das Laufzeitsystem nun direkt auf diese Variante um, d. h. es ist nicht mehr die Basis-Variante sondern die ECU-Variante ausgewählt.
Siehe auch
