OBD

OBD, UDS, and CAN are easy to mix together as if they were just different names for “vehicle diagnostics.” That misunderstanding is especially likely to distort capture analysis and system design, because the first thing you need to grasp about OBD is not a PID number or the shape of a 16-pin connector. It is the role it plays in the whole diagnostic stack.

The most important judgment about OBD is this: it provides a standardized and predictable diagnostic entry point for external tools, driven by regulation and general service scenarios. It does not try to cover every internal ECU diagnostic capability, and it is not the same as a vehicle maker’s private diagnostic stack. Its first goal is to make sure that different vehicles from different vendors can still expose emissions-related states, fault information, and basic data in a similar way to common tools.

UDS

In vehicle-diagnostics captures, the first things people often remember are a few hex service numbers: 0x10, 0x22, 0x27, 0x2E, 0x31, 0x34. Those numbers matter, of course, but memorizing service IDs alone still leaves later implementation, troubleshooting, and flashing analysis confused, because what you need to grasp first is not “which number means which function.” It is “why vehicle diagnostics cannot rely only on a few private commands, and instead need a full application-layer order.”

If a packet was sent and never arrived, how does the sender know what went wrong? “No response” is not enough. It cannot distinguish between a broken path, expired TTL, unreachable destination, or a destination port with nothing listening. IP deliberately does not do that kind of reporting. It forwards best effort and does not explain failure.

ICMP handles the layer where the network talks to the network about what happened. It is not a business-data protocol, but it carries error feedback, reachability probes, path exposure, and some control signals. Without it, many troubleshooting judgments collapse from “know where it broke” to “guess where it broke.”