OpenSource OBD2-Adapter fürs Forum entwickeln

Eines meiner aktuellen Projekte beschäftigt sich damit einen eigenen OBD-Adapter zu konstruieren. Dieser soll als Hardware-Plattform für unsere Basteleien dienen, aber soweit universell sein, das er sich für vielerlei Dinge nutzen lässt. Es sollte jedem Elektroniker möglich sein diesen nachzubauen, aber ich würde ihn auch gern in Kleinserie herstellen. Natürlich sollen sich die Kosten dabei so im Rahmen halten das es auch noch attraktiv bleibt.

Als Plattform denke ich an einen STM32 ARM-Prozessor. Das gibt es eine große Palette mit unterschiedlichen Merkmalen. Allen gemein ist aber das sie im Vergleich zu den AVRs von Atmel viel mehr Leistung und Ressourcen haben. Ab der Baureihe STM32F103 besitzen sie auch zwei CAN-Controller on-board, einen High-Speed und einen Low-Speed. Da wir im Mondeo 3 CAN-Busse haben die auch am OBD-Port anliegen, müsste ich entweder ein STM32F4xxx nehmen oder ggf. einen zusätzlichen, per SPI oder parallel angebundenen CAN-Controller (SJA1000 oder MCP2551) hinzufügen.

An Schnittstellen soll der Adapter zunächst über einen USB-Port verfügen. An diesem kann er direkt mit einem PC verbunden werden, zwecks Programmierung oder Datenaustausch. Für größere Datenmengen wie z.B. Updates oder Loggings möchte ich diesen ebenfalls verwenden, nur das man dann einen Stick dort einsteckt. Über diese Art könnte man den Adapter auch mit einer Firmware versorgen. Grundsätzlich hat der STM32 noch massig I/Os zur Verfügung um Schaltsignale zu erkennen, zu steuern, analoge Werte zu messen, PWM auszugeben, etc. etc. Jede Schnittstelle bedarf aber zusätzlicher Elektronik (Pegelanpassung, Eingangsschutz, Leistungstreiber für Ausgänge) und Mechanik. Auch so Spielereien wie WLAN/Bluetooth/GPS/GSM wären möglich, kosten aber Platz und Geld. Daher überlege ich an einem Erweiterungsbus zum anstecker zusätzlicher Module, auch Eigenentwicklungen. Ein Industriestandard wie SPI und I2C wären hier schon eine gute Wahl, evtl. ergänzt mit einer universellen parallelen Schnittstelle. Dann braucht es nur einen Pfostenstecker mit einem Stück Flachbandkabel als Erweiterung.

Die Bedienelemente sollten auch minimal sein. Die ein oder andere LED zur Statusanzeige und ein paar Taster sollten reichen. Das Gerät sollte in der Lage sein auch ohne angeschlossene Clientsoftware zu funktionieren. Unter Umständen wäre ein kleines OLED-Display mit 128x64 Pixel (1") denkbar. Dazu max. 5 Taster für Steuerkreuz und OK.

Als Anwendung hätte ich folgendes im Blick:

• ELM-Adapter Emulation um mittels ELMConfig arbeiten zu können.
• LAWICEL-Adapter Emulation um z.B. CANhacker oder andere CAN-Analysetools direkt nutzen zu können.
• DTC reader/resetter. Einfach reinstecken, DTCs werden im internen Speicher oder eingestecktem USB-Stick gespeichert und ggf. auf dem kleinen Display angezeigt und können auf Wunsch mit einem Tastendruck auch gelöscht werden.
• CCC reader/programmer. Identisch mit DTC-Funktion. Einfaches auslesen und programmieren (mit automatischem! Backup vorher) der CCC. Ggf. könnte man einfache Settings wie "Autom. Türverriegelung", "Autom. Spiegelanklappen", auch direkt über das Display machen. Aber auch am PC vorbereitete CCCs (oder von einem Forenmitglied für einen bestimmten Konfigurationswunsch eingestellte) hochladen. Einfaches Restore der letzten Konfig mit einem Knopf.
• Modulprogrammierung (IPC, Türmodule, S&C, PAM) mit vorbereiteter Software
• CAN-Gateway Funktion

Ob und wie das alles realisierbar ist, sei mal noch dahingestellt. Bis auf Punkt 5 wüsste ich aber in der Theorie schon wie es geht. Gedacht hätte ich den Adapter für den Diagnosefall, also Adapter rein, irgendwas tun, Adapter wieder raus.
Neben der Herausforderung der Hardware ist vor allem die Software zu programmieren. Hierzu suche ich noch Mitstreiter die mit mir zusammen entwickeln. Aktuell habe ich noch nichts, nur jede Menge Ideen und Fragmente. Wer sich also mit C, Mikrocontrollern, usw. auskennt und Zeit und Lust hat, bitte bei mir melden.

Ich hoffe ich werde bald weiteres berichten können.

Den CAN-Adapter den ich derzeit nutze (mit Lawicel-Firmware für CANhacker) ist dieser:

Der ist nicht von mir entwickelt, aber ich habe einen guten Draht zum Entwickler und arbeite auch viel damit. Darauf werkelt ebenfalls ein STM32 und hat mich auch ein wenig zu meinem Projekt inspiriert. Theoretisch hat der Adapter bereits alles drauf was man braucht. "Leider" hat er nur Dual-CAN und nicht Triple wie ich ihn gern hätte. Auch fehlen noch ein paar Kleinigkeiten wie ein Standard-USB Port damit man auch Sticks einstecken kann, bzw. ein SD-Slot, jenachdem. Auch ist der fahrzeugseitige Anschluß universell als SUB-D 9pol ausgelegt. Ich möchte direkt OBD und ein entsprechendes Gehäuse, sowas in der Art:

Softwareseitig habe ich kürzlich begonnen einem kleinen ELM-Emulator zu programmieren. Der bringt ELM zumindest schonmal (ohne echte Hardware) zum starten, auslesen und löschen von DTCs. Bin grad an der CCC dran. Das ist recht aufschlussreich, weil Ford viele herstellerspezifische OBD-PIDs nutzt. Überhaupt ist Ford der Hersteller der OBD am umfangsreichsten unterstützt, andere Hersteller können da nur rudimentäre Daten liefern. Die Ford-PIDs sind natürlich nicht öffentlich zugänglich, da muss man eine Art "Mitgliedschaft" zahlen für viele tausend Euro im Jahr um da dran zu kommen. Aber Reverse-Engineering hilft Wenn man auf der CAN-Seite den Datenstrom von Ford-Diagnosegeräten mitschneidet und analysiert kommt man evtl. auch dahinter. OBD ist ja (noch) gottseitdank ziehmlich offen da unverschlüsselt. Das wird sich aber in Zukunft (hoffentlich) ändern, bei neuen Fahrzeugen.

Parallel dazu arbeite ich bereits an der ELM-Firmware. Sie wird das für uns wichtigste des ELM-Befehlssatzes unterstützen, also expliziert erspare ich mir die Umsetzung der nicht-CAN Protokolle wie KWP, usw. Sie soll ja in erster Linie mit ELMConfig können.