UDS Software Stack Implementation and Integration Projects for Automotive Customers

4 UDS Protocol Software Services that Every Automotive Product Development Team Should Know

‘Body Electronics’, ‘Embedded Systems’, ‘Electronic Control Units’ (like Body Control Module, Powertrain, Transmission Control, Battery Management Systems), ‘Electric Motors’ and ‘Motor Control Systems’ – if you happen to eavesdrop the conversation of modern-day Automotive Product Development teams, chances are that you will hear a lot of these terms!

This is a testimonial of the amount of presence & influence of electronic embedded systems in the automotive industry. And this presence has been rapidly increasing and becoming more and more complex.

This rapid implementation also required facilitation of diagnostic and repair of these electronic embedded systems, when a fault occurs.

Thus, diagnostic systems were developed so that the product development teams, software/hardware testing teams and after-sales teams can detect faults in a vehicle by connecting their diagnostic tester tools to the electronic control units (ECUs) in the vehicle.

And this is where the software stack based on UDS Protocol (ISO 14229) plays a significant role.

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 a Standard Software Solution for Vehicle Diagnostics was Needed?

As OEMs integrate/assemble automotive ECUs and components from different suppliers, the need for a standard diagnostic protocol was felt.

This is because, prior to a Unified Protocol, 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.

List of Categories of Services Offered by an ISO 14229 UDS Protocol Stack

1. Data Transmission Capabilities

   The 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.

 

2. Fault Diagnostics

   One of the main services of the UDS protocol is fault diagnostics. Whenever an issue occurs in the vehicle, a diagnostic trouble code (DTC) corresponding to the fault is stored in the ECU fault code memory (FCM). The service personnel at the garage can retrieve these DTCs by using the ReadDTCInformation service.

   • Fault Diagnostics service allows the client to read both emission related and non-emission related DTC information. The client can define a status mask based on which the DTC information will be displayed.
   • DTC Snapshot data can also be retrieved using this service.

   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.

   
   

 

3. Upload/Download Capabilities

   As 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.

 

4. Remote Routine Activation

   Vehicle 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.