OBD-II & UDS Diagnostics

OBD-II: the baseline every road car supports

On-Board Diagnostics II (OBD-II) is a standardised diagnostic layer required on virtually all passenger vehicles sold since the late 1990s/early 2000s. It runs as request/response messages over the vehicle's CAN bus (almost always at 500 kbit/s) and is accessed through the same physical connector on every vehicle — the 16-pin OBD-II port, usually under the dash near the steering column.

Modes and PIDs

OBD-II organises requests into numbered Modes (also called Services), each covering a category of diagnostic data:

• Mode 01 — Show current data. Each request specifies a PID (Parameter ID) — e.g. PID 0x0C is Engine RPM, 0x0D is Vehicle Speed, 0x05 is Coolant Temperature. This is what live-data dashboards poll continuously.
• Mode 03 — Show stored Diagnostic Trouble Codes (DTCs) — what's actually triggered the check-engine light.
• Mode 04 — Clear DTCs and reset the MIL (Malfunction Indicator Lamp).
• Mode 09 — Vehicle information, including VIN.

A request and response pair for reading RPM looks like this on the wire:

TX  0x7DF   02 01 0C 00 00 00 00 00     ; request: Mode 01, PID 0x0C (RPM)
RX  0x7E8   04 41 0C 1A F8 00 00 00     ; response: ((0x1A * 256) + 0xF8) / 4 = 1726 RPM

DTC format

Diagnostic Trouble Codes follow a five-character format like P0301:

• Letter — system: Powertrain, Chassis, Body, Unetwork
• First digit — 0 generic/SAE-standard code, 1 manufacturer-specific
• Remaining digits — the specific fault, e.g. 0301 is "Cylinder 1 Misfire Detected"

Beyond OBD-II: UDS (ISO 14229)

OBD-II is deliberately limited — it's an emissions-focused standard, not a general diagnostic interface. UDS (Unified Diagnostic Services, ISO 14229) is what manufacturers actually use for deeper diagnostics, flashing, and configuration — it's the protocol behind "real" dealer-level diagnostic sessions, and what ONAC's own diagnostic and reverse-engineering work is built around.

UDS is session-based: instead of a single stateless request, a tester typically opens a diagnostic session, may need to pass security access (a seed/key challenge) for sensitive services, then issues one or more service requests before the session times out or is closed.

ISO-TP: when 8 bytes isn't enough

A single CAN frame only carries up to 8 data bytes — nowhere near enough for a VIN read, a DTC list, or a firmware block. ISO-TP (ISO 15765-2) is the transport layer that segments a larger UDS message across multiple CAN frames and reassembles it at the other end:

• Single Frame — the whole message fits in one frame (≤ 7 bytes of payload)
• First Frame — announces a multi-frame message and its total length, carries the first chunk
• Flow Control — the receiver tells the sender how many frames it can accept at once, and the minimum gap between them
• Consecutive Frame(s) — the remaining chunks, sent in sequence

Where this fits into the ONAC platform

ONAC's vehicle network and diagnostic consultancy work covers this stack directly — OBD-II Mode 01/03/04, UDS session control, DTC services, and ISO-TP transport, against real ECUs over J2534 pass-thru hardware. ONAC Network Studio's decoded live-data view uses the same underlying frame and signal concepts covered in CAN Bus Fundamentals, just applied to normal periodic broadcast traffic rather than request/response diagnostics.