Warum Automotive Ethernet CAN in neuen Elektrofahrzeugen verdrängt (Tesla, Lucid, Porsche Taycan)

Okay, sprechen wir über etwas, das ich immer häufiger in der Werkstatt sehe, besonders bei diesen neueren Elektrofahrzeugen. Jahrelang, wenn ein Auto Probleme machte, suchte man nach offensichtlichen Dingen: einer Kühlmittelleckage, abgenutzten Riemen oder einem defekten Sensor. Doch heutzutage ist das eigentliche Problem oft kein mechanischer Ausfall, sondern ein Kommunikationsausfall. Ich spreche vom internen Netzwerk des Fahrzeugs, der digitalen Autobahn, über die alle Computer – die ECUs – miteinander kommunizieren.

Jahrzehntelang war diese Autobahn der CAN-Bus (Controller Area Network). Und lassen Sie mich klarstellen: Der CAN-Bus ist ein robustes, zuverlässiges Protokoll. Er war ein Arbeitstier. Aber moderne Autos? Sie sind vollgepackt mit ADAS-Sensoren, hochauflösenden Kameras und versuchen ständig, große Over-the-Air-Updates (OTA) herunterzuladen. Wir bringen den alten CAN-Bus an seine Grenzen, und das zeigt sich jetzt.

Erkennen der Anzeichen: Wenn das Netzwerk das Problem ist

Wie sieht ein überlastetes Netzwerk also konkret aus? Es ist nicht immer ein klarer „Check Engine“-Warnhinweis. Oft handelt es sich um eine Ansammlung von Symptomen, die darauf hindeuten, dass die interne Kommunikation des Fahrzeugs Probleme hat. Darauf achte ich:

1. Langsame oder fehlgeschlagene Over-the-Air (OTA)-Updates

Dies ist einer der ersten deutlichen Hinweise. Ein Kunde kommt herein und sagt, sein Auto schaffe das Update nicht oder es dauere ewig. Ihr erster Gedanke könnte ein defektes Telematiksteuergerät (TCU) oder ein schlechtes Mobilfunksignal sein. Und ja, das können die Ursachen sein. Doch wenn Sie die Signalstärke überprüft und das TCU als in Ordnung befunden haben, beginne ich, das Netzwerk zu untersuchen. Der CAN-Bus kann einfach nicht mit den riesigen Datenmengen moderner Firmware-Updates umgehen. Er ist zu langsam, in der Praxis maximal etwa 1 Mbps. Wenn Sie Gigabytes durch diesen Kanal drücken, wird er sich verschlucken.

2. Vorübergehender Ausfall von Multikamerasystemen oder ADAS-Funktionen

Hatten Sie schon einmal einen Kunden, der sich beschwert, dass die 360-Grad-Kameraperspektive ausfällt oder die automatische Parkhilfe zufällig deaktiviert wird, besonders unter hoher Last (wie im Stau oder wenn andere Systeme aktiv sind)? Dies liegt nicht immer an einem defekten Kameramodul oder einem beschädigten Koaxialkabel. Hochauflösende Videostreams und ständige Sensordaten von ADAS-Systemen erfordern erhebliche Bandbreite. Wenn der CAN-Bus oder sogar die älteren LVDS-Verbindungen überlastet sind, werden diese Datenströme unterbrochen. Das System kann die Informationen einfach nicht schnell genug übertragen und gibt auf.

3. Korrelierte Fehler in scheinbar unabhängigen Systemen

Dies ist für mich ein großes Warnsignal. Wenn Stabilitätsregelung, Batteriemanagementsystem (BMS) und Infotainmentsystem gleichzeitig Fehler melden, besonders wenn das Fahrzeug stark beansprucht wird, ist es selten der Fall, dass drei separate Module gleichzeitig ausfallen. Wahrscheinlicher ist eine Nachrichtenüberlastung im CAN-Netzwerk. Der CAN-Bus verwendet eine prioritätsbasierte Nachrichtenübertragung, aber wenn der Bus überlastet ist, können Nachrichten mit niedrigerer Priorität unbestimmt verzögert oder sogar verworfen werden. Dies führt zu Koordinationsausfällen bei zeitkritischen Systemen und lässt es so aussehen, als wären mehrere Komponenten defekt, obwohl es eigentlich das Kommunikationsgerüst ist.

4. „Softwareinkompatibilität“ für neue Funktionen

Manchmal akzeptiert ein Auto einfach keine neue Softwarefunktion, oder ein Modul scheint im Netzwerk zu verschwinden. Die CAN-Architektur basiert auf einer statischen, vordefinierten Nachrichtendatenbank. Sie ist nicht für dynamische Dienstentdeckung ausgelegt, bei der neue Module oder Funktionen sich einfach „ankündigen“ und mit der Kommunikation beginnen können. Wenn das Auto eine neue Softwarefunktion nicht dynamisch integrieren kann, stößt es möglicherweise an eine grundlegende architektonische Grenze des CAN-Busses.

Wie ich das Problem genau identifiziere: Komponente vs. Netzwerk

Die größte Herausforderung hier besteht darin, herauszufinden, ob Sie es mit einer tatsächlich defekten Komponente zu tun haben oder ob das gesamte Netzwerk einfach an seine Grenzen stößt. Ein lockerer Stecker oder ein defekter Sensor kann definitiv Netzwerküberlastung vortäuschen, daher benötigen Sie präzise Tests, um andere Ursachen auszuschließen. So gehe ich vor:

Warum der CAN-Bus an seine Grenzen stößt

Es ist wichtig zu verstehen, dass der CAN-Bus nicht „kaputt“ ist. Er wurde einfach nie für die heutigen Anforderungen konzipiert. Die Ursachen dieser Netzwerkprobleme liegen nicht in einzelnen Hardwareausfällen, sondern im Protokoll selbst. Stellen Sie sich vor, Sie versuchen, einen Supercomputer über eine Internetverbindung aus den 1990er Jahren zu betreiben.

1. Bandbreitenüberlastung

Der CAN-Bus hat eine harte Obergrenze von etwa 1 Mbps unter realen Bedingungen. Das ist völlig ausreichend für kleine, einfache Nachrichten wie Motordrehzahl, Getriebetemperatur oder ob eine Tür offen ist. Aber völlig nutzlos für Videostreaming, die Verarbeitung riesiger Lidar-Datenmengen oder das Herunterladen vollständiger OTA-Updates. Sie können die Geschwindigkeit des CAN-Busses nicht einfach „aufrüsten“, ohne die gesamte physikalische Schicht auszutauschen und jedes einzelne Modul neu zu programmieren – was bei bestehenden Fahrzeugarchitekturen nicht machbar ist.

2. Nicht-deterministische Latenz

Der CAN-Bus verwendet Nachrichtenpriorisierung. Wichtige Nachrichten werden also zuerst gesendet. Doch bei hohem Verkehr können Nachrichten mit niedrigerer Priorität unvorhersehbar verzögert werden. Für Systeme wie Bremsen, Lenken oder fortschrittliche Fahrerassistenzsysteme, bei denen die Timing absolut kritisch ist, ist dies nicht akzeptabel. Moderne Architekturen erfordern deterministische Kommunikation – das bedeutet garantierte Zustellung innerhalb eines festen, vorhersehbaren Zeitrahmens. Der CAN-Bus kann dies unter hoher Last einfach nicht bieten.

3. Skalierbarkeitsprobleme

Der CAN-Bus ist ein Broadcast-Netzwerk. Jeder einzelne Knoten im Netzwerk erhält jede einzelne Nachricht. Wenn Sie mehr ECUs hinzufügen, wächst der Netzwerk-Overhead exponentiell. Es ist, als würde jeder im Raum jede Nachricht herausschreien, auch wenn sie nur für eine Person bestimmt ist. Es wird schnell laut und ineffizient. Genau deshalb haben Hersteller wie Tesla und Porsche diese „Spaghetti-Harness“-Methode zugunsten zonaler Architekturen mit Automotive-Ethernet-Backbones aufgegeben.

Was können wir dagegen wirklich tun? (Die harte Wahrheit)

Hier wird es für uns in der Werkstatt schwierig. Wenn Sie es mit einer grundlegenden Beschränkung der Netzwerkarchitektur zu tun haben, „reparieren“ Sie das nicht im herkömmlichen Sinne. Es geht um eine Neugestaltung der Architektur, und das liegt meist weit außerhalb unseres Rahmens als Techniker. Die Möglichkeiten hängen vollständig davon ab, ob Sie ein OEM sind, der ein Fahrzeug entwickelt, oder ein Techniker, der ein bestehendes Fahrzeug wartet.

Überprüfung der „Reparatur“: Mehr als nur eine Probefahrt

Wenn ein Fahrzeug tatsächlich eine architektonische Verbesserung erhält – wie eine Gateway-Integration – oder sogar ein großes Software-Update für Netzwerkprobleme, können Sie nicht einfach Ihren OBD-II-Scanner anschließen und es als erledigt betrachten. Wir müssen den gesamten Datenfluss validieren, und das bedeutet, über die Grundlagen hinauszugehen.

Bei einem hybriden CAN-Ethernet-System ist der entscheidende Wert, auf den ich achte, die Übersetzungsverzögerung. Wie schnell wandelt das Gateway veraltete CAN-Signale um und überträgt sie auf den Ethernet-Backbone? Wir sprechen hier von minimaler Verzögerung, idealerweise unter 100 Mikrosekunden. Bei mehr Verzögerung beginnen zeitkritische Systeme zu stottern.

Bei einer vollständigen zonalen Architektur ist die Validierung noch komplexer. Alle ECUs müssen innerhalb von etwa 500 Millisekunden nach dem Aufwachen des Fahrzeugs Dienstentdeckung über Protokolle wie SOME/IP durchführen. Wenn sie sich nicht schnell genug finden, treten Startverzögerungen oder fehlende Funktionen auf. Ich simuliere auch Szenarien mit hoher Last – wie ein großes OTA-Update –, um sicherzustellen, dass die Netzwerk-Switches keine Pakete verlieren oder ihre Puffer überlaufen. Und schließlich prüfe ich Ethernet-basierte DTCs, die über Diagnostic over Internet Protocol (DoIP) gemeldet werden. Dies sind Verbindungsfehler oder CRC-Fehler, die Ihr generischer Scan-Tool nicht einmal erkennt.

Die Quintessenz: Was das für Besitzer und Techniker bedeutet

Seien wir ehrlich: Das ist keine billige oder einfache Angelegenheit. Für uns in der Werkstatt geht es darum, die Grenzen dessen zu verstehen, womit wir arbeiten. Für den Verbraucher geht es darum, kluge Entscheidungen zu treffen.

Als Techniker verändert sich unsere Rolle. Wir müssen verstehen, warum diese Systeme ausfallen, auch wenn wir die zugrundeliegende Architektur nicht selbst „reparieren“ können. Es bedeutet, über das bloße Lesen eines P-Codes hinauszugehen und Netzwerktopologie, Datenfluss und Latenz zu verstehen. Wir werden genauso Netzwerktechniker wie Mechaniker.

Der Blick nach vorn: Gestaltung für die digitale Straße

Für die Automobilhersteller sind die Lehren klar. Die Prävention beginnt in der Entwurfsphase. Die Implementierung von Automotive Ethernet mit Time-Sensitive Networking (TSN)-Standards gewährleistet deterministische Kommunikation und hohe Bandbreite. Dies ist heute Standard bei EVs wie der Tesla-Baureihe und dem Porsche Taycan und die Richtung, in die sich die Branche bewegt.