Automatic driving cluster simulation test system, method, device and program product

Abstract

The embodiment of the invention provides an automatic driving cluster simulation test system, method, device and program product, and relates to the technical field of automatic driving. The system comprises a server and at least one cluster, wherein each cluster comprises a host and at least one slave; a plurality of automatic driving simulation test items are stored in the server; the host in each cluster is used for determining a scheduling node and at least one execution node for the host and the at least one slave in the cluster; the scheduling node is used for sending the identification information of the target project to the target execution node; the target execution node is used for acquiring the target item from the server according to the identification information; running automatic driving simulation test software deployed by the target execution node, and executing the target project; and after the execution of the target project is completed, storing a simulation test result of the target project in the server. According to the embodiment of the invention, the simulation test can be efficiently carried out on the automatic driving system for massive application scenes formed by various scene elements.

Description

Technical Field

[0001] This application relates to the field of autonomous driving technology, and more specifically, to an autonomous driving cluster simulation test system, method, equipment, and program product. Background Technology

[0002] With the development of autonomous driving systems, their complexity has further increased. Changing weather conditions, complex traffic environments, diverse driving tasks, and dynamic driving states all present new challenges to the testing and evaluation of autonomous driving systems. How to efficiently conduct simulation tests on autonomous driving systems in the face of massive application scenarios composed of various scenario elements has become a problem that needs to be solved. Summary of the Invention

[0003] The purpose of this application is to provide a cluster simulation testing system, method, device, and program product for autonomous driving, so as to achieve the technical effect of efficiently simulating and testing autonomous driving systems in the face of a large number of application scenarios composed of various scene elements.

[0004] In a first aspect, embodiments of this application provide an autonomous driving cluster simulation test system, including a server and at least one cluster, each cluster including a host and at least one slave; the server stores multiple autonomous driving simulation test items; Each host in the cluster is used to determine a scheduling node and at least one execution node for the hosts and at least one slave in the cluster; The scheduling node is used to send the identification information of the target project to the target execution node; wherein, the target execution node is any idle node among the at least one execution node, and the target project is any unexecuted project among the plurality of autonomous driving simulation test projects; The target execution node is used for: The target project is obtained from the server based on the identification information; Run the autonomous driving simulation test software deployed on the target execution node itself to execute the target project; After the target project is completed, the simulation test results of the target project are stored on the server.

[0005] In the above implementation process, to meet the needs of autonomous driving simulation testing in massive application scenarios, a server and at least one cluster are configured. Multiple autonomous driving simulation test projects are stored in the server. Autonomous driving simulation test software is deployed in the host and at least one slave in each cluster. A distributed cluster simulation test system is established by combining the server and at least one cluster. For each cluster, the host determines the scheduling node and at least one execution node from itself and at least one slave. The scheduling node sends the identification information of any unexecuted target project in multiple autonomous driving simulation test projects to any idle target execution node in at least one execution node. The target execution node retrieves the target project from the server according to the identification information, runs the autonomous driving simulation test software deployed on the target execution node to execute the target project, and stores the simulation test results of the target project on the server after the target project is executed. The distributed cluster simulation test system can use the various clusters to jointly process autonomous driving simulation test projects in massive application scenarios, thereby improving the simulation test efficiency of the autonomous driving system.

[0006] Furthermore, the server also stores the working status of the hosts and at least one slave in each cluster, as well as the execution status of each autonomous driving simulation test project; The target execution node is also used for: After obtaining the target project, a first status update instruction is sent to the server; wherein, the first status update instruction is used to instruct the server to update the working status of the target execution node from idle to busy, and to update the execution status of the target project from never executed to executing. After completing the execution of the target project, a second status update instruction is sent to the server; wherein, the second status update instruction is used to instruct the server to update the working status of the target execution node from busy to idle, and to update the execution status of the target project from executing to executed.

[0007] In the above implementation process, by storing the working status of the host and at least one slave in each cluster, as well as the execution status of each autonomous driving simulation test project, in the server, the target execution node sends a first status update instruction to the server after acquiring the target project, instructing the server to update the working status of the target execution node from idle to busy and the execution status of the target project from unexecuted to executing. After completing the execution of the target project, the target execution node sends a second status update instruction to the server, instructing the server to update the working status of the target execution node from busy to idle and the execution status of the target project from executing to executed. This can automatically update the working status of the target execution node and the execution status of the target project stored in the server during the execution of the target project by the target execution node, effectively avoiding problems such as target project execution conflicts or duplicate execution, thereby further improving the simulation test efficiency of the autonomous driving system.

[0008] Further, determining the scheduling node and at least one execution node for the host and at least one slave in the cluster includes: Based on the node configuration information of the cluster, the scheduling node and the at least one execution node are determined; wherein, the node configuration information is used to designate any device in the cluster as the scheduling node, and all devices in the cluster other than the specified device as the at least one execution node.

[0009] In the above implementation process, by utilizing the hosts in the cluster and determining the scheduling nodes and at least one execution node from the hosts and at least one slave devices in the cluster based on the node configuration information used to specify the scheduling nodes and at least one execution node in the cluster, the scheduling nodes and at least one execution node in each cluster can be determined quickly and accurately. This helps each cluster to quickly engage in simulation testing of the autonomous driving system, which is conducive to further improving the simulation testing efficiency of the autonomous driving system.

[0010] Furthermore, any one of the at least one execution node is also configured to, in the event of detecting abnormal operation of the scheduling node, determine the first normally operating node in the cluster after the scheduling node as the new scheduling node according to the node recommendation order of the cluster. The scheduling node is also configured to delete the current execution node in the cluster and delete the arrangement information of the current execution node in the node recommendation order when it detects that any execution node among the at least one execution node is running abnormally.

[0011] In the above implementation process, by utilizing the operation of scheduling nodes and at least one execution node in the cluster, each execution node detects whether any node in the cluster other than itself is running abnormally. If any execution node detects an abnormal operation of a scheduling node, it determines the first normally operating node in the cluster after the scheduling node as the new scheduling node, according to the cluster's node recommendation order. Furthermore, the scheduling node detects whether any execution node is running abnormally. If the scheduling node detects any abnormal operation of at least one execution node, it deletes the current execution node from the cluster and removes the current execution node's order from the node recommendation order. This approach takes into account the abnormal operation issues of scheduling and execution nodes in practical applications, promptly switching abnormally operating nodes to normally operating nodes upon discovery. This ensures that each cluster can handle autonomous driving simulation test projects under massive application scenarios, thereby further improving the simulation test efficiency of the autonomous driving system.

[0012] Furthermore, any one of the at least one execution node is also used to periodically receive heartbeat packets sent by the calling node. If the number of lost heartbeat packets or the duration of lost heartbeat packets exceeds a first threshold, it is determined that the scheduling node is operating abnormally. The scheduling node is also configured to periodically receive heartbeat packets sent by each of the at least one execution node. If the number of lost heartbeat packets or the duration of lost heartbeat packets exceeds a second threshold, the execution node is determined to be operating abnormally.

[0013] In the above implementation process, by using the heartbeat packet detection method of each node to detect the running status of nodes other than the node itself during the operation of the scheduling node and at least one execution node in the cluster, the detection process of node running status can be simplified, which is conducive to further improving the simulation test efficiency of the autonomous driving system.

[0014] Furthermore, the scheduling node is also used to change the execution status of the autonomous driving simulation test project being executed by the current execution node to not being executed when the current execution node is busy.

[0015] In the above implementation process, by utilizing the scheduling node and at least one execution node in the cluster during operation, when the scheduling node detects abnormal operation of any execution node and the current execution node's working status is busy, it will also change the execution status of the autonomous driving simulation test project currently being executed by the execution node to not executed. This allows the scheduling node to subsequently reschedule the autonomous driving simulation test project currently being executed by the execution node to another execution node for execution, avoiding omissions in processing autonomous driving simulation test projects, thereby further improving the simulation testing efficiency of the autonomous driving system.

[0016] Furthermore, storing the simulation test results of the target project on the server includes: Determine the target storage location within the server corresponding to the identification information; The simulation test results are stored in the target storage location.

[0017] In the above implementation process, by utilizing the target execution node to determine the target storage location corresponding to the identification information of the target project in the server after completing the execution of the target project, and storing the simulation test results in the target storage location, the orderly storage of data in the server can be achieved.

[0018] Furthermore, the target execution node is also used to delete the target project and the simulation test results locally after storing the simulation test results.

[0019] In the above implementation process, by deleting the local target project and its simulation test results after the target execution node has completed storing the simulation test results of the target project, the local storage space of the target execution node can be released in a timely manner, avoiding excessive local resource occupation of the target execution node, improving the running performance of the target execution node, and thus further improving the simulation test efficiency of the autonomous driving system.

[0020] Furthermore, the scheduling node is also used to check the target data stored on the server after completing the execution of the plurality of autonomous driving simulation test projects; wherein, the target data includes the execution status of the plurality of autonomous driving simulation test projects, and / or, the simulation test results of the plurality of autonomous driving simulation test projects.

[0021] In the above implementation process, by using the scheduling node to check the target data associated with multiple autonomous driving simulation test projects stored on the server after the execution of multiple autonomous driving simulation test projects, the accuracy of the entire autonomous driving system simulation test process can be guaranteed, thereby further improving the simulation test efficiency of the autonomous driving system.

[0022] Secondly, embodiments of this application provide a cluster simulation testing method for autonomous driving, applied to an autonomous driving cluster simulation testing system. The system includes a server and at least one cluster, each cluster including a host and at least one slave. The server stores multiple autonomous driving simulation test projects. The method includes: Using the hosts in each cluster, for each host and at least one slave in the cluster, determine the scheduling node and at least one execution node; The scheduling node sends the identification information of the target project to the target execution node; wherein, the target execution node is any idle node among the at least one execution node, and the target project is any unexecuted project among the plurality of autonomous driving simulation test projects; Perform the following operations through the target execution node: The target project is obtained from the server based on the identification information; Run the autonomous driving simulation test software deployed on the target execution node itself to execute the target project; After the target project is completed, the simulation test results of the target project are stored on the server.

[0023] Thirdly, embodiments of this application provide an electronic device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor; the processor executes the computer program to implement the method described above.

[0024] Fourthly, embodiments of this application provide a computer program product, the computer program product including instructions, which, when executed by a computer, cause the computer to perform the method described above.

[0025] Fifthly, embodiments of this application provide a computer-readable storage medium, the computer-readable storage medium including a stored computer program; wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the method described above. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A schematic diagram of the structure of an autonomous driving cluster simulation test system provided in the first embodiment of this application; Figure 2 A flowchart illustrating a cluster simulation testing method for autonomous driving provided in the second embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in the third embodiment of this application. Detailed Implementation

[0028] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0029] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] In related technologies, with the development of autonomous driving systems, system complexity has further increased. Changing weather conditions, complex traffic environments, diverse driving tasks, and dynamic driving states all present new challenges to the testing and evaluation of autonomous driving systems.

[0031] Virtual simulation testing technology based on application scenarios offers advantages such as flexible scenario configuration, high test repeatability, low testing cost, and high testing security. Therefore, simulation testing platforms built upon this technology can handle a vast array of application scenarios, providing more comprehensive support for autonomous driving system products and improving vehicle intelligence and safety performance. However, efficiently simulating and testing autonomous driving systems across a multitude of application scenarios composed of diverse scenario elements remains a critical challenge.

[0032] Based on the number of participating hardware components, simulation testing platforms can be categorized into standalone simulation testing platforms and distributed simulation testing platforms. While standalone simulation testing platforms leverage the characteristics of virtual simulation testing technology, eliminating the need for extensive deployment of sensors and cameras and avoiding numerous interference factors in real-world environments, allowing for rapid setup of application scenarios for simulation testing, their acceleration effect is limited by computer performance, making them unsuitable for handling massive application scenario simulation testing tasks. In contrast, distributed simulation testing platforms, building upon virtual simulation testing technology, further enhance computer performance by adding hardware, directly expanding computer capabilities and breaking through the performance threshold of standalone simulation testing, thereby improving simulation testing efficiency. Therefore, distributed simulation testing platforms can effectively address the challenges of handling massive application scenarios.

[0033] To address this, this application proposes a cluster simulation testing system for autonomous driving. Addressing the simulation testing needs of autonomous driving in a wide range of application scenarios, the system configures a server and at least one cluster. Multiple autonomous driving simulation test projects are stored on the server. Autonomous driving simulation test software is deployed on the host and at least one slave machine within each cluster. This combined system establishes a distributed cluster simulation testing system. For each cluster, the host determines a scheduling node and at least one execution node from itself and at least one slave machine. The scheduling node sends the identification information of any unexecuted target project among the multiple autonomous driving simulation test projects to any idle target execution node among the at least one execution node. The target execution node retrieves the target project from the server based on the identification information, runs the autonomous driving simulation test software deployed on its own, and stores the simulation test results of the target project on the server after execution. This distributed cluster simulation testing system enables the various clusters to collaboratively process autonomous driving simulation test projects in a wide range of application scenarios, improving the simulation testing efficiency of the autonomous driving system.

[0034] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0035] It should be understood that the vehicles described in the embodiments of this application can be pure electric vehicles, hybrid electric vehicles, gas-electric hybrid vehicles, fuel cell vehicles, or vehicles with other energy types including electric motors, and the embodiments of this application are not limited to these. The types of vehicles in the embodiments of this application can include sedans, SUVs, trucks, buses, etc., and the embodiments of this application are not limited to these. The vehicles in the embodiments of this application can be autonomous intelligent driving vehicles or manned vehicles with assisted intelligent driving functions, and the embodiments of this application are not limited to these.

[0036] Please refer to Figure 1 , Figure 1This is a schematic diagram of the structure of an autonomous driving cluster simulation test system provided in the first embodiment of this application. The first embodiment of this application provides an autonomous driving cluster simulation test system, including a server 10 and at least one cluster 20. Each cluster 20 includes a host 201 and at least one slave 202. The server 10 stores multiple autonomous driving simulation test projects. The host 201 in each cluster 20 is used to determine a scheduling node and at least one execution node for the host 201 and at least one slave 202 in the cluster 20. The scheduling node is used to send the identification information of the target project to the target execution node. The target execution node is any idle node among the at least one execution node, and the target project is any unexecuted project among the multiple autonomous driving simulation test projects. The target execution node is used to: obtain the target project from the server 10 according to the identification information; run the autonomous driving simulation test software deployed on the target execution node itself to execute the target project; and store the simulation test results of the target project in the server 10 after completing the execution of the target project.

[0037] As an example, based on the autonomous driving simulation test requirements of massive application scenarios, a server 10 is pre-configured to store multiple autonomous driving simulation test projects. At least one cluster 20 is configured, and each cluster 20 includes a host 201 and at least one slave 202. The host 201 and at least one slave 202 are deployed with autonomous driving simulation test software. The server 10 and the host 201 and at least one slave 202 in each cluster 20 are connected via Ethernet to achieve mutual interaction, thereby establishing a cluster simulation test system.

[0038] It should be noted that each autonomous driving simulation test project is a simulation test project for an application scenario of autonomous driving system.

[0039] For each cluster 20, the host 201 in the cluster 20 determines the scheduling node and at least one execution node for itself and at least one slave 202 in the cluster 20.

[0040] The scheduling node obtains the working status of each execution node, identifies any node in at least one execution node whose working status is idle (i.e., an idle node) as the target execution node, and obtains the execution status of each autonomous driving simulation test project, identifies any project in the multiple autonomous driving simulation test projects whose execution status is not executed (i.e., an unexecuted project) as the target project, and sends the identification information of the target project to the target execution node.

[0041] In practical applications, the server 10 can store the identification information and project files for each autonomous driving simulation test project. The identification information for each autonomous driving simulation test project includes a project ID (Identity Document), and the project file for each autonomous driving simulation test project is used to record the project simulation test content.

[0042] After receiving the identification information of the target project, the target execution node retrieves the target project from the server 10 based on the identification information, runs the autonomous driving simulation test software deployed by the target execution node, executes the target project, and stores the simulation test results of the target project on the server 10 after completing the execution of the target project.

[0043] In practical applications, the target execution node can read the target project's project file from server 10 based on the target project's identification information.

[0044] This application embodiment addresses the needs of autonomous driving simulation testing in massive application scenarios by configuring a server 10 and at least one cluster 20. Multiple autonomous driving simulation test projects are stored within the server 10. Autonomous driving simulation test software is deployed in the host 201 and at least one slave 202 within each cluster 20. A distributed cluster simulation test system is established by combining the server 10 and at least one cluster 20. For each cluster 20, the host 201 determines a scheduling node and at least one execution node from itself and at least one slave 202. The scheduling node sends the identification information of any unexecuted target project among the multiple autonomous driving simulation test projects to any idle target execution node among the at least one execution node. The target execution node retrieves the target project from the server 10 based on the identification information, runs the autonomous driving simulation test software deployed on its own to execute the target project, and stores the simulation test results of the target project on the server 10 after completion. This distributed cluster simulation test system can utilize the various clusters 20 to jointly process autonomous driving simulation test projects in massive application scenarios, improving the simulation test efficiency of the autonomous driving system.

[0045] In an optional embodiment, server 10 further stores the working status of the host 201 and at least one slave 202 in each cluster 20, as well as the execution status of each autonomous driving simulation test project; the target execution node is further configured to: after acquiring the target project, send a first status update instruction to server 10; wherein the first status update instruction is used to instruct server 10 to update the working status of the target execution node from idle to busy, and update the execution status of the target project from unexecuted to executing; after completing the execution of the target project, send a second status update instruction to server 10; wherein the second status update instruction is used to instruct server 10 to update the working status of the target execution node from busy to idle, and update the execution status of the target project from executing to executed.

[0046] As an example, if the cluster simulation test system includes multiple clusters 20, the scheduling nodes in different clusters 20 may easily select the same execution node and / or the same autonomous driving simulation test project, resulting in execution conflicts of the same execution node executing different autonomous driving simulation test projects, repeated execution of the same autonomous driving simulation test project by the same execution node, or repeated execution of the same autonomous driving simulation test project by different execution nodes, etc.

[0047] For this reason, the working status of the host 201 and at least one slave 202 in each cluster 20 is stored in advance in the server 10, that is, idle or busy, as well as the execution status of each autonomous driving simulation test project, that is, not executed, executing or executed.

[0048] After acquiring the target project, the target execution node generates a first status update instruction. The first status update instruction is used to instruct the server 10 to update the working status of the target execution node from idle to busy, and to update the execution status of the target project from never executed to executing. The server 10 sends the first status update instruction to the server 10, so that the server 10 can update the working status of the target execution node from idle to busy, and update the execution status of the target project from never executed to executing.

[0049] The target execution node runs the autonomous driving simulation test software deployed on its own to execute the target project.

[0050] After the target execution node completes the execution of the target project, it generates a second status update instruction. The second status update instruction is used to instruct the server 10 to update the working status of the target execution node from busy to idle, and the execution status of the target project from executing to executed. The server 10 sends the second status update instruction to the server 10 so that the server 10 can update the working status of the target execution node from busy to idle and the execution status of the target project from executing to executed.

[0051] This embodiment of the application stores the working status of the host 201 and at least one slave 202 in each cluster 20, as well as the execution status of each autonomous driving simulation test project, within the server 10. After the target execution node acquires the target project, it sends a first status update instruction to the server 10, instructing the server 10 to update the working status of the target execution node from idle to busy and the execution status of the target project from unexecuted to executing. After completing the execution of the target project, it sends a second status update instruction to the server 10, instructing the server 10 to update the working status of the target execution node from busy to idle and the execution status of the target project from executing to executed. This allows for automatic updates of the working status of the target execution node and the execution status of the target project stored in the server 10 during the execution of the target project by the target execution node, effectively avoiding problems such as target project execution conflicts or duplicate execution, thereby further improving the simulation testing efficiency of the autonomous driving system.

[0052] In an optional embodiment, determining the scheduling node and at least one execution node for the host 201 and at least one slave 202 in the cluster 20 includes: determining the scheduling node and at least one execution node according to the node configuration information of the cluster 20; wherein the node configuration information is used to designate any device in the cluster 20 as the scheduling node, and all devices in the cluster 20 other than the device as at least one execution node.

[0053] As an example, during the initialization phase of the cluster simulation test system, for each cluster 20, node configuration information is configured for the cluster 20. The node configuration information is used to specify any device in the cluster 20 as a scheduling node, and all devices in the cluster 20 other than the scheduling device are at least one execution node.

[0054] For each cluster 20, the host 201 in the cluster 20 can determine the scheduling node and at least one execution node based on the node configuration information of the cluster 20 and at least one slave 202 in the cluster 20.

[0055] It is understandable that the scheduling node in any cluster 20 can be either the host 201 in the current cluster 20 or any slave 202 in the current cluster 20.

[0056] In practical applications, during the initialization phase of the cluster simulation test system, for each cluster 20, the node configuration information of the cluster 20 can be the IP address (Internet Protocol Address) of the scheduling node in the cluster 20. Additionally, the IP addresses of the host 201 and at least one slave 202 in the cluster 20, the storage addresses of each autonomous driving simulation test project within the server 10, and the node election order of the cluster 20 can also be configured for the cluster 20.

[0057] This application embodiment utilizes the host 201 in cluster 20 to determine the scheduling node and at least one execution node from the host 201 and at least one slave 202 in cluster 20 according to the node configuration information used to specify the scheduling node and at least one execution node in cluster 20. This can quickly and accurately determine the scheduling node and at least one execution node in each cluster 20, helping each cluster 20 to quickly engage in simulation testing of the autonomous driving system, and further improving the simulation testing efficiency of the autonomous driving system.

[0058] In an optional embodiment, any one of the at least one execution node is further configured to, upon detecting abnormal operation of the scheduling node, determine the first normally operating node in the cluster 20 arranged after the scheduling node as the new scheduling node according to the node recommendation order of the cluster 20; the scheduling node is further configured to, upon detecting abnormal operation of any one of the at least one execution node, delete the current execution node in the cluster 20, and delete the arrangement information of the current execution node in the node recommendation order.

[0059] As an example, in order to ensure that each cluster 20 can normally handle autonomous driving simulation test projects under massive application scenarios, for each cluster 20, during the operation of the scheduling node and at least one execution node in the cluster 20, each execution node can detect whether the nodes in the cluster 20 other than the execution node itself, that is, the scheduling node and other execution nodes, are running abnormally, and the scheduling node can also detect whether each execution node is running abnormally.

[0060] If any execution node detects that the scheduling node is running abnormally, it obtains the node recommendation order pre-configured for the cluster 20. The node recommendation order of the cluster 20 is the arrangement order between the scheduling node and at least one execution node in the cluster 20. According to the node recommendation order of the cluster 20, the first normal operating node in the cluster 20 after the scheduling node is determined, and this normal operating node is determined as the new scheduling node.

[0061] In practical applications, the node election order of cluster 20 can be a circular order, that is, the node after the last node is the first node, and the first and last nodes are connected to form a circular order.

[0062] If the scheduling node detects that any execution node is running abnormally, it will remove that execution node (i.e., the current execution node) from the cluster 20 and remove the current execution node's arrangement information from the node recommendation order of the cluster 20, so as to avoid selecting the abnormally running node to execute the autonomous driving simulation test system in the future.

[0063] This embodiment of the application, during the operation of scheduling nodes and at least one execution node in cluster 20, utilizes each execution node to detect whether any node in cluster 20, excluding itself, is operating abnormally. If any execution node detects an abnormal operation of a scheduling node, it determines the first normally operating node in cluster 20, following the scheduling node, as the new scheduling node according to the node recommendation order of cluster 20. Furthermore, the scheduling node detects whether any execution node is operating abnormally, and if the scheduling node detects any abnormal operation of at least one execution node, it deletes the current execution node in cluster 20 and removes the current execution node's order from the node recommendation sequence. This approach takes into account the abnormal operation issues of scheduling and execution nodes in practical applications, promptly switching abnormally operating nodes to normally operating nodes upon detection. This ensures that each cluster 20 can normally handle autonomous driving simulation test projects under massive application scenarios, thereby further improving the simulation test efficiency of the autonomous driving system.

[0064] In an optional embodiment, any one of the at least one execution node is further configured to periodically receive heartbeat packets sent by the calling node. If the number of lost heartbeat packets or the duration of lost heartbeat packets exceeds a first threshold, the scheduling node is determined to be operating abnormally. The scheduling node is further configured to periodically receive heartbeat packets sent by the execution node for each of the at least one execution node. If the number of lost heartbeat packets or the duration of lost heartbeat packets exceeds a second threshold, the execution node is determined to be operating abnormally.

[0065] As an example, in order to improve the efficiency of detecting the running status of nodes, a heartbeat detection method can be used.

[0066] For each cluster 20, during the operation of the scheduling node and at least one execution node in the cluster 20, each execution node can periodically receive heartbeat packets sent by each node in the cluster 20 other than itself, such as the scheduling node or another execution node, count the number of heartbeat packets lost since the node started running, and compare the number of lost heartbeat packets with a first threshold corresponding to the number of lost heartbeat packets. If the number of lost heartbeat packets is greater than the first threshold, the node is determined to be operating abnormally; otherwise, the node is determined to be operating normally. Alternatively, each execution node can count the duration from the time the last heartbeat packet was received to the current time, i.e., the heartbeat packet loss duration, and compare the heartbeat packet loss duration with a first threshold corresponding to the heartbeat packet loss duration. If the heartbeat packet loss duration is greater than the first threshold, the node is determined to be operating abnormally; otherwise, the node is determined to be operating normally.

[0067] This application embodiment utilizes a heartbeat packet detection method to detect the running status of nodes other than the nodes themselves in the cluster 20 during the operation of the scheduling nodes and at least one execution node in the cluster 20. This simplifies the node running status detection process and helps to further improve the simulation testing efficiency of the autonomous driving system.

[0068] In an optional embodiment, the scheduling node is further configured to change the execution status of the autonomous driving simulation test project being executed by the current execution node to "not executed" when the current execution node is in a busy state.

[0069] As an example, when a scheduling node detects any execution node running abnormally, it continues to obtain the working status of that execution node, that is, the current execution node. If the current execution node's working status is busy, it is assumed that the current execution node is executing an autonomous driving simulation test project. At this time, the current execution node is removed from the cluster 20, and its arrangement information is removed from the node recommendation order of the cluster 20. The execution status of the autonomous driving simulation test project executed by the current execution node is changed to not executed, so that the subsequent scheduling node can reschedule the autonomous driving simulation test project executed by the current execution node to another execution node. If the current execution node's working status is idle, it is assumed that the current execution node has no autonomous driving simulation test project being executed. At this time, the current execution node is directly removed from the cluster 20, and its arrangement information is removed from the node recommendation order of the cluster 20.

[0070] In this embodiment of the application, during the operation of the scheduling node and at least one execution node in the cluster 20, if the scheduling node detects that any execution node is running abnormally and the current execution node is busy, it will also change the execution status of the autonomous driving simulation test project being executed by the current execution node to not executed. This allows the scheduling node to reschedule the autonomous driving simulation test project being executed by the current execution node to another execution node for execution, avoiding omissions in processing autonomous driving simulation test projects, thereby further improving the simulation test efficiency of the autonomous driving system.

[0071] In an optional embodiment, storing the simulation test results of the target project in the server 10 includes: determining the target storage location within the server 10 corresponding to the identification information; and storing the simulation test results in the target storage location.

[0072] As an example, considering the needs of autonomous driving simulation testing in a massive number of application scenarios, the number of autonomous driving simulation test projects is huge. In order to achieve orderly storage of data within server 10, a storage location can be configured for each autonomous driving simulation test project stored within server 10 during the initialization phase of the cluster simulation test system, so that the identification information of each autonomous driving simulation test project corresponds to a storage location.

[0073] After the target execution node completes the execution of the target project, it obtains the simulation test results of the target project. Since the identification information of the target project was obtained earlier, the target storage location corresponding to it in server 10 can be determined according to the identification information of the target project, and the simulation test results are stored in the target storage location.

[0074] This application embodiment utilizes the target execution node to determine the target storage location corresponding to the identification information of the target project within the server 10 after completing the execution of the target project, and stores the simulation test results in the target storage location, thereby enabling the orderly storage of data within the server 10.

[0075] In an optional embodiment, the target execution node is further configured to delete the local target project and simulation test results after storing the simulation test results.

[0076] As an example, considering the demand for autonomous driving simulation testing in massive application scenarios, the number of autonomous driving simulation test projects is enormous. Storing multiple autonomous driving simulation test projects and their simulation test results on a single device would consume a large amount of storage resources and affect device performance. Therefore, to improve the execution performance of execution nodes, they can be required to promptly delete the locally stored autonomous driving simulation test projects and their simulation test results after completing the execution of each project.

[0077] After the target execution node completes storing the simulation test results of the target project, it deletes the local target project and simulation test results.

[0078] In practical applications, the target execution node can obtain the project file of the target project from server 10, store the project file of the target project locally, and then delete the project file and simulation test results of the target project stored locally after completing the simulation test structure of the stored target project.

[0079] This application embodiment utilizes the method of deleting the local target project and its simulation test results after the target execution node has completed storing the simulation test results of the target project. This can promptly release the local storage space of the target execution node, avoid excessive local resource occupation of the target execution node, improve the operating performance of the target execution node, and thus further improve the simulation test efficiency of the autonomous driving system.

[0080] In an optional embodiment, the scheduling node is further configured to check the target data stored on the server 10 after completing the execution of multiple autonomous driving simulation test projects; wherein the target data includes the execution status of the multiple autonomous driving simulation test projects and / or the simulation test results of the multiple autonomous driving simulation test projects.

[0081] As an example, considering that the cluster simulation test system may experience abnormal operation problems caused by the aforementioned node hardware and software failures, as well as data anomalies caused by network instability, in order to address data anomalies, the target data associated with multiple autonomous driving simulation test projects can also be checked. The target data includes the execution status of multiple autonomous driving simulation test projects and / or the simulation test results of multiple autonomous driving simulation test projects.

[0082] After completing multiple autonomous driving simulation test projects, the scheduling node checks the target data stored on server 10.

[0083] In practical applications, the inspection items include any one or more of the following: checking whether the execution status of multiple autonomous driving simulation test projects is executed; checking whether the simulation test results of multiple autonomous driving simulation test projects are valid, for example, whether the storage time of the simulation test results of each autonomous driving simulation test project is within a valid period, such as within the most recent day; and checking whether the storage location of the simulation test results of multiple autonomous driving simulation test projects is correct.

[0084] In practical applications, after determining that the target data has failed the check, the scheduling node can also perform one or more of the following operations: instruct the server 10 to change the execution status of each autonomous driving simulation test project with an incorrect execution status to executed; instruct the server 10 to delete each invalid simulation test result, wherein the storage time of the invalid simulation test result is not within the valid time period and / or the storage location is incorrect, and change the execution status of the autonomous driving simulation test project corresponding to each invalid simulation test result to not executed, so that the scheduling node can subsequently reschedule these autonomous driving simulation test projects to the execution node for execution; instruct the server 10 to delete the simulation test results of multiple autonomous driving simulation test projects, and change the execution status of multiple autonomous driving simulation test projects to not executed.

[0085] This application embodiment utilizes a scheduling node to check the target data associated with multiple autonomous driving simulation test projects stored on server 10 after the execution of multiple autonomous driving simulation test projects. This ensures the accuracy of the entire autonomous driving system simulation test process and further improves the simulation test efficiency of the autonomous driving system.

[0086] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating a cluster simulation testing method for autonomous driving provided in the second embodiment of this application. The second embodiment of this application provides a cluster simulation testing method for autonomous driving, applied to an autonomous driving cluster simulation testing system. The system includes a server 10 and at least one cluster 20, each cluster 20 including a host 201 and at least one slave 202; the server 10 stores multiple autonomous driving simulation test projects; the method includes steps S1-S3: S1. Using the host 201 in each cluster 20, determine the scheduling node and at least one execution node for the host 201 and at least one slave 202 in the cluster 20; S2. Send the identification information of the target project to the target execution node through the scheduling node; wherein, the target execution node is any idle node among at least one execution node, and the target project is any unexecuted project among multiple autonomous driving simulation test projects; S3. Perform the following operations through the target execution node: The target item is retrieved from server 10 based on the identification information; Run the autonomous driving simulation test software deployed on the target execution node itself to execute the target project; After completing the execution of the target project, the simulation test results of the target project are stored on server 10.

[0087] In an optional embodiment, server 10 further stores the working status of hosts 201 and at least one slave 202 in each cluster 20, as well as the execution status of each autonomous driving simulation test project; the method further includes step S4: S4. Perform the following operations through the target execution node: After acquiring the target project, a first status update instruction is sent to server 10; wherein, the first status update instruction is used to instruct server 10 to update the working status of the target execution node from idle to busy, and to update the execution status of the target project from unexecuted to executing. After completing the execution of the target project, a second status update instruction is sent to server 10; wherein, the second status update instruction is used to instruct server 10 to update the working status of the target execution node from busy to idle, and to update the execution status of the target project from executing to executed.

[0088] In an optional embodiment, determining the scheduling node and at least one execution node for the host 201 and at least one slave 202 in the cluster 20 includes: determining the scheduling node and at least one execution node according to the node configuration information of the cluster 20; wherein the node configuration information is used to designate any device in the cluster 20 as the scheduling node, and all devices in the cluster 20 other than the device as at least one execution node.

[0089] In an optional embodiment, the method further includes steps S5-S6: S5. If any execution node in at least one execution node detects abnormal operation of the scheduling node, the first normally operating node in the cluster 20 after the scheduling node shall be determined as the new scheduling node according to the node election order of the cluster 20. S6. By using the scheduling node, if any execution node in at least one execution node is detected to be running abnormally, delete the current execution node in cluster 20, as well as the arrangement information of the current execution node in the deletion node recommendation order.

[0090] In an optional embodiment, the method further includes steps S7-S8: S7. Receive heartbeat packets sent by the calling node periodically through any of the at least one execution node. If the number of lost heartbeat packets or the duration of lost heartbeat packets exceeds the first threshold, it is determined that the scheduling node is operating abnormally. S8. Through the scheduling node, for each execution node in at least one execution node, the heartbeat packets sent by the execution node are received periodically. If the number of lost heartbeat packets or the duration of lost heartbeat packets exceeds the second threshold, it is determined that the execution node is running abnormally.

[0091] In an optional embodiment, the method further includes step S9: S9. By scheduling nodes, when the current execution node is busy, change the execution status of the autonomous driving simulation test project being executed by the current execution node to not being executed.

[0092] In an optional embodiment, storing the simulation test results of the target project in the server 10 includes: determining the target storage location within the server 10 corresponding to the identification information; and storing the simulation test results in the target storage location.

[0093] In an optional embodiment, the method further includes step S10: S10. After storing the simulation test results, delete the local target project and simulation test results through the target execution node.

[0094] In an optional embodiment, the method further includes step S11: S11. After completing the execution of multiple autonomous driving simulation test projects, the target data stored on server 10 is checked through the scheduling node; wherein, the target data includes the execution status of multiple autonomous driving simulation test projects, and / or, the simulation test results of multiple autonomous driving simulation test projects.

[0095] For details on the implementation process of each step in the above method, please refer to the implementation process of the corresponding device's function and role in the above system, which will not be repeated here.

[0096] Please refer to Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in the third embodiment of this application. The third embodiment of this application provides an electronic device 30, including a processor 301, a memory 302, and a computer program stored in the memory 302 and configured to be executed by the processor 301; when the processor 301 executes the computer program, it implements the method described in the second embodiment of this application and can achieve the same beneficial effects.

[0097] When the processor 301 reads a computer program from the memory 302 via the bus 303 and executes the computer program, it can implement the method described in the second embodiment of this application.

[0098] Processor 301 can process digital signals and may include various computing architectures. For example, it may be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 301 may be a microprocessor.

[0099] The memory 302 can be used to store instructions executed by the processor 301 or data related to the execution of instructions. These instructions and / or data may include code used to implement some or all of the functions of one or more modules described in the embodiments of this application. The processor 301 of this embodiment can be used to execute the instructions in the memory 302 to implement the method described in the second embodiment of this application. The memory 302 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memories well known to those skilled in the art.

[0100] The fourth embodiment of this application provides a computer program product including instructions that, when executed by a computer, cause the computer to perform the method described in the second embodiment of this application and achieve the same beneficial effects.

[0101] The methods described in the second embodiment of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the various embodiments of this application are executed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, a core network device, an OAM (Open Application Model), or other programmable devices.

[0102] The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions may be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium may be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; or an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0103] The fifth embodiment of this application provides a computer-readable storage medium, which includes a stored computer program; wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to perform the method described in the second embodiment of this application, and can achieve the same beneficial effects.

[0104] In summary, this application provides an autonomous driving cluster simulation test system, method, device, and program product. The autonomous driving cluster simulation test system includes a server 10 and at least one cluster 20. Each cluster 20 includes a host 201 and at least one slave 202. The server 10 stores multiple autonomous driving simulation test projects. The host 201 in each cluster 20 is used to determine a scheduling node and at least one execution node for the host 201 and at least one slave 202 in the cluster 20. The scheduling node is used to send the identification information of the target project to the target execution node. The target execution node is any idle node among the at least one execution node, and the target project is any unexecuted project among the multiple autonomous driving simulation test projects. The target execution node is used to: obtain the target project from the server 10 according to the identification information; run the autonomous driving simulation test software deployed by the target execution node itself to execute the target project; and store the simulation test results of the target project in the server 10 after completing the execution of the target project. This application embodiment addresses the needs of autonomous driving simulation testing in massive application scenarios by configuring a server 10 and at least one cluster 20. Multiple autonomous driving simulation test projects are stored within the server 10. Autonomous driving simulation test software is deployed in the host 201 and at least one slave 202 within each cluster 20. A distributed cluster simulation test system is established by combining the server 10 and at least one cluster 20. For each cluster 20, the host 201 determines a scheduling node and at least one execution node from itself and at least one slave 202. The scheduling node sends the identification information of any unexecuted target project among the multiple autonomous driving simulation test projects to any idle target execution node among the at least one execution node. The target execution node retrieves the target project from the server 10 based on the identification information, runs the autonomous driving simulation test software deployed on its own to execute the target project, and stores the simulation test results of the target project on the server 10 after completion. This distributed cluster simulation test system can utilize the various clusters 20 to jointly process autonomous driving simulation test projects in massive application scenarios, improving the simulation test efficiency of the autonomous driving system.

[0105] The above embodiments are merely illustrative examples. The various embodiments of this application can be combined or nested with each other, and this application is not limited thereto.

[0106] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0107] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0108] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0109] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0110] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0111] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A cluster simulation test system for autonomous driving, characterized in that, It includes a server and at least one cluster, each cluster including a host and at least one slave; the server stores multiple autonomous driving simulation test projects. Each host in the cluster is used to determine a scheduling node and at least one execution node for the hosts and at least one slave in the cluster; The scheduling node is used to send the identification information of the target project to the target execution node; wherein, the target execution node is any idle node among the at least one execution node, and the target project is any unexecuted project among the plurality of autonomous driving simulation test projects; The target execution node is used for: The target project is obtained from the server based on the identification information; Run the autonomous driving simulation test software deployed on the target execution node itself to execute the target project; After the target project is completed, the simulation test results of the target project are stored on the server.

2. The system according to claim 1, characterized in that, The server also stores the working status of the hosts and at least one slave in each cluster, as well as the execution status of each autonomous driving simulation test project. The target execution node is also used for: After obtaining the target project, a first status update instruction is sent to the server; wherein, the first status update instruction is used to instruct the server to update the working status of the target execution node from idle to busy, and to update the execution status of the target project from never executed to executing. After completing the execution of the target project, a second status update instruction is sent to the server; wherein, the second status update instruction is used to instruct the server to update the working status of the target execution node from busy to idle, and to update the execution status of the target project from executing to executed.

3. The system according to claim 1, characterized in that, The step of determining the scheduling node and at least one execution node for the host and at least one slave in the cluster includes: Based on the node configuration information of the cluster, the scheduling node and the at least one execution node are determined; wherein, the node configuration information is used to designate any device in the cluster as the scheduling node, and all devices in the cluster other than the specified device as the at least one execution node.

4. The system according to claim 1, characterized in that, Any of the at least one execution node is further configured to, in the event of detecting abnormal operation of the scheduling node, determine the first normally operating node in the cluster after the scheduling node as the new scheduling node according to the node recommendation order of the cluster. The scheduling node is also configured to delete the current execution node in the cluster and delete the arrangement information of the current execution node in the node recommendation order when it detects that any execution node among the at least one execution node is running abnormally.

5. The system according to claim 4, characterized in that, Any of the at least one execution node is also used to periodically receive heartbeat packets sent by the calling node. If the number of lost heartbeat packets or the duration of lost heartbeat packets exceeds a first threshold, it is determined that the scheduling node is operating abnormally. The scheduling node is also configured to periodically receive heartbeat packets sent by each of the at least one execution node. If the number of lost heartbeat packets or the duration of lost heartbeat packets exceeds a second threshold, the execution node is determined to be operating abnormally.

6. The system according to claim 4, characterized in that, The scheduling node is also used to change the execution status of the autonomous driving simulation test project being executed by the current execution node to not being executed when the current execution node is busy.

7. The system according to claim 1, characterized in that, The step of storing the simulation test results of the target project on the server includes: Determine the target storage location within the server corresponding to the identification information; The simulation test results are stored in the target storage location.

8. The system according to claim 1, characterized in that, The target execution node is also configured to delete the target project and the simulation test results locally after storing the simulation test results.

9. The system according to claim 1, characterized in that, The scheduling node is further configured to check the target data stored on the server after completing the execution of the plurality of autonomous driving simulation test projects; wherein the target data includes the execution status of the plurality of autonomous driving simulation test projects and / or the simulation test results of the plurality of autonomous driving simulation test projects.

10. A cluster simulation testing method for autonomous driving, characterized in that, A cluster simulation test system for autonomous driving, the system comprising a server and at least one cluster, each cluster comprising a host and at least one slave. The server stores multiple autonomous driving simulation test projects; the method includes: Using the hosts in each cluster, for each host and at least one slave in the cluster, determine the scheduling node and at least one execution node; The scheduling node sends the identification information of the target project to the target execution node; wherein, the target execution node is any idle node among the at least one execution node, and the target project is any unexecuted project among the plurality of autonomous driving simulation test projects; Perform the following operations through the target execution node: The target project is obtained from the server based on the identification information; Run the autonomous driving simulation test software deployed on the target execution node itself to execute the target project; After the target project is completed, the simulation test results of the target project are stored on the server.

11. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor; when the processor executes the computer program, it implements the method according to claim 10.

12. A computer program product, characterized in that, The computer program product includes instructions that, when executed by a computer, cause the computer to perform the method according to claim 10.

Images