CAN, CAN FD, LIN und Ethernet — warum ein Fahrzeugnetzwerk kein einziger Bus ist

Ein Datenkabel für alles gibt es nicht

Im Forumsbeitrag, der diesen Text ausgelöst hat, wollte jemand einen handelsüblichen CAN-Logger an die Zuleitung seines elektrischen Fensterhebers klemmen, um herauszufinden, warum die Scheibe ruckelt. Das Problem: Ein Fensterheber hängt in aller Regel gar nicht am CAN-Bus. Er sitzt an einem LIN-Subnetz, das physikalisch, elektrisch und protokollarisch ein anderes System ist. Der Logger hätte an dieser Leitung schlicht nichts empfangen, egal wie teuer das Gerät war. Aus einer einfachen Verwechslung wäre eine stundenlange Fehlersuche ohne jede Chance auf ein Ergebnis geworden.

Diese Verwechslung ist kein Einzelfall. Wer „CAN“ hört, denkt oft an einen einzigen Bus, über den angeblich das ganze Auto kommuniziert. Tatsächlich stecken hinter dem einen Wort mehrere Protokollgenerationen: Classical CAN, CAN FD und inzwischen CAN XL. Dazu kommt ein komplett eigenständiges Subnetz namens LIN. Seit einigen Fahrzeuggenerationen zählt außerdem Ethernet als zusätzliche Netzebene für große Datenmengen. Jede dieser Techniken hat eine andere Nutzdatenmenge, eine andere Datenrate und einen anderen Zweck im Fahrzeugnetzwerk.

Dieser Beitrag ordnet die vier Ebenen des Fahrzeugnetzwerks als Vergleich ein: was sie unterscheidet, wo sie typischerweise sitzen und warum eine höhere Datenrate allein noch keine schnellere Diagnose bedeutet. Er geht bewusst nicht in die Tiefe der einzelnen Ethernet-Ausbaustufen oder Netzwerktopologien — das ist ein eigenes, deutlich technischeres Thema. Hier zählt die Einordnung auf Systemebene, damit ein Logger, ein Diagnosegerät oder ein Umbau am richtigen Netz ansetzt.

Warum „CAN-Fehler“ allein diagnostisch zu unscharf ist

Ein Fahrzeugnetzwerk lässt sich am einfachsten in Schichten denken, ähnlich wie es die Informatik mit dem OSI-Modell tut. Ganz unten liegt die elektrische, physikalische Übertragung: Spannungspegel, Leitungswiderstand, Abschlusswiderstände, Signalqualität. Darüber liegt die Data-Link-Ebene, die festlegt, wie eine einzelne Nachricht — ein Frame — aufgebaut ist und wie viele Nutzdaten hineinpassen. Erst darüber folgen Transport- und Anwendungsschicht, die entscheiden, was eine Nachricht inhaltlich bedeutet: ein Messwert, ein Fehlercode, eine Diagnosesitzung.

„CAN-Fehler“ als Diagnose ist deshalb zu unscharf, weil er offenlässt, auf welcher dieser Ebenen das eigentliche Problem sitzt. Ein wackelnder Steckkontakt ist ein physikalisches Problem. Ein überlasteter Bus mit zu vielen Nachrichten pro Sekunde ist ein Data-Link-Problem. Eine abgelehnte Diagnoseanfrage, weil das Steuergerät gerade in der falschen Sitzung steckt, ist ein Anwendungsproblem. Alle drei können sich im Fahrzeug ähnlich äußern — eine Warnleuchte, ein sporadischer Ausfall, ein Diagnosetool, das „keine Antwort“ meldet —, brauchen aber völlig unterschiedliche Prüfschritte.

Für jede Messgröße lohnt sich deshalb dieselbe Frage: Auf welcher Ebene gilt dieser Wert, und woher stammt er? Ein direkt gemessener Spannungspegel ist etwas anderes als ein aus dem Steuergerät ausgelesener Softwarewert. Und beide sind wieder etwas anderes als eine Herstellerangabe aus einem Datenblatt. Wer diese Herkunft nicht sauber trennt, vermischt am Ende Ebenen, die im Fahrzeugnetzwerk physisch getrennt verkabelt sind.

Classical CAN: die Basis seit den Achtzigern

Classical CAN — häufig auch CAN 2.0 oder inzwischen CAN CC (Classic) genannt — ist die älteste und am weitesten verbreitete Variante der Protokollfamilie. Sie transportiert je Nachricht maximal 8 Byte Nutzdaten und erreicht eine nominelle Datenrate von bis zu 1 Mbit/s. Zwei verdrillte Leitungen genügen. Das Signal wird differenziell übertragen, also als Spannungsdifferenz zwischen beiden Adern. Das macht das Netz robust gegenüber elektromagnetischen Störungen, wie sie im Motorraum reichlich vorkommen.

Der Clou von Classical CAN liegt in der Art, wie sich mehrere Steuergeräte im Fahrzeugnetzwerk den Bus teilen, ohne dass eine zentrale Instanz den Takt vorgibt. Jede Nachricht trägt eine Kennung. Wenn zwei Steuergeräte gleichzeitig senden wollen, gewinnt automatisch die Nachricht mit der niedrigeren, also dominanteren Kennung — ohne Kollision, ohne Datenverlust, rein über die elektrische Eigenschaft der Leitung. Dieses Verfahren heißt Arbitrierung. Es ist einer der Gründe, warum sich Classical CAN seit den Achtzigerjahren praktisch unverändert in fast jedem Fahrzeugnetzwerk findet, von der Antriebssteuerung bis zum Fahrwerk.

Die Kehrseite ist die knappe Nutzlast. 8 Byte reichen für einen Drehzahlwert, ein Bit-Flag oder einen kurzen Statuswert gut aus. Eng wird es, sobald ein Steuergerät größere Datenblöcke überträgt — etwa signierte, per SecOC authentisierte Nachrichten oder umfangreichere Messwertpakete moderner Sensorik. Genau an diesem Engpass setzt die nächste Generation an.

CAN FD: mehr Nutzdaten, mehr Tempo in der Datenphase

CAN FD steht für Flexible Data-Rate und löst genau das Nutzlastproblem von Classical CAN. Eine CAN-FD-Nachricht trägt bis zu 64 Byte Nutzdaten, das Achtfache der klassischen Variante. Für die eigentliche Übertragung dieser Nutzdaten schaltet das Protokoll zudem auf eine höhere Datenrate um. Die Arbitrierungsphase, in der die Buszuteilung entschieden wird, läuft weiterhin mit maximal 1 Mbit/s wie bei Classical CAN. Die anschließende Datenphase erreicht in der Praxis Datenraten von rund 5 Mbit/s.

Dieser Wechsel innerhalb einer einzigen Nachricht ist technisch der eigentliche Kern von CAN FD. Er bringt mehr Tempo genau dort, wo es zählt — beim eigentlichen Datenblock —, ohne die Kompatibilität zur bewährten Arbitrierung von Classical CAN aufzugeben. Für Steuergeräte bedeutet das: größere Sensordatensätze, umfangreichere Diagnoseantworten oder zusätzliche Sicherheitsinformationen passen in eine einzelne Nachricht. Sie müssen nicht mehr auf mehrere Frames verteilt werden. Das reduziert den organisatorischen Aufwand im Steuergerät spürbar und macht CAN FD zur bevorzugten Wahl für neuere Zweige eines Fahrzeugnetzwerks.

Die aktuelle Data-Link- und Physical-Coding-Schicht für die gesamte CAN-Familie, einschließlich CAN FD, ist in der Norm ISO 11898-1:2024 festgelegt. Diese Ausgabe deckt inzwischen drei Protokollgenerationen gleichzeitig ab: Classical CAN, CAN FD und CAN XL. Alle drei teilen dieselbe logische Grundstruktur, unterscheiden sich aber in Nutzlast und Datenrate. Wichtig für die Praxis: Diese Norm beschreibt nur die logische Ebene. Welcher physikalische Transceiver ein Steuergerät tatsächlich anspricht, steht in einer eigenen Norm — dazu gleich mehr.

CAN XL: der Schritt in Richtung großer Datenblöcke

CAN XL ist die dritte und bislang jüngste Generation der Protokollfamilie. Sie erweitert die Nutzlast noch einmal drastisch auf bis zu 2.048 Byte je Nachricht und erreicht Datenraten von bis zu 20 Mbit/s. Damit schließt CAN XL bewusst eine Lücke: Es liegt zwischen der Datenmenge, die CAN FD noch komfortabel bewältigt, und der Bandbreite, die erst Ethernet liefert. Steuergeräte, die ohnehin schon einen CAN-XL-fähigen Controller besitzen, können weiterhin auch klassische CAN- und CAN-FD-Nachrichten senden und empfangen. Die neue Generation ersetzt die alten also nicht abrupt. Sie kommt zunächst dort im Fahrzeugnetzwerk zum Einsatz, wo besonders große Datenblöcke anfallen — etwa an Gateways und Zonensteuergeräten, die mehrere Subnetze bündeln.

Technisch wichtig ist eine Unterscheidung, die in der Praxis häufig durcheinandergerät. ISO 11898-1:2024 enthält CAN XL auf der Data-Link- und Physical-Coding-Ebene — also die Frage, wie eine Nachricht logisch aufgebaut ist. Die davon getrennte physikalische Übertragungsebene, die eigentliche elektrische Ansteuerung mit hoher Datenrate, regelt eine eigene Norm: ISO 11898-2. Die aktuell gültige Ausgabe ist ISO 11898-2:2026 und hat die vorherige Fassung von 2024 abgelöst. Wer ein Diagnosegerät oder einen Transceiver als „CAN-XL-fähig“ bewirbt, muss also für beide Ebenen — logisch und physikalisch — die passende, aktuelle Norm erfüllen. Ein Gerät, das nur die logische Seite beherrscht, funktioniert an einem physikalischen High-Speed-Bus nach der neuesten Fassung nicht automatisch mit.

Low-Speed Fault-Tolerant CAN: langsamer, aber ausfallsicherer

Neben den schnellen Varianten existiert seit Jahrzehnten eine deutlich langsamere CAN-Auslegung, die in der Praxis oft übersehen wird: Low-Speed Fault-Tolerant CAN, festgelegt in ISO 11898-3:2006. Diese physikalische Ausführung arbeitet in einem Datenratenbereich zwischen 40 und 125 kbit/s, also deutlich unterhalb der schnellen High-Speed-Varianten. Dafür bringt sie einen entscheidenden Vorteil: Sie ist so ausgelegt, dass die Kommunikation auch dann eingeschränkt weiterläuft, wenn eine der beiden Signalleitungen beschädigt ist oder Masseschluss hat.

Diese Ausfallsicherheit macht Low-Speed CAN vor allem in der Komfort- und Karosserieelektrik des Fahrzeugnetzwerks attraktiv — bei Systemen, die notfalls mit reduzierter Leistung weiterlaufen sollen, anstatt komplett auszufallen. Wichtig für die Diagnose: Ein Low-Speed-Bus teilt sich zwar die grundlegende Nachrichtenlogik mit High-Speed-CAN, besitzt aber eine eigene, andere physikalische Schicht. Ein Diagnosegerät, das ausschließlich für High-Speed-Netze ausgelegt ist, liest an einem Low-Speed-Bus deshalb nicht automatisch mit — selbst wenn beide Netze unter demselben Namen „CAN“ laufen. Die physikalische Ebene entscheidet zuerst, nicht der Protokollname.

LIN: das günstige Subnetz für einfache Aufgaben

LIN — Local Interconnect Network — ist innerhalb des Fahrzeugnetzwerks architektonisch das genaue Gegenteil der CAN-Familie, kein langsamerer Verwandter. Statt mehrerer gleichberechtigter Steuergeräte, die sich den Bus per Arbitrierung teilen, besitzt ein LIN-Netz genau einen Steuerknoten und bis zu 15 angeschlossene Teilnehmer, insgesamt also bis zu 16 Knoten in einem Cluster. Der Steuerknoten gibt den kompletten Kommunikationsablauf vor und fragt die Teilnehmer der Reihe nach ab. Eine Arbitrierung wie bei CAN braucht es dafür gar nicht, weil von vornherein feststeht, wer wann sprechen darf.

Die Datenrate liegt bewusst niedrig, zwischen 1 und 20 kbit/s, in der Praxis meist bei 9,6, 10,4 oder 19,2 kbit/s. Für die Aufgaben, die LIN übernimmt, reicht das völlig aus: Fensterheber, Sitzpositionsmotoren, Spiegelverstellung, Verriegelungen, Klimaklappen, Regensensoren oder Lenkradtasten für Tempomat und Radio. Keine dieser Funktionen braucht die Geschwindigkeit oder die Nutzdatenmenge eines CAN-Netzes. Dafür zählt eine möglichst günstige Verkabelung — LIN kommt mit einer einzigen Signalleitung statt eines verdrillten Adernpaars aus. Das spart bei einem Fahrzeug mit Dutzenden solcher Kleinfunktionen spürbar Gewicht, Bauraum und Kosten.

Für die Diagnose folgt daraus eine klare Regel: LIN ist niemals ein Ersatz für CAN oder Ethernet. Es ergänzt beide für genau die Funktionen, bei denen Determinismus und Kosten wichtiger sind als Bandbreite. Ein LIN-Netz hängt in aller Regel über ein Gateway am CAN-Bus. Dort meldet es sich aber nur mit verdichteten Statuswerten, nicht mit den rohen Einzelsignalen seiner Teilnehmer. Wer direkt auf einem LIN-Subnetz mitschneiden will, braucht ein dafür ausgelegtes Werkzeug — kein CAN-Logger, so hochwertig er auch sein mag, liest an einer LIN-Leitung sinnvolle Daten mit.

Ethernet im Fahrzeugnetzwerk: eine andere Bandbreitenklasse

Ethernet ist die jüngste der vier Ebenen im Fahrzeugnetzwerk und unterscheidet sich fundamental von der gesamten CAN-Familie und von LIN. Statt Nachrichten über Arbitrierung oder festen Zeitplan auf einer gemeinsamen Leitung zu verteilen, arbeitet Ethernet paketvermittelt über geschaltete Verbindungen — ähnlich wie ein Netzwerk aus dem Bürobereich, nur automobiltauglich ausgeführt. Die erreichbare Bandbreite liegt dabei in einer völlig anderen Größenordnung als bei CAN XL, gerade dort, wo mehrere Kameras, Radarsensoren oder ein zentrales Steuergerät gleichzeitig große Datenmengen austauschen müssen.

In modernen Zonenarchitekturen übernimmt Ethernet die Rolle des Rückgrats. Zonensteuergeräte sammeln Signale aus ihrer unmittelbaren Umgebung — oft weiterhin über CAN, CAN FD oder LIN — und leiten verdichtete oder große Datenmengen über ein geschaltetes Ethernet-Netz an zentrale Recheneinheiten weiter. CAN allein, so die verbreitete Einschätzung aus der Fahrzeugnetzwerktechnik, war für kompakte, steuerungsorientierte Nachrichten ausgelegt, nicht für den Transport großer Datenmengen, wie sie Kamerabilder oder Softwareaktualisierungen erzeugen. Genau diese Lücke füllt Ethernet.

Welche konkreten Geschwindigkeitsstufen und welche Verkabelungstopologien Automotive Ethernet dafür im Detail nutzt, ordnet ein eigener Beitrag zu 100BASE-T1, 1000BASE-T1 und Multi-Gig-Ethernet ein. Für die Einordnung als vierte Ebene des Fahrzeugnetzwerks reicht die Feststellung: Ethernet bringt eine Bandbreite ins Fahrzeug, die keine CAN-Variante erreichen kann. Dafür stellt es auch andere Anforderungen an Verkabelung, Switches und Diagnosewerkzeuge als die drei anderen Netze.

Warum mehr Mbit/s nicht automatisch schnellere Diagnose bedeutet

Ein verbreiteter Trugschluss lautet: Je höher die Datenrate eines Busses, desto schneller die Diagnose. Das stimmt nur für die reine Übertragungszeit einzelner Bits, nicht für die tatsächlich erlebte Antwortzeit eines Diagnosetools. Dazwischen liegen mehrere Faktoren, die mit der nominellen Datenrate nichts zu tun haben. Dazu zählt die aktuelle Buslast: wie viele andere Nachrichten gerade um denselben Bus konkurrieren. Dazu zählt die Anzahl der Frames, in die eine größere Antwort aufgeteilt werden muss. Und dazu zählen mindestens ein Gateway, das zwischen zwei unterschiedlichen Netzen übersetzt, sowie der Protokoll-Overhead jeder einzelnen Nachricht.

Eine einfache Rechnung macht den reinen Geschwindigkeitsgewinn sichtbar, ohne ihn mit der gesamten Antwortzeit zu verwechseln. Eine CAN-FD-Nachricht mit 64 Byte Nutzdaten entspricht 512 Bit. Bei 500 kbit/s Datenphase braucht die reine Bitübertragung rechnerisch 512 geteilt durch 500.000, also rund 1,02 Millisekunden. Läuft dieselbe Nachricht mit 2 Mbit/s Datenphase, sind es nur noch rund 0,26 Millisekunden. Das ist ein realer Unterschied. Er betrifft aber ausschließlich die Zeit für die reinen Nutzdatenbits — ohne Arbitrierung, ohne Bit-Stopfung, ohne Wartezeit auf freien Buszugriff und ohne die Zeit, die ein zwischengeschaltetes Gateway für die Übersetzung zwischen zwei Netzen braucht.

Genau diese zusätzlichen Schritte erklären, warum zwei Fahrzeuge mit derselben nominellen Busgeschwindigkeit in der Praxis unterschiedlich schnell auf dieselbe Diagnoseanfrage antworten können. Ein stark ausgelasteter Bus lässt niederpriore Nachrichten länger warten. Ein zusätzliches Gateway zwischen Diagnosetool und Zielsteuergerät kostet jedes Mal Verarbeitungszeit. Und eine Antwort, die über mehrere Frames verteilt werden muss, braucht mehr Zeit als eine, die in eine einzige Nachricht passt. Wer eine Diagnosezeit im Fahrzeugnetzwerk beurteilen will, braucht deshalb den ganzen Weg der Nachricht, nicht nur die Datenblattzeile mit der maximalen Bitrate.

Was ein brauchbares Diagnoseprotokoll festhalten muss

Ein Mitschnitt vom Fahrzeugnetzwerk ist nur so gut wie seine Metadaten. Fehlt der Bezug zur physikalischen Ebene, lässt sich ein aufgezeichneter Wert später nicht mehr zuordnen — stammt er von einem High-Speed-CAN, einem Low-Speed-CAN, einem LIN-Subnetz oder von Ethernet? Ohne diese Angabe wird aus einer sauberen Aufzeichnung schnell eine Ansammlung von Zahlen ohne verlässliche Herkunft.

Ein brauchbares Protokoll trennt deshalb konsequent drei Ebenen: die physikalische Herkunft der Nachricht, den Transportweg und die Anwendungsbedeutung. Transportweg heißt: über welchen Bus und über welches Gateway die Nachricht gelaufen ist. Anwendungsbedeutung heißt: was der Wert inhaltlich aussagt. Dazu gehört eine gemeinsame Zeitbasis für alle aufgezeichneten Kanäle, damit sich Ereignisse auf unterschiedlichen Netzen später überhaupt noch in eine zeitliche Reihenfolge bringen lassen. Und dazu gehört der Software- und Kalibrierstand der beteiligten Steuergeräte, weil derselbe Wert je nach Softwarestand unterschiedliche Bedeutung haben kann.

Wer nur den Endwert notiert — „Fehlercode X gesetzt“ — ohne diesen Kontext, verliert genau die Information, die später zwischen einem echten Defekt, einer Wartezeit im Gateway und einer schlicht falsch interpretierten Softwareversion unterscheiden würde. Für eine belastbare Aussage über ein Fahrzeugnetzwerk braucht es deshalb immer die Kette aus Eingangsgröße, Übertragungsweg und tatsächlicher Reaktion, nicht nur den letzten Wert am Ende.

Typische Verwechslungen und bessere Formulierungen

Ein paar Sätze über das Fahrzeugnetzwerk tauchen in Werkstattgesprächen und Foren immer wieder auf, obwohl sie technisch nicht stimmen. Die häufigste lautet: „CAN, das ist doch der eine Datenbus im Auto.“ Richtiger ist: CAN ist eine ganze Protokollfamilie mit mindestens drei Generationen, die sich in Nutzdatenmenge und Datenrate erheblich unterscheiden. Daneben laufen mit LIN und Ethernet noch zwei völlig andere Ebenen desselben Fahrzeugnetzwerks.

Eine zweite verbreitete Annahme lautet: „Mehr Mbit/s heißt automatisch schnellere Diagnose.“ Das gilt nur für die reine Bitübertragungszeit, wie die Rechnung weiter oben zeigt. Buslast, Gateways und Protokoll-Overhead entscheiden mindestens genauso stark über die tatsächlich erlebte Antwortzeit. Eine dritte Verwechslung betrifft LIN: „Das ist doch bloß ein langsameres CAN.“ Tatsächlich ist LIN architektonisch etwas völlig anderes — ein Steuerknoten mit fest zugeteilten Sendezeiten statt mehrerer gleichberechtigter Teilnehmer mit Arbitrierung.

Und eine vierte Verwechslung betrifft CAN XL: „Das ersetzt jetzt sofort das ganze Bordnetz.“ In der Praxis kommt CAN XL zunächst dort zum Einsatz, wo besonders große Datenblöcke anfallen, etwa an Gateways und Zonensteuergeräten, deren Aufbau ein eigener Beitrag zur Domänen- und Zonenarchitektur einordnet, während viele bestehende Classical-CAN- und CAN-FD-Netze im Fahrzeugnetzwerk unverändert weiterlaufen. Eine Migration betrifft selten das gesamte Fahrzeugnetzwerk auf einmal.

Umbauten am Bordnetz und was sie zulassungsrechtlich auslösen

Wer an Steuergeräten, Gateways oder der Busverkabelung eines Fahrzeugnetzwerks arbeitet, bewegt sich technisch schnell in einem Bereich, der über reine Diagnose hinausgeht. Ein zusätzliches Gerät am Diagnosestecker, das nur passiv mitliest, ist etwas anderes als ein Eingriff, der Nachrichten auf dem Bus verändert, ein Gateway umkonfiguriert oder Sicherheitsmechanismen umgeht. Genau diese Unterscheidung im Fahrzeugnetzwerk entscheidet darüber, ob ein Eingriff harmlos bleibt oder Auswirkungen auf den genehmigten Zustand des Fahrzeugs hat.

Umbauten am eigenen Fahrzeug. Ob ein Umbau auf öffentlichen Straßen betrieben werden darf, entscheidet der Genehmigungszustand des Fahrzeugs — die Genehmigung des Teils, der Einbau nach ihren Auflagen und, wo nötig, die Abnahme durch eine dafür zuständige Stelle. Solange diese Kette nicht vollständig ist, gehört der Umbau auf Privatgelände, Testflächen und in nicht öffentliche Bereiche.

Für das Bordnetz kommt eine zusätzliche Grenze hinzu, die rein technischer Natur ist und nichts mit der Zulassung zu tun hat: Zugriffsschutz, Gateways und Update-Absicherung eines Fahrzeugs sind keine Hindernisse, die ein Tuning-Vorhaben einfach umgehen sollte. Ein Eingriff, der Sicherheits- oder Diebstahlschutzfunktionen aushebelt, betrifft nicht nur die eigene Betriebserlaubnis, sondern potenziell auch fremde Systeme und Daten. Die technische Erklärung in diesem Beitrag ersetzt weder eine fahrzeugbezogene Freigabe noch eine Begutachtung — sie erklärt lediglich, wie die Ebenen des Fahrzeugnetzwerks funktionieren und wie sich eine Diagnose sauber aufbaut.

Häufige Fragen

Einordnung: wo die Angaben herkommen

Die Fundstellen stehen hier gebündelt, damit der Fließtext ohne Normkürzel und Herstellerlinks auskommt. Die ISO-Normen sind kostenpflichtige Katalogwerke ohne öffentlich verlinkbaren Volltext und werden deshalb nur im Klartext genannt, ebenso die technischen Herstellerseiten. Der Normtext zu § 19 StVZO ist am 16.09.2026 am amtlichen Angebot gegengelesen.