Unified Diagnostic Services (UDS Protocol), born out of the necessity for a standardized communication mechanism across different vehicles, has become synonymous with vehicle diagnostics.
Its importance lies in its comprehensive approach to vehicle diagnostics and maintenance, addressing a wide range of functions from fault diagnosis to ECU programming.
UDS protocol facilitates nuanced interactions with the vehicle’s control units, enabling precise identification and rectification of issues, efficient real-time data processing, and streamlined firmware updates.
Such capabilities are crucial in an era where vehicles are not just modes of transport but complex networks of integrated electronic systems.
UDS Protocol transcends basic diagnostic capabilities, offering a suite of services that cater to complex needs like ECU programming, real-time data monitoring, and fault diagnosis. For instance, the ‘ECU Reset’ service, a service crucial for ensuring proper function post-update or repair.
In this article, we will delve into four critical UDS Services that are indispensable for any automotive product development team.
These services are the backbone of modern vehicle diagnostics, offering tools and functionalities that are essential for maintaining the high standards of performance, safety, and reliability.
What is UDS Protocol (ISO 14229)?
Unified Diagnostic Services (UDS) is an automotive protocol that lets the diagnostic systems communicate with the ECUs to diagnose faults and reprogram the ECUs accordingly (if required).
It is called unified because it combines and consolidates all the standards like KWP 2000, ISO 15765 and others.
The Architecture of the UDS protocol is designed based on the Open System Interconnection (OSI) Reference Model. Hence, the UDS software stack has a layered architecture.
One of the major functions of UDS software stack is to store the fault code in the ECU memory for every issue that occurs in the vehicle and transfer it (to the client side) as and when required.
The diagnostic tester tool has a GUI that connects to the ECU, retrieves the fault code and displays it.
Why was a Standardized UDS Protocol Needed for Vehicle Diagnostics?
As OEMs integrate/assemble automotive ECUs and components from different suppliers, the need for a set of standardized unified diagnostic services was felt.
This is because, prior to a set of Unified Diagnostic Services, OEMs and suppliers had to deal with compatibility issues between different diagnostic protocols like KWP 2000, ISO 15765, and diagnostics over K-Line.
- Unified Diagnostic Services (UDS) is the preferred choice of protocols for all off-board vehicle diagnostic activities. Off-board diagnostics refers to the examination of the vehicle parameters when the car is at servicing in the garage (while the vehicle is stationary).
- ECU flashing and reprogramming can also be performed efficiently with the help of a UDS stack.
- Additionally, UDS protocol is quite flexible and is capable of performing more detailed diagnostics as compared to other protocols like OBD and J1939.
Our UDS Protocol Stack is ISO 14229 compliant and comes with a one-time licensing fee. Want to know more?
You can also take a look at our free handy-dandy manual on the UDS Protocol Stack in a pdf format:
https://www.embitel.com/wp-content/uploads/UDS-fact-sheet_1.1.pdf
List of Categories of Unified Diagnostic Services Offered by an ISO 14229 UDS Protocol Stack
Unified Diagnostic Services has made stellar strides in simplifying ECU diagnostics.
Services like Diagnostic Session Control provide the flexibility to establish sessions tailored to specific testing needs, while ECU Reset facilitates seamless reinitialization for precise evaluations.
The Read Data by Identifier service allows direct access to critical data points, enabling real-time monitoring of sensor values and essential parameters.
Additionally, UDS-based Read Diagnostic Trouble Codes service enables prompt identification of potential issues, expediting the troubleshooting process. Let’s learn about them in more detail.
New Meta- Let’s know UDS protocol a little better! How about unravelling its pivotal services in our detailed article? We will learn how different UDS services enhance vehicle diagnostics and ECU management, making automotive technology safer.
- Data Transmission CapabilitiesThe data transmission capabilities of a UDS Protocol Stack enable the clients to read or write any information to or from the ECU.
The data can be read or written on the basis of identifiers and periodic identifiers. The client can also read data from the physical memory at the specified address.
- The information can range from static info like ECU serial number to some real time data like the current status of the sensors, engine speed, etc.
- If the client wants the ECU to send periodic service values, then ‘Read Data By Identifier Periodically’ service will be required. The client can also write data by identifier and address. Using the write service, certain parameters such as threshold values and angles can be changed.
- Usually, the permission to write some sensitive data to the ECU can be controlled by restricting the access using ‘Security Access Service’. Such permissions are reserved by the OEMs, as writing data to the ECU can interfere with the security and overall functioning of the vehicle.
- Diagnostic and Communications Management in UDS Protocol This services group primarily focuses on managing the communication flow between the tester (diagnostic tool) and the electronic control units (ECUs) within a vehicle. Below is an overview of the services under this category:
- Diagnostic Session Control (Service 0x10): Initiates different diagnostic sessions, each with unique communication and diagnostic capabilities.
- ECU Reset (Service 0x11): Resets the ECU to its default state, useful after updates or error recovery.
- Security Access (Service 0x27): Secures ECU functions via a challenge-response mechanism for protected access.
- Communication Control (Service 0x28): Manages ECU communication, controlling message transmission and reception.
- Tester Present (Service 0x3E): Keeps the diagnostic session active by signaling the ECU that the tester is still connected.
- Access Timing Parameter (Service 0x83): Adjusts timing parameters like message timeouts and intervals for optimized communication.
- Secured Data Transmission (Service 0x84): Adds a security layer to the data exchanged between the tester and ECU.
- Control DTC Setting (Service 0x85): Enables or disables the generation of Diagnostic Trouble Codes (DTCs) during diagnostics.
- Response On Event (Service 0x86): Configures the ECU to automatically respond to specific events for real-time monitoring.
- Link Control (Service 0x87): Adjusts the data transfer rate between the tester and ECU to suit diagnostic needs.
Note: DTC Snapshot data gives additional information about the engine’s parameters at the time of occurrence of the fault.
The DTC information along with other data stored in the server can be erased if need be. ClearDiagnosticInformation service can be invoked to delete all such diagnostics data stored in the server.
Once the fault codes are retrieved, the problem can be diagnosed efficiently, and repair work can follow.
- Upload/Download CapabilitiesAs highlighted earlier, UDS protocol also supports ECU reprogramming. ECU reprogramming refers to updating the ECU software. This is required to resolve any existing bug or add newly developed modules in the ECU.
Using the upload and download capabilities of UDS protocol, large packets of data can be sent and received from the car’s ECU for ECU reprogramming purpose.
The client can invoke RequestDownload and TransferData service to initiate a data transfer to the server (ECU) from the client (diagnostic tester) using a tester device.
- The server upon receiving the request will take all necessary actions to receive the data.
- A positive response message is sent when the server has successfully received the message.
Likewise, a RequestUpload service is used by the client to request data packets from the server.
- One of its practical examples can be configuring the parameters related to the vehicle’s variant code. It implies that the client can download or upload the settings/configurations in order to change or adapt a particular variant.
- Suppose a car has two variants and one of them has Anti-lock braking system (ABS) and the other doesn’t. The ECU of the variant with the ABS will need to be updated with configurations and settings to control the ABS. A task like this can be performed using this service.
- Remote Routine ActivationVehicle Diagnostics may require testing the faulty component in a given range of parameters. Moreover, during the testing phase of the vehicle, some system tests may be required to run over a period of time.
For all such tasks, remote routine activation service of UDS protocol is used.
- In order to perform a test, a routine is triggered by the client in the server’s memory. There are two methods for ending this routine – one is where the client interrupts the routine to stop it, and the other is when the server/ECU finishes the routine after a specified time frame.
- Using this service, the client can start a routine, stop a routine and also check the result that the routine produced after successful execution.
For instance, the service personnel at the garage may use this service to run the engine fan for a certain period of time and record the results. This would help him understand a particular issue well and rectify it without using any hit and trial method.
The Final Word
UDS protocol is by far the smartest diagnostic protocol capable of performing detailed vehicle diagnostics.
The future of UDS protocol is quite bright in the automotive industry as it gives the flexibility to implement diagnostics independent of the medium (CAN,K-Line or FlexRay) the vehicle communicates with.
