OBD on CAN
Die Abgasgesetzgebung und mit ihr einhergehend die On-Board-Diagnose für abgasrelevante Systeme hat eine lange Historie. Bereits 1970 beschloss der amerikanische Kongress nach Vorarbeiten insbesondere in Kalifornien den Clean-Air-Act, die erste Gesetzgebung, die die Abgasemission von Autos massiv regelt. Gleichzeitig wurde die Environmental Protection Agency (EPA) mit der Zielsetzung gegründet, die Abgasgesetze zu überwachen und weiterzuentwickeln. In der Folge kam es zur Einführung des Katalysators, der elektronischen Zündung und der elektronischen Benzineinspritzung in Verbindung mit der Lambda-Sonde.
Geschichte On Board Diagnose |
Sehr früh wurde klar, dass die elektronischen Maßnahmen zur Verbesserung des Abgases auch einer Diagnose und einer Diagnoseschnittstelle bedürfen. 1982 implementierte GM zum ersten Mal eine damals noch proprietäre Schnittstelle für die On-Board-Diagnose. Und 1987 wurde diese Schnittstelle zusammen mit einer Reihe von weiteren Vorschriften zur Überwachung des Emissionsverhaltens für Neufahrzeuge in den USA eingeführt. Anfangs durch die kalifornische Umweltbehörde, das Californian-Air-Resources-Board (CARB) und später durch die EPA für die gesamten Vereinigten Staaten. 1996 /97 wurden die Vorschriften weiter präzisiert und verschärft. Man spricht bei dieser zweiten Generation von OBD II.
In Europa hinkte die Entwicklung etwas hinterher. Im Jahr 2000 für das Modelljahr 2001 wurde die europäische Variante der On-Board-Diagnose eingeführt. Sie läuft dort unter dem Namen JOBD. Im Jahr 2000 wurde für Benzinfahrzeuge in Europa die entsprechende Regelung aus USA weitgehend übernommen. Für Dieselfahrzeuge wurde das erst in den Jahren 2003/ 04 verbindlich.
Aufgaben der OBD
- Ständige Überwachung aller abgasrelevanten Komponenten
- Erfassen Emissionserhöhungen während der Laufzeit
- Gewährleistung niedriger Abgasemissionen
- Schutz von Komponenten, z.B. Katalysator bei Fehlzündungen
- Meldung von abgasrelevanten Fehlern an den Fahrer
- Speichern von Fehlern
- Bereitstellung einer Diagnoseschnittstelle
Was sind nun die Aufgaben der On-Board-Diagnose? Zum einen die Überwachung abgasrelevanter Komponenten. Die OBD-Regeln schreiben hier vor, dass Emissionserhöhungen ab einem gewissen Grenzwert während der Laufzeit des Fahrzeugs erkannt werden müssen. Das soll gewährleisten, dass die Abgasemissionen nicht nur bei der Typzulassung, sondern über die gesamte Lebensdauer realer Fahrzeuge niedrig bleiben. Weiterhin Maßnahmen zum Schutz von Komponenten. Bei Benzinmotoren werden beispielsweise Katalysatoren durch Fehlzündungen relativ rasch zerstört. Hier schreibt die On-Board-Diagnose Maßnahmen zur Überwachung vor, die diese Zerstörung und damit das Unwirksamwerden des Katalysators verhindern soll. Die erkannten Fehler müssen dem Fahrer mitgeteilt werden. Dazu gibt es im Armaturenbrett eine Anzeigelampe, die so genannte Malfunction-Indicator-Lamp, kurz MIL. Die Fehler müssen in den Steuergeräten gespeichert werden. Und dieser Speicher muss über eine entsprechende Diagnoseschnittstelle für den Werkstatttester zugänglich gemacht werden. Die sichtbarste Konsequenz der Einführung der OBD-Regelungen ergab sich beim Diagnosestecker, obwohl es lange vorher bereits Diagnoseschnittstellen in allen Fahrzeugen gab, hatte lange Zeit jeder Hersteller seine proprietäre Anschlusstechnik. Bei OBD regelt dies die ISO 15031-3 beziehungsweise die inhaltsgleiche amerikanische Norm SAE J1962.
OBD-Diagnosestecker nach ISO 15031-3 bzw. SAE J1962 |
Wie der Diagnosestecker auszusehen hat, sehen Sie im Bild oben. Worauf man sich in der Praxis verlassen kann ist der Einbauort in der Umgebung des Fahrers, also nicht im Motorraum, sondern im Fahrgastraum und die minimale Steckerbelegung mit Batteriespannungsanschlüssen und Masse. Sie sehen auch die von der Norm vorgeschlagene Belegung für die drei verschiedenen Schnittstellen: Die K-Line für Europa, SAE J1850 für die amerikanischen Fahrzeuge und seit 2007 /08 ist sowohl in USA als auch in Europa CAN verbindlich.
Allgemeines zur Diagnoseschnittstelle
Die Diagnosedienste der On-Board-Diagnose werden durch ISO 15031 im Teil 5 beziehungsweise die weitgehend inhaltsgleiche Norm SAE J1979 definiert. Diese beiden Normen sind zunächst unabhängig vom Bussystem. Die bussystemspezifischen Regularien für CAN werden in ISO 15765, dort im Teil 4 beschrieben.
Die Vorgaben dabei sind bei CAN, dass das ISO-Transportprotokoll eingesetzt werden muss, dass die CAN-Bit-Raten entweder 250 kbit/s oder 500 kbit/s betragen müssen und dass entweder 11 Bit oder 29 Bit Can-Identifier unterstützt werden müssen. Das bedeutet, dass ein Steuergerät eine der beiden Bit-Raten oder eine der beiden Identifier-Längen verwenden muss. Ein Diagnosetester muss jedoch beide Bit-Raten und beide Identifier-Längen unterstützen und automatisch erkennen, mit welcher Bitrate das Steuergerät arbeitet. Außerdem wird vorgeschrieben, dass beim ISO-Transportprotokoll die Flusssteuerung stets eine Blockgröße von Null und eine minimale Separation-Time ebenfalls von Null verwendet. Für die Diagnose-Requests wird eine funktionale Adressierung für den Diagnosetester vorgeschrieben und dabei muss für 11 Bit CAN-IDs die CAN-ID 0x7DF verwendet werden.
Steuergeräte, die eine OBD-Anfrage an bestimmte Diagnosedienste nicht unterstützen, sollen, um die Buskommunikation zu entlasten, nicht mit einer negativen Botschaft antworten.
Zulässige Diagnose-Requests, sgn. „Test Modes“ |
Die zulässigen Diagnosedienste (Diagnose-Requests), bei SAE „Test-Modes“ genannt, sind in obiger Tabelle aufgelistet. Sie sind relativ überschaubar. Es gibt eine Gruppe von zwei Diagnosediensten, die dem Auslesen von Mess- und Fahrzeugdaten dienen. Mit der Service-ID 0x01 kann man Messdaten abfragen. Welche, wird über zusätzliche Parameter-Identifier spezifiziert, siehe folgendes Beispiel. Mit der Service-ID 0x09 kann man allgemeine Fahrzeuginformationen, zum Beispiel die Fahrgestellnummer, Software- oder Hardwarevariantennummern der Steuergeräte abfragen. Dann gibt es eine Gruppe von Diensten, die den Fehlerspeicher betreffen. Mit dem Dienst 0x03 kann man Fehlercodes auslesen, mit dem Dienst 0x02 Messdaten, die beim Auftreten eines Fehlers im Steuergerät gespeichert wurden, so genannte Freeze-Frames. Und nicht zuletzt kann man mit Dienst 0x04 den Fehlerspeicher löschen.
Dann schreibt die OBD-Norm eine Reihe von Testverfahren vor, zum Beispiel um die Tankentlüftung zu testen, um den Katalysator, um die Funktion der Lambda-Sonde zu testen und Ähnliches. Mit den Diensten 0x06, 0x07 und 0x08 werden entsprechende Diagnosedienste spezifiziert, die solche Tests und Überwachungen ausführen beziehungsweise abfragen.
Erstes Beispiel: Messdaten lesen
Als erstes Beispiel wollen wir uns den Diagnosedienst 0x01, den Dienst mit dem man Messdaten auslesen kann etwas genauer anschauen.
Auszug aus ISO 15031-5 |
Dazu werfen wir einen Blick in die ISO-Norm. In der Tabelle 127 der Norm wird der Diagnosedienst 0x01 genauer beschrieben, siehe Bild oben. Sie sehen hier in der ersten Zeile die Bezeichnung des Dienstes und Sie sehen hier in dieser Spalte ein M stehen. M steht für Mandatory, also „verbindlich“, und hier einen hexadezimalen Wert 01. Das heißt, wenn man den Diagnosedienst benutzt, muss man in jedem Fall den hexadezimalen Wert 01 als erstes Byte der Botschaft schicken. Das ist die SID. Dann folgt die PID. Sie sehen auch in der zweiten Zeile ein M für Mandatory und in den folgenden Zeilen ein U für User-Defined, also eine beliebige Anzahl von weiteren PIDs. Man kann also mit diesem Diagnosedienst einen oder mehrere Messwerte abfragen. Welche Messwerte dabei zur Verfügung stehen und wie diese formatiert sind, steht in einer anderen Tabelle im sogenannten Appendix-B. Dort in der Tabelle B.6 sind die PIDs für den Dienst 01 definiert. Hier finden wir unter anderem die PID 05. Die PID 05 erlaubt es uns, die Engine-Coolant-Temperature, also die Motortemperatur auszulesen. Das entsprechende Datenformat lautet wie folgt: Wir haben ein Byte, welches den Wertebereich von -40°C bis +215°C beinhaltet. Wir haben demnach eine Auflösung von 1°C mit einem Offset von -40°C.
Die Response wird in der Tabelle 128 beschrieben, siehe Bild oben. Dort sieht man, dass der hexadezimale Wert 41 als erstes Byte zurückgeliefert werden muss. Das entspricht der SID, bei der das Bit 6 gesetzt ist, also einer um 0x40 erhöhten SID von 0x01. Das gibt genau 41 Hex. Danach muss die PID als Kopie zurückgeschickt werden. Dann folgen die Datenbytes und diese Datenbytes entsprechen dem Wert, der hier als Messwert zu liefern ist.
Der Appendix-B umfasst eine ganze Reihe von Messwerten. Natürlich unterstützt nicht jedes Steuergerät alle Messwerte. Welche Messwerte unterstützt werden, steht in der Dokumentation des Steuergeräts oder der Diagnosetester fragt dies ab. Dazu gibt es eine spezielle PID, die PID 0, die bei allen Diagnosediensten in Verwendung ist. Als Antwort auf die PID 0 liefert das Steuergerät ein Bit-Feld zurück, welches anzeigt, welche PIDs unterstützt werden.
{{{3}}} |
In der Tabelle oben sind einige der Messwerte aufgelistet. Zum Beispiel PID 0x01: Anzahl der Fehler im Fehlerspeicher, PID 0x04: Motorlast (prozentual zwischen Null und 100 % mit 8 Bit kodiert), PID 0x05: Kühlwassertemperatur und PID 0x0C: Motordrehzahl (16 Bit-Wert mit einer Auflösung von einer Umdrehung pro Minute).
{{{3}}} |
Schauen wir uns jetzt unser Beispiel des Auslesens der Kühlwassertemperatur in allen Details an (einschließlich CAN-ID und einschließlich dessen, was auf der Transportebene passiert). Wir haben hier die Diagnoseanfrage kommend vom Diagnosetester zum Steuergerät, siehe Abbildung oben. Dort muss die funktionale Adressierung verwendet werden. Wir nehmen an, dass wir einen 11 Bit CAN-Identifier einsetzen. Dieser ist nach Standard 0x7DF. Da diese Botschaft mit 2 Byte Nutzdaten auskommt, bedeutet dies, dass auf der Transportebene ein Single-Frame ausreicht. Entsprechend folgt das PCI-Byte mit den Wert 02 (Null zeigt den Single-Frame und die Zwei zeigt, dass zwei Nutzdaten geschickt werden). Dann die eigentliche Anfrage. Die Anfrage hat die SID 01 und die PID 05.
Response des Motor-Steuergerätes zum Tester |
Die Response, die Antwort des Steuergerätes ist im Bild oben zu sehen. Hier muss die physikalische Adresse des Testers, die dem ersten Steuergerät zugeordnet ist, verwendet werden, laut Norm 0x7E8. Danach folgt wieder ein PCI-Byte welches einen Single-Frame mit 3 Nutzdatenbytes kennzeichnet. Jetzt kommt die eigentliche Antwortbotschaft: Sie beginnt mit der um 0x40 erhöhten SID, also hier 0x41. Dann wird die PID 05 zurückgeschickt und dann die eigentliche Motortemperatur. Nehmen wir an, die Temperatur sei momentan 62°C, ergibt dies 0x66.
Interpretation des Zahlenwertes 0x66: Wir wissen, die Motortemperatur ist ein 8 Bit-Wert, normiert für den Wertebereich zwischen -40°C und +215°C. Die 0x66 muss zuerst in einen Dezimalwert umgerechnet werden und dann, da wir einen 8 Bit-Wert haben durch 2 hoch 8, also 256 geteilt werden. Das Ganze muss mit dem Wertebereich multipliziert (Maximalwert minus Minimalwert, also 215 minus -40°C) und dazu der Offset addiert werden (hier -40°C). Das ergibt 62°C.
Zweites Beispiel: Lesen Fahrgestellnummer
Als zweites Beispiel wollen wir die Fahrgestellnummer mit SID 09 auslesen. Und wenn Sie wiederum im Appendix-B der Norm nachschauen, stellen Sie fest, für die Fahrgestellnummer benötigen wir die PID 02. Das heißt, die Request-Botschaft des Diagnosetesters enthält die Datenbytes 0x09 als SID und 0x02 als PID. Die entsprechende Steuergeräteantwort ist in der Tabelle 186 in der Norm dargestellt, siehe nachfolgende Abbildung. Die Response beginnt mit der um 0x40 erhöhten SID (0x49), dann folgt die Kopie der PID 02 und danach der Wert 01. Dieser Wert zeigt an, wie viele Fahrgestellnummern im Steuergerät gespeichert sind. Es gibt Länder in denen es mehr als eine Fahrgestellnummer gibt. In Deutschland ist dies zurzeit nicht der Fall. Daher steht hier in der Regel der Wert 01. Dann folgt die Fahrgestellnummer und zwar insgesamt 17 ASCII-Zeichen. Sie sehen hier in dem Beispiel die ASCII-Zeichen hexadezimal kodiert (0x31, 0x47 etc.).
Auszug aus ISO 15031-5 |
Betrachten wir nun, wie dieser Diagnosedienst als vollständige Sequenz von CAN-Botschaften umgesetzt wird.
Request zum Lesen der Vehicle Identification Number vom Tester zum Steuergerät (SID: 0x09, PID: 0x02) |
Zunächst die Diagnoseanfrage (Request) vom Diagnosetester zum Steuergerät: Funktionale Adressierung und 11 Bit CAN-Identifier ergeben den Wert 7DF. Dann folgt das PCI-Byte für einen Single-Frame mit 2 Bytes Nutzdaten. Jetzt kommt die eigentliche Anfrage mit der SID 09 und der PID 02.
Die Antwort des Steuergeräts, die Fahrgestellnummer mit 17 Zeichen passt nicht mehr in eine einzelne CAN-Botschaft. Daher haben wir nun auf der Ebene des Transportprotokolls eine Sequenz mit einem First-Frame und einer Reihe von Consecutive-Frames. Beginnen wir mit dem First-Frame, siehe Abbildung unten.
Response des Motor-Steuergerätes zum Tester |
Für die physikalische Adressierung des ersten Steuergeräts schreibt die OBD die CAN-ID 7E8 vor. Dann folgen 2 PCI-Bytes für den First-Frame. Die obersten 4 Bits (hier 1) kennzeichnen den First-Frame, die folgenden 12 Bits (hier 0x14 = 20) die Anzahl der Nutzdatenbytes. Dann kommen die um 0x40 erhöhte SID, (0x49), die PID 02 und weiterhin die eigentlich 17 Zeichen der Fahrgestellnummer. Sie beginnt mit der Zahl 01, die anzeigt, dass genau eine Fahrgestellnummer gespeichert ist. Jetzt folgen die ersten drei ASCII-Zeichen (W = 0x57, A = 0x41, U = 0x55). Die hier abgebildete Fahrgestellnummer ist ein Fahrzeugs der Firma Audi. Damit sind die 8 Bytes der ersten CAN-Botschaft gefüllt.
Es folgt, hier nicht dargestellt, auf den First-Frame ein Flow-Control vom Diagnosetester zum Steuergerät. Dann sendet das Steuergerät die zweite Antwortbotschaft, das heißt den ersten Consecutive-Frame. Der hat die Zahl 2 an erster Stelle des PCI-Bytes und als Sequenznummer die 1. Jetzt folgen in den 7 verbleibenden Nutzdatenbytes die nächsten 7 ASCII-Zeichen. Der nächste Consecutive-Frame mit der Sequenznummer 2 liefert dann die restlichen ASCII-Zeichen. Mit drei Botschaften ist die Response abgearbeitet.
Drittes Beispiel: Fehlerspeicher
Im dritten Beispiel wollen wir nun eine Sequenz von Diagnosediensten betrachten, mit denen der Fehlerspeicher gelesen werden kann. Um das Beispiel etwas übersichtlicher zu halten, haben wir im Gegensatz zu den beiden vorigen Beispielen die Ebene des Bussystems und die Ebene des Transportprotokolls weggelassen. Sie sehen also hier keine CAN-Identifier und auch keine PCI-Bits.
Auslesen des Fehlerspeichers nach OBD |
Die Abfrage ob und wie viele Fehler gespeichert sind, wird mit dem Dienst 01 und der PID 01 durchgeführt. Sie sehen in der Antwort die SID 41, PID 01 und dann grau dargestellt eine Reihe von Bytes, die die eigentliche Antwort enthalten. Das erste Byte mit 83 ist das wichtigste. Bei 0x83 ist das oberste Bit gesetzt. Nach Norm heißt das, die Malfunction-Indicator-Lamp ist eingeschaltet. Die unteren 7 Bits (entsprechen hier dem Wert 3) zeigen an, dass drei Fehler gespeichert sind. Die folgenden 3 Bytes geben Auskunft darüber, welche Überwachungsverfahren während der letzten Fahrzyklen aktiviert oder nicht aktiviert wurden. Das ist von Bedeutung, da es sein kann – falls keine Fehler angezeigt wurden – dass das Fahrzeug in Betriebszyklen gefahren ist, in denen bestimmte Überwachungen nicht aktiv waren. Beispielsweise wird im Kurzstreckenverkehr der Katalysator seine Betriebstemperatur nicht erreichen. Daher können auch die Katalysator- und Lambdasonden-Überwachungen nicht in vollem Umfang aktiviert sein.
Betrachten wir nun als Nächstes die Abfrage welche Fehler gespeichert sind. Wir wissen zwar, dass es drei Stück sind, aber wir wissen nicht genau welche. Deswegen benutzen wir als nächstes den Diagnosedienst mit der SID 03 ohne Parameter. In der Antwort bekommen wir zusammen mit der SID drei Mal 2 Bytes zurück. Die 2 Bytes stehen für einen so genannten Diagnostic-Trouble-Code (DTC), siehe folgende Abbildung. Dies ist ein hexadezimal kodierter Fehlercode. In unserem Beispiel hat der erste Fehler den Wert 0x0119.
OBD-Fehlerkodes nach ISO 15031-6 |
Wenn wir in der Norm nachschauen, sehen wir dort eine Erklärung der Fehlercodes (2 Bytes DTC). Die obersten beiden Bits, werden beim Diagnosetester typischerweise als Buchstabe dargestellt und zwar P, C, B oder U. P steht für Power Train (Antriebsstrang), C für Chassis (Fahrwerk), B für (Karosserieelektronik) und in der Praxis gar nicht so selten U für irgendein Problem im Bussystem.
Bit 5 und Bit 4 des ersten Bytes geben die erste Ziffer des Fehlerkodes an. Diese Ziffer zeigt an, ob der Fehlerkode durch die OBD-Norm definiert ist (0) oder bei 1 oder 2 wurde der Fehlerkode durch den Steuergeräte- bzw. den Fahrzeughersteller definiert. Er entspricht damit nicht der Norm.
Die zweite Ziffer wird über die Bits 3 bis 0 definiert. Sie zeigt an – wenn der Fehlerkode ein OBD-Fehlerkode ist – in welcher Komponente der Fehler aufgetreten ist. 1 und 2 stehen für die Einspritzanlage, 3 für die Zündung und 4 für das Abgas- oder Luftsystem.
Die nächsten 4 Bits, die dritte Ziffer, zeigen die Komponente genauer an. Bei der Einspritzanlage beispielsweise, die Einspritzdüse oder eine bestimmte Lambdasonde. Die vierte Ziffer beschreibt die Fehlerart. Hier zum Beispiel ein Wackelkontakt, also ein Signal das außerhalb des normalen Arbeitsbereiches liegt.
Wenn Sie für unser Beispiel 0x0119 in der Norm nachschauen, stellen Sie fest, der Fehler betrifft den Antriebsstrang, der Fehlerkode ist durch ISO festgelegt, wir haben es mit einem Fehler in der Einspritzanlage zu tun und zwar ist der Wassertemperatursensor nicht in Ordnung. Das Steuergerät meint, der Sensor habe einen Wackelkontakt.
Kommen wir jetzt zurück zum vorletzten Bild „Auslesen des Fehlerspeichers nach OBD“. Wenn uns der Fehlerkode als Information für die Fehlerbeseitigung nicht ausreicht, könnten wir zum Beispiel noch abfragen, bei welcher Motordrehzahl, bei welcher Motortemperatur usw. der Fehler aufgetreten ist. Um diese Informationen zu erhalten brauchen wir die sogenannten Freeze-Frames. Diese haben die SID 02 und die entsprechenden PIDs sind in der Norm aufgeführt.
Wenn der Fehler auf Basis dieser Informationen behoben ist, können wir den Fehlerspeicher löschen. Dazu benutzen wir den Dienst mit der SID 04, der keine weiteren Parameter benötigt.
Im Gegensatz zur On-Board-Diagnose, die nur relativ wenige Funktionen bereitstellt und mit denen im Wesentlichen nur lesend zugegriffen werden kann, stellt UDS Funktionen bereit, mit denen praktisch jedes Detail der Steuergeräte bedient werden kann. Darauf gehen wir im nächsten Abschnitt ein.
Siehe auch