Vehicle testing methods, apparatus, systems and non-volatile storage media

Abstract

This application discloses a vehicle testing method, apparatus, system, and non-volatile storage medium. The method includes: establishing a communication connection between the vehicle under test (V2T) and a testing system, wherein the testing system is used to test the functions of the V2T in a vehicle-to-everything (V2X) environment, and the testing system and the V2T use the same time base; determining a virtual test scenario for the V2T in response to an operation command from a target object, and determining multiple test cases under different operating conditions based on the virtual test scenario, wherein the test cases are used to test different functions of the V2T in the V2X environment; testing the V2T according to the test cases, and updating the test scenario library based on the test results. This application solves the technical problems of poor cross-domain synchronization and insufficient scenario reproducibility in vehicle testing in related technologies.

Description

Technical Field

[0001] This application relates to the field of vehicle testing, and more specifically, to a vehicle testing method, apparatus, system, and non-volatile storage medium. Background Technology

[0002] As intelligent connected vehicles rapidly evolve from single-vehicle intelligence to "vehicle-road-cloud" collaborative control, functions based on V2X (Vehicle to Everything) communication, such as forward collision warning, red light warning, blind spot collaborative perception, road construction warning, and intersection traffic coordination, have gradually become important capabilities of mass-produced vehicles. Unlike traditional ADAS (Advanced Driver Assistance Systems) which rely solely on onboard sensors, V2X functions are simultaneously influenced by the vehicle controller, T-BOX (Telematics BOX) / OBU (On-Board Unit), RSU (Road Side Unit), cloud control platform, positioning and timing, wireless link latency, and the behavior of traffic participants in the scenario. Therefore, its testing is no longer a single ECU (Electronic Control Unit) functional verification, but a cross-domain closed-loop verification covering perception, communication, decision-making, and execution. The main problems in the verification of V2X functions for intelligent connected vehicles in related technologies are poor cross-domain synchronization and insufficient scenario reproduction capabilities.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a vehicle testing method, apparatus, system, and non-volatile storage medium to at least solve the technical problems of poor cross-domain synchronization and insufficient scenario reproduction capability in vehicle testing in related technologies.

[0005] According to one aspect of the embodiments of this application, a vehicle testing method is provided, comprising: establishing a communication connection between a vehicle under test and a testing system, wherein the testing system is used to test the functions of the vehicle under test in a vehicle-to-everything (V2X) environment, and the testing system and the vehicle under test use the same time base; determining a virtual test scenario for the vehicle under test in response to an operation instruction from a target object, and determining multiple test cases under different working conditions based on the virtual test scenario, wherein the test cases are used to test different functions of the vehicle under test in the V2X environment; testing the vehicle under test according to the test cases, and updating the test scenario library according to the test results.

[0006] Optionally, determining the virtual test scenario for the vehicle under test in response to the operation instructions of the target object includes: receiving the operation instructions from the target object, wherein the operation instructions represent the test target of the vehicle under test; obtaining the initial state information of the vehicle under test, wherein the initial state information includes the software version number, vehicle model parameters, and communication configuration; determining the truth world state table corresponding to the initial state information from the test scenario library based on the operation instructions, wherein the truth world state table includes at least one of the following: real-time updated road topology information, participant trajectory information, and external event state information; and generating the virtual test scenario based on the truth world state table.

[0007] Optionally, before testing the vehicle under test according to the test cases, the method further includes: converting the information in the truth world state table into standard protocol messages or cloud control commands; and sending the standard protocol messages or cloud control commands to the vehicle under test.

[0008] Optionally, the vehicle under test is tested according to the test cases, including: generating risk events according to the test cases, wherein the risk events include: network anomaly events, location anomaly events, and external data source anomaly events; determining the execution order of the risk events, and injecting the risk events into the vehicle under test in the order of execution for risk testing.

[0009] Optionally, after testing the vehicle under test according to the test cases, the method further includes: receiving response data returned by the vehicle under test corresponding to the test cases; obtaining the pass conditions for different function tests in the vehicle-to-everything (V2X) environment from the function rule base, and determining the quantitative index range of different functions from the performance threshold base; comparing the response data with the pass conditions and the quantitative index range respectively to obtain a first comparison result and a second comparison result; and determining the test result of the vehicle under test based on the first comparison result and the second comparison result.

[0010] Optionally, the response data and the range of quantitative indicators are compared, including: identifying key events from the original logs of the vehicle under test and identifying key response data corresponding to the key events, wherein the key response data includes the actual trajectory of the vehicle under test; obtaining the expected trajectory of the vehicle under test and comparing the actual trajectory with the expected trajectory to obtain the trajectory deviation; comparing whether the trajectory deviation is within the range of quantitative indicators to obtain a second comparison result.

[0011] Optionally, updating the test scenario library based on the test results includes: obtaining the target test case whose test result is a test failure, updating the target test case, and generating a new test case; updating the test scenario library based on the new test case; or, after obtaining the test results, comparing whether the version of the vehicle under test has changed before and after the test is executed; if the version of the vehicle under test has changed, updating the indicator thresholds in the performance threshold library, and adjusting the test scenario library based on the updated indicator thresholds.

[0012] According to another aspect of the embodiments of this application, a vehicle testing apparatus is also provided, comprising: an establishment module, configured to establish a communication connection between a vehicle under test and a testing system, wherein the testing system is used to test the functions of the vehicle under test in a vehicle-to-everything (V2X) environment, and the testing system and the vehicle under test use the same time base; a determination module, configured to determine a virtual test scenario for the vehicle under test in response to an operation instruction from a target object, and determine multiple test cases under different working conditions based on the virtual test scenario, wherein the test cases are used to test different functions of the vehicle under test in the V2X environment; and a testing module, configured to test the vehicle under test according to the test cases, and update the test scenario library according to the test results.

[0013] According to another aspect of the embodiments of this application, a vehicle testing system is also provided, comprising: a vehicle under test and a testing system, wherein a communication connection is established between the vehicle under test and the testing system, wherein the testing system is used to test the functions of the vehicle under test in a vehicle-to-everything (V2X) environment, and the testing system and the vehicle under test use the same time base; the testing system determines a virtual test scenario for the vehicle under test in response to an operation instruction from a target object, and determines multiple test cases under different working conditions based on the virtual test scenario, wherein the test cases are used to test different functions of the vehicle under test in the V2X environment; the vehicle under test is tested according to the test cases, and the test scenario library is updated according to the test results; the vehicle under test is used to return test results to the testing system in response to the test cases.

[0014] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device containing the non-volatile storage medium executes the above-described vehicle testing method by running the computer program.

[0015] In this embodiment, a communication connection is established between the vehicle under test (V2T) and the testing system. The testing system is used to test the functions of the V2T in a vehicle-to-everything (V2X) environment, and the testing system and the V2T use the same time base. A virtual test scenario for the V2T is determined in response to the operation instructions of the target object, and multiple test cases under different operating conditions are determined based on the virtual test scenario. These test cases are used to test different functions of the V2T in the V2X environment. The V2T is tested according to the test cases, and the test scenario library is updated based on the test results. This achieves the goal of closed-loop automatic testing of the vehicle, thereby realizing the technical effect of replayable test scenarios and solving the technical problems of poor cross-domain synchronization and insufficient scenario reproduction capability in related technologies. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0017] Figure 1 This is a hardware structure block diagram of a computer terminal for implementing a vehicle testing method according to an embodiment of this application;

[0018] Figure 2 This is a flowchart of a vehicle testing method according to an embodiment of this application;

[0019] Figure 3 This is a structural diagram of a vehicle testing device according to an embodiment of this application;

[0020] Figure 4 This is a structural diagram of a vehicle testing system according to an embodiment of this application;

[0021] Figure 5 This is a functional schematic diagram of a digital road and traffic generation module according to an embodiment of this application;

[0022] Figure 6 This is a functional diagram of a virtual-physical interface mirroring and time base unification module according to an embodiment of this application;

[0023] Figure 7 This is a functional diagram of a risk event orchestration and fault injection module according to an embodiment of this application;

[0024] Figure 8 This is a functional diagram of an online judgment and arbitration module according to an embodiment of this application;

[0025] Figure 9 This is a functional diagram of a result feedback and use case evolution module according to an embodiment of this application. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] First, some nouns or terms that appear in the explanation of the embodiments of this application shall be interpreted as follows:

[0029] The verification of V2X functions in related technologies mainly adopts three methods: First, conducting real-vehicle road tests by setting up RSUs, traffic lights, and target vehicles in a closed environment; second, conducting module-by-module tests on the communication protocol stack, application layer messages, and vehicle control logic; and third, using simulation software to conduct offline scenario playback. While these solutions can verify some functionalities, they mostly remain at the "single-link" or "single-domain" testing stage, making it difficult to form a closed-loop automated testing system that synchronously links the vehicle, road, cloud, and network links. Therefore, the solutions in these technologies have the following shortcomings:

[0030] 1. Poor cross-domain synchronization: Existing tests typically verify communication messages, sensing inputs, and control outputs separately, lacking a unified clock and event alignment mechanism, making it difficult to accurately assess the real impact of V2X message delays, packet loss, and out-of-order delivery on vehicle decisions.

[0031] 2. Insufficient ability to reproduce scenarios: Real vehicle road tests rely on time, weather and site conditions, and high-risk scenarios such as complex intersections, obscured targets, sudden construction, and weak edge networks are difficult to reproduce stably and frequently.

[0032] 3. Weak fault injection capability: Existing solutions have difficulty injecting various faults in a controllable manner, such as RSU anomalies, MAP / SPAT (Signal Phase and Timing) message errors, positioning drift, network jitter, and cloud control transmission anomalies, resulting in insufficient robustness verification.

[0033] 4. Inconsistent evaluation of results: There is a lack of automatic scoring models for V2X collaborative functions. Test results mostly rely on manual interpretation of logs, making it difficult to form a production line test closed loop that is traceable, comparable, and batch-executable.

[0034] To address the problems existing in related technologies, this application provides a vehicle testing method that can be run on... Figure 1 The computer terminal shown is explained below.

[0035] The vehicle testing method embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing a vehicle testing method is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions connected via wired and / or wireless networks. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0036] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0037] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the vehicle testing method in this embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned vehicle testing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0038] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0039] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0040] It should be noted here that, in some optional embodiments, the above... Figure 1 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0041] In the above operating environment, this application provides a vehicle testing method embodiment. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

[0042] Figure 2 This is a flowchart of a vehicle testing method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0043] Step S202: Establish a communication connection between the vehicle under test and the test system. The test system is used to test the functions of the vehicle under test in the vehicle network environment. The test system and the vehicle under test use the same time base.

[0044] In step S202 above, the test system can be a control terminal located on the server side and can interact with the actual vehicle under test (V2X). For example, the test system can send control commands to the V2X, including starting the test and injecting faults. The test system can also collect real-time data from the V2X (such as CAN bus data, vehicle speed, steering angle, and V2X messages received by the OBU). Therefore, the communication channel between the V2X and the test system is a bidirectional control and feedback channel. The test system can simulate the external environment required for V2X, including roadside infrastructure (RSU), other traffic participants, and cloud platforms. Its testing focus for the V2X includes not only traditional ADAS functions but also V2X-specific functions such as forward collision warning (FCW), intersection coordination, and blind spot perception.

[0045] In traditional vehicle testing, the clocks of the simulation software, RSU, vehicle ECU, and data acquisition card are often independent. Because timestamps cannot be aligned, it's difficult to determine whether a deviation in testing is due to a late message or a slow vehicle response. In this embodiment, GNSS (Global Navigation Satellite System), PTP (Precision Time Protocol), or a software master clock are used to synchronize the test controller, RSU simulator, OBU / TCU (Telematics Control Unit), and onboard bus data acquisition equipment to the same absolute time (e.g., UTC). This ensures the test system and the vehicle under test use the same time base, allowing for precise calculation of communication and response delays to accurately assess the real impact of V2X message latency and packet loss on vehicle decision-making.

[0046] Step S204: In response to the operation instructions of the target object, determine the virtual test scenario of the vehicle under test, and determine multiple test cases under different working conditions based on the virtual test scenario. The test cases are used to test the different functions of the vehicle under test in the vehicle network environment.

[0047] In step S204 above, the target object can be a test engineer, an automated scheduling platform, or host computer software, etc., and the operation instruction can be clicking the start test button, selecting a test item, or uploading a specific test script, etc. After receiving the operation instruction, the test system generates a corresponding virtual test scenario. This virtual test scenario can be, for example, a virtual traffic environment built in a digital twin environment, including road geometry (intersections, highway ramps), traffic participants (virtual vehicles, pedestrians), traffic facilities (traffic lights, road signs), and weather and lighting conditions, etc.

[0048] Specifically, the testing system retrieves or generates a logically consistent scenario from the scenario library based on the operation command. For example, if the operation command is "test intersection coordination," the testing system will generate a complex intersection scenario that includes traffic lights, oncoming traffic, and the current lane. Different operation commands correspond to different virtual test scenarios; for example, the "test construction zone" command corresponds to a road construction scenario, and the "test blind spot perception" command corresponds to an intersection occlusion scenario.

[0049] Virtual testing scenarios also include different operating conditions, which refer to different combinations or states of parameters under a specific scenario. Normal operating conditions include, for example, green light passage and clear weather; extreme operating conditions include, for example, red light emergency braking and low light at night; abnormal operating conditions include, for example, network packet loss, location drift, and RSU offline.

[0050] A test case is a specific, executable set of test steps. Based on a virtual test scenario, the test system automatically or semi-automatically generates test cases covering various operating conditions. For example, in a virtual test scenario of a "crossroads," the test system can generate the following test case conditions:

[0051] Test Case 1: Normal green light passage (normal operating conditions);

[0052] Test Case 2: Braking 0.5 seconds before the red light turns on (emergency situation);

[0053] Test Case 3: Response when communication latency exceeds 200ms (fault condition);

[0054] Test Case 4: Degradation handling when GNSS signal is lost (fault condition).

[0055] The generated test cases can flexibly and automatically cover various complex V2X application scenarios without the need for manual writing of each test step, thereby improving testing efficiency.

[0056] Step S206: Test the vehicle under test according to the test cases, and update the test scenario library based on the test results.

[0057] In step S206 above, test cases may include scenario parameters, operating conditions, and expected results. Based on the test cases, the test system generates corresponding virtual traffic flows (e.g., generating a virtual vehicle cutting in at a specific distance) through the digital road and traffic generation module, and generates V2X messages (e.g., RSM (Road Side Message) collision warning messages) to send to the OBU of the actual vehicle under test. If the test cases also include fault conditions (e.g., packet loss), the test system will simulate interference via a wireless link at a specified time point and record the vehicle under test's reactions in real time (e.g., braking, steering, logs, video, etc.). The test system compares the actual actions of the vehicle under test with the expected results in the test cases to determine whether the test passes, thereby verifying the functional correctness, performance indicators (latency, accuracy), and robustness of the vehicle under test in a specific V2X scenario.

[0058] In the event of a test failure, the testing system analyzes the cause of the failure. For example, when the vehicle speed is greater than 80 km / h and the network latency is greater than 150 ms, the vehicle is prone to false alarms. This yields a boundary condition or failure mode. The testing system automatically encapsulates this boundary condition (high vehicle speed + high latency) into a new standard test case and stores it in the test scenario library. Simultaneously, it updates the scoring threshold or test rule library (e.g., adjusting the "acceptable maximum latency" from 200 ms to 150 ms). When testing a new version of the vehicle's software next time, the testing system automatically runs the new standard test case to ensure that the previous defect does not reappear.

[0059] Through steps S202 to S206 above, the goal of closed-loop automatic vehicle testing is achieved, thereby realizing the technical effect of replayable test scenarios and solving the technical problems of poor cross-domain synchronization and insufficient scenario reproducibility in related technologies. The following is an explanation.

[0060] In step S204 above, determining the virtual test scenario for the vehicle under test in response to the operation instructions of the target object includes: receiving the operation instructions from the target object, wherein the operation instructions represent the test target of the vehicle under test; obtaining the initial state information of the vehicle under test, wherein the initial state information includes the software version number, vehicle model parameters, and communication configuration; determining the truth world state table corresponding to the initial state information from the test scenario library according to the operation instructions, wherein the truth world state table includes at least one of the following: real-time updated road topology information, participant trajectory information, and external event state information; and generating a virtual test scenario based on the truth world state table.

[0061] In some embodiments of this application, during the generation of virtual test scenarios, the test objective of the vehicle under test is first determined based on the operation instructions. For example, the test objective could be: testing the unprotected left-turn function of vehicle model A in heavy rain. After clarifying the test objective, the test system needs to obtain the initial state information of the vehicle under test, including the software version number, vehicle parameters (including vehicle size, wheelbase, maximum acceleration / deceleration, sensor range, etc.), and communication configuration (including OBU type, supported protocol version, antenna gain, receiver sensitivity, etc.). Based on the operation instructions and the previously obtained initial state information, the test system selects a suitable truth-world state table from the test scenario library. For example, if the vehicle under test does not support a certain function (such as not supporting V2V direct communication), the test system will automatically filter out complex scenarios that rely on V2V direct connection, or mark that part of the test as "not applicable." This ensures the compatibility and relevance of the scenario data, avoiding the loading of data that the vehicle under test cannot process or that is irrelevant.

[0062] The true world state table stored in the test scenario library refers to the simulated digital truth table, which can include: real-time updated road topology information, participant trajectory information, and external event state information. Road topology information includes lane position, curvature, slope, speed limit, traffic light position, and phase timing. During testing, this road topology information changes over time (e.g., traffic lights change from green to red). Participant trajectory information includes the position, velocity, and acceleration sequence of other vehicles, pedestrians, and non-motorized vehicles in space (X, Y, Z) and time (T). External event state information includes weather conditions (rain / snow / fog), lighting conditions, road construction areas, temporary traffic control, etc. This external event state information is used to simulate the impact of harsh environments on sensors and communication.

[0063] After reading the data from the truth world state table, the testing system transforms it into visualized 3D graphics (road, vehicle models, and pedestrian models) and drives the movement of virtual traffic participants based on trajectory information; it calculates collision risks based on road topology information; and it adjusts environmental effects (such as screen blurring effects in rainy weather) based on external state event information, thereby generating a virtual test scenario.

[0064] In step S206 above, before testing the vehicle under test according to the test cases, the method further includes: converting the information in the truth world state table into standard protocol messages or cloud control commands; and sending the standard protocol messages or cloud control commands to the vehicle under test.

[0065] In some embodiments of this application, before the vehicle under test (VUT) can actually react (e.g., brake, steer), the environmental information of the current virtual test scenario must be sent to the VUT. Since the truth world state table is an internal data structure containing raw physical quantities (e.g., coordinates of the center point of an intersection, 5 seconds remaining on a red light, an obstacle 50 meters ahead), and the VUT (OBU / TCU) cannot directly read this internal data structure, but can only receive protocol messages conforming to communication standards, the test system needs to first convert the data in the virtual test scenario into a format that the VUT can understand before sending it.

[0066] Specifically, the traffic infrastructure information in the state table is converted into SPAT (Signal Phase and Time) and MAP (High-Precision Map) messages, the traffic participant (virtual vehicle / person) information is converted into RSM (Roadside Message, such as Road Safety Message) or BSM (Basic Safety Message) messages, and the road construction or accident information is converted into RSI (Road Side Infrastructure, such as Road Construction Information) messages. If the test involves a cloud control platform (such as remote speed limit, fleet collaboration), the test system converts the instructions in the truth world state table into cloud control instructions (e.g., based on private protocols or standard API formats) to ensure that the vehicle protocol stack can be correctly parsed. The SPAT / MAP / RSM messages generated by the test system are transmitted by the RSU simulator through the roadside equipment mirror unit and pass through the simulated wireless channel (which may include delay, packet loss, and interference) to finally reach the OBU (On-Board Unit) or TCU (Telematics Unit) of the vehicle under test. Meanwhile, the terminal control commands can be sent to the T-BOX (Telematics BOX) of the vehicle under test through the 4G / 5G network.

[0067] In step S206 above, the vehicle under test is tested according to the test cases, including: generating risk events according to the test cases, wherein the risk events include: network anomaly events, location anomaly events, and external data source anomaly events; determining the execution order of the risk events, and injecting the risk events into the vehicle under test in the order of execution for risk testing.

[0068] In some embodiments of this application, abnormal situations to be simulated are dynamically generated based on the current test cases. Specifically, the test system extracts the fault types to be injected from the test cases and instantiates them into specific risk events. Risk events include, but are not limited to, network anomaly events, location anomaly events, and external data source anomaly events. Among them, network anomaly events are used to simulate problems on the wireless communication link to test the performance of the V2X function under communication quality fluctuations. Examples include: high latency (late message arrival), packet loss (message loss), out-of-order delivery (messages arrive in the wrong order), bandwidth limitation (slow network speed), and signal interruption. Location anomaly events are used to simulate errors in GNSS (Global Navigation Satellite System) or IMU (Inertial Measurement Unit). Examples include: location drift (sudden change in position), location loss (complete signal interruption), and reduced accuracy (error changes from 1 meter to 10 meters). External data source anomaly events are used to simulate errors in the V2X messages themselves or cloud data to test the vehicle's fault tolerance. Examples include: the RSU sending an incorrect SPAT message (such as a green light displaying as a red light), an incorrect RSM message field, or a cloud control command timeout or format error.

[0069] After identifying risk events, it's necessary to plan the timeline and logical sequence of fault occurrences. For example, a fault injection sequence can be constructed based on test cases to determine the start time, duration, and end time of each fault. During testing, when a preset time point is reached, the scheduler activates the corresponding fault module to perform fault injection, and the response of the vehicle under test is observed. For instance, at T=10s, a network anomaly (such as intercepting and dropping data packets) is injected into the wireless channel (i.e., link layer) between the RSU simulator and the OBU; at T=30s, in the data layer, the content of the upcoming SPAT / RSM message is modified (such as tampering with the timestamp) to simulate an external data source anomaly; at T=50s, in the bus layer, the positioning data signal sent to the ECU is modified to simulate a positioning anomaly. By monitoring the behavior of the vehicle under test in real time, including speed, braking, steering, and alarm prompts, it can be determined whether the vehicle under test has performed the expected degrading action (e.g., downgrading from "cooperative automated driving" to "driver takeover" or "conservative driving").

[0070] In step S206 above, after testing the vehicle under test according to the test cases, the method further includes: receiving response data returned by the vehicle under test corresponding to the test cases; obtaining the pass conditions for different function tests in the vehicle network environment from the function rule base, and determining the quantitative index range of different functions from the performance threshold base; comparing the response data with the pass conditions and the quantitative index range respectively to obtain a first comparison result and a second comparison result; and determining the test result of the vehicle under test based on the first comparison result and the second comparison result.

[0071] In some embodiments of this application, during test operation, the test system collects all response data generated by the vehicle under test in real time through the vehicle bus mirror unit, log interface, or cloud interface, including: (1) control commands: braking requests, steering angle, throttle opening, etc. issued by the ECU; (2) status feedback: current vehicle speed, position coordinates, acceleration, etc.; (3) interactive information: message list received by the OBU, warning information displayed on the instrument panel (such as "FCW alarm", "AEB (Autonomous Emergency Braking) activated"); (4) system status: working status of the V2X module, degrade mode flag, etc. The test results of the vehicle under test are determined by comparing the response data with the pass conditions and quantitative index range.

[0072] The functional rule base stores logical judgment rules, including those based on regulations (such as GB standards), enterprise standards, or test case requirements. An example of such conditions is shown below:

[0073] FCW (Forward Collision Warning): The condition for passing is that "a visual or audible warning must be issued when TTC < 2.5s";

[0074] ICW (Red Light Warning): The condition for passing through is "when the traffic light is red and the vehicle has not stopped, an alarm must be triggered";

[0075] Degradation strategy: The condition for passing is that "when RSM messages are lost for more than 3 seconds, the collaboration function must be downgraded to rely only on local sensors".

[0076] The performance threshold library stores numerical limits used to measure the quality and efficiency of vehicle behavior. Examples of quantifiable metric ranges are shown below:

[0077] Message latency: The latency from when a SPAT message is sent from the RSU to when it is received by the OBU must be less than 100ms;

[0078] Trajectory deviation: The lateral deviation between the actual driving trajectory and the expected trajectory of the vehicle must be less than 0.5 meters;

[0079] Braking response time: The time from issuing a braking command to the actual generation of braking force by the wheels must be less than 0.5 seconds;

[0080] Warning lead time: The FCW alarm distance must be greater than 50 meters.

[0081] The behavior logic of the vehicle under test is compared with the functional rules, that is, the response data is compared with the passage conditions. For example, the response data is: the vehicle under test receives a red light signal, but does not alarm, and passes directly; the passage condition is: the red light must alarm, thus the first comparison result (used to indicate that the functional logic) is failure.

[0082] The vehicle's quantitative data is compared with the performance threshold, that is, the response data is compared with the quantitative index range. For example, the response data is: when the test vehicle alarms, there are only 1.0 seconds left before the collision point (TTC); the quantitative index range is: TTC must be > 2.0 seconds to be considered a valid warning. Thus, the second comparison result (used to represent the performance index) is not up to standard.

[0083] When determining the test result of the vehicle under test based on the first comparison result and the second comparison result, a comprehensive judgment can be made. For example, if both the first comparison result and the second comparison result are successful or meet the standard, the test result of the vehicle under test is determined to be passed; otherwise, it is considered to be failed.

[0084] In the above steps, the response data and the range of quantitative indicators are compared, including: identifying key events from the original logs of the vehicle under test and identifying key response data corresponding to the key events, wherein the key response data includes the actual trajectory of the vehicle under test; obtaining the expected trajectory of the vehicle under test and comparing the actual trajectory with the expected trajectory to obtain the trajectory deviation; comparing whether the trajectory deviation is within the range of quantitative indicators to obtain a second comparison result.

[0085] In some embodiments of this application, due to the large amount of data generated by the vehicle under test in the original log, it is necessary to identify key events, such as the V2X message reception time, warning alarm time, braking command issuance time, vehicle initiation of steering time, and vehicle crossing the stop line time. Based on these key events, corresponding key response data is determined. For example, in determining the vehicle trajectory, key response data includes the actual trajectory of the vehicle under test, i.e., the sequence of the vehicle's position changing over time in the real physical world (which may include latitude and longitude, heading angle, vehicle speed, etc.). This can be obtained through high-precision positioning data acquired by the onboard GPS / GNSS module, or calculated using wheel speed sensors and steering angle sensors combined with a vehicle kinematics model. The desired trajectory of the vehicle under test can be predefined according to the test cases. For example, in the "unprotected left turn" scenario, the desired trajectory is an ideal curve that smoothly transitions from the current lane to the target lane and conforms to the vehicle's dynamic limits.

[0086] The testing system spatially compares the actual trajectory points with the expected trajectory points at the same timestamp, calculates the trajectory deviation between the two (which may include lateral deviation, longitudinal deviation, heading angle deviation, etc.), and determines whether the trajectory deviation exceeds the quantitative index range (i.e., the allowable range). If the trajectory deviation is consistently within the allowable range, it indicates that the control of the vehicle under test is accurate, and the second comparison result is pass or meet the standard. If the trajectory deviation exceeds the allowable range, it indicates that the control of the vehicle under test is unstable, and the second comparison result is fail or not meet the standard.

[0087] In step S206 above, updating the test scenario library based on the test results includes: obtaining the target test case whose test result is a test failure, updating the target test case, and generating a new test case; updating the test scenario library based on the new test case; or, after obtaining the test results, comparing whether the version of the vehicle under test has changed before and after the test is executed; if the version of the vehicle under test has changed, updating the indicator thresholds in the performance threshold library, and adjusting the test scenario library based on the updated indicator thresholds.

[0088] In some embodiments of this application, when the target test case fails, the testing system analyzes the cause of the failure (e.g., the vehicle did not trigger a warning at a specific speed and with a specific time delay) to obtain the boundary conditions or failure mode, i.e., the combination of the aforementioned specific speed and specific time delay. This boundary condition is then solidified to generate a new standard test case. The generated new test case and its corresponding scenario parameters (road topology, traffic flow, event sequence) are stored in the test scenario library.

[0089] In some alternative embodiments, after each test, the testing system checks whether the software version number of the vehicle under test has changed before and after the test. If the version remains unchanged, no adjustment is needed; if the version has changed, it indicates that the algorithm or logic of the vehicle under test may have been updated, and the original test standards need to be adjusted. For example, the average response latency of OBU version V1.0 is 50ms, and the threshold is set to 100ms. Version V2.0 optimizes the protocol stack, reducing the average latency to 20ms. If 100ms is continued as the threshold, although it can pass, the optimization effect cannot be reflected, and it may even mask new performance degradation issues. Therefore, it is necessary to update the indicator thresholds in the performance threshold library, adjust the test scenario library according to the updated indicator thresholds, and generate new virtual test scenarios to conduct a new round of testing on the vehicle under test.

[0090] The vehicle testing method provided in this application not only offers a digital twin closed-loop automatic testing system for intelligent connected vehicle V2X collaborative scenarios, realizing unified orchestration and automatic verification of vehicle-side, road-side, cloud-side, and network links, but also provides configurable scenario-driven, network disturbance, and fault injection mechanisms, covering functional and performance testing under normal, extreme, and abnormal operating conditions. By establishing a unified clock synchronization, data acquisition, and automatic scoring model, it supports batch regression testing, version comparison testing, and automatic generation of test reports. This achieves the following beneficial effects: 1. Closed-loop testing: Coupling digital scenarios, wireless communication, roadside equipment simulation, vehicle-in-the-loop testing, and the evaluation engine into a unified platform, it can realistically reflect the impact of V2X collaborative links on vehicle functionality; 2. Replayability and scalability: The same test case can accurately replay scenario scripts, communication interference, and fault events, facilitating defect reproduction, algorithm iteration, and version regression; 3. Automatic quantitative evaluation: Automatically outputting key indicators such as message latency, trigger timing, trajectory deviation, warning lead time, false alarm rate, and missed alarm rate, reducing manual analysis costs; 4. Support for engineering implementation: It can be used for SIL / HIL / Vehicle-in-the-loop verification in the R&D phase, as well as for bench testing and conformance acceptance in the pre-mass production phase, improving testing efficiency and coverage.

[0091] Figure 3 This is a structural diagram of a vehicle testing device according to an embodiment of this application, such as... Figure 3 As shown, the vehicle testing apparatus includes:

[0092] Module 30 is established to establish a communication connection between the vehicle under test and the test system. The test system is used to test the functions of the vehicle under test in the vehicle network environment. The test system and the vehicle under test use the same time base.

[0093] The determination module 32 is used to determine the virtual test scenario of the vehicle under test in response to the operation instructions of the target object, and to determine multiple test cases under different working conditions based on the virtual test scenario. The test cases are used to test the different functions of the vehicle under test in the vehicle network environment.

[0094] Test module 34 is used to test the vehicle under test according to the test cases and update the test scenario library based on the test results.

[0095] By establishing, determining, and testing the aforementioned vehicle testing device, the goal of closed-loop automatic vehicle testing is achieved, thereby realizing the technical effect of replayable test scenarios and solving the technical problems of poor cross-domain synchronization and insufficient scenario reproduction capability in related technologies.

[0096] In the aforementioned determining module, the determining module is further configured to receive operation instructions from the target object, wherein the operation instructions represent the test target of the vehicle under test; acquire the initial state information of the vehicle under test, wherein the initial state information includes software version number, vehicle model parameters, and communication configuration; determine the truth world state table corresponding to the initial state information from the test scenario library based on the operation instructions, wherein the truth world state table includes at least one of the following: real-time updated road topology information, participant trajectory information, and external event state information; and generate a virtual test scenario based on the truth world state table.

[0097] In the aforementioned test module, the test module is also used to convert the information in the truth world state table into standard protocol messages or cloud control commands; and to send the standard protocol messages or cloud control commands to the vehicle under test.

[0098] In the aforementioned testing module, the module is also used to generate risk events based on test cases. These risk events include: network anomaly events, location anomaly events, and external data source anomaly events. The module determines the execution order of the risk events and injects them into the vehicle under test in the order of execution to perform risk testing.

[0099] In the aforementioned testing module, the testing module is also used to receive response data returned by the vehicle under test corresponding to the test cases; obtain the pass conditions for different function tests in the vehicle networking environment from the function rule base, and determine the quantitative index range of different functions from the performance threshold base; compare the response data with the pass conditions and the quantitative index range respectively to obtain the first comparison result and the second comparison result; and determine the test result of the vehicle under test based on the first comparison result and the second comparison result.

[0100] In the aforementioned test module, the test module is also used to identify key events from the original logs of the vehicle under test and to identify key response data corresponding to the key events. The key response data includes the actual trajectory of the vehicle under test; to obtain the expected trajectory of the vehicle under test and to compare the actual trajectory with the expected trajectory to obtain the trajectory deviation; and to compare whether the trajectory deviation is within the range of quantitative indicators to obtain a second comparison result.

[0101] In the aforementioned testing module, the module is also used to obtain target test cases that have failed, update the target test cases, and generate new test cases; update the test scenario library based on the test cases; or, after obtaining the test results, compare whether the version of the vehicle under test has changed before and after the test is executed; if the version of the vehicle under test has changed, update the indicator thresholds in the performance threshold library, and adjust the test scenario library according to the updated indicator thresholds.

[0102] It should be noted that, Figure 3 The vehicle testing apparatus shown is used to perform Figure 2 The vehicle testing method shown above is also applicable to this vehicle testing device, and will not be repeated here.

[0103] Figure 4 This is a structural diagram of a vehicle testing system according to an embodiment of this application, such as... Figure 4 As shown, the vehicle testing system 40 includes a vehicle under test (V2) 42 and a testing system 44. A communication connection is established between the V2 and the testing system. The testing system is used to test the functions of the V2 in a vehicle-to-everything (V2X) environment. The testing system and the V2 use the same time base. The testing system determines a virtual test scenario for the V2 in response to the operation instructions of the target object, and determines multiple test cases under different operating conditions based on the virtual test scenario. The test cases are used to test different functions of the V2 in the V2X environment. The testing system performs tests on the V2 according to the test cases and updates the test scenario library based on the test results. The V2 responds to the test cases and returns test results to the testing system.

[0104] Figure 4 The test system 44 shown can be composed of a test master control and scheduling state machine, a scenario planning and regulatory labeling module, a digital road and traffic generation module, a V2X message mapping and forwarding module, a virtual-real interface mirroring and time base unification module, a risk event orchestration and fault injection module, an online judgment and arbitration module, and a result feedback and test case evolution module. These modules are not simply connected in series, but rather form a multi-round closed loop of "scenario generation - message delivery - vehicle response - automatic judgment - result feedback" through a unified state table (i.e., a truth-world state table) and a unified timeline. The functions of some of the above modules are shown below:

[0105] Test master control and scheduling state machine: used to manage test case loading, device initialization, execution order, abnormal pause, breakpoint resume and batch regression plan;

[0106] The scenario planning and regulatory labeling module is used to map rules, regulations, enterprise standards, issue tickets, and historical failure cases into executable test targets.

[0107] Digital Road and Traffic Generation Module: Used to generate road geometry, traffic light phases, target vehicle / pedestrian / non-motorized vehicle trajectories, and road occupancy information in construction zones in real time;

[0108] The Results Feedback and Test Case Evolution module is used to feed back failure reasons, boundary conditions, and version differences into the test scenario library, forming a continuously expandable test asset.

[0109] The following is a brief explanation of each module in conjunction with the testing process:

[0110] For example, the scenario planning and regulatory labeling module schedules the test master controller and scheduling state machine to obtain the initial state information of the vehicle under test and determine the test objectives of the vehicle under test. The digital road and traffic generation module generates a virtual test scenario for the vehicle under test. The V2X message mapping and forwarding module forwards the virtual test scenario and test-related messages to the OBU domain controller of the vehicle under test. The V2X message mapping and forwarding module also returns the test response data of the vehicle under test to the test system. The virtual-physical interface mirroring and time base unification module realizes the data conversion and interaction between the virtual test scenario and the vehicle under test, and unifies all devices and modules to the same time base. The risk event orchestration and fault injection module realizes the injection of risks and faults into the vehicle under test. The online judgment and arbitration module judges the test results of the vehicle under test. The result feedback and test case evolution module feeds back the reasons for test failures to the test scenario library and updates the test cases.

[0111] The digital road and traffic generation module includes traffic element generation and message mapping processes. The mapping flowchart consists of a road topology generation unit, a participant trajectory generation unit, an event trigger, a truth world state table, a message mapping unit, and an interface mirroring unit. This digital road and traffic generation module no longer uses the four-segment structure of "environment simulation platform - data acquisition - algorithm analysis - result output," but is reorganized around the "truth-driven message, message-driven vehicle" logic in V2X testing.

[0112] like Figure 5 As shown, the road topology generation unit is used to construct different road topologies such as intersections, ramps, main and auxiliary roads, and construction detours, and to set lane attributes, speed limits, and phase timing; the participant trajectory generation unit is used to generate continuous trajectories of social vehicles, pedestrians, non-motorized vehicles (such as cyclists), and obstacles occupying the road; the event triggers trigger external events such as accidents ahead, lane occupancy, traffic light switching, speed limit changes, and construction based on time, location, speed, or relative distance; the truth world state table uniformly maintains the state of traffic elements and performs message mapping, such as converting them into SPAT, MAP, RSM, RSI, or cloud control commands, and sending them to the vehicle under test through interface mirroring.

[0113] The virtual-real interface mirroring and time base unification module consists of a unified timing unit, an on-board bus mirroring unit, a protocol stack mirroring unit, a roadside device mirroring unit, a timestamp bus, and a status feedback unit. This module is used to handle the one-to-one mirroring relationship between "virtual scene objects" and "real interfaces under test," enabling each truth event within the scene to be mapped to real protocol messages, bus signals, or cloud control calls.

[0114] Specifically, such as Figure 6As shown, the unified timing unit uses GNSS, PTP, or software master clock to perform unified time calibration for the scene engine, interface devices, and acquisition server; the vehicle bus mirroring unit is used to collect vehicle status and control feedback from CAN (Controller Area Network) / CANFD (CAN with Flexible Data-Rate) and vehicle Ethernet; the protocol stack mirroring unit and roadside equipment mirroring unit are used to synchronize and cache the OBU / TCU protocol processing link and the RSU simulator broadcast link, respectively, that is, to cache the data of the timestamp bus and the mirror; the status feedback unit writes back vehicle speed, trajectory, braking, steering, message transmission and reception time, and instrument prompts to the digital scene through aligned writing, forming a real-time closed loop that is consistent between the virtual and real worlds.

[0115] The risk event orchestration and fault injection module consists of a link disturbance submodule, a location anomaly submodule, a roadside / cloud-side anomaly submodule, and a degradation monitoring submodule. For example... Figure 7 As shown, the insertion order of multiple anomalies and their impact on vehicle behavior during the same test are displayed in a timeline format. Specifically, the link disturbance submodule injects network anomalies such as fixed delay, random jitter, packet loss, out-of-order delivery, or bandwidth limitations within a specified time window; the location anomaly submodule simulates GNSS drift, IMU offset, or location jumps under specified trigger conditions; the roadside / cloud-side anomaly submodule simulates anomalies such as RSU offline, cloud control timeout, message field errors, and phase data conflicts; and the degradation monitoring submodule records the trigger times for the vehicle under test entering warning, speed limit, manual takeover, or exiting cooperative control.

[0116] like Figure 8 As shown, the online judgment and arbitration module consists of a functional rule base, a performance threshold base, an event identifier, a trajectory deviation calculator, a causal arbitrator, a failure locator, and a comprehensive scorer. The online judgment and arbitration module does not simply statistically analyze test results; instead, it performs layered arbitration on whether the message is correct, whether the vehicle correctly understands it, and whether the vehicle responds correctly. Specifically, the functional rule base defines event passage conditions based on different V2X functions, such as red light restrictions, collision risk warnings, construction zone speed limits, and weak network degradation prompts; the performance threshold base defines quantitative indicator ranges such as message latency, response lead time, braking trigger time, trajectory deviation, and minimum TTC (Time To Collision); the event identifier and trajectory deviation calculator extract key events from the raw logs and calculate the deviation between the expected trajectory and the actual trajectory; the causal arbitrator and failure locator distinguish different failure sources such as communication failures, interface adaptation failures, policy misunderstandings, or execution control lags; finally, the comprehensive scorer performs judgment and scoring and outputs a conclusion.

[0117] like Figure 9 As shown, the result backfeeding and test case evolution module consists of a batch execution result pool, a failure clustering unit, a version comparison unit, a new test case generation unit, a threshold update unit, and a scenario library backfeeding unit. After multiple rounds of regression testing, the result backfeeding and test case evolution module can automatically precipitate boundary conditions into new standard test cases.

[0118] Based on the above modules, the closed-loop automatic testing process of this application embodiment includes: loading regulatory requirements and enterprise testing objectives by the main control scheduler; constructing a true scenario by the digital road and traffic generation module; outputting corresponding messages and signals to the vehicle under test by the interface mirroring module; inserting anomalies in key windows by the fault injection module; outputting test conclusions by the online judgment and arbitration engine; and finally updating the scenario asset library by the result feedback module.

[0119] The vehicle testing process is described below with reference to specific embodiments:

[0120] Example 1: Test of unprotected left turn coordination at intersection.

[0121] Step 1: Connect the vehicle under test, domain controller, OBU / TCU, RSU simulator and test master server in a closed test environment, and read the software version number, vehicle parameters and communication configuration;

[0122] Step 2: Select the "Unprotected Left Turn Cooperative Traffic" scenario, and set the intersection lane topology, traffic light phase table, oncoming straight-through vehicle trajectory, and the vehicle's target path;

[0123] Step 3: Start the unified time synchronization unit to synchronize the time of the scene engine, message forwarding device, bus acquisition device and the vehicle under test, and establish a unified event time base;

[0124] Step 4: Generate MAP and SPAT messages in real time from the truth world state table, and broadcast cooperative passage information to the vehicle under test before oncoming straight-ahead vehicles enter the conflict area;

[0125] Step 5: When the vehicle under test approaches the stop line, the event trigger inserts two types of test branches according to the preset strategy: one is the normal communication branch, and the other is the SPAT jitter superimposed RSU instantaneous offline branch.

[0126] Step 6: Collect the instrument prompts, braking requests, steering trajectory, vehicle speed changes, message reception logs, and collaborative control status of the vehicle under test, and simultaneously feed them back into the digital twin scenario;

[0127] Step 7: The online judgment and arbitration engine determines whether the vehicle under test has completed the left turn under the permitted passage conditions, or whether it has entered the deceleration waiting state or exited the cooperative control state when the risk increases or the message is abnormal;

[0128] Step 8: If the test fails, the failure locator outputs the source of the failure, such as excessive message delay, incorrect signal phase interpretation, abnormal identification of conflicting vehicles, or delayed execution control.

[0129] Example 2: Construction Zone Speed ​​Limit Coordination and Weak Network Degradation Test. First, generate construction zone lane occupancy, temporary speed limit signs, and roadside broadcast messages in a highway scenario. Second, gradually increase link jitter and packet loss rate as the vehicle approaches the construction zone, and superimpose slight GNSS drift. Finally, evaluate whether the test vehicle receives the speed limit information within the specified distance, smoothly reduces speed, and provides a degradation prompt rather than erroneous execution when the message reliability is insufficient.

[0130] This application's vehicle testing process integrates digital twin scenarios, vehicle-side control, roadside broadcasting, cloud control interfaces, and network disturbances into a unified testing loop, no longer limited to single-domain testing of communication or the entire vehicle. Furthermore, through unified timing and end-to-end timestamp alignment mechanisms, it enables causal correlation analysis of V2X messages, scenario truth values, and vehicle behavior, improving the interpretability of test results. Configurable message-level fault injection, link disturbance injection, and device anomaly injection systematically verify anomaly handling and degradation strategies for V2X collaborative functions. An automatic evaluation model enables batch execution, automatic scoring, and version regression of regulatory scenarios, customer scenarios, and problem reproduction scenarios, making it suitable for R&D and pre-production testing.

[0131] It should be noted that in the vehicle testing process, a pure software-in-the-loop (SIL) approach can be used to achieve partial closed-loop testing, in which virtual OBUs, virtual RSUs, and virtual vehicle models can be used to replace some physical equipment; or a vehicle-in-the-loop (HIL) approach or a physical vehicle turntable approach can be used to replace some road traffic participant models to improve the realism of vehicle-level actuator response testing; or a cellular network simulator, radio frequency channel simulator, or recording and playback device can be used to replace network disturbance units, etc.

[0132] It should be noted that, Figure 4 The vehicle testing system shown is used to perform Figure 2 The vehicle testing method shown above is also applicable to this vehicle testing system, and will not be repeated here.

[0133] This application also provides an electronic device, which includes a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the above-described vehicle testing method.

[0134] This application also provides a non-volatile storage medium including a stored computer program, wherein the device containing the non-volatile storage medium executes the above-described vehicle testing method by running the computer program.

[0135] This application also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the vehicle testing method in various embodiments of this application.

[0136] This application also provides a computer program that, when executed by a processor, implements the steps of the vehicle testing method in various embodiments of this application.

[0137] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0138] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0139] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0140] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0141] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0143] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A vehicle testing method, characterized in that, include: Establish a communication connection between the vehicle under test and the test system, wherein the test system is used to test the functionality of the vehicle under test in a vehicle networking environment, and the test system and the vehicle under test use the same time base; In response to the operation instructions of the target object, a virtual test scenario for the vehicle under test is determined, and multiple test cases under different working conditions are determined based on the virtual test scenario. The test cases are used to test different functions of the vehicle under test in the vehicle network environment. The vehicle under test is tested according to the test cases, and the test scenario library is updated based on the test results.

2. The method according to claim 1, characterized in that, Determining the virtual test scenario for the vehicle under test in response to an operation command from the target object includes: Receive the operation instruction of the target object, wherein the operation instruction is used to represent the test target of the vehicle under test; Obtain the initial state information of the vehicle under test, wherein the initial state information includes software version number, vehicle model parameters and communication configuration; According to the operation instructions, a truth world state table corresponding to the initial state information is determined from the test scenario library, wherein the truth world state table includes at least one of the following: real-time updated road topology information, participant trajectory information, and external event state information; The virtual test scenario is generated based on the truth world state table.

3. The method according to claim 2, characterized in that, Before testing the vehicle under test according to the test cases, the method further includes: The information in the truth world state table is converted into standard protocol messages or cloud control commands. The standard protocol message or the cloud control command is sent to the vehicle under test.

4. The method according to claim 1, characterized in that, The vehicle under test is tested according to the test cases, including: Risk events are generated based on the test cases, including: network anomaly events, location anomaly events, and external data source anomaly events. The execution order of the risk events is determined, and the risk events are injected into the vehicle under test in the order of execution to conduct risk testing.

5. The method according to claim 4, characterized in that, After testing the vehicle under test according to the test cases, the method further includes: Receive response data returned by the vehicle under test corresponding to the test case; Obtain the pass conditions for different function tests in the vehicle networking environment from the function rule base, and determine the quantitative index range of different functions from the performance threshold base; The response data is compared with the pass conditions and the quantitative index range respectively to obtain a first comparison result and a second comparison result; The test results of the vehicle under test are determined based on the first comparison result and the second comparison result.

6. The method according to claim 5, characterized in that, Comparing the response data with the range of the quantification metrics includes: Key events are identified from the original logs of the vehicle under test, and key response data corresponding to the key events are determined, wherein the key response data includes the actual trajectory of the vehicle under test; The desired trajectory of the vehicle under test is obtained, and the actual trajectory is compared with the desired trajectory to obtain the trajectory deviation. The second comparison result is obtained by comparing whether the trajectory deviation is within the range of the quantification index.

7. The method according to claim 1, characterized in that, Update the test scenario library based on the test results, including: Obtain the target test case whose test result is a test failure, update the target test case, and generate a new test case; Update the test scenario library based on the new test cases; or, After obtaining the test results, compare whether the version of the vehicle under test has changed before and after the test. If the version of the vehicle under test changes, update the indicator thresholds in the performance threshold library, and adjust the test scenario library according to the updated indicator thresholds.

8. A vehicle testing device, characterized in that, include: A module is established to establish a communication connection between the vehicle under test and the test system. The test system is used to test the functionality of the vehicle under test in a vehicle-to-everything (V2X) environment. The test system and the vehicle under test use the same time reference. The determination module is used to determine the virtual test scenario of the vehicle under test in response to the operation instructions of the target object, and to determine multiple test cases under different working conditions based on the virtual test scenario, wherein the test cases are used to test different functions of the vehicle under test in the vehicle network environment. The testing module is used to test the vehicle under test according to the test cases and update the test scenario library based on the test results.

9. A vehicle testing system, characterized in that, include: The vehicle under test and the test system, among which, A communication connection is established between the vehicle under test and the test system, wherein the test system is used to test the functionality of the vehicle under test in the vehicle network environment, and the test system and the vehicle under test use the same time base. The testing system responds to the operation instructions of the target object to determine the virtual test scenario of the vehicle under test, and determines multiple test cases under different working conditions based on the virtual test scenario. The test cases are used to test different functions of the vehicle under test in the vehicle network environment. The system tests the vehicle under test according to the test cases and updates the test scenario library based on the test results. The vehicle under test is used to return the test results to the test system in response to the test case.

10. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored computer program, wherein the device containing the non-volatile storage medium executes the vehicle testing method according to any one of claims 1 to 7 by running the computer program.

Images