What Is UDS? Unified Diagnostic Services Explained

Why read this

UDS is a request-response diagnostic protocol that gives a tester a standard way to read ECU data, control sessions, handle faults, run routines, and support programming.

UDS in simple words

UDS is a standard way for a diagnostic tester to ask an ECU for information or request a diagnostic action.

UDS stands for Unified Diagnostic Services. The main protocol is defined by ISO 14229.

A tester sends a request. The ECU sends a positive response, a negative response, or no response if communication fails.

Tester -> UDS request -> ECU
Tester <- UDS response <- ECU

What UDS is used for

UDS supports services for work such as:

changing diagnostic sessions
reading ECU data
writing allowed ECU data
reading diagnostic trouble codes
clearing diagnostic information
running ECU routines
controlling communication
security access
software download and programming
resetting an ECU

Not every ECU supports every service. Supported services, data identifiers, routines, sessions, and access rules are defined by the project.

UDS over CAN

UDS messages can be larger than one classical CAN frame. On CAN, UDS commonly uses ISO-TP, defined by ISO 15765-2, to split and reassemble longer messages.

The layers are:

UDS       -> diagnostic service and data
ISO-TP    -> moves long diagnostic payloads over CAN frames
CAN       -> sends the actual frames on the bus

UDS can also run on other transports, such as Diagnostics over IP. Do not assume UDS always means raw CAN frames.

Service IDs

Each UDS request begins with a service identifier, often called SID.

Common examples include:

SID	Service
`0x10`	Diagnostic Session Control
`0x11`	ECU Reset
`0x14`	Clear Diagnostic Information
`0x19`	Read DTC Information
`0x22`	Read Data By Identifier
`0x27`	Security Access
`0x2E`	Write Data By Identifier
`0x31`	Routine Control
`0x34`	Request Download
`0x36`	Transfer Data
`0x3E`	Tester Present

A positive response SID is commonly the request SID plus 0x40.

Request:  0x22 Read Data By Identifier
Response: 0x62 Positive Read Data By Identifier response

DID meaning

DID stands for Data Identifier. A DID identifies a piece of ECU data.

For example, DID 0xF190 is commonly used for the Vehicle Identification Number.

A request may look like:

22 F1 90

The positive response begins with:

62 F1 90 ...data...

OEM and supplier projects define many additional DIDs. You need the correct diagnostic specification to know their sizes, encodings, and access conditions.

Diagnostic sessions

An ECU can expose different functions in different sessions.

Common session ideas are:

default session
programming session
extended diagnostic session

A service that works in the extended session may be rejected in the default session. Sessions also have timing and inactivity behavior. Tester Present messages may be needed to keep a non-default session active.

Positive and negative responses

A positive response means the ECU accepted and completed the request.

A negative response begins with 0x7F:

7F <request SID> <negative response code>

Example:

7F 22 31

This means the ECU rejected service 0x22 with negative response code 0x31, Request Out Of Range.

Other common reasons include:

service not supported
sub-function not supported
incorrect message length
conditions not correct
security access denied
request sequence error
response pending

A good tester reports the code clearly instead of only showing “request failed.”

Security Access

Some UDS functions are protected. The tester may request a seed and return a calculated key.

Security Access is not permission to bypass an ECU's protection. The algorithm and access process belong to the vehicle or ECU program. Use only approved credentials and test procedures.

Modern systems may also use additional authentication and secure diagnostic mechanisms.

DTC meaning

DTC stands for Diagnostic Trouble Code. An ECU records DTC information when monitored conditions fail.

UDS services can request information such as:

which DTCs are stored
current status bits
snapshot data
extended data
supported DTC information

The exact behavior depends on the ECU implementation and diagnostic specification.

UDS request example

Read DID 0xF190:

Application request: 22 F1 90

When carried as a short ISO-TP single frame on CAN, it may look like:

03 22 F1 90 00 00 00 00

The first byte says three UDS bytes follow. A longer VIN response needs ISO-TP multi-frame handling.

Use an ISO-TP library. Do not treat the first CAN frame as the complete UDS response.

UDS vs OBD-II

UDS	OBD-II
Broad ECU diagnostic protocol	Standardized emissions-related diagnostics
Project-specific DIDs and routines	Standard modes and PIDs for regulated data
Used for development, service, manufacturing, and programming	Commonly used by generic scan tools for emissions data
Can support ECU flashing	Focused on diagnostic and emissions information

Some vehicles support both.

The simple summary

UDS is a request-response protocol for ECU diagnostics. Services identify the action, DIDs identify data, sessions control access, and negative response codes explain why a request was rejected. Over CAN, ISO-TP carries UDS messages that do not fit in one frame.