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

This article is the first part of the Series on 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 Introduction (Unified Diagnostic Services) – UDS Protocol Tutorial

What is UDS Protocol?

In the automotive embedded system world there are many car manufacturers are there like Audi, Jaguar, BMW, Benz, etc and each manufacturer are using different architecture and software to implement their ECUs and we can’t say for the particular brand of car they should have their own brand of ECUs only, they may procure some ECUs from other manufactures also. So it is not possible to have one tester communication language for each car brand so in order to communicate with all brands of cars, a standard protocol has been implemented. This protocol is called as Unified Diagnostics Service Unified Diagnostics Services(UDS) is a diagnostic communication protocol that is used to diagnose the Electronic Control Unit(ECU) within automotive electronics all around the world.

The word “Unified” means it is a common standard not a particular companies 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 is having OBD interface port with the help of an OBD interface cable we can connect with the car and we can able to read the fault codes or reprogram or calibrate the sensors.

Why do we need diagnostics in vehicles?

A modern vehicle has more than 100 ECUs, each ECUs performing specific functions like Battery management system, automatic gearbox, anti-lock braking system, infotainment unit, etc. So it’s difficult to test and diagnose vehicle systems when a fault occurs. Let’s consider the human, if any health issue comes to human, he used to visit the hospital to diagnose the issue to find the solution, like this vehicle also needed to diagnose its issue and it will inform to a human about the fault in the form of fault code(DTC). For this purpose, UDS protocol requests are sent to the ECU which provides a positive or negative response. The diagnostic tester tool that connects to the ECU and retrieves the fault code(Diagnostics Trouble Code)and shows it on the screen. The communication between ECU and client(testing tool) may be CAN or LIN or K- line.

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. These diagnostic protocols are used to identify the faults in ECU.

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 Frame Format

UDS is a Request and Response based protocol based on client-server architecture and it is 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.

Sub-function

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 act 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 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 act 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
Service ID (SID) + 0x40 Sub-Function ID Negative Response Code

Negative Response Frame

UDS Protocol Addressing Methods

To repair, read, write, or to 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 couldn’t able to find the exact fault causing ECU in the network. Now, the tester needs to take all the ECUs fault code (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
Bootloader TutorialsRaspberry PI Pico Tutorials
Zephyr RTOS Tutorials - STM32Zephyr RTOS Tutorials - ESP32
VHDL TutorialsUDS Protocol Tutorials
Product Reviews
Subscribe
Notify of
guest

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

0 Comments
Inline Feedbacks
View all comments