Wenn ein modernes Fahrzeug in der Werkstatt schnell erkannt, diagnostiziert oder mit neuer Software versorgt werden soll, reicht ein klassischer CAN-Anschluss oft nicht mehr aus. ISO 13400 beschreibt dafür die standardisierte Diagnosekommunikation über IP, meist bekannt als DoIP, und verbindet Fahrzeugnetzwerke mit Ethernet, TCP und UDP. Ich zeige, wie der Ablauf funktioniert, welche Teile der Norm relevant sind und worauf Werkstätten, Entwickler und Betreiber von Fahrzeugnetzwerken achten sollten.
Die wichtigsten Fakten zur IP-basierten Fahrzeugdiagnose auf einen Blick
- DoIP überträgt Diagnosemeldungen über IP und Ethernet.
- UDP dient vor allem der Fahrzeugsuche, TCP der stabilen Diagnoseverbindung.
- Port 13400 ist der übliche Netzwerkport für DoIP-Kommunikation.
- ISO 13400-2:2025 ist seit Juni 2025 die aktuelle Ausgabe des zentralen Transportteils.
- Routing Activation muss erfolgreich sein, bevor ein Tester Steuergeräte erreicht.
- TLS und Firewalls erhöhen die Sicherheit, sind aber nicht automatisch in jeder Umgebung aktiv.
Was DoIP im Fahrzeugnetz wirklich leistet
DoIP steht für Diagnostic communication over Internet Protocol. Gemeint ist damit keine Diagnose über das öffentliche Internet, sondern die Übertragung von Diagnoseinformationen über ein IP-basiertes Netzwerk im Fahrzeug oder zwischen Fahrzeug und Testgerät.
Die eigentlichen Diagnosebefehle stammen häufig aus UDS nach ISO 14229. DoIP übernimmt vor allem den Transport dieser Nachrichten. Das ist ein wichtiger Unterschied: Die Norm definiert nicht jede Diagnosefunktion selbst, sondern stellt den Netzwerkweg bereit, über den ein Tester beispielsweise Fehlerspeicher ausliest, Messwerte anfordert oder Steuergeräte programmiert.
Ich halte diese Trennung für besonders sinnvoll. Der Fahrzeughersteller kann intern CAN, LIN, FlexRay oder Automotive Ethernet einsetzen, während die externe Diagnoseschnittstelle nach außen einheitlich bleibt. Ein DoIP-Gateway nimmt die IP-Nachrichten entgegen und leitet sie an das passende elektronische Steuergerät weiter.
Wie die Normenfamilie aufgebaut ist
Die Bezeichnung ISO 13400 steht nicht für ein einziges Dokument. Die Normenfamilie beschreibt verschiedene Ebenen, vom allgemeinen Anwendungsfall bis zum physischen Diagnoseanschluss. Für die Praxis ist vor allem Teil 2 entscheidend, weil dort der eigentliche Kommunikationsablauf festgelegt wird.
| Teil | Schwerpunkt | Bedeutung für die Praxis |
|---|---|---|
| ISO 13400-1:2011 | Allgemeine Informationen und Anwendungsfälle | Beschreibt Szenarien wie Fahrzeugdiagnose, WWH-OBD und herstellerspezifische Anwendungen. |
| ISO 13400-2:2025 | Transportprotokoll und Netzwerkdienste | Regelt IP-Adressierung, Fahrzeugerkennung, TCP-, UDP- und Routing-Funktionen. |
| ISO 13400-3:2016 | Verkabelte Fahrzeugschnittstelle | Definiert die physische Schnittstelle auf Basis von IEEE 802.3 und 100BASE-TX. |
| ISO 13400-4:2016 | Ethernet-basierter Diagnoseanschluss | Beschreibt Anforderungen an Stecker, Kontakte, Pinbelegung und elektrische Eigenschaften. |
Stand 2026 ist ISO 13400-2:2025 die aktuelle dritte Ausgabe des zentralen Protokollteils. Die Ausgabe von 2019 wurde zurückgezogen und durch die überarbeitete Fassung ersetzt. Wer Software oder Testgeräte entwickelt, sollte deshalb die verwendete Protokollversion ausdrücklich prüfen, statt nur allgemein von DoIP-Kompatibilität auszugehen.
Teil 3 und Teil 4 bleiben ebenfalls wichtig. Ein Tester kann softwareseitig korrekt arbeiten und trotzdem keine Verbindung aufbauen, wenn Stecker, Pinbelegung oder Aktivierung nicht zum Fahrzeug passen. Gerade bei unterschiedlichen Fahrzeugplattformen wird dieser physische Teil schnell unterschätzt.
So läuft eine DoIP-Verbindung vom Stecker bis zum Steuergerät
1. Physische Verbindung und Ethernet-Aktivierung
Die Verbindung beginnt meist über den Diagnoseanschluss des Fahrzeugs. ISO 13400-3 beschreibt dafür eine kabelgebundene Ethernet-Schnittstelle auf Basis von 100BASE-TX. Das entspricht einer Bruttodatenrate von 100 Mbit/s und ist deutlich schneller als die klassische Kommunikation über viele Fahrzeugbusse.
Die Ethernet-Schnittstelle muss nicht permanent aktiv sein. Eine definierte Ethernet Activation Line kann die Hardware einschalten, wenn ein Diagnosegerät angeschlossen wird. Das reduziert Stromverbrauch und elektromagnetische Störungen. Für Werkstätten bedeutet das allerdings, dass ein bloß eingestecktes Kabel nicht immer sofort einen aktiven Netzwerklink garantiert.
2. Fahrzeugsuche über UDP
Nach dem Linkaufbau sucht der Tester nach erreichbaren DoIP-Einheiten. Dafür werden typischerweise UDP-Nachrichten auf Port 13400 verwendet. Das Fahrzeug antwortet mit Informationen wie VIN, logischer Adresse und Status der Diagnoseeinheit.
Dieser Schritt wird als Vehicle Discovery oder Vehicle Announcement bezeichnet. Er ist praktisch, weil der Tester nicht zwingend vorher eine feste IP-Adresse kennen muss. In einem isolierten Werkstattnetz mit direkter Verbindung zwischen Laptop und Fahrzeug funktioniert die Suche oft zuverlässig, während VLANs, aktive Firewalls oder mehrere Netzwerkadapter die Antwort blockieren können.
3. TCP-Verbindung und Routing Activation
Für die eigentliche Kommunikation baut der Tester eine TCP-Verbindung zum DoIP-Gateway auf. TCP sorgt dafür, dass die Daten geordnet und zuverlässig übertragen werden. Danach folgt die Routing Activation, bei der sich der Tester gegenüber dem Gateway anmeldet und die Weiterleitung zu den internen Steuergeräten anfordert.
Erst wenn diese Aktivierung akzeptiert wurde, kann der Tester UDS-Nachrichten an ein Zielsteuergerät senden. Die Diagnoseadresse des Steuergeräts ist dabei nicht automatisch identisch mit seiner IP-Adresse. DoIP nutzt zusätzlich logische Fahrzeugadressen, die das Gateway für die Weiterleitung verwendet.
4. Diagnose, Keep-alive und Abbau
Nach erfolgreicher Aktivierung laufen Lese- und Schreibvorgänge über dieselbe TCP-Sitzung. Dazu gehören Fehlerspeicher, Identifikationsdaten, Stellgliedtests und bei entsprechender Berechtigung auch Softwareupdates.
Während längerer Sitzungen muss die Verbindung überwacht werden. Keep-alive- und Statusmechanismen helfen zu erkennen, ob Tester, Gateway und Fahrzeug noch erreichbar sind. Ein physischer Kabelbruch, ein Neustart des Gateways oder ein Wechsel des Diagnosemodus kann die Sitzung beenden, obwohl die IP-Konfiguration zunächst korrekt aussieht.
Warum DoIP bei Diagnose und Softwareupdates Vorteile bringt
Der größte Vorteil liegt in der hohen Übertragungsgeschwindigkeit. Große Datenmengen, etwa Flash-Dateien für mehrere Steuergeräte, lassen sich über Ethernet wesentlich schneller übertragen als über eine langsame serielle Fahrzeugbusverbindung. Das verkürzt Standzeiten in Werkstätten und erleichtert umfangreiche Fahrzeugtests.
| Kriterium | Klassische Diagnose über CAN | Diagnose über DoIP |
|---|---|---|
| Übertragungsweg | CAN-Bus und Transportmechanismen | IP, Ethernet und TCP oder UDP |
| Geschwindigkeit | Für viele Diagnoseaufgaben ausreichend | Deutlich höher, besonders bei großen Datenmengen |
| Netzwerkstruktur | Busorientiert | IP-basiert mit Gateway und logischen Adressen |
| Typische Stärke | Einfache, robuste Kommunikation | Softwareupdates, schnelle Messwertübertragung und zentrale Diagnose |
| Typische Hürde | Begrenzte Bandbreite | IP-Konfiguration, Firewall und Routing Activation |
Mehr Bandbreite bedeutet aber nicht automatisch, dass jede Diagnose schneller wird. Wenn ein Steuergerät seine Antwort langsam erzeugt oder das Gateway intern auf CAN weiterleitet, bleibt dieser Teil der Prozesskette der Engpass. Meine praktische Faustregel lautet deshalb: DoIP beschleunigt den Transport, ersetzt aber keine leistungsfähige Steuergerätearchitektur.
Für Werkstätten in Deutschland ist DoIP besonders relevant, wenn Fahrzeuge regelmäßig programmiert oder mehrere Steuergeräte in einem Durchlauf geprüft werden. In Regionen mit weniger stabiler Infrastruktur, etwa bei Werkstattnetzen in Timor-Leste, sollte die Verbindung lokal und kontrolliert aufgebaut werden. Das Protokoll benötigt kein öffentliches Internet, sondern zunächst nur ein funktionierendes IP-Netz zwischen Tester und Fahrzeug.
Sicherheit und Netzwerkdesign entscheiden über den Erfolg
Eine IP-Schnittstelle macht Fahrzeugdiagnose flexibler, vergrößert aber auch die Angriffsfläche. Die Ausgabe ISO 13400-2:2025 berücksichtigt sowohl gesicherte als auch ungesicherte Kommunikation. TLS und Firewall-Funktionen sind wichtige Schutzmechanismen, müssen jedoch in Fahrzeug, Tester und Werkstattnetz tatsächlich konfiguriert und geprüft werden.
Ich würde einen Diagnoseanschluss nie ungefiltert mit dem normalen Büro- oder Gäste-WLAN verbinden. Besser sind ein separates Diagnose-VLAN, eine direkte Kabelverbindung oder ein abgeschotteter Werkstatt-Switch. Für Fernwartung kommt zusätzlich ein kontrollierter VPN-Zugang infrage. DoIP selbst macht aus einer lokalen Fahrzeugverbindung keinen sicheren Fernzugriff.
Lesen Sie auch: QUIC erklärt - Was das Protokoll wirklich leistet & wo Grenzen sind
Typische Fehlerbilder
- Kein Link: Kabel, Stecker, Pinbelegung, Aktivierungsleitung oder Fahrzeugzustand prüfen.
- Fahrzeug wird nicht gefunden: UDP-Port 13400, Broadcasts, Firewall und IP-Adressierung kontrollieren.
- Discovery funktioniert, Diagnose aber nicht: TCP-Verbindung oder Routing Activation untersuchen.
- Gateway antwortet mit Ablehnung: logische Testeradresse, Aktivierungstyp oder Berechtigungen prüfen.
- Verbindung bricht beim Flashen ab: Stromversorgung, Kabelqualität, Sleep-Modus und Sitzungsüberwachung kontrollieren.
Der häufigste Denkfehler ist, aus einer erfolgreichen Fahrzeugerkennung auf eine vollständig funktionierende Diagnose zu schließen. Discovery ist nur der erste Schritt. Erst TCP-Verbindung, Routing Activation und die Weiterleitung zum gewünschten Steuergerät zeigen, ob die gesamte Kette arbeitet.
So würde ich eine DoIP-Umgebung systematisch prüfen
- Physik prüfen: Stecker, Kabel, Link-LEDs und die zum Fahrzeug passende Pinbelegung kontrollieren.
- IP-Konfiguration ansehen: Adapter, IPv4- oder IPv6-Einstellung und automatische Adressvergabe prüfen.
- Discovery testen: Mit einem Netzwerkmitschnitt feststellen, ob UDP-Anfragen und Fahrzeugantworten sichtbar sind.
- TCP-Port prüfen: Sicherstellen, dass Port 13400 nicht durch Laptop-, Switch- oder Unternehmensfirewall blockiert wird.
- Routing Activation auswerten: Antwortcode und logische Adressen dokumentieren, statt nur auf eine allgemeine Fehlermeldung zu achten.
- UDS getrennt testen: Zuerst eine einfache Identifikationsabfrage senden, bevor Codierung oder Flashen begonnen wird.
Für Entwickler gehört außerdem ein Test mit mehreren parallelen Verbindungen dazu. Die aktuelle Protokollbeschreibung berücksichtigt konkurrierende Verbindungsversuche, Statusinformationen und Fehler bei physischer Unterbrechung. Eine Implementierung, die nur den Idealfall mit einem einzigen Tester abbildet, ist für reale Werkstattnetze zu knapp ausgelegt.
Bei einer verteilten Infrastruktur, beispielsweise zwischen einem lokalen Diagnoseplatz und einem entfernten Server, würde ich zusätzlich Latenz, Paketverluste und Stromversorgung messen. Ein stabiles IP-Netz ist wichtiger als eine theoretisch hohe Bandbreite, besonders während sicherheitskritischer Programmierprozesse.
Die eigentliche Stärke liegt im sauberen Netzwerk
DoIP ist kein Ersatz für Diagnosewissen, sondern eine leistungsfähige Transportschicht für moderne Fahrzeugnetzwerke. Wer die Rollen von UDP-Discovery, TCP und Routing Activation versteht, kann Fehler deutlich schneller eingrenzen und vermeidet die typische Suche nach einem vermeintlich defekten Steuergerät.
Für eine belastbare Umsetzung zählen drei Dinge zusammen. Die physische Ethernet-Schnittstelle muss passen, das IP-Netz muss die Kommunikation zulassen und das Gateway muss die Diagnoseanfrage korrekt weiterleiten. Genau diese Kombination macht den Standard für Werkstätten, Fahrzeugentwickler und regionale Konnektivitätsprojekte interessant, unabhängig davon, ob das Fahrzeug in Deutschland oder in Timor-Leste diagnostiziert wird.
