Unified Diagnostics Services (UDS) stands as the backbone of modern automobile diagnostics, encompassing a myriad of features designed to ensure the well-being of vehicles. Governed by the ISO-14229 standard, the automotive UDS protocol serves as the universal language adopted by automotive OEMs to establish a common system capable of diagnosing any vehicle. However, navigating the complexities of the automotive UDS protocol and validating its implementation is far from straightforward. Testers often find themselves engaged in a series of operations and steps to execute even for a single test. In practice, several approaches are employed to conduct automotive UDS protocol testing — ranging from manual UDS validation using automotive diagnostic tools to custom test applications and HiL testing in automotive environments. Using DevOps services to automate ECU test pipelines can significantly accelerate automotive UDS protocol validation cycles.
UDS Services Test cases
Before delving into the different approaches and determining the optimal method for testing, it is crucial to first grasp the various test scenarios associated with the automotive UDS protocol. Understanding the fundamentals of the automotive UDS protocol is essential for laying a strong foundation in this domain. For a comprehensive overview, refer to the article titled 'Introduction to Automotive UDS Protocol', which will provide valuable insights into the core principles of UDS and set the stage for exploring testing methodologies and best practices. Digital transformation services in the automotive domain increasingly rely on robust automotive UDS protocol validation to ensure ECU software quality.
While testing UDS features with automotive diagnostic tools, it is important to cover various services, each serving a specific function within the diagnostic ecosystem. Some of these services, along with their purpose and test cases, are captured below:
| Service/Feature | Purpose | Test case |
|---|---|---|
| Diagnostic Session Control (0x10) | This service involves configuring the Electronic Control Unit (ECU) into the required session before initiating any diagnostic operation | Testers need to ensure that services associated with the active session alone are allowed while others are disallowed. This ensures proper isolation and functionality within the designated session |
| ECU Reset (0x11) | This service does soft resets, hard resets, and other reset mechanisms | Invoke this service during normal execution or ongoing testing. The objective of a tester is to validate the system's resilience and stability in response to interruptions, ensuring seamless operation regardless of reset events |
| Security Access (0x27) | This is used to gain access to security critical services. Certain services are expected to work only after establishing a secure session to the ECU |
Testers need to check those services are protected with security and not working without gaining access. Testers need to perform penetration test to validate the implementation |
| Diagnostic Trouble Code (DTC) | Diagnostic Trouble Code (DTC) is stored in the Electronic Control Unit's (ECU) Fault Code Memory (FCM) during Fault occurrence in the system | Testers shall test the record of DTC under different stages/scenarios and operating conditions. It is also important to test if the cleared faults are reflected in the DTC records |
| DTC Aging | This evaluates past diagnostic results to determine if a confirmed Diagnostic Trouble Code (DTC) can be cleared from Non-Volatile Memory (NVM) based on a defined number of error free cycles | Testers track the aging process of DTCs by simulating fault conditions and monitoring the response of the ECU. Testers validate whether DTCs are cleared from NVM accurately and timely, based on the designated number of failure-free cycles |
| Routine Control | Certain tests are expected to run over a specified period. With this service, testers can initiate, terminate, and verify the results of routines executed by the Electronic Control Unit (ECU) | Testers provide the necessary inputs to the ECU and validate the working of the associated routines. This involves initiating tasks like erasing fault memory, reading or writing calibration/configuration data, performing self-tests and functional tests, and activating or deactivating features within the ECU |
Many other services such as Firmware upload/download, Communication control etc. must be validated as per the product specification. Apart from these services, other general functionalities have to be tested. For example, in most cases, the UDS feature is to be enabled only when the vehicle is in standstill condition with engine OFF. There are performance requirements associated with the connectivity including the adherence to DoCAN transport timing, size of the packet transfers, throughput metrics etc. The testing process should ensure these are validated and reported.
UDS Testing Methods
As we have seen, there are many diagnostic services offered by a typical ECU implementing the automotive UDS protocol. Beyond these, based on the ECU feature list, the number of functionalities under many services can vary from a few dozen to several hundred. Testing of the automotive UDS protocol implementation in an ECU can therefore be a daunting task. Let’s look at a couple of methods followed generally in the automotive industry.
Manual UDS Validation
One simple method for automotive UDS protocol testing involves a manual approach where testers follow test specifications, frame packets, and transmit diagnostic messages individually. Testers then analyze response messages to ensure data correctness. This manual UDS validation approach uses automotive diagnostic tools like Peak CAN analyzer, WaveShare, BusMaster, or Vector to perform these operations. While straightforward, manual UDS validation is inefficient and primarily suitable for simple initial testing or for developers. It is time-consuming and prone to human errors due to the need to verify responses for each command or frame packet.
Let us see the manual method of reading DID to know if a feature is enabled using Busmaster tool. To begin with, the tester has to establish a diagnostic session control (Default Session). The typical packet to be sent via BusMaster tool is captured below.
UDS Manual Default Session Configuration
Now to request the Data ID corresponding to the required information can be sent as below:
UDS Manual DID Read
Up on analyzing the response, the status can be obtained.
Thus, going through each bit/byte of response will be tiresome process and will need a strong understanding of the UDS protocol and DoCAN transport.
UDS Validation based on HiL tools
HiL Testing (Hardware-in-the-Loop testing) enables comprehensive and accurate validation of the hardware and its automotive UDS protocol server implementation in the target ECU. HiL testing in automotive environments does not rely on a specific development project — most automotive diagnostic tools offer intuitive interfaces that enable testers to modify parameters effortlessly. These tools provide a holistic view of the ECU's automotive UDS protocol capabilities and offer the flexibility to enable or disable specific UDS services based on ECU requirements.
In this method, a configuration script is used to generate multiple test scripts to automate automotive UDS protocol testing across multiple environments or projects. Some of the commonly used automotive diagnostic tools for HiL testing in automotive programs include Vector CANoE, LabView, Simulink, and TestBot. This HiL Testing method has become the prevalent approach in the automobile industry today.
Typical Inputs for these automation tools are:
- Open Diagnostic eXchange format (ODX) - an XML-based ASAM standard for describing diagnostically relevant ECU data
- Database file (DBC) – Specification for the IVN communication Process involved in performing automated testing of UDS services usually are:
- Tester shall Import ODX file and configuration file in the Script generator tool
- Script generator generates test specification and test scripts
- Tester shall apply test script on the test environment to test the target ECU board
HIM based UDS Validation Process
However, it's important to note that these professional tools require expertise to operate effectively.
Let us see how the same DID can be read to know if the feature is enabled using CANoE.
Tester needs to load the ODX file and select the session in Diagnostic option as Default.
HiL based UDS Default Session configuration
Tester needs to choose Read Data Identifier and feed the ID, HiL Automation tool will fetch the data and present in a human readable format.
UDS HiL Tool based DID read
As can be seen, without any effort the underlying data can be obtained and understood.
Conclusion
The adoption of automation in automotive UDS protocol testing offers a multitude of benefits that significantly enhance efficiency, accuracy, and overall product quality. By leveraging automotive diagnostic tools and HiL testing in automotive environments, testers can streamline the validation process, reduce manual UDS validation errors, and achieve a faster completion cycle. As the automotive industry continues to evolve with increasingly complex electronic architectures and stringent regulatory requirements, embracing HiL Testing and automated automotive UDS protocol validation emerges as a strategic imperative for automotive manufacturers aiming to deliver superior, reliable, and compliant vehicles to the market.