DoIP oder CAN — wie die UDS-Diagnose im Auto tatsächlich übertragen wird

Warum UDS überhaupt einen Transportweg braucht

UDS beschreibt, welche Diagnosedienste ein Steuergerät anbietet, aber nicht, wie die dazugehörigen Bytes das Fahrzeug tatsächlich durchqueren. Diese Trennung ist kein Zufall, sondern bewusst so konstruiert. Die Anwendungsschicht bleibt datenlinkunabhängig, damit dieselbe Diagnoselogik auf ganz unterschiedlichen Bordnetzen funktioniert, ohne bei jedem neuen Bustyp neu erfunden zu werden.

Zwischen der Anwendung und dem eigentlichen Bus sitzt deshalb eine eigene Sitzungsschicht, die genau diese Abstraktion herstellt. Sie übernimmt eine Diagnoseanfrage aus der Anwendungsschicht und reicht sie an denjenigen Transport- und Netzwerkdienst weiter, der auf dem jeweiligen Fahrzeug tatsächlich verbaut ist. Für ältere und viele mittlere Baureihen ist das der CAN-Bus über DoCAN, für Zonenarchitekturen mit Ethernet-Rückgrat zunehmend DoIP. Beide Wege liefern am Ende dieselbe UDS-Nachricht beim Steuergerät ab, nur auf komplett unterschiedlichen physikalischen Strecken.

DoCAN: wie eine UDS-Nachricht über den CAN-Bus reist

DoCAN, genormt in ISO 15765-2, ist der Transportweg für UDS über CAN-basierte Netzwerke. Der Name steht für Diagnostic communication over Controller Area Network, und die Norm liegt seit April 2024 in ihrer vierten, aktuellen Ausgabe vor. Sie definiert, wie eine Diagnosenachricht in CAN-Frames verpackt, über den Bus geschickt und beim Empfänger wieder zu einer vollständigen Nachricht zusammengesetzt wird.

Der Grund, warum das überhaupt nötig ist, liegt in der Natur des klassischen CAN-Busses. Ein einzelner CAN-Frame trägt höchstens acht Byte Nutzdaten, eine UDS-Anfrage oder -Antwort kann aber deutlich größer sein, etwa ein längerer Messwertblock oder ein Datenblock beim Flashen. DoCAN löst das über ein eigenes Transportprotokoll, das in der Praxis als ISO-TP bekannt ist. Es zerlegt eine zu große Nachricht in mehrere Frames, nummeriert sie durch und stellt beim Empfänger sicher, dass am Ende wieder die vollständige, unverfälschte Nachricht ankommt.

Warum eine UDS-Nachricht zerlegt werden muss

Passt eine Nachricht vollständig in einen einzigen Frame, reicht ein sogenannter Single Frame. Abzüglich eines Steuerbytes bleiben beim klassischen CAN-Frame rund sieben Byte für die eigentlichen Nutzdaten übrig, mehr passt physikalisch nicht hinein. Ist die Nachricht größer, beginnt die Übertragung mit einem First Frame. Er nennt die Gesamtlänge der Nachricht und trägt bereits die ersten Nutzdaten-Bytes.

Danach folgen sogenannte Consecutive Frames, die den Rest der Nachricht in fortlaufend nummerierten Häppchen nachliefern. Damit der Sender nicht schneller schickt, als das Steuergerät verarbeiten kann, schaltet sich zwischen First Frame und den Consecutive Frames ein Flow-Control-Frame vom Empfänger ein. Er sagt dem Sender, wie viele Frames er am Stück schicken darf und wie viel Pause dazwischen liegen soll. Genau diese Taktung ist einer der Gründe, warum eine größere UDS-Übertragung über DoCAN spürbar länger dauert als die reine Rechnung aus Byteanzahl und Busgeschwindigkeit vermuten lässt.

DoIP: wie eine UDS-Nachricht über Ethernet reist

DoIP, genormt in ISO 13400-2, überträgt dieselbe UDS-Nachricht stattdessen über Internet Protocol. Die aktuelle Fassung stammt aus dem Juni 2025 und ist die dritte Ausgabe der Norm. Statt CAN-Frames mit acht Byte Nutzlast nutzt dieser Weg ein IP-basiertes Netzwerk, in dem eine einzelne Nachricht ohne die kleinteilige Segmentierung von DoCAN in einem einzigen Paket Platz findet, solange sie in die üblichen Ethernet-Rahmengrößen passt.

Für den eigentlichen Datenaustausch setzt dieser Transportweg auf TCP, also eine verbindungsorientierte Übertragung mit eingebauter Fehlerkontrolle und erneutem Senden verlorener Pakete. Für die Suche nach Fahrzeugen im Netzwerk kommt dagegen UDP zum Einsatz, ein verbindungsloses Protokoll, das sich für kurze Broadcast-Nachrichten besser eignet als eine aufwendig aufgebaute TCP-Verbindung. Die Norm definiert außerdem eigene Gateway-Funktionen, die dafür sorgen, dass eine Diagnoseanfrage vom externen Testgerät über das richtige Steuergerät im richtigen internen Segment landet und nicht einfach im gesamten Bordnetz verteilt wird.

Wie ein Testgerät das Fahrzeug über DoIP überhaupt findet

Bevor eine solche IP-Verbindung überhaupt Diagnosedaten überträgt, muss sich das Testgerät im Netzwerk zurechtfinden. Dafür sieht die Norm eine eigene Erkennungsphase vor. Ein Gateway im Fahrzeug sendet nach dem Einschalten eine Ankündigungsnachricht per UDP, die unter anderem die Fahrzeug-Identifikationsnummer und die eigene Netzwerkadresse enthält. Ein Testgerät kann diese Nachricht abwarten oder aktiv per Broadcast danach fragen.

Danach folgt ein zweiter Schritt, der oft übersehen wird: die sogenannte Routing-Aktivierung. Das Testgerät meldet dem Gateway, mit welcher Quelladresse und zu welchem Zweck es Zugriff möchte, und erst nach einer positiven Antwort leitet das Gateway die folgenden Diagnoseanfragen tatsächlich an das gewünschte Steuergerät weiter. Diese zwei Schritte, Erkennung und Aktivierung, finden statt, bevor überhaupt eine einzige UDS-Anwendungsnachricht auf dem Weg ist. Genau das kostet Zeit, die bei DoCAN in dieser Form nicht anfällt, weil dort der Bus selbst schon die Adressierung übernimmt.

Warum ein Fahrzeug beide Wege gleichzeitig braucht

In der Praxis besitzt ein modernes Fahrzeug häufig nicht nur einen einzigen Diagnosepfad. Viele Komponenten mit geringem Bandbreitenbedarf, etwa Sitz-, Tür- oder Klimasteuergeräte, hängen weiterhin an einem klassischen CAN-Bus und werden über DoCAN erreicht. Kameras, zentrale Steuergeräte oder Systeme mit hohem Datenaufkommen sitzen dagegen zunehmend an einem Ethernet-Rückgrat und laufen über DoIP. Ein zentrales Gateway übersetzt zwischen beiden Welten, sodass ein einziges Diagnosetool am Fahrzeugstecker am Ende beide Wege nutzen kann.

Für die Fehlersuche bedeutet das: Ein Log, das nur „Diagnose fehlgeschlagen“ notiert, verschweigt eine wichtige Information. Erst wenn feststeht, ob die betroffene Anfrage über DoCAN oder über DoIP unterwegs war, lässt sich der Fehler überhaupt der richtigen Ebene zuordnen. Ein Problem auf dem CAN-Segment und ein Problem auf dem Ethernet-Segment haben unterschiedliche Ursachen und brauchen unterschiedliche Prüfschritte, auch wenn am Ende dieselbe UDS-Fehlermeldung im Tool auftaucht.

Warum eine gestörte Verbindung bei beiden Wegen unterschiedlich ausfällt

CAN bringt seine Fehlerprüfung direkt auf Busebene mit. Jeder Frame trägt eine eigene Prüfsumme, und ein Empfänger bestätigt den korrekten Empfang aktiv im selben Frame. Kommt keine Bestätigung zurück, wiederholt der Sender die Übertragung automatisch, noch bevor DoCAN als Transportschicht überhaupt etwas davon merkt. Für eine kurze Störung bedeutet das: Der Bus fängt sie meist selbst ab, und die Diagnose bemerkt allenfalls eine kleine Verzögerung.

Beim IP-basierten Weg läuft die Absicherung auf einer anderen Ebene. TCP erkennt einen Paketverlust erst mit einer gewissen Verzögerung und fordert die fehlenden Daten dann erneut an, während UDP für die Fahrzeugerkennung gar keine eingebaute Wiederholung kennt und im Zweifel einfach verloren geht. Fällt die physische Netzwerkverbindung dagegen ganz aus, etwa durch einen gelösten Steckkontakt, sieht die Norm dafür eine eigene Fehlerbehandlung vor, die eine bestehende Diagnosesitzung sauber beendet, statt sie unbestimmt hängen zu lassen. Ein Diagnosetool sollte deshalb bei diesem Transportweg klar zwischen einem kurzen Paketverlust, der sich selbst korrigiert, und einem physischen Verbindungsabbruch unterscheiden, der eine neue Erkennungs- und Aktivierungsphase erzwingt.

Der Irrtum: mehr Bandbreite heißt automatisch schneller

Ethernet liefert auf dem Papier ein Vielfaches der Datenrate eines klassischen CAN-Busses, und daraus entsteht schnell die Annahme, DoIP müsse jede Diagnose beschleunigen. Das stimmt nur, wenn die reine Übertragungszeit tatsächlich der Engpass ist. Ein einfaches Rechenbeispiel zeigt die Größenordnung: Eine 4-Kilobyte-Nachricht braucht bei 50 Kilobyte pro Sekunde rechnerisch rund 82 Millisekunden, bei 2 Megabyte pro Sekunde nur rund 2 Millisekunden. Das wäre ein Geschwindigkeitsfaktor von etwa 40, wenn ausschließlich die reine Übertragungszeit zählen würde.

In der Praxis holt der IP-basierte Weg diesen Vorteil aber nicht automatisch heraus. Die Erkennungsphase, die Routing-Aktivierung und jeder zusätzliche Gateway-Sprung kosten eigene Zeit, und diese Zeit fällt unabhängig von der Leitungsgeschwindigkeit an. Sechs Gateway-Sprünge mit jeweils zwei Millisekunden Verarbeitungszeit summieren sich bereits auf zwölf Millisekunden, bevor überhaupt die erste Nutzlast beim Zielsteuergerät ankommt. Dominieren Sitzungsaufbau, Routing oder die interne Verarbeitung im Steuergerät, bleibt vom rechnerischen Bandbreitenvorteil im Alltag oft nur ein Bruchteil übrig.

Warum große Datenmengen oft über DoIP laufen

Bei kleinen Diagnoseanfragen, etwa dem Lesen eines einzelnen Fehlercodes, macht der Transportweg kaum einen spürbaren Unterschied. Anders sieht es aus, sobald größere Datenmengen bewegt werden, etwa beim Schreiben einer neuen Steuergerätesoftware. Ein 20-Megabyte-Datenblock braucht bei fünf Megabyte pro Sekunde rechnerisch rund vier Sekunden reine Übertragungszeit. Über den klassischen CAN-Bus mit seiner viel geringeren Nutzdatenrate wäre dieselbe Datenmenge um ein Vielfaches langsamer, allein wegen der Segmentierung in kleine Frames mit eigener Flusssteuerung.

Genau deshalb setzen viele neuere Fahrzeugarchitekturen für umfangreiche Programmiervorgänge auf DoIP. Wichtig bleibt trotzdem eine Einschränkung: Auch hier ist die theoretische Linkrate nur eine Obergrenze, keine garantierte Praxiszahl. Wie schnell ein Flashvorgang tatsächlich abläuft, hängt zusätzlich davon ab, wie schnell das Steuergerät die eingehenden Daten verarbeiten, zwischenspeichern und ins eigene Speichermedium schreiben kann. Ein schneller Transportweg nützt wenig, wenn die Pufferung im Steuergerät selbst der eigentliche Flaschenhals ist.

Transportfehler und Anwendungsfehler auseinanderhalten

Eine gescheiterte Diagnose hat nicht automatisch mit UDS selbst zu tun. Ehe eine Anwendungsnachricht überhaupt bewertet werden kann, muss der Transportweg sauber funktionieren, und genau dort lohnt sich ein erster, einfacher Blick. Kommt bei DoCAN überhaupt eine Antwort auf dem Bus an, oder bleibt der Bus für die betroffene Adresse still? Steht auf dem IP-Weg die Verbindung zum Gateway, und war die Routing-Aktivierung erfolgreich?

Erst wenn diese Fragen mit Ja beantwortet sind, ergibt eine zweite Prüfung überhaupt Sinn: Antwortet das Steuergerät auf Anwendungsebene negativ, obwohl der Transportweg technisch sauber steht? Das ist ein völlig anderes Fehlerbild als ein Transportproblem, auch wenn beide im Diagnosetool ähnlich aussehen können. Ein einfacher Kontrolltest hilft dabei, beides zu trennen: Bleibt die Antwortzeit trotz spürbar größerer Bandbreite fast gleich, lag der eigentliche Engpass nicht im Transport, sondern in der Verarbeitung im Steuergerät oder im Gateway selbst.

Woran du erkennst, über welchen Weg dein Gerät gerade spricht

Der 16-polige Diagnosestecker im Fahrzeug ist zunächst nur eine physische Schnittstelle und sagt für sich genommen nichts darüber, welches Transportprotokoll dahinter aktiv ist. Welche Pins tatsächlich belegt sind, entscheidet die jeweilige Fahrzeugarchitektur, nicht der Stecker selbst. Ein passendes Diagnosegerät muss deshalb beide Wege unterstützen und automatisch erkennen, welcher davon auf dem angeschlossenen Fahrzeug tatsächlich funktioniert.

In der Praxis zeigt ein brauchbares Werkzeug diese Information auch an, etwa als Hinweis, ob eine Sitzung gerade über CAN oder über Ethernet läuft. Wer das nicht sieht, kann sich an zwei indirekten Anzeichen orientieren: Baut das Gerät zunächst eine IP-Verbindung mit einer Erkennungs- und einer Aktivierungsphase auf, war es DoIP. Reagiert es dagegen sofort auf Busebene ohne diese beiden zusätzlichen Schritte, war es DoCAN. Für die eigentliche Fehlersuche lohnt sich diese Unterscheidung, weil sie festlegt, welche der beiden vorherigen Prüfschritte überhaupt greift.

Was das für die Praxis an einem getunten Fahrzeug bedeutet

Für die reine Fehlersuche ändert der Transportweg wenig an der grundsätzlichen Vorgehensweise. Wichtiger wird er, sobald es um das Schreiben neuer Steuergerätesoftware geht, weil dort größere Datenmengen und damit meist DoIP im Spiel sind. Ein technisch erfolgreicher Datentransfer über diesen Weg beweist dabei für sich genommen nichts darüber, ob die übertragene Software für dieses Fahrzeug inhaltlich passt oder freigegeben ist. Diese Frage liegt außerhalb dessen, was der Transportweg überhaupt regeln kann.

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.

Das gilt ausdrücklich auch dann, wenn eine Änderung rein softwareseitig über DoIP oder DoCAN aufgespielt wird, ohne dass ein einziges Bauteil getauscht wurde. Der Transportweg entscheidet nur, wie die Daten ins Steuergerät gelangen, nicht darüber, ob die neue Kalibrierung anschließend zum genehmigten Zustand des Fahrzeugs passt. Welche Norm dabei greift und wie ihr Wortlaut lautet, steht ausführlich im Einordnungsblock am Ende dieses Beitrags.

Häufige Missverständnisse rund um DoIP und DoCAN

Ein verbreiteter Irrtum lautet, DoIP werde DoCAN in jedem Fahrzeug vollständig ablösen. Tatsächlich koexistieren beide Wege in vielen aktuellen Architekturen, weil nicht jedes Steuergerät die Bandbreite oder die Kosten eines Ethernet-Anschlusses rechtfertigt. Ein zweiter Irrtum verwechselt die physische Schnittstelle mit dem Protokoll dahinter: Der genormte Diagnosestecker regelt den emissionsbezogenen Zugriff, sagt aber nichts darüber, ob dahinter DoCAN oder DoIP aktiv ist.

Ein dritter Irrtum unterstellt, eine schnellere Verbindung könne jede Diagnose beschleunigen. Wie die Rechenbeispiele oben zeigen, verschiebt sich der Engpass bei kleinen Anfragen häufig weg vom reinen Transport, hin zu Sitzungsaufbau und Steuergeräteverarbeitung. Und ein vierter Irrtum hält eine erfolgreiche Verbindung für den Beweis, dass auch die Anwendungsebene fehlerfrei arbeitet. Transportweg und UDS-Anwendungsschicht sind zwei getrennte Prüfebenen, und nur wer beide sauber auseinanderhält, liest ein Diagnoseprotokoll wirklich zuverlässig.

Häufige Fragen

Einordnung: wo die Angaben herkommen

Die Fundstellen stehen hier gebündelt, damit der Fließtext ohne Normzitate und Paragrafenketten auskommt. Die ISO-Angaben sind am 18.09.2026 über die öffentlichen Kataloge geprüft worden, der Normtext zu § 19 StVZO am selben Tag am amtlichen Angebot gegengelesen.