OBD-II
The legally mandated diagnostic socket every road vehicle carries, and the small set of standard PIDs behind it. A guaranteed way in, and a deliberately narrow one.
OBD-II is the diagnostic interface every road vehicle sold in the major markets has been required to carry for emissions compliance since the mid nineteen nineties. It gives you a physically standard 16-pin socket within reach of the driver's seat, and a short, standard list of readable parameters behind it. It is the one interface on a vehicle you can count on, and it is deliberately narrow.
What it is
The socket is the physical layer plus the pinout. On essentially everything built this century the transport underneath is CAN, at 500 kbit/s on pins 6 and 14, with the diagnostic exchange carried over ISO-TP and structured by the SAE J1979 service set.
| Service | What it does |
|---|---|
| 0x01 | read current data by PID |
| 0x02 | read the freeze frame captured when a fault was stored |
| 0x03 | read stored diagnostic trouble codes |
| 0x04 | clear codes and the malfunction indicator lamp |
| 0x09 | read vehicle information, notably the VIN |
A PID is a one-octet parameter number inside service 0x01. The set is small and standard: 0x0C engine speed at a quarter of a rpm, 0x0D vehicle speed as a whole number of km/h, 0x05 coolant temperature in whole degrees with a 40 degree offset, 0x11 throttle position as one part in 255. Requests are usually broadcast to the functional address 0x7DF and answered from 0x7E8 upward.
ELM327 is the near-universal serial-to-OBD interpreter chip, cloned endlessly into cheap Bluetooth and USB dongles, and it is what every phone diagnostic app talks to.
Why it matters
It is the only guaranteed access point, and the only source of ground truth on a vehicle whose signal database you do not have: a phone app logging PIDs gives you a labelled physical quantity to search the raw bus for. It is also the way in for the manufacturer-specific services that matter more, because UDS rides on the same transport at the same socket and that is where security access, memory read and reprogramming live.
The counterweight is that the socket is not the vehicle. On modern architectures a gateway terminates the diagnostic session and forwards nothing else, so a dongle at the socket sees the answers to its own questions and none of the vehicle's internal traffic.
How to work it
- Read the standard set first. It costs nothing and it tells you what the vehicle admits to.
# over SocketCAN, service 01 PID 0D, vehicle speed
cansend can0 7DF#0201 0D0000000000
candump can0,7E8:7FF
- Or through a dongle, where the AT command set does the framing for you.
ATZ # reset
ATSP0 # let it work out the protocol
0100 # which PIDs of service 01 are supported
010C # engine speed
- Log PIDs over a drive with a phone app and export the CSV. That is ground truth for reverse engineering the real signals.
- When the standard set runs out, move to UDS on the same socket.
Pitfalls
- The app's clock is not the vehicle's clock. Phone exports carry the phone's wall clock, which is frequently wrong, and lining an export up with a bus capture is a correlation problem rather than a lookup.
- PID resolutions are coarse by design. Vehicle speed to the whole km/h is often not precise enough to distinguish two candidate bus signals.
- A gateway may rate-limit or refuse requests, and some refuse everything while the vehicle is moving.
- Clearing codes with service 0x04 destroys evidence, including freeze frames. On an investigation it is the one command never to send.
- The presence of a socket says nothing about which buses reach it. Verify by capturing rather than assuming.