Einleitung Transport Diagnoseprotokolle
Im folgenden Kapitel gehen wir auf Transport- und Diagnoseprotokolle ein. Nach einer kurzen Einleitung betrachten wir zunächst das Transportprotokoll, wie es für CAN im Einsatz ist und besprechen anschließend die Unterschiede, die sich bei der Weiterentwicklung für FlexRay ergeben haben. Danach gehen wir auf die drei heute wichtigsten Diagnoseprotokolle ein:
- OBD on CAN – vom Gesetzgeber für die Diagnose abgasrelevanter Systeme vorgeschrieben
- UDS (Unified-Diagnostic-Services) – für die allgemeine Fahrzeugdiagnose
- KWP 2000 – dem Vorgänger von UDS
Der folgende Abschnitt ist gegliedert in:
Einleitung
Wir bewegen uns also im Bereich der Off-Board-Kommunikation, das heißt der Kommunikation zwischen den Geräten im Fahrzeug und den externen Werkstatt- und Diagnosetestern.
|
| Vereinfachte Darstellung der Kommunikation im Fahrzeug |
Im ISO/OSI Schichtenmodell sind das die Ebene 4, der Transport-Layer und die Ebene 7, der Application-Layer. Auf letzterer sind die Diagnoseprotokolle angesiedelt.
|
| Open System Interconnection (OSI) Schichtenmodell nach ISO 1978 |
Off-Board-Kommunikation
Im Gegensatz zur On-Board-Kommunikation bei CAN oder FlexRay, bei der jedes Steuergerät seine Informationen an alle sendet, haben wir bei der Diagnosekommunikation ein klares Rollenmodell: Der Diagnosetester beginnt immer die Kommunikation. Er sendet eine Anfrage, wie beispielsweise: „Gibt es abgasrelevante Fehler im System?“ oder „Wie ist die Öltemperatur?“. Er sendet auch Befehle wie zum Beispiel: „Schalte den Motorlüfter ein!“. Diese Anfrage, der so genannte Diagnose-Request, geht an ein oder mehrere Steuergeräte. Diese Antworten mit den entsprechenden Diagnose-Responses. Es gibt also eine eindeutige Rollenverteilung: Der Tester fragt, die Steuergeräte antworten. Man nennt dieses Kommunikationsprinzip das so genannte Request/Response-Verfahren, siehe Abbildung.
|
| Off-Board-Kommunikation – Request/Response-Verfahren |
Zu Beginn der Kommunikation weiß der Diagnosetester nicht unbedingt, welche Steuergeräte im Fahrzeug verbaut sind. Das heißt, er kennt nicht immer das genaue Fahrzeugmodell und vor allem nicht die Kombination der verbauten Zusatzausstattungen. Auf der einen Seite muss es also möglich sein, dass der Diagnosetester mit allen Steuergeräten in irgendeiner Form kommuniziert. Auf der anderen Seite kann natürlich auch jeder, nicht nur die autorisierte Werkstatt, einen Diagnosetester am Fahrzeug anschließen. Es muss also sichergestellt werden, dass der Diagnosetester nicht alle Dinge auslesen und vor allem nicht alle Dinge verändern oder manipulieren kann.
Ein weiteres Problem für die Kommunikation entsteht dadurch, dass die Botschaften, die ausgetauscht werden, unter Umständen sehr viel länger sind, als eine einzelne Bus-Botschaft. Wenn man beispielsweise die Fahrgestellnummer abfragen will, hat man 17 Zeichen zu übertragen. CAN kann aber in einer einzelnen Botschaft maximal 8 Nutzdatenbytes übertragen. Man braucht also mehrere CAN-Botschaften, um diese Abfrage zu realisieren. Ein Extremfall stellt das Flashen der Steuergerätesoftware dar. Dort hat man häufig mehrere hundert Kilobyte bis vielleicht sogar einige Megabyte zu übertragen.
Protokollstapel (Protocol Stack)
Durch das ISO/OSI-Schichtenmodell wird die Aufgabenverteilung bei der Kommunikation zwischen Tester und Steuergerät festgelegt, siehe Abbildung. Das Diagnoseprotokoll beschreibt den Application-Layer, also die Ebene, mit der die Diagnoseanwendung arbeitet. Dieser Application-Layer stellt nun einzelne Dienste dar, zum Beispiel den Dienst: „Fehlerspeicher lesen“. Wenn die Diagnosebotschaft nicht in eine einzelne Bus-Botschaft hineinpasst, zerlegt das Transportprotokoll die entsprechende Diagnosebotschaft dann auf der Senderseite in mehrere Bus-Botschaften. Das Bussystem selbst, der Data-Link-Layer und der Physical-Layer versenden diese Botschaft.
|
| Protokollstapel (Protocol Stack) |
Auf der Seite des Steuergerätes wird die Botschaft empfangen. Auf der Ebene des Transportprotokolls im Steuergerät werden die einzelnen Bus-Botschaften wieder zur ursprünglichen Diagnosebotschaft zusammengesetzt und über den Application-Layer als Service an die Anwendungssoftware auf dem Steuergerät übergeben. Das Steuergerät seinerseits stellt dann die Antwort zusammen und übergibt sie einem Dienst, der diese Antwort versendet. Diese wird wieder in der Transportebene segmentiert, über das Bussystem übertragen, auf der Seite des Testers wieder in umgekehrter Reihenfolge zusammengesetzt und ganz oben an die Diagnoseanwendung übergeben.
Standardisierung
Wenn wir Diagnosethemen besprechen, haben wir es meist mit ISO-Standards und ASAM-Spezifikationen zu tun. In den entsprechenden Normen von ISO und ASAM, die Transport- und Diagnoseprotokolle betreffen, haben Steuergeräte auf der einen und Tester auf der anderen Seite spezielle Bezeichnungen. Bei ASAM heißt der Diagnosetester „Master“, weil er durch seine Request-Anfragen die Kommunikation auslöst, während die Steuergeräte als „Slaves“ bezeichnet werden, weil sie mit den Responses nur auf solche Anfragen antworten. ISO dagegen sieht das ganze eher aus Sicht der Informatik. Hier wird das Steuergerät, das auf eine Anfrage wartet, als einen „Server“ bezeichnet und der Tester, der eine solche Anfrage stellt, als „Client“.
Im folgenden Schaubild sieht man verschiedene ISO-Standards aufgeführt, die auf den ersten Blick etwas verwirren können:
|
| Überblick der Standards – Historische Entwicklung in Europa |
Historisch gesehen gibt es die allgemeine Fahrzeugdiagnose schon sehr lange. Zunächst hat sie jeder Hersteller, zumindest in der Applikationsschicht, proprietär gehandhabt. Auf der Ebene der Diagnoseschnittstelle hat man sich mit ISO 9141, der K-Line Schnittstelle, beziehungsweise SAE J1850 relativ früh festgelegt. Die Unterschiede auf der Applikationsebene haben dazu geführt, dass die Steuergeräte- und Diagnosetesterhersteller viel parallelen Entwicklungsaufwand für verschiedene Fahrzeughersteller hatten. Um dies zu reduzieren, führte man das in der ISO 14230 spezifizierte KWP 2000 ein. Diese Norm versuchte, die Diagnosedienste, die bei allen Herstellern im Einsatz waren, mehr oder weniger zu standardisieren.
Während der Einführung von KWP 2000 war die K-Line noch das dominierende Bussystem auf dem Markt. Als dann jedoch auch für die Diagnose CAN eingeführt wurde, hat man die Applikationsschicht von KWP 2000 zunächst einmal auf CAN übertragen. Die Änderungen waren relativ gering. Spezifiziert wurde das mit dem Normentwurf ISO/DIS 15765-3, der aber niemals den Entwurfsstatus verließ und zu einer vollen ISO Norm wurde. Grund: Während des Entwicklungsprozesses dieses Standards hat man das KWP 2000 Protokoll aus verschiedenen Gründen verworfen und auf das so genannte Unified-Diagnostic-Systems Protokoll (UDS) gesetzt. UDS unterscheidet sich zwar nicht in den Grundprinzipien, aber in vielen Details von KWP 2000. Das in der ISO 14229 standardisierte UDS ist etwas klarer und sauberer als KWP 2000. Zudem ist es grundsätzlich unabhängig vom darunter liegenden Bussystem, wird aber heute praktisch nur für CAN umgesetzt. Diese Umsetzung erfolgt durch die ISO 15765 (ohne DIS!). Teil 3 beschreibt die Anpassung an CAN und Teil 2 das entsprechende Transportprotokoll.
Parallel zu der allgemeinen Fahrzeugdiagnose war der Gesetzgeber aktiv. Mit der OBD hat zunächst der amerikanische Gesetzgeber Anforderungen an das Abgasverhalten eines Fahrzeuges und an deren Fehlerüberwachung gestellt. Die Europäer haben das dann mehr oder weniger unverändert übernommen. Dafür waren ein entsprechendes Diagnoseprotokoll und eine Diagnoseschnittstelle notwendig. Diese wurden in Europa in der ISO 15031 spezifiziert. Diese Norm hat eine ganze Reihe von verschiedenen Teilen. Im dritten Teil ist beispielsweise die Diagnosesteckdose (OBD-Dose) und im Teil 5 die Applikationsschicht mit den Diagnosediensten spezifiziert. Verwendbar ist OBD mit allen üblichen Bussystemen, also mit K-Line, SAE J1850 und CAN.
