Understanding UDS, Unified Diagnostic Services
The protocol that lets one diagnostic tool talk to every ECU in a vehicle, whoever made it. Here is how the request and response system works, in plain terms.
UDS is a common language for vehicle diagnostics, standardised as ISO 14229. It lets a diagnostic tool, called the tester, send requests to an ECU and receive replies, using the same set of services no matter which manufacturer or supplier built the ECU. With it you can read fault codes, read and write data, run tests, manage security and flash new firmware. Every request starts with a one-byte service identifier, and every reply tells you clearly whether it worked.
| Part | What it is | Example |
|---|---|---|
| Service ID (SID) | One byte naming the service you want, the first byte of every request | 0x22 read data |
| Sub-function | An optional byte selecting a variant of the service | 0x03 extended session |
| Data Identifier (DID) | An optional 2-byte code naming a specific value | 0xF190 the VIN |
| Positive reply | The request SID with 0x40 added | 0x22 becomes 0x62 |
| Negative reply | 0x7F, then the SID, then a reason code | 0x7F 0x22 0x31 |
Why UDS became necessary
A modern vehicle contains many ECUs, and they rarely all come from one place. Even a single manufacturer sources control units from different suppliers, each with its own internal design. Without a shared standard, diagnosing them all would mean a different tool and a different language for every unit, which is unworkable in a workshop or on a production line.
ISO 14229, the UDS standard, was introduced to fix this. It defines one consistent set of diagnostic services so that any compliant tester can talk to any compliant ECU. UDS lives at the application layer, which means it is independent of the wiring underneath: the same services run over CAN, LIN, FlexRay, K-Line and automotive Ethernet, each covered by its own part of the standard. On CAN specifically, larger messages are carried using a transport protocol called ISO-TP, because a single CAN frame holds only a few bytes.
Client and server
UDS works as a client and server relationship. The client, almost always called the tester, asks for things. It might be an off-board scan tool in a garage or an on-board tester on an assembly line. The server lives inside the ECU and answers. Every ECU that supports UDS acts as a server, offering its diagnostic services to whichever tester connects.
The pattern is always the same: the tester sends a single request, and the ECU sends back a single response. The tester drives the conversation, and the ECU only ever speaks when asked. That simple rhythm, one request and one reply, is the whole basis of the protocol.
How a request is built, and how the reply is marked
A UDS request is a short sequence of bytes. The first byte is always the Service Identifier, the SID, which says what you want to do. After it come optional fields depending on the service: a sub-function byte selecting a variant, a two-byte Data Identifier naming a specific value, and any further data the request needs.
The reply uses a neat convention. For success, the ECU echoes the service back with 0x40 added to the SID, so a 0x22 request gets a 0x62 response. For a rejection, the reply instead starts with 0x7F, followed by the original SID and a one-byte reason called a Negative Response Code. That single rule, add 0x40 for yes or lead with 0x7F for no, lets you read the outcome at a glance. Try a few services below.
The common UDS services
UDS defines a large catalogue of services, but a working knowledge of a dozen covers most diagnostics. They group loosely into reading information, writing and controlling, managing the session and security, and transferring software during a flash. Service IDs run from 0x10 upward, with the range below 0x10 reserved for legislated on-board diagnostics.
Positive and negative replies
Every request ends one of two ways. A positive reply means the ECU accepted and carried out the request. Its first byte is the SID plus 0x40, and any data you asked for follows. Some services let the tester ask for the positive reply to be suppressed when only the action matters, by setting the top bit of the sub-function.
A negative reply means the request was refused. It is always three bytes: 0x7F, then the original SID so you know which request failed, then a Negative Response Code explaining why. Common reasons include the service not being supported, the conditions not being right, the request being out of range, or security access being required first. The codes turn a bare refusal into something you can act on.
On CAN, one more detail matters. A single classical CAN frame carries only eight bytes, but plenty of UDS responses are far larger, a vehicle identification number alone is seventeen. A transport protocol called ISO-TP, defined in ISO 15765-2, splits these into several CAN frames and reassembles them, so UDS can move payloads of any practical size over the bus.
Every UDS request starts with a service ID, and every reply adds 0x40 for yes or 0x7F for no. Learn that pattern and the rest is detail.
UDS FAQ
What is UDS in simple terms?
UDS, Unified Diagnostic Services, is a standard language for talking to vehicle ECUs for diagnostics. Defined in ISO 14229, it lets one tester read faults, read and write data, run tests and flash firmware on ECUs from any manufacturer that supports it.
What is a service ID in UDS?
The service ID, or SID, is the first byte of every request and names the service being asked for, such as 0x22 to read data or 0x10 to control the diagnostic session. Request SIDs run from 0x10 upward, with the range below 0x10 reserved for legislated on-board diagnostics.
How does a UDS positive response work?
A positive response starts with the request SID plus 0x40. So a 0x22 request returns 0x62, a 0x10 request returns 0x50, and a 0x3E request returns 0x7E, followed by any requested data.
What is a UDS negative response?
A negative response signals a rejection. It is three bytes: 0x7F, then the original SID, then a Negative Response Code giving the reason, such as 0x31 request out of range or 0x33 security access denied.
What is the difference between UDS and OBD?
OBD covers legislated emissions diagnostics with a fixed, public set of parameters, using service IDs below 0x10. UDS is the broader manufacturer protocol for deeper diagnostics, configuration and reprogramming, using service IDs from 0x10 upward. They share the same request and response style.
How does UDS work over CAN?
UDS sits at the application layer and runs on CAN using the ISO-TP transport protocol, ISO 15765-2. Because a CAN frame holds only eight bytes, ISO-TP splits larger messages into several frames and reassembles them at the other end.
Written by the engineering team at Influx Technology. Service identifiers and response codes follow ISO 14229. Always confirm against the specification and your ECU documentation.
Capture UDS traffic alongside your CAN data
The data loggers from Influx Technology, including the REXGEN and REBEL ranges, record CAN traffic so you can capture diagnostic exchanges in context. REXDESK and DIALOG handle configuration and decoding, turning raw frames into readable signals.
