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, UDS serves as the universal language adopted by automotive OEMs to establish a common computer system capable of diagnosing any vehicle. However, navigating the complexities of UDS and validating the 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, few approaches are employed to conduct UDS testing, ranging from manual testing procedures to the development of custom test applications and utilization of automation testing tools.
UDS Services Test cases
Before delving into the different approaches and determining the optimal method for testing, it's crucial to first grasp the various test scenarios associated with each of Unified Diagnostics Services (UDS). Understanding the fundamentals of UDS is essential for laying a strong foundation in this domain. For a comprehensive overview of the basics of UDS, refer to the article titled 'Introduction to Automotive UDS Protocol'. This resource will provide valuable insights into the core principles and functionalities of UDS, setting the stage for a deeper exploration of testing methodologies and best practices in the coming sections.
While testing UDS features, it's 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 a lot of diagnostic services offered by a typical ECU. Beyond these, based on the feature list of the ECU, the quantum of functionalities under many of these services will vary between a few scores to few hundreds. Thus, testing of the UDS diagnostic implementation in an ECU could well 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 function testing involves a manual approach where testers follow test specifications and frame packets and transmit diagnostic messages individually. Testers then analyze response messages to ensure data correctness. Popular CAN bus communication tools like Peak CAN analyzer, WaveShare, or Vector can be used to perform these operations along with the associated software. While straightforward, this method is inefficient and primarily suitable for simple initial testing or for developers. Further 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
Utilizing Automation tools enable users to conduct comprehensive and accurate testing of the hardware and its UDS server implementation in the target ECU. This approach does not rely on a specific development project or test environment. Most of the tools offer intuitive interfaces that enable testers to modify parameters effortlessly. These tools provide a holistic view of the ECU's capabilities and offer the flexibility to enable or disable specific UDS services based on the ECU requirements.
In this method a configuration script is used to generate multiple test scripts to automate the testing for multiple environments or projects via automation tools. Some of the commonly used tools include such as Vector CANoE, LabView, Simulink, TestBot etc. This method has become prevalent 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 testing offers a multitude of benefits that significantly enhance efficiency, accuracy, and overall product quality. By leveraging automated testing frameworks, testers can streamline the testing process, reduce manual errors, and achieve a faster completion cycle. As the automotive industry continues to evolve with increasingly complex electronic architectures and stringent regulatory requirements, embracing automation in UDS testing emerges not only as a necessity but also as a strategic imperative for automotive manufacturers aiming to deliver superior, reliable, and compliant vehicles to the market.