Method and device for testing intelligent driving system based on multi-terminal cooperation

Abstract

The application relates to a method and device for testing an intelligent driving system based on multi-terminal cooperation, wherein the method comprises the following steps: generating a test scene file; analyzing the test scene file, determining a vehicle under test based on a first parameter, determining a dynamic target platform based on a second parameter, and determining an environment perception device based on a third parameter; issuing a driving instruction to the vehicle under test to drive the vehicle under test to travel along a path defined by the first parameter; controlling the dynamic target platform to simulate a dynamic traffic participant according to the behavior of a dynamic target defined by the second parameter; starting the environment perception device to collect perception data of a test area and uploading the perception data; collecting and storing vehicle state data in the vehicle traveling process and target motion data of the dynamic target platform, and in response to a test end instruction, controlling the vehicle under test and the dynamic target platform to return to a starting position; and generating a test report based on the perception data, the vehicle state data and the target motion data.

Description

Technical Field

[0001] This application relates to the field of automotive parts technology, specifically to a method and apparatus for testing intelligent driving systems based on multi-terminal collaboration. Background Technology

[0002] The rapid iteration of intelligent driving technology has placed higher demands on the testing and verification of driver assistance systems. Closed test track vehicle testing is a core part of the research and verification of driver assistance systems. However, the existing vehicle testing mode often adopts manual testing mode for the testing and verification of driver assistance systems. Its testing efficiency is low, and when multiple people work together to complete the test scenario construction and execution, problems such as operational deviation and multi-target coordination errors frequently occur, resulting in poor repeatability of test results and failing to effectively support algorithm iteration verification. It is clear that the existing manual testing mode can no longer meet the needs of large-scale and highly complex testing. Summary of the Invention

[0003] This application provides a method and apparatus for testing intelligent driving systems based on multi-terminal collaboration, in order to solve the problems of low testing efficiency and high testing error in the existing technology of testing and verifying assisted driving systems based on manual testing mode.

[0004] Firstly, this application provides a method for testing an intelligent driving system based on multi-terminal collaboration, applied to a control device, including: Generate a test scenario file, wherein the test scenario file includes a first parameter for characterizing the behavior of the vehicle under test in the test scenario, a second parameter for characterizing the type of the dynamic target and the behavior of the dynamic target in the test scenario, and a third parameter for characterizing the test triggering conditions. The test scenario file is parsed, and the vehicle under test is determined based on the first parameter, the dynamic target platform is determined based on the second parameter, and the environmental perception device is determined based on the third parameter. The vehicle under test is used to perform the behavior represented by the first parameter in the physical world, the dynamic target platform is used to perform the behavior of the dynamic target represented by the second parameter in the physical world, and the environmental perception device is used to monitor whether the test triggering condition represented by the third parameter is met in the physical world. The system issues a driving command to the vehicle under test to drive the vehicle under test along the path defined by the first parameter; controls the dynamic target platform to behave according to the dynamic target defined by the second parameter to simulate dynamic traffic participants; and activates the environmental perception device to collect perception data of the test area and uploads the perception data. Collect and store vehicle status data and target motion data of the dynamic target platform during vehicle operation, and control the tested vehicle and the dynamic target platform to return to the starting position in response to the test end command; A test report is generated based on the perception data, the vehicle status data, and the target motion data.

[0005] Secondly, this application provides a device for testing intelligent driving systems based on multi-terminal collaboration, applied to control equipment, characterized in that it includes: The first generation module is used to generate a test scenario file, wherein the test scenario file includes a first parameter for characterizing the behavior of the vehicle under test in the test scenario, a second parameter for characterizing the type of the dynamic target and the behavior of the dynamic target in the test scenario, and a third parameter for characterizing the test triggering conditions. A first processing module is used to parse the test scenario file, determine the vehicle under test based on the first parameter, determine the dynamic target platform based on the second parameter, and determine the environmental perception device based on the third parameter; wherein, the vehicle under test is used to perform the behavior represented by the first parameter in the physical world, the dynamic target platform is used to perform the behavior of the dynamic target represented by the second parameter in the physical world, and the environmental perception device is used to monitor whether the test triggering condition represented by the third parameter is met in the physical world; The second processing module is used to issue driving commands to the vehicle under test to drive the vehicle under test to travel along the path defined by the first parameter; control the dynamic target platform to behave according to the dynamic target defined by the second parameter to simulate dynamic traffic participants; and start the environmental perception device to collect perception data of the test area and upload the perception data. The third processing module is used to collect and store vehicle status data and target motion data of the dynamic target platform during vehicle driving, and to control the tested vehicle and the dynamic target platform to return to the starting position in response to the test end command. The second generation module is used to generate a test report based on the perception data, the vehicle status data, and the target motion data.

[0006] Thirdly, this application provides an electronic device, including: 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; the memory is used to store a computer program; and the processor is used to execute the computer program to implement the method for testing an intelligent driving system based on multi-terminal collaboration as described in the first aspect.

[0007] Fourthly, this application provides a storage medium storing a computer program thereon, characterized in that, when the computer program is executed by a processor, it implements the method for testing an intelligent driving system based on multi-terminal collaboration as described in the first aspect.

[0008] In this application, the test scenario is digitized into a standardized file containing a first parameter, a second parameter, and a third parameter. Based on these three parameters, the vehicle under test, the dynamic target platform, and the environmental perception device are automatically determined, achieving automated mapping from scenario definition to device allocation. Furthermore, by issuing drive commands and trajectory control commands to the vehicle under test and the dynamic target platform respectively through control equipment, the entire test execution process is automated, eliminating the inconsistencies caused by operational deviations and the safety risks caused by reaction delays in existing manual testing. In addition, by having the dynamic target platform carry the target object's shell in the physical world and move according to a preset trajectory, a dual simulation of the appearance and behavior of real traffic participants is achieved. And by simultaneously collecting and fusing perception data, vehicle status data, and target motion data, automated and objective evaluation and report generation of test results are achieved. It is evident that the above steps cooperate and work synergistically to form a complete unmanned testing closed loop from scenario configuration and test execution to result output, significantly improving the efficiency, accuracy, and safety of field testing of intelligent driving systems. Attached Figure Description

[0009] Figure 1 A flowchart of a method for testing an intelligent driving system based on multi-terminal collaboration, provided in an embodiment of this application; Figure 2 This application provides a schematic diagram of an unmanned intelligent driving test. Figure 3 This is a schematic diagram of the cloud platform module composition in the intelligent driving unmanned testing system provided in the embodiments of this application; Figure 4 This is a schematic diagram of the vehicle-side hardware architecture in the intelligent driving unmanned testing system provided in this application embodiment; Figure 5 This is a schematic diagram of the deployment of roadside sensing devices in the intelligent driving unmanned testing system provided in this application embodiment; Figure 6 This is a schematic diagram of the 5G+fiber optic network topology in the intelligent driving unmanned testing system provided in the embodiments of this application; Figure 7 This is a schematic diagram of the entire testing process business logic in the intelligent driving unmanned testing system provided in this application embodiment; Figure 8 A schematic diagram of the structure of the device for testing an intelligent driving system based on multi-terminal collaboration, provided in an embodiment of this application; Figure 9This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0010] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0011] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0012] For ease of description, spatial relative terms may be used in the text to describe the relative position or movement of one element or feature relative to another element or feature, as shown in the figure. These relative terms include, for example, "inside," "outside," "middle," "outer," "below," "below," "above," "front," "back," etc. Such spatial relative terms are intended to include different orientations of the device in use or operation, other than those depicted in the figure. For example, if the device in the figure undergoes a positional flip, orientation change, or change of motion, these directional indications will change accordingly. For instance, an element described as "below other elements or features" or "below other elements or features" will subsequently be oriented "above other elements or features" or "above other elements or features." Therefore, the example term "below" can include both upper and lower orientations. The device may be otherwise oriented (rotated 90 degrees or in other directions), and the spatial relative descriptors used in the text will be interpreted accordingly.

[0013] To address the problems of low testing efficiency and high testing error in existing manual testing methods for driver assistance systems, this application provides a method for testing intelligent driving systems based on multi-terminal collaboration, applied to control devices, such as... Figure 1 As shown, the steps of this method include: Step 101: Generate a test scenario file, wherein the test scenario file includes a first parameter for characterizing the behavior of the vehicle under test in the test scenario, a second parameter for characterizing the type of dynamic target and the behavior of the dynamic target in the test scenario, and a third parameter for characterizing the test triggering conditions. It should be noted that, in this application embodiment, the control device refers to a server or server cluster deployed in the cloud. As the decision-making and control center of the entire testing system, it is responsible for the generation and management of test scenarios, the scheduling and distribution of test tasks, and the collection and processing of test data. The control device establishes data connections via a communication network with the vehicle under test (i.e., the vehicle being tested), the mobile platform used to simulate traffic participants (i.e., the dynamic target platform), and environmental sensing devices deployed around the test area, forming a three-way collaborative architecture of control center—execution end—sensing end.

[0014] Furthermore, the test scenario file in this application embodiment is an electronic data file, which functions similarly to a test task book or test script in traditional testing, and is used to completely record all elements of a test scenario in digital form.

[0015] Specifically, test engineers can use the visual editing interface provided by the control device to drag and drop various test elements in a graphical environment. The control device automatically generates structured test scenario files based on the engineer's configuration. The test scenario file contains three core parameters: 1) The first parameter, which characterizes the initial state and expected behavior of the vehicle under test in the test scenario. For example, in the test scenario file, the first parameter can define the position of the vehicle under test at the start of the test (i.e., initial pose, including planar coordinates and orientation angle) and the initial speed at the start of the test. Furthermore, the first parameter can also define the driving path and speed change curve that the vehicle under test should follow throughout the test. 2) The second parameter, which characterizes the type of dynamic target and its behavior in the test scenario. Dynamic targets refer to other traffic participants that need to be simulated in the test scenario besides the vehicle under test, such as vehicles traveling ahead, pedestrians crossing the road, and two-wheeled vehicles emerging from the roadside. The second parameter contains information on two levels: first, the type of the dynamic target, such as whether it simulates a car, a dummy, or a two-wheeled vehicle; second, the behavioral parameters of the dynamic target in the test scenario, such as its initial position, trajectory, speed, direction, and triggering timing. 3) The third parameter characterizes the test triggering conditions. Test triggering conditions refer to threshold conditions used to determine whether a test is effective or when to begin recording key data. For example, in an Automatic Emergency Braking (AEB) test scenario, the third parameter can be defined as triggering emergency braking when the distance between the tested vehicle and the dynamic target ahead is less than 20 meters; this 20-meter distance threshold is a test triggering condition. Similarly, in a lane centering test scenario, the third parameter can be defined as starting data recording when the tested vehicle deviates from the lane centerline by more than 0.3 meters; this 0.3-meter lateral deviation threshold is a test triggering condition.

[0016] It is evident that by digitizing the test scenario into a file containing three types of standardized parameters, the test scenario achieves editability, reusability, and remote transmission, enabling the test scenario to be repeatedly executed at different times and locations, while also facilitating scenario management and scheduling during multi-task parallel testing.

[0017] Step 102: Parse the test scenario file and determine the vehicle under test based on the first parameter, the dynamic target platform based on the second parameter, and the environmental perception device based on the third parameter; wherein, the vehicle under test is used to perform the behavior represented by the first parameter in the physical world, the dynamic target platform is used to perform the behavior of the dynamic target represented by the second parameter in the physical world, and the environmental perception device is used to monitor whether the test triggering conditions represented by the third parameter are met in the physical world. After generating the test scenario file, the control device parses the test scenario file. Parsing refers to the control device reading the contents of the test scenario file, extracting the specific values ​​of the first, second, and third parameters, and loading these values ​​into the control device's memory for subsequent processing.

[0018] After parsing, the control device determines the test vehicle from the available vehicle resources based on the first parameter. Available vehicle resources refer to all test vehicles pre-connected to the control device and in standby mode. The control device selects vehicles from the available vehicle resources that meet the initial pose, speed level, and other requirements defined in the first parameter, and are not currently occupied by other test tasks, as the test vehicles for this test. "Determination" means binding the selected vehicle to the current test task, making it one of the execution entities for this test.

[0019] Similarly, the control device determines the dynamic target platform to be used in this test from the available target platform resources based on the second parameter. A dynamic target platform is a physically movable device, essentially a platform with independent movement capabilities. Different types of dynamic target shells can be installed on the platform, such as the shell of a simulated car, a model of a simulated human, or the shell of a simulated two-wheeled vehicle. When equipped with different types of shells, the dynamic target platform physically appears as different types of traffic participants. Based on the type and behavioral parameters of the dynamic target defined in the second parameter, the control device selects a dynamic target platform from the available target platform resources that meets the conditions and is not currently occupied by other test tasks as the dynamic target platform for this test.

[0020] Similarly, the control device determines the environmental sensing devices to be used in this test from the available sensing resources based on the third parameter. Environmental sensing devices refer to various sensors and related edge computing units pre-deployed around the test area, including but not limited to LiDAR, cameras, and millimeter-wave radar. These sensors perceive the test area from different angles and using different physical principles. Based on the sensing range and accuracy requirements involved in the test triggering conditions defined in the third parameter, the control device selects environmental sensing devices from the available sensing resources that can cover the test area and meet the sensing accuracy requirements as the environmental sensing devices for this test.

[0021] As can be seen, by parsing the three types of parameters in the test scenario file and determining the corresponding physical execution devices based on each parameter, an automated mapping from virtual scenario definition to physical device allocation is achieved. Test engineers no longer need to manually arrange which vehicle to participate in the test, which target platform to perform the movement, or which sensors to monitor; all of these decisions are automatically completed by the control equipment based on the scenario file, significantly reducing the human input and human decision-making time in test preparation.

[0022] Step 103: Issue a driving command to the vehicle under test to drive the vehicle under test to travel along the path defined by the first parameter; control the dynamic target platform to simulate the behavior of the dynamic target defined by the second parameter to simulate dynamic traffic participants; and start the environmental perception device to collect perception data of the test area and upload the perception data. After the equipment is determined, the control equipment enters the test execution phase. Specifically, the control equipment sends drive commands to the vehicle under test and trajectory control commands to the dynamic target platform through the communication network, and starts the environmental perception equipment to collect data.

[0023] First, the control device issues driving commands to the vehicle under test. These driving commands are a series of lateral and longitudinal control commands generated by the control device using a path planning algorithm based on the driving path and speed requirements of the vehicle under test as defined in the first parameter. These commands include, but are not limited to, acceleration, braking, steering, and lighting commands. These commands are transmitted to the vehicle under test via a communication network. Upon receiving the driving commands, the vehicle under test travels along the path defined in the first parameter, that is, starting from its initial position, it completes the prescribed driving behavior along the prescribed path at the prescribed speed.

[0024] Secondly, the control equipment controls the dynamic target platform to move according to the dynamic target behavior defined by the second parameter, in order to simulate dynamic traffic participants. Simulating dynamic traffic participants means that the dynamic target platform, through the combined action of two dimensions, presents a perception effect in the physical world equivalent to that of real traffic participants. The first dimension is appearance simulation, which involves configuring a target object shell corresponding to the type defined by the second parameter on the upper part of the dynamic target platform, so that the visual sensors (such as cameras) of the tested vehicle recognize the platform as the corresponding type of traffic participant. For example, when the dynamic target platform is equipped with a simulated car shell, the camera of the tested vehicle identifies it as "a car"; when it is equipped with a simulated human shell, the camera of the tested vehicle identifies it as "a pedestrian." The second dimension is behavior simulation, which means that the dynamic target platform moves according to the motion trajectory and speed defined by the second parameter, so that the ranging sensors of the tested vehicle, such as radar and lidar, detect a target with realistic motion characteristics. By fusing the visual perception results (appearance) and the ranging perception results (motion), the tested vehicle perceives the dynamic target platform as a real, dynamic traffic participant consistent with the scene definition.

[0025] After receiving trajectory control commands, the dynamic target platform acquires its current position information in real time through its onboard positioning and navigation module (such as a combined navigation system, including a global satellite navigation system receiver and an inertial measurement unit). The control system of the dynamic target platform compares the current position information with the motion trajectory defined by the second parameter, calculating the position and direction deviations between the two. Based on this deviation, the control system drives the omnidirectional movement mechanism of the dynamic target platform to perform motion compensation, making the actual motion trajectory of the dynamic target platform approximate the theoretical trajectory defined by the second parameter, thereby achieving accurate trajectory tracking. This omnidirectional movement mechanism preferably uses Mecanum wheels. Through the coordinated rotation of the Mecanum wheels, the dynamic target platform can achieve translational motion in any direction and rotational motion at the origin with zero turning radius, thus flexibly simulating various complex traffic participant behaviors, including straight driving, lane changing, and curve turning of vehicles, as well as pedestrian crossing and turning back.

[0026] Next, the control equipment activates the environmental perception equipment to collect perception data of the test area. During the test, the environmental perception equipment operates continuously, with its sensors constantly collecting raw perception data of the test area. Specifically, the lidar emits laser beams and receives reflected signals to generate point cloud data reflecting the three-dimensional spatial structure of the test area; the camera captures continuous image frames of the test area, generating image data containing color and texture information; the millimeter-wave radar emits millimeter waves and receives echoes, generating radar data reflecting the position and velocity of target objects. This raw data from different sensors undergoes multi-source fusion processing in the edge computing unit of the environmental perception equipment, synthesizing it into structured fused perception data. The fused perception data includes, but is not limited to, the real-time position coordinates, speed, direction of motion, and size of various targets within the test area (including the vehicle under test, dynamic target platform, and any non-test targets). The environmental perception equipment uploads the fused perception data to the control equipment via a communication network, allowing the control equipment to monitor the dynamic status of the test area in real time.

[0027] As can be seen, by issuing control commands to the vehicle under test and the dynamic target platform through control equipment, fully unmanned test execution is achieved, eliminating the safety risks caused by delayed driver response in traditional manual testing. The dynamic target platform moves realistically in the physical world according to preset parameters, and the test data obtained is actual measurement data collected by physical sensors in a real physical environment, which has higher realism and reliability compared to pure software simulation testing.

[0028] Step 104: Collect and store vehicle status data and target motion data of the dynamic target platform during vehicle driving, and in response to the test end command, control the tested vehicle and the dynamic target platform to return to the starting position. During the test execution, the control equipment synchronously performs data acquisition operations. The control equipment collects and stores two types of data in real time: The first type is vehicle status data, which is the operating status information continuously reported by the vehicle under test during its operation. Specifically, the vehicle under test continuously collects data from its internal control units and sensors via its controller area network bus. This data may include, but is not limited to: vehicle speed signal, engine or motor output torque, brake master cylinder pressure, steering wheel angle, yaw rate, longitudinal acceleration, and lateral acceleration. The vehicle under test uploads this data to the control equipment in real time via the communication network. The second type of data is target motion data, which is the motion status information continuously reported by the dynamic target platform during its trajectory movement. Specifically, the dynamic target platform continuously acquires its real-time position, speed, and direction of movement through its integrated navigation system, and simultaneously acquires its own battery level, communication status, and other health information through internal monitoring circuits. The dynamic target platform uploads this data to the control equipment in real time via the communication network.

[0029] After receiving the above data, the control device stores it together with the sensing data uploaded by the environmental sensing device in the storage medium of the control device. Each data is accompanied by precise timestamp information so as to facilitate subsequent time synchronization and alignment of multi-source data.

[0030] Once the test scenario is completed, the control equipment responds to the test end command, controlling the vehicle under test and the dynamic target platform to return to their respective starting positions. The test end command can be a stop command remotely issued by the test engineer, or it can be an automatic stop command generated by the control equipment after the preset test duration in the test scenario file has elapsed. Returning to the starting position means that the control equipment issues a return path planning command to the vehicle under test, causing it to automatically drive back to its initial parking position before the test began; simultaneously, it issues a return command to the dynamic target platform, causing it to automatically return to its initial standby position before the test began. Through these return operations, the test area is cleared and restored to its initial state, preparing for the next round of testing.

[0031] As can be seen, by simultaneously collecting status data from both the vehicle under test and the dynamic target platform during the test execution, complete basic data is provided for subsequent test evaluation. Automatic return to its original position after the test eliminates the need for manual driving of the test vehicle back or manual retrieval of the target platform, achieving continuous automated testing and significantly improving site utilization efficiency and testing capacity.

[0032] Step 105: Generate a test report based on perception data, vehicle status data, and target motion data.

[0033] To address this, the control equipment first synchronizes the three types of data according to their respective timestamps. Since the three types of data come from different sources and may have different sampling frequencies, the purpose of time alignment is to associate the three types of data at the same physical moment into a fused data record, thereby constructing a complete state snapshot of the tested vehicle, the dynamic target platform, and their relative relationship at each moment during the test.

[0034] After time alignment is completed, the control device locates key time points from the aligned data according to the test trigger conditions defined by the third parameter. For example, in AEB testing, the control device searches the fused data for the moment when the distance between the test vehicle and the dynamic target platform equals the 20-meter threshold defined by the third parameter, and marks this moment as the trigger moment. Then, based on the trigger moment, data within a preset time window is extracted from the fused data as valid analysis data.

[0035] The control equipment calculates test evaluation indicators based on valid analysis data. These indicators are quantitative values ​​that measure the performance of the driver assistance functions of the tested vehicle; different types of tests correspond to different evaluation indicators. For example, in AEB testing, evaluation indicators may include: emergency braking trigger time (i.e., the time interval from triggering to the braking system starting to act), maximum braking deceleration, and final braking distance. In lane centering keeping testing, evaluation indicators may include: the root mean square value of lateral deviation, lane keeping success rate, etc.

[0036] Finally, the control equipment combines the effective analysis data, test evaluation indicators, and scenario information from the test scenario file according to the preset report template to generate a structured test report. The scenario information includes the specific values ​​of the first, second, and third parameters, which explain the condition settings for this test. The generated test report can be exported in PDF, Excel, or CSV format for engineers to view, archive, or conduct subsequent analysis.

[0037] As can be seen, through steps 101 to 105, the test scenario is digitized into a standardized file containing the first, second, and third parameters. Based on these three types of parameters, the vehicle under test, the dynamic target platform, and the environmental perception device are automatically determined, achieving automated mapping from scenario definition to device allocation. Furthermore, by issuing drive commands and trajectory control commands to the vehicle under test and the dynamic target platform respectively through the control device, the entire test execution process is automated, eliminating the inconsistencies caused by operational deviations and the safety risks caused by reaction delays in existing manual testing. In addition, by having the dynamic target platform carry the target object's shell in the physical world and move according to a preset trajectory, a dual simulation of the appearance and behavior of real traffic participants is achieved. And by simultaneously collecting and fusing perception data, vehicle status data, and target motion data, automated and objective evaluation and report generation of test results are achieved. It is evident that the above steps cooperate and work synergistically to form a complete unmanned testing closed loop from scenario configuration and test execution to result output, significantly improving the efficiency, accuracy, and safety of intelligent driving system field testing.

[0038] In an optional embodiment of this application, the method of parsing the test scenario file and determining the vehicle under test based on the first parameter, determining the dynamic target platform based on the second parameter, and determining the environmental perception device based on the third parameter involved in step 102 above may further include: Step 11: Extract the first parameter, the second parameter, and the third parameter from the test scenario file; Step 12: Verify whether the available test resources in the test area meet the scenario execution conditions based on the first parameter, the second parameter, and the third parameter. The test resources include the vehicle under test, the dynamic target platform, and the environmental perception device. After parameter extraction is complete, the control device performs a resource verification operation. Resource verification refers to the control device's pre-checking of whether the various available test resources within the test area meet the conditions required to execute the current test scenario before officially determining the execution device. Test resources include three categories: vehicle under test resources (i.e., all available test vehicles), dynamic target platform resources (i.e., all available dynamic target platforms), and environmental perception device resources (i.e., all available sensors and edge computing units).

[0039] The core purpose of resource verification is to avoid the following situations: the control device identifies a vehicle under test based on a scenario file, only to find that the vehicle's current battery level is insufficient to complete the test; or it identifies a dynamic target platform, only to find that the platform does not currently have the corresponding type of target object shell required by the scenario installed; or it identifies certain environmental sensing devices, only to find that the sensing range of these devices does not fully cover the test area. If any of these situations occur, it will lead to abnormal interruptions or data loss during test execution, severely impacting test efficiency and data integrity.

[0040] Specifically, resource verification is based on the extracted first, second, and third parameters. The control equipment determines the performance requirements for vehicle resources for this test based on the behavioral requirements of the tested vehicle, such as its initial speed and driving path, as defined in the first parameter. This includes the maximum speed the vehicle needs to achieve and the required drive system (pure electric or fuel-powered). Based on the type and behavioral parameters of the dynamic target defined in the second parameter, the control equipment determines the resource requirements for the target platform for this test. This includes the type of target object shell that needs to be installed on the platform (simulated vehicle shell, simulated dummy model, or simulated two-wheeled vehicle shell), and the required speed and positioning accuracy. Based on the spatial range involved in the test triggering conditions defined in the third parameter (e.g., if the triggering distance is 20 meters, then all space within the 20-meter range must be effectively sensed), the control equipment determines the resource requirements for environmental sensing equipment for this test. This includes whether the sensor's sensing distance meets the requirements and whether the sensing range completely covers the test area.

[0041] After determining the above requirements, the control device queries the status information of each available resource within the test area and compares the actual capabilities of each resource with the conditions required for scenario execution. Only when the actual capabilities of all three types of resources meet the corresponding scenario execution conditions is the control device determined that the resource verification has passed, and the subsequent matching and locking steps continue. If any resource does not meet the conditions, the control device generates corresponding prompt information, such as "None of the currently available vehicles can reach the required speed" or "No available simulated vehicle shell target platform," and suspends the execution of the test task until the resource conditions are met before re-verifying.

[0042] Step 13: After the resource verification is passed, the vehicle under test is matched and locked from the available vehicle resources based on the first parameter, the dynamic target platform is matched and locked from the available target platform resources based on the second parameter, and the environmental perception device is matched and locked from the available perception resources based on the third parameter.

[0043] In this context, "matching" refers to the control device selecting the most suitable device from available resources of a corresponding category based on requirements defined by specific parameters. Specifically, the control device matches the vehicle to be tested from available vehicle resources based on a first parameter. Here, "available vehicle resources" refers to all vehicles that have passed resource verification and whose capabilities meet the scenario execution conditions. The control device further selects the vehicle that best matches the definition from these vehicles as the vehicle to be tested, based on the specific behavioral definitions in the first parameter (e.g., initial pose coordinates, initial speed level, etc.). Matching can be implemented using various strategies, such as selecting the vehicle with the most current battery power, selecting the vehicle closest to the pose coordinates in the first parameter, or selecting the vehicle with the longest current idle time.

[0044] The control device matches a dynamic target platform from the available target platform resources based on the second parameter. Here, available target platform resources refer to all dynamic target platforms that have passed resource verification and whose capabilities meet the scenario execution conditions. The control device further selects the platform that best matches the definition from these platforms based on the dynamic target type and behavioral parameters in the second parameter (e.g., needing to simulate a dummy car, needing to start at a specific location, etc.). During matching, it is especially important to ensure that the shell of the target object currently installed on the selected platform is consistent with the dynamic target type defined by the second parameter.

[0045] The control device matches environmental sensing devices from available sensing resources based on a third parameter. Available sensing resources refer to all environmental sensing devices that have passed resource verification and whose sensing capabilities meet the scenario execution conditions. The control device further selects the group of devices that best matches the requirements based on the sensing area and accuracy requirements related to the triggering conditions in the third parameter. During matching, it is especially important to ensure that the sensing range of the selected devices can completely cover the entire motion space of the vehicle under test and the dynamic target platform.

[0046] Locking refers to the control device binding a successfully matched device to the current test task and marking the bound device as exclusive. Exclusivity means that the locked device cannot be invoked or controlled by any other test task during the execution of the current test task. The purpose of locking is to prevent resource conflicts in a multi-task parallel testing environment, specifically preventing two different test tasks from simultaneously attempting to control the same vehicle or the same dynamic target platform, thereby avoiding crosstalk of control commands and the risk of physical collisions. In the locked state, control commands from other test tasks will not be sent to the locked device, and the locked device will not respond to commands or requests from other test tasks. When the current test task completes (including normal or abnormal termination), the control device releases the lock on the device, restoring it to an available state for subsequent test tasks to invoke.

[0047] As can be seen, by performing matching and locking only after verification, test interruptions due to insufficient resources are effectively avoided. In unmanned testing scenarios, once the test starts, the vehicle under test and the dynamic target platform begin to move autonomously along a preset trajectory. If insufficient resources are detected at this time (such as insufficient battery power of the target platform preventing it from completing the entire movement), the test will be abnormally interrupted, and the collected data may be invalid due to incompleteness, resulting in wasted time and the cost of repeated testing. Claim 2 avoids the above problems from the source by performing resource verification in advance before the equipment is determined.

[0048] In an optional embodiment of this application, step 13, which involves matching and locking the test vehicle from available vehicle resources based on the first parameter, includes: Step 21: Based on the initial pose and initial velocity of the vehicle under test in the first parameter, select candidate vehicles from the available vehicle resources that meet the position accuracy requirements corresponding to the initial pose and the speed level requirements corresponding to the initial velocity. In this context, the initial pose in the first parameter refers to the spatial position and orientation of the vehicle under test (VAT) at the start of the test, as defined by the first parameter in the test scenario file. The initial pose is typically expressed in coordinates (X, Y) and a yaw angle (the angle between the vehicle's heading and a reference direction). For example, "Initial pose (X=0 meters, Y=0 meters, yaw angle=0°)" means the VAT should be located at the center of the test road's starting point, with its front facing the direction of the road's extension. The initial speed refers to the speed the VAT should possess at the start of the test, as defined by the first parameter in the test scenario file. Initial speed is typically expressed in kilometers per hour (km / h) or meters per second (m / s). For example, "Initial speed of 60 km / h" means the VAT should be traveling at 60 km / h at the start of the test. The position accuracy requirement refers to the allowable deviation range between the VAT's actual parking position at the start of the test and the initial pose defined by the first parameter. This requirement is preset by the system based on the characteristics of the test scenario and the sensor's sensing range. For example, in some test scenarios that are extremely sensitive to the starting position (such as when a vehicle needs to trigger interaction with a target object at a specific location), the position accuracy requirement can be set to "the deviation between the actual position and the defined position does not exceed ±0.1 meters"; for scenarios with a relatively lenient starting position, this requirement can be relaxed accordingly. The position accuracy requirement is essentially a threshold condition used to determine whether the actual current position of a physical vehicle can be considered equivalent to the initial pose defined by the first parameter. The speed level requirement refers to the allowable deviation range between the actual speed of the vehicle under test at the start of the test and the initial speed defined by the first parameter, and whether the vehicle's maximum speed capability meets or exceeds the initial speed requirement. The speed level requirement has two levels of meaning. The first level is the vehicle's own capability level, that is, whether the vehicle's maximum design speed can reach the initial speed defined by the first parameter. For example, if the initial speed defined by the first parameter is 120 km / h, then any vehicle with a maximum speed lower than 120 km / h cannot meet the speed requirement of this scenario. The second aspect is the allowable deviation range between the vehicle's current actual speed and the defined speed; that is, whether the selected vehicle has the ability to precisely control its speed near the defined speed at the start of the test. The speed rating requirement is essentially a composite condition encompassing both capability compliance and precise controllability.

[0049] Based on this, for step 21 above, specifically, for each available vehicle, the control device first obtains the vehicle's current actual position (obtainable through the positioning information reported by the vehicle), calculates the spatial distance deviation and orientation angle deviation between the actual position and the initial pose defined by the first parameter, and compares this deviation with the system's preset position accuracy requirements. Only when the deviation between the actual position and the initial pose is less than or equal to the upper limit of the position accuracy requirement is the vehicle selected for position accuracy. Simultaneously, the control device obtains the vehicle's maximum design speed and current actual speed, and compares them with the initial speed defined by the first parameter. The comparison is divided into two stages. The first stage is a capability comparison, i.e., determining whether the vehicle's maximum design speed is greater than or equal to the initial speed. If the vehicle's maximum design speed is lower than the initial speed, the vehicle cannot reach the speed required by the scenario and is directly eliminated. The second stage is a current speed deviation comparison, i.e., determining whether the deviation between the vehicle's current actual speed and the initial speed is within the allowable range. If the deviation between the current actual speed and the initial speed exceeds the allowable range of the speed level requirement, the vehicle's current state cannot meet the scenario's starting conditions and is also eliminated. Only vehicles that pass both the position accuracy screening and speed level screening are included in the candidate vehicle set. The above screening process is essentially a pre-filter of available vehicle resources. Its purpose is to ensure that the vehicles subsequently selected are highly consistent with the definition of the first parameter in terms of physical spatial location and speed capability, thereby avoiding deviations from the expected test execution due to excessive deviations in the vehicle's initial position or insufficient speed capability.

[0050] Step 22: Select a vehicle from the candidate vehicles that is not currently locked by other test tasks and whose equipment is in normal condition as the test vehicle; In this regard, "equipment in normal condition" means that all major systems of the vehicle (including but not limited to the powertrain, braking system, steering system, communication system, and positioning system) are in normal working order, with no fault alarms, no performance degradation, and no need for maintenance. Normal equipment condition is a necessary condition for the vehicle to safely and reliably perform testing tasks.

[0051] In addition, the selection operation considers two conditions. The first condition is the locked state. The control device checks whether each candidate vehicle is currently locked by other test tasks. If a vehicle is currently in an exclusive state and bound to another test task, then that vehicle cannot be selected. The second condition is the device status. The control device checks the current device self-test report of each candidate vehicle to confirm that all its major systems are in normal working condition, without any fault alarms or performance abnormalities. If a vehicle currently has any device faults or abnormal status, then that vehicle cannot be selected. Only candidate vehicles that simultaneously meet both the conditions of not being locked and having normal device status are eligible for selection. If there are multiple vehicles in the candidate vehicle set that simultaneously meet the above two conditions, the control device can select one from them according to a preset priority rule. The priority rule can be pre-configured by the system, for example, it can prioritize the vehicle with the best device status (such as the most sufficient battery power, the shortest driving range, etc.), or it can prioritize the vehicle with the highest matching degree to the initial pose (such as the smallest position deviation).

[0052] Step 23: Mark the selected vehicle as exclusive and send the scene configuration file to the selected vehicle.

[0053] It is evident that by employing a dual-dimensional screening based on initial pose and initial velocity, the selected vehicles are ensured to be highly consistent with the scenario definition in terms of both physical spatial position and speed capability. In unmanned testing, the initial position and initial velocity of the tested vehicle are crucial for the comparability and repeatability of test results. If the actual initial position of the vehicle deviates too much in different rounds of testing, or if the actual initial velocity deviates too much from the scenario definition, the test results for the same scenario in different rounds will be incomparable, failing to effectively support the iterative verification of the algorithm. Claim 3, through a dual screening mechanism of position accuracy requirements and speed level requirements, ensures the consistency of the starting conditions for each round of testing from the source, thereby improving the repeatability of test results. Furthermore, by issuing scenario configuration files instead of issuing control commands one by one, the communication load and communication latency sensitivity between the control device and the vehicle during test execution are reduced. The scenario configuration file contains all the behavioral parameters of the tested vehicle throughout the entire test process. After receiving the file, the vehicle can execute autonomously locally without continuously relying on real-time command issuance from the control device during test execution. This significantly improves the robustness of test execution, ensuring that even in the event of short-term fluctuations in the communication network, the vehicle can continue to complete the test according to the received configuration file without being interrupted by the loss of a single instruction.

[0054] In an optional embodiment of this application, step 13, which involves matching and locking a dynamic target platform from available target platform resources based on the second parameter, includes: Step 31: Based on the type and movement trajectory of the dynamic traffic participants in the second parameter, select candidate platforms from the available target platform resources that have installed the corresponding type of target object shell and whose positioning accuracy meets the path accuracy requirements corresponding to the movement trajectory; In this embodiment, the type of dynamic traffic participant in the second parameter refers to the specific category of traffic participants that the dynamic target platform needs to simulate, as defined by the second parameter in the test scenario file. The types of dynamic traffic participants typically include at least one of simulated cars (used to simulate vehicles traveling in front or cutting in from the side), simulated dummies (used to simulate pedestrians crossing the road or standing on the roadside), and simulated two-wheeled vehicles (used to simulate bicycles or electric bicycles). This type information determines the physical appearance of the dynamic target platform. The target shell refers to a physical shell detachably mounted on the upper part of the dynamic target platform, possessing the appearance characteristics of a specific traffic participant. The target shell is typically made of lightweight and relatively strong materials, such as foam or composite materials, and its shape is designed to mimic the appearance of a real traffic participant. By mounting different types of target shells, the dynamic target platform physically presents the visual appearance of the corresponding type of traffic participant. For example, when the dynamic target platform is equipped with a simulated car shell, it appears as a car in the camera's field of view of the tested vehicle; when equipped with a simulated dummy shell, it appears as a pedestrian. The corresponding target object shell type refers to the one-to-one correspondence between the target object shell type and the dynamic traffic participant type defined by the second parameter. For example, if the second parameter defines the dynamic traffic participant type as "simulated car," then the corresponding target object shell type is a simulated car shell; if it is defined as a simulated dummy, then the corresponding target object shell type is a simulated dummy model; if it is defined as a simulated two-wheeled vehicle, then the corresponding target object shell type is a simulated two-wheeled vehicle shell. This correspondence ensures that the physical appearance of the dynamic target platform is consistent with the role type defined in the scene. Positioning accuracy refers to the degree of deviation between the dynamic target platform's own position coordinates obtained through its onboard positioning and navigation module (usually a combined navigation system, including a global navigation satellite system receiver and an inertial measurement unit) and its actual physical position. Positioning accuracy is usually quantified in centimeters; for example, a positioning accuracy better than 5 centimeters means that the deviation between the platform's reported position coordinates and its actual position does not exceed 5 centimeters. The higher the positioning accuracy, the stronger the dynamic target platform's ability to track the preset trajectory. Path accuracy requirement refers to the allowable deviation range between the actual driving path and the theoretical trajectory when the dynamic target platform executes the motion trajectory defined by the second parameter. This requirement is preset by the control equipment based on the complexity of the motion trajectory in the second parameter and the sensitivity of the test scenario to positional accuracy. For example, for scenarios requiring the dynamic target platform to move accurately in narrow passages, the path accuracy requirement can be set to a lateral deviation of no more than ±10 cm; for scenarios with more lenient paths, this requirement can be relaxed accordingly. Essentially, the path accuracy requirement is a threshold condition used to determine whether the positioning capability of a dynamic target platform is sufficient to meet the trajectory tracking requirements of the scenario.

[0055] Based on this, in step 31 above, specifically, for each available dynamic target platform, the control device first obtains the type information of the target object shell currently installed on the platform (obtainable through the device status information reported by the platform), and compares this type with the type of dynamic traffic participant defined by the second parameter. The platform passes the appearance type screening only if the type of the target object shell currently installed on the platform is completely consistent with the type defined by the second parameter. For example, if the second parameter defines the need to simulate a dummy vehicle, any platform currently installed with a simulated dummy shell or a simulated two-wheeled vehicle shell is eliminated. Simultaneously, the control device obtains the platform's positioning accuracy index (obtainable through the self-test report of the positioning and navigation module on the platform), and compares this positioning accuracy with the path accuracy requirement determined by the system based on the complexity of the motion trajectory in the second parameter. The platform passes the positioning accuracy screening only if its positioning accuracy is better than or equal to the accuracy threshold specified by the path accuracy requirement. For example, if the motion trajectory in the second parameter includes complex paths such as sharp turns or narrow passages, the control device sets a high path accuracy requirement (e.g., lateral deviation not exceeding ±5 cm), and only platforms whose positioning accuracy meets this requirement are included in the candidate platform set. If the motion trajectory is relatively simple (e.g., straight-line driving), the path accuracy requirement can be relaxed accordingly. Only dynamic target platforms that pass both appearance type screening and positioning accuracy screening are included in the candidate platform set.

[0056] Step 32: Select a platform from the candidate platforms that is not currently locked by other test tasks and whose device status is normal as the dynamic target platform; Step 33: Mark the selected dynamic target platform as exclusive and send the trajectory configuration file to the selected dynamic target platform.

[0057] It is evident that by employing a dual-dimensional screening approach based on the type and trajectory of dynamic traffic participants, the selected dynamic target platforms are ensured to be consistent with the scene definition in both physical appearance and motion accuracy. In unmanned testing, the physical appearance of the dynamic target platform determines whether the visual sensors of the tested vehicle can correctly identify the target. If the platform's appearance is inconsistent with the scene definition, the vehicle's perception algorithm will be unable to correctly correlate the visual detection results with the radar detection results, rendering the test data invalid. Simultaneously, the platform's positioning accuracy determines whether it can accurately reproduce the preset motion trajectory, thereby determining whether the test results truly reflect the performance of the tested vehicle in the expected scenario. Moreover, the dual mechanism of appearance type matching and positioning accuracy screening ensures the realism and effectiveness of the simulation from the outset.

[0058] In an optional embodiment of this application, the method of driving the test vehicle to travel along the path defined by the first parameter in step 103 above may further include: Step 41: Generate lateral and longitudinal control commands based on path planning, and drive the test vehicle to travel along the path defined by the first parameter based on the lateral and longitudinal control commands. The lateral and longitudinal control commands include at least one of acceleration commands, braking commands, steering commands, and lighting commands. The lateral and longitudinal control commands are converted into controller area network messages that can be executed by the test vehicle, and the lateral and longitudinal control commands are transmitted to the power actuator, chassis actuator, and brake actuator.

[0059] In this context, path planning refers to the process by which control equipment calculates and generates a series of continuous control command sequences based on the test vehicle's driving path, speed requirements, and other behavioral requirements defined by the first parameter, combined with physical environmental information of the test area (such as road boundaries and obstacle positions). The essence of path planning is to transform the abstract behavioral definitions in the first parameter into specific, executable sequences of control commands. For example, the first parameter might define the test vehicle as starting from a starting point, accelerating along a straight line to 60 km / h, and then maintaining a constant speed. During path planning, the control equipment needs to calculate the complete path from the starting point to the end point, and calculate the acceleration, braking, steering angle, and light status required at each moment to achieve this path. These calculation results are then organized into a sequence of control commands arranged in chronological order. Furthermore, lateral and longitudinal control commands refer to comprehensive control commands that simultaneously include lateral and longitudinal control information. Longitudinal control refers to controlling the vehicle's movement in the forward direction, mainly including acceleration and braking, with the control targets being vehicle speed and acceleration. Lateral control refers to controlling the vehicle's movement perpendicular to the forward direction, mainly including steering, with the control targets being driving direction and lane position. Lateral and longitudinal control commands integrate longitudinal and lateral control into a single command, enabling the vehicle to perform steering operations simultaneously with acceleration or braking, thus achieving a complete driving action. For example, turning right through a curve at 30 km / h requires issuing steering and speed control commands simultaneously. The steering command handles lateral control, while the speed control command handles longitudinal control; both work together to achieve the complete cornering maneuver. Furthermore, Controller Area Network (CAN) messages refer to communication data frames encapsulated according to the CAN protocol standard format. CAN is a serial communication protocol widely used in automotive electronic systems. Its characteristics include differential signal transmission, strong resistance to electromagnetic interference, and error detection mechanisms, meeting the real-time communication needs between various electronic control units within the vehicle. The vehicle's power actuators, chassis actuators, and brake actuators all communicate with other control units via the CAN bus. Therefore, lateral and longitudinal control commands generated by the control equipment can only be recognized and executed by the actuators of the vehicle under test after being encapsulated in CAN message format.

[0060] Therefore, in step 41 above, specifically, the control device takes the driving path, speed curve, and other behavioral requirements defined by the first parameter as input, and combines it with pre-stored high-precision map information of the test area (including road boundary coordinates, lane line positions, road surface friction coefficient, radius of curvature, etc.) to calculate a feasible path from the vehicle's current position to the target position using a path planning algorithm. Based on the required vehicle speed and driving direction at each position point along this path, a series of lateral and longitudinal control commands are generated. Each control command includes a timestamp indicating when the command should be executed, the desired longitudinal acceleration (positive values ​​for acceleration, negative values ​​for braking), the desired lateral acceleration (i.e., steering angle or steering angular velocity), and the desired lighting status. Furthermore, the control device converts this command into a controller area network (CLAN) message executable by the vehicle under test. This conversion operation is typically performed by an external control module installed on the vehicle under test. Specifically, after receiving the lateral and longitudinal control commands from the control device, the external control module parses the control parameters (such as target acceleration, target steering angle, target vehicle speed, etc.) in the commands. Based on the message formats and protocol specifications required by the power actuators, chassis actuators, and brake actuators of the vehicle under test, the external control module encapsulates the control parameters into corresponding Controller Area Network (CAN) messages. Different types of actuators typically correspond to different CAN identifiers and different data field definitions; therefore, the external control module needs to generate corresponding messages according to the actuator type. After the lateral and longitudinal control commands are converted into CAN messages, these messages are transparently transmitted to the power actuators, chassis actuators, and brake actuators of the vehicle under test. Specifically, the external control module sends the encapsulated CAN messages to the CAN bus of the vehicle under test. The CAN bus is a broadcast communication network; all electronic control units connected to the bus can receive all messages transmitted on the bus, but each control unit only processes the message corresponding to its identifier, ignoring messages unrelated to it. The power actuator, chassis actuator, and brake actuator each continuously listen to messages on the bus through their respective controller area network interfaces. When a message matching their identifier is received, the data field content in the message is read and the corresponding physical action is performed based on that content.

[0061] As can be seen, generating lateral and longitudinal control commands through path planning automates the transformation from abstract behavioral definitions in the first parameter to specific control commands. In traditional manual testing, drivers need to determine when to accelerate, brake, and steer based on test requirements. Differences in driving habits among different drivers can lead to inconsistent test results in the same scenario. Generating standardized control command sequences through path planning algorithms eliminates random biases from human operation, ensuring consistent execution conditions for the same test scenario across different rounds, thereby significantly improving the repeatability and comparability of test results.

[0062] In an optional embodiment of this application, step 103, which involves controlling the dynamic target platform to simulate the behavior of a dynamic target defined by the second parameter to mimic dynamic traffic participants, may further include: Step 51: Determine the type of dynamic traffic participant based on the second parameter. The type of dynamic traffic participant includes at least one of simulated cars, simulated dummies, and simulated two-wheeled vehicles. The first step in the simulation operation is for the control device to determine the type of dynamic traffic participant based on the second parameter. Specifically, the control device reads the value of the dynamic target type field from the second parameter. This field is a preset parameter item in the second parameter, and its value is set to one of "simulated vehicle," "simulated human," or "simulated two-wheeler." The control device uses this value as the target type that the dynamic target platform needs to simulate in this test, and performs subsequent appearance configuration and behavior control operations accordingly. The significance of this determination is that different types correspond to different physical configurations and motion parameters in subsequent operations. For example, if the type is determined to be "simulated vehicle," then a simulated vehicle shell needs to be installed, and the movement speed is usually at the speed level of a motor vehicle (e.g., 20 to 80 km / h); if the type is determined to be "simulated human," then a simulated human model needs to be installed, and the movement speed is usually at the walking speed level (e.g., 4 to 6 km / h); if the type is determined to be "simulated two-wheeler," then a simulated two-wheeler shell needs to be installed, and the movement speed is between the two.

[0063] Step 52: According to the type of dynamic traffic participant, configure the corresponding type of target shell on the upper part of the dynamic target platform. After the dynamic target platform is equipped with the target shell, it presents the visual appearance of the dynamic traffic participant in physical form. After determining the type of dynamic traffic participant, the control device triggers the shell configuration operation. It should be noted that in this technical solution, the "installation" operation can be implemented in two ways. One way is automatic installation: an automatic shell-changing device can be configured on the dynamic target platform. After determining the type, the control device issues a shell-changing command to the dynamic target platform, which then uses its automatic shell-changing device to remove the currently installed shell and replace it with the target shell corresponding to the determined type. The other way is manual installation: during the test preparation phase, the test engineer manually installs the corresponding target shell on the dynamic target platform based on prompts generated by the control device (e.g., "Please install the simulated vehicle shell to dynamic target platform #3"). Regardless of the installation method used, the ultimate goal is the same: to ensure that the dynamic target platform physically presents a visual appearance that matches the type defined by the second parameter.

[0064] In practice, to ensure the continuity of testing, multiple dynamic target platforms are typically pre-equipped at the test site, each with a different type of target object shell installed. For example, platform one might have a simulated car shell installed, platform two a simulated dummy model installed, and platform three a simulated two-wheeled vehicle shell installed. With this configuration, when the control equipment performs platform matching and locking, it can directly select the platform with the corresponding type of shell installed based on the type defined in the second parameter, without needing to perform installation or shell replacement operations. In this case, this operation is manifested as "confirming that the dynamic target platform has installed the corresponding type of target object shell based on the type of dynamic traffic participant," rather than actually performing the installation action. Therefore, installation encompasses both scenarios, including both actually performing the installation action and confirming the existing installation status of the corresponding type of shell.

[0065] When the dynamic target platform is fitted with a shell of the corresponding type of target object, its overall physical form changes. What was originally just a mobile base with wheels and sensors now possesses a three-dimensional shape and color characteristics similar to a real traffic participant. When the visual sensors of the tested vehicle observe this dynamic target platform, the optical signals received by the sensors are highly similar to those received when observing a real traffic participant; its shape, surface reflectivity, color distribution, and other visual features are consistent with those of a real traffic participant. This allows the image recognition algorithm of the tested vehicle to correctly identify the platform as the corresponding type of traffic participant, rather than as a mobile platform.

[0066] Step 53: Send trajectory control instructions to the dynamic target platform so that the dynamic target platform drives the omnidirectional movement mechanism of the dynamic target platform to move according to the deviation between the current position information and the movement trajectory, so that the dynamic target platform moves according to the movement trajectory and movement speed, and exhibits the movement characteristics of a dynamic traffic participant in terms of movement behavior.

[0067] After the dynamic target platform's external configuration is completed, the control device sends a trajectory control command to the platform. This command contains all the parameter information for the motion trajectory and velocity defined by the second parameter. Upon receiving the command, the dynamic target platform stores it in the control host's memory and initiates the trajectory tracking control program. During trajectory tracking, the dynamic target platform acquires its current position information in real time through its onboard positioning and navigation module. The positioning and navigation module typically employs integrated navigation technology, fusing Global Navigation Satellite System (GNSS) signals and Inertial Measurement Unit (IMU) signals. With the support of high-precision differential positioning services (such as Real-Time Dynamic Differential Positioning, or RTK), it can achieve centimeter-level real-time positioning accuracy. The dynamic target platform's control host compares the real-time acquired current position information with the theoretical motion trajectory defined in the trajectory control command, calculating the deviation between the current position and the corresponding point on the theoretical trajectory. This deviation reflects the degree and direction of the dynamic target platform's actual position deviating from its theoretical position at the current moment.

[0068] Based on this deviation, the control host of the dynamic target platform calculates the motion compensation amount required to correct the deviation, including the magnitude and direction of the compensation speed, through a closed-loop control algorithm (such as proportional-integral-derivative control, i.e., PID control algorithm). The control host converts this compensation amount into the rotational speed and steering commands of each wheel set of the omnidirectional traverse mechanism, and drives the omnidirectional traverse mechanism to execute the corresponding movements, so that the actual driving path of the dynamic target platform continuously converges to the theoretical trajectory. This closed-loop control process is continuously performed at an extremely high frequency (usually 50 to 100 times per second) to ensure that the dynamic target platform always closely follows the preset theoretical trajectory throughout the entire test process.

[0069] In terms of motion speed control, the control host of the dynamic target platform also adopts a closed-loop control strategy. The platform compares the real-time measured current driving speed with the target speed defined in the trajectory control command, calculates the speed deviation, and eliminates the deviation by adjusting the output power of the omnidirectional moving mechanism, so that the actual driving speed is stabilized near the target speed.

[0070] As can be seen, through the synergistic effect of the aforementioned position closed-loop control and speed closed-loop control, the dynamic target platform accurately reproduces the motion trajectory and speed defined by the second parameter in the physical world. When this accurately reproduced motion behavior is combined with the aforementioned visual appearance, the dynamic target platform is fully presented as a real dynamic traffic participant in the physical world. It looks like a vehicle (or a person, or a two-wheeled vehicle), and its movement is also like that of a vehicle (or a person, or a two-wheeled vehicle). The perception system of the tested vehicle will then react in the same way as when facing a real traffic participant, thus realizing the complete function of simulating a dynamic traffic participant.

[0071] In other words, through steps 51 to 53 above, a complete and realistic physical simulation of dynamic traffic participants is achieved through the synergy of appearance simulation and behavior simulation. In intelligent driving testing, the perception system of the vehicle under test includes two main types of sensors: visual sensors (cameras) and ranging sensors (radar, lidar). Visual sensors are responsible for identifying the type and appearance characteristics of the target (whether it's a car or a person), while ranging sensors are responsible for detecting the target's position, speed, and trajectory. If only appearance simulation is performed (the platform is mounted but not moving), the ranging sensors cannot acquire the target's motion information, and the test cannot proceed. If only behavior simulation is performed (the platform moves but the platform is not mounted), the visual sensors cannot correctly identify the target type, and the perception fusion algorithm will produce incorrect results. Furthermore, through closed-loop control based on the deviation between the current position information and the trajectory, high-precision tracking of the preset trajectory by the dynamic target platform is achieved. In the test scenario, the positional accuracy of the dynamic target platform directly affects the validity of the test results. For example, in AEB testing, if the actual position of the dynamic target platform is tens of centimeters forward or backward relative to the preset position, the trigger distance will deviate from the preset value, causing the test results to fail to accurately reflect the real performance of the tested vehicle in the preset scenario.

[0072] In an optional embodiment of this application, after issuing a drive command to the vehicle under test, the method of this application further includes: Step 61: Send heartbeat messages to the vehicle under test according to a preset cycle. The vehicle under test detects in real time whether it receives the heartbeat messages. If it does not receive the heartbeat messages within a preset number of consecutive cycles, it is determined that the connection with the control device has failed, and a safety shutdown and emergency braking are triggered independently. As can be seen, after the control device issues a drive command to the vehicle under test, it begins sending heartbeat messages to the vehicle under test at a preset period (e.g., every 500 milliseconds). This heartbeat message is a short data frame, which may contain an incrementing sequence number or a fixed status flag to indicate to the vehicle under test that the control device is still functioning normally and the communication link is intact. After receiving the drive command and starting to drive, the vehicle under test simultaneously initiates a heartbeat monitoring process. This monitoring process continuously runs in the vehicle under test's control system, its function being to detect in real time whether a heartbeat message has been received from the control device. Specifically, the vehicle under test's control system maintains a timer, which is reset and restarts whenever a heartbeat message is received. If no heartbeat message is received within the preset period (e.g., 500 milliseconds), the timer continues counting. When the accumulated value of the timer exceeds the time length corresponding to a "preset number of consecutive cycles" (e.g., 3 consecutive cycles, i.e., 3 × 500 milliseconds = 1500 milliseconds), the vehicle under test determines that its connection with the control device has failed. Specifically, this refers to the failure of the connection between the control device and the external control module installed on the vehicle under test. This module is physically located inside the vehicle under test and connected to the vehicle's original control unit via a controller area network bus. After determining the connection failure, the vehicle under test no longer waits for any instructions from the control device but independently triggers a safety stop and performs emergency braking. Independent triggering means that the triggering operation is entirely completed by the vehicle under test's own control system, without receiving any instructions from the control device. When the vehicle under test's control system triggers a safety stop, it first sends a command to the power system, requesting it to reduce the output power to zero (i.e., stop acceleration); then it sends a command to the braking system, requesting it to apply appropriate braking force to stop the vehicle within a safe distance. In some implementations, if the vehicle is equipped with an automatic emergency braking function of an advanced driver assistance system, the vehicle under test can also directly invoke this function to perform emergency braking.

[0073] Step 62: Monitor the status of the communication link with the vehicle under test in real time; when the communication link with the vehicle under test is interrupted, cut off the control authority of the vehicle under test, and let the control equipment take over the vehicle under test and perform emergency braking.

[0074] In addition, after issuing drive commands to the vehicle under test, the control device (specifically, the external control module) continuously monitors the communication link status between itself and the vehicle under test. Physically, this monitored communication link refers to the communication link between the control device and the original vehicle control unit of the vehicle under test via the controller area network (CAN) bus through the external control module. This monitoring is achieved by checking whether the physical signals on the CAN bus are normal, whether there are bus error frames, and whether message transmission is acknowledged. When the external control module detects an interruption in the CAN bus communication link (e.g., physical disconnection of the bus, continuous bus signal error, bus arbitration failure, etc.), it first disconnects the control authority of the original vehicle control unit of the vehicle under test through a hardware relay. This operation is achieved through a relay—a relay is an electromagnetic switching device whose contacts can disconnect or connect a circuit. Under normal operation, the external control module keeps the relay closed, allowing signals from the original vehicle control unit to be transmitted normally to the actuator. When a communication link interruption is detected, the external control module opens the relay, cutting off the signal path between the original vehicle control unit and the actuator, thus preventing control commands from the original vehicle control unit from reaching the actuator. This operation ensures that even if the original vehicle control unit itself malfunctions or misoperates, the actuator will not receive any instructions that could lead to dangerous behavior.

[0075] After disconnecting the original vehicle control unit, the control device takes over control of the tested vehicle, directly sending emergency braking commands to the vehicle's brake actuators. Since the path between the original vehicle control unit and the actuators has been severed, the control device now becomes the sole control source for the actuators. Its braking commands directly drive the brake actuators (such as the hydraulic control unit of the electronic stability program system) to apply maximum braking force, bringing the vehicle to a stop in the shortest possible distance. This takeover operation essentially transfers control from the original vehicle control unit to an external control module through a hardware-level control path switch, ensuring that even if the original vehicle control unit completely malfunctions, the control device can still control the vehicle's braking through an independent hardware path.

[0076] As can be seen, in this embodiment, the two levels of protection operate independently and are not dependent on each other. If the first level of protection fails due to a fault in the original vehicle control unit, the second level of protection can still be completed independently by the control equipment for emergency braking. If the second level of protection fails due to a fault in the control equipment, the first level of protection can still be completed independently by the original vehicle control unit for safe shutdown. The effectiveness of either protection mechanism ensures the safe stopping of the vehicle under test in the event of communication abnormalities. This dual safety redundancy design ensures that the safety protection functions can still be fully executed even in the event of a single fault point.

[0077] In an optional embodiment of this application, the control device presets the boundary range of the test area. After issuing a driving command to the vehicle under test, the method in this application embodiment may further include: Step 71: Real-time detection of the positions of the tested vehicle and dynamic target platform within the test area, and whether there are any non-test targets within the test area; Step 72: If the vehicle under test or the dynamic target platform is detected to exceed the boundary range, or if a non-test target is detected to intrude into the test area, an emergency braking command is generated and issued to the vehicle under test and the dynamic target platform to stop all movement of the vehicle under test and the dynamic target platform.

[0078] As can be seen, before the test begins, the control device first presets the boundary range of the test based on the specific test scenario and the environmental conditions of the test area. This boundary range is set by the test engineer through the control device's visual interface; that is, the engineer delineates the permitted activity area for the test on the test area map displayed on the interface by drawing polygons or entering coordinate values. The control device stores the defined boundary range in the system's resource management database as a basis for subsequent position detection.

[0079] After the control device issues a drive command to the vehicle under test and begins test execution, position boundary protection is activated. The control device continuously senses dynamic objects within the test area using environmental sensing devices (including LiDAR, cameras, millimeter-wave radar, etc.), acquiring the real-time position coordinates of the vehicle under test and the dynamic target platform. Specifically, the edge computing unit of the environmental sensing device fuses raw sensing data from different sensors, outputting the real-time position, speed, size, and type information of all moving targets within the test area (including the vehicle under test, the dynamic target platform, and any other moving objects), and uploads this information to the control device. Upon receiving the position information of each moving target, the control device compares the position coordinates of the vehicle under test and the dynamic target platform with the preset boundary range in real time. The comparison process determines two key issues: first, whether the vehicle under test has exceeded the boundary range; second, whether the dynamic target platform has exceeded the boundary range. A yes answer to either question indicates a boundary violation event has occurred.

[0080] When the control equipment detects that the vehicle under test or the dynamic target platform exceeds the preset boundary range, the control equipment immediately generates an emergency braking command. This command is sent to both the vehicle under test and the dynamic target platform via the communication network. Upon receiving the emergency braking command, the vehicle under test interrupts all currently executing driving commands (including acceleration, cruise, steering, etc.) and immediately switches to emergency braking mode, applying maximum braking force through the brake actuator to decelerate the vehicle to a stop in the shortest possible distance. Upon receiving the emergency braking command, the dynamic target platform also interrupts its current trajectory tracking motion and uses the braking function of the omnidirectional movement mechanism (i.e., applying reverse braking torque to the drive motor of the Mecanum wheel) to bring the platform to a stop in the shortest possible distance.

[0081] Furthermore, when the edge computing unit of the environmental perception device processes the raw data collected by the sensors, it not only calculates the position and velocity of each target but also classifies and identifies each target, determining whether it is a "test vehicle," a "dynamic target platform," or "other." This classification and identification can be achieved through various technical means: using target shape recognition algorithms based on LiDAR point clouds to determine whether the geometric contour of the target matches a known vehicle or human body; using image recognition algorithms from cameras (such as deep learning target detection models) for visual classification of targets; or using active identification devices (such as ultra-wideband positioning tags) installed on the target for identification. Regardless of the specific technical means used, its core function is to distinguish between targets authorized to participate in this test and those not authorized to participate in this test. When the control device receives the perception data uploaded by the environmental perception device, it extracts the position information of targets identified as other (i.e., targets that are neither the test vehicle nor the dynamic target platform). The control device determines whether the target is located within the preset test area boundary. If the target's position coordinates are within the boundary, the control device determines that a non-test target intrusion event has occurred. The safety risks of non-test targets intruding into the test area lie in the fact that the target's trajectory is unpredictable, not included in the test scenario planning, and there is no collaborative control mechanism between the target and the test equipment. When intrusion occurs, the vehicle under test and the dynamic target platform continue to move according to the preset trajectory, while the intruded non-test target is also moving freely. The relative motion between the two cannot be coordinated by any control system, resulting in an extremely high risk of collision. Especially in high-speed test scenarios, the time window from non-test target intrusion to collision may be extremely short (only a few seconds or even less), requiring automated real-time detection and response mechanisms to handle the situation, and cannot rely on remote manual intervention.

[0082] The following detailed explanation, in conjunction with specific embodiments of this application, provides a method for unmanned testing of an intelligent driving system based on vehicle-road-cloud integration. Specifically, the unmanned testing method and the modules involved in its technical architecture are described below. Figure 2 Based on vehicle-road-cloud integrated technology, the system automatically builds and tests test scenarios, controls the controlled vehicles and target objects, and generates reports. See the cloud module composition diagram below. Figure 3 The system comprises a scenario simulation platform, a cloud control infrastructure platform, and a cloud control application platform. SimPro is used as the scenario designer to generate unmanned test scenarios based on specific configurations. Data from test vehicles, tablets, and roadside equipment within the test scenarios is collected and uniformly input into the cloud control infrastructure platform for multi-source perception fusion. The cloud control application platform can perform tasks such as task configuration, real-time switching, parameter adjustment, and priority queueing. It can also use safety mechanisms to urgently stop test tasks. The vehicle-side hardware solution is referenced. Figure 4 The system primarily includes an external control module (external domain controller), an in-vehicle Ethernet converter, a combined navigation system and antenna, platform networking equipment, and an antenna data acquisition module. It communicates with the original vehicle domain controller via CAN bus messages to issue control commands. For safety redundancy, the external domain controller retains a direct control link for emergency braking of the target vehicle. In cloud-collaborative mode, the cloud platform connects to the external domain controller to issue trajectory and control commands, ultimately controlling the original vehicle domain controller to operate the vehicle and complete the driving function test. (Roadside equipment setup reference) Figure 5 It includes LiDAR, cameras, millimeter-wave radar, and MEC computing modules to perform real-time detection of roadside environmental information and upload it to the cloud. The cloud automatically activates protective measures when it detects unauthorized intrusions, equipment malfunctions, or scene deviations. (Network topology diagram for the network side is provided.) Figure 6 Since this application adopts vehicle-road-cloud integrated technology, which has high requirements for network latency, a 5G and fixed fiber optic collaborative solution is adopted, a new 5G site is built, and lightweight 5G and supporting equipment are deployed to achieve network coverage in the test area.

[0083] Furthermore, the unmanned testing method and process for the vehicle-road-cloud integrated intelligent driving system provided in this application are as follows: Figure 7As shown, the first step is scene editing. Specifically, test engineers use the SimPro scene simulation platform in the cloud to configure variables such as the initial attitude of the vehicle under test, the trajectory of the target object, the test speed, the trigger distance, and environmental parameters, based on intelligent driving test cases such as LCC lane centering, AEB automatic emergency braking, front vehicle cut-in, pedestrian crossing, and right turn interference at intersections. Then, standardized scene files in xosc format are generated. The platform supports editing single-scene, multi-scene concatenation, and complex multi-target collaborative scenes, with a single scene file size not exceeding 10MB, and is compatible with parsing by all test devices. Scene uploading and cloud task parsing: The scene file is uploaded to the cloud control application platform. The platform forwards the file to the cloud control basic platform through the API gateway. The basic platform calls the scene service module to complete file parsing, resource verification, and site matching. Combining test task priority, equipment occupancy status, completion time scheduling, and resource allocation, it locks the dynamic square test area, the vehicle under test, the micro-tablet target object, and roadside perception devices.

[0084] Furthermore, for the issuance of test commands and the collaborative initialization of equipment, the cloud control platform sends control commands to the vehicle, target, and roadside via a 5G private network and a direct fiber optic connection. The external control module on the vehicle side completes self-testing, enters cloud-collaborative control mode, and establishes CAN bus communication with the original vehicle domain controller. The roadside MEC edge computing module initiates multi-sensor fusion sensing to complete a full-area scan of the test area. The target-side micro-tablet completes positioning calibration and Mecanum wheel self-testing, entering a cloud-controlled state. After all equipment initialization is complete, the cloud sends a ready signal, entering the test execution phase. Based on this, for unmanned test execution, in cloud-collaborative mode, the cloud performs path planning and issues lateral and longitudinal control commands (acceleration, braking, steering, lights, etc.) to the original vehicle domain controller via the external control module. The original vehicle domain controller transmits commands to the powertrain, chassis, and brake actuators to achieve precise vehicle control. The micro-tablet, based on a preset trajectory, achieves omnidirectional movement and zero-turn radius motion via Mecanum wheels, simulating dynamic traffic participants such as dummy cars and dummies, and collaborating with the vehicle under test in real time. LiDAR, millimeter-wave radar, and cameras collect target position, velocity, and distance data in real time. This data is then fused and processed by MEC before being uploaded to the cloud, ensuring consistency across different scenarios. Finally, for data extraction and automated data processing, the system enables real-time acquisition of multi-source data, automated cleaning and parsing, extraction of core indicators, and generation of standard reports, replacing manual data processing and improving data accuracy and output efficiency.

[0085] To further illustrate this specific implementation method, the unmanned testing method will be analyzed in depth from the following sections: 1. Remote control of test task switching and adjustment; Specifically, relying on the cloud-based application platform's web-based visual management system, test engineers can complete task configuration, real-time switching, parameter adjustment, and priority queueing in a remote office area, without needing to be physically present at the test site, significantly improving the flexibility of test scheduling. During task creation and configuration, engineers log into the test management module via the web platform to remotely complete the following tasks: editing basic test task information (project name, test case number, number of tests, execution time), configuring parameters for the vehicle under test (vehicle type, domain control version, control mode), adjusting target object parameters (number of micro-tablets, movement speed, trajectory path, load weight), and setting test constraints (area restrictions, speed limits, trigger conditions). After configuration, the system submits the configuration to the cloud and automatically performs a validity check. During testing, engineers can remotely initiate seamless scenario switching: the cloud pauses the execution of the current scenario, retains the real-time position of the vehicle and target object, quickly parses the new scenario file, reallocates control commands, issues new commands without interruption, and the vehicle and target object directly execute the new scenario without stopping, restarting, or on-site adjustments. During testing, dynamic parameters can be remotely adjusted, such as the trigger speed, following distance, and response threshold of the tested vehicle, as well as the movement speed, entry angle, crossing timing, and stopping position of the micro-flatbed. In case of safety risks, the current task can be terminated remotely with a single click, and the vehicle will immediately perform safety braking. Furthermore, this embodiment supports resume testing from the point of interruption, preventing data loss.

[0086] 2. Test data extraction and automated analysis; The aim is to achieve real-time acquisition of multi-source data, automated cleaning and parsing, extraction of core indicators, and generation of standard reports, replacing manual data processing and improving data accuracy and output efficiency. The cloud-based system collects four types of core data uniformly through a device gateway: vehicle-side data: CAN bus messages, domain control status, executed commands, vehicle attitude (speed, acceleration, steering angle), braking pressure, etc.; roadside data: target location, speed, trajectory, perception fusion results, video stream, device status, etc.; target-side data: micro-tablet positioning information, motion parameters, battery level, communication status, etc.; and cloud-based data: timestamps, communication latency, command issuance logs, and abnormal alarm information. The system requires a data acquisition frequency ≥100Hz and a positioning accuracy ≤30cm to ensure data integrity and precision. The cloud control platform's data service module will automatically clean and align the data and automatically calculate core indicators such as AEB braking distance and trigger time according to intelligent driving test standards. The cloud platform generates complete test reports with a single click using enterprise-standard modules. These reports include scenario information, test parameters, execution time, device information, core performance data, charts, video screenshots, test results, anomaly analysis, and improvement suggestions. The reports can be exported in PDF, Excel, and CSV formats and can be directly used for development verification and project delivery.

[0087] 3. Remote monitoring and testing security control; By combining roadside full-domain perception, digital twin visualization, and multi-layered safety redundancy, remote real-time monitoring of the testing process is achieved, enabling second-level response, proactive protection, and remote emergency handling in case of abnormalities, ensuring zero human injury and zero major equipment accidents during unmanned testing. During the testing process, the invention supports full-domain remote visualization monitoring. A digital twin system for the test site is built in the cloud, synchronizing the location and status of vehicles, micro-tablets, and roadside equipment in real time, restoring the test scenario 1:1. Multiple roadside cameras transmit video streams in real time, supporting remote full-screen viewing, snapshot capture, and playback. Equipment communication latency, positioning accuracy, battery level, and fault alarms are remotely displayed, providing a comprehensive understanding of the testing status. Because unmanned testing under the vehicle-road-cloud integrated structure presents safety risks, this application embodiment involves multi-layered safety protection mechanisms, including: 1) Electronic fence protection: The cloud-based preset test area electronic boundary. When a vehicle or micro-tablet exceeds the boundary or a target outside the ODD range is detected entering the test area, it will immediately stop automatically and apply emergency braking to prevent it from crossing the boundary.

[0088] 2) Communication Disconnection Protection: A dual-domain controller architecture is adopted, using an MQTT heartbeat mechanism. The external domain controller monitors the cloud-vehicle connection, latency, and other communication status in real time and outputs a heartbeat status synchronously. Simultaneously, both the external domain controller and the original vehicle domain controller synchronously verify their communication status. When the original vehicle domain controller detects an abnormal heartbeat status from the external domain controller, the device immediately triggers a safety shutdown and emergency braking to prevent loss of control. When the external domain controller detects an abnormal status from the original vehicle domain controller, it disconnects the original vehicle domain controller's control via a relay and takes over the vehicle to a stop.

[0089] 3) Roadside perception anomaly warning: The roadside MEC monitors the test area in real time. When it detects non-test targets entering, equipment failure, or scene deviation, it uploads an alarm within 100ms, and the cloud automatically starts protection measures.

[0090] Corresponding to Figure 1 This application also provides a device for testing intelligent driving systems based on multi-terminal collaboration, applied to control equipment, such as... Figure 8 As shown, the device includes: The first generation module 802 is used to generate a test scenario file, wherein the test scenario file includes a first parameter for characterizing the behavior of the vehicle under test in the test scenario, a second parameter for characterizing the type of dynamic target and the behavior of the dynamic target in the test scenario, and a third parameter for characterizing the test triggering conditions. The first processing module 804 is used to parse the test scenario file, determine the vehicle under test based on the first parameter, determine the dynamic target platform based on the second parameter, and determine the environmental perception device based on the third parameter; wherein, the vehicle under test is used to perform the behavior represented by the first parameter in the physical world, the dynamic target platform is used to perform the behavior of the dynamic target represented by the second parameter in the physical world, and the environmental perception device is used to monitor whether the test triggering condition represented by the third parameter is met in the physical world. The second processing module 806 is used to issue driving commands to the vehicle under test to drive the vehicle under test to travel along the path defined by the first parameter; control the dynamic target platform to simulate the behavior of dynamic targets defined by the second parameter to simulate dynamic traffic participants; and start the environmental perception device to collect perception data of the test area and upload the perception data. The third processing module 808 is used to collect and store vehicle status data and target motion data of the dynamic target platform during vehicle driving, and to control the tested vehicle and the dynamic target platform to return to the starting position in response to the test end command. The second generation module 810 is used to generate a test report based on perception data, vehicle status data, and target motion data.

[0091] In an optional embodiment of this application, the first processing module in this application includes: The extraction unit is used to extract the first parameter, the second parameter, and the third parameter from the test scenario file; The verification unit is used to verify whether the available test resources in the test area meet the scenario execution conditions based on the first parameter, the second parameter and the third parameter. The test resources include the vehicle under test, the dynamic target platform and the environmental perception device. The first processing unit is used to match and lock the vehicle under test from the available vehicle resources based on the first parameter after the resource verification is passed, match and lock the dynamic target platform from the available target platform resources based on the second parameter, and match and lock the environmental sensing device from the available sensing resources based on the third parameter.

[0092] In an optional embodiment of this application, the first processing unit in this application is used to perform the following steps: based on the initial pose and initial velocity of the vehicle under test in the first parameters, select candidate vehicles from available vehicle resources that meet the position accuracy requirements corresponding to the initial pose and the speed level requirements corresponding to the initial velocity; select a vehicle from the candidate vehicles that is not currently locked by other test tasks and whose equipment status is normal as the vehicle under test; mark the selected vehicle as exclusive, and send the scene configuration file to the selected vehicle. In an optional embodiment of this application, the first processing unit in this application is further configured to perform the following steps: based on the type and movement trajectory of the dynamic traffic participant in the second parameter, select candidate platforms from the available target platform resources that have installed the corresponding type of target object shell and whose positioning accuracy meets the path accuracy requirements corresponding to the movement trajectory; select a platform from the candidate platforms that is not currently locked by other test tasks and whose equipment status is normal as the dynamic target platform; mark the selected dynamic target platform as exclusive, and send the trajectory configuration file to the selected dynamic target platform.

[0093] In an optional embodiment of this application, the second processing module includes: The second processing unit is used to generate lateral and longitudinal control commands based on path planning, and drive the vehicle under test to travel along the path defined by the first parameter based on the lateral and longitudinal control commands. The lateral and longitudinal control commands include at least one of acceleration commands, braking commands, steering commands and lighting commands. The lateral and longitudinal control commands are converted into controller area network messages that can be executed by the vehicle under test, and the lateral and longitudinal control commands are transmitted to the power actuator, chassis actuator and brake actuator.

[0094] In an optional embodiment of this application, the second processing module includes: The determining unit is used to determine the type of dynamic traffic participant based on the second parameter, wherein the type of dynamic traffic participant includes at least one of simulated car, simulated dummy, and simulated two-wheeled vehicle; The third processing unit is used to configure a target shell of the corresponding type on the upper part of the dynamic target platform according to the type of dynamic traffic participant. After the dynamic target platform is equipped with the target shell, it presents the visual appearance of the dynamic traffic participant in physical form. The fourth processing unit is used to send trajectory control commands to the dynamic target platform so that the dynamic target platform drives the omnidirectional movement mechanism of the dynamic target platform to move by the deviation between the current position information and the movement trajectory, and makes the dynamic target platform move according to the movement trajectory and movement speed, thus exhibiting the movement characteristics of a dynamic traffic participant in terms of movement behavior.

[0095] In optional embodiments of this application, the apparatus further includes: The sending module is used to send heartbeat messages to the vehicle under test according to a preset period after issuing a drive command to the vehicle under test. The vehicle under test detects in real time whether it receives the heartbeat message. If it does not receive the heartbeat message within a preset number of consecutive periods, it determines that the connection with the control device has failed, independently triggers a safety stop and performs emergency braking. The third processing module is used to monitor the status of the communication link with the vehicle under test in real time. When the communication link with the vehicle under test is interrupted, the control authority of the vehicle under test is cut off, and the control equipment takes over the vehicle under test and performs emergency braking.

[0096] In an optional embodiment of this application, the control device presets the boundary range of the test area. Based on this, the apparatus in this application embodiment further includes: The detection module is used to detect the position of the vehicle under test and the dynamic target platform in the test area in real time after the drive command is issued to the vehicle under test, as well as whether there are non-test targets in the test area. The fourth processing module is used to generate an emergency braking command and issue an emergency braking command to the vehicle under test and the dynamic target platform to stop all movement of the vehicle under test and the dynamic target platform when the vehicle under test or the dynamic target platform exceeds the boundary range or a non-test target intrudes into the test area.

[0097] like Figure 9 As shown in the figure, this application provides an electronic device, including a processor 911, a communication interface 912, a memory 913, and a communication bus 914, wherein the processor 911, the communication interface 912, and the memory 913 communicate with each other through the communication bus 914. Memory 913 is used to store computer programs; In one embodiment of this application, when the processor 911 executes the program stored in the memory 913, it implements the method for testing the intelligent driving system based on multi-terminal collaboration provided in any of the aforementioned method embodiments. Its function is similar and will not be described again here.

[0098] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method for testing an intelligent driving system based on multi-terminal collaboration as provided in any of the foregoing method embodiments.

[0099] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0100] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0101] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0102] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for testing intelligent driving systems based on multi-terminal collaboration, applied to control equipment, characterized in that, include: Generate a test scenario file, wherein the test scenario file includes a first parameter for characterizing the behavior of the vehicle under test in the test scenario, a second parameter for characterizing the type of the dynamic target and the behavior of the dynamic target in the test scenario, and a third parameter for characterizing the test triggering conditions. The test scenario file is parsed, and the vehicle under test is determined based on the first parameter, the dynamic target platform is determined based on the second parameter, and the environmental perception device is determined based on the third parameter. The vehicle under test is used to perform the behavior represented by the first parameter in the physical world, the dynamic target platform is used to perform the behavior of the dynamic target represented by the second parameter in the physical world, and the environmental perception device is used to monitor whether the test triggering condition represented by the third parameter is met in the physical world. The system issues a driving command to the vehicle under test to drive the vehicle under test along the path defined by the first parameter; controls the dynamic target platform to behave according to the dynamic target defined by the second parameter to simulate dynamic traffic participants; and activates the environmental perception device to collect perception data of the test area and uploads the perception data. Collect and store vehicle status data and target motion data of the dynamic target platform during vehicle operation, and control the tested vehicle and the dynamic target platform to return to the starting position in response to the test end command; A test report is generated based on the perception data, the vehicle status data, and the target motion data.

2. The method according to claim 1, characterized in that, Parsing the test scenario file, determining the vehicle under test based on the first parameter, determining the dynamic target platform based on the second parameter, and determining the environmental perception device based on the third parameter, includes: Extract the first parameter, the second parameter, and the third parameter from the test scenario file; The test resources available in the test area are verified according to the first parameter, the second parameter and the third parameter to determine whether they meet the scenario execution conditions. The test resources include the vehicle under test, the dynamic target platform and the environmental perception device. After the resource verification is passed, the vehicle under test is matched and locked from the available vehicle resources based on the first parameter, the dynamic target platform is matched and locked from the available target platform resources based on the second parameter, and the environmental sensing device is matched and locked from the available sensing resources based on the third parameter.

3. The method according to claim 2, characterized in that, Matching and locking the vehicle under test from available vehicle resources based on the first parameter includes: filtering candidate vehicles from available vehicle resources that meet the position accuracy requirements corresponding to the initial pose and the speed level requirements corresponding to the initial speed, based on the initial pose and initial speed of the vehicle under test in the first parameter; selecting a vehicle from the candidate vehicles that is not currently locked by other test tasks and whose equipment status is normal as the vehicle under test; marking the selected vehicle as exclusive and sending a scene configuration file to the selected vehicle. The step of matching and locking a dynamic target platform from available target platform resources based on the second parameter includes: filtering candidate platforms from the available target platform resources that have installed the corresponding type of target object shell and whose positioning accuracy meets the path accuracy requirements corresponding to the movement trajectory, according to the type and movement trajectory of the dynamic traffic participant in the second parameter; selecting a platform from the candidate platforms that is not currently locked by other test tasks and whose equipment status is normal as the dynamic target platform; marking the selected dynamic target platform as exclusive, and sending a trajectory configuration file to the selected dynamic target platform.

4. The method according to claim 1, characterized in that, Driving the vehicle under test to travel along the path defined by the first parameter includes: Based on path planning, lateral and longitudinal control commands are generated, and the test vehicle is driven to travel along the path defined by the first parameter based on the lateral and longitudinal control commands. The lateral and longitudinal control commands include at least one of acceleration commands, braking commands, steering commands, and lighting commands. The lateral and longitudinal control commands are converted into controller area network messages that the test vehicle can execute, and the lateral and longitudinal control commands are transparently transmitted to the power actuator, chassis actuator, and brake actuator.

5. The method according to claim 1, characterized in that, Controlling the dynamic target platform to behave according to the dynamic target defined by the second parameter to simulate dynamic traffic participants includes: The type of dynamic traffic participant is determined based on the second parameter, and the type of dynamic traffic participant includes at least one of simulated cars, simulated dummies, and simulated two-wheeled vehicles; According to the type of dynamic traffic participant, a target object shell of the corresponding type is configured on the upper part of the dynamic target platform, wherein the dynamic target platform, after being equipped with the target object shell, presents the visual appearance of the dynamic traffic participant in physical form. A trajectory control command is sent to the dynamic target platform so that the dynamic target platform drives the omnidirectional movement mechanism of the dynamic target platform to move according to the deviation between the current position information and the movement trajectory, and makes the dynamic target platform move according to the movement trajectory and movement speed, thus exhibiting the movement characteristics of the dynamic traffic participant in terms of movement behavior.

6. The method according to claim 1, characterized in that, After issuing a drive command to the vehicle under test, the method further includes: Heartbeat messages are sent to the vehicle under test according to a preset period, wherein the vehicle under test detects in real time whether it receives the heartbeat messages; if the heartbeat messages are not received within a preset number of consecutive periods, it is determined that the connection with the control device has failed, and a safety shutdown and emergency braking are independently triggered. The communication link status between the device and the vehicle under test is monitored in real time. When the communication link between the device and the vehicle under test is interrupted, the control authority of the vehicle under test is cut off, and the control device takes over the vehicle under test and performs emergency braking.

7. The method according to claim 1, characterized in that, The control device presets the boundary range of the test area. After issuing a drive command to the vehicle under test, the method further includes: The system can detect in real time the positions of the vehicle under test and the dynamic target platform within the test area, as well as whether there are any non-test targets within the test area. If the vehicle under test or the dynamic target platform is detected to exceed the boundary range, or if a non-test target is detected to intrude into the test area, an emergency braking command is generated and issued to the vehicle under test and the dynamic target platform to stop all movement of the vehicle under test and the dynamic target platform.

8. A device for testing intelligent driving systems based on multi-terminal collaboration, applied to control equipment, characterized in that, include: The first generation module is used to generate a test scenario file, wherein the test scenario file includes a first parameter for characterizing the behavior of the vehicle under test in the test scenario, a second parameter for characterizing the type of the dynamic target and the behavior of the dynamic target in the test scenario, and a third parameter for characterizing the test triggering conditions. A first processing module is used to parse the test scenario file, determine the vehicle under test based on the first parameter, determine the dynamic target platform based on the second parameter, and determine the environmental perception device based on the third parameter; wherein, the vehicle under test is used to perform the behavior represented by the first parameter in the physical world, the dynamic target platform is used to perform the behavior of the dynamic target represented by the second parameter in the physical world, and the environmental perception device is used to monitor whether the test triggering condition represented by the third parameter is met in the physical world; The second processing module is used to issue driving commands to the vehicle under test to drive the vehicle under test to travel along the path defined by the first parameter; control the dynamic target platform to behave according to the dynamic target defined by the second parameter to simulate dynamic traffic participants; and start the environmental perception device to collect perception data of the test area and upload the perception data. The third processing module is used to collect and store vehicle status data and target motion data of the dynamic target platform during vehicle driving, and to control the tested vehicle and the dynamic target platform to return to the starting position in response to the test end command. The second generation module is used to generate a test report based on the perception data, the vehicle status data, and the target motion data.

9. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory is used to store computer programs; the processor is used to execute the computer programs to implement the method for testing the intelligent driving system based on multi-terminal collaboration as described in any one of claims 1-7.

10. A storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the method for testing an intelligent driving system based on multi-terminal collaboration as described in any one of claims 1-7.

Images