DBC

DBC is often first seen as a “CAN signal manual”: which bits in a given ID mean what, what the scaling factor is, and what unit is used. That understanding is not wrong, but it stays at the reference-document level. Anyone who has actually done packet capture, integration, or protocol handoff quickly learns that the real problem is usually not “there is no table.” The real problem is that everyone has a table, but they still cannot agree on how a frame should be interpreted, which node should send it, how the physical value should be calculated, or whether the version has changed.

UDS Flashing Flow

In ECU flashing captures, the first services you usually notice are Request Download, Transfer Data, and Request Transfer Exit. At first glance, it seems simple: tell the ECU to get ready, send the binary in chunks, and then finish. But real engineering is never that simple. Flashing is hard not because segmented transfer is complicated by itself, but because it is a high-risk business chain: if permissions are wrong, the session is wrong, erase is wrong, the block order is wrong, verification fails, or activation fails, the ECU can be left in a state worse than “not upgraded.”

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.”

CAN TP

Once you understand classic CAN and CAN FD, the next natural thought is: if one frame cannot hold the data, why not just split it in application code and send multiple frames? That can work in the simplest experiments, but once a real system is involved, problems appear quickly: how does the receiver know where the long message starts and ends, what happens if one frame is missing, what if the sender transmits too fast for the receiver to keep up, and what if both directions have large messages at the same time?

CAN FD

Once you already accept the core judgment of classic CAN, the easiest mistake when reading CAN FD is to think “the payload just grew from 8 bytes to 64 bytes, so it is faster.” That is not wrong, but it is far from enough. What really pushed CAN FD into existence was not only payload size. It was the fact that classic CAN ties arbitration and whole-frame transmission to the same bit rate, so systems increasingly wanted to keep deterministic shared-bus contention while being constrained by payload size and bus time.

CAN

People often remember CAN through a few surface facts first: two wires, differential signaling, 1 Mbps, common in cars, and no traditional source or destination address in the frame. Those facts are true, but they are not enough for implementation, packet capture, or debugging. What really defines CAN is not what it looks like, but how it lets many nodes watch the same wire and still keep working when they try to send at the same time.