CAN-Bus-Latenz und Automotive Ethernet: Buslast und Zeitbasis messen

Latenz ist nicht Bandbreite: der Unterschied, der Diagnosen verändert

Bandbreite beschreibt, wie viele Daten ein Netzwerk pro Sekunde tragen kann. Latenz beschreibt etwas anderes: die Zeit, die eine einzelne Nachricht vom Absender bis zum Empfänger braucht. Ein Netzwerk kann eine hohe Bandbreite haben und trotzdem für eine bestimmte Nachricht eine unerwünscht hohe Latenz erzeugen, etwa weil diese Nachricht in einer Warteschlange hinter anderen, wichtigeren Nachrichten steht. Für eine Regelung, die auf ein frisches Sensorsignal angewiesen ist, zählt aber genau diese Ankunftszeit, nicht die theoretische Kapazität der Leitung.

Wer beide Größen verwechselt, sucht Fehler an der falschen Stelle. Ein „schnelles“ Netzwerk mit viel Bandbreite kann für eine einzelne, latenzkritische Nachricht trotzdem zu langsam sein. Und ein Bus mit vergleichsweise wenig Bandbreite kann für eine gut priorisierte Nachricht ausreichend schnell reagieren. Genau diese Unterscheidung trägt den gesamten Beitrag: Es geht um die Zeitebene eines Fahrzeugnetzwerks, nicht um seine elektrische Beschaffenheit und nicht um seine Rohdatenrate.

Vom klassischen CAN-Bus zum Ethernet-Backbone

Ein klassischer CAN-Bus verbindet mehrere Steuergeräte über eine gemeinsame Leitung. Jede Nachricht trägt eine feste Priorität, und bei einer Kollision gewinnt die höher priorisierte Nachricht automatisch. Das funktioniert gut für kleine, klar abgegrenzte Netzwerke. Mit steigender Anzahl an Kameras, Sensoren und Zonensteuergeräten wächst aber die Datenmenge, die zwischen ihnen fließen muss, oft schneller als der klassische Bus sie tragen kann. Genau hier setzen Ethernet-Backbones an, wie sie in modernen Fahrzeugen zunehmend die zentrale Datenverteilung übernehmen. Wie Steuergeräte dabei von der Domäne zur Zone wandern, verändert zusätzlich, welche Nachrichten überhaupt über denselben Pfad laufen.

Dieser Beitrag setzt bewusst eine Ebene oberhalb der reinen Verkabelung an. Wer die elektrische Bus-Ebene mit Widerstand, Pegel und Masse prüft, misst etwas anderes als die Zeitebene. Terminierung und Signalqualität entscheiden, ob eine Nachricht überhaupt sauber ankommt. Dieser Beitrag misst dagegen, wie lange die Ankunft dauert. Beide Ebenen ergänzen sich, ersetzen sich aber nicht. Für die technischen Grundlagen der Leitungsstandards selbst, etwa 100BASE-T1 oder Multi-Gig-Ethernet, ist ein eigener Beitrag zu den Automotive-Ethernet-Standards die passendere Stelle. Auch Zonenarchitektur und Ethernet-Backbone im Zusammenspiel sind dort vertieft, mit Fokus auf die Leistungsseite statt auf die Zeitebene.

Die gemeinsame Zeitbasis: was gPTP wirklich synchronisiert

Mehrere Steuergeräte in einem Netzwerk führen normalerweise jeweils ihre eigene interne Uhr. Ohne Abgleich laufen diese Uhren minimal auseinander, und schon kleine Abweichungen reichen, damit Ereignisse in der falschen Reihenfolge erscheinen. Das Protokoll gPTP, eine Variante des Precision Time Protocol für Ethernet-Netzwerke, gleicht diese Uhren regelmäßig gegeneinander ab. Es meldet dabei einen Synchronisationszustand, einen Offset zwischen den Uhren und eine gemessene Signallaufzeit zwischen zwei Knoten, die sogenannte Pfadverzögerung.

Für eine Latenzmessung ist diese gemeinsame Zeitbasis die Voraussetzung, nicht ein Nebeneffekt. Ohne synchronisierte Uhren lässt sich eine Zeitspanne zwischen zwei Steuergeräten schlicht nicht sauber bestimmen. Zwei unsynchronisierte Uhren können denselben Zeitpunkt völlig unterschiedlich stempeln. Ein Zeitstempel, der auf einem Steuergerät entsteht, ist deshalb nur dann mit einem Zeitstempel auf einem anderen Steuergerät vergleichbar, wenn beide auf dieselbe Zeitbasis zurückgeführt werden können.

Latenz gegen Jitter: zwei Werte, ein Missverständnis

Latenz ist die Zeit, die eine einzelne Nachricht braucht. Jitter ist etwas anderes: die Schwankung dieser Zeit über mehrere Nachrichten hinweg. Eine Verbindung mit gleichbleibend hoher Latenz kann für viele Anwendungen unproblematisch sein, solange sie vorhersehbar bleibt. Eine Verbindung mit im Mittel niedriger, aber stark schwankender Latenz ist dagegen oft die schwierigere. Für eine Regelung zählt nicht nur, wie schnell eine Nachricht im Durchschnitt ankommt, sondern auch, wie stark diese Ankunftszeit von Nachricht zu Nachricht abweicht.

In der Praxis wird Jitter meist als Spanne zwischen der längsten und der kürzesten gemessenen Latenz innerhalb eines Beobachtungsfensters angegeben. Diese Spanne sagt, wie „nervös“ ein Datenpfad ist. Ein System mit kleiner Jitterspanne lässt sich enger auslegen, weil weniger Sicherheitsreserve gegen den ungünstigsten Fall eingeplant werden muss. Ein System mit großer Spanne braucht entweder mehr Reserve oder eine bessere Priorisierung, damit die kritischen Nachrichten nicht in die Streuung der unkritischen geraten.

Deterministisch heißt begrenzt, nicht null

Ein Netzwerk als „deterministisch“ zu bezeichnen, klingt nach einer festen, immer gleichen Zeit. Gemeint ist etwas anderes: Eine deterministische Übertragung garantiert eine obere Grenze für Latenz und Jitter, nicht deren Abwesenheit. Zeitsensitives Networking, kurz TSN, ist eine Sammlung von Ethernet-Erweiterungen, die genau solche oberen Grenzen für bestimmte Verkehrsklassen zusichern. Eine Nachricht mit hoher Priorität bekommt reservierte Zeitfenster oder wird an Switches bevorzugt weitergeleitet, während weniger kritischer Verkehr warten muss.

Wer TSN als einzelne Protokollfunktion behandelt, unterschätzt, wie viele einzelne Bausteine zusammenspielen: Zeitsynchronisation, Verkehrsklassen, reservierte Bandbreite und garantierte Weiterleitungszeiten an jedem einzelnen Switch. Fällt einer dieser Bausteine aus der Reihe, bricht die Garantie zusammen, selbst wenn die übrigen Bausteine weiter korrekt arbeiten. Deshalb wird eine Latenzgarantie immer für den gesamten Pfad geprüft, nicht für ein einzelnes Gerät auf diesem Pfad.

Buslast auf dem CAN-Bus: wo die Grenze liegt

Auf einem klassischen CAN-Bus konkurrieren alle Nachrichten um dieselbe Leitung. Die Buslast beschreibt, wie viel Prozent der verfügbaren Übertragungszeit tatsächlich mit Nachrichten belegt ist. Steigt die Buslast, steigt auch die Wahrscheinlichkeit, dass eine Nachricht mit niedrigerer Priorität länger warten muss, bis die Leitung frei wird. Bei niedriger Buslast bleibt dieser Effekt meist unauffällig. Erst bei hoher, dauerhafter Auslastung wird er zum echten Zeitproblem, besonders für Nachrichten, die selbst niedrig priorisiert sind.

Diese Wartezeit ist kein Fehler des Busses, sondern seine vorgesehene Funktionsweise: Hochpriorisierte Nachrichten setzen sich planmäßig durch. Problematisch wird es erst, wenn eine als unkritisch eingestufte Nachricht bei hoher Buslast plötzlich zeitkritisch wird, etwa weil sich ihre Bedeutung im Fahrzeug geändert hat, ohne dass ihre Priorität angepasst wurde. Genau das ist ein Punkt, an dem eine spätere Nachrüstung unbeabsichtigt neue Lasten in ein bestehendes System einbringen kann. Wer erst prüft, ob Masse, Terminierung und Wake-up am Bus überhaupt sauber sind, schließt die einfacheren Ursachen aus, bevor die Zeitebene überhaupt zur Diagnose wird. Auch das Nebeneinander von CAN, CAN FD, LIN und Ethernet im selben Fahrzeugnetzwerk spielt hier hinein, weil Gateways zwischen diesen Bussen selbst wieder Zeit kosten.

Priorisierung und Warteschlangen: warum eine Nachricht überhaupt wartet

An jedem Switch eines Ethernet-Backbones landen Nachrichten aus mehreren Richtungen gleichzeitig. Nur eine kann in einem Moment tatsächlich weitergeleitet werden. Die übrigen warten in einer Warteschlange, sortiert nach ihrer Verkehrsklasse. Wie lange eine Nachricht in dieser Warteschlange verharrt, hängt davon ab, wie viele höher priorisierte Nachrichten bereits davor liegen und wie schnell der Switch die Warteschlange insgesamt abarbeitet.

Der Anteil der Wartezeit an der Gesamtlatenz ist deshalb ein eigener, messbarer Wert. Er zeigt, wie viel der beobachteten Verzögerung tatsächlich am Warten liegt und wie viel an der reinen Übertragungszeit über die Leitung. Ein hoher Warteschlangenanteil weist auf einen überlasteten oder falsch priorisierten Pfad hin. Ein niedriger Anteil bei trotzdem hoher Gesamtlatenz deutet eher auf einen langen physischen Pfad oder viele hintereinandergeschaltete Switches hin – zwei unterschiedliche Ursachen, die zwei unterschiedliche Abhilfen brauchen. Dienste wie SOME/IP und DDS fragen Daten außerdem erst bei Bedarf an, statt sie fest verdrahtet zu senden, und verschieben damit einen Teil der Wartezeit von der Leitung in die Anwendungsebene.

Mittelwert gegen Worst Case: der teuerste Denkfehler

Eine mittlere Latenz beschreibt das typische Verhalten eines Pfads. Für eine sicherheitsrelevante Anwendung zählt aber nicht der typische Fall, sondern der ungünstigste innerhalb eines definierten Zeitfensters. Wer eine mittlere Latenz mit dem Worst Case gleichsetzt, unterschätzt systematisch das Risiko einer verspäteten Nachricht. Genau dieser Fehler zählt zu den teuersten Denkfehlern bei Latenzmessungen im Fahrzeug.

Ein robustes Messverfahren gibt deshalb nie nur einen einzigen Wert an. Es nennt Mittelwert, eine hohe Perzentilgrenze wie den 99. Perzentilwert und den bisher beobachteten Maximalwert nebeneinander. Nur so lässt sich beurteilen, ob ein System auch in seltenen, ungünstigen Momenten innerhalb seiner Vorgaben bleibt. Ein System, das im Mittel hervorragend aussieht, aber gelegentlich weit ausreißt, ist für eine zeitkritische Funktion riskanter als eines mit etwas höherem, aber stabilem Mittelwert.

Der Messpunkt entscheidet, was eine Messung wert ist

Eine Latenz zwischen „Sender“ und „Empfänger“ zu nennen, klingt eindeutig, ist es aber oft nicht. Wird am Anwendungsprozess gemessen, an der Netzwerkschnittstelle des Steuergeräts oder direkt am Switch-Port? Jede dieser Stellen liefert einen anderen Wert, weil zwischen ihnen jeweils zusätzliche Verarbeitungsschritte liegen. Eine Messung an der Anwendung schließt beispielsweise auch die interne Verarbeitungszeit im Steuergerät mit ein, eine Messung am Port dagegen nicht.

Für einen belastbaren Vergleich zweier Messungen muss deshalb feststehen, an welchem Punkt jeweils gemessen wurde. Zwei Zahlen ohne benannten Messpunkt lassen sich nicht seriös gegeneinander bewerten, selbst wenn sie auf den ersten Blick ähnlich aussehen. Wer eigene Werte veröffentlicht oder mit fremden vergleicht, nennt deshalb immer die genaue Messstelle dazu – sonst bleibt unklar, ob ein Unterschied real ist oder nur aus einem anderen Messpunkt stammt. Bei einer UDS-Diagnose über DoIP oder CAN gilt dieselbe Regel: Der Messpunkt entscheidet, ob eine gemessene Antwortzeit die Diagnoseanwendung, das Gateway oder nur die reine Übertragung beschreibt.

Was ein Zeitversatz zwischen Steuergeräten in der Praxis anrichtet

Wenn zwei Steuergeräte über verschiedene Zeitbasen berichten, können ihre gemeldeten Ereignisse scheinbar in der falschen Reihenfolge erscheinen. Ein Sensorwert wirkt dann älter oder jünger, als er tatsächlich ist. Für eine reine Anzeige ist das meist unproblematisch. Für eine Funktion, die aus mehreren Signalen eine gemeinsame Entscheidung ableitet, kann ein solcher Zeitversatz dagegen zu einer falschen Reihenfolge in der Bewertung führen.

Bevor ein auffälliges Log als Beweis für eine bestimmte Ursache gilt, wird deshalb zuerst die Zeitbasis der beteiligten Steuergeräte geprüft. Stimmen die Zeitstempel nicht überein, ist jede daraus abgeleitete Reihenfolge unsicher. Erst wenn die Zeitbasis gesichert ist, lohnt sich der nächste Schritt: der Vergleich der eigentlichen Inhalte. Diese Reihenfolge – zuerst die Zeit, dann der Inhalt – verhindert, dass ein nachgelagerter Effekt fälschlich zur Ursache erklärt wird.

Retrofit und Nachrüstung: neue Lasten, neue Zeitpfade

Ein nachgerüstetes Steuergerät oder eine zusätzliche Kamera kann technisch einwandfrei funktionieren und trotzdem neue Zeitpfade in ein bestehendes Netzwerk einbringen. Zusätzlicher Datenverkehr erhöht die Buslast oder die Auslastung eines Switches, selbst wenn das neue Gerät selbst keine besonders zeitkritischen Nachrichten sendet. Andere, bereits vorhandene Nachrichten können dadurch länger in ihren Warteschlangen verharren als vor der Nachrüstung.

Deshalb wird jede Nachrüstung an einem Datennetz als Systemänderung dokumentiert, nicht nur als eingebautes Bauteil. Ein Steuergerät, das plötzlich nicht mehr kommuniziert, muss dabei nicht defekt sein – häufig liegt die Ursache im Gateway oder in der Netzwerktopologie, nicht im Bauteil selbst. Vorher- und Nachher-Messungen von Buslast und Latenz gehören deshalb in die Dokumentation jeder Nachrüstung, die neue Teilnehmer in ein bestehendes Netzwerk einbringt. Das gilt auch für scheinbar reine Stromthemen: Der Weg vom klassischen Sicherungskasten zur Smart Fuse macht Leistungsverteilung selbst zu einem Softwaredienst im Netzwerk, mit eigenem Zeitverhalten. Und ein Software-Update über die Luftschnittstelle kann Prioritäten, Warteschlangenlängen oder sogar Zeitsynchronisationsparameter verändern, ohne dass am Kabelbaum etwas sichtbar anders wäre.

Ein Rechenbeispiel: Jitterspanne, Offset und Reserve einordnen

Ein einfaches Zahlenbeispiel zeigt, wie die Größen zusammenhängen, ohne dass daraus eine Aussage über ein bestimmtes Fahrzeug wird. Angenommen, die längste gemessene Latenz in einem Beobachtungsfenster liegt bei 5,1 Millisekunden, die kürzeste bei 2,5 Millisekunden. Daraus ergibt sich eine Jitterspanne von 2,6 Millisekunden. Zwei Uhren im selben Netzwerk weichen dabei um 4 Millisekunden voneinander ab, gemessen als Betrag der Differenz.

Die dritte Zeile zeigt, warum eine Reserve zum vereinbarten Zeitbudget mehr aussagt als eine einzelne Latenzzahl. Ein System mit 2,4 Millisekunden Reserve zu seinem 99.-Perzentil-Wert verträgt noch spürbare Zusatzlast, bevor es sein Budget reißt. Ein System ohne diese Reserve ist bereits an seiner Grenze, auch wenn der aktuelle Mittelwert unauffällig aussieht. Dieses Beispiel ist ausdrücklich ein Rechenmodell zur Veranschaulichung, keine Spezifikation für ein bestimmtes Fahrzeug oder Netzwerk – reale Werte hängen von Topologie, Buslast und der tatsächlichen Zahl der Teilnehmer ab.

Häufige Fragen

Einordnung: wo die Angaben herkommen

Dieser Beitrag ordnet die Zeit- und Latenzebene von CAN-Bus und Automotive Ethernet ein und benennt seine technischen Quellen im Klartext. Normtitel werden nur bis zu dem öffentlich belegbaren Status eingeordnet – ein Entwurf oder ein laufendes Revisionsverfahren wird nicht als bereits geltende Endfassung dargestellt.

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.