DDS communication simulation test system and method, electronic equipment and storage medium

Abstract

The invention relates to data transmission in a vehicle-mounted distributed system, in particular to a DDS communication simulation test system and method, electronic equipment and a storage medium, and the method comprises the steps: obtaining a test request, running a test script according to the test request, starting a publishing end, and publishing test sample data by using the publishing end to communicate with a subscription end; the publishing end is Canon equipment, and the subscribing end is tested equipment, or the publishing end is tested equipment, and the subscribing end is Canon equipment; and capturing a test message interacted between the publishing end and the subscription end, analyzing the test message to obtain an execution result, comparing the execution result with a preset condition, and outputting a test result. Bidirectional information interaction can be realized, a test link can be perfected, a test process can be simplified, and test efficiency can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to data transmission in a vehicle-mounted distributed system, in particular to a DDS communication simulation test system and method, electronic equipment and storage medium. BACKGROUND

[0002] DDS (Data Distributed Service) as a new generation of distributed real-time communication middleware protocol and API standard, its technical root can be traced back to the early application of naval system. With the core advantage of the publish-subscribe mode, it can realize real-time transmission of data, efficient interaction, security protection and flexible adaptation, perfectly meet the multi-element needs of distributed communication scene, so it has been widely used in the fields of national defense, civil aviation, industrial control and other fields. With the upgrading of the demand for high reliability communication technology in the vehicle-mounted field, domestic host manufacturers are investing more research and development focus on the technology development and landing application of DDS in the vehicle-mounted scene.

[0003] In related technologies, for example: by constructing DDS publishing model, matching model and hardware IP address to realize simulation connection, and relying on dSPACE to complete inter-domain communication. But this scheme only supports the Ethernet communication function of the DDS publishing end, cannot realize the bidirectional information interaction of the publishing end and the subscribing end, and the applicability is limited in the whole link test scene. For another example: a test system including an industrial computer, a DDS server, a tested hardware, a CICD platform and test cases is built. However, the strong dependence of this scheme on the CICD platform leads to complex test prerequisites, which not only makes it difficult to become a general test scheme, but also greatly reduces its universality. SUMMARY

[0004] The purpose of the present application is to provide a DDS communication simulation test system, method, electronic equipment and storage medium, which can realize bidirectional information interaction, perfect the test link, simplify the test process and improve the test efficiency.

[0005] In order to achieve the above purpose, the technical scheme adopted by the present application is as follows: In a first aspect, the present application discloses a DDS communication simulation test method, which comprises: Obtaining a test request, running a test script according to the test request, starting a publishing end, and publishing test sample data with the publishing end to communicate with the subscribing end; the publishing end is a Canoe device, and the subscribing end is a tested device, or the publishing end is a tested device, and the subscribing end is a Canoe device; Capturing the test messages exchanged between the publishing end and the subscribing end, analyzing the test messages to obtain execution results, comparing the execution results with preset conditions, and outputting test results.

[0006] Further, before obtaining the test request of the device under test, the method further comprises: connecting the publishing end and the subscribing end through Ethernet, setting the IP addresses of the publishing end and the subscribing end as the same, so that the publishing end and the subscribing end are in the same network.

[0007] Further, the test script comprises a publishing end test script and a subscribing end test script. The creation of the publishing end test script comprises: creating a new vCDL script file, importing a DDS module and a function library in the vCDL script file, so that the test script obtains DDS protocol support; establishing a DDS domain and a data topic, and configuring a publishing end and a QoS policy; specifying a network interface used by the publishing end; The subscribing end test script has the same creation process as the publishing end test script.

[0008] Further, the execution result is whether the subscribing end receives the test sample data published by the publishing end. If the subscribing end receives the test sample data published by the publishing end, it is determined that the test passes; otherwise, it is determined that the test fails.

[0009] Further, the test sample data published by the publishing end is encapsulated into an RTPS message, and the publishing end and the subscribing end complete data interaction through an RTPS protocol.

[0010] Further, the publishing end and the subscribing end complete data interaction through an RTPS protocol comprises: a DDS node broadcasts handshake information to the surroundings, and determines a DDS participant after successful handshake; the DDS participant confirms the subscribing end and the publishing end by sending and receiving messages; the publishing end encapsulates the test sample data into a Data sub-message in the RTPS protocol, publishes through the network, and periodically sends a heartbeat message after sending the Data sub-message; after receiving the Data sub-message and the heartbeat message, the subscribing end responds to the publishing end through an AckNack message; when the subscribing end checks that the received Data sub-message is correct, it feeds back complete reception of the test sample data in the AckNack; when the subscribing end finds that part of the Data sub-message is lost, it feeds back incomplete reception of the test sample data in the AckNack.

[0011] Further, the execution result obtained by the packet capturing tool is displayed through a graphical interface.

[0012] In a second aspect, the application discloses a DDS communication simulation test system, which comprises: The acquisition module is used for acquiring a test request, running a test script according to the test request, starting a publishing end, and publishing test sample data by using the publishing end to communicate with the subscribing end; the publishing end is a Canoe device, and the subscribing end is a device under test, or the publishing end is the device under test, and the subscribing end is the Canoe device; The grabbing module is used for grabbing test messages exchanged between the publishing end and the subscribing end, and obtaining execution results by analyzing the test messages. The determining module is used for comparing the execution results with preset conditions, and outputting test results.

[0013] In a third aspect, the present application discloses an electronic device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor executes the program to realize the DDS communication simulation test method.

[0014] In a fourth aspect, the present application discloses a computer readable storage medium, which stores a computer program, and the program is executed by a processor to realize the DDS communication simulation test method.

[0015] The present application has the following unexpected beneficial effects: 1. The present application supports bidirectional information interaction between the publishing end and the subscribing end, can completely cover the whole-link scenario of DDS communication, makes the test more realistically simulate the bidirectional flow process of data in the vehicle-mounted environment, ensures the functional integrity and reliability of the device under test in the actual communication scenario, and improves the comprehensiveness and accuracy of the test.

[0016] 2. The present application can complete the test based on only the Canoe device, greatly simplifies the test environment building, configuration adaptation and other links, reduces the operation complexity, can significantly improve the test efficiency, and is more convenient for rapid deployment and application in engineering practice. Moreover, the test is realized based on the Canoe device, without the need of introducing special devices or platforms, reduces the dependence on specific hardware / software environment, makes it more easily popularized and applied in different host manufacturers and different test scenarios, and has stronger universality.

[0017] 3. The present application can better match the stringent requirements of the vehicle-mounted scenario on the DDS communication test by optimizing the test process and perfecting the interaction function. The simplified operation and comprehensive test capability can accelerate the verification and landing of the DDS technology in the vehicle-mounted Ethernet, and provide strong support for the related technology research and development of domestic host manufacturers. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the specific embodiments of the present application or the prior art, the drawings required to be used in the description of the embodiments or the prior art will be briefly introduced. Obviously, the drawings in the following description only represent some embodiments of the present application.

[0019] Figure 1 A flowchart of the DDS communication simulation test method according to an embodiment of the present application is shown.

[0020] Figure 2 A flowchart of the creation of the test script according to an embodiment of the present application is shown.

[0021] Figure 3 A flowchart of the data interaction between the publishing end and the subscribing end according to an embodiment of the present application is shown.

[0022] Figure 4 A structural diagram of the DDS communication simulation test device according to an embodiment of the present application is shown.

[0023] Figure 5 A hardware entity diagram of an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0024] The embodiments of the present application will be described below with reference to the drawings and preferred embodiments, and other advantages and effects of the present application can be easily understood by those skilled in the art from the content disclosed in the present specification. The present application can also be implemented or applied by means of other different specific embodiments, and each detail in the present specification can be modified or changed based on different views and applications without departing from the spirit of the present application. It should be understood that the preferred embodiments are only for the purpose of illustrating the present application, and are not intended to limit the protection scope of the present application.

[0025] In an embodiment, the present application discloses a DDS communication simulation test method, as shown in Figure 1 which comprises: obtaining a test request, running a test script according to the test request, starting a publishing end, and publishing test sample data by the publishing end to communicate with a subscribing end; the publishing end is a Canoe device, and the subscribing end is a device under test, or the publishing end is a device under test, and the subscribing end is a Canoe device; capturing test packets interacted between the publishing end and the subscribing end, analyzing the test packets to obtain an execution result, comparing the execution result with a preset condition, and outputting a test result.

[0026] The application supports bidirectional information interaction of the publishing end and the subscribing end, and can completely cover the whole-link scenario of DDS communication. This feature enables the test to more realistically simulate the bidirectional flow process of data in the vehicle-mounted environment, ensures the functional integrity and reliability of the device under test in the actual communication scenario, and improves the comprehensiveness and accuracy of the test.

[0027] The application can complete the test based on the Canoe device only, greatly simplifies the test environment building, configuration adaptation and other links, reduces the operation complexity, and can significantly improve the test efficiency, and is more convenient for rapid deployment and application in engineering practice. Moreover, the test is realized based on the Canoe device, without the need to additionally introduce special devices or platforms, reduces the dependence on specific hardware / software environment, makes it more easily popularized and applied in different host manufacturers and different test scenarios, and has stronger universality.

[0028] The application can better match the stringent requirements of the vehicle-mounted scenario on the DDS communication test through optimizing the test process and perfecting the interaction function. The simplified operation and comprehensive test capability can accelerate the verification and landing of the DDS technology in the vehicle-mounted Ethernet, and provide strong support for the related technology research and development of domestic host manufacturers.

[0029] As a preferred embodiment of the application, before acquiring the test request of the device under test, the application further comprises: connecting the publishing end and the subscribing end through an Ethernet, and setting the IP addresses of the publishing end and the subscribing end to be the same, so that the publishing end and the subscribing end are in the same network.

[0030] In the preferred embodiment, the setting mode of the unified IP address avoids complex subnet division, gateway configuration or routing rule setting, and reduces the connection failure problem caused by network parameter mismatch. For the test personnel, it is not necessary to have in-depth network protocol knowledge to quickly complete the network adaptation of the publishing end and the subscribing end, which significantly reduces the technical threshold and operation complexity of the test environment building.

[0031] Being in the same network is a basic prerequisite for realizing data interaction in the publish-subscribe mode. Through the setting, it can be ensured that the DDS data sent by the publishing end can be directly recognized and received by the subscribing end, avoiding the delay, packet loss or data filtering problem caused by cross-network segment communication, providing stable underlying network support for the bidirectional information interaction of the publishing end and the subscribing end, and reducing the test error caused by abnormal network environment from the source. Moreover, through the same network configuration, a bidirectional channel is provided for the publishing end to push data to the subscribing end and the subscribing end to feedback the state to the publishing end, which is a prerequisite guarantee for realizing the core function of the publish-subscribe bidirectional interaction, and further makes up for the limitations of the prior art.

[0032] In actual application of the vehicle-mounted Ethernet, the DDS publishing end (such as a sensor or a domain controller) and the subscribing end (such as an actuator or a central control system) are usually in the same vehicle-mounted local area network. This setting mode accurately simulates the network deployment state of the devices in the vehicle-mounted environment, makes the test scene closer to the real application working condition, ensures that the test result can effectively reflect the communication performance of the measured device after being actually installed in a vehicle, and improves the reference value of the test.

[0033] As a preferred embodiment of the present application, referring to Figure 2 The test script includes a publishing end test script and a subscribing end test script. The creation of the publishing end test script includes: A vCDL script file is newly created, and a DDS module and a function library are imported into the vCDL script file, so that the test script obtains DDS protocol support. A DDS domain and a data topic are established, and a publishing end and a QoS policy are configured. A network interface used by the publishing end is specified. The subscribing end test script has the same creation process as the publishing end test script.

[0034] In this preferred embodiment, by importing the DDS module and the function library into the vCDL script, the test script directly obtains native support of the DDS protocol, avoiding problems such as data format error and interaction logic deviation caused by insufficient protocol adaptation. This operation ensures that the test script can accurately follow the DDS protocol specification, lays a foundation for the correctness of subsequent publishing-subscribing interaction, and improves the professionalism and reliability of the test script.

[0035] The publishing end and the subscribing end test scripts have the same creation process, that is, both include the steps of importing a protocol library, establishing a domain and a topic, configuring node parameters, and specifying a network interface, forming a unified development specification: for the test personnel, there is no need to learn different development logics for the two scripts, reducing the learning cost and operation error; for the test project, the standardized process facilitates batch development, version management and reuse of the scripts, reduces redundant work caused by inconsistent processes, and significantly improves the script development efficiency. Moreover, since the publishing end and the subscribing end scripts have symmetrical development logics and both complete protocol adaptation, parameter configuration and interface binding, the two ends can realize bidirectional interaction such as data publishing-receiving and request-response based on the unified rules. This feature directly supports the core advantage of the present application in simultaneously realizing information interaction of the publishing end and the subscribing end at the script layer, effectively makes up for the defect of the prior art that only supports single-end communication, and ensures the integrity of the DDS communication full-link test.

[0036] The establishment of the DDS domain and the data topic ensures that the publishing end and the subscribing end interact based on the same communication domain and data topic, avoids the data island problem caused by domain isolation or topic mismatch, and the QoS policy configuration can flexibly set the quality of service parameters according to the vehicle scene demand, so that the test script can simulate the communication demand under different working conditions, and the scene coverage of the test is improved. By specifying the network interface, the communication interface of the publishing end and the subscribing end is clear, interface conflicts in a multi-network card environment are avoided, and the uniqueness and stability of the data transmission path are ensured.

[0037] As a native script language of the Canoe device, the vCDL is combined with the DDS module to fully utilize the integrated advantages of Canoe in vehicle bus testing, such as real-time monitoring, data recording, and automation execution. Test personnel can directly call the script through the visual interface of Canoe, which simplifies the operation process of script debugging and test execution, and further reduces the test threshold.

[0038] As a preferred embodiment of the present application, the execution result is whether the subscribing end receives the test sample data published by the publishing end; in response to the subscribing end receiving the test sample data published by the publishing end, it is determined that the test passes; otherwise, it is determined that the test fails.

[0039] The determination method of the preferred embodiment greatly simplifies the logic of result determination, so that the test personnel can quickly and clearly determine whether the basic communication function of the device under test is normal, and the intuitiveness and determination efficiency of the test result are improved.

[0040] In vehicle Ethernet applications, the basic requirement of DDS communication is that data can be accurately transmitted from the publishing end (such as a sensor) to the subscribing end (such as a controller), otherwise subsequent data analysis, instruction execution and other links cannot be discussed. The determination standard ensures that the test result can directly reflect the basic communication feasibility of the device under test in actual application, and lays a reliable foundation for subsequent more complex function tests.

[0041] As a preferred embodiment of the present application, the test sample data published by the publishing end is encapsulated into an RTPS packet, and the publishing end and the subscribing end complete data interaction through the RTPS protocol.

[0042] RTPS (Real-time Publish-Subscribe Protocol) is the underlying transport protocol of DDS. Encapsulating test sample data into RTPS messages and interacting through this protocol ensures that the communication process between the publisher and subscriber conforms to unified technical specifications, avoiding platform barriers caused by proprietary protocols. Regardless of different vendors' DDS implementations or different hardware architectures, seamless integration can be achieved based on the RTPS protocol, significantly improving the cross-platform adaptability of the testing system.

[0043] As a preferred embodiment of the present invention, see Figure 3 As shown, the data interaction between the publisher and subscriber via the RTPS protocol includes: DDS nodes broadcast handshake information to their surroundings, and once the handshake is successful, the DDS participants are identified.

[0044] DDS nodes establish initial connections by broadcasting handshake messages, ensuring that all potential publishers and subscribers in the network are accurately identified and included in the communication domain, avoiding one-way communication or data silos caused by missing nodes. This configuration provides a prerequisite for bidirectional interaction between publishers and subscribers, offering greater flexibility and adaptability than the statically configured communication modes in existing technologies.

[0045] DDS participants confirm the subscriber and publisher by sending and receiving messages.

[0046] By confirming the identities of the publisher and subscriber through message exchange, both parties can clarify the direction and responsibilities of data transmission at the beginning of communication, reducing logical confusion in subsequent interactions, such as the subscriber sending data incorrectly or the publisher receiving instructions incorrectly, and improving the standardization of the communication link.

[0047] The publishing end encapsulates the test sample data into Data sub-messages in the RTPS protocol, publishes them over the network, and periodically sends heartbeat messages after sending the Data sub-messages.

[0048] Test sample data is encapsulated into RTPS standard Data sub-messages to ensure the data format conforms to the protocol specifications and avoids parsing errors caused by format incompatibility. The heartbeat messages periodically sent by the publisher provide subscribers with real-time feedback on data transmission status, enabling them to promptly perceive the publisher's online status and data transmission rhythm. If the heartbeat is interrupted, communication anomalies such as network disconnection or publisher failure can be quickly identified.

[0049] The subscription end receives the Data sub-message and the heartbeat message, and responds to the publishing end through an AckNack message; when the subscription end checks that the received Data sub-message is correct, the subscription end feeds back complete reception of the test sample data in the AckNack; and when the subscription end finds that part of the Data sub-message is lost, the subscription end feeds back a non-acknowledgement mode in the AckNack, that is, the test sample data is not received completely.

[0050] The subscription end accurately feeds back the data reception state through the AckNack message, confirms communication success when the data is received completely, and explicitly indicates the missing content when the data is partially lost. This closed-loop feedback enables the publishing end to retransmit the lost data in a targeted manner, significantly reducing the risk of data loss caused by network jitter and interference. In a vehicle-mounted scenario, this mechanism is crucial for ensuring the integrity of critical data.

[0051] The interaction process of the RTPS protocol completely replicates the underlying logic of real vehicle-mounted DDS communication: from node discovery and role negotiation to data transmission and state feedback, each step is consistent with the actual communication scenario after the vehicle is mounted. This means that the test process not only verifies whether the data can be transmitted, but also simulates abnormal situations that may occur in the real environment, such as heartbeat interruption, data loss, and effectiveness of the retransmission mechanism, so that the test results can directly reflect the communication performance of the device under test in actual application, providing a more realistic reference for subsequent function optimization and fault troubleshooting.

[0052] Since each step of the interaction process has explicit message interaction, such as handshake messages, role confirmation messages, Data sub-messages, heartbeat messages, and AckNack messages, the Canoe device, which is a test tool, can record and analyze these messages throughout the process. When the test fails, the tester can quickly locate the problem by tracing the message sequence. For example, if the handshake fails, network configuration or node compatibility issues can be checked; if the heartbeat is interrupted, the stability of the publishing end or network link failure can be focused on; and if the AckNack feedback indicates data loss, the packet loss reason (such as network congestion or improper message priority setting) can be analyzed. This debugging method of tracing by process is more efficient than traditional fuzzy result determination, significantly reducing the time cost of test troubleshooting. As a preferred embodiment of the present application, the packet capture tool displays the execution results obtained through analysis on a graphical interface.

[0053] The graphical interface converts complex message data, interaction timing, state identifiers, and other information into intuitive charts, flowcharts, or state identifiers, such as green identifiers for successful data transmission, red warnings for packet loss, and interaction nodes on the timing axis. The tester does not need to deeply understand the original data format or protocol details, but can quickly understand the communication state of the publishing end and the subscription end, the data transmission link, and the execution results, significantly shortening the information processing time and improving the decision-making efficiency during the test process.

[0054] In an embodiment, the present application discloses a DDS communication simulation test system, as shown in Figure 4 The DDS communication simulation test system 10 comprises: An acquisition module 11 is configured to acquire a test request, run a test script according to the test request, start a publishing end, and publish test sample data by using the publishing end to communicate with a subscribing end; the publishing end is a Canoe device, the subscribing end is a device under test, or the publishing end is the device under test, and the subscribing end is the Canoe device. A grabbing module 12 is configured to grab test messages exchanged between the publishing end and the subscribing end, and analyze the test messages to obtain an execution result. A determination module 13 is configured to compare the execution result with a preset condition, and output a test result.

[0055] In an embodiment, the present application discloses an electronic device, 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 simulation test method.

[0056] As shown in Figure 5 The hardware entities of the electronic device 20 comprise a processor 21, a memory 22, and a communication interface 23, wherein: The processor 21 generally controls the overall operation of the electronic device 20.

[0057] The memory 22 is configured to store instructions and applications executable by the processor 21, and can also cache data to be processed by the processor 21 and modules in the electronic device 20, such as image data, audio data, voice communication data, and video communication data, which can be realized by a FLASH or a random access memory (RAM).

[0058] The communication interface 23 can enable the electronic device to communicate with other terminals or servers through a network.

[0059] The processor 21, the memory 22, and the communication interface 23 can transmit data through a bus 24.

[0060] In an embodiment, the present application discloses a computer readable storage medium, which stores a computer program, and the program is executed by a processor to implement the DDS communication simulation test method.

[0061] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other manners. The embodiments described above are merely exemplary, for example, the division of the modules is only a logical function division, and there can be other division manners in actual implementation, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed coupling, or direct coupling, or communication connection between any two components can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or in other forms.

[0062] The units described as separate components above can or can not be physically separate, and the components shown as units can or can not be physical units; they can be located in one place or distributed on a plurality of network units; and part or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

[0063] In addition, each functional unit in each embodiment of the present application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; and the integrated unit can be implemented in the form of hardware or in the form of hardware plus software functional unit.

[0064] The above is merely an implementation manner of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical range disclosed in the present application, which should be covered in the protection scope of the present application.

Claims

1. A DDS communication simulation test method, characterized in that, include: Obtain a test request, run a test script according to the test request, start the publishing end, and use the publishing end to publish test sample data and communicate with the subscription end; The publishing end is a Canoe device and the subscription end is the device under test, or the publishing end is the device under test and the subscription end is a Canoe device; The test messages between the publisher and subscriber are captured, the test messages are parsed to obtain the execution results, the execution results are compared with preset conditions, and the test results are output.

2. The DDS communication simulation test method according to claim 1, characterized in that: Before obtaining the test request from the device under test, the method further includes: connecting the publisher and the subscriber via Ethernet, and setting the IP addresses of the publisher and the subscriber to be the same, so that the publisher and the subscriber are in the same network.

3. The DDS communication simulation test method according to claim 1, characterized in that: The test scripts include publisher test scripts and subscriber test scripts; The creation of the release-side test script includes: Create a new vCDL script file, import the DDS module and function library into the vCDL script file, so that the test script can obtain DDS protocol support; Establish DDS domains and data topics, and configure the publisher and QoS policies; Specify the network interface used by the publishing end; The creation process for the subscription-side test script is the same as that for the publishing-side test script.

4. The DDS communication simulation test method according to claim 1, characterized in that: The execution result is whether the subscriber has received the test sample data published by the publisher. The test is considered passed when the subscriber receives the test sample data published by the publisher. Otherwise, the test is considered failed.

5. The DDS communication simulation test method according to claim 1, characterized in that: The test sample data published by the publishing end is encapsulated as RTPS messages, and the publishing end and the subscription end complete data interaction through the RTPS protocol.

6. The DDS communication simulation test method according to claim 5, characterized in that, The data interaction between the publisher and subscriber via the RTPS protocol includes: DDS nodes broadcast handshake information to their surroundings, and DDS participants are identified after a successful handshake. DDS participants confirm the subscriber and publisher by sending and receiving messages; The publishing end encapsulates the test sample data into Data sub-messages in the RTPS protocol, publishes them over the network, and periodically sends heartbeat messages after sending the Data sub-messages. After receiving the Data sub-message and the heartbeat message, the subscriber responds to the publisher via an AckNack message. If the subscriber verifies that the received Data sub-message is correct, it reports in the AckNack message that the test sample data has been received completely. If the subscriber finds that some Data sub-messages are missing, it reports in the AckNack message that the test sample data has not been received completely.

7. The DDS communication simulation test method according to claim 1, characterized in that: The packet capture tool displays the parsed execution results through a graphical interface.

8. A DDS communication simulation test system, characterized in that, include: The acquisition module is used to acquire test requests, run test scripts according to the test requests, start the publishing end, and use the publishing end to publish test sample data and communicate with the subscription end; The publishing end is a Canoe device and the subscription end is the device under test, or the publishing end is the device under test and the subscription end is a Canoe device; The capture module is used to capture test messages exchanged between the publisher and subscriber, and parse the test messages to obtain the execution results; The judgment module is used to compare the execution result with preset conditions and output the test result.

9. An electronic device, characterized in that, include: 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 simulation test method as described in any one of claims 1 to 6.

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 simulation test method as described in any one of claims 1 to 6.

Images