was ist OBD? 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.
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
J1850 Bus an
ISO 9141-2 an
sowie immer an
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? 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? OBD im Käfer? 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:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
vw-resto...not only aircooled! advanced customizing meets engineering |
|
|
|
|
