Intelligent driving assistance offline detection method and device, and electronic equipment

Abstract

The application discloses a kind of intelligent driving assistance offline detection method, device and electronic equipment, the method includes: based on quality evidence calculation each candidate scene risk weight w_s, and utilize historical test results to calibrate w_s;Under total test duration constraint Σ_{s∈S*}t_s≤B, solve the minimum scene subset S* and its execution order π that make coverage maximization and risk benefit maximization, and reserve exploration quota for new version change and unknown risk to form online sampling strategy;According to π, execute whole vehicle in loop / bench test and generate evidence package;Defect is labeled, automatically generates or combines new scene and updates scene library and sampling strategy.The intelligent driving assistance offline detection method, device and electronic equipment provided by the application can improve detection coverage and defect detection benefit without increasing production line beat burden, and enhance the traceability verification capability of end-to-end intelligent driving assistance system.

Description

Technical Field

[0001] This application relates to the field of whole vehicle in-loop simulation testing technology, and in particular to intelligent driving assistance off-line testing methods, devices and electronic equipment. Background Technology

[0002] End-to-end intelligent driving assistance systems directly output control or decision results in a data-driven manner, and their behavior is highly sensitive to scene distribution, sensor input, and version changes. If mass production line testing continues to use traditional static point testing or limited-condition road testing, problems such as insufficient coverage, non-reproducibility, or mismatched testing cycles are likely to occur. Vehicle-in-the-loop testing can reproduce traffic scenarios indoors and perform automated verification, but it faces strict cycle time constraints at the end of the production line, making it impossible to perform full-scale scenario regression. Simple random sampling will lead to missed high-risk defects; a fixed scenario list is insufficient to cope with version iterations and problem distribution drift. Therefore, a scenario selection and management method is needed that simultaneously considers detection coverage, defect detection benefits, and continuous self-updating capabilities under cycle time constraints. Summary of the Invention

[0003] The purpose of this invention is to provide a method, device, and electronic device for detecting defects in intelligent driving assistance systems, which can improve detection coverage and defect detection benefits without increasing the production line cycle time, and enhance the mass production-level traceability and verification capabilities of end-to-end intelligent driving assistance systems.

[0004] This invention provides the following solution:

[0005] According to one aspect of the present invention, a method for detecting the decommissioning of intelligent driving assistance systems is provided, the method comprising:

[0006] Obtain the production line inspection cycle number B, vehicle model version, and test target;

[0007] Construct a candidate scenario set that includes function points, triggering conditions and execution time, and extract quality evidence from production line defects, road test events, after-sales feedback and replay logs;

[0008] The risk weight w_s for each candidate scenario is calculated based on quality evidence, and w_s is calibrated using historical test results.

[0009] Under the total test duration constraint Σ_{s∈S*}t_s≤B, solve for the minimum scenario subset S* and its execution order π that maximizes coverage and risk-reward ratio, and reserve exploration quotas for new version changes and unknown risks to form an online sampling strategy;

[0010] Perform vehicle-in-the-loop / bench testing according to π and generate certification package;

[0011] When new defects or distribution drift are discovered, the defects are tagged as root causes, new scenarios are automatically generated or combined, and the scenario library and sampling strategy are updated to complete the self-evolution closed loop of the scenario library.

[0012] Optionally, under the total test duration constraint Σ_{s∈S*}t_s≤B, solve for the minimum subset of scenarios S* and its execution order π that maximizes coverage and risk-reward ratio, and reserve exploration quotas for new version changes and unknown risks to form an online sampling strategy, including:

[0013] Greedy heuristics based on marginal returns, integer programming in the form of 0-1 knapsack, or rolling optimization are used to update w_s and t_s in real time with the beat.

[0014] After obtaining S*, the execution order π is generated.

[0015] Optionally, generate the execution order π, including:

[0016] π is generated according to the rule of prioritizing risk weight and coverage gain.

[0017] Optionally, calculating the risk weight w_s for each candidate scenario based on quality evidence and calibrating w_s using historical test results also includes:

[0018] Based on the detected gains y_s from historical tests and the closed-loop labels of the real problems, the parameters of w_s are updated so that the correlation between w_s and y_s meets the preset threshold.

[0019] Optionally, reserve exploration quotas for new version changes and unknown risks to form online sampling strategies, including:

[0020] Without exceeding the beat B, select an exploration scenario with high uncertainty or novelty N from the candidate scenarios and insert it into π;

[0021] The reasons for insertion in the exploration scenario, the characteristics of version differences, and the coverage gain brought by the insertion will be recorded in the forensic package to support subsequent policy evaluation and parameter calibration.

[0022] Optionally, when new defects or distribution drift are discovered, the defects are root cause-labeled, new scenarios are automatically generated or combined, and the scenario library and sampling strategy are updated to complete the self-evolutionary closed loop of the scenario library, including:

[0023] When a new defect is discovered during testing or real-world operation, the closed-loop update module tags the defect as a root cause.

[0024] New scenarios are automatically generated or combined based on root cause tags;

[0025] The new scenario will be added to the candidate set S, and its recurrence rate and detection rate will be verified by subsequent regression.

[0026] If the detected benefit is high, its w_s is increased and it enters S*, thus forming a scene library that evolves on its own.

[0027] Optionally, root cause tagging may include at least one or more of the following: function point, trigger condition, sensor type, environmental features, map / road structure, and software version.

[0028] Optionally, the risk weight w_s is determined by severity S, occurrence O, and detectability D, and satisfies:

[0029] w_s = g(S,O,D,N,T),

[0030] Where N is the version change or novelty index, T is the trigger condition complexity index, and g is the weight function that maps the above index to [0,1].

[0031] According to a second aspect of the present invention, an intelligent driving assistance decommissioning detection device is provided, the intelligent driving assistance decommissioning detection device comprising:

[0032] The acquisition module is used to acquire the production line inspection cycle B, vehicle model version, and test target;

[0033] The building module is used to build a set of candidate scenarios that include functional points, triggering conditions and execution time, and to extract quality evidence from production line defects, road test events, after-sales feedback and replay logs.

[0034] The calculation module is used to calculate the risk weight w_s for each candidate scenario based on quality evidence, and to calibrate w_s using historical test results;

[0035] The solution module is used to solve for the minimum subset of scenarios S* and its execution order π that maximizes coverage and risk-reward under the total test duration constraint Σ_{s∈S*}t_s≤B, and to reserve exploration quotas for new version changes and unknown risks to form an online sampling strategy.

[0036] The execution module is used to perform vehicle-in-the-loop / bench testing on a π basis and generate a certification package;

[0037] The generation module is used to tag the root cause of defects when new defects or distribution drift are discovered, automatically generate or combine new scenarios and update the scenario library and sampling strategy to complete the self-evolution closed loop of the scenario library.

[0038] According to three aspects of the present invention, an electronic device is provided, the electronic device comprising:

[0039] Processor, communication interface, memory, and communication bus.

[0040] The processor, communication interface, and memory communicate with each other through a communication bus.

[0041] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the intelligent driving assistance offline detection method described above.

[0042] The above solution achieves the following beneficial technical effects:

[0043] Under the cycle time constraint of Σt_s≤B, the test resources are concentrated on "high-yield scenarios" through joint optimization of risk weight and coverage gain, thereby improving defect detection efficiency.

[0044] By controlling repeated regressions through coverage vectors and redundancy penalty terms, the coverage rate can be improved within the same tick.

[0045] By exploring quota mechanisms, online spot checks can be conducted on new versions and drift risks to reduce the missed detection of unknown defects.

[0046] Achieving a reproducible and traceable quality closed loop through evidence collection packages;

[0047] By using root cause tagging and automatic scenario generation, the scenario library can continuously evolve with problems and versions, maintaining long-term effectiveness. Attached Figure Description

[0048] Figure 1 This is a flowchart of an intelligent driving assistance offline detection method provided in one or more embodiments of the present invention;

[0049] Figure 2 This is a flowchart of the solution operation in the intelligent driving assistance offline detection method provided by one or more embodiments of the present invention;

[0050] Figure 3 This is a flowchart of the solution operation in the intelligent driving assistance offline detection method provided by one or more embodiments of the present invention;

[0051] Figure 4 This is a flowchart of an intelligent driving assistance offline detection method provided in one or more embodiments of the present invention;

[0052] Figure 5 This is a flowchart of the solution operation in the intelligent driving assistance offline detection method provided by one or more embodiments of the present invention;

[0053] Figure 6 This is a flowchart of the generation operation in the intelligent driving assistance offline detection method provided in one or more embodiments of the present invention;

[0054] Figure 7This is a structural diagram of an intelligent driving assistance off-line detection device provided in one or more embodiments of the present invention;

[0055] Figure 8 This is a structural diagram of an electronic device provided in one or more embodiments of the present invention. Detailed Implementation

[0056] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0057] Figure 1 This is a flowchart of an intelligent driving assistance offline detection method provided in one or more embodiments of the present invention. See also Figure 1 The method for detecting the decommissioning of intelligent driving assistance systems includes the following steps:

[0058] S11, obtain the production line inspection cycle B, vehicle model version, and test target.

[0059] S12 constructs a set of candidate scenarios that include function points, triggering conditions, and execution time, and extracts quality evidence from production line defects, road test events, after-sales feedback, and replay logs.

[0060] S13, calculate the risk weight w_s for each candidate scenario based on quality evidence, and calibrate w_s using historical test results.

[0061] S14, under the total test duration constraint Σ_{s∈S*}t_s≤B, solve for the minimum subset of scenarios S* and its execution order π that maximizes coverage and risk-reward ratio, and reserve exploration quotas for new version changes and unknown risks to form an online sampling strategy.

[0062] S15, perform vehicle-in-the-loop / bench testing according to π and generate certification package.

[0063] S16: When a new defect or distribution drift is discovered, the defect is root cause-labeled, new scenarios are automatically generated or combined, and the scenario library and sampling strategy are updated to complete the self-evolution closed loop of the scenario library.

[0064] As described above, existing offline testing methods generally suffer from incomplete scenario coverage and failure to maximize risk and benefit.

[0065] In response to the aforementioned problems in the existing offline testing process, this embodiment provides a solution that not only improves the comprehensiveness of scenario coverage but also enhances the risk-benefit ratio of the testing process.

[0066] At the outset of the implementation plan, it is necessary to obtain some essential conditions for the testing process. These conditions include: production line testing cycle time B, vehicle model version, and testing target.

[0067] After obtaining the necessary testing conditions mentioned above, a set of candidate scenarios is constructed based on these conditions. The factors to be considered in the set of candidate scenarios include: functional points, triggering conditions, and execution time.

[0068] It should be understood that each test scenario in the candidate scenario set corresponds to its own quality factors. These quality factors can be reflected in the production line defects, road test events, after-sales feedback, and playback logs corresponding to that scenario.

[0069] To more accurately control the quality factors of each scenario, quality evidence is extracted from production line defects, road test events, after-sales feedback, and playback logs for each candidate scenario in the candidate scenario set.

[0070] Next, based on the extracted quality evidence, the risk weight of each candidate scenario in the candidate scenario set is calculated.

[0071] To make the calculated risk weights more realistic and reliable, w_s needs to be further calibrated using historical test results.

[0072] Next, the optimization solution is performed. Specifically, the optimization solution module solves for the minimum scene subset S* under the total duration constraint Σ_{s∈S*}t_s≤B. The coverage term can be calculated based on the function point coverage set: Coverage(S*)=|⋃F_s| / |F_all|. To reduce repeated regressions, a redundancy penalty term Redundancy(S*) can be defined, for example, by accumulating the similarity of the coverage vectors. The objective function can be written as J(S*)=α·Coverage(S*)+β·Σw_s−γ·Redundancy(S*). The solver can adopt: a greedy heuristic based on marginal returns, integer programming in the form of 0-1 knapsack, or rolling optimization (updating w_s and t_s in real time with the beat). After obtaining S*, the execution order π is generated, prioritizing scenes with both high w_s and high coverage gain to ensure that the gain and coverage of any prefix sequence are not lower than the threshold.

[0073] The process of finding the minimum scene subset S* includes: under the total duration constraint, solving the problem using one of the following algorithms: a heuristic algorithm, an integer programming algorithm, or a rolling optimization algorithm, and introducing a redundancy penalty term Redundancy(S*) into the objective function to reduce duplicate coverage.

[0074] Furthermore, the execution order π needs to be calculated. Additionally, exploration quotas need to be reserved for new version changes and unknown risks to formulate an online sampling strategy.

[0075] The scenario selection strategy includes an online sampling strategy, which includes reserving an exploration quota E for version changes, new feature launches, or distribution drifts, inserting the exploration scenario into the execution order π under the condition that Σt_s≤B, and recording the reason for insertion and the scope of impact in the evidence collection package.

[0076] The next step is the test execution process. It's important to note that once an execution order π is selected, the execution process must strictly adhere to that selected order π.

[0077] Furthermore, when new defects or distribution drift are discovered, the defects are root cause-labeled, new scenarios are automatically generated or combined, and the scenario library and sampling strategy are updated to complete the self-evolution closed loop of the scenario library.

[0078] Figure 2 This is a flowchart of the solution operation in the intelligent driving assistance offline detection method provided in one or more embodiments of the present invention. See also Figure 2 Under the total test duration constraint Σ_{s∈S*}t_s≤B, solve for the minimum subset of scenarios S* and its execution order π that maximizes coverage and risk-reward ratio, and reserve exploration quotas for new version changes and unknown risks to form an online sampling strategy, including:

[0079] S21 uses a greedy heuristic based on marginal returns, integer programming in the form of 0-1 knapsack, or rolling optimization, updating w_s and t_s in real time with the beat.

[0080] S22, after obtaining S*, generates the execution order π.

[0081] Before solving for the minimum scenario subset S*, the risk weights for each candidate scenario have been calculated.

[0082] Candidate scenarios *s* include function point identifiers, triggering conditions (e.g., weather, lighting, traffic flow density, road structure combination), and execution time *t_s*. Risk weights can be constructed based on severity *S*, occurrence *O*, and detectability *D*, and further incorporate version change / novelty *N* and trigger complexity *T*. In one optional implementation, *S* describes the impact of defects on safety and compliance, *O* describes the frequency of defect exposure or the proportion of affected vehicles, and *D* describes the detectability probability in the test environment. The weighting function *g* can be in the form of weighted normalization or logistic regression, mapping (S, O, D, N, T) to [0, 1].

[0083] The solution for the minimum scene subset S* can be obtained using a greedy heuristic based on marginal returns, integer programming in the form of a 0-1 knapsack problem, or rolling optimization. Furthermore, the weights w_s and execution time t_s need to be updated in real-time to keep pace with the beat of the algorithm.

[0084] After the calculation of S* is completed, the execution order π is generated.

[0085] Figure 3 This is a flowchart of the solution operation in the intelligent driving assistance offline detection method provided in one or more embodiments of the present invention. See also Figure 3 Under the total test duration constraint Σ_{s∈S*}t_s≤B, solve for the minimum subset of scenarios S* and its execution order π that maximizes coverage and risk-reward ratio, and reserve exploration quotas for new version changes and unknown risks to form an online sampling strategy, including:

[0086] S31 uses a greedy heuristic based on marginal returns, integer programming in the form of 0-1 knapsack, or rolling optimization, updating w_s and t_s in real time with the beat.

[0087] S32 generates π according to the rule of prioritizing risk weight and coverage gain.

[0088] This embodiment is based on the foregoing embodiments of the present invention and further explains the specific process of the solution operation.

[0089] This embodiment focuses on the generation rules of the execution order π.

[0090] The execution order refers to which scenarios' tests are executed first, and which scenarios' rules are executed next during the testing process.

[0091] Among the different execution order options, the execution order should follow the principles of prioritizing risk weight and coverage gain.

[0092] For example, if one execution order has a higher risk weight than the others, then the execution order with the higher risk weight should be executed first.

[0093] For example, if one execution order has a greater coverage gain than the others, then the execution order with the greater coverage gain should be executed first.

[0094] Figure 4 This is a flowchart of an intelligent driving assistance offline detection method provided in one or more embodiments of the present invention. See also Figure 4 The method for detecting the decommissioning of intelligent driving assistance systems includes the following steps:

[0095] S41, obtain the production line inspection cycle B, vehicle model version, and test target.

[0096] S42 constructs a set of candidate scenarios that include function points, triggering conditions, and execution time, and extracts quality evidence from production line defects, road test events, after-sales feedback, and playback logs.

[0097] S43, based on the detected gains y_s from historical tests and the closed-loop labels of real problems, update the parameters of w_s so that the correlation between w_s and y_s meets the preset threshold.

[0098] S44, under the total test duration constraint Σ_{s∈S*}t_s≤B, solve for the minimum subset of scenarios S* and its execution order π that maximizes coverage and risk-reward ratio, and reserve exploration quotas for new version changes and unknown risks to form an online sampling strategy.

[0099] S45, perform vehicle-in-the-loop / bench testing by pressing π and generate a certification package.

[0100] S46. When a new defect or distribution drift is discovered, the defect is root cause-labeled, new scenarios are automatically generated or combined, and the scenario library and sampling strategy are updated to complete the self-evolution closed loop of the scenario library.

[0101] This embodiment is based on the foregoing embodiments of the present invention and further illustrates the calibration process of risk weights.

[0102] In this embodiment, the calculated risk weights are calibrated based on the detection gains from historical tests.

[0103] During calibration, it is necessary to maintain the correlation between risk weights and detection benefits within the relevant preset threshold requirements. More specifically, the correlation between puncture risk weights and detection benefits must not exceed a preset correlation threshold.

[0104] Figure 5 This is a flowchart of the solution operation in the intelligent driving assistance offline detection method provided in one or more embodiments of the present invention. See also Figure 5 To reserve exploration quotas for new version changes and unknown risks in order to formulate online sampling strategies, the following operational steps are included:

[0105] S51, without exceeding the beat B, select an exploration scenario with high uncertainty or novelty N from the candidate scenarios and insert it into π.

[0106] S52, the reasons for insertion in the exploration scenario, version difference characteristics, and coverage gain brought by the insertion will be recorded in the forensic package to support subsequent policy evaluation and parameter calibration.

[0107] The process of reserving exploration quotas first requires selecting some exploration scenarios from the candidate scenarios and inserting the selected exploration scenarios into the execution order.

[0108] There are two aspects to consider when selecting an exploration scenario: first, it must have high uncertainty; second, it must be novel. A scenario that meets either of these requirements can be selected as an exploration scenario.

[0109] Furthermore, the reasons for inserting the scene, the characteristics of version differences, and the coverage gain brought by the insertion will all be recorded in the evidence collection package.

[0110] Figure 6 This is a flowchart of the generation operation in the intelligent driving assistance offline detection method provided in one or more embodiments of the present invention. See also Figure 6 When new defects or distribution drift are discovered, the defects are tagged as root causes, new scenarios are automatically generated or combined, and the scenario library and sampling strategy are updated to complete the self-evolution closed loop of the scenario library. This includes the following steps:

[0111] S61, when a new defect is discovered during testing or actual operation, the closed-loop update module tags the defect as a root cause.

[0112] S62 automatically generates or combines new scenarios based on root cause tags.

[0113] S63, the new scene will be added to the candidate set S, and its recurrence rate and detection rate will be verified by subsequent regression.

[0114] S64, if the detected benefit is high, then its w_s is increased and it enters S*, thus forming a scene library self-evolution.

[0115] It should be understood that the scenario library should not be a database that remains unchanged after it is formed, but rather a database that evolves continuously as scenario testing needs to be met.

[0116] If new defects are discovered during actual operation, the root causes of these defects need to be addressed.

[0117] Then, new scenarios are generated or combined based on root cause labels. These new scenarios are then added to the candidate scenario set. After addition, regression validation is used to verify their recurrence rate and detection rate.

[0118] If a high return is detected, its risk weight is increased and it is added to the smallest subset of scenarios, thus completing the self-evolution of the scenario library.

[0119] Figure 7 This is a structural diagram of an intelligent driving assistance off-line detection device provided in one or more embodiments of the present invention. See also... Figure 7 The intelligent driving assistance off-line detection device includes:

[0120] The acquisition module 71 is used to acquire the production line inspection cycle B, vehicle model version, and test target.

[0121] Module 72 is used to build a set of candidate scenarios that include function points, triggering conditions and execution time, and to extract quality evidence from production line defects, road test events, after-sales feedback and playback logs.

[0122] The calculation module 73 is used to calculate the risk weight w_s of each candidate scenario based on quality evidence, and to calibrate w_s using historical test results.

[0123] The solver module 74 is used to solve for the minimum subset of scenarios S* that maximizes coverage and risk-reward ratio and its execution order π under the total test duration constraint Σ_{s∈S*}t_s≤B, and to reserve exploration quotas for new version changes and unknown risks to form an online sampling strategy.

[0124] Execution module 75 is used to perform vehicle-in-the-loop / bench testing on a π basis and generate a certification package.

[0125] The generation module 76 is used to tag the root cause of defects when new defects or distribution drift are discovered, automatically generate or combine new scenarios and update the scenario library and sampling strategy to complete the self-evolution closed loop of the scenario library.

[0126] It is worth noting that although only some basic functional modules are disclosed in the embodiments of this invention, it does not mean that the composition of this system is limited to the above-mentioned basic functional modules. On the contrary, what this embodiment intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. The fact that this embodiment only discloses a few basic functional modules should not be considered as the scope of protection of the claims of this invention being limited to the disclosed basic functional modules. At the same time, for the convenience of description, the above device is described separately according to its functions as various units and modules. Of course, in implementing this invention, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0127] like Figure 8 As shown, the present invention also provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the intelligent driving assistance offline detection method.

[0128] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. For example... Figure 8The structure shown in this embodiment of the invention includes an electronic device comprising one or more processors 810 and a memory 820; the processors 810 in this electronic device may be one or more. Figure 8 Taking a processor 810 as an example; the memory 820 is used to store one or more programs; the one or more programs are executed by the one or more processors 810, so that the one or more processors 810 implement the intelligent driving assistance offline detection method as described in any one of the embodiments of the present invention.

[0129] The electronic device may also include an input device 830 and an output device 840.

[0130] The processor 810, memory 820, input device 830, and output device 840 in this electronic device can be connected via a bus or other means. Figure 8 Taking the example of a connection between China and Israel via a bus.

[0131] The memory 820 in this electronic device serves as a computer-readable storage medium, capable of storing one or more programs. These programs can be software programs, computer-executable programs, or modules, such as the program instructions / modules corresponding to the intelligent driving assistance off-line detection method provided in this embodiment of the invention. The processor 810 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 820, thereby implementing the intelligent driving assistance off-line detection method described in the above method embodiment.

[0132] The memory 820 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 the electronic device. Furthermore, the memory 820 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 instances, the memory 820 may further include memory remotely located relative to the processor 810, which can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0133] Input device 830 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the electronic device. Output device 840 may include display devices such as a display screen.

[0134] The present invention also provides a computer-readable storage medium, comprising: storing a computer program executable by a vehicle, wherein when the computer program is run on the vehicle, the vehicle performs the steps of the intelligent driving assistance off-line detection method.

[0135] Specifically, the computer storage medium in this embodiment of the invention can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be—but is not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the 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.

[0136] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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 or all of the technical features; and these 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 the present invention.

Claims

1. A method for detecting the decommissioning of intelligent driving assistance systems, characterized in that, The intelligent driving assistance offline detection method includes: Obtain the production line inspection cycle number B, vehicle model version, and test target; Construct a candidate scenario set that includes function points, triggering conditions and execution time, and extract quality evidence from production line defects, road test events, after-sales feedback and replay logs; The risk weight w_s for each candidate scenario is calculated based on quality evidence, and w_s is calibrated using historical test results. Under the total test duration constraint Σ_{s∈S*}t_s≤B, solve for the minimum scenario subset S* and its execution order π that maximizes coverage and risk-reward ratio, and reserve exploration quotas for new version changes and unknown risks to form an online sampling strategy; Perform vehicle-in-the-loop / bench testing according to π and generate certification package; When new defects or distribution drift are discovered, the defects are tagged as root causes, new scenarios are automatically generated or combined, and the scenario library and sampling strategy are updated to complete the self-evolution closed loop of the scenario library.

2. The method according to claim 1, characterized in that, Under the total test duration constraint Σ_{s∈S*}t_s≤B, solve for the minimum subset of scenarios S* and its execution order π that maximizes coverage and risk-reward ratio, and reserve exploration quotas for new version changes and unknown risks to form an online sampling strategy, including: Greedy heuristics based on marginal returns, integer programming in the form of 0-1 knapsack, or rolling optimization are used to update w_s and t_s in real time with the beat. After obtaining S*, the execution order π is generated.

3. The method according to claim 2, characterized in that, The execution order π is generated, including: π is generated according to the rule of prioritizing risk weight and coverage gain.

4. The method according to claim 1, characterized in that, The risk weight w_s for each candidate scenario is calculated based on quality evidence, and w_s is calibrated using historical test results, including: Based on the detected gains y_s from historical tests and the closed-loop labels of the real problems, the parameters of w_s are updated so that the correlation between w_s and y_s meets the preset threshold.

5. The method according to claim 1, characterized in that, To reserve exploration quotas for new version changes and unknown risks in order to formulate online sampling strategies, including: Without exceeding the beat B, select an exploration scenario with high uncertainty or novelty N from the candidate scenarios and insert it into π; The reasons for insertion in the exploration scenario, the characteristics of version differences, and the coverage gain brought by the insertion will be recorded in the forensic package to support subsequent policy evaluation and parameter calibration.

6. The method according to claim 1, characterized in that, When new defects or distribution drift are discovered, the defects are root cause-labeled, new scenarios are automatically generated or combined, and the scenario library and sampling strategy are updated to complete the self-evolutionary closed loop of the scenario library, including: When a new defect is discovered during testing or real-world operation, the closed-loop update module tags the defect as a root cause. New scenarios are automatically generated or combined based on root cause tags; The new scenario will be added to the candidate set S, and its recurrence rate and detection rate will be verified by subsequent regression. If the detected benefit is high, its w_s is increased and it enters S*, thus forming a scene library that evolves on its own.

7. The method according to claim 6, characterized in that, Root cause labeling includes at least one or more of the following: function point, trigger condition, sensor type, environmental features, map / road structure, and software version.

8. The method according to claim 1, characterized in that, The risk weight w_s is determined by severity S, occurrence O, and detectability D, and satisfies: w_s = g(S,O,D,N,T), Where N is the version change or novelty index, T is the trigger condition complexity index, and g is the weight function that maps the above index to [0,1].

9. A smart driving assistance off-line detection device, characterized in that, The intelligent driving assistance off-line detection device includes: The acquisition module is used to acquire the production line inspection cycle B, vehicle model version, and test target; The building module is used to build a set of candidate scenarios that include functional points, triggering conditions and execution time, and to extract quality evidence from production line defects, road test events, after-sales feedback and replay logs. The calculation module is used to calculate the risk weight w_s for each candidate scenario based on quality evidence, and to calibrate w_s using historical test results; The solution module is used to solve for the minimum subset of scenarios S* and its execution order π that maximizes coverage and risk-reward under the total test duration constraint Σ_{s∈S*}t_s≤B, and to reserve exploration quotas for new version changes and unknown risks to form an online sampling strategy. The execution module is used to perform vehicle-in-the-loop / bench testing on a π basis and generate a certification package; The generation module is used to tag the root cause of defects when new defects or distribution drift are discovered, automatically generate or combine new scenarios and update the scenario library and sampling strategy to complete the self-evolution closed loop of the scenario library.

10. An electronic device, characterized in that, The electronic device includes: Processor, communication interface, memory, and communication bus. The processor, communication interface, and memory communicate with each other through a communication bus. The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the intelligent driving assistance offline detection method according to any one of claims 1 to 8.

Images