UDS Protocol Introduction (Unified Diagnostic Services) – UDS Protocol Tutorial Part 1

This article is the first part of the Series on the UDS Protocol and carries the discussion on the Unified Diagnostic Services Protocol. The aim of this series is to provide easy and practical examples that anyone can understand. This is the UDS Protocol Introduction (Unified Diagnostic Services) – UDS Protocol Tutorial Part 1

UDS Protocol Tutorial

What is the UDS Protocol?

Navigating the world of automotive embedded systems reveals a landscape bustling with diverse car manufacturers—Audi, Jaguar, BMW, Benz, and others—each employing unique architectures and software to actualize their ECUs. Gone are the days when a singular car brand should exclusively align with its own ECU.

Nowadays, collaborations extend to procuring ECUs from various manufacturers. This dynamic interplay necessitates a flexible approach to tester communication, as a uniform language cannot fit every car brand’s distinct communication needs.

Enter the solution: a standardized protocol. Termed Unified Diagnostics Services (UDS), this diagnostic communication protocol harmonizes ECU diagnosis within the global automotive electronics domain.

Experience the seamlessness of UDS as it bridges the gap between manufacturers and ushers in a new era of automotive diagnostics.

The word “Unified” means it is a common standard, not a particular company standard, so the service and functionality will be the same for all the ECU manufacturers(OEM). The word “Diagnostics” means it is a technique to identify any kind of illness(faults) of the vehicle. It also allows us to reprogram and calibrate the sensors.

Unified Diagnostic Services Protocol

Tester to communicate with ECUs, each car has having OBD (On-Board Diagnostics) interface port. With the help of an OBD interface cable, we can connect with the car, and we can read the fault codes or reprogram or calibrate the sensors.

Why do we need diagnostics in vehicles?

In today’s modern vehicles, there are more than 100 tiny control units that handle different tasks like managing the battery, controlling the gearbox, handling braking, and even taking care of the entertainment system. But when something goes wrong, it’s like when a person gets sick.

Just as a person goes to a doctor to figure out the problem and find a solution, a vehicle needs to figure out its issue too. It does this by using something called a “fault code” or “Diagnostics Trouble Code (DTC).” This code tells us what’s wrong with the vehicle.

To help with this, there’s a special way of talking to the control units called the Unified Diagnostics Service (UDS) protocol. It’s like the vehicle asking the control unit, “Hey, what’s going on?” The control unit responds with an answer that helps us understand the problem.

We use a special tool to talk to the control units. This tool connects to the control unit and gets the fault code. It’s kind of like a translator between us and the vehicle. This communication can happen using different ways, like through CAN, LIN, or K-line methods.

So, just like people need to talk to doctors to figure out what’s wrong, vehicles use the UDS protocol and tools to talk to their control units and find out what’s going on when something isn’t right.

Difference between Communication Protocol and Diagnostic Protocol

Communication protocol means it is used to communicate between two microcontrollers or to communicate between a controller and a computer to transfer the data. In automotive electronics, we have ECUs (Electronic Control Unit). These diagnostic protocols are used to identify the faults in ECU.

Evolution of Diagnostic Protocols Standards

Before introducing UDS, there were many Diagnostic protocols like KWP2000, Diagnostics over K-Line, and ISO-15765. Automotive OEMs and suppliers have agreed to rely on Unified Diagnostic Services (UDS) as a standard protocol to ensure International compatibility.

This diagnostic protocol is defined in ISO-14229 standard, This protocol is based on the Open System Interconnect (OSI) model, and it uses the fifth (Session layer) and seventh (Application layer) levels of the OSI model.

Available ISO-14229 Standards

The general UDS protocol is defined in some sub-standard of ISO-14229. Also, the standard ISO-14229 consists of the following parts,

  1. ISO 14229-1: Specification and requirements for UDS Protocol
  2. ISO 14229-2: Session layer services for UDS Protocol
  3. ISO 14229-3: Unified diagnostic services on CAN implementation (UDSonCAN)
  4. ISO 14229-4: Unified diagnostic services on FlexRay implementation (UDSonFR)
  5. ISO 14229-5: Unified diagnostic services on Internet Protocol implementation (UDSonIP)
  6. ISO 14229-6: Unified diagnostic services on K-Line implementation (UDSonK-Line)
  7. ISO 14229-7: Unified diagnostic services on Local Interconnect Network implementation (UDSonLIN) (Under ongoing research for implementation)
  8. ISO 14229-8: Unified diagnostic services on UDSon
UDS Protocol ISO-14229 standards
UDS Protocol ISO-14229 standards

UDS Protocol Frame Format

UDS is a Request and Response-based protocol based on client-server architecture, and it has having unique service ID(SID). SID is the size of one byte, and it ranges from 0x00 to 0x3E.

Basically, there are 4 types of frame formats,

  1. Request frame with sub-function ID
  2. Request frame without sub-function ID
  3. Positive Response Frame
  4. Negative Response Frame

Before going to know about frame format in detail, it’s good to know what is Service ID and Sub-function.

Service ID

It is a 1-byte identifier, it indicates the services which are defined in ISO-14229. The server (ECU) sees this identifier and does the operation based on this identifier.

For example, service ID: 0x11 -It is an ECU Reset.


It is a part of the service ID and it is an optional field.

Under ECU Reset service ID (0x11), there are 3 sub-function IDs are there.

  1. Hard Reset(0x01)
  2. Key-Off On Reset(0x02)
  3. Soft Reset(0x03)

Request Frame Format

Request with Sub-function ID

The request frame is used to send the request to the server(ECU) from the client(Tester tool).

Service ID (SID) Sub-Function ID Data Parameters

Request Frame with Sub-Function ID

Request without Sub-function ID

Service ID (SID) Data Parameters

Request Frame without Sub-Function ID

Response Frame Format

Positive Response Frame:

In UDS diagnostics, the tester acts as a client, and ECUs act as a server. When the server (ECU)receives the service request from the tester, the server checks the message. If everything is fine, then it executes the requested service and responds to the client with a positive response. If the response is positive, then the 6th bit of the SID should be 1.

For example,

Service ID – 0x31 =>  0 0 1 1 0 0 0 1

For a positive response, 0 1 1 1 0 0 0 1 is equal to 0x71 (0x31 + 0x40).

In another way, we can say the positive response means SID+ 0x40, There is no logical reason for this. Simply, it is defined in International standard IS0-14229-1.

Service ID (SID) + 0x40 Sub-Function ID Data Response Code

Positive response with Sub-Function ID

Service ID (SID) + 0x40 Data Response Code

Positive response with Sub-Function ID

Negative Response Frame:

In UDS diagnostics, the tester acts as a client, and ECUs act as a server. When the server (ECU) receives the service request from the tester, ECU checks the message. If the server finds something wrong, then it executes the negative response and sends the Negative response code(NRC). There are some Negative Response Codes given below.

  1. General Rejection – 0x10
  2. Sub-Function Not Supported – 0x12
  3. Incorrect Message Length(IML) – 0x13
  4. Busy Repeat Request – 0x21
  5. Condition not correct – 0x22
  6. Request sequence Error – 0x24
  7. Request Out Of Range(ROOR) – 0x31
  8. Security Access Denied – 0x33
  9. Invalid Key – 0x35
0x7F Service ID Negative Response Code

Negative Response Frame

UDS Protocol Addressing Methods

To repair, read, write, or flash the new software, the tester needs to connect the testing tool to the ECU. If we want to connect the ECU to the system, we need to assign the address.

There are 2 types of addressing methods.

  1. Physical Addressing
  2. Functional Addressing

Physical Addressing

In physical addressing mode, If the tester knows which ECU is causing the issue, the tester can connect the testing tool directly to that particular ECU and get the fault code(DTC). To achieve this, each ECU should have its own ECU Identification Number.

So the tester connects with the ECU and sends the request and gets the response from the ECU. This method is called as Physical Addressing method.

Functional Addressing

In modern vehicles, a lot of ECUs are available based on the different OEMs. Suppose the tester knows there is a fault in the network(Bus) but he isn’t able to find the exact fault causing ECU in the network. Now, the tester needs to take all the ECUs’ fault codes (DTC) in the network.

In the vehicle, there will be a Global ECU Identifier, which will be implemented in all the CAN receivers. So the ECU can receive the request and give a response to the tester. This method is called as Functional Addressing method.

In our next tutorial, we will discuss the Function Group Diagnostics and Communication Management.

You can also read the below tutorials.

Linux Device Driver TutorialsC Programming Tutorials
FreeRTOS TutorialsNuttX RTOS Tutorials
RTX RTOS TutorialsInterrupts Basics
I2C Protocol – Part 1 (Basics)I2C Protocol – Part 2 (Advanced Topics)
STM32 TutorialsLPC2148 (ARM7) Tutorials
PIC16F877A Tutorials8051 Tutorials
Unit Testing in C TutorialsESP32-IDF Tutorials
Raspberry Pi TutorialsEmbedded Interview Topics
Reset Sequence in ARM Cortex-M4BLE Basics
VIC and NVIC in ARMSPI – Serial Peripheral Interface Protocol
STM32F7 Bootloader TutorialsRaspberry PI Pico Tutorials
STM32F103 Bootloader TutorialsRT-Thread RTOS Tutorials
Zephyr RTOS Tutorials - STM32Zephyr RTOS Tutorials - ESP32
AUTOSAR TutorialsUDS Protocol Tutorials
Product ReviewsSTM32 MikroC Bootloader Tutorial
VHDL Tutorials
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newest Most Voted
Inline Feedbacks
View all comments
Table of Contents