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 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 Automotive UDS protocol implementation and highlight Embien’s services for Unified Diagnostic Services development.
The UDS 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 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 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 be 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 – the 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 Automotive UDS Protocol defines scores of services that can be used to perform a variety of operations on the server. These services include 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 UDS services list along with their IDs is captured below.
| Function group | Service | Service ID | Description | ||
|---|---|---|---|---|---|
| Diagnostic and Communications Management | ISO 11898 | ISO 17897 | ISO 17458 | IEEE 802.3bw | ISO 21806 |
| Physical Layer | 2 Wire bus | 1 Wire bus | 2 or 4 Wire bus | 2 Wire bus | Optical or 2 Wire bus |
| Throughput | 125 Kbps/1Mbps | 20 Kbps | 10 Mbps | 100/1000BASE-T1 | 25/50/150 Mbps |
| Transfer Trigger | Event | Event | Event & Time | Event & Time | Event & Time |
| Cost | Medium | Low | Medium | High | Very High |
| Max Nodes | 127 | 16 | 64 | 30+ | 64 |
| Master | Multi-master | Single-master | Multi-master | Multi-master | Multi-master |
| Bus Topology | Linear, star, or hybrid | Linear bus | Linear, star, or hybrid | Linear, star, ring or mesh | Daisy-chain |
| Applications | Soft real-time – wide | Body Control | Hard real-time Power Train | Soft real-time - Wide | Media |
A special value of 0x7F is used to indicate negative response when an error occurs during the course of the service execution by the server.
These high-level services in the UDS services list form the backbone of the Automotive UDS 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 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 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 Automotive UDS Protocol.
At Embien, we offer comprehensive services for Automotive UDS protocol 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 Automotive UDS Protocol and can assist automotive manufacturers and developers in integrating the protocol into their vehicles. Our services include:
Firmware Design and Development :We can help design and develop customized implementations of the Unified Diagnostic Services protocol tailored to specific vehicle requirements on any MCU or platform. Our team works closely with clients to understand their needs and has provided efficient and reliable solutions on top of Renesas, NXP, STM32 and Android platforms.
ECU Firmware Update :Embien can provide support to perform update of ECUs in the vehicle network. We have helped achieve this capability for a wide range of devices using the UDS protocol. We have created gateways that download update images, act as a client and update other ECUs in the bus.
Integration and Testing :We offer integration services to seamlessly integrate the Automotive 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 Automotive UDS Protocol 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 Automotive 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 Automotive UDS Protocol, both server and client, enabling our clients to enhance their vehicle diagnostics capabilities.
This article explained the intricacies of the UDS protocol including the message structure and UDS services list. 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 Automotive UDS Protocol development needs.
Electrical/electronic architecture, also known as EE architecture, is the intricate system that manages the flow of electrical and electronic signals within a vehicle.