UDS protocol (ISO 14229) explained: a guide to the services

Unified Diagnostic Services (UDS) is the standardised request-response protocol that a diagnostic tester uses to talk to an electronic control unit (ECU) for fault diagnosis, configuration, data readout and reprogramming. It is defined by ISO 14229, with the protocol-agnostic application layer specified in ISO 14229-1. UDS deliberately sits above the transport and network layers, which is why the same service definitions apply whether the ECU is reached over CAN or Ethernet.

The model is strictly client-server. The tester (client) sends a request; the ECU (server) answers with exactly one response. There are no unsolicited messages from the server in normal operation. Every request opens with a one-byte Service Identifier (SID) that says what is being asked; everything after it is service-specific parameters. This simplicity is what makes UDS implementable on resource-constrained targets and consistent across an entire vehicle programme.

UDS behaviour is governed by the active diagnostic session, controlled with DiagnosticSessionControl (SID 0x10). The default session (0x01) is always active at power-up and exposes a limited, safe set of services. The extended session (0x03) unlocks fuller diagnostics and configuration, and the programming session (0x02) enables the reflashing services. Sub-functions select which session you enter, and a positive response returns timing parameters the tester must honour.

Most non-default sessions time out if the bus goes quiet, returning the ECU to the default session and dropping any unlocked state. To hold a session open during long operations, the tester periodically sends TesterPresent (SID 0x3E), typically with the suppressPositiveResponse bit set so the keep-alive generates no reply traffic. Getting this timing right is a common source of field issues: lose the heartbeat mid-flash and the ECU drops back to a safe state.

Data access is the everyday workhorse. ReadDataByIdentifier (SID 0x22) reads a value addressed by a two-byte Data Identifier (DID), from VIN and software part numbers to live sensor signals; WriteDataByIdentifier (SID 0x2E) writes coding and configuration to a DID. For fault management, ReadDTCInformation (SID 0x19) retrieves Diagnostic Trouble Codes with their status, snapshot and extended data, while ClearDiagnosticInformation (SID 0x14) erases stored DTCs.

Two services gate the sensitive operations. SecurityAccess (SID 0x27) runs a seed-and-key challenge using symmetric cryptography to unlock protected functions. The newer Authentication service (SID 0x29), introduced in ISO 14229-1:2020, adds certificate-based, asymmetric authentication with PKI for stronger trust establishment. RoutineControl (SID 0x31) starts, stops and reads the results of ECU-side routines such as memory erase, checksum verification or actuator self-tests.

ECU reflashing is a defined choreography rather than a single service. After entering the programming session and passing SecurityAccess, the tester issues RequestDownload (SID 0x34) to declare the target memory address and the uncompressed size of the image. The ECU replies with the maximum block length it will accept per transfer.

The image is then streamed with repeated TransferData (SID 0x36) requests, each carrying a block sequence counter and a chunk of the payload, sized to that agreed maximum. When the last block is sent, RequestTransferExit (SID 0x37) closes the transfer so the ECU can finalise and validate the written data. A bootloader and a robust implementation of this sequence are what stand between a routine update and a bricked controller in the field; Diadrom's Autotech Bootloader and DCS stack exist precisely to make that sequence dependable.

A successful response echoes the request SID with 0x40 added: a 0x10 request is acknowledged with 0x50, a 0x22 with 0x62, a 0x3E with 0x7E. The response SID is followed by any service-specific return data, so a tester can match a reply to its request by inspecting a single byte.

A rejected request returns a three-byte negative response: the fixed byte 0x7F, then the SID that was rejected, then a Negative Response Code (NRC). The NRCs are standardised and worth knowing on sight, for example 0x11 serviceNotSupported, 0x7F serviceNotSupportedInActiveSession, 0x33 securityAccessDenied, and 0x78 requestCorrectlyReceived-ResponsePending, which tells the tester the ECU is still working and to keep waiting rather than time out. Reading NRCs fluently is most of practical UDS debugging.

UDS itself carries no addressing or segmentation, so it relies on a transport protocol underneath. On Classical CAN and CAN FD, that layer is ISO 15765-2 (ISO-TP, also called DoCAN), which segments payloads larger than a single frame into First, Consecutive and Flow Control frames so multi-kilobyte messages move across an 8-byte bus.

For higher-bandwidth needs, particularly fast flashing, UDS runs over automotive Ethernet using Diagnostics over IP (DoIP), standardised as ISO 13400. DoIP adds vehicle discovery, routing activation and a TCP/UDP framing layer, but the UDS services above are identical to the CAN case. That separation of concerns is the real strength of ISO 14229: write your diagnostic logic once, and it remains valid as the in-vehicle network evolves from CAN to Ethernet.