Automatic testing method and device for automatic driving simulation and electronic equipment

Abstract

The invention provides an automatic testing method and device for automatic driving simulation and electronic equipment, and relates to the technical field of automatic driving simulation tests.The method comprises the steps that after a test case management module sends a control instruction to a simulation environment module, preset path point information is input into an automatic driving algorithm module; the simulation environment module loads a test scene according to the control instruction; and the simulation environment module performs testing according to the test scene and a driving route determined by the automatic driving algorithm module based on the path point information to obtain simulation test data, and determines a test result based on the simulation test data. According to the application, the test case management module is linked with the simulation environment module to load a scene and input path points to the algorithm module, so that the automation of the whole test process is realized, the test efficiency is remarkably improved, and personal errors are reduced; scene library verification and evaluation index verification can be synchronously completed, it is ensured that a test scene is complete, indexes are reasonable, and test effectiveness is guaranteed.

Description

Technical Field

[0001] This application relates to the field of autonomous driving simulation testing technology, and more specifically, to an automated testing method, apparatus, and electronic device for autonomous driving simulation. Background Technology

[0002] With the development of autonomous driving technology, simulation testing has become a crucial step in verifying the safety and reliability of algorithms. Currently, mainstream testing methods rely on manual operation: engineers must sequentially launch planning, control, and routing algorithm modules through a visual interface, manually selecting test maps and configuring vehicle trajectory points. This approach has significant drawbacks: First, it is cumbersome and inefficient, requiring repeated button clicks for each test, making it difficult to achieve large-scale scene coverage; second, it carries a high risk of human error, easily leading to distorted test results due to improper operation; finally, the testing process is not reproducible, and manual operation makes it difficult to ensure that the initial conditions are completely consistent for each test, affecting the reliability of the verification results. While existing technologies can complete basic verification, they cannot meet the growing demand for automated, high-concurrency testing. Especially when performing regression testing or verifying evaluation metrics on complex scene libraries, traditional methods are time-consuming and labor-intensive, becoming a bottleneck restricting development efficiency. Summary of the Invention

[0003] The purpose of this application is to provide an automated testing method, device, and electronic device for autonomous driving simulation, which solves the above-mentioned problems existing in the prior art. It can achieve one-click testing through an automated script toolchain, significantly improve testing efficiency and consistency, reduce human error, and support efficient verification of scenario libraries and evaluation indicators.

[0004] Firstly, an automated testing method for autonomous driving simulation is provided, applicable to a testing system including a test case management module, a simulation environment module, and an autonomous driving algorithm module; the method may include: After the test case management module sends control commands to the simulation environment module, it inputs preset path point information into the autonomous driving algorithm module. The simulation environment module loads the test scenario according to the control command; The simulation environment module performs tests based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the waypoint information, obtains simulation test data, and determines the test results based on the simulation test data.

[0005] In one possible implementation, preset path point information is input to the autonomous driving algorithm module, including: The test case management module calls a preset path injection script, which sends path point information containing at least one preset start point coordinate and a preset end point coordinate to the routing request interface of the autonomous driving algorithm module, so that the autonomous driving algorithm module can generate a driving route based on the path point information.

[0006] In one possible implementation, before the path injection script sends the path point information to the routing request interface of the autonomous driving algorithm module, the method further includes: The path injection script performs a format conversion on the start-point and end-point coordinates to obtain the start-point and end-point coordinates in the target format.

[0007] In one possible implementation, after the simulation environment module loads the test scenario according to the control instructions, the method further includes: The simulation environment module initializes the environmental parameters corresponding to the test scenario according to the environment configuration instructions sent by the test case management module; the environmental parameters include at least one of weather conditions, light intensity, road sign information, and virtual traffic participant attributes.

[0008] In one possible implementation, before the simulation environment module performs the test based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the waypoint information, the method further includes: The test case management module calls the algorithm startup script, which triggers the autonomous driving algorithm module to load a preset algorithm configuration file and automatically starts the autonomous driving algorithm module; the autonomous driving algorithm module includes a planning submodule, a control submodule, and a perception submodule.

[0009] In one possible implementation, determining the test results based on the simulation test data includes: The test case management module extracts the actual values ​​of preset evaluation indicators from the simulation test data. The preset evaluation indicators include at least one of path tracking accuracy, obstacle collision avoidance success rate, vehicle speed control stability, and traffic rule compliance rate. If the actual value meets the preset threshold, the test result is determined to be passed.

[0010] In one possible implementation, during the testing process by the simulation environment module based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the waypoint information, the method further includes: The test case management module receives scene status data sent by the simulation environment module and running status data sent by the autonomous driving algorithm module in real time, and verifies the scene status data and running status data respectively to obtain verification results; the scene status data includes dynamic change information of virtual roads, and the running status data includes internal running parameters determined by the autonomous driving algorithm module.

[0011] Secondly, an automated testing device for autonomous driving simulation is provided, applied to a testing system including a test case management module, a simulation environment module, and an autonomous driving algorithm module; the device may include: The input unit is used to input preset path point information into the autonomous driving algorithm module after the test case management module sends control commands to the simulation environment module; The loading unit is used by the simulation environment module to load the test scenario according to the control command; The testing unit is used by the simulation environment module to conduct tests based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the waypoint information, to obtain simulation test data, and to determine the test results based on the simulation test data.

[0012] Thirdly, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements any of the steps described in the first aspect above.

[0013] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of any of the methods described in the first aspect above.

[0014] This application provides an automated testing method, apparatus, and electronic device for autonomous driving simulation. The method includes: a test case management module sending control commands to a simulation environment module and then inputting preset path point information into an autonomous driving algorithm module; the simulation environment module loading a test scenario according to the control commands; the simulation environment module performing tests based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the path point information, obtaining simulation test data, and determining test results based on the simulation test data. This application avoids the problems of low efficiency and error-proneness of traditional manual operations (such as manually opening the autonomous driving algorithm module and selecting test maps and trajectory points). By linking the test case management module with the simulation environment module to load scenarios and input path points into the autonomous driving algorithm module, the entire testing process is automated, significantly improving testing efficiency and reducing human error. It can also simultaneously complete scenario library verification and evaluation index verification, ensuring the completeness of test scenarios and the rationality of indicators, guaranteeing the effectiveness of testing, and ultimately accelerating the development and verification process of autonomous driving algorithms, providing efficient support for technology implementation. Attached Figure Description

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

[0016] Figure 1 A system architecture diagram of an automated testing method for autonomous driving simulation provided in this application embodiment; Figure 2 A flowchart illustrating an automated testing method for autonomous driving simulation provided in this application embodiment; Figure 3 A flowchart illustrating an automated testing method for autonomous driving simulation provided in this application embodiment; Figure 4 A schematic diagram of the structure of an automated testing device for autonomous driving simulation provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] 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 a part of the embodiments of this application, and not all of the 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.

[0018] The automated testing method for autonomous driving simulation provided in this application embodiment can be applied to... Figure 1 In the system architecture shown, such as Figure 1 As shown, the system may include a processor and a testing system.

[0019] The testing system includes a test case management module, a simulation environment module, and an autonomous driving algorithm module; The processor is used to execute an automated testing method for autonomous driving simulation provided in this application.

[0020] With the development of autonomous driving technology, simulation testing has become a crucial step in verifying the safety and reliability of algorithms. Currently, mainstream testing methods rely on manual operation: engineers must sequentially launch autonomous driving algorithm modules such as planning, control, and routing through a visual interface, manually selecting test maps and configuring vehicle trajectory points. This approach has significant drawbacks: First, it is cumbersome and inefficient, requiring repeated button clicks for each test, making it difficult to achieve large-scale scene coverage; second, it carries a high risk of human error, easily leading to distorted test results due to improper operation; finally, the testing process is not reproducible, and manual operation makes it difficult to ensure that the initial conditions are completely consistent for each test, affecting the reliability of the verification results. While existing technologies (such as manual testing schemes based on a single simulation platform) can complete basic verification, they cannot meet the growing demand for automated, high-concurrency testing. Especially when performing regression testing or verifying evaluation metrics on complex scene libraries, traditional methods are time-consuming and labor-intensive, becoming a bottleneck restricting development efficiency.

[0021] Therefore, this application provides an automated testing method for autonomous driving simulation, which solves the above-mentioned problems in the prior art. It can achieve one-click testing through an automated script toolchain, significantly improve testing efficiency and consistency, reduce human error, and support efficient verification of scenario libraries and evaluation indicators.

[0022] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0023] Figure 2This is a flowchart illustrating an automated testing method for autonomous driving simulation provided in an embodiment of this application. Figure 2 and Figure 3 As shown, this method is applied to a test system that includes a test case management module, a simulation environment module, and an autonomous driving algorithm module. The method may include: Step S210: After the test case management module sends control commands to the simulation environment module, it inputs preset path point information to the autonomous driving algorithm module.

[0024] Specifically, this step is based on the fact that the simulation environment module (VTD) has completed the loading of the test scenario according to the previous control instructions. The test case management module (ECU-test) running on the Windows operating system injects the preset path point information into the autonomous driving algorithm module (such as Apollo) deployed on the Linux operating system through automated scheduling.

[0025] This step may specifically include: the test case management module triggering the autonomous driving algorithm module to start, and then inputting preset path point information into the autonomous driving algorithm module; The test case management module establishes a communication connection with the Linux system where the autonomous driving algorithm module is located through a preset remote connection protocol (SSH protocol); the test case management module calls the preset algorithm startup script (start_apollo script). Step 1: Trigger the startup of the autonomous driving algorithm module; The test case management module calls the algorithm startup script, which triggers the autonomous driving algorithm module to load the preset algorithm configuration file and automatically start the autonomous driving algorithm module. The autonomous driving algorithm module includes a planning submodule, a control submodule, and a perception submodule.

[0026] The algorithm startup script performs the following operations: Load the preset algorithm configuration file (apollo.rc configuration file), and read the container identification parameters required for the autonomous driving algorithm module to run (i.e., APOLLO_CONTAINER=apollo_dev_${USER}, which determines the name of the Docker container in which the algorithm runs). The Docker container is entered using the command `docker exec -u ${USER}${APOLLO_CONTAINER} / apollo / set_map$1`, and a test map matching the current test scenario is loaded ($1 is the map parameter, such as UrbanRoad_TwonLane_LaneWidth3point5, which is a map of a two-lane city road with a lane width of 3.5 meters). The sub-startup script (start_apollo.sh) within the container is invoked to automatically start the planning, control, and perception sub-modules included in the autonomous driving algorithm module (specifically, the launch files of each sub-module are started via the cyber_launch start command, such as planning.launch and control.launch). At the same time, the data interaction sub-modules between the algorithm module and the simulation environment module (gateway modules such as vtdobstaclestrafficlightgateway_groundtruthvtdlocalizationgateway, etc.) are started to ensure that the autonomous driving algorithm module has the ability to receive path point information and interact with the simulation environment.

[0027] Step 2: Call the path injection script and trigger coordinate processing; After all sub-modules of the autonomous driving algorithm module have started (set the waiting time to 6 seconds to ensure stable module initialization), the test case management module calls the preset path injection scripts (send_dest series scripts, including the outer send_dest script, the middle send_dest.sh script, and the core send_dest.py script). The path injection scripts process the preset start and end coordinates according to the following process: The test case management module calls a pre-defined path injection script (e.g., send_dest). The path injection script, as a key component for automation, contains a series of executable instructions.

[0028] In some embodiments, inputting preset waypoint information into the autonomous driving algorithm module includes: The test case management module calls a preset path injection script, which sends path point information containing at least one preset start point coordinate and a preset end point coordinate to the routing request interface of the autonomous driving algorithm module, so that the autonomous driving algorithm module can generate a driving route based on the path point information.

[0029] Before the path injection script sends the waypoint information to the routing request interface of the autonomous driving algorithm module, the method also includes: The path injection script converts the start and end coordinates to the target format. For example, it converts the relative or simulated coordinates set in the test case into coordinate parameters in the global coordinate system that can be recognized by the routing service inside the autonomous driving algorithm module (the specific implementation may include a calculation process of adding to a specific offset).

[0030] Furthermore, the outer script triggers (cross-environment call): the test case management module executes the outer send_dest script. This script first loads the apollo.rc configuration file, reads the Docker container identifier where the autonomous driving algorithm module is located, and then passes the preset start-point coordinate parameters and end-point coordinate parameters as input parameters to the middle-level send_dest.sh script in the Docker container through the docker exec -u${USER}${APOLLO_CONTAINER} / apollo / send_dest.sh$@ command. Mid-level script environment configuration: The mid-level send_dest.sh script is executed inside a Docker container. First, it loads the communication framework environment of the autonomous driving algorithm module ( / apollo / cyber / setup.bash, i.e., the Cyber ​​communication framework) and sets the Python running path (export PYTHONPATH=$PYTHONPATH: / apollo / bazel-bin) to ensure that the core Python script can call the communication interface and data format definition file of the algorithm module. Once the core send_dest.py script is triggered, it reads the input start and end coordinates and performs format conversion: it overlays the x-axis value of the start coordinates with a preset first offset parameter, and overlays the y-axis value of the start coordinates with a preset second offset parameter to obtain the target format start coordinates; it then uses the same offset calculation method to convert the end coordinates to obtain the target format end coordinates; the preset first and second offset parameters are fixed values ​​that match the coordinate system of the test map, used to convert the simplified input coordinates into absolute coordinate system coordinates that can be recognized by the autonomous driving algorithm module.

[0031] Step 3: Send waypoint information to the autonomous driving algorithm module; After completing the coordinate format conversion, the path injection script (send_dest.py script) sends the path point information to the routing request interface of the autonomous driving algorithm module according to the following process: The script `send_dest.py` initializes the Cyber ​​communication framework (`cyber.init()`), creates a dedicated communication node `ftx_send_dest`, and creates two data receiving interfaces (readers) based on this node: one for receiving real-time positioning data from the autonomous driving algorithm module (topic: ` / apollo / localization / pose`, data format: `LocalizationEstimate`), obtaining the current virtual vehicle position of the autonomous driving algorithm module (i.e., the actual starting position, used for calibration with the input preset starting coordinates); the other for receiving routing response data from the autonomous driving algorithm module (topic: ` / apollo / routing_response`, data format: `RoutingResponse`), confirming whether the waypoint information has been successfully received; simultaneously, a data sending interface (writer) is created based on this node to send waypoint information to the autonomous driving algorithm module's routing request interface (topic: ` / apollo / routing_request`, data format: `RoutingRequest`). Assemble and send waypoint information: After the send_dest.py script obtains the real-time location of the virtual vehicle through the positioning data receiving interface, it creates a waypoint information message in RoutingRequest format. The start coordinates and end coordinates of the target format are added to the waypoint field of the message according to the LaneWaypoint data structure (including x-axis and y-axis coordinate parameters) to form complete waypoint information. The message is then sent to the routing request interface of the autonomous driving algorithm module through the data sending interface. Confirm sending result and exit: After the send_dest.py script obtains the RoutingResponse message returned by the autonomous driving algorithm module through the routing response data receiving interface (that is, the autonomous driving algorithm module confirms that the waypoint information has been received), it outputs a log of successful waypoint information sending (print("RoutingResponse received",flush=True)) and automatically exits the script, completing the entire waypoint information input process.

[0032] Step S220: The simulation environment module loads the test scenario according to the control instructions.

[0033] Specifically, the test case management module (ECU-test) sends control commands containing target test scenario identifiers to the simulation environment module (VTD) based on a preset cross-system communication protocol (SCP message transmission protocol that supports remote control). The target test scenario identifier is a unique code that corresponds one-to-one with a scenario in the preset scenario library (e.g., UrbanRoad_TwoLane_001 represents the basic urban two-lane scenario, and Highway_Merge_003 represents the highway merging scenario), which is used by VTD to accurately locate the scenario file to be loaded.

[0034] After receiving the control command, the simulation environment module (VTD) decodes the target test scene identifier through the built-in command parsing module, and locates the corresponding scene data package (including scene topology, basic road model, initial static elements, etc.) from the local scene storage path (such as / vtd / Scenarios / ) according to the identifier, in preparation for subsequent loading.

[0035] Next, the simulation environment module (VTD) calls the built-in scene loading engine to read the located scene data package and load the scene in the order of road model, static elements, and initial boundary conditions: first, it loads the physical road model corresponding to the test scene (such as the number of lanes, lane width, road curvature, etc., for example: UrbanRoad_TwonLane_LaneWidth3point5 corresponds to a two-lane 3.5-meter-wide road model); then, it loads the static elements on both sides of the road (such as curbs, guardrails, traffic sign poles, and other basic static facilities); finally, it loads the initial boundary conditions of the scene (such as initial timestamps and basic coordinate system parameters).

[0036] Considering that the scene data package contains complex road topology and static element data, in order to avoid parameter configuration failure due to incomplete scene loading during subsequent environment parameter initialization, the simulation environment module (VTD) automatically triggers a preset waiting mechanism after starting loading, setting an 18-second waiting time (this time has been verified through multiple tests and can cover 99% of the scene loading time). During the waiting period, the scene loading progress is monitored in real time (e.g., by judging through the completion rate of road model vertex rendering and the number of static elements loaded). When the loading progress reaches 100% and there are no loading errors, the scene loading is determined to be complete.

[0037] After that, once the simulation environment module (VTD) has finished loading the test scenario, it sends a status message (based on the SCP protocol) to the test case management module (ECU-test) to indicate that the scenario loading is complete. Upon receiving this feedback, the test case management module (ECU-test) generates an environment configuration instruction containing a list of environment parameter configurations based on the requirements of the current test case (such as urban road testing in rainy weather at night and highway testing during peak hours in sunny weather), and sends it to the simulation environment module (VTD) again via an SCP message.

[0038] After receiving the environment configuration command, the simulation environment module (VTD) parses the environment parameter configuration list and extracts the specific configuration values ​​for each environment parameter; this configuration list includes the following configurable dimensions: Weather conditions: Rainy days correspond to rainfall intensity parameters (e.g., 5mm / h, representing light rain), snowy days correspond to snow depth parameters (e.g., 3cm), and foggy days correspond to visibility parameters (e.g., 200m). Light intensity: includes the direction of light source (e.g., azimuth angle 120°, elevation angle 60°, simulating the direction of sunlight at 3 pm), light intensity value (e.g., 8000 lux, simulating midday sunlight on a sunny day), and light attenuation coefficient (e.g., 0.8, simulating reduced light on a cloudy day). Road signage information includes lane line type (e.g., solid line, dashed line, corresponding line width 15cm), speed limit sign value (e.g., 60km / h), intersection directional signs (e.g., left turn and straight lane configuration), and road edge warning signs (e.g., reflective guardrails). Virtual traffic participant attributes include participant type (e.g., small cars, large trucks, and electric bicycles), initial position coordinates (e.g., right lane of the road, x=166025.3, y=10000008.5), initial driving speed (e.g., 40km / h for small cars, 30km / h for large trucks), and driving behavior mode (e.g., constant speed driving, following other vehicles, and waiting at intersections). Additional environmental parameters include simulation observation perspective parameters (such as third-person perspective, height 10m, distance from virtual test vehicle 20m, used for visual monitoring during the test) and initial state of traffic signals (such as red light at an intersection, remaining duration 5 seconds).

[0039] The method also includes: The simulation environment module initializes the environmental parameters corresponding to the test scenario according to the environment configuration instructions sent by the test case management module; the environmental parameters include at least one of weather conditions, light intensity, road sign information, and virtual traffic participant attributes.

[0040] The simulation environment module (VTD) uses the parsed environment parameter configuration list as a basis to call the built-in environment parameter initialization engine. It performs initialization in the order of basic environment, road elements, dynamic participants, and monitoring perspective, with the specific operations as follows: Basic environmental parameter initialization: First, initialize the weather and lighting conditions. By calling the VTD's WeatherControl interface, write parameters such as rainfall intensity, snow thickness, and visibility into the scene's weather control module. Then, call the LightingControl interface to set the lighting direction, intensity value, and attenuation coefficient to ensure that the lighting effect matches the scene time (e.g., nighttime corresponding to a light intensity ≤500 lux).

[0041] Road sign parameter initialization: Call the VTD's RoadSignControl interface to render lane lines, speed limit signs, directional signs, etc. at the preset road positions in the scene according to the configuration list. For example, at the intersection of a two-lane urban scene, render left turn and straight directional arrows (arrow length 3m, width 0.5m), and hang a 60km / h speed limit sign (sign size 1.2m×0.8m) on the right side of the road guardrail.

[0042] Virtual traffic participant initialization: Call the TrafficParticipantControl interface of VTD to create virtual traffic participant instances according to the configuration list. For example, create 3 small cars (vehicle parameters are 4.5m in length and 1.8m in width) and deploy them in the left and right lanes of the road and the waiting area at the intersection. Set their initial speed and driving mode (e.g., the car in the leftmost lane travels at a constant speed of 60km / h, and the car in the waiting area at the intersection waits at 0km / h at the red light).

[0043] Initialize the monitoring view and traffic signals: Call the VTD's ViewControl interface to adjust the observation view to the preset third-person monitoring view and lock the virtual test vehicle (to ensure that the view moves synchronously with the vehicle's movement); at the same time, call the TrafficLightControl interface to set the initial state of the intersection traffic signals (such as switching from red light to green light after 5 seconds) to prepare for the dynamic interaction of subsequent simulation tests.

[0044] In some embodiments, after the environmental parameters are initialized, the simulation environment module (VTD) automatically performs parameter validity verification: The built-in verification module checks whether each environmental parameter is compatible with the scene (e.g., speed limit sign ≥60km / h in high-speed scenes, light intensity ≤500lux in night scenes). If there is a parameter conflict (e.g., 0mm / h rainfall intensity is configured in rainy weather), the parameter abnormality prompt will be automatically returned to the test case management module (ECU-test) for reconfiguration. If the self-test passes, the simulation environment module (VTD) generates a status message indicating that the environment parameters have been initialized, including the actual configuration values ​​of each parameter (e.g., weather: light rain, illumination: 8000 lux, virtual participants: 3 cars), and sends it to the test case management module (ECU-test). After the test case management module (ECU-test) returns an instruction to allow the simulation to start, the simulation environment module (VTD) enters the test-ready state, waiting for the joint simulation to be triggered with the autonomous driving algorithm module.

[0045] Step S230: The simulation environment module performs tests based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the waypoint information, obtains simulation test data, and determines the test results based on the simulation test data.

[0046] First, the test case management module (ECU-test running on the Windows system) confirms that the simulation environment module has completed loading the scenario and initializing the environment parameters, and that the autonomous driving algorithm module has received the path point information and generated the driving route. Then, it sends a start co-simulation command to the simulation environment module (VTD) via SCP message, and at the same time sends a start driving control command to the Docker container of the autonomous driving algorithm module via SSH protocol to ensure that the two start the test synchronously.

[0047] After receiving the instruction, the simulation environment module (VTD) activates the real-time data interaction link with the autonomous driving algorithm module. Based on the Cyber ​​communication framework, the VTD sends dynamic scene data (such as changes in the position of virtual obstacles and traffic light status switching) to the autonomous driving algorithm module in real time through modules such as vtdobstaclestrafficlightgateway_groundtruth (obstacle / traffic light gateway) and vtdlocalizationgateway (location gateway). The autonomous driving algorithm module, in turn, feeds back vehicle control instructions (such as acceleration / deceleration signals and steering angles) to the VTD in real time through vtdchassisgateway (chassis gateway).

[0048] To avoid test deviations caused by asynchronous module startup, the test case management module (ECU-test) is set to a 1-second synchronization wait time. Once the data interaction frequency between VTD and the autonomous driving algorithm module is stabilized at 1Hz, the joint simulation test is determined to have officially entered the stable execution phase.

[0049] Secondly, the simulation environment module (VTD) sends scenario state data to the test case management module (ECU-test) via SCP messages at a frequency of 1Hz; for example, the dynamic change information of virtual roads, specifically: Dynamic adjustment of virtual road topology (such as changes in the location of temporary road occupancy areas and temporary disappearance of lane lines to simulate construction scenarios). The state of dynamic elements within the scene (such as the real-time location / speed / direction of virtual traffic participants, the switching state of traffic lights (red, green, or yellow), and the location and size of sudden obstacles (such as falling objects); Simulation operation data of the virtual test vehicle (real-time vehicle position coordinates, speed, acceleration, steering angle, brake pedal opening, etc. recorded by the VTD terminal).

[0050] The autonomous driving algorithm module sends runtime status data to the test case management module (ECU-test) at a frequency of 1Hz via the SSH protocol; for example, the internal runtime parameters of the autonomous driving algorithm module are as follows: The running status of the algorithm submodule (real-time trajectory output coordinates of the planning submodule, calculated values ​​of control commands from the control submodule, and obstacle recognition results from the perception submodule (such as the type / location / distance of the recognized obstacles)); Algorithm computational resource load (CPU utilization within Docker containers (e.g., CPU usage of 30% during the planning submodule runtime), memory usage (e.g., memory usage of 2GB after loading the map), Cyber ​​node communication latency (e.g., sending and receiving routing request messages with a latency of ≤50ms)). Path tracking deviation data (the calculated deviation between the actual driving trajectory and the preset driving route, such as x-axis deviation of 0.2m and y-axis deviation of 0.1m).

[0051] In some embodiments, during the testing process where the simulation environment module performs tests based on the test scenario and the driving route determined by the autonomous driving algorithm module based on waypoint information, the method further includes: The test case management module receives scene status data sent by the simulation environment module and running status data sent by the autonomous driving algorithm module in real time, and verifies the scene status data and running status data respectively to obtain the verification results. The scene status data includes the dynamic change information of the virtual road, and the running status data includes the internal running parameters determined by the autonomous driving algorithm module.

[0052] Scene status data verification includes checking whether the scene status data sent by VTD contains three core types of information: virtual road dynamic changes, traffic participant status, and vehicle simulation data. If any one of these is missing, the scene data is determined to be incomplete, triggering a remedial mechanism that pauses the test and requests VTD to resend the data. The system determines whether the data conforms to physical logic based on preset rules. For example, the speed of the virtual test vehicle must not exceed the scene speed limit sign value (e.g., ≤60km / h on urban roads) and the traffic light switching interval must not be less than 3 seconds. If there is data anomaly (e.g., the vehicle speed instantaneously reaches 100km / h), the scene data anomaly log is recorded (storage path such as / ECU-test / log / scene_error_2024xx.log), and subsequent data is continuously monitored to see if it returns to normal.

[0053] Operational status data verification includes: The position of the virtual test vehicle fed back by the autonomous driving algorithm module is compared with the simulated vehicle position sent by VTD. If the difference between the two exceeds 0.5 meters, it is determined that the autonomous driving algorithm module is inconsistent with the scene positioning, and the autonomous driving algorithm module is triggered to recalibrate the positioning. At the same time, the position of the obstacle identified by the algorithm perception submodule is compared with the position of the scene obstacle sent by VTD. If the difference exceeds 0.3 meters, it is determined that the perception deviation exceeds the standard, and the deviation data is recorded for subsequent analysis. Monitor the CPU usage (threshold ≤ 80%) and memory usage (threshold ≤ 4GB) of the autonomous driving algorithm module. If the threshold is exceeded, it is determined that the algorithm's computational load is too high, which may lead to delays in control commands. At this time, the test case management module (ECU-test) sends an instruction to the autonomous driving algorithm module to reduce the priority of non-core sub-modules (such as reducing the computation frequency of the prediction sub-module) to ensure the stability of the core control function.

[0054] The test case management module (ECU-test) stores the real-time verification results (data normal or data abnormal and type) in the form of logs in real time, and displays them synchronously through a visual interface, so that testers can monitor the test status in real time. If the data is abnormal for 3 consecutive verifications, the test will be automatically paused to avoid wasting resources on ineffective tests.

[0055] Subsequently, the test case management module (ECU-test) triggers a stop test command when any of the following conditions are met: The virtual test vehicle reached the destination along the preset driving route (VTD detected that the deviation between the vehicle position and the destination coordinates in the waypoint information was ≤0.2 meters). The test duration reaches the preset value (e.g., 300 seconds for a single-scenario test). Serious anomalies occur (judged based on data verification results, such as autonomous driving algorithm module crash or VTD scene freeze, judged based on data verification results).

[0056] The test case management module (ECU-test) sends a stop scene execution command to the VTD via SCP messages and a stop control command output command to the autonomous driving algorithm module via the SSH protocol. After the VTD reports that the scene has stopped and the autonomous driving algorithm module reports that the control has been paused, it performs cleanup operations: shuts down the VTD's scene rendering engine and stops the Docker container of the autonomous driving algorithm module (command such as docker stop${APOLLO_CONTAINER}) to avoid continuous resource occupation.

[0057] The test case management module (ECU-test) extracts and summarizes complete simulation test data from the VTD scenario data storage path (e.g., / vtd / data / simulation_2024xx.csv) and the autonomous driving algorithm module log storage path (e.g., / apollo / data / log / test_data_2024xx.log). The data types include: The test included recording of dynamic scene changes throughout the entire process, trajectories of virtual traffic participants, traffic light switching timing, and vehicle simulation data (speed / position / attitude timing sequence) from the VTD terminal. The algorithm submodule output records throughout the test (planning trajectory timing, control command timing, perception result timing), algorithm calculation load timing data, and path tracking deviation timing data; Records of data anomalies and deviations exceeding limits during real-time verification.

[0058] Finally, based on the simulation test data, the test results are determined, including: The test case management module extracts the actual values ​​of preset evaluation indicators from the simulation test data. The preset evaluation indicators include at least one of path tracking accuracy, obstacle collision avoidance success rate, vehicle speed control stability, and traffic rule compliance rate. If the actual value meets the preset threshold, the test result is determined to be passed.

[0059] Extract the Euclidean distance between the coordinates of the algorithm-planned trajectory and the actual driving trajectory coordinates of the vehicle at the VTD end throughout the test, and calculate the average deviation (i.e., the actual value) of all sampling points, for example, an average deviation of 0.2 meters; Count the total number of obstacles in the VTD scenario (e.g., 10) and the number of obstacles that the autonomous driving algorithm module successfully avoids by "deceleration / steering" (e.g., 9), and calculate the success rate (9 / 10=90%, i.e., the actual value). Extract the speed time series data of the virtual test vehicle throughout the test process, and calculate the standard deviation of speed fluctuation (e.g., a standard deviation of 2.5 km / h, which is the actual value). The smaller the standard deviation, the more stable the speed control. The number of times traffic rules are triggered in the statistical scenario (e.g., stopping at red lights and complying with speed limits, a total of 8 times), and the number of times the autonomous driving algorithm module actually complies with them (e.g., 7 times), are used to calculate the compliance rate (7 / 8=87.5%, i.e., the actual value).

[0060] The preset threshold is set based on industry standards and algorithm requirements, for example: Path tracking accuracy threshold: ≤0.5 meters; Obstacle collision avoidance success rate threshold: ≥90%; Vehicle speed control stability threshold: ≤3km / h; Traffic rule compliance rate threshold: ≥85%.

[0061] Threshold comparison and result determination: If the actual values ​​of all evaluation indicators meet the corresponding preset thresholds (such as path tracking accuracy 0.2m ≤ 0.5m, collision avoidance success rate 90% ≥ 90%, speed standard deviation 2.5km / h ≤ 3km / h, compliance rate 87.5% ≥ 85%), then the test result is considered to be passed. If the actual value of any indicator does not meet the threshold (e.g., collision avoidance success rate 80% < 90%), the test result is determined to be unsuccessful, and a failure analysis report is generated to clarify the specific deviation of the unsuccessful indicator (e.g., the 5th obstacle was not avoided because the perception submodule did not identify the static obstacle). The test case management module (ECU-test) outputs a test report (formatted as PDF / Excel) containing test results, actual values ​​of each metric, thresholds, and exception logs. Simultaneously, in conjunction with the requirement to validate the existing scenario library, the test results are supplemented with scenario library validation results, namely the loading success rate (100%), operational stability (no crashes), and data integrity (no missing data) of the scenarios used in this test. If the scenario library validation passes, the overall test results are valid; if the scenario library validation fails (e.g., scenario loading crashes), the test must be repeated.

[0062] This application provides an automated testing method for autonomous driving simulation. The method includes: a test case management module sending control commands to a simulation environment module and then inputting preset path point information into an autonomous driving algorithm module; the simulation environment module loading a test scenario according to the control commands; the simulation environment module performing tests based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the path point information, obtaining simulation test data, and determining the test results based on the simulation test data. This application avoids the inefficiency and error-prone nature of traditional manual operations (such as manually opening the autonomous driving algorithm module and selecting test maps and trajectory points). By linking the test case management module with the simulation environment module to load scenarios and input path points into the autonomous driving algorithm module, the entire testing process is automated, significantly improving testing efficiency and reducing human error. It can also simultaneously complete scenario library verification and evaluation index verification, ensuring the completeness of test scenarios and the rationality of indicators, guaranteeing test effectiveness, and ultimately accelerating the development and verification process of autonomous driving algorithms, providing efficient support for technology implementation.

[0063] Corresponding to the above method, this application also provides an automated testing device for autonomous driving simulation, applied to a testing system including a test case management module, a simulation environment module, and an autonomous driving algorithm module; such as Figure 4 As shown, the device includes: The input unit 410 is used to input preset path point information into the autonomous driving algorithm module after the test case management module sends control commands to the simulation environment module; Loading unit 420 is used by the simulation environment module to load the test scenario according to the control command; The test unit 430 is used by the simulation environment module to perform tests based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the waypoint information, to obtain simulation test data, and to determine the test results based on the simulation test data.

[0064] The functions of each functional unit of the automated testing device for autonomous driving simulation provided in the above embodiments of this application can be implemented through the above methods and steps. Therefore, the specific working process and beneficial effects of each unit in the automated testing device for autonomous driving simulation provided in the embodiments of this application will not be repeated here.

[0065] This application also provides an electronic device, such as... Figure 5 As shown, it includes a processor 510, a communication interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other through the communication bus 540.

[0066] Memory 530 is used to store computer programs; When the processor 510 executes the program stored in the memory 530, it performs the following steps: After the test case management module sends control commands to the simulation environment module, it inputs preset path point information into the autonomous driving algorithm module. The simulation environment module loads the test scenario according to the control command; The simulation environment module performs tests based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the waypoint information, obtains simulation test data, and determines the test results based on the simulation test data.

[0067] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0068] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0069] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0070] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0071] The implementation methods and beneficial effects of the various components of the electronic device in the above embodiments for solving the problem can be found in [reference needed]. Figure 2 The steps in the illustrated embodiments are used to implement the electronic device. Therefore, the specific working process and beneficial effects of the electronic device provided in this application will not be repeated here.

[0072] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform an automated testing method for autonomous driving simulation as described in any of the above embodiments.

[0073] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute an automated testing method for autonomous driving simulation as described in any of the above embodiments.

[0074] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0075] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0076] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0077] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0078] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected," "coupled," or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0079] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the embodiments in this application are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments in this application.

[0080] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the embodiments of this application and their equivalents, then these modifications and variations are also intended to be included in the embodiments of this application.

Claims

1. An automated testing method for autonomous driving simulation, characterized in that, A testing system applied to include a test case management module, a simulation environment module, and an autonomous driving algorithm module; the method includes: After the test case management module sends control commands to the simulation environment module, it inputs preset path point information into the autonomous driving algorithm module. The simulation environment module loads the test scenario according to the control command; The simulation environment module performs tests based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the waypoint information, obtains simulation test data, and determines the test results based on the simulation test data.

2. The method as described in claim 1, characterized in that, Inputting preset waypoint information into the autonomous driving algorithm module includes: The test case management module calls a preset path injection script, which sends path point information containing at least one preset start point coordinate and a preset end point coordinate to the routing request interface of the autonomous driving algorithm module, so that the autonomous driving algorithm module can generate a driving route based on the path point information.

3. The method as described in claim 2, characterized in that, Before the path injection script sends the path point information to the routing request interface of the autonomous driving algorithm module, the method further includes: The path injection script performs a format conversion on the start-point and end-point coordinates to obtain the start-point and end-point coordinates in the target format.

4. The method as described in claim 1, characterized in that, After the simulation environment module loads the test scenario according to the control command, the method further includes: The simulation environment module initializes the environmental parameters corresponding to the test scenario according to the environment configuration instructions sent by the test case management module; the environmental parameters include at least one of weather conditions, light intensity, road sign information, and virtual traffic participant attributes.

5. The method as described in claim 1, characterized in that, Before the simulation environment module performs the test based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the waypoint information, the method further includes: The test case management module calls the algorithm startup script, which triggers the autonomous driving algorithm module to load a preset algorithm configuration file and automatically starts the autonomous driving algorithm module; the autonomous driving algorithm module includes a planning submodule, a control submodule, and a perception submodule.

6. The method as described in claim 1, characterized in that, Based on the simulation test data, the test results are determined, including: The test case management module extracts the actual values ​​of preset evaluation indicators from the simulation test data. The preset evaluation indicators include at least one of path tracking accuracy, obstacle collision avoidance success rate, vehicle speed control stability, and traffic rule compliance rate. If the actual value meets the preset threshold, the test result is determined to be passed.

7. The method as described in claim 1, characterized in that, During the testing process by the simulation environment module based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the waypoint information, the method further includes: The test case management module receives scene status data sent by the simulation environment module and running status data sent by the autonomous driving algorithm module in real time, and verifies the scene status data and running status data respectively to obtain verification results; the scene status data includes dynamic change information of virtual roads, and the running status data includes internal running parameters determined by the autonomous driving algorithm module.

8. An automated testing device for autonomous driving simulation, characterized in that, A testing system applied to include a test case management module, a simulation environment module, and an autonomous driving algorithm module; the device includes: The input unit is used to input preset path point information into the autonomous driving algorithm module after the test case management module sends control commands to the simulation environment module; The loading unit is used by the simulation environment module to load the test scenario according to the control command; The testing unit is used by the simulation environment module to conduct tests based on the test scenario and the driving route determined by the autonomous driving algorithm module based on the waypoint information, to obtain simulation test data, and to determine the test results based on the simulation test data.

9. An electronic device, characterized in that, The electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-7.

Images