Introduction

Currently, vehicle diagnostics primarily use the UDS (Unified Diagnostic Services) diagnostic protocol, which allows retrieving the status information of a vehicle's ECU and performing data flashing. However, with the increasing complexity of automotive architectures, the explosion of data, and the rise of remote diagnostics, traditional diagnostic methods are no longer sufficient to address these complexities and rapid changes. Thus, the Service-Oriented Vehicle Diagnostics (SOVD) protocol was initiated by ASAM in 2019. Through standardized diagnostic services and interfaces, it aims to improve diagnostic efficiency, flexibility, and accuracy, meeting the demands for remote diagnostics, near-end diagnostics, and in-vehicle diagnostics.

Why is SOVD Needed?

- Efficient Data Transmission: The amount of data generated by vehicles is increasing, covering everything from vehicle status to driving habits. A more powerful protocol is needed to handle and analyze this data. SOVD achieves high-speed data transmission, significantly improving diagnostic efficiency and response speed.

- Remote Needs: With the development of connected car technology, the demand for remote diagnostics and services has gradually increased.

- Flexibility: SOVD allows services to be dynamically defined and invoked at runtime, rather than relying on static API descriptions, meeting the diagnostic and service needs of different vehicles and scenarios.

- Standardization: SOVD provides a standardized diagnostic framework and unified diagnostic interface, enabling interoperability between systems from different OEMs and suppliers, reducing compatibility issues caused by proprietary protocols.

- Cross-Platform Compatibility: Supports different hardware and software platforms, ensuring seamless communication between various devices and systems.

Figure 1: The Evolution of Automotive Diagnostics

2. SOVD – Service-Oriented Dynamic Diagnostics

Compared to traditional diagnostic protocols, SOVD adopts service-oriented dynamic diagnostic features:

- Service Independence: In the SOVD protocol, diagnostic functions are broken down into independent service modules. For example, engine diagnostics, brake system diagnostics, and battery management diagnostics are all independent services. These services run independently without relying on each other, ensuring system flexibility and stability.

- Loose Coupling: Services communicate via standardized interfaces rather than directly invoking each other. This means changes in one service do not directly affect others. This loose coupling design makes the system easier to maintain and expand.

- Service Reusability: A diagnostic service can be reused in different vehicles and systems. For example, a standardized engine diagnostic service can be applied to various vehicle models without developing it separately for each model. This reusability improves development efficiency and reduces costs.

- Service Discovery Mechanism: Diagnostic services can be dynamically discovered when needed, rather than being pre-bound to specific service implementations. This means vehicle systems can discover and invoke the most appropriate diagnostic services based on current needs at runtime.

- On-Demand Service Invocation: The SOVD protocol supports on-demand invocation of diagnostic services, rather than loading all potential services during system startup. This on-demand invocation ensures efficient use of system resources and service flexibility. When a vehicle component needs diagnostics, the system sends a request to invoke the relevant diagnostic service. After diagnostics are complete, the service can release resources and wait for the next invocation.

- Real-Time Response and Data Processing: Dynamic diagnostics require the system to respond to diagnostic requests in real time and process and transmit diagnostic data. This real-time capability is crucial for ensuring vehicle safety and performance. Efficient communication protocols (such as HTTP and MQTT) and optimized service implementations ensure that diagnostic requests are quickly responded to, and diagnostic results are transmitted in real time.

- Adaptive Capability: The dynamic diagnostic features of the SOVD protocol allow the system to adjust diagnostic strategies and services based on real-world conditions. For example, under different driving conditions or vehicle states, the system can adaptively choose appropriate diagnostic services and strategies.

SOVD Protocol Architecture

Figure 2: SOVD Protocol Architecture Diagram

The SOVD protocol supports three diagnostic scenarios:

1. Remote Diagnostics: Allows technicians or service systems to remotely access vehicle data and control systems through mobile broadband networks without needing to physically interact with the vehicle.

2. Near-End Diagnostics: When technicians are near the vehicle, they can connect to the vehicle’s SOVD server via wired or wireless connections for diagnostic operations.

3. In-Vehicle Diagnostics: Diagnostic tasks within the vehicle can run independently of external servers or near-field testers, such as vehicle health monitoring and predictive maintenance.

The SOVD protocol on the vehicle side consists of four main components: SOVD Gateway, SOVD2UDS Adapter, SOVD Library, and Diagnostic Manager (AUTOSAR AP):

- SOVD Gateway: The SOVD edge node responsible for receiving SOVD requests, using mDNS for device discovery and connection, and distributing them to the correct terminals. Each vehicle has only one of these components.

- SOVD2UDS Adapter: Converts diagnostic requests and data based on the SOVD protocol into a format compliant with the UDS protocol and vice versa. This component natively supports DoIP and can extend custom TP. Each vehicle has only one of these components.

- Diagnostic Manager (AUTOSAR AP): The local SOVD server for AUTOSAR AP applications within the vehicle. It implements SOVD functions through the ara::diag (C++) interface. The number of this component depends on the number of ECUs/systems.

- SOVD Library: For applications without a complete AUTOSAR environment, this component can be used to implement SOVD functions. The number of this component also depends on the number of ECUs/systems.

SOVD Testing Solution

After in-depth understanding and analysis of the SOVD protocol, Polelink has introduced system-level and vehicle-level automated SOVD testing solutions. Below is an overview of the SOVD testing solution’s overall composition.

Based on the characteristics of the SOVD protocol, the following testing scenarios were identified:

1. SOVD API Testing: Verifies all API interfaces of the vehicle’s SOVD system.

   - Uses HTTP commands to invoke the vehicle-side SOVD interface and verifies protocol consistency.

   - Uses HTTP commands to invoke the vehicle-side SOVD interface and checks whether the SOVD2UDS adapter behaves as expected.

   - Challenge: Automated invocation of remote diagnostic servers and vehicle-side SOVD interfaces.

   - Solution: Polelink’s custom-developed Test Center software can automate the invocation of remote diagnostic servers and vehicle-side SOVD interfaces.

   - Testing Environment: System-level + vehicle-level.

   - Testing Input: API documentation.

2. SOVD2UDS Testing:

  - Protocol Conversion Testing: Verifies the correctness of converting SOVD diagnostic requests and data to the UDS protocol format.

   - Uses HTTP commands to invoke the vehicle-side SOVD interface and checks whether the SOVD2UDS adapter behaves as expected.

   - Testing Environment: System-level + vehicle-level.

   - Testing Input: API documentation + diagnostic database.

-Reverse Scenario Testing: Verify the correctness of converting SOVD diagnostic requests and data into the UDS protocol format under abnormal ECU conditions.

· Simulate abnormal responses from the UDS protocol controller (negative response or no response), and invoke the vehicle-side SOVD interface through HTTP commands to observe whether the SOVD2UDS adapter behaves as expected.

· Challenges: Simulation of reverse scenarios

· UDS Controller Abnormal Response Simulation: In the system-level SOVD testing bench environment, various types of reverse testing scenarios can be automated, such as bus/power supply hardline fault injection, ECU bus signal no response/negative response, etc.

· Testing Environment: System-level

· Testing Inputs: API documentation + diagnostic database

Given the aforementioned content of SOVD automated testing, after an in-depth analysis of the SOVD protocol, Polelink has introduced a general system-level and vehicle-level SOVD automated testing solution. Based on this, we offer customized development for different clients, enabling system-level and vehicle-level automated SOVD testing. Below is an introduction to the overall structure of the SOVD automated testing system.

On the hardware level, the SOVD automated testing solution can be divided into two forms: system-level testing system and vehicle-level testing system, tailored to different clients' testing needs.

The system-level SOVD testing system consists of a testing cabinet and a testing bench. The testing bench integrates SOVD-related controllers and programmable BOB (Breakout Box) equipment. Using the custom-developed programmable BOB equipment by Polelink, fault injection into the controllers can be realized to conduct reverse testing. The testing cabinet acts as the core tool for executing the solution, monitoring and simulating bus messages via bus simulation and collection interface cards, while the industrial PC configures and executes the testing projects, with the testing interface connecting to the testing bench. The system-level SOVD testing system can complete SOVD API testing, SOVD2UDS protocol conversion testing, and SOVD2UDS reverse testing.

The vehicle-level SOVD testing system consists of a testing chassis and an outdoor power supply. The outdoor power supply provides power to the SOVD testing chassis, mainly configured for fuel vehicles and hybrid vehicles, while for electric vehicles with automatic power replenishment functionality, the vehicle’s 12V battery can be used to power the SOVD testing chassis. The SOVD testing chassis serves as the core tool for executing the solution, monitoring and simulating bus messages via bus simulation and collection interface cards, while the industrial PC configures and executes the testing projects, with the testing interface connecting to the vehicle. The vehicle-level SOVD testing system can complete SOVD API testing and SOVD2UDS protocol conversion testing.

Figure 3: SOVD Testing System Hardware Architecture

On the software level, the SOVD testing solution consists of five major components:

1. Logic Definition Module (PAVELINK.Test Center): Through the custom-developed Test Center by Polelink, it is possible to perform graphical test case editing, test case management, device management, test task scheduling, and test task execution. Additionally, through customized modules, the automated invocation of remote diagnostic servers and vehicle-side SOVD interfaces can be achieved.

2. Logic Forwarding Module (PAVELINK.Test Agent): Through the custom-developed Test Agent by Polelink, logic execution requests sent from the Test Center, including CANoe project calls, can be forwarded. It also controls the automated start and stop of CANoe testing projects.

3. Database Conversion Module (PAVELINK.SOA-Converter): The custom-developed SOA-Converter by Polelink can convert file formats such as OpenAPI and diagnostic databases (ODX and DEXT formats) for use in generating test cases with test case generation tools.

4. Test Case Auto-Generation Tool:

o (i) Through the custom-developed test case auto-generation tool by Polelink, based on the imported database, SOVD test cases can be automatically generated.

o (ii) Through VECTOR’s CANoe.Diva, based on OpenAPI, test cases can be automatically generated, with manual modifications to specific cases, allowing testing of external and internal SOVD API interfaces.

5. Test Execution Software (CANoe): Based on VECTOR's CANoe software, it enables message simulation, power control, signal simulation, and BOB (Breakout Box) control, among other functions.

Figure 4: SOVD Testing System Software Architecture

The SOVD protocol testing process is as follows:

· Pre-conditions for testing:

o Input: API and diagnostic database

· Input format conversion:

o The PAVELINK.SOA-Converter automatically completes the format conversion of the inputs and imports them into the test case auto-generation tool.

· Test case generation:

o System-level SOVD test cases: The test case generator parses the inputs and automatically generates SOVD API test cases, SOVD2UDS protocol conversion test cases, and SOVD2UDS reverse test cases.

o Vehicle-level SOVD test cases: The test case generator parses the inputs and automatically generates SOVD API test cases.

· Test execution and management:

o The test cases are input into the PAVELINK.Test Center. The Test Center, with the help of PAVELINK.Test Agent, automatically invokes CANoe, the remote diagnostic server, and the vehicle-side SOVD interface to execute the tests and generate test reports based on the results.

Conclusion

In the wave of digital transformation in the automotive industry, the introduction of the SOVD (Service-Oriented Vehicle Diagnostics) protocol not only marks a qualitative leap in vehicle diagnostic technology but also represents a profound revolution in automotive safety and intelligence levels.

The testing phase is critical to ensuring the feasibility and stability of the SOVD protocol. Polelink’s SOVD testing solution covers API testing, protocol conversion testing, and reverse scenario testing, ensuring that each diagnostic service executes accurately under various working conditions, thereby ensuring the reliability of vehicle systems and the safety of users.

Polelink’s SOVD testing solution uses advanced automated tools and methods, combined with system-level and vehicle-level testing environments, to comprehensively simulate various possible application scenarios. This comprehensive testing strategy not only improves testing efficiency and coverage but also ensures the maturity and broad applicability of the technology.

The future of the automotive industry is full of infinite possibilities, and the SOVD protocol and its testing solutions will be powerful tools in exploring this future world. Let us move forward together, using testing as a bridge to connect innovation and practice, ensuring that every step of technological advancement is solid and reliable. Thank you for reading, and we look forward to meeting you on the road to automotive technological innovation.