Scene-based testing method for vehicle-road-cloud integrated system and electronic device

Abstract

This invention discloses a scenario-based testing method and electronic device for vehicle-road-cloud integrated systems. The scenario-based testing method for vehicle-road-cloud integrated systems includes: responding to the start of a test scenario, identifying the units associated with the target test scenario as associated units, and acquiring the data of the associated units; for each associated unit, judging whether the data of the associated unit satisfies the rules in the rule base of the associated unit, and obtaining the judgment result; and outputting the cause of the problem based on the judgment result. This invention addresses the problems of difficult and time-consuming debugging of vehicle-road-cloud integrated systems by providing a structured, data-driven, and traceable solution, which can effectively improve the stability of real-vehicle testing and the efficiency of R&D iteration, significantly reduce the complexity of problem investigation, and reduce labor costs, thus possessing strong engineering practical value and promotional significance.

Description

Technical Field

[0001] This invention relates to the field of vehicle-related technologies, and in particular to a scenario-based testing method, electronic device, storage medium, and computer program product for an integrated vehicle-road-cloud system. Background Technology

[0002] With the rapid development of intelligent transportation technology, vehicle-road-cloud integrated systems are becoming an important direction for industry evolution. This system integrates vehicle terminals, roadside units, and cloud control platforms, forming a complex cross-domain collaborative ecosystem. Among these, the cloud control platform undertakes core functions such as data aggregation, task scheduling, and policy distribution, encompassing vehicle-road-cloud gateways, message buses, perception fusion standard components, event perception standard components, hierarchical sharing interfaces, and various cloud control applications for autonomous driving. Its architecture is vast and contains numerous modules.

[0003] During the actual vehicle debugging phase, the high complexity of the system and the strong coupling of multiple modules pose a huge challenge to troubleshooting: when abnormal behavior occurs, it may be due to network communication, data quality, timing delay, or the internal logic of a certain computing module. The cause is often difficult to define, and the reproduction and localization of the problem are also more difficult.

[0004] Currently, debugging integrated vehicle-road-cloud systems primarily relies on log analysis methods. Testers typically need to collect log files from various modules and attempt to reconstruct the scenario and cause of problems through keyword searches, timestamp comparisons, and other methods. This approach suffers from inefficiency, fragmented information, lack of context, high technical requirements, and difficulty in reproducing issues. To improve problem localization efficiency, the industry has developed full-data acquisition systems, key indicator monitoring systems, distributed tracing systems, and anomaly detection systems. However, these systems still face common problems in integrated vehicle-road-cloud testing and debugging, such as data overload, lack of scenario correlation, module isolation, static configuration, and verification difficulties. Summary of the Invention

[0005] Therefore, it is necessary to address the technical problem of difficulty in locating the testing of vehicle-road-cloud integrated systems using existing technologies, and to provide a scenario-based testing method, electronic equipment, storage media, and computer program products for vehicle-road-cloud integrated systems.

[0006] This invention provides a scenario-based testing method for integrated vehicle-road-cloud systems, including: Upon the start of a test scenario, identify the unit associated with the target test scenario as the associated unit and obtain the data of the associated unit; For each associated unit, based on the rule base of the associated unit, it is determined whether the data of the associated unit satisfies the rules in the rule base, and the determination result is obtained; Based on the judgment result, output the reason for the problem.

[0007] Further, for each associated unit, based on the rule base of the associated unit, determining whether the data of the associated unit satisfies the rules in the rule base to obtain a determination result includes: For each associated unit, obtain the rule base of the associated unit, the rule base including multiple rules; Based on the data from the associated unit, it is determined whether each rule is satisfied, and the judgment result for each rule is obtained.

[0008] Furthermore, the step of outputting the cause of the problem based on the judgment result includes: When there is a rule whose judgment result is not satisfied, the rule whose judgment result is not satisfied is regarded as a problem rule. The problem reason corresponding to the problem rule is searched from the result library and output. The result library includes the problem reasons corresponding to multiple rules or combinations of rules. The rule combination includes multiple rules.

[0009] Furthermore, the step of searching the result database for the cause of the problem corresponding to the problem rule includes: If the problem rule has no dependent rules, then the cause of the problem corresponding to the problem rule is searched from the result database; If the problem rule has a dependent rule, then determine whether the dependent rule is satisfied, obtain the judgment result of the dependent rule, combine the judgment result of the problem rule with the judgment result of the dependent rule to form a judgment result combination, and search the result database for the problem cause corresponding to the judgment result combination.

[0010] Furthermore, the cause of the problem includes one or more problem elements, and the cause of the problem includes the confidence level corresponding to each problem element, and each problem element corresponds to the problem rule or the dependency rule.

[0011] Furthermore, after searching the result database for the cause of the problem corresponding to the problem rule, the process also includes: Obtain the results of manual review of the problem rules, and update the problem reasons corresponding to the problem rules in the result database based on the results of manual review.

[0012] Furthermore, updating the cause of the problem corresponding to the problem rule in the result database based on the manual review result includes: Among the causes of the problem, the problem elements confirmed by manual review are designated as problem elements to be added, and other problem elements are designated as problem elements to be reduced. The confidence level of the problem elements to be added is increased, and the confidence level of the problem elements to be reduced is decreased. The changed confidence levels are then saved to the result database.

[0013] This invention provides an electronic device, comprising: At least one processor; and, A memory communicatively connected to at least one of the processors; wherein, The memory stores instructions that can be executed by at least one of the processors, which enable the at least one processor to perform the scenario-based testing method for the vehicle-road-cloud integrated system as described above.

[0014] This invention provides a storage medium that stores computer instructions, which, when executed by a computer, are used to perform all steps of the scenario-based testing method for an integrated vehicle-road-cloud system as described above.

[0015] This invention provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the scenario-based testing method for an integrated vehicle-road-cloud system as described above.

[0016] This invention collects data from units managed within a test scenario and, based on the rule base of each unit, judges the rules to output the cause of the problem based on the judgment results. Addressing the challenges and long cycles of debugging integrated vehicle-road-cloud systems, this invention provides a structured, data-driven, and traceable solution. It effectively improves the stability of real-vehicle testing and the efficiency of R&D iteration, significantly reduces the complexity of problem investigation, and lowers labor costs, demonstrating strong engineering practical value and promotional significance. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a scenario-based testing method for a vehicle-road-cloud integrated system, according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating a scenario-based testing method for a vehicle-road-cloud integrated system, according to another embodiment of the present invention. Figure 3 A system schematic diagram of a scenario-based testing system for a vehicle-road-cloud integrated system, which is the preferred embodiment of the present invention; Figure 4 This is a flowchart illustrating the data acquisition process of the preferred embodiment of the present invention. Figure 5 This is a schematic diagram of the hardware structure of an electronic device according to the present invention. Detailed Implementation

[0018] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings. Identical components are indicated by the same reference numerals. It should be noted that the terms "front," "rear," "left," "right," "up," and "down" used in the following description refer to directions in the accompanying drawings, while the terms "inner" and "outer" refer to directions toward or away from the geometric center of a specific component, respectively.

[0019] The concepts involved in this invention include: Connected vehicles: These are vehicles with intelligent and connected capabilities that can communicate bidirectionally with cloud control platforms and other transportation infrastructure via onboard terminals. Connected vehicles can upload their own status information in real time, such as location, speed, heading, acceleration, and sensor perception results, while receiving collaborative perception, collaborative decision-making, and collaborative control commands from the cloud control platform, enabling dynamic collaboration between the vehicle and its external environment.

[0020] Roadside computing units (LCUs) are edge computing devices deployed along roads or at intersections. They are typically equipped with communication modules, sensing devices (cameras, radar, etc.), and computing and storage resources. LCUs are responsible for collecting road traffic information, running local algorithms to process data, and interacting in real time with cloud control platforms and connected vehicles to provide low-latency perception and decision support for vehicle-road cooperation.

[0021] Vehicle-Road-Cloud Gateway: As a bridge between vehicles, roadside equipment and the cloud control platform, the gateway provides functions such as protocol adaptation, message routing, security authentication, and load balancing to achieve interconnection between different communication protocols and different network domains, ensuring the efficiency and security of data transmission.

[0022] Message bus: In the vehicle-road-cloud integrated architecture, the message bus is used to decouple and enable efficient communication between various modules of the system. It supports data publishing / subscription, routing, and caching, ensuring that messages such as perception information, control commands, and status feedback can be transmitted with high reliability and low latency between vehicles, roadside units, and the cloud control platform.

[0023] Perception fusion standard components: These are core modules used to fuse multi-source information from vehicle-mounted sensors, roadside sensing devices, and historical data from the cloud. Through algorithms, these components align, filter, and synthesize sensing data from different sources and with varying levels of precision in both time and space, outputting a unified environmental perception result. This provides complete and accurate input for subsequent decision-making and control.

[0024] Event-aware standard components: These are used to identify and analyze critical events in road traffic, such as vehicle anomalies, road obstructions, traffic accidents, or sudden weather events. Based on perceived data and business rules, this module detects events that may affect driving safety or traffic efficiency in real time and generates event information for use by the cloud control platform or related applications.

[0025] Tiered sharing interfaces refer to a type of interface in a vehicle-road-cloud integrated system that provides data access and interaction capabilities for services with different security levels, functional levels, or permission levels. Through tiered authorization and sharing strategies, it ensures that various services efficiently utilize platform data and capabilities while meeting security and compliance requirements, achieving "on-demand sharing and tiered openness."

[0026] Cloud-based control platform: The core infrastructure for vehicle-road-cloud integration, it aggregates various data from vehicles and roadside equipment, providing capabilities such as computing, storage, communication, scheduling, and algorithm services. The cloud-based control platform supports functions such as perception fusion, collaborative decision-making, collaborative control, data management, and simulation verification, and is a key carrier for realizing vehicle-road cooperative services.

[0027] Cloud-based applications: Various business systems and application services developed based on the cloud-based control platform, such as lane-level path planning, traffic signal priority, cooperative lane changing, emergency avoidance, and remote driving assistance. These applications utilize the perception, decision-making, control, and data capabilities provided by the platform to offer intelligent and collaborative services to connected vehicles and road traffic participants.

[0028] like Figure 1 The diagram shows a workflow of a scenario-based testing method for a vehicle-road-cloud integrated system according to an embodiment of the present invention, including: Step S101: Respond to the start of the test scenario, determine the unit associated with the target test scenario as the associated unit, and obtain the data of the associated unit; Step S102: For each associated unit, based on the rule base of the associated unit, determine whether the data of the associated unit satisfies the rules in the rule base, and obtain the judgment result; Step S103: Based on the judgment result, output the cause of the problem.

[0029] Specifically, the present invention can be applied to electronic devices with processing capabilities, such as computers.

[0030] This invention proposes a vehicle-road-cloud integrated testing and debugging method and system based on scenario-based management. This technology uses "scenario" as the core concept, abstracting the real-vehicle testing process into manageable and traceable scenario objects, and establishing relationships between scenarios and regions, equipment, and functional modules. By modeling system dependencies and comprehensively collecting input and output data from key interfaces and modules, a solid data foundation is provided for subsequent root cause analysis and verification.

[0031] First, execute step S101 to respond to the start of the test scenario, determine the unit associated with the target test scenario as the associated unit, and obtain the data of the associated unit.

[0032] Specifically, each test scenario is pre-associated with and recorded units. These units include functional modules within the test system and external devices.

[0033] In some embodiments, a test area is determined according to the test scenario, external devices in the test area are designated as associated devices, functional modules through which data passes during the test are designated as associated modules, and associated devices and associated modules are designated as associated units of the test scenario.

[0034] The purpose of identifying related units for a test scenario is primarily to reduce the amount of data collected and analyzed, and to eliminate interference from irrelevant data. This is also a common pain point in problem analysis. For example, the Beijing Yizhuang Autonomous Driving Demonstration Zone has thousands of connected intersections, but the test scenario may only need to use one or two designated intersections. Therefore, it is only necessary to collect and analyze the data from these one or two intersections, while the data from other intersections does not need to be collected and analyzed, thus avoiding excessive data volume. Furthermore, even if there are problems with the data from other intersections, it will not affect the data collection and analysis of the current test scenario.

[0035] During implementation, testers first define the target test scenario using the scenario management function.

[0036] During real-vehicle testing, testers use a visual interface to initiate tests for the corresponding scenarios. The data acquisition module monitors the scenario test status; when it detects that a scenario test is enabled, it creates a data acquisition task and notifies the units that depend on the scenario. Each unit receives the scenario debugging request and, based on the device and area information in the scenario definition, formats and outputs the relevant device inputs and outputs, along with related log data, to the corresponding scenario debugging queue. The data analysis module reads the data from the corresponding scenario debugging queue and persists it for later use.

[0037] Then, step S102 is executed: for each associated unit, based on the rule base of the associated unit, it is determined whether the data of the associated unit satisfies the rules in the rule base, and the determination result is obtained.

[0038] Specifically, if the expected results are not achieved during the actual vehicle test, steps S102 and S103 can be executed for troubleshooting. If the actual vehicle test achieves the expected results, no troubleshooting is required and the test can be terminated. However, if steps S102 and S103 are to be executed to further improve the accuracy of the test, the data can also be examined.

[0039] Based on the dependency relationship between test scenarios and units, the units associated with the target test scenario are obtained as associated units, and the input and output data and process logs of each associated unit are analyzed layer by layer.

[0040] At the implementation level, a rule base is maintained for each device and module, that is, a rule base is maintained for each unit. The rule base includes multiple rules. After the associated unit is determined, the data is judged according to the rules in the rule base of the associated unit. The rules include various indicators and / or various conditions. For each associated unit, all rules in the rule base are judged one by one to determine the data integrity, whether the characteristics meet the requirements, whether the latency meets the standards, etc.

[0041] Finally, step S103 is executed, and the cause of the problem is output based on the judgment result.

[0042] Specifically, the judgment result includes "satisfied" and "unsatisfied." "Satisfied" means the data meets all the indicators and conditions defined by the rule. For example, the data meets the integrity condition, the features meet the requirements, and the delay meets the standard. "Unsatisfied" means the data does not meet at least one of the indicators or conditions defined by the rule. For example, the data does not meet the integrity requirement, the features do not meet the requirements, or the delay does not meet the standard.

[0043] If there are rules that are not satisfied, output the corresponding reason for the problem based on the rules that are not satisfied.

[0044] If all rules are met, the test can be considered successful.

[0045] Compared to traditional debugging methods that rely on manual experience and scattered logs, this invention offers significant advantages. First, the scenario-based modeling approach provides testing activities with clear contextual information, facilitating unified semantics during cross-departmental and cross-team collaborations and reducing communication and manpower costs. Second, the robust data collection mechanism provides comprehensive, end-to-end evidence for analysis, avoiding repeated verification due to missing information. Third, root cause analysis, with unit dependencies and call chains as its core logic, ensures an orderly investigation process rather than blind searching, significantly improving localization efficiency.

[0046] This invention collects data from units managed within a test scenario and, based on the rule base of each unit, judges the rules to output the cause of the problem based on the judgment results. Addressing the challenges and long cycles of debugging integrated vehicle-road-cloud systems, this invention provides a structured, data-driven, and traceable solution. It effectively improves the stability of real-vehicle testing and the efficiency of R&D iteration, significantly reduces the complexity of problem investigation, and lowers labor costs, demonstrating strong engineering practical value and promotional significance.

[0047] like Figure 2 The diagram shown is a flowchart of a scenario-based testing method for a vehicle-road-cloud integrated system according to another embodiment of the present invention, including: Step S201: Response test scenario starts, determine the unit associated with the target test scenario as the associated unit, and obtain the data of the associated unit.

[0048] Step S202: For each associated unit, obtain the rule base of the associated unit, the rule base including multiple rules; Based on the data from the associated unit, it is determined whether each rule is satisfied, and the judgment result for each rule is obtained.

[0049] Step S203: When there is a rule whose judgment result is not satisfied, the rule whose judgment result is not satisfied is taken as a problem rule, the problem reason corresponding to the problem rule is searched from the result library and output. The result library includes problem reasons corresponding to multiple rules or combinations of rules, and the rule combination includes multiple rules.

[0050] This embodiment proposes a scenario-based testing and debugging method for integrated vehicle-road-cloud systems. This testing method can be implemented through a testing system.

[0051] like Figure 3 The diagram shown is a system principle diagram of a scenario-based testing system for a vehicle-road-cloud integrated system according to a preferred embodiment of the present invention. The system includes: a scenario management module 301, a data acquisition module 302, a root cause analysis module 303, and a playback verification module 304. The scenario management module abstracts testing activities into "scenarios" and establishes the association relationships between scenarios and regions, equipment, and functional modules. It also defines dependent functional modules and their hierarchical structure, providing a clear context for subsequent debugging. During test execution, the data acquisition module collects input / output data from associated units and equipment in real time, providing a complete and reliable data foundation for analysis and fault location. The root cause analysis module verifies the fault layer by layer from top to bottom based on unit dependencies, quickly locating the cause of the fault.

[0052] After the problem is fixed, the replay verification module uses the collected data to perform a replay test, verifying the repair effect and preventing the problem from recurring. Through the collaborative work of the above modules, efficient and accurate debugging of faults in the vehicle-road-cloud integrated system can be achieved.

[0053] Specifically, step S201 is executed first to respond to the start of the test scenario, determine the unit associated with the target test scenario as the associated unit, and obtain the data of the associated unit.

[0054] Specifically, during implementation, testers first define the target test scenario using the scenario management function. Examples include "cloud-controlled emergency braking" and "cloud-controlled ramp merging." The scenario includes operational steps and business objectives, and also clearly defines the functional modules and equipment that serve as associated units. Taking the cloud-controlled emergency braking scenario as an example, the scenario is defined as follows: "QD1E0001" was used as the main vehicle for the test, and "QD1E0002" was used as the event vehicle for the test. Scenario verification was conducted on the road sections between the intersections of Hanjin Road and Jinjian Road and Fengyuan Road and Jinjian Road in the demonstration area. This involves sensing devices “RCU01”, “RCU02”, etc. It involves functional modules such as vehicle-road-cloud gateway, fusion perception standard components, hierarchical sharing interface, and emergency braking application; The vehicle involved in the incident braked suddenly near the coordinates "106.322268, 29.516558", causing an emergency braking event that affected the vehicles behind it. Emergency braking applications issue emergency braking / lane-changing commands to the vehicle to avoid a collision.

[0055] During real-vehicle testing, testers use a visual interface to initiate tests for the corresponding scenarios. The data acquisition module monitors the scenario test status; when it detects that a scenario test is enabled, it creates a data acquisition task and notifies the units that the scenario depends on. Each unit receives the scenario debugging request and, based on the unit and region information in the scenario definition, formats and outputs the inputs and outputs of related units, along with relevant log data, and outputs them to the corresponding scenario debugging queue. The data analysis module reads the data from the corresponding scenario debugging queue and persists it for later use.

[0056] Then, step S202 is executed to obtain the rule base of each associated unit, wherein the rule base includes multiple rules; Based on the data from the associated unit, it is determined whether each rule is satisfied, and the judgment result for each rule is obtained.

[0057] Specifically, based on the dependency relationship between the test scenario and the equipment, the units associated with the target test scenario are obtained as associated units, and the input and output data and process logs of each associated unit are analyzed layer by layer.

[0058] At the implementation level, the root cause analysis module maintains a rule base for each unit, used to judge the integrity of data, whether features meet requirements, and whether latency meets standards, etc. For example, for RCU01 mentioned above, the rules are used to determine whether the input and output are compliant.

[0059] like Figure 4 The diagram shown illustrates the data acquisition workflow of the preferred embodiment of the present invention, including: Step S401: The tester starts the scene from the scene library; Step S402: The data acquisition module monitors the scene status; Step S403: The data acquisition module acquires the associated units of the scene; Step S404: Data acquisition notification of the associated unit scene status; Step S405: The associated unit starts the debug mode and outputs the input and output data of the associated unit to the specified queue; Step S406: The data acquisition module reads the data of each associated unit in the queue and stores it persistently.

[0060] Finally, step S203 is executed. When there is a rule whose judgment result is not satisfied, the rule whose judgment result is not satisfied is taken as a problem rule. The problem reason corresponding to the problem rule is searched from the result library and output. The result library includes the problem reasons corresponding to multiple rules or combinations of rules. The rule combination includes multiple rules.

[0061] This embodiment establishes a debugging method of "scenario modeling - data acquisition - root cause analysis," enabling complex vehicle-road-cloud integrated systems to possess standardized and traceable debugging capabilities, thereby achieving efficient and accurate debugging of vehicle-road-cloud integrated system faults. Addressing the difficulties and long cycles in debugging vehicle-road-cloud integrated systems, this embodiment provides a structured, data-driven, and traceable solution, effectively improving the stability of real-vehicle testing and R&D iteration efficiency, significantly reducing the complexity of problem investigation, and lowering labor costs. It has strong engineering practical value and promotional significance.

[0062] In one embodiment, the step of searching for the cause of the problem corresponding to the problem rule from the result database includes: If the problem rule has no dependent rules, then the cause of the problem corresponding to the problem rule is searched from the result database; If the problem rule has a dependent rule, then determine whether the dependent rule is satisfied, obtain the judgment result of the dependent rule, combine the judgment result of the problem rule with the judgment result of the dependent rule to form a judgment result combination, and search the result database for the problem cause corresponding to the judgment result combination.

[0063] Specifically, if a rule is satisfied, the next rule is evaluated. If a rule is not satisfied, it is considered a problematic rule. Each rule can be configured with one or more dependent rules, which can depend on rules within the same unit or rules from preceding units. Units include functional modules or devices. For example, the "input data delay of this unit" rule can depend on the "output data delay of preceding units" rule.

[0064] Therefore, if a problem rule has no dependent rules, the corresponding problem cause is directly retrieved from the results database. The results database pre-loads different problem causes corresponding to different rules. For example, the rule "Input data delay in this unit" could correspond to "Network problem".

[0065] If the problem rule has dependent rules, then it is further determined whether the dependent rules are satisfied, obtaining the judgment result of the dependent rules. The judgment result of the problem rule and the judgment result of the dependent rules are combined into a judgment result combination, and the problem cause corresponding to the judgment result combination is searched in the result database. The judgment result combination includes the judgment result of the problem rule itself and the judgment result of the dependent rules.

[0066] For example, if the combined result is "Input data delay in this unit is too large, but output delay in the preceding unit is normal," the corresponding cause of the problem can be retrieved from the result database as: "Network problem or excessive CPU load in this unit causing slow processing." The cause of the problem is output as a localization conclusion to facilitate testers in locating the issue.

[0067] This embodiment improves the accuracy of problem localization by adding dependency rule judgments.

[0068] In one embodiment, the cause of the problem includes one or more problem elements, and the cause of the problem includes a confidence level corresponding to each problem element, and each problem element corresponds to the problem rule or the dependency rule.

[0069] Specifically, the cause of a problem includes one or more problem elements, each corresponding to a problem rule or dependency rule. For example, when "the input data delay of this unit is too large, but the output delay of the front-end unit is normal," the corresponding cause can be obtained from the result database as: "90% probability of network problem, 10% probability of high CPU load in this unit causing slow processing." Here, "network problem" is one problem element, and "high CPU load in this unit causing slow processing" is another. Simultaneously, a confidence level is set for each problem element. For example, 90% confidence level for the problem element "network problem," and 10% confidence level for the problem element "high CPU load in this unit causing slow processing." The problem elements included in the cause of a problem, along with their confidence levels, are pre-entered manually into the result database based on experience and saved in combination with the judgment results.

[0070] This embodiment provides corresponding problem reasons including multiple problem elements for a combination of judgment results, and sets the confidence level of each problem reason, thereby facilitating testers to locate the problem.

[0071] In one embodiment, after searching for the cause of the problem corresponding to the problem rule in the result database, the method further includes: Obtain the results of manual review of the problem rules, and update the problem reasons corresponding to the problem rules in the result database based on the results of manual review.

[0072] Specifically, after obtaining the cause of the problem according to the problem rules, it is manually reviewed to determine whether the cause of the problem provided in the result database is correct, and the cause of the problem in the result database is updated based on the results of the manual review.

[0073] This embodiment updates the causes of problems in the result database based on the results of manual review. As the project lifecycle progresses, the rule database and result database are continuously enriched and optimized, the accuracy of root cause analysis is gradually improved, the workload of manual troubleshooting is gradually reduced, and finally, automatic fault delimitation and location are achieved.

[0074] In one embodiment, updating the cause of the problem corresponding to the problem rule in the result database based on the manual review result includes: Among the causes of the problem, the problem elements confirmed by manual review are designated as problem elements to be added, and other problem elements are designated as problem elements to be reduced. The confidence level of the problem elements to be added is increased, and the confidence level of the problem elements to be reduced is decreased. The changed confidence levels are then saved to the result database.

[0075] Specifically, after obtaining the cause of the problem rule, it is manually reviewed. This manual review verifies the correctness of the cause. The correct problem element is then confirmed based on the manual review results. The problem elements confirmed by the manual review are then designated as potential problem elements to be added.

[0076] The element to be added may or may not be already included in the cause of the problem. If the element is already included, its confidence level is increased directly. If it is not already included, it is added to the cause of the problem, and its confidence level is set to the initial confidence level. The initial confidence level is set manually.

[0077] At the same time, the confidence level of other problem elements in the cause of the problem is reduced.

[0078] In some embodiments, the sum of the confidence levels of all problem elements included in the cause of the problem is 1.

[0079] As an example, when the rule indicates "the input data latency of this unit is too high, but the output latency of the preceding unit is normal," the system might give the following reasons: "90% probability of network problem, 10% probability of slow processing due to excessive CPU load in this unit." If manual review confirms that the problem is caused by a network issue, the system will automatically adjust the confidence level of the network cause (i.e., the weight of the problem element), increasing the confidence level of "network problem" to 91% and decreasing the confidence level of "excessive CPU load" to 9%.

[0080] This embodiment adjusts the confidence level of problematic elements based on manual review, thereby reducing the workload of manual investigation.

[0081] In some embodiments, the method further includes: after the problem is fixed, re-importing the previously collected data stream to simulate the operating environment at that time and verifying the fix results.

[0082] Specifically, for confirmed issues, after developers fix them, they can directly use the replay verification function to re-import the previously collected complete data stream into the system, simulating the original operating environment, verifying the fix results, and evaluating the system's stability under the same conditions. The replay verification module uses the collected data to perform replay tests, verifying the fix's effectiveness and preventing the problem from recurring.

[0083] Through the above design, this embodiment forms a closed-loop debugging method of "scenario modeling - data acquisition - root cause analysis - replay verification," enabling the complex vehicle-road-cloud integrated system to have standardized, traceable, and repeatable debugging capabilities. The replay verification capability ensures that the repair measures can be fully verified under real data-driven conditions, forming a closed loop and preventing the recurrence of similar faults.

[0084] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0085] like Figure 5 The diagram shown is a hardware structure schematic of an electronic device according to the present invention, comprising: At least one processor 501; and, A memory 502 is communicatively connected to at least one of the processors 501; wherein, The memory 502 stores instructions that can be executed by at least one of the processors, which enable the at least one processor to perform the scenario-based testing method for the vehicle-road-cloud integrated system as described above.

[0086] Figure 5 Take a processor 501 as an example.

[0087] The electronic device may also include an input device 503 and a display device 504.

[0088] The processor 501, memory 502, input device 503 and display device 504 can be connected by a bus or other means. The figure shows an example of connection by bus.

[0089] The memory 502, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the scenario-based testing method for the vehicle-road-cloud integrated system in this embodiment of the application. Figure 1 , Figure 2 The method flow is shown. The processor 501 executes various functional applications and data processing by running non-volatile software programs, instructions, and modules stored in the memory 502, thereby realizing the scenario-based testing method for the vehicle-road-cloud integrated system in the above embodiment.

[0090] Memory 502 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of a scenario-based testing method for a vehicle-road-cloud integrated system. Furthermore, memory 502 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 502 may optionally include memory remotely located relative to processor 501, and these remote memories may be connected via a network to the apparatus performing the scenario-based testing method for a vehicle-road-cloud integrated system. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0091] The input device 503 can receive user clicks and generate signal inputs related to user settings and function control for scenario-based testing methods of the vehicle-road-cloud integrated system. The display device 504 may include display screens or other display devices.

[0092] When one or more modules are stored in the memory 502 and are run by one or more processors 501, the scenario-based testing method for the vehicle-road-cloud integrated system described in any of the above method embodiments is executed.

[0093] This invention collects data from the devices managed in the test scenario and, based on the rule base of each unit, judges the rules to output the cause of the problem. Addressing the difficulties and long cycles in debugging integrated vehicle-road-cloud systems, this invention provides a structured, data-driven, and traceable solution that effectively improves the stability of real-vehicle testing and the efficiency of R&D iteration, significantly reduces the complexity of problem investigation, and lowers labor costs. It has strong engineering practical value and promotional significance.

[0094] One embodiment of the present invention provides a storage medium that stores computer instructions. When a computer executes the computer instructions, it performs all the steps of the scenario-based testing method for the vehicle-road-cloud integrated system described above.

[0095] In the context of this disclosure, a storage medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. The storage medium can be a machine-readable signal medium or a machine-readable storage medium. Optionally, the storage medium can be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), compact disc ROM (CD-ROM), magnetic tape, floppy disk, and optical data storage device.

[0096] One embodiment of the present invention provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the scenario-based testing method for an integrated vehicle-road-cloud system as described above.

[0097] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A scenario-based testing method for an integrated vehicle-road-cloud system, characterized in that, include: Upon the start of a test scenario, identify the unit associated with the target test scenario as the associated unit and obtain the data of the associated unit; For each associated unit, based on the rule base of the associated unit, it is determined whether the data of the associated unit satisfies the rules in the rule base, and the determination result is obtained; Based on the judgment result, output the reason for the problem.

2. The scenario-based testing method for a vehicle-road-cloud integrated system according to claim 1, characterized in that, For each associated unit, based on the rule base of the associated unit, it is determined whether the data of the associated unit satisfies the rules in the rule base to obtain a determination result, including: For each associated unit, obtain the rule base of the associated unit, the rule base including multiple rules; Based on the data from the associated unit, it is determined whether each rule is satisfied, and the judgment result for each rule is obtained.

3. The scenario-based testing method for a vehicle-road-cloud integrated system according to claim 2, characterized in that, The step of outputting the cause of the problem based on the judgment result includes: When there is a rule whose judgment result is not satisfied, the rule whose judgment result is not satisfied is regarded as a problem rule. The problem reason corresponding to the problem rule is searched from the result library and output. The result library includes the problem reasons corresponding to multiple rules or combinations of rules. The rule combination includes multiple rules.

4. The scenario-based testing method for a vehicle-road-cloud integrated system according to claim 3, characterized in that, The step of searching for the cause of the problem corresponding to the problem rule in the result database includes: If the problem rule has no dependent rules, then the cause of the problem corresponding to the problem rule is searched from the result database; If the problem rule has a dependent rule, then determine whether the dependent rule is satisfied, obtain the judgment result of the dependent rule, combine the judgment result of the problem rule with the judgment result of the dependent rule to form a judgment result combination, and search the result database for the problem cause corresponding to the judgment result combination.

5. The scenario-based testing method for a vehicle-road-cloud integrated system according to claim 4, characterized in that, The cause of the problem includes one or more problem elements, and the cause of the problem includes the confidence level corresponding to each problem element. Each problem element corresponds to the problem rule or the dependency rule.

6. The scenario-based testing method for a vehicle-road-cloud integrated system according to claim 5, characterized in that, After searching the result database for the cause of the problem corresponding to the problem rule, the process also includes: Obtain the results of manual review of the problem rules, and update the problem reasons corresponding to the problem rules in the result database based on the results of manual review.

7. The scenario-based testing method for a vehicle-road-cloud integrated system according to claim 6, characterized in that, The step of updating the cause of the problem corresponding to the problem rule in the result database based on the manual review result includes: Among the causes of the problem, the problem elements confirmed by manual review are designated as problem elements to be added, and other problem elements are designated as problem elements to be reduced. The confidence level of the problem elements to be added is increased, and the confidence level of the problem elements to be reduced is decreased. The changed confidence levels are then saved to the result database.

8. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to at least one of the processors; wherein, The memory stores instructions that can be executed by at least one of the processors, which enable at least one of the processors to perform the scenario-based testing method for a vehicle-road-cloud integrated system as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium stores computer instructions, which, when executed by the computer, are used to perform all the steps of the scenario-based testing method for a vehicle-road-cloud integrated system as described in any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the scenario-based testing method for vehicle-road-cloud integrated systems as described in any one of claims 1 to 7.

Images