Diagnostics over Internet Protocol
Diagnostics over Internet Protocol: DoIP transports vehicle diagnostics over IP using the ISO 13400 family; UDS can be the diagnostic application while Ethernet/IP is the transport path. The page also includes a worked example and measurement sequence.
Technical frame
Diagnostics over Internet Protocol: DoIP transports vehicle diagnostics over IP using the ISO 13400 family; UDS can be the diagnostic application while Ethernet/IP is the transport path. The page also includes a worked example and measurement sequence.
The technical values here expose the standard, protocol or physical relationship directly; model-specific service values are linked through the matching model/variant dossier.
The goal is not only to define the term but to let the reader calculate and interpret what the data means in a scan, scope or physical test.
Concrete technical facts
- DoIP transports vehicle diagnostics over IP using the ISO 13400 family; UDS can be the diagnostic application while Ethernet/IP is the transport path.
- TCP/UDP port 13400 is the standardized DoIP port commonly used for discovery/vehicle announcement and diagnostic connections.
- 100BASE-T1 provides 100 Mbit/s and 1000BASE-T1 provides 1 Gbit/s class automotive Ethernet over a single twisted pair.
- IP addressing, routing activation and ECU logical-address faults are a different layer from UDS service errors.
- An Ethernet link being up does not mean a diagnostic session is established; DoIP routing activation must also succeed.
- Packet loss, VLAN/routing, gateway behavior and tester latency can present as apparent UDS timeouts.
Worked example
- Layering example: if the Ethernet link works but routing activation is rejected, diagnose the DoIP session/gateway layer instead of starting with the physical link.
Measurement and verification sequence
- Verify link state and IP addressing.
- Capture UDP vehicle discovery/announcement traffic.
- Check TCP 13400 connection and routing-activation response.
- Only then evaluate UDS request/response and P2/P2* timing.
Fault-separation logic
- Is a valid command present and are power/ground/network healthy?
- Does feedback follow the command?
- Does an independent physical measurement confirm the output?
- Is the fault limited to a specific temperature/load/speed condition?
- Does the result remain stable when the original condition is repeated after repair?
Technical sources
Continue investigating
Model-specific real technical data · Measurement references · Technical diagnostic atlas