V2x test method, system, medium and product based on hil simulation

Abstract

A V2X test method, system, medium and product based on HIL simulation. In the method, first, the vehicle basic signal data is obtained by importing the database file and system variable of the vehicle communication simulation software tool, which covers the key operating state information such as vehicle position, acceleration and speed. Based on the data analysis of the influence relationship between signals, a graph is generated, thus the signal importance and trigger condition are clear, and a structured basis is provided for subsequent scene decomposition. By decomposing the complex scene into independent events and extracting the parameter list, analyzing the logical relationship and parameter constraint between events, combining conflict detection to identify events that can occur at the same time, and constructing a priority queue to determine the optimal execution order. This dynamic scheduling strategy enables the test case to be precisely configured for specific events, significantly improving the coverage of the test scene and the test efficiency, and solving the problem that the traditional method is difficult to adapt to complex dynamic scenes.

Description

Technical Field

[0001] This application relates to the field of vehicle-to-everything (V2X) communication technology, and in particular to a V2X testing method, system, medium and product based on HIL simulation. Background Technology

[0002] With the rapid development of Vehicle-to-Everything (V2X) technology, intelligent transportation systems have been widely applied. V2X technology improves traffic safety, efficiency, and driving experience through information interaction between vehicles, infrastructure, and pedestrians. To ensure the reliability and performance of V2X systems in complex scenarios, testing and verification have become crucial aspects of the development process. Hardware-in-the-loop (HIL) simulation technology, due to its ability to simulate real-world traffic scenarios in a closed-loop environment, has become an important tool for testing V2X systems.

[0003] In related technologies, test scripts are constructed by analyzing the characteristics of the target scenario, pre-defining the behavioral logic of vehicles and other entities based on experience, and manually inputting test parameters. For example, testers configure the initial position, speed, and driving path for each vehicle and run these statically configured test scripts through the HIL simulation system.

[0004] While existing technologies have achieved partial simulation testing of V2X communication through fixed test scripts and predefined scenario models, the coverage of test scenarios is limited, making it difficult to quickly adapt to dynamically changing testing needs. Predefined test scripts are typically tied to specific scenarios, lacking flexibility. When testing new scenario combinations, scripts often need to be rewritten or significantly modified, increasing testing time and complexity. Therefore, when facing complex scenarios with multiple signal interactions, existing technologies struggle to achieve efficient and comprehensive testing and verification, especially when testing dynamically changing scenarios, where this limitation becomes even more pronounced. Summary of the Invention

[0005] This application provides a V2X testing method, system, medium, and product based on HIL simulation, which solves the problem of difficulty in adapting to complex dynamic scenario combinations in the prior art, and improves the efficiency, flexibility, and coverage of V2X automated testing.

[0006] Firstly, this application provides a V2X testing method based on HIL simulation, applied to a V2X automated testing system, comprising: importing database files and system variables from a vehicle communication simulation software tool into a test script development tool to obtain basic vehicle signal data, wherein the system variables include vehicle operating status, environmental conditions, and test scenario-related variables, and the basic signal data includes vehicle position, vehicle acceleration, and vehicle speed; based on the basic signal data and the system variables, analyzing the influence relationships between the basic signals to obtain a signal influence relationship graph, wherein the signal influence relationship graph includes the basic signal data, signal importance, and triggering conditions; and decomposing a complex test scenario into multiple independent events according to the signal influence relationship graph to obtain a parameter list, wherein the parameters... The list includes the triggering conditions, related signal data, and dynamic range of change of each independent event. Based on this parameter list and the signal influence relationship graph, the multiple independent events are sorted to obtain their execution order. Rules related to these independent events are extracted from a pre-set scenario rule base. Combined with the execution order, a test script body is generated. This scenario rule base contains mapping rules between scenario triggering conditions and execution actions. Using this test script body and the parameter list, test scripts adapted to different vehicle-to-everything (V2X) scenarios are generated. These test scripts include combinations of different execution orders of the multiple independent events. Based on these test scripts, hardware-in-the-loop (HIL) simulation technology is used to simulate and test V2X communication in the fused scenario, resulting in an automated test report.

[0007] By adopting the above technical solution, this method first acquires basic vehicle signal data by importing database files and system variables from vehicle communication simulation software tools. This data covers key operational status information such as vehicle position, acceleration, and speed. Based on this data, the influence relationships between signals are analyzed, and a spectrum is generated, thereby clarifying the importance of signals and triggering conditions, providing a structured basis for subsequent scenario decomposition. By breaking down complex scenarios into independent events and extracting parameter lists, the logical relationships and parameter constraints between events are analyzed. Combined with conflict detection to identify events that can occur simultaneously, a priority queue is constructed to determine the optimal execution order. This dynamic scheduling strategy enables test cases to be precisely configured for specific events, significantly improving the coverage and efficiency of test scenarios, and solving the problem that traditional methods are difficult to adapt to complex dynamic scenarios.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, based on the signal influence relationship graph, the complex test scenario is decomposed into multiple independent events to obtain a parameter list. Specifically, this includes: analyzing the variation range of the basic signal data based on the signal influence relationship graph and the physical relationship of the basic signal; analyzing the environmental limitations on the variation range based on the variation range and the system variable to obtain an adjusted variation range; and decomposing the complex test scenario into multiple independent events based on the adjusted variation range and the triggering condition to obtain a parameter list for each independent event.

[0009] By employing the aforementioned technical solution, when decomposing complex test scenarios, this method first analyzes the range of data variation based on signal influence relationship diagrams and the physical relationships of fundamental signals. Then, it considers environmental constraints in conjunction with system variables, thereby obtaining a more realistic adjusted range of variation. Based on this, independent events are decomposed, ensuring that the parameter list for each event more accurately reflects the constraints of the real-world scenario. This hierarchical analysis and dynamic adjustment mechanism ensures the scientific nature of the test scenario parameter settings, improves the simulation accuracy of test cases for complex dynamic scenarios, and makes the test results more reliable.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the multiple independent events are sorted according to the parameter list and the signal influence relationship graph to obtain the execution order of the multiple independent events. Specifically, this includes: constructing a priority evaluation matrix based on the signal influence relationship graph and the multiple independent events; calculating the priority score of each independent event based on the priority evaluation matrix; establishing a priority queue for the execution order of the multiple independent events based on the priority score and the parameter list; performing conflict detection on the priority queue and analyzing events that can be executed simultaneously; and generating an optimal execution sequence based on the events that can be executed simultaneously and the priority queue to obtain the execution order.

[0011] By employing the above technical solution, this method constructs a priority evaluation matrix to calculate the priority scores of independent events, establishes a priority queue and performs conflict detection, and finally generates the optimal execution sequence. This sorting mechanism fully considers the influence relationships between signals and the timing constraints of event execution, ensuring that high-priority events are executed first, while rationally arranging parallelizable events, effectively avoiding resource contention and logical conflicts during the testing process. By optimizing the event execution order, the testing cycle is significantly shortened, the execution efficiency of automated testing is improved, and efficient utilization of testing resources is achieved.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the extraction of rules related to the multiple independent events from a preset scenario rule base, combined with the execution order, generates the main body of the test script, specifically including: constructing matching rules according to the execution order, the matching rules including rule templates and rule combination logic; retrieving a set of rules that meet the conditions from the scenario rule base based on the mapping rules of the scenario rule base and the matching rules, obtaining a rule chain, the mapping rule being the mapping relationship between the triggering condition and the execution action; converting the rule chain into a unified standard test statement to obtain the main body of the test script.

[0013] By employing the above technical solution, this method constructs matching rules based on the order of event execution, retrieves rule sets from the scenario rule base to form rule chains, and converts them into standard test statements. This rule-driven script generation mechanism transforms abstract scenario logic into executable test code, ensuring the consistency between test scripts and scenario requirements. Standardized statement generation improves the readability and maintainability of test scripts, enabling testers to quickly understand and modify them, and reducing the technical threshold and manpower costs of test script development.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the process of retrieving a set of rules that meet the conditions from the scenario rule base based on the mapping rule and the matching rule to obtain a rule chain specifically includes: retrieving a set of rules that meet the conditions from the scenario rule base based on the mapping rule and the matching rule to obtain an initial rule chain; analyzing the correlation between rules based on the initial rule chain to obtain a processed rule chain, the processing including merging similar rules and deleting redundant rules; supplementing the transition logic of the rule chain based on the signal influence relationship graph to obtain a logically complete rule chain; and adjusting the execution conditions of the logically complete rule chain according to the parameter list to obtain an optimized rule chain.

[0015] By employing the aforementioned technical solution, during the rule chain retrieval process, this method performs correlation analysis on the initial rule chain, merges similar rules, deletes redundant rules, supplements transition logic by incorporating signal influence relationship graphs, and adjusts execution conditions based on the parameter list. This multi-dimensional rule chain optimization mechanism eliminates redundancy and conflicts between rules, improves the logical connections between rules, and makes the generated test scripts more compact and logically rigorous. The optimized rule chain can more accurately simulate signal interaction processes in real-world scenarios, improving the test scripts' adaptability to complex scenarios and execution stability.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, based on the test script, the vehicle-to-everything (V2X) communication in the fusion scenario is simulated and tested using hardware-in-the-loop (HIL) simulation technology to obtain an automated test report. Specifically, this includes: compiling the test script into an executable file of a set format using the test script development tool; loading the executable file into the test unit of the vehicle communication simulation software tool to obtain a loaded executable file; selecting an appropriate scenario variant from the scenario variant library based on the loaded executable file and the signal influence relationship graph to obtain corresponding test cases. The scenario variant library includes different vehicle models, different vehicle configurations, and scenario coverage; and simulating and testing the V2X communication in the fusion scenario using hardware-in-the-loop (HIL) simulation technology based on the test cases to obtain an automated test report.

[0017] By employing the above technical solution, this method compiles test scripts into executable files and loads them into the simulation tool's test unit. It then uses signal influence relationship graphs to select suitable scenario variants from a scenario variant library to generate test cases. This variant-based test case generation mechanism can quickly adapt to different vehicle models, configurations, and scenario coverage requirements, achieving diversification and customization of test scenarios. Executing test cases using hardware-in-the-loop simulation technology enables verification of V2X system performance in a real hardware environment. The generated automated test reports provide objective evidence for system optimization, improving the reliability and practicality of the test results.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of simulating and testing the vehicle-to-everything (V2X) communication in the fusion scenario using hardware-in-the-loop simulation technology based on the test script to obtain an automated test report, the specific steps include: assessing the risk level of the fusion scenario based on the automated test report, the signal impact relationship graph, and the preset scenario rule base; generating avoidance strategy suggestions and early warning information based on the risk level and the automated test report; and calling a Python script to send the automated test report, the avoidance strategy suggestions, and the early warning information to a designated email address.

[0019] By employing the aforementioned technical solution, this method assesses the risk level of fusion scenarios based on automated test reports, signal impact relationship graphs, and scenario rule bases, generates avoidance strategy suggestions and early warning information, and automatically sends them to designated email addresses. This closed-loop risk assessment and information push mechanism can promptly identify high-risk scenarios during the testing process, providing developers with targeted optimization suggestions and shortening the problem localization and remediation cycle. The automated report distribution mechanism ensures the timely transmission of test results and risk information, improves overall collaboration efficiency, and provides strong support for the secure and reliable deployment of V2X systems.

[0020] In a second aspect, this application provides a V2X automated testing system, including one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the V2X automated testing system to perform the methods described in the first aspect and any possible implementation thereof.

[0021] Thirdly, this application provides a computer-readable storage medium including instructions that, when executed on a V2X automated testing system, cause the V2X automated testing system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, this application provides a computer program product that, when run on a V2X automated testing system, causes the V2X automated testing system to perform the method described in the first aspect and any possible implementation thereof.

[0023] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0024] 1. By employing techniques such as importing basic signal data from vehicle communication simulation software, analyzing the influence relationships between signals to generate graphs, and breaking down complex scenarios into independent events to obtain parameter lists, a clear, structured framework for scenario decomposition is provided, supported by basic signal data and influence relationship graphs. This allows for precise configuration of test scenarios based on independent events. This effectively solves the problem of limited test scenario coverage in existing technologies, thereby significantly improving the breadth and specificity of test scenario coverage, and making test cases more closely aligned with real-world complex scenarios.

[0025] 2. By employing a technique that constructs matching rules based on the order of event execution, retrieves rule chains from a scenario rule base, and converts them into standard test statements, the matching rules can accurately filter relevant rules from the rule base. This transforms abstract scenario logic into standardized, directly executable test code, ensuring a high degree of consistency between test scripts and actual scenario requirements. This effectively solves the problem of lack of standardization and consistency in test script development in existing technologies, thereby significantly improving the readability and maintainability of test scripts and reducing development costs and technical barriers.

[0026] 3. By employing a technical approach that combines test reports, signal impact relationship graphs, and scenario rule bases to assess risk levels, generate avoidance strategies and early warning information, and automatically send them out, the system can integrate multi-faceted data for a comprehensive risk assessment. This allows for the timely generation and automatic delivery of targeted response strategies, ensuring developers can quickly access risk information. This effectively solves the problems of delayed post-test risk handling and inefficient information transmission in existing technologies, thereby significantly shortening the problem localization and repair cycle, improving team collaboration efficiency, and providing strong technical support for the secure and reliable deployment of V2X systems. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating the V2X testing method based on HIL simulation used in the embodiments of this application.

[0028] Figure 2 This is another flowchart illustrating the V2X testing method based on HIL simulation used in the embodiments of this application;

[0029] Figure 3 This is a schematic diagram of the hardware structure of an electronic device in an embodiment of this application. Detailed Implementation

[0030] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0031] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0032] This application aims to address the problem that existing V2X testing technologies are ill-suited for complex and dynamic scenario combinations. Existing technologies rely on fixed test scripts and predefined scenario models for simulation testing, resulting in limited test scenario coverage and insufficient flexibility. When faced with new scenario combinations, scripts must be rewritten or significantly modified, leading to high time costs and complexity, making it difficult to efficiently and comprehensively test and verify complex dynamic scenarios with multiple signal interactions. This application aims to improve the efficiency, flexibility, and coverage of V2X automated testing, ensuring the reliability and performance of V2X systems in complex scenarios.

[0033] For ease of understanding, the V2X testing method based on HIL simulation provided in this application is described below: By importing data from vehicle communication simulation software, basic signal data is acquired and its influence relationships are analyzed to generate a signal influence relationship map. Based on this map, complex test scenarios are decomposed into independent events, and a parameter list containing triggering conditions and data variation ranges is extracted. Through priority evaluation and conflict detection, events that can be executed simultaneously are identified, and the execution order of independent events is determined. Then, rules are extracted from the scenario rule base, and the script body is generated in combination with the execution order. The test script is generated in conjunction with the parameter list, and finally, automated testing is completed through hardware-in-the-loop simulation.

[0034] Figure 1 This is a flowchart illustrating the V2X testing method based on HIL simulation used in the embodiments of this application.

[0035] Please see Figure 1 The specific description of the V2X testing method based on HIL simulation is as follows:

[0036] 101. Import the database file and system variables from the vehicle communication simulation software tool into the test script development tool to obtain the basic signal data of the vehicle. The system variables include vehicle operating status, environmental conditions and test scenario-related variables. The basic signal data includes vehicle position, vehicle acceleration and vehicle speed.

[0037] The vehicle communication simulation software tool used to implement this embodiment is CANoe, and the test script development tool is vTESTstudio.

[0038] The systems mentioned in this embodiment are all V2X automated testing systems.

[0039] The system first imports the database file and system variables from the vehicle communication simulation software tool into the test script development tool to obtain the vehicle's basic signal data. The system establishes a connection with the vehicle communication simulation software tool through interface adaptation technology, recognizing the database file format; it can parse and read both structured and unstructured data files. Simultaneously, the system variables cover vehicle operating status (such as engine speed and gear information), environmental conditions (such as weather conditions and light intensity), and test scenario-related variables (such as traffic flow and road type), which are imported along with the database file. After import, the system cleans and filters the data, removing redundant information and extracting basic signal data such as vehicle position, vehicle acceleration, and vehicle speed, laying the foundation for subsequent analysis.

[0040] 102. Based on the basic signal data and the system variables, analyze the influence relationship between the basic signals to obtain a signal influence relationship map, which includes the basic signal data, signal importance, and triggering conditions.

[0041] After data import, the system analyzes the influence relationships between basic signals based on the acquired fundamental signal data and system variables, generating a signal influence relationship graph. The system employs correlation analysis algorithms to process the fundamental signal data and system variables. For example, when a vehicle is in a rainy environment (environmental condition variable), its speed (fundamental signal data) may decrease, and the frequency of change in its acceleration will also be affected. The system establishes a correlation model between fundamental signals using extensive historical and simulated data. During the analysis, the system also determines the importance of each fundamental signal; for instance, in an emergency braking scenario, vehicle speed and acceleration are more important than vehicle position. Furthermore, the system defines the signal triggering conditions, such as triggering an emergency braking signal when the vehicle speed exceeds a certain threshold and an obstacle appears ahead (test scenario-related variable). Finally, this information is integrated to form a signal influence relationship graph that includes fundamental signal data, signal importance, and triggering conditions.

[0042] 103. Based on the signal influence relationship graph, the complex test scenario is decomposed into multiple independent events to obtain a parameter list. The parameter list includes the triggering conditions of each independent event, related signal data, and the dynamic change range of the related signal data.

[0043] Based on the signal influence relationship graph, the system decomposes complex test scenarios into multiple independent events, resulting in a parameter list. The system breaks down complex test scenarios according to the triggering conditions and interrelationships of signals in the signal influence relationship graph. Taking a multi-vehicle interaction scenario on a highway as an example, the system decomposes it into independent events such as lane changing, following distance adjustment, and emergency braking response of the vehicle in front. During the decomposition process, the system analyzes the range of variation of basic signal data based on the signal influence relationship graph and the physical relationships of basic signals. For example, in the lane changing event, the range of variation of vehicle speed, acceleration, and position has physical limitations. Then, combined with system variables, the system analyzes the environmental limitations on this range of variation; for example, on a slippery road surface, the range of variation of vehicle acceleration will be reduced, resulting in an adjusted range of variation. Finally, based on the adjusted range of variation and triggering conditions, the system determines the triggering conditions, related signal data, and the dynamic range of variation of related signal data for each independent event, forming a detailed parameter list.

[0044] 104. Based on the parameter list and the signal influence relationship graph, sort the multiple independent events to obtain the execution order of the multiple independent events.

[0045] The system sorts multiple independent events based on a parameter list and a signal influence relationship graph to determine the execution order. First, the system analyzes the importance and triggering conditions of each signal in the signal influence relationship graph. Then, it combines this with the relevant signal data and dynamic change range of each independent event in the parameter list to comprehensively determine the logical relationships between events. For example, if the triggering of an event depends on a signal change generated by another event, then the event that generates the preceding signal will necessarily be executed first.

[0046] The system further considers the influence relationships between basic signals. If multiple events involve the same basic signal, the system prioritizes the events based on the importance of that signal in the signal influence relationship graph. For example, if the vehicle speed signal is of high importance in the signal influence relationship graph, the "vehicle acceleration event" will be prioritized when both the "vehicle acceleration event" and the "in-vehicle entertainment system volume adjustment event" are associated with the same signal.

[0047] In processing the sequencing of multiple independent events, the system compares the triggering conditions of each event in the parameter list one by one. If there are events whose triggering conditions have a sequential order, such as the "vehicle ahead decelerating" event followed by the "vehicle behind braking" event, the execution order is determined according to the logical order of the triggering conditions. Through a comprehensive analysis of the signal influence relationships, event triggering conditions, and related signal data, the system ultimately arrives at a clear and reasonable execution order for multiple independent events.

[0048] 105. Extract rules related to the multiple independent events from the preset scene rule library, and generate the main body of the test script in combination with the execution order. The scene rule library contains mapping rules between scene triggering conditions and execution actions.

[0049] The system extracts rules related to multiple independent events from a pre-defined scenario rule base and generates the main body of the test script based on the determined execution order. According to the execution order, the system compares the triggering conditions of each independent event with the scenario triggering conditions stored in the scenario rule base. Since the scenario rule base contains mapping rules between scenario triggering conditions and execution actions, when the triggering condition of an independent event matches the triggering condition of a rule in the scenario rule base, the system extracts the corresponding execution action. For example, if the independent event is "the vehicle detects an obstacle ahead and its speed is greater than 50 km / h," the system finds a matching triggering condition in the scenario rule base and then obtains the execution action of "sending a deceleration command and illuminating the hazard warning lights." Following the execution order of the independent events, the system integrates the matched execution actions sequentially to form the main content of the test script.

[0050] The test script body is the core architecture and key content framework of the entire test script. It is a crucial component that transforms abstract test requirements into executable test instructions. It contains a series of standard test statements tailored to different connected vehicle test scenarios, based on event logic and execution sequence. These statements clearly define the actions the system should perform under specific conditions, such as under what signal triggers the vehicle to accelerate, decelerate, or change lanes, or how information should be exchanged between vehicles or between vehicles and infrastructure. The test script body is like the framework of a house; by filling in specific parameter data, a complete test script adapted to various complex connected vehicle scenarios can be generated. It is the logical foundation and core of instructions for achieving automated testing.

[0051] 106. Using the test script body and the parameter list, generate test scripts adapted to different vehicle networking scenarios. The test scripts include combinations of different execution orders of the multiple independent events.

[0052] The system uses the test script body and parameter list to generate test scripts adapted to different vehicle-to-everything (V2X) scenarios. Based on the test script body, the system accurately fills the corresponding test statements with the triggering conditions, relevant signal data, and dynamic change ranges of each independent event from the parameter list. For example, for the independent event of "vehicle lane change," the parameter list provides the dynamic change ranges of vehicle speed, acceleration, and other data; the system substitutes this data into the test statements related to "vehicle lane change" in the test script body.

[0053] Meanwhile, the system adjusts the execution order of independent events based on the characteristics of different vehicle-to-everything (V2X) scenarios. In urban congestion scenarios, events such as "vehicle start," "following other vehicles," and "yielding to pedestrians" are set to a specific sequence; in highway driving scenarios, these events are rearranged to form an execution order suitable for highway conditions. Through diverse combinations of the execution order of independent events, combined with the rich data provided by the parameter list, the system generates a series of test scripts that can cover different V2X scenarios, meeting various complex testing needs.

[0054] 107. Based on the test script, perform simulation tests on vehicle-to-everything (V2X) communication in the fusion scenario using hardware-in-the-loop simulation technology to obtain an automated test report.

[0055] Based on the generated test scripts, the system utilizes hardware-in-the-loop (HIL) simulation technology to perform simulation tests on vehicle-to-everything (V2X) communication in integrated scenarios and output automated test reports. First, the system interfaces with the HIL simulation platform, which integrates real onboard electronic control units (ECUs), communication modules, and other hardware devices. It also combines virtual vehicle dynamics models, traffic environment models, and communication network models to construct a highly realistic test environment. For example, in simulating urban road test scenarios, the platform loads a virtual city map containing intersections, pedestrians, and other vehicles, and sets the vehicle's initial position, speed, and other parameters according to the test script.

[0056] After the system initiates hardware-in-the-loop simulation, the test script drives the simulation environment to run according to a preset event sequence and parameters. During the simulation test, the onboard hardware receives instructions from the test script in real time and interacts with other entities in the virtual environment through simulated communication links. Taking the communication test between the vehicle and the roadside unit (RSU) as an example, when the test script triggers the "vehicle approaching an intersection" event, the onboard communication module simulates sending a request signal, and the roadside unit replies with data such as traffic signal status and surrounding vehicle information according to a preset communication protocol. The transmission and processing of this data completely simulates a real vehicle-to-everything (V2X) communication scenario.

[0057] During simulation testing, the system continuously monitors and collects various types of data, including real-time vehicle operating status data, communication data, and hardware device operating status data. The system uses data acquisition cards and other devices to convert these analog signals into digital signals and transmits them to the data processing module for analysis. For example, when testing vehicle-to-vehicle (V2V) communication, the system records the timestamp, data packet content, and transmission path of each information exchange to facilitate subsequent analysis of communication reliability and real-time performance.

[0058] After the simulation test is completed, the system performs a comprehensive analysis and evaluation of the collected data based on preset test standards and expected results. The system compares the actual collected data with the expected values ​​set in the test script to determine whether each test event passes. For example, if the test script requires the vehicle to decelerate within one second of receiving an emergency braking signal from the vehicle ahead, the system will check whether the actual deceleration time is within the allowable error range. For failed test events, the system will record detailed abnormal data and related information, such as excessive signal transmission delay or instruction execution errors. Finally, the system automatically generates a test report based on the data analysis results.

[0059] The HIL simulation-based V2X testing method described in this application imports the database files and system variables from the vehicle communication simulation software tool (CANoe) into the test script development tool (vTESTstudio) to obtain basic signal data. Based on this, signal influence relationships are analyzed to generate a spectrum. Complex scenarios are then broken down into independent events, and their execution order is determined. The main body of the test script is generated by combining the scenario rule base. Finally, the test script is generated for HIL simulation testing through parameter filling and sequence combination. This achieves full automation from data acquisition and scenario analysis to script generation and simulation testing. It not only solves the problems of limited scenario coverage and poor script flexibility in traditional testing, but also significantly improves the efficiency, flexibility, and coverage of V2X automated testing, ensuring the reliability and performance of the vehicle-to-everything (V2X) system in complex scenarios.

[0060] The following describes another method provided by an embodiment of this application: Basic signals are extracted by importing vehicle communication simulation data, and a signal influence relationship graph is generated. Based on the graph, complex scenarios are decomposed into multiple independent events, and the execution order is determined through priority evaluation and conflict detection. Matching rules are constructed by retrieving rules from a scenario rule base, and optimized by merging redundancies and supplementing logic to form a rule chain. This chain is then converted into the main body of the test script and combined with parameters to generate multi-scenario scripts. After testing, the risk level is assessed, and strategies and early warning information are automatically generated and sent.

[0061] Figure 2 This is another flowchart illustrating the V2X testing method based on HIL simulation used in the embodiments of this application.

[0062] Please see Figure 2 The other method for automated V2X testing based on HIL simulation is described in detail below:

[0063] 201. Import the database file and system variables from the vehicle communication simulation software tool into the test script development tool to obtain the basic signal data of the vehicle. The system variables include vehicle operating status, environmental conditions and test scenario-related variables. The basic signal data includes vehicle position, vehicle acceleration and vehicle speed (this step has been explained in 101 and will not be repeated here).

[0064] The vehicle communication simulation software tool used to implement this embodiment is CANoe, and the test script development tool is vTESTstudio.

[0065] The systems mentioned in this embodiment are all V2X automated testing systems.

[0066] 202. Based on the basic signal data and the system variables, analyze the influence relationship between the basic signals to obtain a signal influence relationship map. The signal influence relationship map includes the basic signal data, signal importance and triggering conditions (this step has been explained in 102 and will not be repeated here).

[0067] 203. Based on the signal influence relationship graph, the complex test scenario is decomposed into multiple independent events to obtain a parameter list. The parameter list includes the triggering conditions of each independent event, related signal data, and the dynamic change range of the related signal data.

[0068] The method specifically includes steps 2031 to 2033, which are not shown in the figure.

[0069] 2031. Based on the signal influence relationship spectrum and the physical relationship of the basic signal, analyze the variation range of the basic signal data.

[0070] Based on the basic signal data (such as vehicle position, acceleration, and speed) and their physical properties recorded in the signal influence relationship graph, the system analyzes the theoretical variation range of each signal under ideal conditions using vehicle dynamics and signal association rules. For example, for the "emergency braking" scenario, the system calculates the theoretical maximum value of vehicle acceleration as -10 m / s² based on Newton's second law and the formula for the friction coefficient between the tire and the road surface (assuming the road surface is dry and the tire grip is sufficient). At the same time, combined with the strong positive correlation between vehicle speed and braking distance in the signal influence relationship graph, the system determines the range of vehicle speed variation to be from the current speed to 0 km / h.

[0071] For scenarios with multiple coupled signals (such as the relationship between lateral acceleration and vehicle speed during lane changes), the system establishes multivariate constraint equations using the weights of signal-related edges in the signal influence graph (e.g., the weight of lateral acceleration on lane departure risk is 0.7). For example, when the vehicle speed exceeds 60 km / h, the theoretical maximum value of lateral acceleration is automatically limited to 1.5 m / s² to avoid the risk of rollover due to excessive centrifugal force. The system generates an initial list of variation ranges, including upper and lower limits, for each basic signal as the basic parameters for scenario decomposition.

[0072] 2032. Based on the range of change and the system variables, analyze the environmental limitations on the range of change to obtain the adjusted range of change.

[0073] The system incorporates environmental conditions (such as weather, road type, and light intensity) and test scenario variables (such as traffic flow and obstacle type) from system variables to dynamically correct the range of changes obtained in step 2031. For example, when the "weather" parameter in the system variables is "rainy," based on the negative correlation between "road surface slippage affecting tire adhesion" in the signal influence relationship graph (e.g., correlation coefficient -0.6), the maximum theoretical value of vehicle acceleration is adjusted from -10 m / s² to -6 m / s², while the lower limit of the vehicle speed variation range is adjusted to 10 km / h (to avoid rear-end collisions due to increased braking distance).

[0074] For the combined effects of environmental variables, the system employs a hierarchical correction logic. For example, in a "mountain road + foggy weather" scenario, the system first adjusts the theoretical range of vehicle acceleration based on the "road slope" variable (e.g., 5° uphill) (the maximum braking acceleration becomes -8 m / s² when going uphill). Then, considering the foggy weather condition of "visibility less than 50 meters," the system further restricts the vehicle speed variation range to 20-40 km / h. Through this multi-dimensional environmental constraint analysis, the system generates adjusted variation ranges that more closely resemble real-world scenarios, ensuring the rationality of independent event parameters.

[0075] 2033. Based on the adjusted range of change and the triggering conditions, the complex test scenario is decomposed into multiple independent events, and a parameter list for each independent event is obtained.

[0076] Based on the adjusted signal variation range and trigger conditions (such as signal combination logic and threshold boundaries) in the signal influence relationship graph, the system uses a recursive segmentation algorithm to decompose complex scenarios into multiple independent events. For example, the "highway rear-end collision warning scenario" is decomposed into three independent events: "the vehicle in front brakes suddenly," "the vehicle behind detects a braking signal," and "the vehicle behind decelerates." Each event corresponds to a unique trigger condition and signal parameters. The parameter list is generated according to the "minimum functional unit" principle. Each event contains only a single core logic (such as signal detection and action execution) and is indexed and associated with nodes in the signal influence relationship graph through the "event ID" field (such as EVT-003). For example, in the parameter list of the "vehicle behind decelerates" event, the "constraint condition" field references the rule "rainy weather → braking distance increased by 30%" in the signal influence relationship graph, automatically further limiting the adjusted range of the vehicle behind's acceleration to [-6m / s², 0m / s²], ensuring the consistency of signal parameters and environmental variables.

[0077] Through this process, the system transforms the originally complex scenario into an independently configurable and reusable event unit. The parameter list of each event not only includes the signal dynamic range and triggering conditions, but also integrates environmental constraints and priority indicators (such as "the event of the vehicle in front braking suddenly" has a high priority).

[0078] 204. Based on the parameter list and the signal influence relationship graph, sort the multiple independent events to obtain the execution order of the multiple independent events.

[0079] The method specifically includes steps 2041 to 2045, which are not shown in the figure.

[0080] 2041. Based on the signal influence relationship spectrum and the multiple independent events, construct a priority evaluation matrix.

[0081] The system constructs a multi-dimensional priority evaluation matrix based on the signal importance, triggering conditions, and logical relationships of multiple independent events recorded in the signal impact relationship graph. The rows of the matrix represent individual events (e.g., "emerging vehicle sudden braking event" and "following vehicle braking response event"), and the columns represent evaluation dimensions, including signal impact degree (e.g., the event's impact on V2X communication reliability), scenario coverage (e.g., the frequency of the event's occurrence in different test scenarios), and execution time (e.g., the time cost from triggering to completion of the event). Each cell is filled with the event's quantified value in the corresponding dimension (usually using a 1-5 point scale). For example, the "emerging vehicle sudden braking event" scores 5 points (highest priority) in the "signal impact degree" dimension and 3 points (medium priority) in the "execution time" dimension.

[0082] The construction process of this matrix combines the signal weights in the signal influence relationship graph (e.g., the importance weight of the vehicle speed signal is 40%) with the complexity of the triggering conditions in the event parameter list, ensuring that the evaluation dimensions are deeply bound to the scene features.

[0083] 2042. Calculate the priority score for each independent event based on the priority evaluation matrix.

[0084] The system uses matrix operations to perform weighted summation of the scores for each dimension of each independent event, generating a unique priority score. For example, the weighted scores for the "sudden braking event" in terms of signal impact (5 points), scene coverage (4 points), and execution time (3 points) are 2 points (5×40%), 1.2 points (4×30%), and 0.9 points (3×30%), respectively, for a total priority score of 4.1 points. For events involving multiple signals (such as the "vehicle lane change event" which involves vehicle speed and acceleration), the system accumulates the importance weights of each signal as the signal impact score for that event. Through this calculation process, the system transforms qualitative event priorities into quantitative values, providing an objective basis for subsequent ranking.

[0085] 2043. Based on the priority score and the parameter list, establish a priority queue for the execution order of the multiple independent events.

[0086] The system sorts independent events in descending order based on their priority scores, forming a priority queue. Events with higher priority scores are placed earlier in the priority queue to ensure that high-priority events are executed first. For example, the "emergency braking event," involving critical safety signals, has the highest priority score and is placed at the front of the queue; while non-critical events such as the "in-vehicle entertainment system adjustment event" are arranged sequentially according to their scores. Simultaneously, the system adjusts the priority queue based on the triggering conditions and resource usage of each event in the parameter list to ensure that the event order conforms to logical relationships and data dependencies. For instance, events that require a specific signal from a preceding event to trigger are automatically placed after the preceding event, forming the basis of an ordered execution sequence.

[0087] 2044. Perform conflict detection on the priority queue and analyze the events that can be executed simultaneously.

[0088] The system performs conflict detection on the established priority queue. By traversing the events in the queue, it identifies whether there are resource competitions or logical dependencies between events. For example, if two events both require the same CAN bus channel to send signals, it is determined to be a resource conflict; if the triggering of one event depends on the signal output of another event (such as "rear vehicle braking response" depending on "front vehicle emergency braking signal"), it is determined to be a logical dependency. For events without conflicts, the system marks them as events that can be executed simultaneously. For example, the "vehicle headlight adjustment event" and the "vehicle navigation route calculation event" can be executed in parallel because they do not involve shared resources and have no logical dependencies.

[0089] 2045. Based on the events that can be executed simultaneously and the priority queue, generate the optimal execution sequence to obtain the execution order.

[0090] The system combines a priority queue and a set of events that can be executed simultaneously. Under the premise of ensuring that high-priority events are executed first, the system sets the execution sequence based on the triggering logic inside the test equipment, thereby meeting the purpose of the test.

[0091] 205. Construct matching rules according to the execution order, wherein the matching rules include rule templates and rule combination logic.

[0092] The system constructs matching rules for retrieving the scenario rule base based on the established execution sequence of independent events. Rule templates are standardized definitions of the triggering conditions and execution actions for independent events. For example, for a "vehicle emergency braking event," the rule template could be expressed as "If the vehicle's acceleration is less than -5 m / s² and its speed is greater than 40 km / h, then send a braking signal to the vehicle's ECU." Rule combination logic is used to define the temporal relationships between multiple rules, such as "Event B is triggered within 100 ms after Event A is executed" or "Events C and D must be executed in sequence."

[0093] When constructing matching rules, the system associates each event in the execution sequence with the triggering conditions in the signal influence relationship graph, ensuring the logical coherence of the rules. For example, in the "pedestrian crossing scenario at an urban intersection," the execution sequence is "first, pedestrian detection event; second, vehicle deceleration event; and finally, brake light illumination event." The matching rules first define the triggering conditions for pedestrian detection (such as radar signal detecting a moving target), and then use combinational logic to set that vehicle deceleration must be triggered within 200ms after pedestrian detection, and brake light illumination must be synchronized with the deceleration action. This rule construction method ensures that the test script can accurately simulate the causal relationships of events in real-world scenarios.

[0094] 206. Based on the mapping rules and matching rules of the scenario rule base, retrieve the set of rules that meet the conditions from the scenario rule base to obtain the initial rule chain.

[0095] The system precisely matches the triggering conditions of matching rules with the mapping rules in the scene rule base (i.e., the correspondence between preset triggering conditions and execution actions) to filter out all rules that match the current scene. The scene rule base contains a large number of predefined rules, such as "send a deceleration command if the vehicle speed is greater than 60km / h and an obstacle is detected" and "reduce the acceleration threshold in rainy conditions".

[0096] Taking the "highway following scenario" as an example, the matching rule is "the preceding vehicle's deceleration event triggers the following vehicle's braking response event." The system will search the rule base for all rules containing the trigger condition of "the preceding vehicle's deceleration signal," such as "if the preceding vehicle decelerates more than 3 m / s², a broadcast braking signal is triggered" or "if the following vehicle receives a braking signal, its own braking logic is triggered," forming an initial rule chain. The initial rule chain may contain multiple rules, such as rules involving different levels of communication signal transmission and vehicle system response, which need further processing to eliminate redundancy and conflicts.

[0097] 207. Based on the initial rule chain, analyze the correlation between rules to obtain a processed rule chain. The processing includes merging similar rules and deleting redundant rules.

[0098] The system performs correlation analysis on the rules in the initial rule chain to identify rules with duplicate functions or logical conflicts. Similar rules are merged based on the similarity of triggering conditions and execution actions. For example, if two rules both target the "vehicle lane change" scenario, both have the triggering conditions of "steering angle greater than 15° and vehicle speed greater than 50km / h", and the execution actions are "send lane change request" and "turn on turn signal" respectively, the system will merge them into one rule, integrating the triggering conditions and executing the actions in sequence.

[0099] Redundant rules are deleted when there are completely identical rule entries; for example, if two rules are completely duplicated, only one is retained. Furthermore, the system detects logical conflicts between rules. For instance, if one rule requires "lane changing is prohibited when the vehicle speed is greater than 80 km / h" and another rule requires "lane changing is allowed when the vehicle speed is greater than 100 km / h," the system will retain the former and delete the latter based on the signal importance in the signal influence graph (e.g., safety signals have higher priority than performance signals). Through merging and deletion operations, the processed rule chain is more concise and logically clearer, avoiding resource waste and instruction conflicts during test script execution.

[0100] 208. Based on the signal influence relationship graph, supplement the transition logic of the rule chain to obtain a logically complete rule chain.

[0101] The signal influence relationship graph records the dependencies and transmission paths between basic signals, and the system uses this to supplement missing transition logic in the rule chain. For example, in the "vehicle platooning scenario," there is a CAN bus signal transmission delay between the "leading vehicle steering event" and the "following vehicle steering response event." The signal influence relationship graph clearly states that the signal transmission time is 50-100ms. Therefore, the system inserts "waiting for signal reception" transition logic into the rule chain to ensure that the following vehicle steering rule is triggered after the leading vehicle's signal is successfully transmitted, avoiding inaccurate test results due to timing loopholes.

[0102] In addition, the transition logic includes signal conversion rules, such as converting physical signals (e.g., acceleration values) into logical instructions (e.g., an "emergency braking" flag). If such conversion logic is lacking in the rule chain, the system will automatically extract relevant signal mapping relationships from the signal influence relationship graph to supplement it. By perfecting the transition logic, the rule chain can fully reproduce the entire process of signal generation, transmission, and response in a real-world scenario.

[0103] 209. Adjust the execution conditions of the logically complete rule chain according to the parameter list to obtain the optimized rule chain.

[0104] The system fine-tunes the logically complete rule chain based on the triggering conditions, related signal data, and dynamic change range of each independent event in the parameter list. The parameter list records the dynamic range of the signal under different environments (e.g., adjusting the vehicle acceleration threshold from -10m / s² to -6m / s² in rainy weather) and constraints (e.g., shortening the detection distance when the light intensity is <500 lux). The system associates these parameters with the execution conditions in the logically complete rule chain through mapping relationships. For example, if the triggering condition for the "emergency braking rule" in the logically complete rule chain is "vehicle speed greater than 60km / h and obstacle distance less than 50 meters", combined with the constraint "braking distance increased by 30% in rainy weather" in the parameter list, the system will automatically adjust the obstacle distance threshold to less than 35 meters to ensure the effectiveness of the rule in slippery environments.

[0105] For execution conditions involving multiple signal combinations (such as "steering angle greater than 15° and no turn signal activated and vehicle speed greater than 50km / h triggering lane departure warning"), the system verifies the condition boundaries based on the dynamic range of the signals in the parameter list. If the parameter list specifies "maximum lateral acceleration of the vehicle is 2m / s²", and a condition in a logically complete rule chain implicitly allows lateral acceleration exceeding this threshold, the system will automatically correct the condition to avoid logical contradictions. Through this parameter-driven condition adjustment mechanism, the optimized rule chain can accurately adapt to the constraints of different test scenarios, improving the robustness of the test script.

[0106] 210. Convert the rule chain into a unified standard test statement to obtain the main body of the test script.

[0107] The system converts the optimized rule chain into standard test statements recognizable by the test script development tool, forming the main body of the test script. The conversion process follows standardized syntax rules; for example, the trigger condition "vehicle speed > 60km / h" in the rule chain is converted to "VehicleSpeed ​​> 60", and the action "send braking command" is converted to "SendBrakeCommand()". For rules containing timing logic (such as "event B is triggered 50ms after event A is executed"), the system inserts time synchronization functions, such as "Wait (50ms); ExecuteEventB ()", to ensure the accuracy of the event execution order.

[0108] For different test script development tools (such as vTESTstudio and CANoe), the system supports multi-syntax adaptation and automatically maps the rule chain to the scripting language of the corresponding tool. For example, in vTESTstudio, parallel events in the rule chain are converted into "ParGroup" parallel execution blocks, while in CANoe they are implemented through the "OnMessage" event triggering mechanism. The converted test script body contains clear comments and structured indentation.

[0109] 211. Using the test script body and the parameter list, generate test scripts adapted to different vehicle networking scenarios. The test scripts include combinations of different execution orders of the multiple independent events (this step has been explained in 106 and will not be repeated here).

[0110] 212. Using the test script development tool, compile the test script into an executable file of a specified format.

[0111] The system invokes the compilation engine of the test script development tool vTESTstudio to convert the text-formatted test script into an executable file in a specified format. It should be understood that the specified format here is .vtuexe, a commonly used format for test scripts and an execution format familiar to those skilled in the art. The compilation process includes three stages: lexical analysis, syntax checking, and code generation. First, the script code is scanned to identify lexical units such as variable names (e.g., VehicleSpeed) and function names (e.g., SendBrakeCommand()). Then, the code structure is verified to conform to the tool's syntax rules (e.g., matching brackets in conditional statements, data type consistency). If errors such as "undefined trigger condition" or "missing action function parameters" are found, detailed error messages are generated in the development tool interface. Finally, a .vtuexe instruction set recognizable by CANoe is generated based on the target hardware architecture (e.g., x86 or ARM), ensuring efficient code execution in the hardware-in-the-loop simulation environment.

[0112] Taking vTESTstudio as an example, the compiled executable file contains a symbol table, instruction opcodes, and a data segment. The symbol table records the mapping relationship between signal variables and hardware registers (such as mapping the "vehicle speed" variable in the script to the 0x101 register address of the CAN bus), ensuring the accuracy of data interaction during simulation. During the compilation process, the system will also trigger error reports or warnings to remind users that there may be execution problems in the current compilation process.

[0113] 213. Load the executable file into the test unit of the vehicle communication simulation software tool to obtain the loaded executable file.

[0114] The system either adds an executable file to the test unit or starts the test unit process via vTESTstudio's ExecutionEngine. This process uses a dynamic loading mechanism (such as .NET reflection) to load the compiled executable file (.dll) into the application domain. After loading, the system traverses the mapping table to check if all variables have corresponding entities in the simulation environment. If unmapped variables exist (e.g., a script references a non-existent signal), an error report is generated and loading is terminated; if all mappings are successful, the test unit is switched to a standby state, awaiting execution instructions. (The test unit is the core module in the simulation software responsible for executing test logic, supporting dynamic loading of external programs and data interaction with virtual vehicle models and traffic environment models.)

[0115] 214. Based on the loaded executable file and the signal influence relationship graph, select the appropriate scenario variant from the scenario variant library to obtain the corresponding test cases. The scenario variant library includes different vehicle models, different vehicle configurations, and scenario coverage.

[0116] Based on the logical requirements of the loaded executable file and the constraints of the signal influence relationship graph, the system dynamically selects suitable scene variants from the scene variant library. The scene variant library predefines various testing dimensions, such as:

[0117] Vehicle type dimension: Includes dynamic models of different vehicle types such as sedans, SUVs, and trucks (e.g., trucks have longer braking distances, and SUVs have a higher center of gravity, resulting in a lower rollover threshold).

[0118] Configuration dimension: differentiate whether it is equipped with active safety systems such as ABS and ESP, or the parameter differences of different communication modules (such as LTE-V2X and DSRC);

[0119] Scene coverage dimension: hierarchical configuration from simple scenarios (such as a single vehicle going straight) to complex scenarios (such as collision warning at a multi-vehicle intersection).

[0120] During the screening process, the system first analyzes the signal types and triggering conditions involved in the loaded executable file. For example, if the test script contains logic to "detect pedestrians crossing and trigger emergency braking", the system will prioritize scene variants that include "pedestrian dynamic models" in the scene coverage and have vehicle configurations with automatic emergency braking (AEB) function.

[0121] After selecting a scenario variant, the system automatically generates test cases. These cases include specific initial conditions (e.g., initial vehicle speed of 50 km / h, pedestrian appearance position 20 meters from the intersection), expected results (e.g., braking distance less than 15 meters), and evaluation metrics (e.g., communication latency < 100 ms). For example, for the rainy scenario variant for SUVs, the test cases automatically adjust the vehicle acceleration threshold to -6 m / s² and add an environmental variable of "wet road adhesion coefficient 0.3" to ensure that the test cases perfectly match the parameters of the scenario variant. Through this dynamic adaptation mechanism, the system can quickly generate a set of test cases covering multi-dimensional scenarios, significantly improving the comprehensiveness and relevance of the testing.

[0122] 215. Based on the test cases, conduct simulation tests on vehicle-to-everything (V2X) communication in the fusion scenario using hardware-in-the-loop simulation technology to obtain an automated test report.

[0123] The system loads the generated test cases into a hardware-in-the-loop (HIL) simulation platform, which integrates real vehicle electronic control units (ECUs), communication modules, and a virtual traffic environment. Taking the fusion scenario of "multi-vehicle interaction and pedestrian crossing at an urban intersection" as an example, during the simulation:

[0124] Environment simulation: The virtual engine generates a 3D intersection scene that includes traffic lights, buildings, and dynamic pedestrians. Pedestrian models cross the road according to test case parameters (such as a moving speed of 1.5 m / s).

[0125] Signal interaction: The vehicle ECU sends steering and braking signals through a simulated bus (such as CAN), the roadside unit (RSU) simulates broadcast traffic signal status, and vehicles and pedestrians exchange location information through a virtual communication link (such as PC5 interface);

[0126] Data acquisition: The sensor module captures vehicle speed, acceleration and other data in real time, while the communication module records indicators such as signal transmission delay and packet loss rate.

[0127] After the simulation, the system automatically compares the measured data with the expected results of the test cases (such as whether the vehicle triggers a warning 2 seconds before a pedestrian crosses the road), and generates an automated test report containing the pass rate and abnormal data points. The report displays key signal curves (such as the trend of vehicle speed over time) in chart form and marks violations (such as "braking distance exceeds the threshold of 2.3 meters").

[0128] 216. Based on the automated test report, the signal influence relationship graph, and the preset scenario rule base, assess the risk level of the fusion scenario.

[0129] The system assesses scenario risks through multi-dimensional data fusion: Based on the signal impact relationship graph, it identifies high-risk signal chains (such as "vehicle speed > 60km / h and lateral acceleration > 1.8m / s²" corresponding to rollover risk). If the signal combination appears frequently in the test report and is accompanied by abnormal results, the risk weight is increased. The system compares the test case execution results with the standard rules in the scenario rule base (such as "emergency braking response time should be < 0.5 seconds"), counts the number of rule violations, and the more violations, the higher the risk level. Based on the importance of signals in the signal impact relationship graph (such as braking signal weight 40%) and the risk level, the system calculates the comprehensive risk value through a fuzzy logic algorithm and classifies it into three levels: low, medium, and high.

[0130] For example, if in a certain scenario test, "the average transmission delay of the emergency braking signal of the vehicle in front reaches 150ms" (exceeding the rule base threshold of 100ms), and this delay increases the probability of collision with the vehicle behind by 30% (based on the correlation strength between "delay and collision risk" in the graph), then the scenario is assessed as "high risk".

[0131] 217. Based on the risk level and the automated test report, generate avoidance strategy suggestions and early warning information.

[0132] The system automatically generates targeted strategies based on the risk assessment results:

[0133] Low-risk scenarios: It is recommended to optimize non-critical parameters (such as adjusting the response latency of the entertainment system) and generate an alert for "monitoring signal fluctuations";

[0134] Medium-risk scenario: Trigger the default repair scheme in the rule base (such as increasing CAN bus bandwidth to reduce communication latency) and issue a warning "Signal priority needs to be verified";

[0135] High-risk scenarios: Generate mandatory repair strategies (such as recalibrating the braking signal threshold), and link the development process to create defect work orders, issuing an alert to "immediately stop the deployment of the relevant scenario".

[0136] 218. Call a Python script to send the automated test report, the avoidance strategy suggestions, and the warning information to the designated email address.

[0137] The system uses a built-in Python script interface to encapsulate structured data (test report PDFs, strategy suggestion tables, and alert texts) into email body text. The script supports batch sending from multiple email addresses, attachment encryption, and sending status tracking.

[0138] After the email is sent, the system records the sending time, recipient, and attachment hash value for easy traceability. Once developers receive the email, they can directly locate the point of reproduction of the abnormal scenario in the simulation environment via hyperlinks in the report, achieving closed-loop management of the "test, evaluate, and fix" process.

[0139] The V2X testing method based on HIL simulation in this application embodiment acquires basic signal data by importing vehicle communication simulation software data, analyzes signal influence relationships to generate a spectrum, decomposes complex scenarios into independent events and determines the execution order, generates the main body of the test script and test scripts adapted to different scenarios by combining the scenario rule base, and executes the test based on hardware-in-the-loop simulation technology. This achieves full automation from data acquisition and scenario analysis to script generation and simulation testing. It not only solves the problems of limited coverage of traditional test scenarios and poor script flexibility, but also greatly improves the efficiency, flexibility and coverage of V2X automated testing, ensuring the reliability and performance of the vehicle networking system in complex scenarios.

[0140] The methods provided in the above embodiments can be executed by a V2X automated testing system, which is composed of electronic devices. The electronic devices in these embodiments are described below from a hardware processing perspective; please refer to [link to relevant documentation]. Figure 3 This is a schematic diagram of a hardware structure of an electronic device in an embodiment of this application.

[0141] It should be noted that, Figure 3 The structure of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0142] like Figure 3As shown, the electronic device includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on a program stored in Read-Only Memory (ROM) 302 or a program loaded from storage portion 308 into Random Access Memory (RAM) 303, such as performing the methods described in the above embodiments. The Random Access Memory (RAM) 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0143] The following components are connected to the input / output (I / O) interface 305: an input section 306 including audio input devices, push-button switches, etc.; an output section 307 including displays, audio output devices, indicator lights, etc.; a storage section 308 including hard disks, etc.; and a communication section 309 including network interface cards such as LAN (Local Area Network) cards, modems, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to the input / output (I / O) interface 305 as needed. Removable media 311, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on the drive 310 as needed so that computer programs read from them can be installed into the storage section 308 as needed.

[0144] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by the Central Processing Unit (CPU) 301, it performs the various functions defined in the present invention.

[0145] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0146] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0147] Specifically, the electronic device of this embodiment includes a processor and a memory. The memory is coupled to one or more processors and is used to store computer program code. The computer program code includes computer instructions. One or more processors call the computer instructions to cause the electronic device to perform the method provided in the above embodiment.

[0148] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The storage medium carries one or more computer programs that, when executed by a processor of the electronic device, cause the electronic device to implement the methods provided in the above embodiments.

[0149] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0150] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0151] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0152] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A V2X testing method based on HIL simulation, applied to a V2X automated testing system, characterized in that, include: Import the database file and system variables from the vehicle communication simulation software tool into the test script development tool to obtain the vehicle's basic signal data. The system variables include vehicle operating status, environmental conditions, and test scenario-related variables. The basic signal data includes vehicle position, vehicle acceleration, and vehicle speed. Based on the basic signal data and the system variables, the influence relationship between the basic signals is analyzed to obtain a signal influence relationship map, which includes the basic signal data, signal importance and triggering conditions. Based on the signal influence relationship graph, the complex test scenario is decomposed into multiple independent events to obtain a parameter list. The parameter list includes the triggering conditions, related signal data, and dynamic change range of the related signal data for each independent event. Based on the parameter list and the signal influence relationship graph, the multiple independent events are sorted to obtain the execution order of the multiple independent events; Rules related to the multiple independent events are extracted from a preset scenario rule base, and combined with the execution order to generate the main body of the test script. The scenario rule base contains mapping rules between scenario triggering conditions and execution actions. The test script body and the parameter list are used to generate test scripts adapted to different vehicle networking scenarios. The test scripts include combinations of different execution orders of the multiple independent events. Based on the test script, the vehicle-to-everything (V2X) communication in the fusion scenario is simulated and tested using hardware-in-the-loop (HIL) simulation technology, and an automated test report is obtained.

2. The method according to claim 1, characterized in that, Based on the signal influence relationship graph, the complex test scenario is decomposed into multiple independent events, resulting in a parameter list, specifically including: Based on the signal influence relationship spectrum and the physical relationship of the basic signal, the variation range of the basic signal data is analyzed; Based on the range of change and the system variables, analyze the environmental limitations on the range of change to obtain the adjusted range of change; Based on the adjusted range of change and the triggering conditions, the complex test scenario is decomposed into multiple independent events, and a parameter list for each independent event is obtained.

3. The method according to claim 1, characterized in that, Based on the parameter list and the signal influence relationship graph, the multiple independent events are sorted to obtain the execution order of the multiple independent events, specifically including: Based on the signal influence relationship map and the multiple independent events, a priority evaluation matrix is ​​constructed; Calculate the priority score for each individual event based on the priority evaluation matrix; Based on the priority score and the parameter list, a priority queue is established to determine the execution order of the multiple independent events; Perform conflict detection on the priority queue and analyze events that can be executed simultaneously; Based on the events that can be executed simultaneously and the priority queue, an optimal execution sequence is generated to obtain the execution order.

4. The method according to claim 1, characterized in that, The step of extracting rules related to the multiple independent events from a preset scenario rule base, and generating the main body of the test script in combination with the execution order, specifically includes: A matching rule is constructed based on the execution order, and the matching rule includes a rule template and rule combination logic; Based on the mapping rules and matching rules of the scene rule base, a set of rules that meet the conditions is retrieved from the scene rule base to obtain a rule chain, wherein the mapping rule is the mapping relationship between the triggering condition and the execution action; The rule chain is converted into a unified standard test statement to obtain the main body of the test script.

5. The method according to claim 4, characterized in that, The step of retrieving a set of rules that meet the conditions from the scene rule base based on the mapping rules and the matching rules to obtain a rule chain specifically includes: Based on the mapping rules and matching rules of the scenario rule base, a set of rules that meet the conditions is retrieved from the scenario rule base to obtain an initial rule chain; Based on the initial rule chain, the correlation between rules is analyzed to obtain the processed rule chain. The processing includes merging similar rules and deleting redundant rules. Based on the signal influence relationship graph, the transition logic of the rule chain is supplemented to obtain a logically complete rule chain; The execution conditions of the logically complete rule chain are adjusted according to the parameter list to obtain the optimized rule chain.

6. The method according to claim 1, characterized in that, Based on the test script, the vehicle-to-everything (V2X) communication in the fusion scenario is simulated and tested using hardware-in-the-loop (HIL) simulation technology to obtain an automated test report, which specifically includes: The test script is compiled into an executable file of a specified format using the test script development tool. The executable file is loaded into the test unit of the vehicle communication simulation software tool to obtain the loaded executable file; Based on the loaded executable file and the signal influence relationship graph, a suitable scenario variant is selected from the scenario variant library to obtain the corresponding test cases. The scenario variant library includes different vehicle models, different vehicle configurations, and scenario coverage. Based on the test cases, the vehicle-to-everything (V2X) communication in the fusion scenario is simulated and tested using hardware-in-the-loop (HIL) simulation technology, and an automated test report is obtained.

7. The method according to claim 1, characterized in that, After the step of simulating and testing the vehicle-to-everything (V2X) communication in the fusion scenario using hardware-in-the-loop simulation technology based on the test script to obtain an automated test report, the specific steps include: Based on the automated test report, the signal impact relationship graph, and the preset scenario rule base, assess the risk level of the fusion scenario; Based on the risk level and the automated test report, generate avoidance strategy suggestions and early warning information; The Python script is invoked to send the automated test report, the avoidance strategy suggestions, and the warning information to the designated email address.

8. A V2X automated testing system, characterized in that, Includes one or more processors and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, and the one or more processors calling the computer instructions to cause the V2X automated test system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are run on the V2X automated testing system, the V2X automated testing system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the V2X automated testing system, the V2X automated testing system performs the method as described in any one of claims 1-7.

Images