top of page
Writer's pictureInflux Technology

Understanding UDS (Unified Diagnostic Services) - A simple explanation


Unified Diagnostic Services (UDS) is a protocol widely adopted in automotive electronic control units (ECUs) by Tier-1 OEMs. It plays a critical role in enabling unified diagnostics across ECUs, offering a variety of services such as diagnostics, firmware updates, routine testing, and more.



Why UDS Became a Mandatory Protocol


The automotive industry comprises of multiple companies, each using unique architectures for vehicles and ECUs. Even within a single manufacturer, not all ECUs are produced in-house; many are sourced from different suppliers. This diversity makes simultaneous diagnostics across various ECUs highly complex and almost unmanageable.


To address this challenge, ISO 14229, the standard for UDS, was introduced. This standard ensures diagnostic uniformity across different manufacturers and supports various communication protocols, including CAN, KWP2000, Ethernet, and LIN.



UDS protical talking to CAN, LIN, K-Line and LIN. Then to multiple ECUs from multiple suppliers. Talking to each other using UDS.
A simple diagram showing UDS linking other protocols and communicating with ECU's.


UDS Overview and Structure


UDS operates on the Application Layer of the OSI (Open Systems Interconnection) model and is defined by several standards under ISO 14229:


  • ISO 14229-1: Specifications and requirements

  • ISO 14229-3: UDS on CAN

  • ISO 14229-4: UDS on FlexRay

  • ISO 14229-5: UDS on IP

  • ISO 14229-6: UDS on K-Line

  • ISO 14229-7: UDS on LIN



UDS Working topology


Client to OBD Interface to Vehicle OBD Port (In the vehicle) to Server

UDS functions using a client-server topology, where a "Tester" (client) requests services, and the ECU (server) responds.




Tester/Client

Tester can also be referrd to Client

The client, often referred to as a tester, interacts with the ECU for diagnostic functions. It can be implemented in tools such as:


  • Off-board scan tools: Used by garage mechanics.

  • Onboard tester tools: Used in assembly plants.


The tester can perform tasks like inspection, monitoring, testing, and diagnostics.


Server (ECU)

ECU can also be referrd to Server

The server resides within the ECU and offers diagnostic services. Each vehicle ECU must comply with UDS to communicate with the tester. The server supports actions such as:


  • Initiating diagnostic sessions.

  • Reading or clearing diagnostic trouble codes (DTCs).

  • Running component tests and returning results.

  • Flashing firmware.

  • Managing data (read/write).



UDS Services and Messages


UDS defines a range of diagnostic services requested by the client and performed by the ECU server. These services include:


  • Formatting request/response messages.

  • Defining timing parameters.

  • Managing service handling between testers and ECUs.


SID 1 Byte (Mandatory), Sub Fn 1 Byte (Optional), DID 2 Bytes (Optional), Data Req nBytes (Optional)
A service request message for UDS

Service Request Format


A UDS service request consists of:


Service Identifier (SID):

A mandatory 1-byte field (0x00 to 0x3E) identifying the requested service.


Sub-function (SubFn):

Optional 1-byte field specifying a sub-function for certain services (e.g., start/stop a service or request results).


Data Identifier (DID):

A 2-byte field used to identify specific data elements. DIDs are standardised in Onboard Diagnostics (OBD) but are custom-defined in UDS for each manufacturer.


Data Request Field:

This optional field contains metadata related to the DID for the specific message.


Response Types in UDS


Once a service request is received, the server may respond with either a positive or negative response.


Positive Response


The server sends a positive response if the request is valid and successfully executed. Key fields include:


  • Positive Response SID (PR SID): Derived by adding 0x40 to the original SID.

  • Sub-function, DID, and Data Request: Optional fields as needed.


For example: If SID = 0x1E, then PR SID = 0x1E + 0x40 = 0x5E.




PR SID 1 Byte, Sub Fn 1 Byte, DID 2 Bytes, Data Req n Bytes
A positive response message


Negative Response


If the service cannot be performed, the server issues a negative response. This could be due to reasons such as incorrect request formatting, unsuitable working conditions, or security restrictions. Key fields include:


  • Negative Response SID (NR-SID): Pre-defined as 0x7E.

  • Service Request SID (SID RQ): Identifies the service that was rejected.

  • Negative Response Code (NRC): Indicates the reason for rejection.



NR- SID 1 Byte, SID RQ 1 Byte, NRC 1 Bytes
A negative response message

Conclusion

UDS has revolutionised vehicle diagnostics by offering a unified protocol that facilitates seamless communication between testers and ECUs. This standardisation improves efficiency, reduces complexity, and ensures compatibility across diverse automotive systems.


For a deeper dive into UDS and Negative Response Codes (NRCs), visit the resources below:



References:


Website link for NRCs:



 


Check out our UDS-compatible devices!



Influx Technology CAN Bus DataloggerRebel range

Data loggers are ideal for vehicle engineering teams that use XCP or UDS protocols.


DiaLog tool for working with USD with the Rebek Range

Data logger configuration tool with integrated data analysis



Module Analyser a tool for indepth USD and XCP

Module Analyser is a 5 in 1 easy to use CAN bus analyser




23 views0 comments

Recent Posts

See All

NB-IoT

留言


bottom of page