BlinkThorLabsUDS Diagnostics Over DoIP: What Actually Changes When You Move Off CAN
Physical vs functional addressing, and the multi-client problem CAN never made you think about.
UDS (ISO 14229) itself doesn't change when you move it from CAN to DoIP — the service IDs, the request/response semantics, the diagnostic session model are all the same layer, sitting on top of a different transport. Which is exactly why porting an existing CAN-based UDS implementation to DoIP feels, at first glance, like it should be mechanical. It mostly is — until you hit the handful of places where the transport layer's assumptions were quietly baked into how the diagnostic stack was designed, and those places are what this comparison is actually about.
Addressing
Aspect | On CAN | On DoIP |
|---|---|---|
Physical addressing | 11-bit or 29-bit CAN identifier, one ECU (or a small fixed set) per ID, configured at the network design stage | Logical address, a 16-bit value carried in the DoIP header, resolved to an IP address/port via the vehicle's DoIP entity/gateway routing table |
Functional addressing | A separate, well-known "functional" CAN ID that multiple ECUs listen on simultaneously, each replying independently | A distinct functional logical address value, routed by the DoIP gateway to potentially many target ECUs, each still replying independently over its own TCP connection |
Address resolution | Static, baked into the CAN network's DBC/description at design time — an ID always means the same ECU | Often dynamic — a logical address may need to be resolved to a current IP address via a DoIP routing/discovery mechanism, especially in networks using DHCP internally |
The trap: teams porting from CAN often treat DoIP's logical addressing as "just a different number for the same static CAN ID mapping" and hardcode the logical-address-to-IP mapping the same way they hardcoded CAN IDs. This works until the network's IP assignment isn't as static as assumed, or until a gateway needs to route the same logical address differently depending on which physical DoIP entity is currently reachable — a scenario that has no real CAN equivalent, because CAN's physical bus topology made "which wire is this ECU on" a non-question.
Message Framing
Aspect | On CAN | On DoIP |
|---|---|---|
Payload size | Limited by ISO-TP segmentation over classic CAN (up to 4095 bytes with multi-frame) or larger with CAN-FD | Effectively bounded by the DoIP payload length field and underlying TCP stream, generally supporting much larger single diagnostic messages without the same segmentation overhead |
Framing mechanism | ISO-TP (ISO 15765-2) handles segmentation/reassembly, flow control frames explicitly manage sender pacing | DoIP header (protocol version, payload type, payload length) wraps the UDS payload directly over TCP; TCP itself handles stream reliability, no separate flow-control frame exchange needed at the diagnostic layer |
Framing overhead visible to application layer | Diagnostic application code often has some awareness of multi-frame transfer state, especially in older stacks | Largely invisible to the application layer — TCP's stream abstraction means a large UDS response arrives as one logical read, without the application needing multi-frame bookkeeping |
The trap: stacks that were written with explicit awareness of ISO-TP's multi-frame flow control (deliberately pacing large responses, handling flow-control frame timing) sometimes carry that pacing logic over to DoIP unnecessarily — adding artificial delays or chunking that TCP already handles, which at best wastes time and at worst introduces timing assumptions that don't match how the receiving tester actually expects a DoIP response to arrive.
Timing and Timeout Behavior
Aspect | On CAN | On DoIP |
|---|---|---|
P2/P2* timing (server response timing) | Same ISO 14229 timing parameters, tuned against typical CAN bus latency characteristics | Same ISO 14229 timing parameters technically apply, but real network latency (switch hops, potential congestion on a shared automotive Ethernet backbone) can differ meaningfully from CAN's much more deterministic bus arbitration behavior |
Connection-level timeout | Not applicable — CAN has no connection concept, only message-level timing | DoIP adds a genuine connection layer (TCP) with its own keep-alive and connection-timeout behavior, on top of the UDS-level P2/P2* timing — two independent timeout mechanisms now need to be reasoned about together |
Tester-present handling | Straightforward — periodic tester-present message keeps a diagnostic session alive on the bus | Still needed at the UDS layer, but now interacts with DoIP's own TCP connection liveness — a session can be alive at the UDS layer while the underlying TCP connection has silently dropped, or vice versa, in ways that have no CAN equivalent |
The trap: treating DoIP's TCP connection as equivalent to "always on, don't worry about it" the way a CAN bus connection effectively was. In practice, teams porting to DoIP have been caught by a TCP connection quietly timing out or being dropped by an intermediate switch/firewall during a long diagnostic session, while the UDS-layer tester-present kept the logical session alive — resulting in a diagnostic tool that believes it's still connected right up until it tries to send the next request and gets nothing back. Robust DoIP diagnostic clients need to actively monitor connection health, not just UDS session state.
Security Access
Aspect | On CAN | On DoIP |
|---|---|---|
Seed/key exchange mechanism | Same UDS service (0x27), same seed/key challenge-response logic, unaffected by transport | Identical at the UDS layer — this is genuinely one of the few areas that ports over close to unchanged |
Transport-level security | Generally none — CAN bus security relies on physical access control to the vehicle and, increasingly, secure gateway filtering | DoIP, especially in modern SDV architectures, is commonly layered with TLS (DoIP over TLS, per newer ISO 13400 revisions) and often deployed alongside broader vehicle network segmentation/firewalling |
Attack surface consideration | Physical bus access required to interact with diagnostics at all in most classic architectures | Network-reachable diagnostics, even if only intended for use over a physical OBD connector or intended to be firewalled to specific segments, expand the attack surface in ways that need explicit security architecture, not just inherited assumptions from the CAN world |
The trap: assuming that because UDS security access (seed/key) is unchanged at the application layer, the overall security posture is unchanged too. It isn't — DoIP's network-based transport means diagnostic services are reachable from anywhere the underlying IP network reaches, unless explicitly restricted. Teams have shipped DoIP diagnostic stacks that correctly implement seed/key security access at the UDS layer while leaving the DoIP entity reachable from network segments that should never have had diagnostic access at all, because the transport-layer security question wasn't asked with the same rigor as the application-layer one.
Multi-Client Connections
Aspect | On CAN | On DoIP |
|---|---|---|
Concurrent tester connections | Effectively one active diagnostic session at a time in practice — CAN's shared-bus nature and typical diagnostic session locking make simultaneous independent testers unusual and generally not designed for | DoIP explicitly supports multiple simultaneous TCP client connections to the same DoIP entity, and the standard defines specific behavior for how concurrent diagnostic and routing activation requests should be handled |
Session/resource contention | Rarely an application concern — the bus itself serializes access, and diagnostic session state is typically assumed single-owner | A genuine new problem: two testers can connect simultaneously, one might activate a routing session for functional diagnostics while another attempts an ECU-specific session, and the diagnostic server needs explicit logic for arbitrating or rejecting conflicting concurrent access |
Real-world scenario this surfaces in | Rare — usually only a workshop tool connected at a time | Increasingly common as OTA update systems, remote diagnostics services, and a technician's handheld tool can all plausibly want DoIP access to the same vehicle concurrently in a modern SDV context |
The trap, and the biggest one on this list: ported diagnostic server implementations frequently carry forward an implicit single-client assumption from the CAN world — global mutable session state with no locking, because on CAN there was only ever going to be one tester talking at a time in practice. DoIP removes that implicit guarantee. We've seen a ported stack where a second concurrent DoIP client connection could silently interfere with an in-progress diagnostic session from the first client — not by design, but because the underlying session state was never built to be multi-owner-aware, since it never needed to be on CAN. This is the single most common functional regression teams hit when porting, and it's the one most likely to only show up once multiple tools are actually used against the same vehicle concurrently in the field, rather than in a single-tester bench test.
The Overall Shape of the Difference
If there's one sentence to take away from this comparison, it's this: UDS itself barely changes, but nearly everything CAN's physical, single-bus, single-session nature let you take for granted at the transport layer becomes an explicit design decision on DoIP. Addressing becomes potentially dynamic instead of statically wired. Framing overhead that used to be visible to the application layer disappears into TCP, which is a simplification, but a real one to account for if old code carries pacing assumptions forward unnecessarily. Timeouts split into two independent layers that both need attention. Security access logic ports over cleanly, but the transport-level security question around it is new and needs to be answered explicitly rather than inherited. And multi-client access — the item most teams underestimate — moves from "basically never happens" to "explicitly supported by the standard and increasingly common in practice," which means diagnostic server session state needs to be built with concurrent access in mind from the start, not retrofitted after the first field report of two tools stepping on each other.
None of this makes DoIP harder than CAN in any absolute sense — it's a more capable transport for exactly the reasons that make direct porting risky if you don't audit these five areas specifically. The UDS layer being unchanged is precisely what makes it easy to underestimate how much has actually changed underneath it.
