OBD und ihre Kollegen

was ist OBD?
Das Kürzel OBD steht für OnBordDiagnose und sorgt nach wie vor für große Verwirrung durch unpräzise Handhabung einiger durchaus unseriöser Anbieter von Software, Hardware und Dienstleistungen rund um OBD. Seit dem Jahr 2000 muss jeder neu zugelassene PKW mit Otto-Motor in der EU mit einem OBD-System zur Emissionskontrolle ausgerüstet sein. Für PKW und NFZ mit Diesel-Motor gilt dies ab 2003 bzw. 2006. Zur Emissions kontrolle werden die abgasrelevanten Bauteile mit Hilfe der Bordelektronik überwacht. Fällt eine Komponente des Abgasreinigungssystems aus oder zeigt eine Fehlfunktion, leuchtet die Motorkontrolllampe im Kombiinstrument (KI) auf oder wird sogar im Klartext mit Warnsymbol im KI angezeigt und ein entsprechender Fehlercode wird gespeichert. Eine Fehlfunktion liegt vor, wenn z.B. durch Alterung oder Versagen eines Bauteils Emissionen auftreten, die die vorgegebenen Grenzwerte nicht einhalten. OBD dient zur kontinuierlichen Funktionsfähigkeitsüberprüfung der emissionsrelevanten Bauteile und vereinfacht so die Reparatur des System. Im Rahmen der AU wird neben der Abgasmessung auch die Funktion der OBD selbst überprüft. Im Prinzip ist damit alles gesagt was OBD macht.

Im Gegensatz zu anderen Ausführungen, hat OBD erstmal nichts mit der fahrzeugeigenen Kommunikation (Protokolle, Standarts, etc.) zu tun. OBD beschreibt, wie z.B. eine akkreditierte Prüfstelle das Fahrzeug prüfen kann. Welche Protokolle im Hintergrund laufen, ist für OBD egal. Doch wird OBD oft mit CAN oder KWP gleichgesetzt. CAN beschreibt das Controller Area Network, eine Entwicklung ursprünglich von Bosch, ein Netzwerk mehrerer Steuergeräte die über eine gemeinsame Leitung (sog. Bus) miteinander kommunizieren. CAN wird mittlerweile nicht nur im Automobil eingesetzt, es wir auch in NKW, Off-Road, Off-Highway, Spezialmaschinen und Industrieanlagen eingesetzt. Selbst die Kommunikation unabhängiger Teilsysteme erfolgt durchaus mittels CAN. KWP beschreibt das KeyWordProtocol in Verbindung mit einer Zahl, die das jeweilige KWP beschreibt. Desöfteren wird KWP allgemein mit KWP2000 gleichgesetzt, was falsch ist. Man sieht, OBD ist OBD und nichts anderes.

Die folgende Tabelle zeigt eine kleine, nicht vollständige, Übersicht über die wichtigsten (Transfer-)Protokolle und Standards.

ProtokollAnwendungEU und US Standards
ISO 9141-CARBDiagnose
US OBD
ISO 9141-2 Veraltete US-Diagnoseschnittstelle
SAE J1979, J2190
KWP 2000Diagnose
(allgemein und OBD)
ISO 14230 KWP 2000 Diagnose K-Line
ISO 15765 KWP 2000 Diagnose CAN
UDS - Unified Diagnostic
Services
Diagnose
(allgemein und OBD)
ISO 14229
OBDDiagnose EU
Diagnose US

ISO 15031 identisch mit US-Standards
SAE, J1930, J1962, J1978, J1979, J2012, J2186

CCP - Can Calibration
Protocol
ApplikationASAM AE MCD
Automotive Electronics Measurement, Calibration and Diagnostics
XCP - Extended Calibration
Protocol
ApplikationASAM AE MCD
Automotive Electronics Measurement, Calibration and Diagnostics
TransportprotokollAnwendungEU und US Standards
ISO TPCANISO 15765-2
AUTOSAR TPFlexRayAUTOSAR Standard
SAE J1939CANSAE J1939/21
TP 1.6, TP 2.0CANHausstandard VW/Audi/Seat/Skoda
(Basis OSEK COM 1.0)
StandardAnwendungEU und US Standards
OSEK/VDXBetriebssystem
Kommunikation
Netzmanagement
ISO 17356-3 OSEK OS
ISO 17356-4 OSEK COM
ISO 17356-5 OSEK NM
ASAM AE MCDApplikationStandardisierte Mess-, Kalibrier- und Diagnosewerkzeuge
Teilstandards
• ODX Datenformat - Diagnosedaten
• FIBEX Datenformat - Beschreibung der Buskommunikation
HISFlashen
Hardwaretreiber
Softwaremodule für Steuergeräte
AUTOSARSoftwarearchitekturSoftwarestruktur zukünftiger Steuergeräte

Vielleicht hilft es, sich die Entwicklung kurz anzuschauen. Moderne Fahrzeuge benötigen durchaus 20-60 Steuergeräte für unterschiedlichste Funktionen der Sicherheit und des Komforts. Auch ist nicht zwingend jedes Steuergerät mit jedem im regelmäßigen Austausch, doch gibt es zentrale Steuergeräte, die wiederum mehrere ansprechen und deren Daten auswerten. Ursprünglich erfolgte der Datenaustausch über Einzelleitungen zwischen den Steuergeräten. So wurden z.B. das ABS, das ASR und das MSG direkt miteinander verbunden. Diese Point-to-Point Netzwerke lassen sich prinzipiell ewig ausweiten. Der zu betreibende Aufwand ist jedoch so groß, das dies nur für eine bestimmte Anzahl an Funktionen gerechtfertigt ist. Mittlerweileist die Elektronik soweit entwickelt, das sie qualitativ hochwertig und preisgünstig zu gleich ist und dabei sehr viel Mehrwert bieten kann.

Selbstredend macht es keinen Sinn, als Fahrzeugherstelle komplett eigene Standarts zu schaffen. Mit global gültigen und skalierbaren Protokollen, lässt sich jedes Fahrzeug entsprechend ausstatten. So können auch identische Steuergeräte für verschiedene Marken und Typen verwendet werden. Der Applikationsaufwand für neue Typen ist entsprechend gering, wobei dies keine Abwertung der Applikation bedeuten soll. Jedoch kann die Applikation spezifisch auf das Fahrzeug erfolgen, man muß sich nicht um Systemprobleme kümmern, die nichts mit dem neuen Fahrzeugtyp zu tun haben. Auch erfreut es die Werkstätten, wenn man möglichst einheitliche Standarts einhält. Die Werkstatt wird nie einzelne Bits abfragen, dazu fehlt in aller Regel dem typischen Mechatroniker das passende Equipment und das notwendige Hintergrundwissen zum jeweiligen Standart. Dies würde auch nicht weit führen, man könnte falsche Bits nicht identifizieren und dementsprechend auch nicht auswerten. Und nicht jedes falsche Bit zeigt einen Fehler im eigentlichen Sinn. Es macht im Werkstattalltag auch keinen Sinn, sich mit diesen Problemen zu befassen. Es gibt vorgefertigte Lösungen, die passende Fehlertexte und Lösungsvorschläge anzeigen. Da dies für alle Fahrzeuge Gültigkeit haben sollte, sind einheitliche Standarts gefragt. Diese werden in Gremien diskutiert und beschlossen. Jedoch sei gesagt, das die große Phase von Neuerungen vorbei ist. Man muß sich vorstellen, seit Anfang der 90er bis heute, wurde von zwingend notwendiger rudimentärer Elektrifizierung der Fahrzeuge bis zum Highend-Controller, der die Rechenleistung eines PCs erreicht, eine wahnsinns Geschwindigkeit der Integration ins Automobil gezeigt. Natürlich darf man fragen, warum dies im Vergleich zum Home-Computer so lange gedauert hat. Doch bei näherer Betrachtung stellt man fest, das der Computer als Massenprodukt auch erst seit Mitte der 2000er Einzug in die Haushalte hält und Smartphones erst seit Ende der 2000er. Aber weit gefehlt, einfach einen PC ins Auto stellen reicht nicht aus. Die Fahrzeugelektronik muß stabilisiert sein, immerhin herrscht dort Gleichspannung mit starken Spannungsschwankungen vor. Auch sind die Einsatztemperaturen jenseits von Gut und Böse die ein PC bei 20-30°C Raumtemperatur im Jahr hat. Sämtliche Bauteile müssen darauf abgestimmt sein. Extreme Feuchtigkeit durch eintretendes Regenwasser sind für den Home-Computer kein Scenario. Erst recht nicht die Kombination aus Temperatur und Wasser sowie die stetige Wiederholung. Schäden durch Korrosion, Kurzschluss und Bruch sind zu vermeiden.

Neben allerlei herstellerspezifischen Schnittstellen gibt es auch eine standartisierte Diagnosebuchse nach J1962. Dies ist der bekannte Trapezförmige Stecker mit 16Pins. Durch die Kontaktbelegung ist im Regelfall erkennbar, welches Protokoll unterstützt wird.

CAN nach J-2284 an

  • Pin 6 - CAN High und
  • Pin 14 - CAN Low

J1850 Bus an

  • Pin 2 und
  • Pin 10 -

ISO 9141-2 an

  • Pin 7 - K-Line und
  • Pin 15 - L-Line 

sowie immer an

  • Pin 4 - Masse (Bordnetz)
  • Pin 5 - Signal Masse
  • Pin16 - Klemme 15/30

Auch wenn die Kontaktbelegung für die einzelnen Protokolle auf den ersten Blick völlig anders erscheint, so benutzen Sie doch den gleichen Befehlssatz nach J1939. Allerdings nur, wenn wir über die offizielle einheitliche On Board Diagnose reden. Herstellerspezifisch sieht die Sache anders aus.

Diagnose und Fehlercodes

Die Diagnose im Kraftfahrzeug erfolgt überwiegend durch definierte Fehlermeldungen, den Diagnose-Fehlercodes, auch DTC - Diagnostic Trouble Codes genannt. Die unterteilen sich in vorgeschriebene und freiwillige Codes. Über die vorgeschrieben Codes wachen ISO und SAE um ein einheitliches Fehlercode System fahrzeug- und herstellerübergreifend zu realisieren. Diese Fehler treten allgemein bei den meisten Herstellern in gleicher Weise auf und haben deswegen immer die gleiche Fehlernummer und Fehlerbeschreibung. Vorhandene aber nicht belegte Nummer sind für zukünftige Anwendungen reserviert. Die Fehlercodes sind jedoch so allgemein gehalten, dass sie auf nahezu alle Fahrzeuge und Fahrzeughersteller übertragbar sind. Die Verwendung dieser Fehlercodes muß durch ISO bzw. SAE genehmigt werden. Die freiwilligen Codes sind durchaus Hersteller und gar Fahrzeugspezifisch. Grundsätzlich stehen in jedem Fehlercodeblock Bereiche zur Nutzung durch die Hersteller zur Verfügung. Die Benutzung ist jedoch freiwillig und nicht vorgeschrieben.

Was ist CAN?
Wie bereits erwähnt, ist CAN ein Bus-System, bei dem die verschiedenen elektronischen Systeme nicht durch eine Vielzahl einzelner Kabel miteinander verbunden sind, sondern über einen Bus vernetzt sind. Allein diese Tatsache zeigt sofort das Potential des Bus-Systems im Fahrzeug auf. Es entfällt eine Vielzahl an Kabel und Steckverbindern sowie benötigter Bauraum für dicke Kabelbäume, notwendige I/Os zum durchschleifen von Signalen die von mehreren Steuergeräten verarbeitet werden und die hohe Ausfallsicherheit durch Komponentenreduktion. Der CAN Bus arbeitet nach dem Multi-Master-Prinzip, bei dem mehrere gleichberechtigte Steuereinheiten (Multi-Master) durch eine lineare Busstruktur miteinander verbunden sind. Bei Ausfall eines Steuergeräts, bleibt der gesamte Bus erhalten.

Mittlerweile ist CAN durch ISO und SAE standartisiert. Die ISO 11519-2 beschreibt Low-Speed Anwendungen bis 125kBit/s. Die ISO 11898 beschreibt High-Speed Anwendungen über 125kBit7s. Die ISO 11898 wird gleich als SAE J 22584 für PKW und als SAE J 1939 für LKW und Bus geführt. Die ISO 15031beschreibt dabei die Diagnose über CAN. (siehe Tabelle)

Netzwerk im Automobil?
Mit dem rasanten Entwicklung in der Computertechnik nimmt die Anzahl der elektronischen Systeme auch im Automobil immer weiter zu. Das hedeutet aber
auch, dass die Komplexität des Gesamtsystems Fahrzeug weiter steigt. Aus Einzelsystemen für z.B. Motorsteuerung, Leuchtweitenregulierung, Fensterheber, Bremse oder Beleuchtung wird ein Gesamtsystem. Die Innovationen werden aber vor aIlem durch das perfekte Zusammenspiel mehrerer Einzelsysteme erzielt. Damit die Vielzahl an Informationen, die in den Einzelsystemen verarbeitet werden, auch systemübergreifend genutzt werden können, müssen die einzelnen Komponenten untereinander vernetzt sein.

OBD im Käfer?
Ja, auch das geht. Der legendäre 1600i (MKB: ACD) der späteren Mexikaner ist über die Digifant Diagnosefähig. Weitere Details rund um diesen Speziellen Vertreter der Krabbeltiere erfährt man unter http://www.1600i.de. Wer einen 1600i sein Eigen nennt, der wird mit Sicherheit gerne selbst den Fehlerspeicher auslesen und ggf. das Steuergerät anpassen können. An Equipment wie dem original VAG Tester oder VAG COM ist nur schwer bzw. mit zu viel Geld zu kommen. Es gibt eine günstigere Alternative im Form eines Diagnoseadapter-Selbst-Bausatzes von http://www.blafusel.de. Hier bestellt man den Bausatz, lädt sich die Software (Freeware!) runter und bekommt eine vollständige Dokumentation. Für Fragen steht ein Forum zur Verfügung. Jeder der schon mal erfolgreich einen Elektrobausatz zusammen gelötet hat, sollte es auch schaffen, den Adapter zusammen zu löten. Die Software bietet die Möglichkeit zu diagnostizieren, zu adaptieren und Kanäle anzupassen. Mittlerweile gibt es sogar eine Bluetooth Variante des Adapters um mit dem PC zu kommunizieren. Gerade im Käfer ist dies eine feine Sache. Dazu benötigt man noch einen, möglicherweise selbstgebauten, Adapter zur Verbindung von Fahrzeug und Diagnoseadapter. Mit dem Wissen von 1600i.de sollte es jetzt keine Probleme mehr geben die nicht gelöst werden können.

Doch auch weit vor der Digifant im Käfer gab es die Diagnose. Im Jahre 1968 wurde der zentrale Diagnosestecker eingeführt, seit 1971 auch im Käfer und Bus serienmäßig verfügbar. Keine Zehn Jahre später, wurde 1977 aufgrund eines neuen Servicekonzeptes und fortgeschrittener Technologie der Diagnosestecker wieder abgeschafft. Die Diagnose war eher rudimentärer natur, da es damals keiner Steuergeräte im Fahrzeug gab. Vielmehr beruhte die Diagnose auf das Prüfen von Kontakten, Messen von Widerständen und Frequenzen in Kombination mit einer, damals hochmodernen, Lochkarte bzw. einem Diagnose-Sammelheft für das jeweilige Fahrzeug.

weitere Informationen...

...erhält man auf einschlägigen Seiten. Die Qualität der Aussagen ist jedoch oft stark Umsatzgetrieben, nicht ohne Grund findet man oft auf den ersten Blick informierende Seiten auch gleich dubiose Angebote. Darum hier eine kleine Auswahl von Einzelkämpfern ohne Nepp:

http://www.can-cia.org/

http://www.obd-2.net

http://blafusel.de

http://www.obd2-shop.eu

http://www.maliboo.de

http://www.plxdevices.com

 

 

Your rating: None Average: 4.8 (5 votes)