On our earlier introductory article on the Automotive UDS Protocol, the overall picture of the protocol is given including its applications, network architecture, etc. It has been shown that Unified Diagnostic Services is a Client-Server based protocol capable of running on different transport layers including CAN, Ethernet, FlexRay, LIN etc.
In this article, we will take a closer look at the internals of the Unified Diagnostic Services protocol, message structure and UDS services list being defined as part of ISO 14229. We will also explore the design considerations for the UDS protocol implementation and highlight Embien's services for Unified Diagnostic Services development. Our digital transformation services can assist OEMs in adopting Unified Diagnostic Services across their vehicle product lines efficiently.
The Unified Diagnostic Services Protocol provides Application layer services — also called diagnostic services — to the higher-level application. They are broadly classified as Confirmed Services or Unconfirmed Services based on whether a response is expected from the server.
While there are many services defined, all of them share a common packet format. There are 6 service primitives to be provided to support any of these services. These primitives are typically callbacks/APIs that are used by the UDS layer to send/receive packets. The primitives are:
| Service Primitive | Originator | Description |
|---|---|---|
| Request | Client Application | Initiates the specific Diagnostic service |
| RequestConfirm | Client Transport | Indicates the request has been successfully delivered to the server |
| Indication | Server Transport | Indicates reception of request to the server |
| Response | Server Application | Response is ready to be transmitted |
| Confirmation | Client Transport | Response is successfully received from the server |
| ResponseConfirm | Server Transport | Response is successfully delivered to client |
The typical flow of service primitives for a confirmed service is as follows.
Similarly for an unconfirmed service, it is as follows.
As can be seen, whether the response is needed for the service or not, it is essential to have the transport acknowledge the transmission and successful delivery of the message to the other party.
The Unified Diagnostic Services Protocol defines a high-level message structure that is common across the low-level transport protocols. The typical format looks like as depicted below.
Some of the major fields in message structure are:
Message Type:Indicates the type of message and could be one of diagnostics, remote diagnostics, secure diagnostics, or secure remote diagnostics.
Source Address:16-bit address indicating the application layer source address.
Target Address:16-bit address that could be the target physical address (uses point-to-point communication to the client) or the functional address (uses broadcast communication that will be responded to by the intended client).
Target Address Type:Indicates if the target address is physical or functional.
Remote Address:Optional field to extend the available address space if necessary.
Length:Indicates the length of the parameter field.
Service ID:1-byte value that represents the service that the request or response corresponds to.
Parameters:A variable-length field that has sub-functions and other service-specific parameters. Both the Request and Response messages follow the same structure and are differentiated by the value of the Service ID — responses have their 6th bit set (Request | 0x40). For example, the ECU Reset service has a service ID 0x11 and its response will have the service ID 0x51.
The below picture depicts the frame format for the ECU Reset service (only the application PDU part).
The response ID is simply the sixth bit set of the requested value. As the response message has 2 bytes, the length is also updated accordingly.
The Unified Diagnostic Services protocol defines scores of services that can be used to perform a variety of operations on the server. The UDS services list includes diagnostic session control, communication control, and routine control packets. The diagnostic session control service is used to establish and terminate a diagnostic session with the vehicle. It allows the diagnostic tool to switch between different diagnostic modes, such as default session, programming session, extended session, etc.
The communication control service is responsible for managing the communication flow between the diagnostic tool and the vehicle's ECUs. It provides mechanisms for flow control, error detection, and error recovery. The routine control service is used to initiate diagnostic routines, such as reading or writing specific data, executing tests, or configuring vehicle parameters.
Some of the major entries from the UDS services list along with their IDs are captured below:
| Service Group | Service Name | Service ID | Description |
|---|---|---|---|
| Diagnostic & Communication Management | DiagnosticSessionControl | 0x10 | Establishes and controls diagnostic sessions |
| Diagnostic & Communication Management | ECUReset | 0x11 | Forces a reset of the ECU |
| Diagnostic & Communication Management | SecurityAccess | 0x27 | Provides authenticated access to restricted services |
| Data Transmission | ReadDataByIdentifier | 0x22 | Reads a data record identified by a DID |
| Data Transmission | WriteDataByIdentifier | 0x2E | Writes a data record identified by a DID |
| Stored Data | ReadDTCInformation | 0x19 | Reads diagnostic trouble code information |
| Stored Data | ClearDiagnosticInformation | 0x14 | Clears diagnostic trouble codes and related info |
| Upload / Download | RequestDownload | 0x34 | Initiates a data download to the server |
| Upload / Download | TransferData | 0x36 | Transfers a block of data |
| Upload / Download | RequestTransferExit | 0x37 | Terminates the data transfer |
A special value of 0x7F is used to indicate negative response when an error occurs during the course of service execution by the server.
These high-level services in the UDS services list form the backbone of the Unified Diagnostic Services protocol and enable effective communication and diagnostics.
The UDS protocol implementation requires careful consideration of various design aspects to ensure optimal performance and compatibility. Some key design considerations include:
Hardware and Software Compatibility:The protocol should be implemented in a way that ensures compatibility with the vehicle's hardware and software. This includes selecting appropriate hardware components and implementing software modules that support the protocol's requirements.
Communication Interface:The communication interface between the diagnostic tool and the vehicle's ECUs should be designed to support the protocol's communication requirements. This may involve selecting the appropriate communication protocols, such as CAN or Ethernet, and implementing the necessary drivers and interfaces.
Security and Authentication:To ensure secure communication, the UDS protocol implementation should incorporate robust security mechanisms, such as encryption and authentication. This helps prevent unauthorized access and protects against data tampering.
Error Handling and Recovery:The implementation should include mechanisms for error detection, error handling, and error recovery. This ensures reliable communication and prevents data loss or corruption in the event of communication errors.
Performance Optimization:Optimizing the UDS protocol implementation for performance is crucial to ensure efficient diagnostics and minimize delays in communication. This may involve optimizing data transfer rates, reducing overhead, and implementing efficient algorithms.
By considering these design aspects, automotive manufacturers and developers can create robust and effective implementations of the Unified Diagnostic Services protocol. Our automotive engineering services team provides end-to-end support for UDS protocol implementation on a range of embedded platforms.
At Embien, we offer comprehensive services for Unified Diagnostic Services implementation. Our team of experienced engineers and developers specializes in designing and implementing communication protocols for vehicle diagnostics. We have extensive knowledge and expertise in the Unified Diagnostic Services protocol and can assist automotive manufacturers and developers in integrating the protocol into their vehicles. Our services include:
A critical application of Unified Diagnostic Services is ECU firmware update via the automotive bootloader and diagnostics services flow. Embien designs and delivers complete bootloader solutions using the UDS services list — covering RequestDownload (0x34), TransferData (0x36), and RequestTransferExit (0x37) — enabling secure over-the-air and cable-based FOTA. Our automotive bootloader and diagnostics services have been deployed on Renesas, NXP, STM32 and Android platforms, supporting both server (ECU) and client (tester) roles.
Validating a UDS protocol implementation in isolation is insufficient for safety-critical automotive systems. UDS validation based on HIL tools (Hardware-in-the-Loop) ensures that the UDS services list is exercised against real ECU hardware stimulated by a controlled environment. Embien provides UDS validation based on HIL tools to verify diagnostic session management, DTC handling, and flash programming sequences before integration into the vehicle network. This methodology significantly reduces integration risk and shortens time to certification.
Integration and Testing:We offer integration services to seamlessly integrate the Unified Diagnostic Services protocol into existing vehicle systems and diagnostic tools. Our rigorous testing processes ensure compatibility, reliability, and performance.
Optimization and Performance Enhancement:Our team can optimize the performance of the Unified Diagnostic Services implementation, improving data transfer rates, reducing latency, and enhancing overall efficiency.
Support and Maintenance:We provide ongoing support and maintenance services to ensure the continued reliability and performance of the UDS protocol implementation. Our team is available to address any issues or provide assistance as needed.
With our expertise and dedication to quality, we aim to deliver effective and robust implementations of the Unified Diagnostic Services protocol, both server and client, enabling our clients to enhance their vehicle diagnostics capabilities.
This article explained the intricacies of the Unified Diagnostic Services protocol including the message structure and UDS services list. The UDS protocol implementation demands careful attention to session management, security, and transport layer selection. Our services at Embien can assist in the development, integration, and optimization of the protocol, ensuring reliable and efficient vehicle diagnostics. Contact us today to learn more about how we can help with your Unified Diagnostic Services development needs.
Embien's integrated product development services cover the full lifecycle of UDS protocol implementation — from architecture design to ECU integration and HIL-based UDS validation.
Embien's electronic manufacturing supports UDS services list-compliant ECU hardware, ensuring reliable Unified Diagnostic Services implementation across embedded platforms.
A live Unified Diagnostic Services implementation enabling remote ECU diagnostics and firmware-over-the-air update using UDS protocol on an Android-based vehicle cluster.