Grundlagen Diagnoseprotokolle
Im Folgenden wollen wir die drei Diagnoseprotokolle OBD, UDS und das ältere KWP 2000 betrachten. Doch zunächst wichtigsten Prinzipien der Diagnoseprotokolle.
Der Abschnitt untergliedert sich wie folgt:
Allgemeines
Die Grundprinzipien sind bei allen drei Protokollen identisch, auch wenn sie sich in einigen Details voneinander unterscheiden.
|
| Diagnosekommunikation nach dem Request/Response-Verfahren |
Bei allen wird das Request/Response-Kommunikationsprinzip eingesetzt: Der Diagnosetester sendet eine Anfrage, den Request, an ein oder mehrere Steuergeräte und erhält vom Steuergerät eine positive oder negative Antwort, die Response. Innerhalb der Request-Botschaft dient das erste Byte, der so genannte Service-Identifier, der Unterscheidung der einzelnen Diagnosedienste bzw. der Aufgaben, die zu erledigen sind. Die restlichen Bytes enthalten Parameter und Daten.
|
| Aufbau der Diagnoseservices |
Um die Parameter voneinander zu unterscheiden, hat man weitere Kennziffern eingeführt. Bei OBD und KWP 2000 heißen sie Parameter-Identifier (PID) und bei UDS Level-Identifier (LEV). Das Steuergerät antwortet auf eine Diagnoseanfrage entweder mit einer positiven oder mit einer negativen Response. Die positive Response enthält im ersten Byte wiederum die SID. Hier ist jedoch grundsätzlich das Bit 6 gesetzt. Mathematisch entspricht das einer Addition von 0x40 zur SID. In den restlichen Datenbytes der Botschaft werden die PID und die Antwortdaten zurückgeschickt. Im Fehlerfall sendet das Steuergerät die so genannte negative Response zurück. Das erste Byte ist dann immer 0x7F. Das zweite Byte enthält eine Kopie der SID und das letzte Byte den so genannten Response-Code. Dieser beschreibt die Fehlerursache.
|
| Genormte Bereiche für Service IDs |
Die drei Diagnoseprotokolle unterscheiden sich in den einzelnen Diagnosediensten und deren Parametern. Erfreulicherweise hat man bei OBD und UDS darauf geachtet, dass die SID-Bereiche eindeutig gewählt werden. Für OBD ist der SID-Bereich zwischen 0x00 und 0x0F reserviert, die entsprechenden positiven Response-Botschaften haben dann einen Wert, der um 0x40 größer ist, also zwischen 0x40 und 0x4F liegt. Diese Service-IDs sind in der OBD-Norm in ISO 15031-5 und für UDS in der ISO 14229 definiert. Bei UDS ist der Bereich 0x10 bis 0x3E und für busspezifische Aufgaben der Bereich 0x83 bis 0x87 reserviert. KWP 2000 verwendet den gleichen SID-Bereich, weswegen sich UDS und KWP 2000 im selben Fahrzeugnetz leider nicht unterscheiden lassen. Schließlich gibt es noch zwei weitere SID-Bereiche: 0xA0 bis 0xB9 und 0xBA bis 0xBE, die für die Fahrzeug- und Steuergerätehersteller spezifischen Diagnosedienste reserviert sind.
|
| Typische Error Response-Codes |
Die Error-Response-Codes kennzeichnen einen Fehler. Sie sind in der Tabelle für alle drei Normen aufgeführt und weitgehend einheitlich, siehe oben. So bedeutet 0x10 einen General-Reject, d. h. einen allgemeinen, nicht weiter spezifizierten Fehler. Die Response-Codes 0x11 und 0x12 zeigen an, dass ein bestimmter Dienst oder eine bestimmte Unterfunktion durch das Steuergerät nicht unterstützt werden. 0x13 bedeutet, dass das Botschaftsformat nicht korrekt ist und 0x31 bedeutet, dass zwar der Diagnosedienst prinzipiell unterstützt wird, aber bei irgendeinem Parameter der Wertebereich überschritten wurde. Des Weiteren gibt es einige Diagnosedienste, die zur Ausführung längere Zeit benötigen. Dort kann das Steuergerät über die Response-Codes 0x21 (Busy-Repeat) und 0x78 (Response-Pending) dem Tester mitteilen, dass es noch etwas Zeit zur Lieferung der Antwortbotschaft benötigt. Im Fall von 0x21 muss der Tester die Anfrage wiederholen. Im Fall von 0x78 muss der Diagnosetester warten, bis das Steuergerät die eigentliche Antwort sendet.
Adressierungsarten
Eine weitere Gemeinsamkeit der drei Diagnoseprotokolle ist die Adressierung von Diagnosetestern und Steuergeräten. Im einfachsten Fall wird die so genannte physikalische Adressierung eingesetzt. Dabei haben der Diagnosetester und das einzelne Steuergerät ein eindeutiges Paar von Adressen. Im Fall von CAN werden die Adressen über CAN-IDs abgebildet: Mit einer CAN-ID sendet der Tester seine Botschaften (Requests) an das entsprechende Steuergerät, mit einer anderen schickt das Steuergerät seine Antwort (Response) zurück an den Diagnosetester.
Die so genannte funktionale Adressierung hat man für die Fälle eingesetzt, in denen der Diagnosetester nicht genau weiß, welche und wie viele Steuergeräte im Fahrzeug verbaut sind. Sie gilt nur vom Tester zu den Steuergeräten. In der umgekehrten Richtung – von den Steuergeräten zum Tester – wird immer die physikalische Adressierung verwendet. Bei dieser Adressierung gibt es eine Adresse für eine ganze Gruppe von Steuergeräten und deshalb muss der Diagnosetester damit rechnen, dass auf eine einzelne Request-Anfrage mehrere Steuergeräte mit einer Response-Botschaft antworten. In der Regel haben Steuergeräte daher zwei Adressen. Eine physikalische und optional eine funktionale Adresse.
|
| Adressierungsarten – funktionale & physikalische Adressierung |
Das Prinzip soll an einem Beispiel mit einem Diagnosetester und zwei Steuergeräten verdeutlicht werden, siehe Bild oben. Die angegebenen CAN-IDs stammen aus der OBD-Norm. Dort sind diese vom Gesetzgeber vorgegeben. Während bei der allgemeinen Fahrzeugdiagnose (UDS) die CAN-IDs herstellerspezifisch gewählt werden dürfen. Der Diagnosetester stellt eine Anfrage und weil er nicht genau weiß, welche Steuergeräte im Fahrzeug verbaut sind, verwendet er die funktionale Adressierung. Bei OBD ist die funktionale Adresse für abgasrelevante Steuergeräte – für einen 11 Bit CAN-Identifier – auf 0x7DF festgelegt. Wir nehmen nun an, dass auf diese Adresse zwei Steuergeräte antworten: ECU 1 und ECU2. Die Steuergeräte antworten jeweils mit einer eindeutigen physikalischen CAN-ID. Die OBD-Norm legt fest, dass für die Antwort des Steuergerätes 1 die Adresse 0x7E8 und für das Steuergerät 2 die Adresse 0x7E9 verwendet werden müssen. Danach möchte der Diagnosetester gezielt eine Anfrage an das Steuergerät 2 richten. Damit das Steuergerät 1 oder andere Steuergeräte nicht antworten, verwendet er die eindeutige physikalische Adresse des Steuergerätes 2 – in der OBD-Norm mit 0x7E1 festgelegt – und bekommt so nur von diesem eine Antwort – nämlich mit der physikalischen Adresse 0x7E9, derselben, mit der es auch auf die funktional adressierte Anfrage geantwortet hat.
Da OBD versucht, weitgehend bussystemunabhängig zu sein, werden die funktionalen und physikalischen Adressen nicht in der OBD-Norm, sondern in der ISO 15765-4 (Diagnose über CAN) beschrieben. Die Adressen unterscheiden sich, je nachdem ob 11 Bit oder 29 Bit CAN-Identifier eingesetzt werden, siehe Tabelle.
|
| Für OBD-relevante Geräte sind die Adressen in ISO 15765-4 fest vorgegeben |
Die Geräteadressen werden bei KWP 2000 (K-Line) und bei FlexRay in den ersten Bytes der Nutzdatenbotschaft übertragen. Bei CAN gibt es zusätzlich zur normalen noch die erweiterte Adressierung. Hier wird das erste Datenbyte der Botschaft mit zur Adressierung verwendet. Das heißt, der Nutzdatenteil wird noch mal etwas reduziert. Aus diesem Grund versucht man, die erweiterte Adressierung zu vermeiden.
Weiterhin sind noch die Timeouts (Zeitbedingungen) von Bedeutung. Bei CAN müssen die Steuergeräte typischerweise innerhalb von 50 Millisekunden antworten. Das ist vor allem bei der funktionalen Adressierung zu beachten. Da der Diagnosetester nicht weiß, wie viele Steuergeräte auf seine Anfrage antworten, muss er grundsätzlich bis zum Timeout, also 50 Millisekunden abwarten, bevor er die nächste Diagnoseanfrage stellen kann. Dies könnte beispielsweise bei 50 im Fahrzeug verbauten Steuergeräten einige Sekunden dauern. Bei der physikalischen Adressierung dagegen kann er, sobald er eine Antwortbotschaft erhalten hat, sofort die nächste Diagnoseanfrage versenden.
Sicherheitskonzept – Diagnosesitzungen
Bei OBD gibt es kein Sicherheitskonzept. Das ist insoweit unkritisch, als die OBD-Diagnosedienste Daten aus dem Steuergerät nur auslesen können. Der einzige Diagnosedienst, der hier den Steuergeräteinhalt verändert, ist der Dienst, der den Fehlerspeicher löscht.
Bei UDS und KWP 2000 dagegen gibt es eine ganze Reihe von Diensten, mit denen Steuergeräteinhalte manipuliert werden könnten. Deswegen gibt es dort ein Sicherheitskonzept, das den unbeschränkten Zugriff auf das Steuergerät verhindert.
|
| Sicherheitskonzept - Diagnosesitzungen |
Normalerweise befindet sich ein Steuergerät in der so genannten Default-Diagnostic-Session, siehe Abbildung. Hier ist nur ein kleiner, unkritischer Teil der Diagnosedienste verwendbar, und nur ein kleiner Teil der Messwerte und Steuergerätedaten kann gelesen werden. Geschrieben werden kann eigentlich gar nicht. Sollte einer der Diagnosedienste notwendig werden, mit denen kritische Messdaten gelesen oder gar geschrieben werden können, dann muss in eine spezielle Diagnostic-Session umgeschaltet werden. Dafür gibt es bei UDS den Diagnosedienst StartDiagnosticSession. Typischerweise gibt es verschiedene Diagnosesitzungen mit unterschiedlichen Gruppen von Diagnosediensten, wie beispielsweise die Programming-Session (zur Flash-Programmierung) und die Extended-Diagnostic-Session (innerhalb der Werkstatt für die Nachjustierung verschiedener Parameter). Beim Umschalten von der Default-Session in eine spezielle Session ist in der Regel eine bestimmte Login-Prozedur notwendig, so genannter Security-Access, siehe nächster Abschnitt. Die Non-Default-Session bleibt nur dann erhalten, wenn der Diagnosetester regelmäßig Diagnoseaufforderungen an das Steuergerät sendet. Ansonsten startet, sobald die Non-Default-Session betreten wurde ein Timer. Wenn dieser ins Timeout geht, fällt das Steuergerät automatisch wieder in die Default-Session mit dem eingeschränkten Diagnoseumfang zurück.
Security Access
Die Login-Prozedur, der so genannte Security-Access verwendet ein Seed-and-Key Verfahren: Der Diagnosetester fordert den Security-Access mit einer Request-Security-Access-Botschaft an. Sie sehen in der folgenden Abbildung symbolisch die SID und die notwendigen Parameter.
|
| Security Access – „Seed & Key“ Verfahren |
Mit dieser Anfrage fordert der Diagnosetester eine so genannte Seed vom Steuergerät an. Dies ist einfach eine im Steuergerät generierte Zufallszahl. Sie dient dem Diagnosetester als Initialisierungswert für einen geheimen Algorithmus, mit dem er den Key (Schlüssel) berechnet. Der Key wird dann an das Steuergerät zurückgeschickt. Das Steuergerät berechnet parallel dazu mit demselben Algorithmus ebenfalls den entsprechenden Key und vergleicht den vom Diagnosetester Gelieferten mit dem selbst Berechneten. Stimmen beide Keys überein, erlaubt das Steuergerät dem Diagnosetester den Zugang zur gewünschten Diagnose-Session und antwortet mit einer positiven Response.
Siehe auch
