Table of Contents
- en
- de
OOBD - Fahrzeugdiagnose für die Hosentasche
Hardware zur professionellen Fahrzeugdiagnose ist groß, unhandlich und teuer, und man muss ein Diplom haben, um es bedienen zu können? OOBD zeigt: Es geht auch einfach…
Die Vorgeschichte
Vor ein paar Jahren saßen ein paar Entwicklungsingenieure eines großen Automobilherstellers zusammen und fragten sich, warum sie für ihre Fahrzeugdiagnose immer noch mit Laptop, CAN- Blackbox und einer Kabelrolle durchs Werk irren mussten, wo es doch scheinbar in jedem Baumarkt kleine, handliche Fahrzeug- Diagnosetester zu kaufen gibt. Aber für Ingenieure sind Probleme halt dafür da, gelöst zu werden - und so entstand OOBD…
Was ist überhaupt Fahrzeugdiagnose?
Fahrzeugdiagnose macht man heute über den in jedem Auto vorgeschriebenen OBD-II Stecker (OBD= OnBoard Diagnostics). In diesem Stecker finden sich, je nach Automarke und Modelljahr, verschiedene serielle Anschlüsse (Busse), die intern mit den Fahrzeugmodulen verbunden sind. Die Flöte der möglichen Busse reicht von 1/2-Draht Leitungen (K(L)-Line ISO-9141, VW-Bus) über symmetrisch serielle Leitungen (V-/PWM SAE-J1850) bis hin zum richtigen CAN-Bus (SAE-J2284). Ein Teil der Pinbelegung des OBD-II Steckers ist genormt, und die Hersteller lieben es, die nicht genormten freien Pins mit eigenen Erweiterungen zu bepflastern.
Diese ganzen Busse sind von ihrer Hardware her aber alle nicht direkt kompatibel zu dem, was man normalerweise an einen PC anschließen kann, darum ist immer eine zusätzliche (intelligente) Hardware vonnöten, die die Signalpegel und z.T. auch das gesamte auf dem Bus verwendete Datenprotokoll so umsetzt, dass ein PC mit dem Bus die Daten austauschen kann. So ein Hardware- Wandler wird normalerweise als OBD- Dongle oder -Box und die ganze Einheit aus Dongle, PC und Diagnosesoftware als Diagnose-Tester (OBD-II Tester) bezeichnet. Diese Bezeichnungen Dongle und Tester werden wir auch im weiteren Text so wiederfinden.
Auch wenn man als Zuschauer in der Werkstatt den Eindruck bekommt, die Daten würden von selber aus der OBD-II Schnittstelle herauspurzeln, so ist es in Wirklichkeit dann doch anders. Fahrzeugdiagnose ist statt dessen ein streng reglementiertes Frage-und Antwort-Spiel (Request ⇔ Response): Im Detail sieht das so aus, dass der Tester an die Moduladresse des gewünschten Steuergerätes (ECU - Electronic Control Unit) eine Bytefolge schickt, die das angesprochene Modul dann als Anfrage interpretiert und seinerseits daraufhin die Antwort an die Adresse des Testers schickt, der die Antwort entsprechend auswertet.
Wie man daran schon sehen kann, sind dafür schon einige Detailkenntnisse notwendig: Man muss die Modul- Adresse kennen, wissen, wie die gewünschte Frage in Byteform zu formulieren ist und wie man die empfangenen Bytes wieder richtig in eine Klartext- Antwort umrechnen bzw. darstellen muss. Und auch hier hat jeder Automobilhersteller wieder seine eigene Philosophie, aber glücklicherweise ist wenigstens das Protokoll standardisiert, mit dem die Bytes über den Bus huschen, und genau da setzt OOBD an. OOBD steht übrigens für OpenOnBoardDiagnostics wobei das Open für Opensource steht. Aus diesem Grund befinden sich auch alle Hard-und Softwaresourcen des OOBD-Projektes auf OOBD.org 1) .
Welche OBD- Tester gibt es heute?
Betrachtet man die heute auf dem Markt verfügbaren Diagnose- Tester, dann findet man letztlich zwei Kategorien:
Einmal die gefühlt tausend Derivate des Urvaters des Diagnosesteckers, dem ELM 327. Alle diese Geräte sind immer noch Befehls- kompatibel zum alten 327, und haben so auch kaum eine Chance, dessen Einschränkungen zu entkommen: Die Adressen der erreichbaren Module sind hart verdrahtet, und der viel zu kleine interne Speicher reicht nicht aus, um moderne Protokolle in voller Telegrammlänge abwickeln zu können.
Einige dieser Geräte versuchen noch, zumindest einen Low-Level CAN Bus Modus zur Verfügung zu stellen, bei dem einzelne Roh- CAN Datenframes gesendet und empfangen werden können. Das hat aber bei Paketen, die nicht mehr in einen einzelnen CAN- Frame passen, die unangenehme Auswirkung, dass die dann notwendige Protokoll- Abwicklung in Echtzeit vom Diagnose- Tester selber durchgeführt werden muss. Das setzt aber eine schnelle, sichere Verbindung zwischen Dongle und Tester und einen schnellen Tester voraus, wodurch aber wackelige Bluetooth- Verbindungen und langsame Handys als Tester ausfallen.
Am oberen Ende der Preis- und Leistungsskala finden sich dann die Geräte der professionellen Hersteller. Diese Geräte können eigentlich fast alles, hängen aber u.a. aus Geschwindigkeitsgründen oftmals am (unerwünschten) Kabel, sind meistens PC- basiert und teuer, nicht zuletzt auch, weil fahrzeugspezifische Internas mit zusätzlichen Lizenzkosten mit im Produkt enthalten sind. Diese Systeme haben dann meistens entweder viel zu viele Stellschräubchen oder reglementieren den Anwender durch fest verdrahtete Frage- und Antwort- Menüs.
Der OOBD- Tester - was macht ihn anders?
Die ganzen oben genannten “Wenn und aber” waren die Eingangsgrößen, als das OOBD-Projekt startete. OOBD versucht nun, die heutige Lücke zwischen gut und billig mit einem neuen Konzept auszufüllen. Unsere selbst gestellten Anforderungen waren dabei:
- Es soll einfach sein
- Es soll an alle Anforderungen anpassbar sein
- Das gesamte System soll in die Hosentasche passen, um es immer dabei haben zu können
- Es soll über Bluetooth funktionieren, weil Handys nun mal keinen Kabelanschluss haben
- Es soll den kompletten Adressbereich und Telegrammlänge des ISO- Protokolls abdecken, um mit jedem Modul im Fahrzeug arbeiten zu können
- Die gesamte Echtzeit-Abwicklung soll im Dongle passieren, um so problemlos mit langsamen Bluetooth- Verbindungen und Handys zu funktionieren
- Es soll herstellerspezifische Besonderheiten bedienen können, ohne diese aber aus lizenzrechtlichen Gründen von vornherein mitzuschleppen.
- Es soll zwei CAN-Busse unterstützen
Die OOBD- Hardware
Zuerst einmal brauchten wir einen Prozessor, der genügend Speicher bietet, CAN unterstützt und einfach beschaffbar und programmierbar ist. Dies fanden wir im STM32-Cortex M3. Der Prozessor wurde dann noch umgeben mit Bustreibern, Spannungsregler, LEDs und Buzzer und in ein passendes Gehäuse gepresst. Damit war der Hosentaschen- Formfaktor schon mal gegeben.
Dabei wurde auch darauf geachtet, dass die Hardware die rauen Bedingungen im Werkstatt- Alltag überstehen kann: Der OBD-II Stecker hat feste vergossene Kontakte, die Platinenaufhängung ist abgefedert, so daß auch ein Fall aus 1 Meter auf Beton auch mehrmals überstanden wird. Die Platine und der OBD-II Stecker sind getrennt, um entweder den OBD-Stecker an eigene Belegungen anpassen zu können oder die Hauptplatine in eigene Systeme einzustöpseln.
Die OOBD- Firmware
Die Firmware ist viel komplexer, als man das vielleicht bei einem einfachen Stand-Alone-Controller vermuten würde. Statt sich lange mit proprietärem Code- Gebastel rumzuquälen, wurde dem Prozessor gleich ein komplettes Multitasking- Betriebssystem spendiert, nämlich das bekannte FreeRTOS 2) . Dies ermöglichte eine saubere Trennung der einzelnen Funktionsgruppen.
Und diese Trennung wiederum bringt weitere Vorteile mit sich:
- Die hardwarespezifische Programmierung befindet sich in eigenen Sourcefiles für's Startup und die I/O-Konfiguration (CAN-Bus, UART für BT-Module, LED-Ansteuerung, L/K-Line, Buzzer)
- FreeRTOS ist für eine Vielzahl von Prozessoren verfügbar. Will man irgendwann mal OOBD auf einen anderen Prozessor portieren, braucht man nur die hardwarespezifischen Sourcen anzupassen, der Rest bleibt unverändert. Dies wurde schon während der Entwicklung ausgiebig genutzt, indem der OOBD-Kernel mit FreeRTOS als Emulator unter Linux läuft und man alle Prozesse direkt am PC debuggen kann, ohne nach jeder Änderung erst einen Controller flashen zu müssen.
- Weiterhin ist das OOBD-OS von vornherein dafür designed, weitere Protokolle und Busse zu unterstützen. Dazu muss nur ein neues Source-file mit der neuen Funktion in den Build- Prozess aufgenommen werden, die notwendigen Befehle zur Protokoll- oder Bus- Umschaltung sind bereits vorhanden und werden auch schon für verschiedene Protokolle benutzt.
Die Befehls- Syntax
Die Befehlssyntax wirkt im Vergleich zu dem, was man vom ELM327 kennt, ausgesprochen spartanisch, aber das täuscht: OOBD kennt nämlich nur zwei Arten von Eingaben, und nur eine davon ist überhaupt ein Befehl.
Alles, was mit “p” anfängt, gilt als Befehl (p steht für Parameter); alles andere wird als hexadezimale Daten- Eingabe interpretiert und vom jeweils gerade laufenden Protokoll direkt verarbeitet, d.h. es sind nur die Zeichen 0-9, A-F erlaubt. Blanks sind ebenfallsn erlaubt und abgeschlossen wird eine Eingabe mit <CR>; alle anderen Zeichen und Eingaben sind ungültig und die Eingabezeile wird ignoriert.
Die P- Befehle dagegen bestehen auch nur aus mehreren Integer Werten, getrennt durch Blanks, die entweder dezimal oder mit $ am Anfang hexadezimal geschrieben werden. Die erste Zahl gibt immer an, für welchen Funktionsblock der Befehl gedacht ist, so gibt zum Beispiel…
>p 0 0 0 OOBD D2 651 Lux-Wolf CAN-Invader Thu, 15 Aug 2013 01:15:25 +0200 .>
…den Versionsstring aus
So primitiv und für den Menschen unhandlich dieses Format auch ist, so einfach hat es eine Anwendung, mit dem Dongle zu kommunizieren; auch der Inputparser der Firmware braucht längst nicht alles zu verstehen, er reicht Befehle anderer Funktionsgruppen und Daten einfach an die entsprechenden Funktionsgruppen weiter.
So sieht dann eine normale Kommunikation mit dem Dongle wie folgt aus: (die #-Kommentarzeilen dienen lediglich zur Veranschaulichung)
# Umschalten des CAN- Anschlusses auf die Pins des High Speed CAN >p 8 4 0 . # CAN Bus initialisieren für 500 kb/s , 11 Bit CAN-ID >p 8 3 3 . # CAN Transceiver in den normalen Transmit Mode schalten (CAN Active) >p 8 2 3 . # CAN Empfangs- Filter 1 auf 0x000 setzen >p 8 10 1 $000 . # CAN Empfangs- Maske 1 auf 0x000 setzen (alle IDs 0x000 - 0x7FF) erlaubt) >p 8 11 1 $000 . # Aktuelles Protokoll anzeigen lassen >p 7 0 0 1 - UDS (ISO14229-1) . # Daten senden (an Funktionale Modul-Adresse 0x7DF = Broadcast) >1003 # Und das Modul antwortet 5003003200c8 . # Done :-)
Die Dongle Protokolle und Busse
Im Moment ist der Dongle kompatibel zu dem CAN-Transportprotokoll (ISO-TP) nach ISO 15765-2. Dieses erweitert einen Standard CAN-Frame mit max. 8 Nutz-Datenbytes auf eine maximale Anzahl von 4095 (Nutz-)Datenbytes. Diese sogenannten Multiframes werden v.a. im Umfeld der Fahrzeugdiagnose-Kommunikation oftmals verwendet. Beim KWP2000 on CAN (ISO 15765-4) und UDS (Unified Diagnostic Services, ISO 14229) Protokoll auf den zwei umschaltbaren CAN- Bussen kommt dies ebenfalls zum Einsatz. Darüber hinaus gibt es einen CAN- Raw- Modus, der das Mithören auf dem Bus sowie das Abschicken längerer CAN- Sequenzen ermöglicht. Ein weiterer Modus, das sogenannte RealTimeData (RTD) Protokoll, welches Echtzeitdaten (Raw data) im Dongle zwischenspeichert und auf Anfrage zur Applikation schickt, ist bereits enthalten.
Die OOBD- Applikation
Der Dongle erfüllt bereits wie oben beschrieben die an ihn gestellten Anforderungen, doch wie erfüllt die dazu passende Anwendung die Forderungen nach Einfachheit und Anpassungsfähigkeit, ohne herstellerspezifische Geheimnisse mit sich tragen zu müssen?
Der Trick ist: OOBD besitzt einen eingebauten Script- Interpreter, und zwar für die LUA-Skriptsprache. Diese einfache und überaus mächtige Programmiersprache kann nahtlos um neue Funktionsaufrufe ergänzt werden, mit denen das Lua- Programm mit seinem umgebenden Hauptprogramm kommunizieren kann, und genau das wird in OOBD auch umgesetzt. Es gibt eigene Befehle, um die Fensteransicht aufzubauen, um über Datenbanken Fehlernummern in Klartext umzuwandeln und um über die serielle Schnittstelle mit dem Dongle zu sprechen.
D.h. man schreibt sich seine gewünschte Funktionalität in Lua, kompiliert und speichert das File dann auf seinem OOBD- Gerät ab. Das OOBD- Programm zeigt dann die verfügbaren Möglichkeiten im Auswahlfenster an, man wählt das gewünschte Programm aus und ab geht's. Am seriellen Port muss auch nicht unbedingt ein Diagnosetester hängen, sondern das funktioniert mit allem, mit dem man seriell kommunizieren kann.
Das Lua- Listing, um das Hauptmenü darzustellen und von da aus dann z.B. die Fahrgestellnummer (engl. VIN) eines Autos auszulesen, sieht so aus:
function Start(oldvalue,id) identifyOOBDInterface() setSendID("$7E8") -- set specific ISO 15765 compatible sender (=answer) address for OOBD firmware openPage("OOBD-ME Main") addElement("Sensor Data>", "createCMD01Menu",">>>",0x1, "") addElement("Snapshot Data>", "createCMD02Menu",">;;>;;>;;",0x1, "") addElement("Dynamic Menu3>", "createCMD03Menu",">;;>;;>;;",0x1, "") addElement("Trouble Codes", "showdtcs","-",0x1, "") addElement("VIN Number", "vin","-",0x2, "") addElement("Clear Trouble Codes", "clearDTC","-",0x0, "") addElement("System Info>>;;>;;", "SysInfo_Menu",">;;>;;>;;",0x1, "") addElement("Greetings", "greet","",0x1, "") pageDone() return oldvalue end function vin(oldvalue,id) echoWrite("0902\r\n") udsLen=receive() if udsLen>0 then if udsBuffer[1]==73 then local pos=4 local res="" while pos <= udsLen and pos <36 do if udsBuffer[pos]>31 then res=res..string.char(udsBuffer[pos]) end pos= pos +1 end return res else return "Error" end else return "NO DATA" end end
Man muss nun aber nicht grundsätzlich alles von Hand programmieren. Für den eingangs erwähnten Automobilhersteller gibt es z.B. mittlerweile (interne) Bibliotheken, mit denen komplette Modulspezifikationen automatisch ins Lua- Format übersetzt werden und so innerhalb von Minuten hunderte neue Messgrößen zur Verfügung stehen.
Eine gewünschte Sonderfunktion, die mehr auf die gewerbliche Nutzung abzielt, ist die Möglichkeit, die Lua- Skripte per PGP zu verschlüsseln und so nur den Anwendern zugänglich zu machen, die das passende Keyfile und Passwort haben.
Und um das Ganze nun auch möglichst weiträumig nutzen zu können, sind die Apps in Java geschrieben, so das die selben Kern- Sourcen sowohl in Android als auch auf Windows, Linux und Mac funktionieren, lediglich die Oberflächen waren anzupassen.
Und wie geht’s weiter?
Als wir damals mit dem Projekt anfingen, hätten wir nie gedacht, wie weit es uns tragen würde, denn jede geschaffene Möglichkeit weckte wieder neue Begehrlichkeiten, was man denn noch so dazu bringen könnte. OOBD ist heute bereits bei einem großen Hersteller im Einsatz, der das Projekt auch aktiv unterstützt, aber es gibt immer noch viele neue Ideen und Möglichkeiten, aber eher zuwenig Mitarbeiter; darum wie bei den meisten OpenSource Projekten auch hier die Ansage: Wer Interesse hat, an OOBD mitzuwirken oder es für seine eigenen Anforderungen zu erweitern: Wir freuen uns über jeden neuen Mitstreiter.