Was hat ein VW Lupo 3L von 1999 mit dem neuen Tesla Roadster gemeinsam? Nicht die Reichweite, nicht die Beschleunigung und ganz sicher nicht den Preis. Aber wenn du die Leitungen hinter dem Armaturenbrett abhören könntest, würdest du bei beiden dieselbe Sprache hören: CAN-Bus.
Im Lupo 3L beschreibt Volkswagens eigenes Schulungsmaterial, wie das Getriebesteuergerät über einen CAN-Datenbus mit der Dieseleinspritzung, dem ABS und dem Kombiinstrument kommuniziert. Teslas Model S und Model 3 betreiben mehrere CAN-Busse hinter einem zentralen Gateway; die Community hat sie öffentlich dokumentiert. Zur Verkabelung des Roadsters, den Tesla am 15. Oktober vorgestellt hat, gibt es noch keine Angaben. Hier extrapoliere ich also. Ich wäre aber ehrlich überrascht, wenn er mit dem Rest der Familie bräche.
Ein Protokoll, das fast 30 Jahre Fortschritt im Automobilbau überlebt, verdient einen genaueren Blick. Erst recht, wenn du es gerade in dein eigenes Auto einbauen willst.
Ein Design aus den 80ern, das keinen Grund hat, in Rente zu gehen
CAN, kurz für Controller Area Network, entstand 1983 bei Bosch. Im Februar 1986 stellte Bosch es auf dem SAE-Kongress in Detroit vor, 1987 lieferten Intel und Philips die ersten Controller-Chips, und ab 1991 setzte Mercedes-Benz es in seinen Oberklassefahrzeugen ein. 1993 wurde es als ISO 11898 standardisiert. Seitdem kamen CAN FD (2012) und CAN XL dazu, aber klassisches CAN steckt nach wie vor überall.
Warum? Weil das Design die schwierigen Probleme eines Kabelbaums bemerkenswert gut löst:
- Differenzielle Übertragung. Zwei Leitungen, CAN_H und CAN_L, übertragen das Signal als Spannungsdifferenz. Störungen, etwa von der Zündspule, treffen beide Leitungen gleich stark und heben sich auf.
- Kein Master. Jeder Knoten darf senden. Beginnen zwei gleichzeitig, entscheidet die bitweise Arbitrierung: Der Frame mit dem niedrigsten Identifier gewinnt, der andere zieht sich zurück und versucht es erneut. Nichts geht kaputt, und niemand muss etwas koordinieren.
- Eingebaute Fehlerbehandlung. Jeder Frame trägt eine 15-Bit-CRC und braucht eine Bestätigung. Jeder Knoten führt Sende- und Empfangsfehlerzähler, und ein Knoten, der zu oft danebenliegt, schaltet sich selbst ab (Bus-Off), statt alle anderen mit herunterzuziehen.
Der letzte Punkt ist mein Favorit. Ein defekter Sensor reißt nicht das ganze Auto mit. Er verabschiedet sich still aus dem Gespräch.
Warum ich CAN in ein Auto aus den 70ern bauen will
Vielleicht kennst du schon meinen Peugeot 304 (Beitrag auf Englisch). Die S-Version mit Doppelvergaser kam 1972, in einer Zeit, in der „Fahrzeugelektronik“ einen Sicherungskasten und eine optimistische Grundhaltung bedeutete.
Ich will nicht ein paar Gadgets nachrüsten. Ich will die Elektrik selbst neu aufbauen: ESP32-Boards mit Sensoren, verteilt im ganzen Auto, die über CAN miteinander reden. Das Gehirn in der Mitte wird ein Raspberry Pi 5. Falls du Ähnliches vorhast: Der Pi hat keinen eigenen CAN-Controller, er braucht also ein CAN-HAT und unter Linux SocketCAN.
Bevor ich aber auch nur ein Loch in eine 50 Jahre alte Karosserie bohre, wollte ich den Bus richtig verstehen. Nicht aus einem Datenblatt, sondern auf meinem eigenen Schreibtisch.
CAN-Lab: zwei Boards, zwei Leitungen, ein Browser-Tab
Also habe ich CAN-Lab gebaut. Zugegeben nicht ganz allein, aber ich bin ziemlich stolz darauf, was am Ende dabei herausgekommen ist. Der Code ist Open Source unter GPL-3.0 auf GitHub, und das Repository enthält die fertigen Sketches.
Die Hardware ist bewusst günstig: zwei ESP32-C3 SuperMini* mit eingebautem CAN-Controller (bei Espressif heißt er TWAI) und zwei SN65HVD230-Transceiver-Module*, die die Logiksignale auf Buspegel umsetzen. Dazu ein Steckbrett, ein paar Jumper-Kabel und zwei USB-Kabel, und das Labor ist komplett.
CAN-Lab selbst läuft in Chrome oder Edge. Es nutzt die Web Serial API, über die ich schon einmal geschrieben habe (auf Englisch), und liest beide Boards gleichzeitig aus. Es verlässt also nichts deinen Rechner.
Das Projekt richtet sich an IoT-Enthusiasten, die schon einmal einen ESP32 geflasht haben. Wenn dich PlatformIO und ein Steckbrett nicht abschrecken, läuft das Ganze an einem Abend.
Lasttest für einen Bus, der älter ist als manche meiner Kollegen
Der Verbindungstest schickt einen Frame pro Sekunde und zeigt dir, ob Frames ankommen und ob welche fehlen. Nützlich, aber ein bisschen langweilig.
Spannend wird es beim Lasttest. Du wählst eine Zielrate und eine Dauer, CAN-Lab macht beide Boards scharf und zeichnet dann in Echtzeit gesendete gegen empfangene Frames auf, dazu die Fehlerzähler.
Mit meinem Aufbau habe ich 4.303 Frames pro Sekunde ohne eine einzige verlorene Nachricht erreicht: keine Zählerlücken, keine Busfehler.
Ich habe bewusst 10.000 Frames pro Sekunde angeboten. Was der Bus nicht tragen konnte, hat die Sende-Warteschlange abgewiesen, und was durchkam, kam vollständig und in der richtigen Reihenfolge an. Diese Zahl hat mich aufhorchen lassen, denn sie liegt nah am physikalischen Limit. Bei 500 kbit/s braucht ein klassischer Frame mit 8 Datenbytes inklusive Pause zwischen den Frames 111 Bit, mit Bit-Stuffing bis zu 135 Bit. Daraus ergibt sich eine Obergrenze irgendwo zwischen etwa 3.700 und 4.500 Frames pro Sekunde. Anders gesagt: Zwei Boards für ein paar Euro haben die Leitung gefüllt, statt vorher schlappzumachen.
Für meinen Peugeot heißt das: Bandbreite ist meine geringste Sorge. Eine Handvoll Temperatur-, Druck- und Geschwindigkeitssensoren fällt kaum ins Gewicht.
Probier es selbst aus
Alles, was du zum Nachbauen brauchst, steht im CAN-Lab White Paper, das du unten kostenlos herunterladen kannst: Stückliste, Schaltpläne, Flashen, der Lasttest Schritt für Schritt und eine Fehlersuche, dazu die vollständigen Ergebnisse und die Messmethodik. Ich bin gespannt, ob du meine 4.303 Frames pro Sekunde schlägst und was du auf den Bus legst, sobald du ihm vertraust.
Mit * gekennzeichnete Links sind Affiliate-Links. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.