Die IP-basierte Fahrzeugdiagnose, meist als DoIP bezeichnet, verbindet Diagnose, Gateway und Ethernet so, dass Steuergeräte schneller erreichbar sind, große Datenmengen besser transportiert werden und Sitzungen robuster bleiben. Für Werkstätten, Entwicklungsumgebungen und Flotten in Deutschland ist das vor allem dann relevant, wenn mehrere Steuergeräte, Software-Flashs und Remote-Zugriffe zusammenkommen. Der eigentliche Nutzen liegt nicht darin, dass „irgendetwas über IP“ läuft, sondern darin, dass sich Diagnose sauber in bestehende Netzwerke einfügt.
Die Norm macht Fahrzeugdiagnose über IP planbar, schneller und netzwerktauglich
- Die Reihe definiert, wie Diagnosekommunikation über IP, TCP und UDP im Fahrzeugnetz funktioniert.
- Der technische Kern liegt heute in Teil 2; Teil 3 regelt die Ethernet-Anbindung, Teil 4 den Diagnoseanschluss.
- Teil 1 ist historisch und zurückgezogen, wird aber noch oft als Einstieg in die Use Cases genannt.
- Wichtige Funktionen sind IP-Adressierung, Fahrzeugerkennung, Verbindungsaufbau, Routing und Fehlerbehandlung.
- TLS und Firewall-Funktionen sind vorgesehen, aber nicht automatisch überall aktiv oder gleich umgesetzt.
Die Normenreihe ordnet Fahrzeugdiagnose in IP-Netze ein
Nach ISO ist die 13400er-Reihe kein einzelnes Detailprotokoll, sondern ein Rahmen für Diagnose im IP-Umfeld. Der Begriff „Internet Protocol“ führt leicht in die Irre: Gemeint ist nicht das öffentliche Internet, sondern die saubere Nutzung von IP im Fahrzeug- und Testnetz. Genau darin liegt der praktische Wert für Netzwerktechnik, denn Diagnose wird damit zu einem planbaren Bestandteil der Architektur und nicht zu einer proprietären Insel.
| Teil | Thema | Status 2026 | Praktische Bedeutung |
|---|---|---|---|
| Teil 1 | Allgemeine Informationen und Use Cases | zurückgezogen | historische Einordnung, beschreibt Anwendungsszenarien |
| Teil 2 | Transportprotokoll und Netzwerkschichtdienste | aktuell in der Fassung 2025 | Kern für Verbindungsaufbau, Discovery, Routing und Fehlerbehandlung |
| Teil 3 | Wired vehicle interface based on IEEE 802.3 | aktuell, zuletzt bestätigt 2022 | physische Ethernet-Basis, genannt wird 100BASE-TX mit 100 Mbit/s |
| Teil 4 | Ethernet-based high-speed data link connector | aktuell, zuletzt bestätigt 2021 | definiert den Diagnoseanschluss und zwei Pin-Belegungsoptionen |
Ich lese daraus vor allem eines: Wer nur den Stecker sieht, versteht den Standard noch nicht. Entscheidend ist das Zusammenspiel aus Netzwerk, Gateway und Diagnosegerät, und genau dort setzt die nächste Ebene an.
So findet der Tester das Fahrzeug im Netz
Die ISO beschreibt dafür eine kleine, aber entscheidende Kette: IP-Adresszuweisung, Fahrzeugankündigung, Discovery, Verbindungsaufbau, Datenrouting und Fehlerbehandlung. Das klingt trocken, ist in der Werkstatt oder im Entwicklungsnetz aber der Unterschied zwischen „läuft sofort“ und „warum sieht mein Tester das Auto nicht?“.
Discovery statt fester Punkt-zu-Punkt-Verbindung
Der Tester muss nicht blind eine feste Adresse ansprechen. Er kann das Fahrzeug im Netz erkennen, den Grundzustand abfragen und erst dann die Sitzung aufbauen. Das ist besonders nützlich, wenn mehrere Steuergeräte oder mehrere Testgeräte im Spiel sind, weil die Kommunikation nicht auf eine starre Einzellösung festgenagelt wird.
Das Gateway als zentrale Schaltstelle
In modernen Fahrzeugarchitekturen sitzt zwischen Tester und Unterkomponenten meist ein Gateway. Ich halte dieses Bauteil für die eigentliche Stellschraube: Es leitet Anfragen weiter, bündelt Zugriffe und verhindert, dass sich die Diagnose in jedem Subnetz anders verhält. Wenn Routing oder Zustandssteuerung dort unsauber umgesetzt sind, wirkt die ganze IP-basierte Diagnose instabil, obwohl das Protokoll selbst korrekt wäre.
Lesen Sie auch: Netzwerk-Jitter verstehen - Ursachen, Erkennung & Lösungen
Warum TCP und UDP beide vorkommen
Die aktuelle Norm beschreibt Diagnosekommunikation über IP sowie über TCP und UDP. Für die Praxis heißt das: Es gibt neben der eigentlichen Sitzung auch Mechanismen, mit denen das Fahrzeug im Netz auffindbar bleibt und Zustandsinformationen bereitstellt. Wer Netzwerke plant, muss deshalb nicht nur an Bandbreite denken, sondern auch an Erreichbarkeit, Adressierung und saubere Übergänge zwischen Start, Betrieb und Trennung.
Gerade dieser Teil wird oft unterschätzt. Der Standard funktioniert nicht erst dann, wenn das Diagnosefenster offen ist, sondern schon beim ersten Auffinden des Fahrzeugs im Netz.
Warum Ethernet Diagnose spürbar beschleunigt
Ich würde DoIP nicht als Ersatz für jede andere Bordnetztechnik lesen. Sein eigentlicher Vorteil liegt dort, wo viele Daten transportiert werden müssen: Flashen, erweiterte Diagnosen, zentrale Gateway-Abfragen oder Szenarien mit mehreren Steuergeräten. Dann spielt IP-Diagnose ihre Stärke aus, weil sie auf einem Netzwerk aufsetzt, das für höhere Datenraten und bessere Skalierung gebaut ist.
| Aspekt | Klassische CAN-nahe Diagnose | Diagnose über Ethernet/IP |
|---|---|---|
| Datenmenge | gut für kleinere Diagnosepakete | deutlich besser für große Transfers und Flashing |
| Architektur | stärker bus- und segmentorientiert | gateway- und netzwerkorientiert |
| Einbindung | bewährt, aber oft enger an Einzelbusse gebunden | besser in bestehende IT- und Werkstattnetze integrierbar |
| Fehlersuche | einfacher bei kleinen, lokalen Problemen | mächtiger, aber auch anspruchsvoller bei Netzfehlern |
| Typische Stärke | robuste Basisdiagnose | schnelle, skalierbare Sessions mit vielen Daten |
Der wichtige Punkt ist nicht „neu gegen alt“, sondern „passend gegen unpassend“. Für einfache Einzelfehler reicht eine klassische Diagnose oft aus. Sobald aber Softwarestände groß werden oder viele Steuergeräte beteiligt sind, wird Ethernet im Alltag schnell produktiver.
Welche Hardware und Topologie wirklich nötig sind
Die ISO nennt für Teil 3 eine physische Basis auf IEEE 802.3 100BASE-TX, also auf der 100-Mbit/s-Klasse. Teil 4 ergänzt dazu den Diagnoseanschluss mit zwei möglichen Pin-Belegungen. Für die Praxis bedeutet das: Nicht nur das Protokoll muss stimmen, sondern auch Kabel, Stecker, Aktivierung und die saubere Zuordnung im Fahrzeug.
- Ein kompatibles Diagnosegerät, das das Fahrzeug entdecken und die Sitzung aufbauen kann.
- Ein Fahrzeuggateway, das IP-Daten zu den internen Steuergeräten weiterleitet.
- Ein passender Diagnoseanschluss mit korrekter Pin-Belegung und sauberer elektrischer Umsetzung.
- Eine Ethernet-Strecke, die zu Fahrzeug und Testumgebung passt, statt nur „irgendwie verbunden“ zu sein.
In Laboren und Werkstätten kommen oft zusätzlich Switches, Segmentierung und Messpunkte dazu. Das fordert der Standard nicht im Detail, aber ohne solche Hilfen wird die Fehlersuche unnötig zäh. Wenn der Stecker mechanisch passt, die Aktivierungslinie aber nicht sauber umgesetzt ist, hilft dir die beste IP-Konfiguration nichts.
Sicherheit und typische Stolpersteine im Netzwerk
Der technische Reiz von IP-Diagnose ist zugleich ihr Risiko: Man übernimmt die Komplexität von Netzwerken. Die aktuelle Fassung sieht zwar gesicherte und ungesicherte Kommunikation vor und nennt TLS sowie Firewall-Funktionen als optionale Bausteine, aber daraus folgt kein automatischer Schutz. Genau hier sehe ich in Projekten die meisten Fehlannahmen.
- Discovery wird durch falsche Segmentierung oder eine zu harte Firewall blockiert.
- Der Tester findet das Fahrzeug nicht, weil IP-Adressierung und Gateway-Zustand nicht zusammenpassen.
- Das Fahrzeug schläft oder meldet keinen passenden Diagnosezustand, obwohl die Verbindung physisch steht.
- Die Pin-Belegung am Diagnoseanschluss passt nicht zur Fahrzeugplattform oder zum Testadapter.
- Routing zu Unterkomponenten ist nicht konsistent, sodass einzelne Steuergeräte unsichtbar bleiben.
Ich würde deshalb immer zwischen Protokollfehler und Netzfehler unterscheiden. Ein DoIP-Problem ist sehr oft in Wahrheit ein Konfigurationsproblem im Netzwerk, und wer beides sauber trennt, spart in der Fehlersuche schnell viel Zeit.
Worauf ich bei einer Einführung 2026 achten würde
Wenn ich eine IP-basierte Fahrzeugdiagnose in eine bestehende Umgebung einführe, beginne ich nicht beim Tester, sondern bei der Architektur. Zuerst kläre ich, welche Steuergeräte erreicht werden sollen, wie das Gateway arbeitet und ob die bestehende Netzstruktur Discovery, Adressierung und Sitzungsaufbau überhaupt sauber zulässt. Erst danach lohnt sich der Blick auf Adapter, Pinout und konkrete Testabläufe.
- Den Anwendungsfall präzise festlegen, etwa Werkstattdiagnose, Flashing oder Remote-Service.
- Das Gateway-Verhalten unter Realbedingungen prüfen, nicht nur im Laboraufbau.
- Discovery, Sleep/Wake-Verhalten und Fehlertrennung in echten Tests validieren.
- Sicherheit und Zugriff nicht nachträglich anhängen, sondern von Anfang an mitplanen.
- Vor dem Rollout einen Pilot auf einer Plattform fahren, die repräsentativ für den Rest ist.
Für deutsche Werkstätten, Entwicklungsabteilungen und Flotten ist diese Technik besonders dann stark, wenn große Datenmengen, viele Steuergeräte und wiederkehrende Serviceprozesse zusammenkommen. Für kleine, selten genutzte Diagnoseaufgaben ist sie nicht automatisch die wirtschaftlichste Lösung, aber genau diese Abwägung macht ein gutes Netzwerkkonzept aus.
