Dieses Gerät habe ich entwickelt, um die CAN-Busse meiner Fahrzeuge zu analysieren.
Der CAN-Bus (Controller Area Network) ist der zentrale Kommunikationsbus in der Automobilelektronik über den die verschiedenen elektronischen Steuereinheiten eines Fahrzeugs miteinander kommunizieren. Viele wichtige und interessante Daten werden darüber ausgetauscht, die man für eigene Elektronik-Projekte im Fahrzeug nutzen könnte. Leider legen die Fahrzeughersteller nicht offen, nach welchen Mustern die Daten übertragen werden. Um das herauszufinden, muss man am Bus "mitlauschen" und dann die gesammelten Daten analysieren. Genau für diesen Zweck wurde dieses Gerät gebaut.
Ältere Fahrzeuge, wie meine F800GS, verwenden CAN in seiner Standard-Form, moderne Fahrzeuge verwenden eine erweiterte Spezifikation des CAN-Standards: CAN-FD (Flexible Datarate). Mein Gerät beherrscht beide Standards.
An diesem Punkt ein Hinweis an alle, die das Gerät nachbauen und nutzen wollen: Wer sich am CAN-Bus seines Fahrzeugs zu schaffen macht, sollte sehr genau wissen, was er tut! Hier besteht enormes Potential, die gesamte Fahrzeugelektronik durcheinander zu bringen oder gar zu beschädigen. Nicht nur indem evtl. eigene CAN-Nachrichten in den Bus eingebracht werden, die die anderen Teilnehmer des Busses verwirren oder gar zu unbeabsichtigten Aktionen verleiten - schon alleine der falsche Anschluss der Messdrähte an den CAN-Bus kann diesen lahmlegen - absolut nicht ratsam, insbesondere nicht im Fahrbetrieb. Also nochmal ganz explizit: Die Verwendung dieser Pläne und Software geschieht auf eigenes Risiko!
Als zentraler Rechner der Elektronik dient in diesem Fall ein Raspberry Pi ZeroW mit einem entsprechenden Python-Programm. Dieser bietet von sich aus die für die Anwendung nötigen Interfaces (SPI, UART, einige GPIOs) und außerdem ermöglicht er das einfache Erstellen von Datenfiles auf einer SD-Karte. Sicher wäre das Ganze auch mit einer kleineren Hardware als einem kompletten Linux-Rechner gegangen, aber alleine die ganze Low-Level Software für das Erstellen von Files auf der SD-Karte wäre ein Horror geworden.
Die eigenentwickelte Hardware besteht damit im Wesentlichen nur aus einer Spannungsversorgung, dem CAN-Interface, UART-Treibern, und einer einfachen Bedien-/Anzeigeeinheit. Ein Mainboard ist für die Erzeugung der für den Raspberry nötigen 5V über einen LM14206 Schaltregler (IC1) zuständig. Die für weitere Teile der Hardware nötigen 3,3V kommen direkt vom Raspberry-Board. Ebenso auf dem Mainboard untergebracht sind die RX/TX-Treiber für den UART (invertierende Pegelwandler) sowie eine Bedientaste, Auswahlschalter und einige LEDs für die Anzeige des aktuellen Betriebszustands des Geräts.
Schaltplan des CAN-FD-Sniffer Mainboards
Das Mainboard verbindet auch den Raspberry über dessen SPI-Schnittstelle mit dem Controllerboard. Dieses habe ich separat vom Mainboard entworfen, um auch ein zugekauftes "MCP2517-Clickboard" von "Microe" anschließen zu können. In der Tat habe ich das Gerät in einer Zeit entworfen (2022), als es wegen Lieferschwierigkeiten nahezu unmöglich war, an die CAN-Komponenten des Controller-Boards zu kommen. Der einzige Weg einen CAN-FD Controller zu bekommen war in der Tat, sich das genannte Clickboard zu kaufen. Allerdings entsprach der auf diesem Board verbaute CAN-Transceiver nicht ganz meinen Wünschen, weshalb das Board nur die Notlösung blieb.
Das eigenentwickelte Contollerboard besteht aus einem MCP2517 CAN-FD Controller (IC1) mit entsprechender 40MHz-Clock und einem TCAN1051 CAN-FD Transceiver (IC2). Dieser bietet gegenüber dem Transceiver des Clickboards den großen Vorteil, dass man über einen Hardware-Pin sicherstellen kann, dass der Transceiver nur am Bus lauscht (Silent-Mode) und garantiert keine eigenen Nachrichten abgibt.
Dieser Silent-Modus sowie auch die Bus-Terminierung sind in Hardware schaltbar, um mein Gerät so universell wie möglich zu gestalten.
Über einen Testabgriff am RX-Pin des Transceivers lässt sich die CAN-Kommunikation mithilfe eines Oszilloskops oder eines Logikanalyzers verfolgen, um z.B. das Timing des Busses zu ermitteln.
Schaltplan des CAN-FD-Sniffer Controllerboards
Nach dem Start befindet sich das Gerät im Remote-Modus. In diesem kann die Hardware gewissermaßen über einen per UART angeschlossenen PC auf niedrigem Level "ferngesteuert" werden. Dieser Modus bietet die Möglichkeit, die einzelnen GPIOs des Raspberry oder die Register und das RAM des CAN-Controllers byteweise auszulesen oder zu programmieren und dient somit hauptsächlich zum manuellen Ausprobieren verschiedener Konfigurationen des CAN-Controllers.
Über einen Taster lässt sich das Gerät in 16 verschiedene vordefinierte und über den 4-Pin DIP-Switch wählbare Betriebsmodi bringen. Bisher sind folgende Betriebsmodi im Raspberry programmiert:
- DIP-Switch=0: Beenden des Programms auf dem Raspberry.
- DIP-Switch=1: Messages einer einzelnen spezifisch angegebenen CAN-ID werden mitgehört. Dieser Modus macht nur in Verbindung mit einem über UART angeschlossenen PC Sinn. Auf diesem werden die CAN-Daten grafisch angezeigt.
- DIP-Switch=2: Das Gerät zeichnet alle Messages unabhängig von der CAN-ID in einem File auf dem Raspberry auf. Dieser Modus kann auch ohne angeschlossenen PC betrieben werden.
- DIP-Switch=3: Über das Gerät können einzelne CAN-Messages in einen Bus gesendet werden. Dieser Modus macht nur in Verbindung mit einem über UART angeschlossenen PC Sinn.
Obwohl die Hardware auch für CAN-FD Betrieb ausgelegt ist, ist sowohl die Raspberry-SW als auch die PC-Software aktuell noch auf reinen CAN2.0-Betrieb ausgerichtet.
Python-Code des CAN-FD-Sniffers (update 04.02.2023)
PC-Code des CAN-FD-Sniffers (update 04.02.2023)
Das folgende sind einige Screenshots von der PC-Software mit einigen der Funktionen.
Und hier ist, was ich bisher in der CAN-Bus Kommunikation in meinen Fahrzeugen analysieren konnte.