An automatic driving high-value simulation scenario screening method

Abstract

This invention relates to the field of scene selection technology, specifically a method for selecting high-value simulation scenes for autonomous driving. First, the description text of each test scene is acquired. This text is then input into a pre-trained scene parsing model to obtain the structured natural language descriptions of the test scenes output by the model. A first round of screening is performed on these structured natural language descriptions using functional specification rules. Next, the structured natural language descriptions of each test scene are clustered, and the clustering results are determined. Based on the positional relationship of each test scene's structured natural language description within the clustering results, the scenes to be tested are selected. Autonomous driving test tasks are then executed on simulation software. Based on the test results, high-value simulation scenes for autonomous driving are determined. This multi-stage screening mechanism enables accurate selection of high-value simulation scenes for autonomous driving.

Description

Technical Field

[0001] This specification relates to the field of scene selection technology, and in particular to a method for selecting high-value simulation scenes for autonomous driving. Background Technology

[0002] In the rapid iteration and commercialization of autonomous driving technology, systematic simulation testing is a core means of verifying its safety, reliability, and performance. Simulation testing based on massive scenarios has become a necessary step in exposing system defects and assessing system safety boundaries in a virtual environment. Currently, the construction of large-scale scenario sets mainly relies on real-world data-driven approaches or generative techniques such as large language models to generate a vast number of candidate test scenarios.

[0003] However, when testing based on these massive candidate scenarios, many low-value or even meaningless scenarios consume valuable computing resources, leading to high testing costs and low verification efficiency. Therefore, effectively filtering out high-value test scenarios from this vast set of scenarios is crucial to improving testing efficiency.

[0004] Current scenario selection methods largely rely on human experience or single static threshold rules, making it difficult to flexibly adapt to diverse testing needs. Furthermore, these methods often create a dilemma: if the rules are set too loosely, a large number of invalid or low-relevance scenarios will be introduced, diluting the overall testing value; if the rules are set too strictly, critical scenarios that are right on the edge of the specification and have high testing value may be missed.

[0005] Therefore, this specification provides a method for screening high-value simulation scenarios for autonomous driving. Summary of the Invention

[0006] This specification provides a method for screening high-value simulation scenarios for autonomous driving, in order to partially solve the aforementioned problems existing in the prior art.

[0007] The following technical solution is adopted in this specification: This manual provides a method for screening high-value simulation scenarios for autonomous driving, including: S1. Obtain the description text of each test scenario used to generate the test scenarios; S2. Input the description text of each test scenario into the pre-trained scenario parsing model to obtain the structured natural language description of each test scenario output by the scenario parsing model, and determine the first scenario dataset based on the structured natural language description of each test scenario; S3. Using preset functional specification rules, perform a first round of screening on the structured natural language descriptions of each test scenario in the first scenario dataset, and determine the second scenario dataset based on the structured natural language descriptions of each test scenario that have passed the first round of screening; S4. Cluster the structured natural language descriptions of each test scenario in the second scenario dataset and determine the clustering results; S5. Based on the clustering results, select the structured natural language description of the test scenario as the description of the test scenario according to the positional relationship of the structured natural language description of each test scenario in the clustering results; S6. On the preset simulation software, set up the test scenario corresponding to the description of the test scenario and execute the autonomous driving test task to determine the test result of the test scenario; S7. Based on the test results of the scenario to be tested, determine the high-value simulation scenario for autonomous driving.

[0008] Based on the aforementioned technical methods, this solution significantly reduces the number of scenarios requiring simulation through a two-stage automated screening process (rule-based + clustering), focusing on truly challenging or safety-critical scenarios. By combining clustering with representative selection, it ensures that the final test set covers different types of high-value scenarios, improving test coverage and cost-effectiveness. Finally, the actual simulation results are used to verify the value of each scenario, avoiding misjudgments caused by relying solely on prior rules, and linking the definition of "high value" to the actual performance of the system.

[0009] Furthermore, in S3, the structured natural language descriptions of each test scenario in the first scenario dataset are first-round filtered according to preset functional specification rules, specifically including: For each test scenario structured natural language description in the first scenario dataset, determine the confidence level, continuous variables, and categorical variables of the test scenario structured natural language description; For each continuous variable, the boundary distance of the continuous variable is determined according to the preset variable range of the continuous variable, and the boundary distance of the continuous variable is normalized. The continuity coefficients of the continuous variable are determined based on the boundary distance after normalization and the confidence level. Based on the continuous coefficient of the continuous variable and the preset variable range of the continuous variable, determine the variable selection range corresponding to the continuous variable; Based on the variable selection intervals corresponding to each continuous variable in the structured natural language description of the test scenario, the first round of selection is carried out for the structured natural language description of the test scenario.

[0010] Furthermore, S3 also includes step S31: If all continuous variables in the structured natural language description of the test scenario are within their respective variable selection intervals, the structured natural language description of the test scenario is determined to have passed the first round of selection.

[0011] Furthermore, S4 specifically includes: For each pair of test scenarios in the structured natural language description, calculate the distance between continuous variables with the same name and the distance between categorical variables with the same name for continuous variables and categorical variables in the structured natural language description. The scene distance between each pair of test scene structured natural language descriptions is determined based on the distances between each continuous variable and each category variable between each pair of test scene structured natural language descriptions. Based on the distance between each scene, a density hierarchical clustering method is used to cluster the structured natural language descriptions of each test scene in the second scene dataset, and the clustering results are determined.

[0012] Furthermore, based on the distances between continuous variables and categorical variables between each pair of structured natural language descriptions of test scenarios, the scenario distance between each pair of structured natural language descriptions of test scenarios is determined, specifically including: For each test scenario, a structured natural language description is used to determine the boundary risk factor for each variable, where each variable includes continuous variables and categorical variables; and based on the boundary risk factor for each variable, the variable weight corresponding to each variable is determined. For each pair of test scenarios, a structured natural language description is generated, and based on the variable weights corresponding to each variable, the symmetric weights between variables with the same name are calculated. The scene distance between each pair of test scene structured natural language descriptions is determined based on the distances of each continuous variable, each category variable, and each symmetric weight between each pair of test scene structured natural language descriptions.

[0013] Furthermore, S5 specifically includes: For each clustering result, a structured natural language description of the test scenario located in a preset area at the center of the clustering result is selected as the test scenario description representing a typical scenario.

[0014] Furthermore, S5 specifically includes: For each clustering result, a structured natural language description of the test scene located in a preset region at the edge of the clustering result is selected as the test scene description representing the boundary scene.

[0015] Furthermore, S5 specifically includes: Based on the clustering results, the structured natural language descriptions of the test scenarios that are not clustered by the clustering results are selected as the test scenario descriptions representing extreme scenarios.

[0016] Furthermore, S6 specifically includes: The description of the scenario to be tested is converted into a data format that can be input into a preset simulation software; In the simulation software, the simulated test scenario is described in the converted format and the autonomous driving test task is executed. The test results of the autonomous driving test task are determined, and the test results include at least scenario test failure and scenario test success.

[0017] Furthermore, the high-value simulation scenarios for autonomous driving in S7 include failure scenarios, low-performance scenarios, and critical scenarios; the failure scenario is the test scenario in which the test result is a scenario test failure; the low-performance scenario is the test scenario in which the test result is a scenario test success, and the occupant comfort index or safety index is lower than the preset standard; the critical scenario is the test scenario in which the test result is a scenario test success, and the occupant comfort index or safety index is within the preset range.

[0018] The above-mentioned technical solutions adopted in this specification can achieve the following beneficial effects: This solution employs a two-stage automated screening process (rule-based + clustering) to significantly reduce the number of scenarios requiring simulation, focusing on truly challenging or safety-critical scenarios. Through clustering and representative selection, it ensures the final test set covers different types of high-value scenarios, improving test coverage and cost-effectiveness. Finally, the actual simulation results are used to verify the scenario value, avoiding misjudgments caused by relying solely on prior rules, and linking the definition of "high value" to the actual system performance. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings: Figure 1 A flowchart illustrating a method for screening high-value simulation scenarios for autonomous driving, provided as an embodiment of this specification. Figure 2 This specification provides a corresponding Figure 1 A schematic diagram of the structure of an electronic device. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort are within the scope of protection of this application.

[0021] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0022] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0023] Figure 1 A flowchart illustrating a method for screening high-value simulation scenarios for autonomous driving, provided in this specification, includes the following steps: S1: Obtain the description text of each test scenario used to generate the test scenarios.

[0024] In this specification, the process of selecting high-value simulation scenarios for autonomous driving is described. In the embodiments described herein, this process can be executed by a server. However, this specification does not limit the type of device or platform used to perform this selection process; for example, a personal computer, mobile terminal, or other similar devices or platforms can also be used. For ease of description, the following explanation uses a server as the executing entity.

[0025] In one or more embodiments of this specification, the server can obtain various test scenario description texts for generating test scenarios. Each test scenario description text can represent a test scenario. By inputting the test scenario description text into a model specifically designed for generating test scenarios, the model can generate the test scenario represented by the test scenario description text. Therefore, similarly, it is currently possible to generate a large number of test scenarios in batches using scenario generation techniques such as large language models, and each test scenario has a corresponding test scenario description text.

[0026] S2: Input the description text of each test scenario into the pre-trained scenario parsing model to obtain the structured natural language description of each test scenario output by the scenario parsing model, and determine the first scenario dataset based on the structured natural language description of each test scenario.

[0027] In one or more embodiments of this specification, the server inputs the description text of each test scenario into a pre-trained scene parsing model to obtain the structured natural language description of each test scenario output by the scene parsing model. Furthermore, based on the structured natural language descriptions of each test scenario, a first scene dataset containing the structured natural language descriptions of each test scenario can be determined.

[0028] The structured natural language description for each test scenario in the first scenario dataset includes seven layers: road layer, traffic facility layer, temporary traffic time layer, traffic participant layer, environmental condition layer, vehicle state layer, and information layer.

[0029] The test scenario description text is divided into several layers: The Road Layer represents the road type and physical structure, such as highways, road materials (asphalt, tarpaulin), gradient, and number of lanes. The Traffic Facilities Layer represents road traffic facilities, such as streetlights and speed bumps. The Temporary Traffic Time Layer represents temporary traffic conditions, such as construction zones and traffic accidents. The Traffic Participant Layer represents traffic participants, such as cars, pedestrians, trucks, and motorcycles. The Environmental Conditions Layer represents the natural environment, such as lighting conditions, weather conditions, and visibility. The Vehicle Status Layer represents vehicle data, such as vehicle speed and acceleration. The Information Layer represents interactions between the autonomous vehicle and other traffic participants, such as overtaking events between autonomous vehicles and trucks.

[0030] It is worth noting that the scene parsing model can be a generative pre-trained transform model (GPT) such as the GPT-4 model, the Claude model, or other large language models. By pre-setting prompt words to extract seven layers of structured natural language description, the model can divide the test scene description text into seven layers of structure based on the prompt words, thus obtaining a structured natural language description of the test scene.

[0031] Of course, the scene parsing model can also be a specially trained model for determining the seven-layer structured natural language description. The training method for this model can be as follows: Use historical test scene description text as training samples, and use the seven-layer structured natural language descriptions of those texts as annotations. Input the training samples into the scene parsing model to be trained, and obtain the test scene structured natural language descriptions output by the model. Based on the difference between the test scene structured natural language descriptions output by the model and the annotations, determine the loss value. Use minimizing the loss value as the optimization objective to train the scene parsing model.

[0032] S3: Using preset functional specification rules, perform a first round of screening on the structured natural language descriptions of each test scenario in the first scenario dataset, and determine the second scenario dataset based on the structured natural language descriptions of each test scenario that have passed the first round of screening.

[0033] In one or more embodiments of this specification, the server can perform a first round of screening on the structured natural language descriptions of each test scenario in the first scenario dataset using preset functional specification rules. The core objective of this first round of screening is to perform compliance checks on the scenario parameters (i.e., the structured natural language descriptions of the seven layers mentioned above) in the structured natural language descriptions of the test scenarios. Based on the structured natural language descriptions of each test scenario that have passed the first round of screening, a second scenario dataset is determined, which includes the structured natural language descriptions of each test scenario that have passed the first round of screening.

[0034] The preset functional specification rules include rules governing the speed limits, number of lanes, weather conditions, and visibility range of autonomous vehicles in the test scenario. The constraints of these rules cover the seven layers of structured natural language descriptions (SNRs) for the test scenario. Of course, different autonomous driving test tasks have different testing requirements. The functional specification rules for the seven layers of SNRs can be set according to the specific autonomous driving test task, and are not limited in this specification. During the first round of screening of the SNRs for each test scenario in the first scenario dataset, those that meet the functional specification rules can be included in the second scenario dataset.

[0035] Furthermore, in this specification, the first round of screening for the seven-layer structured natural language description can also involve the server determining the confidence level, continuous variables, and categorical variables of each test scenario structured natural language description in the first scenario dataset. The confidence level is the confidence C of the model that generated the test scenario structured natural language description for that test scenario. Continuous variables are those with continuous features in the structured natural language description of the test scenario, such as vehicle speed, distance, acceleration, number of lanes, and road curvature. Categorical variables are those that are not continuous in the structured natural language description of the test scenario, such as weather conditions and lighting conditions. In this case, the number and names of variables in the structured natural language description of each test scenario in the first scenario dataset are the same; the only difference is that the specific content of at least some variables differs between the structured natural language descriptions of different test scenarios and those of other test scenarios.

[0036] Then, the server can determine the boundary distance for each continuous variable based on its preset variable range, and normalize the boundary distance. The formulas for determining and normalizing the boundary distance are as follows:

[0037]

[0038] In the formula, and The preset variable interval of the k-th continuous variable in the i-th test scenario's structured natural language representation. The lower and upper limits, Let represent the value of the k-th continuous variable in the structured natural language representation of the i-th test scenario. Let be the boundary distance of the k-th continuous variable. This is the normalized boundary distance for the k-th continuous variable.

[0039] For example, the structured natural language description of the test scenario to which this continuous variable belongs has a total of p variables, of which the first n are continuous variables and the last m are categorical variables, n+m=p. Then, for the n continuous variables, taking the k-th continuous variable as an example, k∈[1,n], this k-th continuous variable is assumed to be vehicle speed, with a value of 80 km / h, and its preset variable interval is [40,120]. This is equivalent to setting the minimum vehicle speed as 40km / h and the maximum vehicle speed as 120km / h in the preset variable interval. Then, based on this preset variable interval, its boundary distance can be determined to be 40, and after normalization, the boundary distance is 0.5.

[0040] After calculating the normalized boundary distance, the server can determine the continuity coefficient of the continuous variable based on the normalized boundary distance and confidence level. Based on the continuity coefficient and the preset variable interval of the continuous variable, the server determines the corresponding variable filtering interval. Finally, based on the variable filtering intervals corresponding to each continuous variable in the structured natural language description of the test scenario, the server can perform the first round of filtering for the structured natural language description of the test scenario.

[0041] The formula for determining the continuity coefficient is:

[0042] In the formula, Let C be the continuous coefficient of the k-th continuous variable in the structured natural language representation of the i-th test scenario, and let C be the confidence score of the scenario that generates the structured natural language representation of the i-th test scenario. The variable selection interval of the k-th continuous variable can be used as... It is worth noting that, for categorical variables, the reference continuous variable has continuous coefficients. Then the categorical variable has a categorical coefficient. The category coefficient is preset to 1.

[0043] In this specification, a test scenario's structured natural language description is considered to have passed the first round of screening if all continuous variables fall within their respective variable selection intervals. This means that the value of the first continuous variable in the description falls within its corresponding variable selection interval, the value of the second continuous variable falls within its corresponding variable selection interval, and so on, until all continuous variables are within their respective selection intervals. Conversely, if even one continuous variable is outside its selection interval, the description fails the first round of screening.

[0044] S4: Cluster the structured natural language descriptions of each test scenario in the second scenario dataset and determine the clustering results.

[0045] In one or more embodiments of this specification, the server can cluster the structured natural language descriptions of each test scenario in the second scenario dataset and determine the clustering results.

[0046] Specifically, the server can calculate the continuous variable distance between continuous variables with the same name and the categorical variable distance between categorical variables with the same name in the structured natural language descriptions of each pair of test scenarios. Then, based on these distances, the server determines the scene distance between each pair of test scenario structured natural language descriptions. Finally, based on these scene distances, a density-based hierarchical clustering method is used to cluster the structured natural language descriptions of each test scenario in the second scenario dataset, determining the clustering results.

[0047] The expressions for determining the distance between continuous variables, categorical variables, and scene distance are as follows:

[0048]

[0049]

[0050]

[0051] In the formula, let the i-th test scenario be the structured natural language representation of the scenario. The variable has p variables, of which the first n are continuous variables and the last m are categorical variables, and n+m=p. The set of variables is represented as each This represents the structured natural language representation of the i-th test scenario. Which variable is it? The i-th test scenario is a structured natural language representation of the scenario. The value of the k-th continuous variable after normalization. and The preset variable intervals for the k-th continuous variable in the i-th test scenario's structured natural language representation are respectively. Similarly, the lower and upper limits, The j-th test scenario is a structured natural language representation of the scenario. The value of the k-th continuous variable after normalization.

[0052] when When the variable is continuous, Representing a scene and scene The distance on the k-th continuous variable is called the continuous variable distance, which ranges from [0, 1].

[0053] when When it is a categorical variable, Representing a scene and scene The distance on the k-th categorical variable is the categorical distance; the distance is 0 if the categories are the same, and 1 if the categories are different.

[0054] Representing a scene and scene The scene distance between them is the Gower distance used in this specification, with a value range of [0, 1]. Let be the weight of the k-th variable. Of course, the weight of the k-th variable can be a preset weight or a weight determined based on the weight adjustment mechanism described below.

[0055] Furthermore, regarding the method for determining the scene distance and the weight of the k-th variable, specifically, the server determines the boundary risk factor for each variable in each test scene's structured natural language description, where each variable includes both continuous and categorical variables. Based on the boundary risk factor of each variable, the server determines the corresponding variable weight for each variable. Then, for every two test scene structured natural language descriptions, the server calculates the symmetric weight between variables with the same name based on the variable weights corresponding to each variable. Finally, the server determines the scene distance between every two test scene structured natural language descriptions based on the distances between each continuous variable, the distances between each categorical variable, and the symmetric weights.

[0056] Among them, for the i-th test scenario, the structured natural language representation scenario For the k-th variable, when the k-th variable is a continuous variable, its boundary risk factor is... The calculation expression is:

[0057] In the formula, These are preset risk parameters. .

[0058] When the k-th variable is a categorical variable, the pre-defined boundary risk factor for the k-th variable can be directly determined. , .

[0059] The expression for calculating the variable weight for each variable is:

[0060]

[0061] In the formula, The i-th test scenario is a structured natural language representation of the scenario. The variable weight corresponding to the k-th variable in the equation. The preset base weights are assigned to the k-th variable. When the k-th variable is a continuous variable, This is the continuous coefficient of the k-th variable. When the k-th variable is a categorical variable, Let be the category coefficient of the k-th variable.

[0062] The expression for calculating symmetric weights is:

[0063] In the formula, The i-th test scenario is a structured natural language representation of the scenario. The variable weight corresponding to the k-th variable in the equation. The j-th test scenario is a structured natural language representation of the scenario. The variable weight corresponding to the k-th variable. for and Symmetric weights between variables with the same name.

[0064] The expression for calculating scene distance can then be adjusted as follows:

[0065] Then, based on the distance between each scene, density-based clustering algorithms such as Hierarchical Density-Based Spatial Clustering of Applications with Noise (HDBSCAN) can be used to perform clustering.

[0066] S5: Based on the clustering results, select the structured natural language description of each test scenario as the test scenario description according to the positional relationship of the structured natural language description of each test scenario in the clustering results.

[0067] In one or more embodiments of this specification, the server may select the structured natural language description of the test scenario as the description of the test scenario based on the clustering results and the positional relationship of the structured natural language description of each test scenario in the clustering results.

[0068] Specifically, for each clustering result, a structured natural language description of the test scenario located in a preset area at the center of the clustering result is selected as the test scenario description representing a typical scenario.

[0069] Furthermore, for each clustering result, a structured natural language description of the test scene located in a preset region at the edge of the clustering result is selected as the test scene description representing the boundary scene.

[0070] Of course, based on the clustering results, structured natural language descriptions of test scenarios that are not clustered by the clustering results can be selected as test scenario descriptions representing extreme scenarios.

[0071] S6: On the preset simulation software, set up the test scenario corresponding to the description of the test scenario and execute the autonomous driving test task to determine the test result of the test scenario.

[0072] In one or more embodiments of this specification, the server can set up the test scenario corresponding to the description of the test scenario on the preset simulation software and execute the autonomous driving test task to determine the test result of the test scenario.

[0073] Specifically, the server can convert the description of the scenario to be tested into a data format that can be input into preset simulation software. Then, in the simulation software, the converted scenario description is used to simulate the actual test scenario, and the autonomous driving test task is executed. Finally, the test results of the autonomous driving test task are determined, including at least two categories: scenario test failure and scenario test success.

[0074] S7: Based on the test results of the scenario to be tested, determine the high-value simulation scenario for autonomous driving.

[0075] In one or more embodiments of this specification, the server can determine high-value simulation scenarios for autonomous driving based on the test results of the scenario to be tested. High-value simulation scenarios for autonomous driving include failure scenarios, which are the scenarios to be tested that have failed the test.

[0076] Of course, simulation software can also determine occupant comfort and safety indicators for autonomous driving test tasks as test results. Therefore, high-value simulation scenarios for autonomous driving also include low-performance scenarios and critical scenarios. A low-performance scenario is a test scenario where the test result is successful and both occupant comfort and safety indicators are below preset standards. A critical scenario is a test scenario where the test result is successful and both occupant comfort and safety indicators are within preset ranges.

[0077] For example, the occupant comfort indicators included in the test results may include the acceleration, braking frequency, and overall occupant comfort index values ​​determined according to the automotive comfort evaluation standard ISO 2631-1-1997 for autonomous vehicles. Safety indicators may include TTC (Total Traffic Conversion) and minimum distance (the closest distance between the vehicle and other vehicles / obstacles). When the scenario test is successful, and both the occupant comfort and safety indicators are lower than the preset standards, it is identified as a low-performance scenario.

[0078] This specification also provides a computer-readable storage medium storing a computer program that can be used to execute the above-described... Figure 1 This paper presents a method for screening high-value simulation scenarios for autonomous driving.

[0079] This instruction manual also provides Figure 2 The diagram shows a schematic structural representation of the electronic device. Figure 2 As shown, at the hardware level, this electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to achieve the above. Figure 1 This paper presents a method for screening high-value simulation scenarios for autonomous driving.

[0080] Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0081] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0082] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0083] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0084] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0085] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0086] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0087] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0088] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0089] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0090] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0091] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic or disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0092] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0093] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0094] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0095] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0096] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for screening high-value simulation scenarios for autonomous driving, characterized in that, include: S1. Obtain the description text of each test scenario used to generate the test scenarios; S2. Input the description text of each test scenario into the pre-trained scenario parsing model to obtain the structured natural language description of each test scenario output by the scenario parsing model, and determine the first scenario dataset based on the structured natural language description of each test scenario; S3. Using preset functional specification rules, perform a first round of screening on the structured natural language descriptions of each test scenario in the first scenario dataset, and determine the second scenario dataset based on the structured natural language descriptions of each test scenario that have passed the first round of screening; S4. Cluster the structured natural language descriptions of each test scenario in the second scenario dataset and determine the clustering results; S5. Based on the clustering results, select the structured natural language description of the test scenario as the description of the test scenario according to the positional relationship of the structured natural language description of each test scenario in the clustering results; S6. On the preset simulation software, set up the test scenario corresponding to the description of the test scenario and execute the autonomous driving test task to determine the test result of the test scenario; S7. Based on the test results of the scenario to be tested, determine the high-value simulation scenario for autonomous driving.

2. The method for screening high-value simulation scenarios for autonomous driving as described in claim 1, characterized in that, In S3, the structured natural language descriptions of each test scenario in the first scenario dataset are first-round filtered according to preset functional specification rules, specifically including: For each test scenario structured natural language description in the first scenario dataset, determine the confidence level, continuous variables, and categorical variables of the test scenario structured natural language description; For each continuous variable, the boundary distance of the continuous variable is determined according to the preset variable range of the continuous variable, and the boundary distance of the continuous variable is normalized. The continuity coefficients of the continuous variable are determined based on the boundary distance after normalization and the confidence level. Based on the continuous coefficient of the continuous variable and the preset variable range of the continuous variable, determine the variable selection range corresponding to the continuous variable; Based on the variable selection intervals corresponding to each continuous variable in the structured natural language description of the test scenario, the first round of selection is carried out for the structured natural language description of the test scenario.

3. The method for screening high-value simulation scenarios for autonomous driving as described in claim 2, characterized in that, S3 also includes step S31: If all continuous variables in the structured natural language description of the test scenario are within their respective variable selection intervals, the structured natural language description of the test scenario is determined to have passed the first round of selection.

4. A method for screening high-value simulation scenarios for autonomous driving as described in claim 2 or 3, characterized in that, S4 specifically includes: For each pair of test scenarios in the structured natural language description, calculate the distance between continuous variables with the same name and the distance between categorical variables with the same name for continuous variables and categorical variables in the structured natural language description. The scene distance between each pair of test scene structured natural language descriptions is determined based on the distances between each continuous variable and each category variable between each pair of test scene structured natural language descriptions. Based on the distance between each scene, a density hierarchical clustering method is used to cluster the structured natural language descriptions of each test scene in the second scene dataset, and the clustering results are determined.

5. The method for screening high-value simulation scenarios for autonomous driving as described in claim 4, characterized in that, The scene distance between each pair of test scene structured natural language descriptions is determined based on the distances between continuous variables and the distances between categorical variables between each pair of test scene structured natural language descriptions. Specifically, this includes: For each test scenario, a structured natural language description is used to determine the boundary risk factor for each variable, where each variable includes continuous variables and categorical variables; and based on the boundary risk factor for each variable, the variable weight corresponding to each variable is determined. For each pair of test scenarios, a structured natural language description is generated, and based on the variable weights corresponding to each variable, the symmetric weights between variables with the same name are calculated. The scene distance between each pair of test scene structured natural language descriptions is determined based on the distances of each continuous variable, each category variable, and each symmetric weight between each pair of test scene structured natural language descriptions.

6. The method for screening high-value simulation scenarios for autonomous driving as described in claim 1, characterized in that, S5 specifically includes: For each clustering result, a structured natural language description of the test scenario located in a preset area at the center of the clustering result is selected as the test scenario description representing a typical scenario.

7. The method for screening high-value simulation scenarios for autonomous driving as described in claim 1, characterized in that, S5 specifically includes: For each clustering result, a structured natural language description of the test scene located in a preset region at the edge of the clustering result is selected as the test scene description representing the boundary scene.

8. The method for screening high-value simulation scenarios for autonomous driving as described in claim 1, characterized in that, S5 specifically includes: Based on the clustering results, the structured natural language descriptions of the test scenarios that are not clustered by the clustering results are selected as the test scenario descriptions representing extreme scenarios.

9. The method for screening high-value simulation scenarios for autonomous driving as described in claim 1, characterized in that, S6 specifically includes: The description of the scenario to be tested is converted into a data format that can be input into a preset simulation software; In the simulation software, the simulated test scenario is described in the converted format and the autonomous driving test task is executed. The test results of the autonomous driving test task are determined, and the test results include at least scenario test failure and scenario test success.

10. The method for screening high-value simulation scenarios for autonomous driving as described in claim 9, characterized in that, In S7, high-value simulation scenarios for autonomous driving include failure scenarios, low-performance scenarios, and critical scenarios. The failure scenario is the test scenario in which the test result is a failure. The low-performance scenario is the test scenario in which the test result is a success and the occupant comfort index or safety index is lower than the preset standard. The critical scenario is the test scenario in which the test result is a success and the occupant comfort index or safety index is within the preset range.

Images