DoIP and ISO 13400: diagnostics over IP explained

DoIP — Diagnostic communication over Internet Protocol — is the standardised way to carry diagnostic messages over an IP network instead of a fieldbus. It is defined by ISO 13400, with the transport and network-layer behaviour specified in ISO 13400-2 (current edition 2019) and the Ethernet physical layer in ISO 13400-3.

Crucially, DoIP is a transport, not a new diagnostic language. It replaces the CAN-based transport layer (DoCAN, ISO 15765-2) with TCP/IP and UDP/IP over automotive Ethernet. The diagnostic services riding on top are still UDS (ISO 14229) — the same requests, response codes and sessions an engineer already knows. DoIP changes how the bytes travel, not what they say.

Classic CAN tops out around 1 Mbit/s, and even CAN-FD is modest by modern standards. That was tolerable when an ECU held a few hundred kilobytes of firmware. It is painful when a domain controller or high-performance computer holds gigabytes and a workshop needs to reflash it before the customer's coffee goes cold.

Automotive Ethernet offers the bandwidth that makes fast flashing, parallel addressing of many ECUs and large data transfers practical. As vehicles become software-defined — fewer, more powerful compute nodes, frequent over-the-air and at-line updates — an IP backbone is no longer optional. DoIP is the diagnostic protocol that rides that backbone.

A DoIP session has two phases. First, discovery over UDP on port 13400: the tester broadcasts a vehicle identification request, and the vehicle's DoIP entity replies with a vehicle announcement message carrying its VIN, logical address and entity ID (EID). This lets the tester find the vehicle on the network without prior configuration.

Second, a TCP connection on the same port 13400 (or 3496 for a TLS-secured session). Before any diagnostics flow, the tester sends a routing activation request; the DoIP entity validates the source address and, if accepted, returns a positive routing activation response. Only then is the path open. From that point the connection carries ordinary UDS payloads — 0x10 session control, 0x22 read data, 0x34/0x36/0x37 transfer for flashing — exactly as they would appear over CAN.

Few ECUs speak Ethernet directly. The vehicle typically exposes one DoIP entity — the edge node, historically the central gateway — that terminates the IP connection and routes diagnostic messages onward to target ECUs sitting on CAN, CAN-FD, LIN or FlexRay segments. Logical addressing in the DoIP header tells the edge node which internal ECU each message is for.

This is also where the software-defined vehicle is reshaping topology: the DoIP edge-node function is increasingly folded into high-performance computers and body controllers, sometimes with several Ethernet ports, so multiple testers and faster, more parallel flashing become possible.

Putting diagnostics on IP brings the obvious upside of speed and the obvious downside of exposure. The diagnostic channel is now a network endpoint with the threat surface that implies — discovery probes, spoofed routing activation, session hijacking. The 2019 edition of ISO 13400-2 added TLS (on port 3496) precisely to protect confidentiality and integrity at the transport layer.

TLS is necessary but not sufficient. It sits alongside, not instead of, application-layer measures such as UDS authentication (service 0x29) and the broader programme of UN R155 and ISO/SAE 21434. The diagnostic edge node is a high-value target, and it should be designed and tested as one.

DoIP does not retire CAN; it joins it. Low-speed sensor and actuator nodes in body, chassis and powertrain remain perfectly well served by CAN and CAN-FD, and the industry expects a long coexistence well into the 2030s. In practice the same UDS request may reach one ECU over DoIP and another over ISO 15765-2 in the same workshop session.

That is why the transport layer is the right place to absorb this complexity. Diadrom's Diag Com Stack (DCS) handles UDS communication across these transports, so the diagnostic application can address an ECU consistently whether it sits behind automotive Ethernet or classic CAN — and the tooling does not need rewriting as a platform migrates from one to the other.