Test method and device based on DDS communication, test equipment and storage medium

Abstract

The application relates to the technical field of vehicle terminal software debugging, in particular to a test method and device based on DDS communication, test equipment and a storage medium, wherein the method comprises the following steps: obtaining a test request of a tested device; running a test script according to the test request, starting a simulation client or a simulation server by using the test script, calling a data distribution service (DDS) by using the simulation client or the simulation server to communicate with the tested device, and simulating the calling of a target service function on the tested device; if it is detected that an execution result of the target service function on the tested device meets preset qualified conditions, it is determined that the DDS communication test of the tested device is qualified, otherwise, it is determined that the DDS communication test of the tested device is unqualified. Therefore, the problems of application limitations and the like caused by the fact that, in the related art, a traditional communication test equipment is improved but cannot realize the communication test of cross-domain equipment based on the DDS communication are solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle terminal software debugging, and particularly relates to a test method and device based on DDS (Data Distribution Service) communication, test equipment and a storage medium. BACKGROUND

[0002] With the continuous development of Internet of Vehicles technology, SOA (Service-Oriented Architecture) architecture has been gradually applied to Internet of Vehicles. The SOA architecture splits different functional units (referred to as services) of an application program, and connects them through well-defined interfaces and protocols between the services. DDS is a low-latency, high-throughput, high-real-time and decentralized communication middleware. When it is applied to a vehicle terminal, the traditional vehicle terminal communication architecture is gradually replaced.

[0003] In the related art, CAN (Controller Area Network) communication has perfect test equipment, such as canoe, kvaser, USBcan and the like. However, test equipment based on DDS Ethernet communication has not been specifically implemented at present. General interface test tools can be used to customize DDS testing, but secondary development is required, which increases the cost of secondary development and makes the development duration uncontrollable. SUMMARY

[0004] The present application provides a test method and device based on DDS communication, test equipment and a storage medium to solve the problem that the traditional communication test equipment is perfect in the related art, but the communication test of cross-domain equipment based on DDS communication has not been implemented, resulting in application limitations and other problems.

[0005] The first aspect of the present application provides a test method based on DDS communication. The method is applied to test equipment, and includes the following steps: obtaining a test request of a device under test; running a test script according to the test request, starting a simulation client or a simulation server using the test script, and using the simulation client or the simulation server to call a data distribution service (DDS) to communicate with the device under test to simulate the calling of a target service function on the device under test; if it is detected that the execution result of the target service function on the device under test meets a preset qualified condition, it is determined that the DDS communication test of the device under test is qualified, otherwise it is determined that the DDS communication test of the device under test is unqualified.

[0006] According to the technical means, the test script is run according to the test request of the device under test, the simulation client or the simulation server is started, the communication between the data distribution service (DDS) and the device under test is mobilized through the simulation client or the server, the service function on the device under test is simulated and called, and the execution result of the related service function is detected to determine whether it is qualified. When the qualified condition is met, it is determined that the communication test is qualified, otherwise, it is determined that the communication test is not qualified. In the case that there is no DDS test tool, the source code is automatically compiled through the PC (Personal Computer) scripting method to simulate the DDS service of the device under test to realize the DDS data interaction, the development cost is low, and the application is more extensive.

[0007] Optionally, before running the test script according to the test request, the method further includes: obtaining service interface information related to the DDS service in the device under test; generating a service interface file and source code according to the service interface information, and compiling the service interface file and the source code into an executable file of the simulation client or the simulation server; and generating the test script based on the executable file.

[0008] According to the technical means, the service interface information related to the DDS service in the device under test is obtained, the service interface file and the source code are generated according to the related information, the executable file of the simulation client and the simulation server is compiled according to the service interface file and the source code, and the test script is generated based on the executable file. The purpose of simulating the DDS service of the device under test to realize the DDS data interaction is achieved through the script test, and the work efficiency is improved.

[0009] Optionally, in the process of simulating the target service function on the device under test, the method further includes: using a preset grabbing tool to grab a test message, and generating a message file according to the test message; when it is determined that the DDS communication test of the device under test is not qualified, the message file is offline parsed to obtain the test message, and the actual problem of unqualification is determined based on the test message, wherein the actual problem includes a service parameter error problem in the DDS communication process or a service function failure problem of the device under test.

[0010] According to the technical means, the test message is grabbed by using the grabbing tool and the message file is generated, when it is determined that the DDS communication test of the device under test is not qualified, the message file is offline parsed to obtain the test message, and the actual problem of unqualification is determined based on the test message. The message is offline parsed through the idl (Interactive Data Language) file of the corresponding service to realize the playback of the inter-domain data interaction, the problems are understood, the related problems are processed in the subsequent process, and the work efficiency is improved.

[0011] Optionally, before the test request of the device under test is acquired, the method further comprises: connecting the test device and the device under test through an Ethernet; detecting an IP address of the device under test; modifying the IP address of the test device and the IP address of a DDS configuration file in the test device based on the IP address of the device under test.

[0012] According to the technical means described above, the test device and the device under test are connected through an Ethernet, and the IP address of the device under test is detected. The IP address of the test device is modified based on the IP address of the device under test, and the IP address of a DDS configuration file in the test device is modified at the same time. The IP addresses of the configuration file, the test device and the device under test are ensured to be the same, the communication test is ensured to be smooth in the same local area network, and the communication test is ensured to be smooth.

[0013] The second aspect of the application provides a test device based on DDS communication, comprising: an acquisition module configured to acquire a test request of a device under test; an analog calling module configured to run a test script according to the test request, start an analog client or an analog server by using the test script, and call a data distribution service (DDS) to communicate with the device under test by using the analog client or the analog server, so as to simulate calling a target service function on the device under test; and a judgment module configured to determine that the DDS communication test of the device under test is qualified if it is detected that an execution result of the target service function on the device under test meets a preset qualified condition, and otherwise determine that the DDS communication test of the device under test is unqualified.

[0014] Optionally, the analog calling module is further configured to: acquire service interface information related to a DDS service in the device under test; generate a service interface file and source code according to the service interface information, and compile the service interface file and the source code into an executable file of the analog client or the analog server; and generate the test script based on the executable file.

[0015] Optionally, the analog calling module is further configured to: acquire service interface information related to a DDS service in the device under test; generate a service interface file and source code according to the service interface information, and compile the service interface file and the source code into an executable file of the analog client or the analog server; and generate the test script based on the executable file.

[0016] Optionally, the obtaining module is further configured to: connect the test device and the device under test through an Ethernet; detect an IP address of the device under test; modify the IP address of the test device based on the IP address of the device under test; and modify an IP address of a DDS configuration file in the test device.

[0017] The third aspect of the present application provides a vehicle, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the DDS communication based test method according to the above embodiments.

[0018] The fourth aspect of the present application provides a computer readable storage medium, which stores a computer program executable by a processor to implement the DDS communication based test method according to the above embodiments.

[0019] Therefore, the present application has at least the following beneficial effects:

[0020] (1) The embodiments of the present application run the test script by the test request of the device under test, start the simulation client or the simulation server, and communicate between the DDS and the device under test through the simulation client or the server, so as to simulate the service function on the device under test, and then detect the execution result of the related service function to determine whether it is qualified. When the qualified condition is met, it is determined that the communication test is qualified, otherwise it is determined that the communication test is not qualified. In the case that there is no DDS test tool at present, the source code is automatically compiled through the PC scripting method, the DDS service of the device under test is simulated to realize the DDS data interaction, the development cost is low, and the application is more widely used.

[0021] (2) The embodiments of the present application obtain the service interface information related to the DDS service in the device under test, generate the service interface file and the source code according to the related information, compile the executable files of the simulation client and the simulation server according to the source code, generate the test script based on the executable files, and simulate the DDS service of the device under test to realize the DDS data interaction through the script test, thereby improving the work efficiency.

[0022] (3) The embodiments of the present application use the grabbing tool to grab the test message and generate the message file. When it is determined that the DDS communication test of the device under test is not qualified, the test message is obtained by offline parsing the message file, the actual problem of the unqualified test is determined based on the test message, the message is parsed offline through the idl (Interactive Data Language) file of the corresponding service to realize the playback of the inter-domain data interaction, the existing problems are understood, the subsequent processing of the related problems is facilitated, and the work efficiency is improved.

[0023] (4) The embodiment of the present application tests the test equipment and the device under test through Ethernet connection, detects the IP address of the device under test, modifies the IP address of the test equipment and the IP address of the DDS configuration file based on the IP address, ensures that the IP addresses of the configuration file, the test equipment and the device under test are the same, guarantees the smoothness of communication test in the same local area network.

[0024] Additional aspects and advantages of the present application will be made apparent by the following description and the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0025] The above and / or additional aspects and advantages of the present application will become apparent and be more readily understood through consideration of the following description, taken in conjunction with the accompanying drawings, in which:

[0026] Figure 1 A flow chart of a test method based on DDS communication provided according to an embodiment of the present application;

[0027] Figure 2 An overall service flow chart provided according to an embodiment of the present application;

[0028] Figure 3 A network diagram of a rack provided according to an embodiment of the present application;

[0029] Figure 4 An example diagram of DDS service simulation provided according to an embodiment of the present application;

[0030] Figure 5 An example diagram of a test device based on DDS communication according to an embodiment of the present application;

[0031] Figure 6 A structural schematic diagram of a vehicle according to an embodiment of the present application. DETAILED DESCRIPTION

[0032] The embodiments of the present application are described in detail below with reference to the accompanying drawings, in which the same or similar components have the same or similar designations and functions throughout. The embodiments described below are exemplary, and are intended to explain the present application, and are not to be understood as limiting the present application.

[0033] DDS is a low-latency, high-throughput, high real-time, decentralized communication middleware, and is applied at the vehicle end, so that the traditional vehicle end communication architecture is gradually replaced, and at the same time, the following problems are brought to the current test:

[0034] (1) At present, traditional CAN communication has complete testing equipment, such as CANoe, Kvaser, USBcan, etc., but testing equipment based on DDS Ethernet communication is still a blank at present.

[0035] (2) How to test the communication of cross-domain devices based on DDS communication for the whole vehicle, such as: how to mock the DDS service of the device under test when the device under test is missing; how to capture and parse packets when a bug occurs in the cross-domain device communication test.

[0036] (3) How to build a test bench for DDS communication based on SOA architecture.

[0037] To address the aforementioned issues, the testing tools in related technologies support Ethernet TCP, UDP, RS232 / 422 / 485, DDS, AD / DA, and CAN bus, and provide functions such as test case generation, test process control, test environment initialization, test flow management, test data analysis, test simulation model development, and message configuration management. However, these related technologies still have the following drawbacks:

[0038] (1) The tool mainly introduces its own functions and mentions support for DDS for Ethernet, but does not describe the specific implementation method.

[0039] (2) The tool supports customized DDS testing, but requires secondary development, which increases the cost of secondary development and the development time is uncontrollable.

[0040] (3) This tool is a combination of hardware and software and is suitable for laboratory-related scenarios, but not for development, debugging and real vehicle testing scenarios.

[0041] The following description, with reference to the accompanying drawings, describes a testing method, apparatus, testing equipment, and storage medium based on DDS communication according to embodiments of this application.

[0042] Specifically, Figure 1 This is a flowchart illustrating a testing method based on DDS communication provided in an embodiment of this application.

[0043] like Figure 1 As shown, this DDS communication-based testing method, applied to a test device, includes the following steps:

[0044] In step S101, the test request of the device under test is obtained.

[0045] It is understood that the embodiments of this application obtain the test request of the device under test in order to prepare for subsequent testing of the device.

[0046] In the embodiment of the present application, before the test request of the device under test is acquired, the device under test is connected with the test device through Ethernet, and the IP address of the device under test is detected; and the IP address of the test device is modified based on the IP address, and the IP address of the DDS configuration file in the test device is modified at the same time.

[0047] It can be understood that, in the embodiment of the present application, the test device and the device under test are connected through Ethernet, and the IP address of the device under test is detected; and the IP address of the test device is modified based on the IP address, and the IP address of the DDS configuration file in the test device is modified at the same time, so as to ensure that the IP addresses of the configuration file, the test device and the device under test are the same, and ensure that the communication test is smooth in the same local area network.

[0048] In step S102, the test script is run according to the test request, the simulation client or the simulation server is started by using the test script, the data distribution service DDS is called by using the simulation client or the simulation server to communicate with the device under test, so as to simulate the calling of the target service function on the device under test.

[0049] It can be understood that, in the embodiment of the present application, the test script is run according to the test request, the simulation client or the simulation server is started by using the test script, and the data distribution service DDS is called by using the simulation client or the simulation server to communicate with the device under test, so as to simulate the calling of the target service function on the device under test, and to prepare for the subsequent detection of whether the communication is qualified through the service function.

[0050] In the embodiment of the present application, before the test script is run according to the test request, the service interface information related to the DDS service in the device under test is acquired; the service interface file and the source code are generated according to the service interface information, and the executable file of the simulation client or the simulation server is compiled according to the service interface file and the source code; and the test script is generated based on the executable file.

[0051] It can be understood that, in the embodiment of the present application, the service interface information related to the DDS service in the device under test is acquired, the service interface file and the source code are generated according to the related information, and the executable file of the simulation client and the simulation server is compiled according to the related information, and the test script is generated based on the executable file, so as to achieve the purpose of simulating the DDS service of the device under test to realize the DDS data interaction by using the script test, and to improve the work efficiency.

[0052] In the embodiment of the present application, in the process of simulating the calling of the target service function on the device under test, the test message is captured by using a preset capture tool, and the message file is generated according to the test message; when it is determined that the DDS communication test of the device under test is unqualified, the test message is obtained by offline analyzing the message file, and the actual problem of unqualification is determined based on the test message.

[0053] Among these, practical problems include service parameter transmission errors during DDS communication or service function failures of the controlled device under test.

[0054] The default capture tool can be Wireshark or tcpdump, etc., and can be set according to the actual situation. No specific limitation is made here.

[0055] It is understood that the embodiments of this application utilize a capture tool to capture test messages and generate message files. When the DDS communication test of the device under test is determined to be unqualified, the message file is parsed offline to obtain test messages. Based on the test messages, the actual problems of the unqualified devices are determined. The messages are parsed offline through the corresponding service's IDL (Interactive Data Language) file to realize the playback of inter-domain data interaction, understand the problems, facilitate subsequent processing of related problems, and improve work efficiency.

[0056] In step S103, if the execution result of the target service function on the device under test meets the preset qualification conditions, the DDS communication test of the device under test is deemed qualified; otherwise, the DDS communication test of the device under test is deemed unqualified.

[0057] The preset qualification condition can be that the target service function on the device under test is executed correctly, without any specific limitation.

[0058] It is understood that the embodiments of this application detect and determine whether the execution results of related service functions are qualified. When the qualification conditions are met, the communication test is deemed qualified; otherwise, it is deemed unqualified. This solves the problem of the lack of DDS testing tools at present. By automatically compiling the source code through PC-side scripting, the DDS service of the device under test can be simulated to achieve DDS data interaction. The development cost is low, making the application more widely applicable.

[0059] The DDS-based testing method proposed in this application involves running a test script based on the test request of the device under test (DUT). This script launches a simulated client or server, which then initiates communication between the DDS data distribution service and the DUT to simulate the invocation of service functions on the DUT. The execution results of these service functions are then evaluated for compliance. If the compliance conditions are met, the communication test is deemed successful; otherwise, it is deemed unsuccessful. This method addresses the current lack of DDS testing tools by automatically compiling source code via a PC-based scripting approach to simulate DDS services and achieve DDS data interaction on the DUT. This approach has lower development costs and wider applicability. Furthermore, it solves the problem in related technologies where traditional communication testing equipment is comprehensive but lacks DDS-based cross-domain device communication testing capabilities, thus limiting its application.

[0060] The following will combine Figure 2 This application describes a testing method based on DDS communication. The embodiments of this application involve the following modules: a DDS development toolchain backend, scripts for automatically compiling source code and parsing Wireshark packets, an MPU controller and application, and a Windows system computer (host computer). Specifically:

[0061] 1. The DDS development toolchain platform mainly provides the ability to define DDS service interface information (including service name, method name, method type, parameter name, parameter data type, etc.), generate corresponding IDL files and source code, and provide IDL and source code download functions.

[0062] 2. The automatic source code compilation script compiles the source code downloaded from the DDS development toolchain platform into a Windows client or server executable file with dynamically specified parameters, and enables the client or server to call DDS services via command line. The specific implementation mainly involves the following steps:

[0063] (1) Based on the service name, client or server selected by the user, find the corresponding .hpp and .cpp files, read their contents, and create the main function of the client or server according to C++ syntax (Note: get_instance().init() specifies the cyclonedds.xml configuration file);

[0064] (2) Modify the interface network address in cyclonedds.xml using the IP address specified by the user to ensure that the network of the client or server is on the same local area network as the controller under test;

[0065] (3) Compile the source code. After compilation, call the Windows cmd window to enable the exe file and realize the publishing and subscription of DDS data.

[0066] 3. The script for parsing Wireshark packets mainly reads the packet data from the .pcapng file and parses the data values ​​defined in the IDL according to the DDS packet format and the contents of the IDL. This script will use the DDS DLL library.

[0067] 4. The MPU controller and application module are our test objects. They mainly integrate DDS service-related code and application logic. Here we need to obtain DDS service-related documentation, controller network information, and auxiliary components to ensure the controller's Ethernet connection.

[0068] 5. Windows computers mainly act as host computers. We need to install a C++ compilation environment (install CMake and MinGW tools and configure environment variables), a Python environment, and the Wireshark packet capture tool on Windows. The computer also needs to have the ability to connect to Ethernet.

[0069] Taking a specific scenario as an example, the setup of the test bench mainly ensures that the device under test and the simulation device are on the same local area network (LAN) through switches and network cables. Then, by modifying the configuration file, it is ensured that all DDS communication uses the same LAN. The overall logic is as follows: Figure 3 As shown, the specific setup method is as follows:

[0070] 1. Connect the controller, switch, and computer under test using a network cable;

[0071] 2. Check the IP of the controller of the object under test. You can connect to the controller via serial port using the MobaXterm_Personal tool or the xshell tool, enter ifconfig to view the set IP, find the DDS configuration file, and confirm that the IP in the configuration file is the same as the controller's IP.

[0072] 3. Open the computer's network settings interface. On the TCP / IPv4 settings page, click "Advanced" to enter the IP settings interface. Add an IP address that is on the same network segment as the controller under test, and then save. Reopen the cmd command prompt window and use the ping ip command to ensure that the computer's network and the controller's network are on the same local area network.

[0073] To implement DDS service calls and offline parsing of DDS messages, a script needs to be written in advance. This requires obtaining the relevant documentation for the DDS service of the controller under test application, and combining it with... Figure 4 The specific testing procedures are described in detail below:

[0074] 1. Test data preparation: Based on the DDS service documentation for the application of the controller under test, log in to the DDS development toolchain platform to create the corresponding service and download the source code;

[0075] 2. DDS runs a test script on the PC. The execution format is compiler.py IP client / server service name_method name(parameters) method. compiler.py is the script executable file that automatically compiles the DDS service. IP is the IP set on the PC during the bench setup, i.e., the IP set in the DDS communication configuration file. client / server specifies whether to generate the client or server. service name_method name(parameters) is the name of the service to be called + underscore + method name, and the parameters passed to the method are in parentheses. method is the communication method used by the method, such as rpc or notify. After the script is started, it will run the service immediately and print the service running log and the passed parameter values ​​in real time in the cmd command line.

[0076] 3. Check the logs of the cmd client manually to confirm that the DDS service of the PC and the service of the control application under test have been successfully connected, and check whether the function of the service being called on the application on the controller is being executed correctly.

[0077] After the testing process is completed, problems need to be investigated by offline replaying of the packets. Because the DDS service uses Ethernet, real-time packets can be captured using tools such as Wireshark or tcpdump. If problems occur during the test, the location of the problem can be identified by offline parsing of the packets, which will facilitate subsequent troubleshooting. The specific steps are as follows:

[0078] 1. Install the open-source packet capture tool Wireshark on the PC (tcpdump can be used on the controller under test depending on the actual situation) to capture packets and save them to the specified file directory;

[0079] 2. Log in to the DDS development toolchain platform and download the IDL file of the DDS service to be parsed;

[0080] 3. Run the parsing script. The specific format is analysis.py.pcapng idl parsed file (default is the current path). Note that analysis.py is the Python DDS offline parsing script; .pcapng is the packet file captured by the packet capture tool; idl is the IDL of the DDS service to be parsed; and the parsed file is the directory where the parsed data is stored.

[0081] 4. After parsing the file, we can view the specific parameter values ​​using Notepad++ to determine whether the problem lies with the service parameter passing or the functionality of the controller application under test.

[0082] In summary, the source code is automatically compiled via PC-based scripting to simulate the DDS service of the device under test and achieve DDS data interaction; and the message is parsed offline through the corresponding service's IDL file to replay the data interaction between domains.

[0083] Next, referring to the accompanying drawings, a test apparatus based on DDS communication proposed according to an embodiment of this application is described.

[0084] Figure 5 This is a block diagram of a DDS communication-based testing device according to an embodiment of this application.

[0085] like Figure 5 As shown, the DDS communication-based test device 10 includes: an acquisition module 100, a simulation call module 200, and a judgment module 300.

[0086] The acquisition module 100 is used to acquire the test request of the device under test; the simulation call module 200 is used to run the test script according to the test request, start the simulation client or simulation server using the test script, and use the simulation client or simulation server to call the Data Distribution Service (DDS) to communicate with the device under test, so as to simulate the call of the target service function on the device under test; the judgment module 300 is used to determine that the DDS communication test of the device under test is qualified if the execution result of the target service function on the device under test meets the preset qualification conditions, otherwise it determines that the DDS communication test of the device under test is unqualified.

[0087] In this embodiment of the application, the acquisition module 100 is further configured to: connect the test device and the device under test via Ethernet; detect the IP address of the device under test; modify the IP address of the test device based on the IP address, and at the same time modify the IP address of the DDS configuration file in the test device.

[0088] In this embodiment, the simulated call module 200 is further configured to: obtain service interface information related to the DDS service in the device under test; generate service interface files and source code based on the service interface information, and compile them into an executable file of a simulated client or simulated server based on the service interface files and source code; and generate test scripts based on the executable files.

[0089] In this embodiment of the application, the simulation call module 200 is further configured to: capture test messages using a preset capture tool, generate a message file based on the test messages; when the DDS communication test of the device under test is determined to be unqualified, perform offline parsing of the message file to obtain test messages, and determine the actual problem of the unqualified based on the test messages, wherein the actual problem includes service parameter transmission error problem in the DDS communication process or service function failure problem of the control device under test.

[0090] It should be noted that the foregoing explanation of the DDS communication-based test method embodiment also applies to the DDS communication-based test device of this embodiment, and will not be repeated here.

[0091] The DDS-based testing device proposed in this application runs a test script based on the test request of the device under test (DUT). It then launches a simulated client or server and initiates communication between the DDS data distribution service and the DUT to simulate the invocation of service functions on the DUT. The execution results of these service functions are then checked and judged for compliance. If the compliance conditions are met, the communication test is deemed successful; otherwise, it is deemed unsuccessful. This addresses the current lack of DDS testing tools by automatically compiling source code via a PC-based scripting approach to simulate DDS services and achieve DDS data interaction on the DUT. This approach has lower development costs and wider applicability. Therefore, it solves the problem that traditional communication testing devices, while comprehensive, lack cross-domain communication testing capabilities based on DDS, thus limiting their application.

[0092] Figure 6 A schematic diagram of the structure of a testing device provided in an embodiment of this application. The testing device may include:

[0093] The memory 601, the processor 602, and the computer program stored on the memory 601 and capable of running on the processor 602.

[0094] When the processor 602 executes the program, it implements the DDS communication-based test method provided in the above embodiments.

[0095] Furthermore, the testing equipment also includes:

[0096] Communication interface 603 is used for communication between memory 601 and processor 602.

[0097] The memory 601 is used to store computer programs that can run on the processor 602.

[0098] The memory 601 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0099] If the memory 601, processor 602, and communication interface 603 are implemented independently, then the communication interface 603, memory 601, and processor 602 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0100] Optionally, in a specific implementation, if the memory 601, processor 602, and communication interface 603 are integrated on a single chip, then the memory 601, processor 602, and communication interface 603 can communicate with each other through an internal interface.

[0101] The processor 602 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0102] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described DDS communication-based testing method.

[0103] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0104] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0105] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0106] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0107] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium. When executed, the program includes one or a combination of the steps of the method embodiments.

[0108] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A testing method based on DDS communication, characterized in that, The method is applied to a testing device, and the method includes the following steps: Connect the device under test and the analog device to the same local area network by using a switch and network cable, and make all DDS communication use the same local area network by modifying the configuration file. Obtain the test request from the device under test; Run the test script according to the test request, start the simulation client or simulation server using the test script, and use the simulation client or simulation server to call the Data Distribution Service (DDS) to communicate with the device under test in order to simulate calling the target service function on the device under test. The test script is generated as follows: Source code is downloaded from the DDS development toolchain backend; the corresponding .hpp and .cpp files are located and their contents are read according to the user-selected service name, client, or server, and a main function for the client or server is created according to C++ syntax; the interface network address in cyclonedds.xml is modified using the user-specified IP address to ensure that the client or server's network is on the same local area network as the controller under test; the source code is compiled, and after compilation, the .exe file is launched via the Windows command prompt window to implement DDS data publishing and subscription. If the execution result of the target service function on the device under test meets the preset qualification conditions, the DDS communication test of the device under test is deemed qualified; otherwise, the DDS communication test of the device under test is deemed unqualified. When the DDS communication test of the device under test is determined to be unqualified, the script for parsing Wireshark packets reads the message data of the .pcapng file and parses the data values ​​defined in the IDL according to the DDS message format and the content in the IDL. The test script uses the DDS DLL library to parse the message offline through the IDL file of the corresponding service to realize the playback of inter-domain data interaction and locate the problems.

2. The method according to claim 1, characterized in that, Before running the test script according to the test request, the following is also included: Obtain the service interface information related to DDS service in the device under test; Based on the service interface information, a service interface file and source code are generated, and the service interface file and source code are compiled into an executable file for the simulated client or simulated server. The test script is generated based on the executable file.

3. The method according to claim 1, characterized in that, The process of simulating the invocation of the target service function on the device under test also includes: Use a preset capture tool to capture test packets, and generate a packet file based on the test packets; When the DDS communication test of the device under test is determined to be unqualified, the message file is parsed offline to obtain the test message, and the actual problem of the unqualified is determined based on the test message. The actual problem includes service parameter transmission error in the DDS communication process or service function failure of the control device under test.

4. The method according to claim 1, characterized in that, Before obtaining the test request from the device under test, the following steps are also included: The test equipment and the device under test are connected via Ethernet; The IP address of the device under test is detected, and the IP address of the test device is modified based on the IP address. At the same time, the IP address of the DDS configuration file in the test device is also modified.

5. A DDS communication-based test apparatus for performing the method as described in any one of claims 1-4, characterized in that, The device is used in testing equipment and includes: The acquisition module is used to acquire test requests from the device under test. The simulation call module is used to run a test script according to the test request, start a simulation client or simulation server using the test script, and use the simulation client or simulation server to call the Data Distribution Service (DDS) to communicate with the device under test in order to simulate calling the target service function on the device under test. The determination module is used to determine that the DDS communication test of the device under test is qualified if the execution result of the target service function on the device under test meets the preset qualification conditions; otherwise, it determines that the DDS communication test of the device under test is unqualified.

6. The apparatus according to claim 5, characterized in that, The simulated call module is further used for: Obtain the service interface information related to DDS service in the device under test; Based on the service interface information, a service interface file and source code are generated, and the service interface file and source code are compiled into an executable file for the simulated client or simulated server. The test script is generated based on the executable file.

7. The apparatus according to claim 5, characterized in that, The simulated call module is further used for: Use a preset capture tool to capture test packets, and generate a packet file based on the test packets; When the DDS communication test of the device under test is determined to be unqualified, the message file is parsed offline to obtain the test message, and the actual problem of the unqualified is determined based on the test message. The actual problem includes service parameter transmission error in the DDS communication process or service function failure of the control device under test.

8. The apparatus according to claim 5, characterized in that, The acquisition module is further used for: The test equipment and the device under test are connected via Ethernet; The IP address of the device under test is detected, and the IP address of the test device is modified based on the IP address. At the same time, the IP address of the DDS configuration file in the test device is also modified.

9. A testing device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the DDS communication-based test method as described in any one of claims 1-4.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the DDS communication-based test method as described in any one of claims 1-4.

Images