Unified Diagnostic Services (UDS)

Unified Diagnostic Services (UDS), standardised as ISO 14229, is the application-layer protocol that a diagnostic tool, an end-of-line test bench, or a reflashing tool uses to actually talk to an ECU once a connection exists. The site’s BMS Communication Architectures page covers DoIP (ISO 13400) as the transport that increasingly carries this traffic over Ethernet, alongside the older CAN-based transport (ISO 15765, “UDS on CAN”); UDS itself is protocol-agnostic and sits on top of whichever of those two gets the request to the ECU.

Request/Response Structure

UDS is a strict client-server, one-request-one-response protocol. Every request starts with a one-byte Service Identifier (SID) — 0x10 to control the diagnostic session, 0x22 to read data, 0x2E to write data, and so on — usually followed by a sub-function byte and any parameters the service needs. A positive response echoes the SID plus 0x40; a rejected request instead returns the fixed byte 0x7F, the SID that was rejected, and a one-byte Negative Response Code (NRC) explaining why — session not active, security not unlocked, conditions not correct, and similar.

Services a BMS Actually Uses

DiagnosticSessionControl (0x10) — switches the ECU between a default session (normal operation, limited diagnostic access), an extended session (broader read/write access for development and end-of-line test), and a programming session (the state required before a firmware reflash).
SecurityAccess (0x27) — a seed/key challenge-response exchange that must succeed before an ECU will accept calibration writes or a reflash. This is the same gate a TARA analysis treats as protecting a high-value asset: a weak or leaked SecurityAccess key defeats the session-control gate entirely, which is why the key derivation algorithm and its protection are themselves cybersecurity-relevant design decisions, not just a diagnostics detail.
ReadDataByIdentifier / WriteDataByIdentifier (0x22 / 0x2E) — read or write a specific Data Identifier (DID), a two-byte code mapped to a particular value such as SoH, SoC, cell voltages, VIN, or a calibration constant. This is the mechanism the site’s Pack Testing page refers to when it says SoH must be exposed “via diagnostic protocol (UDS / ISO 14229)” for end-of-line verification and Battery Passport reporting.
RoutineControl (0x31) — starts, stops, or polls the result of a defined sequence on the ECU, such as a self-test, an actuator test, or an erase routine, rather than a simple read or write.
RequestDownload / TransferData / RequestTransferExit (0x34 / 0x36 / 0x37) — the three-service sequence that actually moves a new firmware image onto the ECU during a programming session, each chunk acknowledged before the next is sent.

Where This Shows Up in BMS Design

In practice, UDS is how three quite different activities on a BMS all happen through the same protocol: end-of-line functional test at the point of manufacture (reading back SoH, calibration values and fault memory to confirm the unit is built correctly), field diagnostics through a scan tool (reading DTCs and live data during service), and firmware update (moving into a programming session and pushing new software). All three depend on the session and security model above, which is also why a compromised SecurityAccess implementation is a genuine safety concern rather than a purely IT one — see BMS Cybersecurity for how that risk is assessed and mitigated.