Method and device for building DDS simulation link, storage medium and terminal equipment

Abstract

The application discloses a DDS simulation link building method and device, a storage medium and a terminal device, and applies the DDS simulation link to a single bench test of an intelligent driving domain controller, wherein the DDS simulation link comprises test software and a DDS simulation program, and the method comprises the following steps: configuring a service list based on a target tool chain, wherein the service list comprises a first service list of a server and a second service list of a client in the DDS simulation program; when the service is a server service, determining an interface function and a DDS communication matrix of the corresponding service based on the first service list, and when the service is a client service, determining an interface function and a DDS communication matrix of the corresponding service based on the second service list; determining target service information of each service based on the DDS communication matrix; and realizing DDS data communication between the test software and the measured controller based on the interface function and the target service information. Thus, the problem of simulating DDS data by a test tool can be solved, the test cost is reduced, and the test period is shortened.

Description

Technical Field

[0001] This application relates to the field of simulation link construction technology, and in particular to a method for constructing a DDS simulation link, a computer-readable storage medium, a device for constructing a DDS simulation link, and a terminal device. Background Technology

[0002] In the field of bench testing of intelligent driving domain controllers, setting up a bench test environment for domain controllers requires simulating CAN (Controller Area Network) messages, Ethernet data, and hardwired signals. The Ethernet data uses protocols including DDS (Data Distribution Service) and HTTP (Hypertext Transfer Protocol). For the DDS protocol, each OEM or supplier has its own protocol specification, which is not fully compatible. This results in existing automotive testing tools, such as CANoe, PCAN, and TSMaster, not fully supporting all DDS protocols. Summary of the Invention

[0003] This application aims to at least partially address one of the technical problems in related technologies. To this end, the first objective of this application is to propose a method for constructing a DDS simulation link. This method configures a service list based on a target toolchain. The service list includes a first service list for the server side and a second service list for the client side in the DDS simulation program. When the service is a server-side service, the interface function and DDS communication matrix of the corresponding service are determined based on the first service list. When the service is a client-side service, the interface function and DDS communication matrix of the corresponding service are determined based on the second service list. The target service information for each service is determined based on the DDS communication matrix. DDS data communication between the test software and the controller under test is achieved based on the interface function and target service information. This method solves the problem of simulating DDS data in test tools, reduces testing costs, and shortens the testing cycle.

[0004] The second objective of this application is to provide a computer-readable storage medium.

[0005] The third objective of this application is to propose a device for building a DDS simulation link.

[0006] The fourth objective of this application is to propose a terminal device.

[0007] To achieve the above objectives, a first aspect of this application proposes a method for constructing a DDS simulation link. The DDS simulation link is applied to bench testing of a single intelligent driving domain controller. The DDS simulation link includes test software and a DDS simulation program. The method includes: configuring a service list based on a target toolchain, wherein the service list includes a first service list for the server side and a second service list for the client side in the DDS simulation program; when the service is a server-side service, determining the corresponding service's interface function and DDS communication matrix based on the first service list; when the service is a client-side service, determining the corresponding service's interface function and DDS communication matrix based on the second service list; determining target service information for each service based on the DDS communication matrix; and implementing DDS data communication between the test software and the controller under test based on the interface function and the target service information.

[0008] According to the DDS simulation link construction method of this application embodiment, a service list is configured based on the target toolchain. The service list includes a first service list for the server side and a second service list for the client side in the DDS simulation program. When the service is a server-side service, the interface function and DDS communication matrix of the corresponding service are determined based on the first service list. When the service is a client-side service, the interface function and DDS communication matrix of the corresponding service are determined based on the second service list. The target service information for each service is determined based on the DDS communication matrix. DDS data communication between the test software and the controller under test is realized based on the interface function and the target service information. Therefore, this method can solve the problem of simulating DDS data in the test tool, reduce testing costs, and shorten the testing cycle.

[0009] In addition, the DDS simulation link construction method according to the above embodiments of this application may also have the following additional technical features:

[0010] According to one embodiment of this application, the DDS simulation program communicates with the test software using UDP, or uses ZeroMQ communication middleware to communicate with the test software.

[0011] According to one embodiment of this application, DDS data communication between the test software and the controller under test is implemented based on the interface function and the target service information, including: determining the data information received by the DDS simulation program based on the target service information, wherein the data information includes DDS data sent by the controller under test and test data sent by the test software; when the DDS simulation program receives a service request sent by the controller under test, transmitting the DDS data to the test software based on an interface function generated based on the first service list; when the DDS simulation program receives a service request sent by the test software, transmitting the test data to the controller under test based on an interface function generated based on the second service list.

[0012] According to one embodiment of this application, the method includes: reading the input parameter information and return value information of each interface function in each service, and converting basic data types, enumeration types, and structure types into message types in a Proto file, wherein the Proto file is used to represent the data format for communication between the DDS simulation program and the test software.

[0013] According to one embodiment of this application, the method includes: obtaining DDS communication protocol stack code compatible with the controller under test; and compiling and generating the DDS simulation program based on the DDS communication protocol stack code, the interface functions, the target service information, and the Proto file.

[0014] According to one embodiment of this application, the method includes: configuring the service communication unicast IP address used by the DDS emulation program on the host network card.

[0015] According to one embodiment of this application, the DDS simulation program uses a target XML file to configure DomainID, service discovery multicast IP address, service communication unicast IP address and other configuration items, wherein the configuration item data is consistent with the DDS communication configuration in the controller under test, and wherein the DDS simulation program reads the target XML file when it starts.

[0016] To achieve the above objectives, a second aspect of this application provides a computer-readable storage medium storing a program that, when executed by a processor, implements the above-described method for building a DDS simulation link.

[0017] The computer-readable storage medium according to the embodiments of this application, by implementing the above-described method for building a DDS simulation link during execution, can solve the problem of testing tools simulating DDS data, and reduce testing costs and shorten the testing cycle.

[0018] To achieve the above objectives, a third aspect of this application proposes a device for constructing a DDS simulation link. The DDS simulation link is applied to bench testing of a single intelligent driving domain controller. The DDS simulation link includes test software and a DDS simulation program. The device includes: a configuration module for configuring a service list based on a target toolchain, wherein the service list includes a first service list for the server side and a second service list for the client side in the DDS simulation program; a first determination module for determining the interface function and DDS communication matrix of the corresponding service based on the first service list when the service is a server-side service, and for determining the interface function and DDS communication matrix of the corresponding service based on the second service list when the service is a client-side service; a second determination module for determining the target service information of each service based on the DDS communication matrix; and a communication module for implementing DDS data communication between the test software and the controller under test based on the interface function and the target service information.

[0019] According to the DDS simulation link construction apparatus of this application embodiment, the configuration module is used to configure a service list based on the target toolchain. The service list includes a first service list for the server side and a second service list for the client side in the DDS simulation program. A first determining module is used to determine the interface function and DDS communication matrix of the corresponding service based on the first service list when the service is a server-side service, and to determine the interface function and DDS communication matrix of the corresponding service based on the second service list when the service is a client-side service. A second determining module is used to determine the target service information of each service based on the DDS communication matrix. A communication module is used to realize DDS data communication between the test software and the controller under test based on the interface function and the target service information. Therefore, this apparatus can solve the problem of simulating DDS data in test tools, reduce testing costs, and shorten the testing cycle.

[0020] To achieve the above objectives, a terminal device is proposed in the fourth aspect of this application, including a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described method for building a DDS simulation link.

[0021] According to the terminal device in the embodiments of this application, by executing the above-described method for building a DDS simulation link, the problem of simulating DDS data by the test tool can be solved, and the test cost and test cycle can be reduced.

[0022] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0023] Figure 1This is a flowchart illustrating the method for constructing a DDS simulation link according to an embodiment of this application;

[0024] Figure 2 This is a schematic diagram of the DDS simulation link in an embodiment of this application;

[0025] Figure 3 This is a block diagram illustrating the internal implementation of the DDS simulation link in an embodiment of this application.

[0026] Figure 4 This is a block diagram of a DDS simulation link building device according to an embodiment of this application;

[0027] Figure 5 This is a block diagram of a terminal device according to an embodiment of this application.

[0028] The components are as follows: 1-Host running the test software and DDS simulation program; 2-Ethernet transceiver; 3-USB cable; 4-Network cable with interface type T1; 5-Network cable with interface type TX; 6-Controller under test; 11-Test software; 12-DDS simulation program; 100-DDS simulation link building device; 110-Configuration module; 120-First determination module; 130-Second determination module; 140-Communication module; 200-Terminal device; 210-Memory; 220-Processor. Detailed Implementation

[0029] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0030] The following description, with reference to the accompanying drawings, describes the method for constructing a DDS simulation link, a computer-readable storage medium, a device for constructing a DDS simulation link, and a terminal device proposed in the embodiments of this application.

[0031] Figure 1 This is a flowchart of a method for building a DDS simulation link according to an embodiment of this application.

[0032] like Figure 1 As shown, the method for building a DDS simulation link according to an embodiment of this application may include the following steps:

[0033] S1, Configure the service list based on the target toolchain, wherein the service list includes the first service list on the server side and the second service list on the client side in the DDS simulation program.

[0034] S2, when the service is a server-side service, determine the corresponding service's interface function and DDS communication matrix based on the first service list; when the service is a client-side service, determine the corresponding service's interface function and DDS communication matrix based on the second service list.

[0035] S3 determines the target service information for each service based on the DDS communication matrix.

[0036] S4 enables DDS data communication between the test software and the controller under test based on interface functions and target service information.

[0037] Specifically, when building a DDS simulation pipeline, the service list can be configured first according to the target toolchain. For example, based on an SOA (Service-Oriented Architecture) toolchain, the service list consists of two main parts: the first service list, which includes services running as servers in the DDS simulation program. These services will provide interfaces for clients to call. The second service list, which includes services running as clients in the DDS simulation program, will call the interfaces provided by the servers. For example, configuring the service list may include selecting or defining service names and version numbers, defining the interface functions for each service, including function names, input parameters, and output parameters, and defining the data types of the services, including basic data types, enumeration types, and structure types.

[0038] For server-side services, the interface function and DDS communication matrix for each service can be determined based on the first service list. For client-side services, the same operation can be performed based on the second service list, i.e., determining the interface function and DDS communication matrix for each service. The DDS communication matrix is ​​a data structure that defines the communication relationships between services, including: service name, version number, interface function name and its parameter and return value data types, and the QoS (Quality of Service) policy for communication. The communication parameters for each service, such as data format, transport protocol, IP address, and port number, are configured in the DDS communication matrix.

[0039] After determining the DDS communication matrix, the target service information for each service can be determined based on it. Tools or scripts can be used to parse the DDS communication matrix, extracting detailed information for each service. Based on the parsing results, the target service information for each service can be determined, including the service identifier, communication protocol, port, and QoS policy. Therefore, after determining the interface functions and target service information, DDS data communication between the test software and the controller under test (DUT) can be implemented. For example, a DDS simulation program can be developed based on the interface functions and target service information. This includes implementing the server and client interface functions, configuring the DDS communication protocol stack, using data structures defined in Proto files to serialize and deserialize DDS messages, ensuring consistent data exchange formats between the test software and the DDS simulation program, and configuring network communication parameters such as IP address and port number in the DDS simulation program to ensure communication with the DUT. Thus, a complete DDS simulation link can be established for single-unit bench testing of intelligent driving domain controllers.

[0040] Therefore, this application develops a DDS simulation program to achieve DDS data transmission and reception between the test bench and the controller under test (DUT). Through data interaction between the DDS simulation program and the test software, the test software can transmit and receive DDS data from the DUT, thus solving the problem of DDS data simulation in test tools. Furthermore, it eliminates the need for hand-written code, significantly improving the efficiency and reliability of link setup, thereby reducing testing costs and shortening the testing cycle.

[0041] According to one embodiment of this application, the DDS simulation program and the test software communicate using UDP (User Datagram Protocol), or they communicate using ZeroMQ (Zero Message Queue) communication middleware.

[0042] Specifically, in the data communication between the DDS simulation program and the testing software, data communication can be carried out through UDP. UDP is a connectionless network protocol that provides a simple way to send encapsulated IP datagrams on top of the IP protocol. UDP does not guarantee the order, integrity or reliability of data packets, but it is simple to implement and has low overhead. It is suitable for applications that have high real-time requirements but can tolerate some data loss, such as in voice or video communication, where slight data loss will not significantly affect the user experience.

[0043] Alternatively, the DDS simulation program can communicate with the test software using the ZeroMQ communication middleware. ZeroMQ (also known as ZMQ) is a high-performance asynchronous messaging library that provides a simple way to communicate in distributed or concurrent applications. ZeroMQ supports various message transmission modes, including publish-subscribe, request-response, and pipelines, and can be used in high-performance distributed or concurrent applications to handle large numbers of messages without degrading performance. For example, this approach can be used for high-throughput data processing applications that require high-performance message queues.

[0044] According to one embodiment of this application, DDS data communication between test software and the controller under test is realized based on interface functions and target service information, including: determining data information received by the DDS simulation program based on the target service information, wherein the data information includes DDS data sent by the controller under test and test data sent by the test software; when the DDS simulation program receives a service request sent by the controller under test, transmitting the DDS data to the test software based on an interface function generated based on a first service list; when the DDS simulation program receives a service request sent by the test software, transmitting the test data to the controller under test based on an interface function generated based on a second service list.

[0045] Specifically, DDS simulation programs need to process two types of data: DDS data sent by the controller under test (DUT), which is generated by the DUT and sent to the test software or DDS simulation program, and may include sensor readings, status information, or other monitoring data; and test data sent by the test software, which is generated by the test software and sent to the DUT or DDS simulation program, and can be used to simulate external events or inputs to test the behavior of the DUT. The DDS simulation program acts as middleware, responsible for forwarding data between the test software and the DUT. It receives data from either end and routes the data to the other end according to the configuration and interface functions.

[0046] When the DDS simulation program receives a service request from the controller under test, it listens to the network interface and receives DDS data from the controller under test. Based on the target service information, the DDS simulation program identifies the service and interface function to which the data belongs. The DDS simulation program uses the interface function generated based on the first service list to encapsulate the received DDS data into a format that the test software can understand, so that the DDS simulation program sends the encapsulated data to the test software.

[0047] When the DDS simulation program receives a service request from the test software, it listens to the network interface and receives test data from the test software. Based on the target service information, the DDS simulation program identifies the service and interface function to which the data belongs. The DDS simulation program uses the interface function generated based on the second service list to encapsulate the received test data into a format that the controller under test can understand, so that the DDS simulation program sends the encapsulated data to the controller under test.

[0048] In addition, the DDS simulation program should also be able to verify the integrity and correctness of the received data. During data transmission, the DDS simulation program should be able to handle possible errors, such as network failures and data format errors. In this way, the DDS simulation program ensures that data communication between the test software and the controller under test is both reliable and efficient, thereby supporting effective functional testing and verification.

[0049] According to one embodiment of this application, the method for building a DDS simulation link includes: reading the input parameter information and return value information of each interface function in each service, and converting basic data types, enumeration types, and structure types into message types in a Proto (Protocol Buffers) file, wherein the Proto file is used to represent the data format for communication between the DDS simulation program and the test software.

[0050] Specifically, in the communication between the DDS simulation program and the testing software, the Proto file defines the data structures and communication protocols, making data exchange between different languages ​​and platforms standardized and simplified. First, it allows analysis of the parameters (input parameters) and return values ​​of each interface function in each service, including the parameter names and order. The data type of the parameters can be a basic data type (such as int, float, string, etc.), an enumeration type, or a structure type, as well as the data type of the return value. The Proto file needs to define the data types corresponding to the interface function parameters and return values. The Proto file uses specific syntax to define message types, each message type can contain multiple fields, each with a specified data type and field number. In this way, the DDS simulation program and the testing software can exchange data in a standardized and efficient manner, ensuring data consistency and accuracy.

[0051] According to one embodiment of this application, the method for building a DDS simulation link includes: obtaining DDS communication protocol stack code compatible with the controller under test; and compiling and generating a DDS simulation program based on the DDS communication protocol stack code, interface functions, target service information, and Proto file.

[0052] Specifically, obtaining DDS communication protocol stack code compatible with the controller under test (DUT) allows for the selection of a suitable DDS implementation, such as OpenSplice or CycloneDDS, based on the DUT's technical specifications. This ensures the selected DDS implementation supports the features required by the DUT, such as QoS (Quality of Service) policies and security requirements. Service interface function code is generated using the toolchain or other tools, defining the client and server attributes of the service and their communication rules. Based on the parameters and return values ​​of the service interface functions, a Proto file is written to define the data structures, ensuring that the data types in the Proto file match those defined in the DDS communication matrix. The obtained DDS communication protocol stack code is then integrated into the simulation program project. The DDS protocol stack is configured to match the DUT's DDS configuration, including DomainID, service discovery multicast IP address, and service communication unicast IP address. The interface functions are implemented using the APIs provided by the DDS protocol stack, ensuring they can correctly publish and subscribe to data.

[0053] Write the business logic code for the DDS simulation program, including the data receiving, processing, and sending logic. Compile the DDS communication protocol stack code, interface function code, target service information, and data access classes generated from the Proto file into an executable DDS simulation program. Afterward, perform unit tests on each component of the DDS simulation program to ensure they can correctly process data, and test the performance of the DDS simulation program to ensure it meets real-time and reliability requirements.

[0054] This allows the generation of a DDS simulation program compatible with the controller under test, which can accurately simulate and forward test data, providing support for the functional testing of intelligent driving domain controllers.

[0055] According to one embodiment of this application, the method for building a DDS simulation link includes: configuring the service communication unicast IP address used by the DDS simulation program on the host network card.

[0056] Specifically, configuring the service communication unicast IP address used by the DDS emulation program on the host network interface card (NIC) is a crucial step in ensuring correct network communication between the DDS emulation program and the controller under test (DUT). First, a unicast IP address needs to be assigned to the host NIC. This address will be used for point-to-point communication between the DDS emulation program and the DUT. This IP address must be unique within the network and accessible to the DUT via the network. Furthermore, the chosen IP address should conform to the network subnetting and IP address allocation. On the host, access the network configuration through the operating system's network settings interface and assign a static IP address to the NIC. Record the configured IP address for use in the DDS emulation program's configuration file.

[0057] In the DDS simulation program's configuration file (e.g., an XML file), specify the unicast IP address for service communication. This address should match the IP address configured on the host network interface card (NIC) and be compatible with the network configuration of the controller under test (DUT). After configuration, start the DDS simulation program and ensure it can use the configured IP address for network communication. Perform network tests, such as using network testing tools (e.g., the ping command), to test the network connectivity between the host and the DUT. While the DDS simulation program is running, verify that it can successfully establish a connection and exchange data with the DUT. If network communication problems occur, check the host NIC's network configuration to ensure the IP address, subnet mask, and default gateway are set correctly. Check the DDS simulation program's configuration file to ensure all network parameters (e.g., IP address, port number) are correct.

[0058] This ensures that the DDS simulation program uses the correct service communication unicast IP address, thereby achieving stable network communication with the controller under test. This is crucial for effective functional testing and verification.

[0059] According to one embodiment of this application, the DDS simulation program uses a target XML file to configure DomainID (DomainIdentifier, an identifier that represents or distinguishes different domains), service discovery multicast IP address, service communication unicast IP address, and other configuration items. The configuration item data is consistent with the DDS communication configuration in the controller under test. The DDS simulation program reads the target XML (eXtensible Markup Language) file when it starts.

[0060] Specifically, the DDS emulation program is configured by reading an XML file. When the DDS emulation program starts, it reads a target XML file containing all the configuration information required by the program. This target XML file can configure the DomainID, service discovery multicast IP address, service communication unicast IP address, and other configuration items. These parameters should match the DDS configuration of the controller under test (DUT) to ensure correct communication. For example, the DomainID specified in the XML file can be used to set the DDS emulation program's DomainID. The DomainID distinguishes different DDS communication domains, ensuring that data is transmitted only between participants within the same domain. The service discovery multicast IP address is used to configure the DDS emulation program's service discovery mechanism, allowing it to discover other DDS participants within the same domain. The service communication unicast IP address is used to configure the DDS emulation program's communication address, ensuring point-to-point communication between the DDS emulation program and the DUT.

[0061] Once the DDS environment initialization is complete, the DDS simulation program can begin data communication with the controller under test (DUT), forwarding data from the test software and receiving data from the DUT. Additionally, during DDS simulation program operation, its status and performance should be monitored to ensure correct communication with the DUT. Verify that the DDS simulation program correctly reads and applies the parameters in the XML configuration file using log information or debugging tools. If communication problems occur, check the XML configuration file and the DDS simulation program configuration to ensure all parameters are correct and consistent with the DUT configuration. Through this process, the DDS simulation program can flexibly configure its communication parameters to adapt to different test environments and requirements, while ensuring compatibility with the DUT and reliable communication.

[0062] In summary, as a specific example, please refer to... Figure 2 and Figure 3 As shown, the controller under test is an intelligent driving domain controller (vehicle controller ECU (Electronic Control Unit)). The DDS simulation program communicates with the DDS client and DDS server in the controller under test, and also communicates with the test software. The DDS simulation program can receive Proto data sent by the test software, convert it into Struct data, and then pass it to the DDS service interface function, or receive data returned by the DDS service interface function, convert it into Proto data, and send it to the test software for parsing. In other words, the DDS simulation program acts as an intermediate data conversion program, indirectly realizing DDS data communication between the test software and the controller under test.

[0063] First, a test bench can be set up. The Ethernet transceiver (ETH transceiver) is in switch mode and is connected to the host via USB. Connect the controller under test to the Ethernet transceiver and the host to the Ethernet transceiver using cable bundles and network cables to form a closed-loop hardware path. Use the target toolchain to generate service interface function code. The target toolchain contains all existing services, including service name, service version number, interface function name for each service, data type, name, and quantity of interface function input parameters, and data type and name of the interface function return value. Data types include basic data types, enumeration types, and structure types. Structure types also include the data type and name of each member. Configure the service list on the target toolchain, including server-side and client-side service lists. This can be done directly on the SOA toolchain or imported from an Excel spreadsheet. After service configuration, the target toolchain generates the corresponding service interface function code and a DDS communication matrix, which is an Excel spreadsheet.

[0064] The DDS communication matrix can be read using Python. For each service, the service name, client / server attributes, name, input parameters, and return value information of each interface function are retrieved. If the service is a client, the interface function call code for each function is generated according to client-side code calling rules; if the service is a server, the interface function call code is generated according to server-side code calling rules. For each interface function of each service, if the service is a client, the input parameter data comes from the test software. The DDS simulation program calls this interface function to obtain the data returned by the controller under test. The DDS simulation program then sends this returned data to the test software, thus enabling the test software to call the service interface function and receive its return value. For each interface function of each service, if the service is a server, the return value data of the interface function comes from the test software. The DDS simulation program waits for the controller under test to call the interface function of the service, obtains the input parameter data of the interface function sent by the controller under test, and sends the input parameter data to the test software. In addition, the DDS simulation program returns the return value of the interface function to the controller under test, thereby enabling the test software to set the return value of the interface function and monitor the call of the interface function.

[0065] The DDS simulation program and the test software can communicate via UDP or ZeroMQ communication middleware. The data begins with a Topic name, which includes three key pieces of information: service name, interface function name, and whether the input parameters or return value are valid. This is followed by Proto serialized data. Python reads the DDS communication matrix, extracting the input parameters and return values ​​of each interface function within each service. Basic data types, enumeration types, and structure types are converted into Messages in the Proto file. This Proto file is used for data conversion in the DDS simulation program and for data format communication with the test software. Therefore, this application, by developing a DDS simulation program, enables DDS data transmission and reception between the test bench and the controller under test (DUT). Through data interaction between the DDS simulation program and the test software, the test software can send and receive DDS data from the DUT, thus solving the problem of DDS data simulation in test tools.

[0066] This application uses Python and DDS communication matrix to generate source code, eliminating the need for handwritten code, which greatly improves the efficiency and reliability of link construction, thereby reducing testing costs and shortening the testing cycle.

[0067] In summary, the DDS simulation link construction method according to the embodiments of this application configures a service list based on the target toolchain. The service list includes a first service list for the server side and a second service list for the client side in the DDS simulation program. When the service is a server-side service, the interface function and DDS communication matrix of the corresponding service are determined based on the first service list. When the service is a client-side service, the interface function and DDS communication matrix of the corresponding service are determined based on the second service list. The target service information for each service is determined based on the DDS communication matrix. DDS data communication between the test software and the controller under test is achieved based on the interface function and target service information. Therefore, this method can solve the problem of simulating DDS data in the test tool, reduce testing costs, and shorten the testing cycle.

[0068] Corresponding to the above embodiments, this application also proposes a computer-readable storage medium.

[0069] The computer-readable storage medium of this application embodiment stores a program that, when executed by a processor, implements the above-described method for building a DDS simulation link.

[0070] According to the computer-readable storage medium of the present application embodiment, by executing the above-described method for building a DDS simulation link, the problem of simulating DDS data by the test tool can be solved, and the test cost and test cycle can be reduced.

[0071] Corresponding to the above embodiments, this application also proposes a device for building a DDS simulation link.

[0072] like Figure 4 As shown, the DDS simulation link construction device 100 of this application embodiment includes: a configuration module 110, a first determination module 120, a second determination module 130 and a communication module 140.

[0073] The configuration module 110 is used to configure a service list based on the target toolchain. The service list includes a first service list for the server and a second service list for the client in the DDS simulation program. The first determination module 120 is used to determine the interface function and DDS communication matrix of the corresponding service based on the first service list when the service is a server-side service, and to determine the interface function and DDS communication matrix of the corresponding service based on the second service list when the service is a client-side service. The second determination module 130 is used to determine the target service information for each service based on the DDS communication matrix. The communication module 140 is used to realize DDS data communication between the test software and the controller under test based on the interface function and the target service information.

[0074] According to one embodiment of this application, the DDS simulation program and the test software communicate with each other using UDP, or using ZeroMQ communication middleware.

[0075] According to one embodiment of this application, the communication module 140 realizes DDS data communication between the test software and the controller under test based on interface functions and target service information. Specifically, it is used to: determine the data information received by the DDS simulation program based on the target service information, wherein the data information includes DDS data sent by the controller under test and test data sent by the test software; when the DDS simulation program receives a service request sent by the controller under test, it transmits the DDS data to the test software based on the interface function generated by the first service list; when the DDS simulation program receives a service request sent by the test software, it transmits the test data to the controller under test based on the interface function generated by the second service list.

[0076] According to one embodiment of this application, the configuration module 110 is further configured to: read the input parameter information and return value information of each interface function in each service, and convert basic data types, enumeration types, and structure types into message types in the Proto file, wherein the Proto file is used to represent the data format for communication between the DDS simulation program and the test software.

[0077] According to one embodiment of this application, the configuration module 110 is further configured to: acquire DDS communication protocol stack code compatible with the controller under test; and compile and generate a DDS simulation program based on the DDS communication protocol stack code, interface functions, target service information and Proto file.

[0078] According to one embodiment of this application, the configuration module 110 is further configured to: configure the service communication unicast IP address used by the DDS emulation program on the host network card.

[0079] According to one embodiment of this application, the DDS simulation program uses a target XML file to configure DomainID, service discovery multicast IP address, service communication unicast IP address and other configuration items, wherein the configuration item data is consistent with the DDS communication configuration in the controller under test, and the DDS simulation program reads the target XML file when it starts.

[0080] It should be noted that for details not disclosed in the DDS simulation link construction device of this application embodiment, please refer to the details disclosed in the DDS simulation link construction method of this application embodiment, which will not be repeated here.

[0081] According to the DDS simulation link construction apparatus of this application embodiment, the configuration module is used to configure a service list based on the target toolchain. The service list includes a first service list for the server side and a second service list for the client side in the DDS simulation program. A first determining module is used to determine the interface function and DDS communication matrix of the corresponding service based on the first service list when the service is a server-side service, and to determine the interface function and DDS communication matrix of the corresponding service based on the second service list when the service is a client-side service. A second determining module is used to determine the target service information of each service based on the DDS communication matrix. A communication module is used to realize DDS data communication between the test software and the controller under test based on the interface function and the target service information. Therefore, this apparatus can solve the problem of simulating DDS data in test tools, reduce testing costs, and shorten the testing cycle.

[0082] Corresponding to the above embodiments, this application also proposes a terminal device.

[0083] like Figure 5 As shown, the terminal device 200 in this embodiment may include: a memory 210, a processor 220, and a program stored in the memory 210 and executable on the processor 220. When the processor 220 executes the program, it implements the above-described method for building a DDS simulation link.

[0084] According to the terminal device in the embodiments of this application, by executing the above-described method for building a DDS simulation link, the problem of simulating DDS data by the test tool can be solved, and the test cost and test cycle can be reduced.

[0085] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0086] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple 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 (PGAs), field-programmable gate arrays (FPGAs), etc.

[0087] 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.

[0088] 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, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0089] In this application, unless otherwise expressly specified and limited, the terms "installation," "connection," "joining," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0090] 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 method for constructing a DDS simulation link, characterized in that, The DDS simulation link is applied to the bench testing of a single intelligent driving domain controller. The DDS simulation link includes test software and a DDS simulation program. The method includes: The service list is configured based on the target toolchain, wherein the service list includes a first service list on the server side and a second service list on the client side in the DDS simulation program; When the service is a server-side service, the interface function and DDS communication matrix of the corresponding service are determined based on the first service list; when the service is a client-side service, the interface function and DDS communication matrix of the corresponding service are determined based on the second service list. The target service information for each service is determined based on the DDS communication matrix. The DDS data communication between the test software and the controller under test is realized based on the interface function and the target service information.

2. The method for constructing a DDS simulation link according to claim 1, characterized in that, The DDS simulation program communicates with the test software using UDP, or it communicates with the test software using ZeroMQ communication middleware.

3. The method for constructing a DDS simulation link according to claim 2, characterized in that, Based on the interface function and the target service information, the test software and the controller under test implement DDS data communication, including: The data information received by the DDS simulation program is determined based on the target service information, wherein the data information includes DDS data sent by the controller under test and test data sent by the test software; When the DDS simulation program receives a service request sent by the controller under test, it transmits the DDS data to the test software based on the interface function generated by the first service list. When the DDS simulation program receives a service request sent by the test software, it transmits the test data to the controller under test based on the interface function generated by the second service list.

4. The method for constructing a DDS simulation link according to claim 3, characterized in that, The method includes: Read the input parameter information and return value information of each interface function in each service, and convert the basic data type, enumeration type, and structure type into the message type in the Proto file. The Proto file is used to represent the data format for communication between the DDS simulation program and the test software.

5. The method for constructing a DDS simulation link according to claim 4, characterized in that, The method includes: Obtain the DDS communication protocol stack code compatible with the controller under test; The DDS simulation program is compiled based on the DDS communication protocol stack code, the interface functions, the target service information, and the Proto file.

6. The method for constructing a DDS simulation link according to claim 1, characterized in that, The method includes: Configure the service communication unicast IP address used by the DDS emulation program on the host network card.

7. The method for constructing a DDS simulation link according to claim 1, characterized in that, The DDS simulation program uses a target XML file to configure DomainID, service discovery multicast IP address, service communication unicast IP address, and other configuration items. The configuration item data is consistent with the DDS communication configuration in the controller under test. The DDS simulation program reads the target XML file when it starts.

8. A computer-readable storage medium, characterized in that, It stores a program that, when executed by a processor, implements the method for building a DDS simulation link according to any one of claims 1-7.

9. A device for constructing a DDS simulation link, characterized in that, The DDS simulation link is used for bench testing of intelligent driving domain controllers. The DDS simulation link includes test software and a DDS simulation program. The device includes: A configuration module is used to configure a service list based on a target toolchain, wherein the service list includes a first service list for the server and a second service list for the client in the DDS simulation program; The first determining module is used to determine the interface function and DDS communication matrix of the corresponding service based on the first service list when the service is a server-side service, and to determine the interface function and DDS communication matrix of the corresponding service based on the second service list when the service is a client-side service. The second determining module is used to determine the target service information for each service based on the DDS communication matrix. The communication module is used to enable DDS data communication between the test software and the controller under test based on the interface function and the target service information.

10. A terminal device, characterized in that, It includes a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the method for building a DDS simulation link according to any one of claims 1-7.

Images