Automatic driving test scene generation method and device based on text collision report, equipment and medium

Abstract

The invention discloses an automatic driving test scene generation method and device based on a text collision report, equipment and a medium, and relates to the technical field of automatic driving, and the method comprises the steps: obtaining an unstructured text collision report, converting the unstructured text collision report into a high-dimensional numerical vector through preprocessing and feature extraction, and obtaining a high-dimensional numerical vector; a typical collision mode is identified and classified by using an unsupervised clustering algorithm, a logic scene is further constructed in a parameterized manner, physical feasibility is verified through a kinematics verification module, risk levels are divided, and a risk scene library is formed. And finally, generating an automatic driving test case set by adopting a stratified sampling strategy. By using the collision text data, real, diversified and physically feasible test scenes are generated, and the efficiency and accuracy of automatic driving safety assessment are improved.

Description

Technical Field

[0001] This invention relates to the field of autonomous driving technology, and in particular to a method, apparatus, device, and medium for generating autonomous driving test scenarios based on text collision reports. Background Technology

[0002] Currently, autonomous driving test scenario generation technologies primarily rely on structured sensor data (such as LiDAR, cameras, V2X communication, etc.) or manually defined rule templates. Some research attempts to introduce Natural Language Processing (NLP) techniques to extract key variables from textual accident reports to assist in scenario construction. For example, static information such as vehicle type, collision location, and weather conditions is extracted using keyword matching or Named Entity Recognition (NER) methods, and test cases are generated by combining this with pre-defined logic. However, this approach often relies on manual annotation or coarse-grained keyword extraction, lacking in-depth semantic mining of the text, resulting in low information utilization and difficulty in achieving large-scale, automated scenario generation. Furthermore, it ignores the contextual logic and causal relationships inherent in the text, limiting the diversity and realism of the generated scenarios.

[0003] Furthermore, some methods employ clustering or classification algorithms to perform pattern recognition on accident data, attempting to categorize typical collision scenarios. Regarding scenario modeling, most studies follow international standards such as ISO 34502, dividing scenarios into three levels: abstract scenarios, logical scenarios, and concrete scenarios. Logical scenarios, in a parametric form, describe the state and behavioral relationships of traffic participants, serving as input for subsequent simulations. However, this method lacks a risk quantification mechanism for generated scenarios, failing to distinguish between high-risk edge scenarios and low-risk routine scenarios. This leads to unreasonable allocation of testing resources and makes it difficult to achieve a focused and risk-controlled safety assessment. Therefore, there is an urgent need for a method to generate autonomous driving test scenarios to simulate autonomous driving scenarios and improve the safety and reliability of autonomous driving systems. Summary of the Invention

[0004] The main purpose of this application is to provide a method, apparatus, device and medium for generating autonomous driving test scenarios based on text collision reports, aiming to solve the technical problem of how to realize the simulation of autonomous driving scenarios to improve the safety and reliability of autonomous driving systems.

[0005] To achieve the above objectives, this application proposes a method for generating autonomous driving test scenarios based on text collision reports, including:

[0006] Get unstructured text collision reports;

[0007] The unstructured text collision report is preprocessed and its features are extracted to obtain a high-dimensional numerical feature vector;

[0008] Based on the high-dimensional numerical feature vectors, an unsupervised clustering algorithm is used to identify typical collision patterns and obtain an abstract scene classification.

[0009] The abstract scene classification is parameterized to construct standardized logical scenes;

[0010] The kinematics verification module is used to perform physical feasibility checks on the logical scenarios and classify risk levels to obtain a risk scenario library.

[0011] A stratified sampling strategy is used to extract samples from the risk scenario library to generate an autonomous driving test case set.

[0012] In one embodiment, the step of preprocessing and extracting features from the unstructured text collision report to obtain a high-dimensional numerical feature vector includes:

[0013] The unstructured text collision reports are filtered to retain reports related to autonomous driving functions, resulting in multiple valid sub-reports, wherein the valid sub-reports are reports in English text;

[0014] All English text in the effective sub-report is preprocessed to obtain the processed effective sub-report. The preprocessing includes converting all English text to lowercase and removing punctuation marks, non-informative characters, general stop words, and non-key information words specific to the autonomous driving field.

[0015] The processed valid sub-reports are subjected to word frequency statistics to determine the frequency of occurrence of each word.

[0016] The inverse document frequency of each term is calculated across all valid sub-reports.

[0017] The weight of each term is obtained by multiplying its occurrence frequency by its inverse document frequency.

[0018] Based on the weights, each processed valid sub-report is transformed to obtain a high-dimensional numerical feature vector.

[0019] In one embodiment, the step of identifying typical collision patterns using an unsupervised clustering algorithm based on the high-dimensional numerical feature vector to obtain an abstract scene classification includes:

[0020] The high-dimensional numerical feature vector is input into an unsupervised clustering algorithm to initialize the cluster centers;

[0021] Calculate the distance from each of the high-dimensional numerical feature vectors to the corresponding cluster center, and assign each of the high-dimensional numerical feature vectors to the cluster to which the nearest cluster center belongs;

[0022] The cluster centers of each cluster are updated based on the average value of all the high-dimensional numerical feature vectors within each cluster, and the change in the cluster centers is obtained.

[0023] Repeat the operations of calculating distance, assigning clusters, and updating cluster centers until the change in the cluster centers is less than a preset change threshold or the preset number of iterations is reached to obtain preliminary clustering results;

[0024] The preliminary clustering results are evaluated by combining the elbow rule and the silhouette coefficient to determine the optimal number of clusters;

[0025] The high-dimensional numerical feature vectors are re-clustered based on the optimal number of clusters to obtain an abstract scene classification.

[0026] In one embodiment, the step of parameterizing the abstract scene classification to construct a standardized logical scene includes:

[0027] For each scenario in the abstract scenario classification, the parameter type of each scenario is determined, wherein the parameter type includes road geometry parameters, traffic participant parameters, initial dynamic state parameters, and environmental condition parameters;

[0028] From the valid sub-reports corresponding to each type of scenario in the abstract scenario classification, extract the specific parameter values ​​corresponding to each parameter type;

[0029] The specific parameter values ​​are verified to obtain valid parameter values;

[0030] The valid parameter values ​​are organized according to the preset standard format requirements to obtain the organized valid parameter values;

[0031] Based on the compiled valid parameter values, construct standardized logical scenarios corresponding to each type of scenario.

[0032] In one embodiment, the step of performing physical feasibility verification and risk level classification on the logical scenario using a kinematic verification module to obtain a risk scenario library further includes:

[0033] Construct a vehicle kinematics model and a collision set, wherein the vehicle kinematics model includes the relative motion state equations of autonomous vehicles and human-driven vehicles, and the collision set is the set of states in which the physical boundaries of autonomous vehicles and human-driven vehicles overlap.

[0034] The parameter values ​​in the logical scenario are input into the vehicle kinematics model for calculation to obtain the changes in the motion state of autonomous vehicles and human-driven vehicles within a preset time range.

[0035] Based on the changes in motion state, a forward reachability tube is calculated, which represents the set of all states that the vehicle can reach within a preset time range from its initial state.

[0036] Determine whether there is an intersection between the forward reachable tube and the collision set. If there is an intersection, determine that the logical scenario is physically feasible and calculate the risk quantification index.

[0037] Based on the statistical distribution characteristics of the risk quantification index on the preset accident dataset and combined with the preset fractional position, the logical scenarios with physical feasibility are divided into high-risk scenarios, medium-risk scenarios and low-risk scenarios.

[0038] The high-risk, medium-risk, and low-risk scenarios are summarized to form a risk scenario library.

[0039] In one embodiment, the step of classifying physically feasible logical scenarios into high-risk, medium-risk, and low-risk scenarios based on the statistical distribution characteristics of the risk quantification index on a preset accident dataset and a preset fractional place includes:

[0040] Obtain the risk quantification index values ​​corresponding to all logically feasible scenarios in the preset accident dataset;

[0041] The risk quantification index values ​​are sorted and calculated to obtain the cumulative distribution function of the risk quantification index values;

[0042] Based on the cumulative distribution function, a first quantile threshold and a second quantile threshold are determined, wherein the first quantile threshold is less than the second quantile threshold;

[0043] When the value of the risk quantification index is less than the first quantile threshold, the corresponding logical scenario is classified as a high-risk scenario.

[0044] When the risk quantification index value is greater than or equal to the first quantile threshold and the risk quantification index value is less than the second quantile threshold, the corresponding logical scenario is classified as a medium-risk scenario.

[0045] When the risk quantification index value is greater than or equal to the second quantile threshold, the corresponding logical scenario is classified as a low-risk scenario.

[0046] In one embodiment, the step of extracting samples from the risk scenario library using a stratified sampling strategy to generate an autonomous driving test case set includes:

[0047] The first sample size, the second sample size, and the third sample size are calculated based on a preset sampling ratio, wherein the first sample size is drawn from high-risk scenarios, the second sample size is drawn from medium-risk scenarios, and the third sample size is drawn from low-risk scenarios.

[0048] High-risk scenario samples are obtained by randomly selecting high-risk scenarios from the risk scenario library based on the first sample size;

[0049] Based on the second sample size, medium-risk scenarios are randomly selected from the risk scenario library to obtain medium-risk scenario samples;

[0050] Low-risk scenario samples are obtained by randomly selecting low-risk scenarios from the risk scenario library based on the third sample size.

[0051] The high-risk, medium-risk, and low-risk scenario samples are integrated to generate an autonomous driving test case set.

[0052] Furthermore, to achieve the above objectives, this application also proposes an autonomous driving test scenario generation device based on text collision reports, wherein the autonomous driving test scenario generation device based on text collision reports includes:

[0053] The acquisition module is used to acquire unstructured text collision reports;

[0054] The feature extraction module is used to preprocess and extract features from the unstructured text collision report to obtain a high-dimensional numerical feature vector.

[0055] The identification module is used to identify typical collision patterns based on the high-dimensional numerical feature vector using an unsupervised clustering algorithm to obtain an abstract scene classification.

[0056] The processing module is used to perform parameterization processing on the abstract scene classification and construct standardized logical scenes;

[0057] The construction module is used to perform physical feasibility verification of the logical scenario and classify the risk level through the kinematic verification module to obtain a risk scenario library;

[0058] The results module is used to extract samples from the risk scenario library using a stratified sampling strategy to generate an autonomous driving test case set.

[0059] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the autonomous driving test scenario generation method based on text collision reports as described above.

[0060] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the autonomous driving test scenario generation method based on text collision reports as described above.

[0061] This application obtains unstructured text collision reports, preprocesses and extracts features to transform them into high-dimensional numerical vectors, uses an unsupervised clustering algorithm to identify and classify typical collision patterns, further parameterizes and constructs logical scenarios, verifies physical feasibility and classifies risk levels using a kinematic verification module, forming a risk scenario library. Finally, a stratified sampling strategy is used to generate an autonomous driving test case set. By utilizing collision text data, realistic, diverse, and physically feasible test scenarios are generated, improving the efficiency and accuracy of autonomous driving safety assessment. Attached Figure Description

[0062] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0063] Figure 1 This is a flowchart illustrating the first embodiment of the autonomous driving test scenario generation method based on text collision reports in this application;

[0064] Figure 2 This is a flowchart illustrating the second embodiment of the autonomous driving test scenario generation method based on text collision reports in this application.

[0065] Figure 3 This is a flowchart illustrating the third embodiment of the autonomous driving test scenario generation method based on text collision reports in this application;

[0066] Figure 4 This is a schematic diagram of the module structure of the autonomous driving test scenario generation device based on text collision reports in this application;

[0067] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the autonomous driving test scenario generation method based on text collision reports in the embodiments of this application.

[0068] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0069] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0070] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0071] With the rapid development of autonomous driving technology, its safety verification has become a crucial link in ensuring public trust and promoting the implementation of the technology. Scenario-based testing, especially "edge scenario" testing that can detect the boundaries of system capabilities, has become the core technical path for autonomous driving safety verification. However, the generation of current autonomous driving test scenarios faces significant challenges: on the one hand, existing technologies do not make sufficient use of unstructured text collision report data, ignoring the rich semantic information contained within; on the other hand, scenarios generated by existing methods lack systematic verification of physical feasibility, leading to a large number of invalid scenarios, which seriously affects testing efficiency and the reliability of evaluation results. In addition, there are fundamental differences between the collision patterns of autonomous vehicles (AVs) and human-driven vehicles (HDVs), and directly applying human driving accident scenarios to test AVs cannot accurately expose their unique safety shortcomings.

[0072] Therefore, this application proposes a method for generating autonomous driving test scenarios based on text collision reports to solve the above-mentioned problems. The main solution of this application is as follows: obtaining unstructured text collision reports; preprocessing and extracting features from the unstructured text collision reports to obtain high-dimensional numerical feature vectors; using an unsupervised clustering algorithm based on the high-dimensional numerical feature vectors to identify typical collision patterns and obtain abstract scene classifications; parameterizing the abstract scene classifications to construct standardized logical scenes; verifying the physical feasibility of the logical scenes and classifying risk levels through a kinematic verification module to obtain a risk scene library; and using a stratified sampling strategy to extract samples from the risk scene library to generate an autonomous driving test case set.

[0073] Based on the above, this application also provides a method for generating autonomous driving test scenarios based on text collision reports, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the autonomous driving test scenario generation method based on text collision reports according to this application. In this embodiment, the autonomous driving test scenario generation method based on text collision reports includes steps S10 to S60:

[0074] Step S10: Obtain the unstructured text collision report.

[0075] It should be noted that when the autonomous driving test scenario generation system acquires unstructured text collision reports, it first clarifies the scope of the data source, prioritizing accident databases focused on autonomous vehicles (AVs), such as the AVOID dataset released by the University of Central Florida. This dataset aggregates real collision reports from 16 countries, covering three vehicle types: high-level autonomous driving (L3-L5), advanced driver assistance (L2), and low-speed shuttle vehicles. These reports are typically in unstructured text format, covering detailed circumstances of the accident, including vehicle status, road environment, weather conditions, traffic participant behavior, and accident consequences.

[0076] Step S20: Preprocess and extract features from the unstructured text collision report to obtain a high-dimensional numerical feature vector.

[0077] It should be noted that the aforementioned unstructured text reports typically contain a large amount of natural language description, covering detailed circumstances of the accident, such as vehicle status, road environment, and traffic participant behavior. To transform this text data into high-dimensional numerical feature vectors that can be processed by machine learning algorithms, preprocessing of the text is necessary. Further, step S20 includes: first, filtering the unstructured text collision reports to retain reports related to the autonomous driving function, resulting in multiple valid sub-reports, where the valid sub-reports are in English text. Specifically, the system filters out reports related to the autonomous driving function through a filtering operation, forming multiple valid sub-reports. These sub-reports are all in English text, covering detailed descriptions of the autonomous vehicle in the actual accident, including key information such as vehicle behavior, environmental conditions, and traffic conditions.

[0078] Then, all English text in the valid sub-reports is preprocessed to obtain the processed valid sub-reports. This preprocessing includes converting all English text to lowercase and removing punctuation, non-informational characters, general stop words, and non-critical informational words specific to the autonomous driving field. First, the system calls the text format conversion module to uniformly convert all English text characters in the valid sub-reports to lowercase, avoiding duplicate word counts during subsequent feature extraction due to case differences (e.g., "Rear" vs. "rear"). Second, the system activates the character cleanup module, which uses a preset set of punctuation marks (such as commas, periods, question marks, exclamation marks, quotation marks, parentheses, etc.) and a set of non-informational characters (such as garbled characters, special symbols "@", "#", "$", redundant spaces, tabs, etc.) to traverse and detect the text, removing all matched punctuation and non-informational characters, retaining only the text content with actual semantic meaning. The third step involves the system loading a general stop word list, which contains generic words with no actual semantic meaning or that are not helpful for scene classification (such as "the," "and," "or," "a," "an," etc.). The system performs word-by-word matching on the text and removes the matched generic stop words. The fourth step involves the system calling a stop word list specific to the autonomous driving domain. This list covers words in the autonomous driving domain that are not crucial for scene classification (such as specific vehicle brand and model, autonomous driving company names like "Waymo" and "Zoox," and non-critical administrative region names like "street"). The system performs word-by-word matching on the text again, removing matched domain-specific non-critical information words. Finally, a processed effective sub-report is obtained, laying a high-quality text data foundation for subsequent feature extraction steps.

[0079] Furthermore, after preprocessing, feature extraction is performed to obtain a high-dimensional numerical feature vector. Specifically, step S20 also includes: first, performing word frequency statistics on the processed effective sub-reports to determine the frequency of each word. Specifically, each processed effective sub-report is traversed word by word, recording the number of times each word (such as "rear-endcollision", "lane change", "rain", etc.) appears in the current sub-report, obtaining the frequency of each word in the effective sub-report, specifically expressed as:

[0080]

[0081] Where t represents a term, d represents a valid sub-report, D represents the set of documents containing valid sub-reports, and f t,d ∑ represents the number of times term t appears in the valid subreport d. t' f t',dThis represents the total number of occurrences of all terms. Frequency is used to quantify the importance of a single term within a valid sub-report. For example, in a sub-report describing a rear-end collision, terms like "rear-endcollision" and "rear" will appear more frequently than other irrelevant terms. Next, the inverse document frequency (IVF) of each term is calculated across all valid sub-reports. Specifically, the system first counts the number of valid sub-reports containing the term, then obtains the total number of valid sub-reports, and finally calculates the IVF using a preset formula. The specific form is as follows:

[0082]

[0083] Where |D| represents the total number of documents in document set D, and |{d∈D:t∈d}| represents the number of documents in document set D containing term t. Inverse document frequency (IVF) is used to measure the discriminative power of a term in the overall corpus. If a term appears only in a few sub-reports (e.g., "rear-ended while stopped"), its IVF value is high, indicating strong discriminative power for a specific scenario. If a term appears in most sub-reports (e.g., "vehicle"), its IVF value is low, indicating weak scenario discriminative power. Ideally, the occurrence frequency and IVF value of each term are multiplied to obtain the weight of each term, specifically expressed as:

[0084] ω(t,d,D)=tf(t,d)×idf(t,D).

[0085] This weighting comprehensively reflects the importance of a term within a single sub-report and its distinguishability within the overall corpus. A term with a higher weight is more representative of the scenario corresponding to that sub-report. For example, in the sub-report of the "low-speed rear-end collision" scenario, the weights of "low speed" and "rear-end collision" will be much higher than those of "sunny" and "straight road." Based on these weights, each processed valid sub-report is then transformed to obtain a high-dimensional numerical feature vector. Specifically, the system constructs a unified term dimension library, deduplicating all terms appearing in all valid sub-reports and using them as feature dimensions to form a fixed sequence. For each processed valid sub-report, the system extracts the weight of each term corresponding to that dimension in that sub-report according to the sequence in the term dimension library. If a term does not appear in the sub-report, its weight is set to 0. The weights of all dimensions are combined into a vector according to the sequence, ultimately obtaining the high-dimensional numerical feature vector corresponding to that valid sub-report. This achieves the transformation from unstructured text information to structured numerical data, providing standardized data input for subsequent identification of typical collision patterns using unsupervised clustering algorithms.

[0086] Step S30: Based on the high-dimensional numerical feature vector, an unsupervised clustering algorithm is used to identify typical collision patterns and obtain an abstract scene classification.

[0087] It should be noted that, through natural language processing technology, the unstructured text collision report has been transformed into high-dimensional numerical feature vectors. These vectors capture the core information in the accident report, such as the accident type, vehicle status, and road conditions. To discover potential collision patterns from these feature vectors, this embodiment employs an unsupervised clustering algorithm, such as k-means clustering. k-means clustering is a classic unsupervised learning method. Its goal is to find the cluster to which each sample belongs, then calculate the squared Euclidean distance from the sample to the center of the corresponding cluster, and sum up these distances for all samples. The algorithm minimizes this distance through repeated two-step iterations, specifically as follows:

[0088]

[0089] Where min represents finding the parameters that minimize the objective function, μ1,...,μ k Let x represent the centers of k clusters, k represent the number of clusters, n represent the total number of samples in the dataset, i represent the current number of samples in the dataset, j represent the index of a cluster, and x represent the cluster index. i μ represents the feature vector of the i-th sample in the dataset. j Let ||x| represent the eigenvector of the j-th cluster center. i -μ j || 2 It represents the square of the Euclidean distance between the cluster centers of the i-th sample and the j-th sample.

[0090] In this embodiment, similar collision reports are grouped into one category by calculating the distance between feature vectors, thereby identifying typical collision patterns. To determine the optimal number of clusters k, this embodiment employs the elbow rule and silhouette coefficient evaluation metrics. The elbow rule selects the optimal k value by observing the inflection point where the clustering error decreases with increasing cluster number, while the silhouette coefficient is used to measure the quality of sample clustering, specifically expressed as:

[0091]

[0092] Where s(i) represents the silhouette coefficient of the i-th sample, b(i) represents the average distance from the i-th sample to all samples in its nearest cluster (the nearest cluster besides the one containing the i-th sample), reflecting the inter-cluster separation, a(i) represents the average distance from the i-th sample to all samples in its own cluster, reflecting the intra-cluster compactness, and max{a(i),b(i)} represents taking the maximum value between a(i) and b(i). For the entire dataset, the mean of all samples s(i) is taken to obtain the global silhouette coefficient. The larger this value, the clearer and more reasonable the overall clustering structure. Through unsupervised clustering algorithms, this embodiment can automatically discover typical collision patterns in accident reports and classify them into abstract scene categories. For example, collision patterns can be divided into categories such as "rear-end collision," "lane change conflict," and "intersection collision." These abstract scene classifications not only reflect the main characteristics of accident reports but also provide a foundation for subsequent logical scene parameterization and physical feasibility verification.

[0093] Step S40: Perform parameterization on the abstract scene classification to construct a standardized logical scene.

[0094] It should be noted that although the typical collision patterns identified by the unsupervised clustering algorithm have a certain degree of semantic coherence, these abstract scene classifications still need further structured description in order to be understood and used by the autonomous driving test system.

[0095] Further, step S40 includes: First, for each scenario category in the abstract scenario classification, determining the parameter type for each scenario category. Specifically, the parameter types include road geometry parameters (such as road type, curve curvature, number of lanes, etc.), traffic participant parameters (such as vehicle type, number, relative position, etc.), initial dynamic state parameters (such as speed, acceleration, relative speed, etc.), and environmental condition parameters (such as weather conditions, lighting conditions, time, etc.). The selection of these parameter types is based on the analysis of key influencing factors for the safety assessment of the autonomous driving system, ensuring that the generated logical scenarios can comprehensively cover various possible driving environments and conditions.

[0096] Next, from the valid sub-reports corresponding to each scenario category in the abstract scenario classification, specific parameter values ​​corresponding to each parameter type are extracted. This process is implemented using natural language processing techniques and rule matching algorithms to extract information related to parameter types from the text reports. For example, through keyword matching and context analysis, specific information such as vehicle speed, road type, and weather conditions at the time of the accident can be extracted from the report. The mining process needs to consider the diversity and complexity of the text to ensure that the extracted information is accurate and comprehensive.

[0097] Next, the specific parameter values ​​are validated to obtain valid values. Specifically, the validation process includes checking the reasonableness and consistency of the parameter values. For example, it checks whether the speed value is within a reasonable range and whether the road type is consistent with the accident description. Through validation, erroneous or unreasonable parameter values ​​can be eliminated, ensuring the accuracy of subsequent logical scenario construction.

[0098] Then, the valid parameter values ​​are organized according to preset standard format requirements to obtain the organized valid parameter values. Specifically, the organization process includes formatting and standardizing the parameter values ​​to make them conform to the requirements of logical scenario construction. For example, the speed unit is standardized to kilometers per hour, and road types are coded according to predefined categories. The organized parameter values ​​will serve as the basic data for constructing the logical scenario.

[0099] Finally, based on the compiled valid parameter values, standardized logical scenarios are constructed for each type of scenario. Specifically, the construction of logical scenarios follows international standards (such as ISO 34502), integrating parameter values ​​into a structured scenario description. For example, for a "rear-end collision" scenario, the logical scenario might include parameters such as the speed of the vehicle in front being 60 km / h, the speed of the vehicle behind being 80 km / h, the initial distance between the two vehicles being 30 meters, the road type being a highway, and the weather condition being sunny. In this way, logical scenarios can not only accurately reflect the core characteristics of the accident but also provide detailed input for subsequent physical feasibility verification and risk assessment.

[0100] Through the above steps, abstract scenarios can be categorized and transformed into standardized logical scenarios, ensuring that the generated test scenarios are realistic, diverse, and physically feasible. This process provides a high-quality testing foundation for the safety evaluation of autonomous driving systems, contributing to improved safety and reliability of autonomous driving technology.

[0101] Step S50: The kinematic verification module is used to verify the physical feasibility of the logical scenario and classify the risk level to obtain a risk scenario library.

[0102] It's important to note that while logical scenarios structurally define the core characteristics of an accident, a kinematic verification module is still needed to ensure these scenarios are physically feasible and accurately reflect the potential risk level. The core of the kinematic verification module lies in establishing a kinematic model of the vehicle, which describes its motion under specific initial conditions. By calculating the vehicle's forward reachability tube (FRT), all possible locations the vehicle can reach within a future timeframe can be determined. This process considers the vehicle's dynamic constraints, such as maximum acceleration, maximum deceleration, and physical dimensions. Through the calculation of the forward reachability tube, it can be determined whether the vehicle's motion in the logical scenario conforms to physical laws, thereby filtering out physically infeasible scenarios.

[0103] Furthermore, based on the physical feasibility verification, the logical scenarios are classified into risk levels. This risk level classification is based on a series of quantitative indicators, such as Time to Collision (TTC), Forward Risk Index (FRI), and longitudinal safety distance. These indicators assess the collision risk of a vehicle in a specific scenario. For example, a lower TTC value indicates a higher collision risk, while a higher FRI value means a shorter effective reaction time for the human driver, increasing the collision risk. Through the calculation of these indicators, logical scenarios can be classified into high-risk, medium-risk, and low-risk levels.

[0104] Ultimately, the logical scenarios, after physical feasibility verification and risk level classification, were compiled into a risk scenario library. This library not only includes diverse test scenarios but also clearly defines the risk level of each scenario, providing crucial data support for the safety assessment of autonomous driving systems. In this way, this technical solution ensures that the generated test scenarios are not only realistic and diverse but also possess physical fidelity, thus providing strong assurance for the safety and reliability assessment of autonomous driving systems.

[0105] Step S60: Use a stratified sampling strategy to extract samples from the risk scenario library to generate an autonomous driving test case set.

[0106] It should be noted that the risk scenario library contains diverse scenarios that have undergone physical feasibility verification and risk level classification, categorized as high-risk, medium-risk, and low-risk. To efficiently utilize these scenarios for safety assessments of autonomous driving systems, a scientifically sound sampling method is required. The core of the stratified sampling strategy lies in stratifying scenarios according to risk level and extracting samples from each stratum according to a predetermined proportion.

[0107] Specifically, step S60 includes: First, calculating the number of first samples, the number of second samples, and the number of third samples according to a preset sampling ratio, wherein the number of first samples is drawn from high-risk scenarios, the number of second samples is drawn from medium-risk scenarios, and the number of third samples is drawn from low-risk scenarios. The preset sampling ratio is usually set based on the needs and experience of safety assessment of autonomous driving systems. For example, high-risk scenarios may account for 10%, medium-risk scenarios for 30%, and low-risk scenarios for 60%.

[0108] Then, based on the first sample size, high-risk scenarios are randomly selected from the risk scenario library to obtain high-risk scenario samples; based on the second sample size, medium-risk scenarios are randomly selected from the risk scenario library to obtain medium-risk scenario samples; and based on the third sample size, low-risk scenarios are randomly selected from the risk scenario library to obtain low-risk scenario samples.

[0109] Finally, high-risk, medium-risk, and low-risk scenario samples are integrated to generate an autonomous driving test case set. Specifically, these three types of risk scenario samples are integrated to form a complete autonomous driving test case set. The integration process needs to ensure compatibility and consistency between the samples so that the test case set can comprehensively cover driving scenarios with different risk levels. The generated test case set not only includes high-risk edge scenarios to test the performance of the autonomous driving system under extreme conditions, but also medium-risk and low-risk routine scenarios to evaluate the stability and reliability of the system in daily driving.

[0110] This stratified sampling strategy ensures that the generated test case set covers both high-risk edge scenarios and a large number of low-risk routine scenarios, enabling a comprehensive evaluation of the autonomous driving system during testing. This strategy not only improves testing efficiency but also ensures the reliability and representativeness of the test results. The resulting autonomous driving test case set provides strong support for the safety and reliability assessment of autonomous driving systems, helping developers identify and improve potential problems within the system.

[0111] This embodiment acquires unstructured text collision reports, preprocesses and extracts features to transform them into high-dimensional numerical vectors, uses an unsupervised clustering algorithm to identify and classify typical collision patterns, further parameterizes and constructs logical scenarios, verifies physical feasibility and classifies risk levels using a kinematic verification module, forming a risk scenario library. Finally, a stratified sampling strategy is used to generate an autonomous driving test case set. By utilizing collision text data, realistic, diverse, and physically feasible test scenarios are generated, improving the efficiency and accuracy of autonomous driving safety assessment.

[0112] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 The method for generating autonomous driving test scenarios based on text collision reports, step S30, further includes steps S201 to S206:

[0113] Step S201: Input the high-dimensional numerical feature vector into the unsupervised clustering algorithm to initialize the cluster centers.

[0114] It should be noted that the high-dimensional numerical feature vectors extracted from the unstructured text collision report will be used as input data. In natural language processing tasks, TF-IDF is commonly used as a text feature weighting scheme. Through TF-IDF weights, unstructured text data can be transformed into structured high-dimensional numerical feature vectors. These feature vectors can capture key information in the text, such as accident type, vehicle status, road conditions, etc.

[0115] Before inputting these feature vectors into an unsupervised clustering algorithm (such as k-means clustering), cluster centers need to be initialized. Initializing cluster centers is a crucial step in the clustering algorithm, directly affecting the quality of the clustering results and the convergence speed. Common initialization methods include randomly selecting feature vectors as initial cluster centers, using the k-means++ algorithm for optimization, or selecting initial cluster centers based on the distribution characteristics of the data (such as density and distance).

[0116] Taking the k-means clustering algorithm as an example, the process of initializing cluster centers is as follows: randomly select k feature vectors as initial cluster centers, or select initial centers through the k-means++ algorithm to ensure that these centers have a good distribution in the data space.

[0117] Step S202: Calculate the distance from each high-dimensional numerical feature vector to the corresponding cluster center, and assign each high-dimensional numerical feature vector to the cluster to which the nearest cluster center belongs.

[0118] It should be noted that each high-dimensional numerical feature vector represents a key feature of a collision report, extracted from text data using natural language processing techniques such as TF-IDF. During clustering, the first step is to calculate the distance between each feature vector and all cluster centers. Typically, distances can be calculated using methods such as Euclidean distance, Manhattan distance, or cosine similarity. Taking Euclidean distance as an example, it measures the straight-line distance between a feature vector and a cluster center in multidimensional space, and the formula is:

[0119]

[0120] Where, x i c is the i-th eigenvalue of the eigenvector. i Let be the i-th eigenvalue of the cluster center, and n represent the dimension of the feature vector. After calculating the distance from each feature vector to all cluster centers, each feature vector is assigned to the cluster to which its nearest cluster center belongs. This assignment process is based on the principle of minimizing distance, meaning each feature vector is assigned to the cluster represented by its nearest cluster center. In this way, similar feature vectors are grouped together, forming clusters with similar characteristics. This process not only automatically discovers potential structures in the data but also groups similar collision reports into one category, thus obtaining an abstract scene classification. For example, through clustering, collision reports can be classified into categories such as "rear-end collision," "lane change conflict," and "intersection collision." These classifications not only reflect the main characteristics of the accident reports but also provide a foundation for subsequent logical scene parameterization and physical feasibility verification.

[0121] Step S203: Update the cluster center of each cluster based on the average value of all high-dimensional numerical feature vectors in each cluster and obtain the change in the cluster center.

[0122] It should be noted that in each iteration, the average of all high-dimensional numerical eigenvectors within each cluster is first calculated to update the cluster centers of that cluster. This process is implemented using the following formula:

[0123]

[0124] Where, μ j S represents the new cluster center of the j-th cluster. j Let |S| represent the set of all eigenvectors within the j-th cluster. j | represents the number of feature vectors within the cluster, and x represents each feature vector within the cluster. After updating the cluster centers, it is necessary to calculate the change in cluster centers to determine whether the clustering algorithm has converged. The change in cluster centers can be measured by calculating the distance between the old and new cluster centers, typically using Euclidean distance:

[0125]

[0126] Where, μ new μ represents the i-th eigenvalue of the new cluster centers. old Let i represent the i-th eigenvalue of the new cluster center.

[0127] Step S204: Repeat the operations of calculating distance, assigning clusters, and updating cluster centers until the change in cluster centers is less than the preset change threshold or the preset number of iterations is reached, and obtain the preliminary clustering results.

[0128] It should be noted that if the change in all cluster centers is less than a preset change threshold (e.g., 0.001), or if a preset number of iterations is reached (e.g., 100 iterations), the clustering algorithm is considered to have converged and the iteration stops. Otherwise, the next iteration continues, and the above steps are repeated.

[0129] The core of this iterative process lies in gradually optimizing the clustering results, making the feature vectors within each cluster as similar as possible, while ensuring that the feature vectors between different clusters are as different as possible. By continuously updating the cluster centers and reallocating feature vectors, the algorithm can gradually find the optimal clustering structure in the data. For example, in the clustering of autonomous driving collision reports, the algorithm may group similar collision scenarios (such as rear-end collisions, lane change conflicts, etc.) into different clusters, thereby providing a diverse basis for the generation of subsequent test scenarios.

[0130] Step S205: Evaluate the preliminary clustering results by combining the elbow rule and the silhouette coefficient to determine the optimal number of clusters.

[0131] It should be noted that, in order to evaluate the preliminary clustering results and determine the optimal number of clusters, this embodiment combines the elbow rule and the silhouette coefficient to ensure the accuracy and effectiveness of the clustering results. The elbow rule determines the optimal number of clusters by observing the trend of clustering error (such as total squared error within clusters, SSE) as the number of clusters increases. Specifically, as the number of clusters increases, SSE gradually decreases, but the rate of decrease drops significantly at a certain point, forming the "elbow." This elbow point is generally considered a better choice of cluster number. For example, when plotting the curve of SSE versus the number of clusters, the rate of decrease of SSE slows significantly when the number of clusters is k, indicating that adding more clusters has limited improvement on the clustering results. The silhouette coefficient is used to evaluate the quality of the clustering results. The silhouette coefficient measures how tightly each data point is packed within its own cluster and how well it is separated from other clusters. The silhouette coefficient ranges from -1 to 1; the closer the value is to 1, the better the clustering effect, i.e., the data points within clusters are tightly packed and the data points between clusters are separated. By calculating the average silhouette coefficient of all data points, the reasonableness of the entire clustering result can be evaluated. For example, when the number of clusters is k, the average silhouette coefficient reaches a high value, indicating that the clustering results at this time have good internal compactness and external separation.

[0132] In practical applications, the elbow rule and the profile coefficient are usually used in combination. First, the elbow rule is used to initially determine a possible range of optimal cluster numbers; then, the profile coefficient is used within this range to further verify and select the optimal cluster number. For example, if the elbow rule indicates that the elbow occurs at a cluster number of 4, and the profile coefficient also reaches a high value at a cluster number of 4, then 4 can be determined as the optimal cluster number.

[0133] Step S206: Re-cluster the high-dimensional numerical feature vectors according to the optimal number of clusters to obtain the abstract scene classification.

[0134] It should be noted that, through the preceding steps, the initial clustering results have been evaluated using the elbow rule and silhouette coefficient, and the optimal number of clusters has been determined. Next, based on this optimal number of clusters, the clustering algorithm is restarted to re-cluster the high-dimensional numerical feature vectors.

[0135] The re-clustering process is similar to the initial clustering, but the goal is to obtain more accurate clustering results using the optimal number of clusters. Specifically, first, cluster centers are initialized, typically by randomly selecting feature vectors or choosing initial centers based on data distribution characteristics. Then, the distance from each feature vector to a cluster center is calculated, and the feature vector is assigned to the cluster containing the nearest cluster center. Next, the cluster centers are updated based on the average of all feature vectors within each cluster, and the change in cluster centers is calculated. This process iterates until the change in cluster centers is less than a preset threshold or the maximum number of iterations is reached.

[0136] By re-clustering, more stable and accurate cluster partitioning can be obtained. Each cluster represents a class of collision scenarios with similar characteristics. These scenarios are semantically coherent and can reflect various typical situations that autonomous vehicles may encounter in actual driving. For example, one cluster may contain all rear-end collision scenarios, another cluster may contain lane change conflict scenarios, and a third cluster may contain intersection collision scenarios, etc.

[0137] This embodiment uses an unsupervised clustering algorithm to perform cluster analysis on high-dimensional numerical feature vectors. The process includes initializing cluster centers, calculating distances, assigning clusters, and updating cluster centers, continuing until convergence conditions are met to obtain preliminary clustering results. The elbow rule and silhouette coefficient are then used to evaluate the preliminary clustering results. After determining the optimal number of clusters, the clusters are re-clustered to ultimately obtain an abstract scene classification. This approach can automatically discover typical collision patterns from massive amounts of data, generating realistic and diverse autonomous driving test scenarios, thus improving testing efficiency and the accuracy of safety assessments.

[0138] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 The step S50 of generating an autonomous driving test scenario based on a text collision report further includes steps S301 to S306:

[0139] Step S301: Construct the vehicle kinematics model and collision set.

[0140] It should be noted that the vehicle kinematics model includes the relative motion state equations of the automated vehicle (AV) and the human-driven vehicle (HDV), simulating the vehicle's trajectory under specific initial conditions by establishing mathematical equations. This model typically includes dynamic parameters such as the vehicle's position, velocity, and acceleration, as well as the vehicle's physical characteristics (e.g., length, width) and motion constraints (e.g., maximum acceleration, maximum deceleration). Specifically, the kinematic model can be represented by state-space equations in a discrete-time frame:

[0141] x(k+1)=Ax(k)+By(k)+Fω(k)

[0142] Where x(k) is the system's state vector at time step k, containing relative position and velocity information, y(k) is the control input of the AV, ω(k) is the disturbance input from other vehicles, and A, B, and F represent the system matrix, control input matrix, and disturbance input matrix, respectively, defining the dynamic characteristics of the system.

[0143] The collision set is the set of states where the physical boundaries of autonomous vehicles and human-driven vehicles overlap. It determines whether a collision has occurred by defining the physical boundaries and relative positional relationships of the vehicles.

[0144] Step S302: Input the parameter values ​​in the logical scenario into the vehicle kinematics model for calculation to obtain the motion state changes of autonomous vehicles and human-driven vehicles within a preset time range.

[0145] It should be noted that by substituting the parameter values ​​from the logical scenario into the kinematic model, the changes in the motion state of the AV and HDV within a preset time range can be calculated. For example, the model can predict the relative position, velocity changes, and potential collision risks of the two vehicles in the next few seconds. This process takes into account the vehicle's dynamic constraints, such as maximum acceleration and deceleration, to ensure that the simulated motion state conforms to the laws of physics.

[0146] Furthermore, the output of the kinematic model can be used for further risk assessment. For example, by calculating the forward reachability set (FRT), all possible locations that the vehicles may reach within a future timeframe can be determined, thereby assessing whether a collision between the two vehicles is likely. If the reachability sets of the AV and HDV intersect within a preset time range, it indicates a collision risk.

[0147] Step S303: Calculate the forward reachable tube based on the change in motion state.

[0148] It should be noted that a forward reachability tube represents the set of all states a vehicle can reach within a preset time range from its initial state. It describes all states a vehicle can reach within a future period under all possible control inputs and disturbances. Specifically, the calculation of a forward reachability tube is based on the vehicle's kinematic model, which describes the changes in the vehicle's motion state under given initial conditions. By inputting parameter values ​​from the logical scenario (such as initial position, velocity, acceleration, etc.) into the kinematic model, the motion trajectories of autonomous vehicles (AVs) and human-driven vehicles (HDVs) within the preset time range can be obtained. Based on these motion trajectories, the forward reachability tube can be defined as follows:

[0149]

[0150] Here, x0 represents the initial state of the vehicle, Y represents the control input set of the AV, W represents the disturbance input set from other vehicles, and A, B, and F represent the system matrix, control input matrix, and disturbance input matrix, respectively, defining the dynamic characteristics of the system. By calculating the forward reachability tubes, all possible positions and velocities of the vehicle within future time steps can be determined. If the forward reachability tubes of the AV and HDV intersect within a preset time range, it indicates a potential collision risk. This intersection can be defined by the collision set, which is the set of states where the physical boundaries of the two vehicles overlap. By analyzing the intersection of the forward reachability tubes and the collision set, the collision risk can be quantified, providing a scientific basis for the safety assessment of autonomous driving systems.

[0151] Step S304: Determine whether there is an intersection between the forward reachable tube and the collision set. If there is an intersection, determine that the logical scenario is physically feasible and calculate the risk quantification index.

[0152] It should be noted that the forward reachability tube describes the set of all possible states that the vehicle can reach within a preset time range, while the collision set defines the set of states where the vehicle's physical boundaries overlap. By analyzing the intersection of the forward reachability tube and the collision set, it is possible to determine whether the vehicle faces a collision risk in future time steps.

[0153] Specifically, the forward reachability metrics for both the autonomous vehicle (AV) and the human-driven vehicle (HDV) are first calculated. If the forward reachability metrics of the AV and HDV intersect within a preset time range, it indicates that a collision between the two vehicles is likely at some point in the future. In this case, the logical scenario is deemed physically feasible because it is physically achievable and presents a potential collision risk.

[0154] After determining that the logical scenario is physically feasible, risk quantification indicators are further calculated to assess the severity of the collision risk. Commonly used risk quantification indicators include Time to Collision (TTC), Forward Risk Index (FRI), and Longitudinal Safety Distance (D). For example, TTC is defined as the time required for a collision between the two vehicles at the current relative speed, and the calculation formula is:

[0155]

[0156] Where, d rel The relative distance between the two vehicles, v rel The TTC value indicates the relative speed of the two vehicles; a lower TTC value indicates a higher risk of collision. The FRI value, on the other hand, takes into account the vehicles' reaction time and avoidance capabilities to assess the urgency of a collision.

[0157] Step S305: Based on the statistical distribution characteristics of the risk quantification indicators on the preset accident dataset and the preset fractional values, the logical scenarios with physical feasibility are divided into high-risk scenarios, medium-risk scenarios and low-risk scenarios.

[0158] It's important to note that the process involves acquiring risk quantification index values ​​for all physically feasible logical scenarios within a pre-defined accident dataset. These risk quantification index values ​​reflect the potential danger level of each scenario; higher values ​​indicate greater safety, while lower values ​​indicate higher risk. Common risk quantification indices include Time-of-Collision (TTC) and Forward Risk Index (FRI), which effectively assess vehicle collision risk in specific scenarios. The risk quantification index values ​​are then sorted and calculated to obtain the Cumulative Distribution Function (CDF). The CDF visually displays the distribution of risk quantification index values ​​across the entire dataset, providing a basis for subsequent risk level classification. The CDF allows for the determination of quantile thresholds for different risk levels, enabling refined classification of scenario risks. Based on the cumulative distribution function, a first quantile threshold and a second quantile threshold are determined, where the first quantile threshold is lower than the second quantile threshold. These two thresholds divide the risk quantification index values ​​into three intervals, corresponding to high-risk, medium-risk, and low-risk scenarios, respectively. Specifically, using the CDF to determine the quantile thresholds for risk quantification index values ​​is a statistical method used to classify the dataset into different risk levels. This method is particularly important in risk assessment for autonomous driving test scenarios because it helps identify and quantify potential risks in different scenarios. By analyzing the risk quantification index (CDF) values, we can find two key quantile thresholds: the first quantile threshold and the second quantile threshold. These two thresholds divide the entire dataset into three intervals, each corresponding to a different risk level. The first quantile threshold typically corresponds to the lowest 25% of data points in the dataset, while the second quantile threshold corresponds to the upper limit of the middle 50% of data points. When the risk quantile index value is less than the first quantile threshold, the corresponding logical scenario is classified as a high-risk scenario. These scenarios typically require priority for safety assessment and testing to ensure the safety and reliability of the autonomous driving system under high-risk conditions. When the risk quantile index value is greater than or equal to the first quantile threshold and less than the second quantile threshold, the corresponding logical scenario is classified as a medium-risk scenario. Although medium-risk scenarios are relatively less dangerous, they still require attention, and targeted testing can be used to evaluate the performance of the autonomous driving system in these scenarios. When the risk quantification index value is greater than or equal to the second quantile threshold, the corresponding logical scenario is classified as a low-risk scenario. Low-risk scenarios usually reflect relatively common and safe driving situations. These scenarios can be used to test the stability and performance of the autonomous driving system under normal conditions.

[0159] Step S306: High-risk scenarios, medium-risk scenarios, and low-risk scenarios are summarized to form a risk scenario library.

[0160] It's important to note that establishing a risk scenario library not only provides a diverse range of scenarios for testing autonomous driving systems but also ensures that the testing process covers various situations, from extremely dangerous to normal driving. High-risk scenarios typically include extreme situations such as emergency avoidance and rear-end collisions, which place extremely high demands on the perception, decision-making, and control capabilities of autonomous driving systems. Medium-risk scenarios cover more complex traffic interactions, such as lane-change conflicts and intersection collisions, which can assess the system's ability to cope in complex environments. Low-risk scenarios reflect common situations in daily driving, such as smooth following and normal driving; these scenarios are mainly used to test the system's stability and general performance.

[0161] By aggregating these three types of scenarios, the constructed risk scenario library provides a comprehensive testing foundation for the safety assessment of autonomous driving systems. The risk scenario library not only includes diverse test scenarios but also provides clear priority guidance for the testing process through risk level categorization. For example, high-risk scenarios can be prioritized for testing the emergency avoidance and safety response capabilities of autonomous driving systems, medium-risk scenarios are used to evaluate the system's performance in complex environments, and low-risk scenarios are used to verify the system's stability and performance under normal conditions.

[0162] This embodiment constructs a vehicle kinematics model and collision set, inputs logical scenario parameters to calculate changes in motion state, and calculates the forward reachability tube based on this. By determining the intersection of the forward reachability tube and the collision set, the physical feasibility of the logical scenario is assessed, and a risk quantification index is calculated. Combining statistical distribution and preset score ranges, the scenario is divided into high, medium, and low risk scenarios, and a risk scenario library is compiled to comprehensively evaluate the safety of the autonomous driving system, improve testing efficiency and accuracy, and provide a scientific basis for the safety verification of autonomous driving technology.

[0163] Based on the first embodiment of this application, this application also provides an autonomous driving test scenario generation device based on text collision reports. Please refer to... Figure 4 The device includes:

[0164] Module 10 is used to obtain unstructured text collision reports.

[0165] The feature extraction module 20 is used to preprocess and extract features from unstructured text collision reports to obtain high-dimensional numerical feature vectors.

[0166] The recognition module 30 is used to identify typical collision patterns based on high-dimensional numerical feature vectors using an unsupervised clustering algorithm to obtain an abstract scene classification.

[0167] Processing module 40 is used to perform parameterization processing on abstract scene classification and construct standardized logical scenes.

[0168] Module 50 is used to perform physical feasibility verification of logical scenarios and classify risk levels through the kinematic verification module, thereby obtaining a risk scenario library.

[0169] Result module 60 is used to extract samples from the risk scenario library using a stratified sampling strategy to generate an autonomous driving test case set.

[0170] The autonomous driving test scenario generation device based on text collision reports provided in this application, employing the autonomous driving test scenario generation method based on text collision reports in the above embodiments, can solve the technical problem of how to simulate autonomous driving scenarios to improve the safety and reliability of autonomous driving systems. Compared with the prior art, the beneficial effects of the autonomous driving test scenario generation device based on text collision reports provided in this application are the same as those of the autonomous driving test scenario generation method based on text collision reports provided in the above embodiments, and other technical features in the autonomous driving test scenario generation device based on text collision reports are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0171] In one embodiment, the feature extraction module 20 is further configured to filter the unstructured text collision reports to retain reports related to autonomous driving functions, thereby obtaining multiple valid sub-reports, wherein the valid sub-reports are reports in English text; preprocess all English text in the valid sub-reports to obtain processed valid sub-reports, wherein the preprocessing includes converting all English text to lowercase; perform word frequency statistics on the processed valid sub-reports to determine the frequency of occurrence of each term; calculate the inverse document frequency of each term in all valid sub-reports; multiply the frequency of occurrence and the inverse document frequency of each term to obtain the weight of each term; and transform each processed valid sub-report based on the weight to obtain a high-dimensional numerical feature vector.

[0172] In one embodiment, the identification module 30 is further configured to input the high-dimensional numerical feature vectors into an unsupervised clustering algorithm to initialize cluster centers; calculate the distance from each high-dimensional numerical feature vector to its corresponding cluster center, and assign each high-dimensional numerical feature vector to the cluster to which the nearest cluster center belongs; update the cluster centers of each cluster based on the average value of all high-dimensional numerical feature vectors within each cluster and obtain the change in cluster centers; repeatedly perform the operations of calculating distance, assigning clusters, and updating cluster centers until the change in cluster centers is less than a preset change threshold or reaches a preset number of iterations to obtain preliminary clustering results; evaluate the preliminary clustering results using the elbow rule and silhouette coefficient to determine the optimal number of clusters; and re-cluster the high-dimensional numerical feature vectors based on the optimal number of clusters to obtain an abstract scene classification.

[0173] In one embodiment, the processing module 40 is further configured to: determine the parameter type for each scenario in the abstract scenario classification, wherein the parameter type includes road geometry parameters, traffic participant parameters, initial dynamic state parameters, and environmental condition parameters; mine specific parameter values ​​corresponding to each parameter type from the valid sub-reports corresponding to each scenario in the abstract scenario classification; verify the specific parameter values ​​to obtain valid parameter values; organize the valid parameter values ​​according to preset standard format requirements to obtain organized valid parameter values; and construct a standardized logical scenario corresponding to each scenario based on the organized valid parameter values.

[0174] In one embodiment, the construction module 50 is further configured to construct a vehicle kinematics model and a collision set, wherein the vehicle kinematics model includes the relative motion state equations of the autonomous vehicle and the human-driven vehicle, and the collision set is a set of states where the physical boundaries of the autonomous vehicle and the human-driven vehicle overlap; the parameter values ​​in the logical scenario are input into the vehicle kinematics model for calculation to obtain the motion state changes of the autonomous vehicle and the human-driven vehicle within a preset time range; based on the motion state changes, a forward reachable tube is calculated, wherein the forward reachable tube represents the set of all states that the vehicle can reach within the preset time range from the initial state; it is determined whether the forward reachable tube and the collision set have an intersection; if there is an intersection, the logical scenario is determined to be physically feasible and a risk quantification index is calculated; based on the statistical distribution characteristics of the risk quantification index on a preset accident dataset and combined with a preset fraction, the logical scenarios with physical feasibility are divided into high-risk scenarios, medium-risk scenarios, and low-risk scenarios; the high-risk scenarios, medium-risk scenarios, and low-risk scenarios are summarized to construct a risk scenario library.

[0175] In one embodiment, the construction module 50 is further configured to obtain risk quantification index values ​​corresponding to all physically feasible logical scenarios in a preset accident dataset; sort and calculate the risk quantification index values ​​to obtain a cumulative distribution function of the risk quantification index values; determine a first quantile threshold and a second quantile threshold based on the cumulative distribution function, wherein the first quantile threshold is less than the second quantile threshold; when the risk quantification index value is less than the first quantile threshold, the corresponding logical scenario is classified as a high-risk scenario; when the risk quantification index value is greater than or equal to the first quantile threshold and the risk quantification index value is less than the second quantile threshold, the corresponding logical scenario is classified as a medium-risk scenario; when the risk quantification index value is greater than or equal to the second quantile threshold, the corresponding logical scenario is classified as a low-risk scenario.

[0176] In one embodiment, the result module 60 is further configured to calculate a first sample quantity, a second sample quantity, and a third sample quantity according to a preset sampling ratio, wherein the first sample quantity is drawn from high-risk scenarios, the second sample quantity is drawn from medium-risk scenarios, and the third sample quantity is drawn from low-risk scenarios; high-risk scenario samples are obtained by randomly drawing high-risk scenarios from the risk scenario library based on the first sample quantity; medium-risk scenario samples are obtained by randomly drawing medium-risk scenarios from the risk scenario library based on the second sample quantity; low-risk scenario samples are obtained by randomly drawing low-risk scenarios from the risk scenario library based on the third sample quantity; and the high-risk scenario samples, medium-risk scenario samples, and low-risk scenario samples are integrated to generate an autonomous driving test case set.

[0177] This application provides an autonomous driving test scenario generation device based on text collision reports. The autonomous driving test scenario generation device based on text collision reports includes: at least one processor; and a memory communicatively connected to at least one processor; wherein the memory stores instructions that can be executed by at least one processor, and the instructions are executed by at least one processor to enable at least one processor to execute the autonomous driving test scenario generation method based on text collision reports in the above embodiment 1.

[0178] The following is for reference. Figure 5This document illustrates a structural schematic diagram of an autonomous driving test scenario generation device suitable for implementing embodiments of this application based on text collision reports. The autonomous driving test scenario generation device based on text collision reports in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The autonomous driving test scenario generation device based on text collision reports shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0179] like Figure 5 As shown, the autonomous driving test scenario generation device based on text collision reports may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the autonomous driving test scenario generation device based on text collision reports. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the autonomous driving test scenario generation device based on text collision reports to wirelessly or wiredly communicate with other devices to exchange data. Although various autonomous driving test scenario generation devices based on text collision reports are shown in the figures, it should be understood that implementation or possession of all of them is not required. More or fewer may be implemented alternatively.

[0180] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable storage medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0181] The autonomous driving test scenario generation device based on text collision reports provided in this application, employing the autonomous driving test scenario generation method based on text collision reports in the above embodiments, can solve the technical problem of how to simulate autonomous driving scenarios to improve the safety and reliability of autonomous driving systems. Compared with the prior art, the beneficial effects of the autonomous driving test scenario generation device based on text collision reports provided in this application are the same as those of the autonomous driving test scenario generation method based on text collision reports provided in the above embodiments, and other technical features in this autonomous driving test scenario generation device based on text collision reports are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0182] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0183] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0184] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the autonomous driving test scenario generation method based on text collision reports in the above embodiments.

[0185] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, 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 devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible storage medium containing or storing a program that can be executed by instructions, used by a device, or used in conjunction with it. The program code contained on the computer-readable storage medium may be transmitted using any suitable storage medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0186] The aforementioned computer-readable storage medium may be included in the autonomous driving test scenario generation device based on text collision reports; or it may exist independently and not be assembled into the autonomous driving test scenario generation device based on text collision reports.

[0187] The aforementioned computer-readable storage medium carries one or more programs that, when executed by an autonomous driving test scenario generation device based on text collision reports, enable the device to write computer program code for performing the operations of this application in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0188] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using dedicated hardware-based implementations that perform the specified functions or operations, or can be implemented using a combination of dedicated hardware and computer instructions.

[0189] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0190] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described method for generating autonomous driving test scenarios based on text collision reports. This method can solve the technical problem of how to simulate autonomous driving scenarios to improve the safety and reliability of autonomous driving systems. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the autonomous driving test scenario generation method based on text collision reports provided in the above embodiments, and will not be repeated here.

[0191] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method for generating autonomous driving test scenarios based on text collision reports.

[0192] The computer program product provided in this application can solve the technical problem of how to simulate autonomous driving scenarios to improve the safety and reliability of autonomous driving systems. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the autonomous driving test scenario generation method based on text collision reports provided in the above embodiments, and will not be repeated here.

[0193] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for generating autonomous driving test scenarios based on text collision reports, characterized in that, The method includes: Get unstructured text collision reports; The unstructured text collision report is preprocessed and its features are extracted to obtain a high-dimensional numerical feature vector; Based on the high-dimensional numerical feature vectors, an unsupervised clustering algorithm is used to identify typical collision patterns and obtain an abstract scene classification. The abstract scene classification is parameterized to construct standardized logical scenes; The kinematics verification module is used to perform physical feasibility checks on the logical scenarios and classify risk levels to obtain a risk scenario library. A stratified sampling strategy is used to extract samples from the risk scenario library to generate an autonomous driving test case set.

2. The method as described in claim 1, characterized in that, The steps of preprocessing and extracting features from the unstructured text collision report to obtain a high-dimensional numerical feature vector include: The unstructured text collision reports are filtered to retain reports related to autonomous driving functions, resulting in multiple valid sub-reports, wherein the valid sub-reports are reports in English text; All English text in the effective sub-report is preprocessed to obtain the processed effective sub-report. The preprocessing includes converting all English text to lowercase and removing punctuation marks, non-informative characters, general stop words, and non-key information words specific to the autonomous driving field. The processed valid sub-reports are subjected to word frequency statistics to determine the frequency of occurrence of each word. The inverse document frequency of each term is calculated across all valid sub-reports. The weight of each term is obtained by multiplying its occurrence frequency by its inverse document frequency. Based on the weights, each processed valid sub-report is transformed to obtain a high-dimensional numerical feature vector.

3. The method as described in claim 1, characterized in that, The step of identifying typical collision patterns using an unsupervised clustering algorithm based on the high-dimensional numerical feature vector to obtain an abstract scene classification includes: The high-dimensional numerical feature vector is input into an unsupervised clustering algorithm to initialize the cluster centers; Calculate the distance from each of the high-dimensional numerical feature vectors to the corresponding cluster center, and assign each of the high-dimensional numerical feature vectors to the cluster to which the nearest cluster center belongs; The cluster centers of each cluster are updated based on the average value of all the high-dimensional numerical feature vectors within each cluster, and the change in the cluster centers is obtained. Repeat the operations of calculating distance, assigning clusters, and updating cluster centers until the change in the cluster centers is less than a preset change threshold or the preset number of iterations is reached to obtain preliminary clustering results; The preliminary clustering results are evaluated by combining the elbow rule and the silhouette coefficient to determine the optimal number of clusters; The high-dimensional numerical feature vectors are re-clustered based on the optimal number of clusters to obtain an abstract scene classification.

4. The method as described in claim 1, characterized in that, The step of parameterizing the abstract scene classification and constructing standardized logical scenes includes: For each scenario in the abstract scenario classification, the parameter type of each scenario is determined, wherein the parameter type includes road geometry parameters, traffic participant parameters, initial dynamic state parameters, and environmental condition parameters; From the valid sub-reports corresponding to each type of scenario in the abstract scenario classification, extract the specific parameter values ​​corresponding to each parameter type; The specific parameter values ​​are verified to obtain valid parameter values; The valid parameter values ​​are organized according to the preset standard format requirements to obtain the organized valid parameter values; Based on the compiled valid parameter values, construct standardized logical scenarios corresponding to each type of scenario.

5. The method as described in claim 1, characterized in that, The step of verifying the physical feasibility of the logical scenario and classifying its risk level using a kinematic verification module to obtain a risk scenario library further includes: Construct a vehicle kinematics model and a collision set, wherein the vehicle kinematics model includes the relative motion state equations of autonomous vehicles and human-driven vehicles, and the collision set is the set of states in which the physical boundaries of autonomous vehicles and human-driven vehicles overlap. The parameter values ​​in the logical scenario are input into the vehicle kinematics model for calculation to obtain the changes in the motion state of autonomous vehicles and human-driven vehicles within a preset time range. Based on the changes in motion state, a forward reachability tube is calculated, which represents the set of all states that the vehicle can reach within a preset time range from its initial state. Determine whether there is an intersection between the forward reachable tube and the collision set. If there is an intersection, determine that the logical scenario is physically feasible and calculate the risk quantification index. Based on the statistical distribution characteristics of the risk quantification index on the preset accident dataset and combined with the preset fractional position, the logical scenarios with physical feasibility are divided into high-risk scenarios, medium-risk scenarios and low-risk scenarios. The high-risk, medium-risk, and low-risk scenarios are summarized to form a risk scenario library.

6. The method as described in claim 5, characterized in that, The step of classifying physically feasible logical scenarios into high-risk, medium-risk, and low-risk scenarios based on the statistical distribution characteristics of the risk quantification index on a preset accident dataset and a preset fractional place includes: Obtain the risk quantification index values ​​corresponding to all logically feasible scenarios in the preset accident dataset; The risk quantification index values ​​are sorted and calculated to obtain the cumulative distribution function of the risk quantification index values; Based on the cumulative distribution function, a first quantile threshold and a second quantile threshold are determined, wherein the first quantile threshold is less than the second quantile threshold; When the value of the risk quantification index is less than the first quantile threshold, the corresponding logical scenario is classified as a high-risk scenario. When the risk quantification index value is greater than or equal to the first quantile threshold and the risk quantification index value is less than the second quantile threshold, the corresponding logical scenario is classified as a medium-risk scenario. When the risk quantification index value is greater than or equal to the second quantile threshold, the corresponding logical scenario is classified as a low-risk scenario.

7. The method as described in claim 1, characterized in that, The step of extracting samples from the risk scenario library using a stratified sampling strategy to generate an autonomous driving test case set includes: The first sample size, the second sample size, and the third sample size are calculated based on a preset sampling ratio, wherein the first sample size is drawn from high-risk scenarios, the second sample size is drawn from medium-risk scenarios, and the third sample size is drawn from low-risk scenarios. High-risk scenario samples are obtained by randomly selecting high-risk scenarios from the risk scenario library based on the first sample size; Based on the second sample size, medium-risk scenarios are randomly selected from the risk scenario library to obtain medium-risk scenario samples; Low-risk scenario samples are obtained by randomly selecting low-risk scenarios from the risk scenario library based on the third sample size. The high-risk, medium-risk, and low-risk scenario samples are integrated to generate an autonomous driving test case set.

8. An autonomous driving test scenario generation device based on text collision reports, characterized in that, The device includes: The acquisition module is used to acquire unstructured text collision reports; The feature extraction module is used to preprocess and extract features from the unstructured text collision report to obtain a high-dimensional numerical feature vector. The identification module is used to identify typical collision patterns based on the high-dimensional numerical feature vector using an unsupervised clustering algorithm to obtain an abstract scene classification. The processing module is used to perform parameterization processing on the abstract scene classification and construct standardized logical scenes; The construction module is used to perform physical feasibility verification of the logical scenario and classify the risk level through the kinematic verification module to obtain a risk scenario library; The results module is used to extract samples from the risk scenario library using a stratified sampling strategy to generate an autonomous driving test case set.

9. An autonomous driving test scenario generation device based on text collision reports, characterized in that, The device includes: a memory, a processor, and an autonomous driving test scenario generation program based on text collision reports stored in the memory and running on the processor, wherein the autonomous driving test scenario generation program based on text collision reports is configured to implement the steps of the autonomous driving test scenario generation method based on text collision reports as described in any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores an autonomous driving test scenario generation program based on text collision reports. When the autonomous driving test scenario generation program based on text collision reports is executed by the processor, it implements the steps of the autonomous driving test scenario generation method based on text collision reports as described in any one of claims 1-7.

Images