Um große Diagnosenachrichten über ein CAN- oder FlexRay-Netzwerk zu leiten, wird eine Transportschicht im Kommunikations-Stack benötigt (Layer 4 im OSI-Netzwerk-Schichtenmodell). Für die Fahrzeugbusse setzt UDS auf die Transportprotokolle CAN-TP (ISO 15765) oder FlexRay-TP (nach AUTOSAR oder ISO 10681-2) auf. Für den Fahrzeugzugang über Internetprotokolle bietet sich als erstes das UDP (User Datagram Protocol) an. Dieses erlaubt es, einfache Datenpakete über ein IP-Netzwerk zu verschicken. Problematisch an UDP ist jedoch die fehlende Sicherungsschicht, das heißt, das Protokoll überprüft nicht den erfolgreichen Empfang einer gesendeten Nachricht, und UDP-Applikationen müssen selbst mit verlorengegangenen Nachrichten umgehen können. Dieser Fall ist im Internet jedoch die Regel, da jeder Vermittlungsknoten, beispielsweise Router oder Switch, bei Bandbreitenknappheit einzelne IP-Pakete ignoriert und auf diese Weise die Datenflüsse regelt (Congestion Control). UDS geht aber davon aus, dass der Datentransport im zugrundeliegenden Netzwerk-Stack zuverlässig ist. Unter den Internet-Protokollen repräsentiert TCP (Transmission Control Protocol) ein Transportprotokoll inklusive Sicherungsmechanismen. Ein Nachteil von TCP ist allerdings, dass es nicht datagram- sondern streambasiert arbeitet, also verschiedene Datenfragmente über TCP an die Gegenstelle gesendet werden. Diese müssen jedoch nicht in derselben Fragmentierung empfangen werden, lediglich die Reihenfolge bleibt erhalten.
Um also UDS-Diagnose über TCP/IP-Ethernet zu realisieren, bedarf es einer neuen Protokollschicht, die UDS mit den Internet-Protokollen verbindet und die oben beschriebenen Anforderungen erfüllt. Neben der Reprogrammierung müssen darüber hinaus alle anderen Diagnose-Anwendungen realisiert werden können. Dazu gehört auch das schnelle Senden und Empfangen relativ kleiner Diagnosenachrichten. In ersten Umsetzungen haben einige deutsche Automobilhersteller eigene Spezifikationen für die Diagnosekommunikation über Internet-Protokolle (Diagnostics over Internet Protocols, DoIP) definiert und umgesetzt. Momentan arbeiten Daimler, BMW, Audi und GM zusammen in einer ISO-Arbeitsgruppe an einer Standardisierung.
Im Wesentlichen besteht die Aufgabe des DoIP-Moduls im zentralen Fahrzeug-Gateway darin, die UDS-Datenpakete aus dem TCP-Datenstrom vom Tester zu extrahieren oder zu verpacken. Innerhalb des zentralen Gateways werden die UDS-Datenpakete dann an die CAN- und FlexRay-Stacks und -Busse weitergeleitet (Bild 2). Außer dem eigentlichen Nutzdatenaustausch werden auch administrative Informationen zwischen Tester und zentralem Gateway über UDP- und TCP-Steuerkanäle ausgetauscht.
TCP/IP als Steuergeräte-Standard-Software
Da TCP/IP eine sehr weit verbreitete Technik ist, gibt es eine enorme Vielfalt an Implementierungen. Für die Anwendung in Steuergeräten scheiden die großen Implementierungen für Workstations und PCs aufgrund ihrer Größe aus. Für eingebettete Systeme ist ebenfalls eine große Anzahl von freien und kommerziellen Stack-Implementierungen verfügbar. Untersuchungen zu diesen Implementierungen [1] zeigen, dass man diese differenziert betrachten muss. Viele sind Adaptionen des Berkeley-BSD-Stacks und eignen sich aufgrund ihrer Größe nur für große eingebettete Prozessoren, beispielsweise ARM. Auf der anderen Seite stehen sehr kleine und für bestimmte Prozessoren und Anwendungen hin optimierte Stacks. Diesen spezialisierten Stacks fehlen jedoch wichtige Merkmale wie zum Beispiel „TCP Retransmissions“, „IP Reassemblierung“, mehrfache TCPVerbindungen oder „Congestion Control“. Diese Lösungen können daher keine robuste Kommunikation über beliebige Internet-Verbindungen garantieren. Die Erweiterbarkeit solcher spezialisierter Lösungen ist entsprechend limitiert.