UDS diagnostic services and security access

Generic OBD gives you a fixed, small, emissions-related vocabulary. Everything else a modern vehicle can be asked — read this configuration byte, run this actuator, write this variant coding, replace this software — travels on a different protocol.

An engine control unit lifted out of the vehicle and mounted on a test harness board on a wooden bench, its finned alloy casing connected to a thick braided loom that fans out into rows of labelled terminal blocks, relays and fuses on a rail beside them, a small vehicle communication interface box cabled to a laptop turned away from the camera, an anglepoise lamp and laboratory instruments behind. — The protocol standardises the grammar. The manufacturer still owns the vocabulary.

The shape of the conversation

A diagram of the UDS request and response structure. A read request is shown as a service identifier of 0x22 followed by a two byte data identifier of 0x1001, carried on CAN identifier 0x7E0 with a single frame transport header of 0x03 giving the three byte payload length and the remaining bytes padded. The positive response is shown on CAN identifier 0x7E8, the request address plus eight, as 0x62 which is the request service plus 0x40, followed by the echoed identifier and then the data record, with a transport header of 0x05 for a two byte record. A negative response is shown as the fixed three byte form of 0x7F, the rejected service identifier and a single response code byte, with a table listing service not supported, incorrect message length, conditions not correct, security access denied, request out of range and response pending, and a note that the response code distinguishes five entirely different problems that would otherwise all look like silence. A lower panel lists the services worth knowing by number, giving diagnostic session control, ECU reset, clear diagnostic information, read DTC information, read and write data by identifier, security access, routine control and the request download, transfer data and request transfer exit trio used for flashing. A final panel shows the transport layer splitting a payload too long for one frame into a first frame, a flow control frame returned by the receiver stating how many frames it will accept and how fast, and a sequence of consecutive frames. — Request, positive response, negative response. Everything in UDS is one of these three.

Every exchange is a request from the tester and a response from the ECU.

A read of data identifier 0x1001 from an ECU addressed at 0x7E0:

Direction	CAN ID	Bytes	Meaning
Request	`0x7E0`	`03 22 10 01`	length 3, service `0x22`, identifier `10 01`
Response	`0x7E8`	`05 62 10 01 XX YY`	length 5, `0x22 + 0x40`, echoed identifier, two data bytes

Three things are worth memorising from that.

The positive response is the request plus 0x40. 0x22 becomes 0x62, 0x27 becomes 0x67, 0x31 becomes 0x71. You can read a trace in that direction without a lookup table.

The response address is the request address plus 8. 0x7E0 and 0x7E8 are the conventional pair for the engine controller, and each controller has its own.

The identifier is echoed. Several reads may be outstanding at once, and the service byte alone would not tell you which response belonged to which request.

The negative response, which is the useful one

A rejection always takes the same three-byte form — 7F, the service that was rejected, and one code saying why.

Code	Means	What you do about it
`0x11`	Service not supported	This ECU does not implement it at all
`0x13`	Incorrect message length	Your request is malformed
`0x22`	Conditions not correct	Right request, wrong moment — engine running, vehicle moving
`0x31`	Request out of range	The identifier does not exist here
`0x33`	Security access denied	Unlock first
`0x78`	Response pending	Not a failure — wait, it is working on it

0x78 catches people out. It is not an error — it means the operation will take longer than the response timeout, so the ECU is asking for more time. A flash routine may send dozens of them.

The services worth knowing by number

SID	Service	Used for
`0x10`	DiagnosticSessionControl	Change session — almost always the first message
`0x11`	ECUReset	Reboot, hard or soft
`0x14`	ClearDiagnosticInformation	Erase stored codes
`0x19`	ReadDTCInformation	Read codes, with status and snapshot data
`0x22`	ReadDataByIdentifier	Read anything the manufacturer has defined
`0x27`	SecurityAccess	Seed and key
`0x2E`	WriteDataByIdentifier	Configuration, coding, calibration values
`0x31`	RoutineControl	Start, stop or poll an ECU-side routine
`0x34` `0x36` `0x37`	RequestDownload, TransferData, RequestTransferExit	Flashing, in that order
`0x3E`	TesterPresent	Keeps a non-default session alive

Sessions and security

Sessions

An ECU is normally in the default session, where only safe reads are available. The tester changes that with 0x10.

Default — read data, read codes. Nothing that changes behaviour.
Extended — routine control, configuration writes, actuator tests.
Programming — erase and download.

A non-default session must be kept alive with periodic 0x3E TesterPresent. If the messages stop, the ECU falls back to default and any unlock is lost. That is deliberate — an abandoned session must not leave a vehicle sitting unlocked.

Seed and key

Tester requests a seed.
ECU generates a fresh random seed and returns it.
Tester computes a key from the seed using a secret algorithm.
ECU computes the same function and compares.

The secret is the algorithm, never a transmitted value. Because the seed is new each time, a recorded exchange cannot be replayed, and repeated failures trigger a mandatory delay.

Messages longer than a frame

A CAN frame carries eight bytes. Most real requests are longer, so a transport layer sits underneath.

Single frame — payload fits, the first byte is the length.
First frame — the start of a long message, declaring the total length.
Flow control — the receiver replies saying how many frames it will accept before the next flow control and how fast to send them.
Consecutive frames — the rest, each carrying a rolling sequence number.

The flow control step is the one that surprises people. The receiver sets the pace, not the sender. An ECU busy with something else will legitimately slow a flash down, and a tool that ignores the requested separation time will produce corrupted transfers that look like hardware faults.

What to take away

OBD standardises a small emissions vocabulary. UDS standardises the grammar and leaves the vocabulary to the manufacturer.
Positive response equals request plus 0x40; response address equals request address plus 8.
A negative response is three bytes, and the third one separates five quite different problems.
0x78 means wait, not fail.
Services are gated by session, and a non-default session dies if TesterPresent stops.
Seed and key stops casual access and identifies nobody. The algorithm is shared across the fleet, so one leak affects all of it.
On CAN, the receiver sets the pace of a long transfer, not the sender.

Next, what to do when the protocol says everything is fine and the vehicle disagrees — oscilloscope and CAN waveform diagnosis.