Test scene determination method and related device

Abstract

The invention discloses a method for determining a test scene and a related device, and aims to obtain a plurality of candidate scenes by combining element values of different scene elements so as to determine a potential scene which may occur but does not occur in a real road and improve the scene coverage rate. Thirdly, clustering a plurality of candidate scenes so as to cluster similar scenes into one scene cluster and cluster scenes with relatively large differences into different scene clusters; according to the method and the device, scene clusters are obtained, candidate scenes included in the scene clusters are sampled, target scenes as representatives are obtained, and test scenes are determined according to the target scenes corresponding to the multiple scene clusters respectively, so that the test scenes are prevented from including excessive similar scenes, and the problem of test scene redundancy is solved. In addition, due to the fact that sampling is conducted from all the scene clusters, the difference between all the scene clusters can be reserved, and therefore various driving scenes can be covered. On the basis, the scene coverage rate and the test efficiency can be considered, more comprehensive simulation test can be completed more quickly, and the simulation test effect is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and related apparatus for determining a test scenario. Background Technology

[0002] In practical applications, testing is typically required to ensure the driving safety of vehicles on real roads. For example, testing autonomous vehicles is conducted to ensure they can drive safely on real-world roads.

[0003] To improve testing efficiency, simulation testing is commonly used. This involves using computer simulation technology to control a vehicle (such as an autonomous vehicle) in a virtual test scenario to evaluate the safety of autonomous driving controls. Compared to real-world road testing, this method offers higher testing efficiency. The test scenario describes the vehicle's driving conditions on the road (such as road structure and environmental conditions). For example, a test scenario might describe "the vehicle traveling at a certain speed on a certain road for a certain duration, with a vehicle approaching from the front at a certain time," etc. Clearly, constructing test scenarios is crucial.

[0004] In related technologies, road data is acquired based on traffic records generated on actual roads. This road data can reflect the scenarios that vehicles may face in real-world applications, and therefore test scenarios can be constructed based on this data for simulation testing. However, the method of constructing test scenarios used in related technologies results in poor simulation test performance. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a method and related apparatus for determining test scenarios, which can balance scenario coverage and testing efficiency, facilitating faster and more comprehensive simulation testing and improving simulation testing effectiveness.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] On one hand, embodiments of this application provide a method for determining a test scenario, the method comprising:

[0008] Multiple scene elements are obtained, as well as the value range of each scene element. The multiple scene elements describe the driving scenario of the vehicle on the real road from different dimensions.

[0009] By combining the element values ​​of different scene elements, multiple candidate scenes are obtained, wherein the element values ​​of the scene elements are determined within the range of element values ​​of the scene elements;

[0010] Based on the element values ​​of the scene elements in each candidate scene, multiple candidate scenes are clustered to obtain multiple scene clusters. Candidate scenes in the same scene cluster satisfy the condition of similar values.

[0011] The candidate scenes included in the scene cluster are sampled to obtain the target scene corresponding to the scene cluster;

[0012] A test scenario is determined based on the target scenarios corresponding to the multiple scenario clusters, and the test scenario is used to conduct simulation tests on the vehicle.

[0013] In another aspect, embodiments of this application provide a device for determining a test scenario, the device comprising an acquisition unit, a combination unit, a clustering unit, a sampling unit, and a determination unit:

[0014] The acquisition unit is used to acquire multiple scene elements and acquire the value range of each of the multiple scene elements. The multiple scene elements describe the driving scenario of the vehicle on the real road from different dimensions.

[0015] The combination unit is used to combine the element values ​​of different scene elements to obtain multiple candidate scenes, wherein the element values ​​of the scene elements are determined within the range of element values ​​of the scene elements.

[0016] The clustering unit is used to cluster multiple candidate scenes according to the element values ​​of scene elements in each candidate scene to obtain multiple scene clusters, and candidate scenes in the same scene cluster satisfy the condition of similar values.

[0017] The sampling unit is used to sample the candidate scenes included in the scene cluster to obtain the target scene corresponding to the scene cluster;

[0018] The determining unit is used to determine a test scenario based on the target scenarios corresponding to the multiple scene clusters, and the test scenario is used to perform simulation testing on the vehicle.

[0019] On the other hand, embodiments of this application provide a computer device, the computer device including a processor and a memory:

[0020] The memory is used to store computer programs and to transfer the computer programs to the processor;

[0021] The processor is configured to execute the method described in any of the foregoing aspects according to instructions in the computer program.

[0022] On the other hand, embodiments of this application provide a computer-readable storage medium for storing a computer program, which, when run by a computer device, causes the computer device to perform the methods described in any of the foregoing aspects.

[0023] On the other hand, embodiments of this application provide a computer program product, including a computer program that, when run on a computer device, causes the computer device to perform the methods described in any of the foregoing aspects.

[0024] As can be seen from the above technical solution, multiple candidate scenarios are obtained by combining the element values ​​of different scenario elements. Since real road data reflects driving scenarios that have already occurred, the actual values ​​of each scenario element are predetermined. In the combination method, the range of element values ​​indicates the possible values ​​of scenario elements in a driving scenario. Therefore, the combination of element values ​​is not limited by the already occurred driving scenarios. Thus, combination is beneficial for identifying potential scenarios that may occur but have not yet occurred on real roads, resulting in higher scenario coverage. For the multiple candidate scenarios obtained through combination, the element values ​​of the scenario elements in each candidate scenario reflect what kind of driving scenario the candidate scenario indicates. Therefore, clustering multiple candidate scenarios based on the element values ​​of scenario elements can group similar scenarios into one scenario cluster and scenarios with significant differences into different scenario clusters. Next, the candidate scenarios included in the scenario clusters are sampled to obtain representative target scenarios. Test scenarios are then determined based on the target scenarios corresponding to the multiple scenario clusters, and these test scenarios are used for vehicle simulation testing. As can be seen, for the multiple candidate scenarios combined, clustering them into scenario clusters first, and then sampling from each scenario cluster separately, avoids including too many similar scenarios in the test scenario, solves the problem of test scenario redundancy, helps reduce duplicate testing, and improves testing efficiency. Furthermore, because sampling is done separately from each scenario cluster, the final test scenario can retain the differences between the clusters, thus covering a wide variety of driving scenarios and achieving more comprehensive simulation testing. Based on this, it is possible to balance scenario coverage and testing efficiency, which is conducive to completing more comprehensive simulation testing faster and improving simulation testing results. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1A schematic diagram illustrating an application scenario of a method for determining a test scenario provided in an embodiment of this application;

[0027] Figure 2 A flowchart illustrating a method for determining a test scenario provided in an embodiment of this application;

[0028] Figure 3 A schematic diagram of a driving scenario definition model provided in an embodiment of this application;

[0029] Figure 4 An abstract hierarchical diagram of a driving scenario is provided for an embodiment of this application;

[0030] Figure 5 A schematic diagram illustrating the determination of candidate scenarios provided in an embodiment of this application;

[0031] Figure 6 A schematic diagram of the results of principal component analysis provided in an embodiment of this application;

[0032] Figure 7 This is a schematic diagram of a clustering result provided in an embodiment of this application;

[0033] Figure 8 A schematic diagram of a framework for determining a test scenario provided in an embodiment of this application;

[0034] Figure 9 A structural diagram of a test scenario determination device provided in an embodiment of this application;

[0035] Figure 10 A structural diagram of a terminal provided in an embodiment of this application;

[0036] Figure 11 This is a structural diagram of a server provided in an embodiment of this application. Detailed Implementation

[0037] The embodiments of this application will now be described with reference to the accompanying drawings.

[0038] In simulation testing, constructing test scenarios is crucial. Some related technologies build test scenarios based on road data. However, since road data originates from real-world vehicle driving data, it cannot reflect driving scenarios that might occur on real roads but have not yet occurred. Therefore, road data cannot construct potential scenarios that may occur but have not yet happened on real roads, resulting in low scenario coverage and incomplete simulation testing. Furthermore, this approach requires a significant time investment to collect diverse road types, weather conditions, and accident scenarios to determine the richness of the road data, leading to excessive time costs.

[0039] To address this, this application provides a method and related apparatus for determining test scenarios. By combining the values ​​of different scenario elements, multiple candidate scenarios are obtained. These different scenario elements describe driving scenarios of a vehicle on real roads from different dimensions. In this combination method, the range of element values ​​indicates the possible values ​​of the scenario elements in a driving scenario. Therefore, the combination of element values ​​is not limited by already occurred driving scenarios. Thus, by combining these elements, potential scenarios that may occur but have not yet occurred on real roads can be identified, resulting in higher scenario coverage.

[0040] Simultaneously, for the multiple candidate scenarios generated, clustering is first performed to group similar scenarios into one cluster and scenarios with significant differences into different clusters. Then, representative target scenarios are sampled from each cluster, and test scenarios are determined based on the target scenarios corresponding to each cluster. This avoids including too many similar scenarios in the test scenarios, solves the problem of test scenario redundancy, reduces redundant testing, and improves testing efficiency. Because sampling is performed separately from each scenario cluster, the final test scenarios retain the differences between each cluster, thus covering a wide variety of driving scenarios and achieving more comprehensive simulation testing.

[0041] As can be seen, compared with related technologies, this application can improve scenario coverage while taking into account testing efficiency, which is conducive to completing more comprehensive simulation tests faster and improving simulation test results. Furthermore, by combining different scenarios, various possible driving scenarios can be constructed without relying on road data, thus eliminating the need for excessively long sampling times for traffic data under different conditions and reducing time costs.

[0042] The method for determining the test scenario provided in this application can be implemented using a computer device, which can be a terminal or a server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Terminals include, but are not limited to, smartphones, computers, smart voice interaction devices, smart home appliances, and in-vehicle terminals. Terminals and servers can be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitations on this connection.

[0043] The embodiments of this application can be specifically applied to various simulation tests that require the construction of test scenarios. For example, when simulating autonomous driving technology, the embodiments of this application can be used to construct test scenarios. Similarly, when simulating new vehicles, the embodiments of this application can be used to construct test scenarios.

[0044] It should be noted that in the specific implementation of this application, the determination of the test scenario may involve user information and other related data. When the above embodiments of this application are applied to specific products or technologies, separate consent or permission from the user is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0045] Figure 1 This illustration shows an application scenario of the test scenario determination method provided in the embodiments of this application. Figure 1 In the scenario shown, server 100 is used as an example of the aforementioned computer device for illustration:

[0046] First, server 100 can obtain multiple scene elements and the value ranges corresponding to each scene element. These scene elements describe the driving scenario of a vehicle on a real road from different dimensions, and the value range for each scene element can be used to indicate the possible values ​​of that scene element in the driving scenario. Figure 1 In the example, multiple scene elements may include scene element 1, scene element 2, ...

[0047] Next, server 100 can combine the element values ​​of different scene elements to obtain multiple candidate scenes. Figure 1 In the example, candidate scenarios 1, 2, 3, 4, 5, and 6 can be obtained by combining them. Each candidate scenario can indicate a possible driving scenario. Specifically, the value of the scenario element in each candidate scenario reflects the driving scenario indicated by that candidate scenario. Furthermore, different candidate scenarios include at least one scenario element with a different value. For example, in candidate scenario 1, the value of scenario element 1 is a1, and in candidate scenario 2, the value of scenario element 1 is a2 (a2 is different from a1).

[0048] Because the combination of element values ​​involves combining possible values ​​and is not limited by actual driving scenarios, it can identify potential scenarios that may occur but have not yet occurred on real roads. Compared to related technologies that construct test scenarios based on real road data, the multiple candidate scenarios generated by this combination can cover a wider variety of driving scenarios and have a higher scenario coverage rate.

[0049] Because the element values ​​of the scene elements in each candidate scene can reflect the driving scenario indicated by that candidate scene, the server 100 can cluster multiple candidate scenes based on the element values ​​of the scene elements in each candidate scene, so as to group similar scenes into one scene cluster and scenes with large differences into different scene clusters. For Figure 1 The six candidate scenes in the example can be clustered into scene cluster 1 and scene cluster 2. Scene cluster 1 can include candidate scene 1, candidate scene 5, and candidate scene 6, and scene cluster 2 can include candidate scene 2, candidate scene 3, and candidate scene 4. It should be noted that this is only an example and is not intended to impose any limitations.

[0050] Candidate scenes within the same scene cluster satisfy a similarity condition, meaning they are more similar and reflect more similar driving scenarios. Conversely, candidate scenes in different scene clusters are more differentiated and reflect more different driving scenarios. Therefore, after clustering, samples can be taken from each scene cluster to obtain target scenes representing the entire cluster, avoiding the inclusion of too many similar scenes in the test scenarios. Figure 1 In the example, server 100 samples scene cluster 1 to obtain target scene 1, and samples scene cluster 2 to obtain target scene 2.

[0051] Finally, server 100 can determine the test scenario based on target scenario 1 and target scenario 2, and the test scenario can be used to conduct simulation tests on the vehicle.

[0052] As can be seen, for the multiple candidate scenarios combined, clustering them into scenario clusters first, and then sampling from each scenario cluster separately, avoids including too many similar scenarios in the test scenario, solves the problem of test scenario redundancy, helps reduce duplicate testing, and improves testing efficiency. Furthermore, because sampling is done separately from each scenario cluster, the final test scenario retains the differences between the clusters, thus covering a wide variety of driving scenarios and achieving more comprehensive simulation testing. Based on this, it can balance scenario coverage and testing efficiency, facilitating faster and more comprehensive simulation testing and improving simulation testing results.

[0053] Figure 2 A flowchart illustrating a method for determining a test scenario provided in this application embodiment, using a server as an example of the aforementioned computer device, the method includes S201-S205:

[0054] S201: Get multiple scene elements, and get the value range of each scene element.

[0055] The multiple scene elements describe the driving scenario of the vehicle on real roads from different dimensions, and the value range of each scene element can be used to indicate the possible values ​​of that scene element in the driving scenario. It should be noted that this application does not limit the method of determining the scene elements and their value ranges; for details, please refer to the detailed description of the subsequent embodiments, which will not be repeated here.

[0056] S202: Combine the element values ​​of different scene elements to obtain multiple candidate scenes.

[0057] In practical applications, a specific driving scenario can be modeled as a combination of multiple scenario elements. For example, the driving scenario "the main vehicle travels on road xx at speed xx for xx hours, and a vehicle approaches from the front at time xx" can be modeled as a combination of the following scenario elements: "the main vehicle's driving road is road xx, its driving speed is speed xx, its driving time is xx hours, and the time the vehicle approaches from the front is time xx". Therefore, test scenarios reflecting driving scenarios can be constructed by combining the values ​​of different scenario elements. In this application, the server can combine the values ​​of different scenario elements to obtain multiple candidate scenarios. The values ​​of the scenario elements are determined within the range of possible values ​​for each scenario element.

[0058] In real-world driving scenarios, the values ​​of each scenario element are predetermined. However, the combination method is not limited by the actual driving scenario; as long as the values ​​of each scenario element are within their respective ranges, it is acceptable. Therefore, potential scenarios that may occur but have not yet actually occurred can be identified. For example, in a real-world driving scenario, there is no situation where scenario element 1 has the value a1 and scenario element 2 has the value b1. These situations, which do not exist in a real-world driving scenario, simply haven't occurred yet. Since scenario element 1 may have the value a1 and scenario element 2 may have the value b1 in a driving scenario, the combination of a1 and b1 is likely to occur on a real road. By implementing S202, this combination can be identified, meaning that among the aforementioned candidate scenarios, there exists a situation where scenario element 1 has the value a1 and scenario element 2 has the value b1.

[0059] It is evident that by combining unknown values ​​of multiple scene elements, potential scenarios that may occur but have not yet occurred on real roads can be constructed. Therefore, the resulting candidate scenarios can cover a wider variety of driving scenarios, resulting in higher scenario coverage. Based on this, determining the test scenarios and conducting simulation tests helps improve the comprehensiveness of the simulation tests and achieve better simulation test results.

[0060] It should be noted that this application does not impose any limitations on the method of combination. For ease of understanding, the following embodiments are provided as examples:

[0061] Understandably, the more scene elements a candidate scene contains, the more concretely it describes a possible driving scenario. Therefore, in one possible implementation, multiple scene elements can be combined so that each candidate scene includes all of these elements. Based on this, each candidate scene effectively describes various possible driving scenarios. Furthermore, since multiple candidate scenes describe various possible driving scenarios at the same granularity, it is more beneficial to accurately evaluate the similarity between candidate scenes during subsequent clustering.

[0062] In practical applications, to avoid scene redundancy, in the multiple candidate scenes obtained by combination, any two candidate scenes include at least one scene element with different element values, that is, there will be no duplicate scenes in the multiple candidate scenes, thus avoiding scene redundancy.

[0063] S203: Based on the element values ​​of the scene elements in each candidate scene, cluster multiple candidate scenes to obtain multiple scene clusters.

[0064] Because the values ​​of scene elements in each candidate scene reflect the driving scenario indicated by that candidate scene, the server clusters multiple candidate scenes based on the values ​​of the scene elements in each candidate scene. This clustering groups similar scenes into one scene cluster and significantly different scenes into different scene clusters, resulting in multiple scene clusters. Candidate scenes within the same scene cluster satisfy the condition of similar values; that is, candidate scenes within the same scene cluster are more similar and reflect more similar driving scenarios. Conversely, candidate scenes in different scene clusters are more differentiated and reflect more different driving scenarios.

[0065] The similarity condition can be used to indicate that the similarity between the values ​​of scene elements in a candidate scene meets a preset requirement. It should be noted that this application embodiment does not impose any limitations on the setting of the similarity condition. In practical applications, different clustering methods will lead to different methods of evaluating the similarity between candidate scenes, resulting in different similarity conditions and potentially different final clusters of scenes. Therefore, in one possible implementation, the appropriate similarity condition can be flexibly set according to the actual situation of the clustering method used to better perform clustering.

[0066] S204: Sample the candidate scenes included in the scene cluster to obtain the target scene corresponding to the scene cluster.

[0067] It is understandable that similar scenarios reflect similar driving scenarios. Usually, the results of simulation tests using similar scenarios are not significantly different. Therefore, using similar scenarios for simulation tests is difficult to meet the needs of simulating a wide variety of driving scenarios and will also cause unnecessary waste of computing resources.

[0068] In this application, because clustering is performed, candidate scenarios within the same scene cluster satisfy the condition of value similarity. That is, candidate scenarios within the same scene cluster are similar, and the driving scenarios they reflect are also quite similar. Therefore, sampling can be performed from each scene cluster to avoid including too many similar scenarios in the final test scenario, thus solving the problem of test scenario redundancy, reducing the waste of computing resources, and improving testing efficiency.

[0069] In practice, the server can sample candidate scenes included in a scene cluster to obtain the target scene corresponding to the scene cluster. This target scene can serve as a representative scene for the entire scene cluster. For each scene cluster among multiple scene clusters, the target scene corresponding to each scene cluster can be determined by executing S204.

[0070] S205: Determine the test scenario based on the target scenarios corresponding to multiple scenario clusters.

[0071] Correspondingly, the server can determine the test scenario based on the target scenarios corresponding to multiple scenario clusters, and the test scenario can be used to conduct simulation tests on vehicles.

[0072] It should be noted that this application does not impose any limitations on how to determine the test scenario. For ease of understanding, the following methods are provided as examples in the embodiments of this application:

[0073] Because sampling is performed separately from each scene cluster, the differences between the target scenes corresponding to different scene clusters are still preserved. This allows the target scenes corresponding to multiple scene clusters to effectively cover a wide variety of driving scenarios, such as driving scenarios with different functional defects and dangerous situations. Therefore, in one possible implementation, the target scenes corresponding to multiple scene clusters can be directly determined as test scenarios. Based on this, while considering scene coverage, it is beneficial to complete more comprehensive simulation tests and obtain better simulation test results.

[0074] As can be seen from the above technical solution, multiple candidate scenarios are obtained by combining the element values ​​of different scenario elements. Since real road data reflects driving scenarios that have already occurred, the actual values ​​of each scenario element are predetermined. In the combination method, the range of element values ​​indicates the possible values ​​of scenario elements in a driving scenario. Therefore, the combination of element values ​​is not limited by the already occurred driving scenarios. Thus, combination is beneficial for identifying potential scenarios that may occur but have not yet occurred on real roads, resulting in higher scenario coverage. For the multiple candidate scenarios obtained through combination, the element values ​​of the scenario elements in each candidate scenario reflect what kind of driving scenario the candidate scenario indicates. Therefore, clustering multiple candidate scenarios based on the element values ​​of scenario elements can group similar scenarios into one scenario cluster and scenarios with significant differences into different scenario clusters. Next, the candidate scenarios included in the scenario clusters are sampled to obtain representative target scenarios. Test scenarios are then determined based on the target scenarios corresponding to the multiple scenario clusters, and these test scenarios are used for vehicle simulation testing. As can be seen, for the multiple candidate scenarios combined, clustering them into scenario clusters first, and then sampling from each scenario cluster separately, avoids including too many similar scenarios in the test scenario, solves the problem of test scenario redundancy, helps reduce duplicate testing, and improves testing efficiency. Furthermore, because sampling is done separately from each scenario cluster, the final test scenario can retain the differences between the clusters, thus covering a wide variety of driving scenarios and achieving more comprehensive simulation testing. Based on this, it is possible to balance scenario coverage and testing efficiency, which is conducive to completing more comprehensive simulation testing faster and improving simulation testing results.

[0075] The above embodiments illustrate the method for determining test scenarios provided in this application. It should also be noted that this application does not impose any limitations on the methods for obtaining multiple scene elements and their value ranges, the methods for clustering multiple candidate scenes, or the methods for sampling. For ease of understanding, this application will provide examples and illustrations through the following embodiments:

[0076] (I) Regarding how to obtain multiple scene elements and their value ranges, this application provides the following method as an example:

[0077] It is understandable that the process of a vehicle driving on a road can be considered as an interaction with other elements in the driving environment within a certain spatiotemporal range. Therefore, in one possible implementation, these elements can be used to describe the vehicle's driving scenario, and specific scenario elements can be determined from these elements.

[0078] In practical applications, the driving scenario definition model defines various elements in the driving environment, such as road layer elements, traffic participant layer elements, environmental layer elements, traffic infrastructure layer elements, temporary road facility layer elements, and communication signal layer elements. Therefore, in one possible implementation, specific scenario elements can be determined based on these layers. For easier understanding, please refer to... Figure 3 The diagram shown is a schematic of a driving scenario definition model, specifically:

[0079] Road layer elements can be used to identify road-related scene elements, such as road type (e.g., highway), lane width, number of lanes, lane speed limit, road geometry, and road boundary range. Traffic participant layer elements can be used to identify scene elements related to traffic participants, such as participant type (e.g., people, vehicles), speed, behavior, relative distance to the main vehicle, and relative direction. Environment layer elements can be used to identify scene elements related to the event, such as weather (e.g., sunny, rainy, foggy, snowy) and time (e.g., daytime, nighttime). Traffic infrastructure layer elements can be used to identify scene elements related to conventional traffic facilities on the road, such as traffic signal facilities (e.g., traffic lights) and road signs. Temporary road facility layer elements can be used to identify scene elements related to temporary traffic facilities on the road, such as construction barriers and traffic cones. Finally, communication signal layer elements can be used to identify scene elements related to digital signals on the road, such as communication information and electronic maps.

[0080] Understandably, the temporary road infrastructure layer consists of temporary facilities on the road, which are not typically installed on roads. Therefore, to simplify testing, this layer can be disregarded. Similarly, the communication signal layer relies on the construction of communication equipment on the road and is not involved in all driving scenarios. Thus, to simplify testing, this layer can also be disregarded.

[0081] Furthermore, in practical applications, the driving scenarios of a vehicle can be described in a progressively more detailed manner, moving from abstract to concrete. Therefore, in another possible implementation, the aforementioned multiple scenario elements can also be determined based on this approach. For ease of understanding, embodiments of this application provide, as follows: Figure 4 The diagram shown is an abstract hierarchical representation of a driving scenario. Specifically:

[0082] First, the functional scenario is at the top level and is used to describe the main functions or tasks that need to be performed. For example, the functional scenario could be "autonomous driving on the highway" or "parking in an urban environment".

[0083] Secondly, logical scenarios are located at the next level below functional scenarios and are used to describe the specific operations and conditions within a functional scenario. Specifically, they can be further refined into a list of parameters describing the scenario, such as road-related parameters (e.g., lane width, lane speed limit), traffic participant-related parameters (e.g., relative distance, avoidance time point), and the vehicle's speed. For example, for the functional scenario of "autonomous driving on a highway," the parameter list could include highway lane width, lane speed limit, etc., and a corresponding logical scenario could be "driving at 120 km / h on a four-lane highway in clear weather."

[0084] Finally, the specific scenario is the next level below the logical scenario, used to describe the details of a specific driving situation within the logical scenario. It usually includes information such as the specific geographical location and traffic participants. For example, for the logical scenario of "driving at 120 km / h on a four-lane highway in clear weather," a specific scenario could be "While driving at 120 km / h on a four-lane highway in clear weather, there is a truck traveling at 80 km / h three meters ahead, and there is an emergency stopping lane on the right side of the road."

[0085] As can be seen, the description of driving scenarios becomes increasingly specific, progressing from functional scenarios to logical scenarios and then to specific scenarios. Since logical scenarios refine the parameter list describing the scenario, multiple scenario elements can be directly extracted from this list. For example, road-related parameters (such as lane width and speed limits) can be directly used as scenario elements. Furthermore, because specific parameter values ​​are already defined in specific scenarios, the process from logical scenario to specific scenario can be considered a scenario instantiation process. This involves combining the values ​​of various scenario elements to obtain a specific scenario, which is the aforementioned candidate scenario.

[0086] The above embodiments illustrate the methods for determining scene elements. The value range for each scene element can be determined based on actual conditions. In practical applications, the value range of scene elements can be determined by sampling and analyzing the probability distribution of their values ​​in actual traffic data. For example, for the scene element of lane width, the value range corresponding to lane width can be determined based on sampling lane widths in real roads. For the scene element of vehicle speed, the maximum speed of the vehicle can be determined based on its configuration, thus determining its corresponding value range. As another example, for the vehicle speed on a highway, by analyzing the probability distribution of speed values ​​in actual traffic data, it is found that vehicle speeds on highways are mainly distributed between 70 km / h and 100 km / h; therefore, the value range of the scene element of vehicle speed can be determined to be 70 to 100 km / h.

[0087] It should also be noted that the values ​​of scene elements can be continuous or discrete within their corresponding value ranges. For example, vehicle speed can be continuous within its value range, while scene elements that distinguish categories, such as road type and traffic participant type, can be discrete within their value range. In practical applications, to ensure scene coverage, if the element values ​​are continuous during the combination process, the value of the scene element can be determined at equal intervals within its value range to participate in subsequent combinations, thereby ensuring that the scene space is evenly covered, which is beneficial for ensuring scene coverage. For example, the value range of the scene element "vehicle speed" is 70 to 100 km / h. During combination, a value can be taken at intervals of 5, that is, the vehicle speed can be any one of 70, 75, 80, 85, 90, 95, and 100.

[0088] For ease of understanding, Table 1 in this application provides illustrative examples of scene elements and their value ranges:

[0089] Table 1. Examples of scene elements and their value ranges

[0090] Scene elements Element value range Road type Highways, urban roads, rural roads Number of lanes One lane, two lanes, three lanes, four lanes lane width 2 meters to 4 meters The speed of the main vehicle 0 km / h to 120 km / h Types of traffic participants People and vehicles weather Sunny day, rainy day, foggy day, snowy day time Day and night …… ……

[0091] It should be noted that Table 1 is merely an example and does not impose any limitations. Furthermore, the value range for lane width may differ on different roads, and the value range for vehicle speed may also vary depending on the vehicle model. These can all be determined based on the actual situation.

[0092] For ease of understanding, embodiments of this application also provide, as follows: Figure 5 The diagram shown illustrates a method for determining candidate scenes. Figure 5In the example, scene elements may include lane width (denoted as 'a', with a value range of {a-min, a-max}), lane speed limit (denoted as 'b', with a value range of {b-min, b-max}), vehicle speed (denoted as 'c', with a value range of {c-min, c-max}), relative distance (denoted as 'd', with a value range of {d-min, d-max}), and avoidance time point (denoted as 'e', ​​with a value range of {e-min, e-max}). Within their respective value ranges, element values ​​are combined to obtain candidate scene 1, candidate scene 2, and candidate scene 3. For example, 'a-min' can be 2 meters as shown in Table 1, and 'a-max' can be 4 meters as shown in Table 1.

[0093] In candidate scenario 1, each scenario element can have values ​​of {a1, b1, c1, d1, e1}, which can be used to indicate "On a highway with a lane width of a1 meters and a lane speed limit of b1 km / h, the main vehicle is traveling at c1 km / h, and there is a truck traveling at a distance of d1 meters ahead. It is expected to avoid the truck in e1 seconds." Similarly, in candidate scenario 2, each scenario element can have values ​​of {a2, b2, c2, d2, e2}, which can be used to indicate "On a highway with a lane width of a2 meters and a lane speed limit of b2 km / h, the main vehicle is traveling at c2 km / h, and there is a truck traveling at a distance of d2 meters ahead. It is expected to avoid the truck in e2 seconds." Furthermore, the element values ​​of each scene element in candidate scene 3 can be {a3, b3, c3, d3, e3}, which can be used to indicate "On a highway with a lane width of a3 meters and a lane speed limit of b3 km / h, the main vehicle is traveling at c3 km / h, and there is a truck traveling at a distance of d3 meters ahead, and it is expected to avoid it in e3 seconds".

[0094] It should be noted that, Figure 5 This is merely an example and does not constitute any limitation. In practical applications, other candidate scenarios can be combined. For ease of understanding, Table 2 provides further examples of multiple candidate scenarios in this application embodiment:

[0095] Table 2. Examples of Multiple Candidate Scenarios

[0096]

[0097] In Table 2, each row can represent a candidate scenario. It should be noted that Table 2 is merely an example and does not impose any limitations. It is understandable that in practical applications, more scenario element columns and candidate scenarios formed by richer combinations of element values ​​can be included.

[0098] (II) Regarding how to cluster multiple candidate scenarios, the embodiments of this application provide the following methods as examples:

[0099] (1) First, from the perspective of clustering method selection, the following example illustrates how to cluster multiple candidate scenarios:

[0100] Understandably, elements in similar scenes tend to have similar values. Therefore, in one possible implementation, the server can determine the position of sample points in the feature space to identify candidate scenes based on the element values ​​of scene elements in the candidate scenes. Based on this, multiple candidate scenes are first mapped to the same feature space, and the similarity between the element values ​​in each candidate scene can be directly reflected by the positions corresponding to the multiple sample points. Accordingly, the server can perform density clustering on the multiple sample points based on their respective positions to obtain multiple scene clusters.

[0101] As can be seen, the proximity of element values ​​can be directly reflected by the location distribution. Density clustering focuses more on location density, dividing sample points within sufficiently dense areas into clusters, ensuring that densely distributed data can be clustered, thus yielding a richer variety of clusters. For example, even within a small area with only a few sample points, if these points are densely distributed, they can still be clustered. Based on this, the resulting scene clusters can more comprehensively and granularly represent various driving scenarios, thereby facilitating the identification of richer test scenarios and achieving generalization of test scenarios.

[0102] Corresponding to density clustering, sample points within the same scene cluster satisfy a density connectivity condition in the feature space. This condition indicates whether the locations of sample points within a scene cluster are densely distributed. Specifically, if the density connectivity condition is satisfied, the locations are considered densely distributed, meaning the candidate scenes identified by these sample points are similar and can be grouped into one cluster. Conversely, if the density connectivity condition is not satisfied, the locations are considered dispersed, indicating that the candidate scenes identified by these sample points are more differentiated and will not be grouped into one cluster.

[0103] It should be noted that this application does not impose any limitations on the setting of density connectivity conditions. In practical applications, when different density clustering methods are used, the principles for dividing multiple sample points into multiple scene clusters based on their respective locations will differ, and the corresponding density connectivity conditions may also differ. Therefore, in one possible implementation, density connectivity conditions can be flexibly set according to the specific density clustering method used to better perform density clustering and obtain more accurate multiple scene clusters.

[0104] It should also be noted that this application does not impose any limitations on the density clustering method. In practical applications, a more suitable density clustering method for the current multiple sample points can be flexibly selected based on factors such as the number of sample points. To further understand, this application provides an example illustration of a density clustering method through the following embodiments:

[0105] In one possible implementation, the server can obtain a radius parameter and a neighborhood density threshold, and perform density clustering on multiple sample points according to the radius parameter, the neighborhood density threshold, and the positions corresponding to the multiple sample points, to obtain multiple scene clusters. During density clustering, if the number of sample points included in the neighborhood of a sample point is greater than or equal to the neighborhood density threshold, then the sample point is a core point. The neighborhood of a sample point indicates the region in the feature space centered on the sample point's position, determined based on the radius parameter. Furthermore, each scene cluster includes at least one core point and non-core points located within the neighborhood of the core point. The number of sample points included in the neighborhood of a non-core point is less than the neighborhood density threshold.

[0106] Based on this, density clustering is achieved by setting a radius parameter and a neighborhood density threshold as parameters. Then, the number of neighboring sample points determines whether a sample point is a core point, making density clustering simpler and easier to implement. In practice, sample points falling within the neighborhood of a core point are considered density-reachable from that core point, and the positions of two density-reachable sample points satisfy the density connectivity condition. For example, common density clustering methods based on radius parameters and neighborhood density thresholds include density-based clustering of applications with noise (DBSCAN).

[0107] Among them, the radius parameter and neighborhood density threshold, as parameters of density clustering, directly affect the final clustering result. Specifically, the size of the radius parameter affects the size of the neighborhood of a sample point, thus affecting the number of sample points within that neighborhood, and consequently, whether that sample point can be used as a core point. Similarly, the neighborhood density threshold also directly affects whether a sample point can be used as a core point. If the number of core points is too small, the number of clusters will be too small, resulting in insufficient differences between clusters; conversely, if the number of core points is too large, the number of clusters may be too large, resulting in excessive differences between clusters. Understandably, a reasonable radius parameter and neighborhood density threshold are more conducive to avoiding insufficient or excessive differences between clusters, thereby obtaining more accurate multi-scene clusters.

[0108] This application does not impose any limitations on how to obtain the radius parameter and the neighborhood density threshold. For ease of understanding, the following embodiments are provided as examples:

[0109] Since the position of a sample point in the feature space is constrained by the values ​​of scene elements in the candidate scenes, and the differences between the values ​​of scene elements in multiple candidate scenes affect the dispersion of the sample points in the feature space, as does the number of scene elements, which in turn affects the complexity of the feature space and thus the dispersion of the sample points, one possible implementation is to determine the radius parameter and the neighborhood density threshold based on the differences between the values ​​of scene elements in multiple candidate scenes and the number of scene elements. Based on this, the radius parameter and neighborhood density threshold can be flexibly set according to the actual situation and the degree of dispersion, which is beneficial for forming more reasonable scene clusters and avoiding too many or too few clusters.

[0110] For example, if the number of scene elements is one, the feature space can be a one-dimensional space; if the number of scene elements is two, the feature space can be a two-dimensional space. Since the location dispersion of sample points is also higher in a higher-dimensional feature space, a larger radius parameter and neighborhood density threshold can be set.

[0111] (2) Secondly, from the perspective of processing the clustered objects (i.e., multiple candidate scenarios), the following example illustrates how to cluster multiple candidate scenarios:

[0112] Clustering is based on the values ​​of scene elements in each candidate scene. The number of scene elements affects the computational cost of the clustering process. Therefore, we can start from the level of the objects to be clustered (i.e., multiple candidate scenes), process multiple candidate scenes first, and then perform clustering based on the processed results, in order to reduce the computational cost of the clustering process. For ease of understanding, the embodiments of this application provide the following methods as examples.

[0113] Typically, different tests have different test objectives, and the data analyzed to achieve those objectives may differ. Therefore, one possible approach is to process candidate scenarios in conjunction with the vehicle-specific test objectives, and then perform clustering to obtain multiple scenario clusters that better fit the test objectives.

[0114] That is, in the specific implementation of the aforementioned S203, the server can first obtain the test target for the vehicle, which can be used to indicate the target to be completed for testing the vehicle based on the test scenario. Next, it can filter the scene elements related to completing the test target from multiple scene elements, and then cluster the multiple candidate scenes according to the element values ​​corresponding to the scene elements related to completing the test target in the candidate scenes to obtain multiple scene clusters.

[0115] As can be seen, selecting scene elements relevant to the testing objective for subsequent clustering, while excluding those irrelevant, helps reduce the computational load of the clustering process. Thus, by simply filtering out scene elements unrelated to the testing objective, computational costs are reduced without affecting testing results.

[0116] Typically, the test objectives may differ across different tests. This application, however, utilizes a richer and more comprehensive set of scenario elements to construct a candidate scenario, making it more closely aligned with potential driving scenarios. This ensures the candidate scenario construction is applicable to various tests, resulting in higher versatility. In subsequent processing, it can differentiate between the specific test objectives of different tests, selecting scenario elements relevant to those objectives for further processing to reduce computational load. Simultaneously, it ensures that the final clusters of multiple scenarios can still construct the test scenarios required to achieve the test objectives. Therefore, it balances computational load with the practical needs of test scenario construction.

[0117] For example, if the test objective is for the lead vehicle (e.g., an autonomous vehicle) to decelerate in time to avoid a collision when the vehicle in front slows down, then for any model of lead vehicle, the deceleration conditions to avoid a collision need to be tested. Therefore, the model of the lead vehicle can be considered an irrelevant element to this test objective, while the lead vehicle's speed and the distance between the lead vehicle and the vehicle in front are relevant elements. Of course, in some other test objectives, the model of the lead vehicle may be a relevant element; this should be determined based on the specific test objective. Furthermore, in some test objectives, it is necessary to test the collision conditions of the vehicle. In such cases, scenarios where a collision will definitely not occur are irrelevant to the test objective. Examples include situations where the relative distance and relative speed between the lead vehicle and other road users are too large to cause a collision, or situations where the lead vehicle and other road users have no intersection in their driving directions and neither changes lanes during their journey, thus preventing a collision.

[0118] In practical implementation, correlation analysis can be used to determine whether something is relevant to the test objective. For example, based on this, it can be determined that road-related elements such as road type, lane width, number of lanes, and lane speed limit at the road layer, weather and time at the environment layer, speed, behavior, relative distance, and relative direction of traffic participants at the traffic participant layer, and the speed, behavior, relative distance, and relative direction of the main vehicle are all relevant to the test objective.

[0119] Furthermore, scene elements that need to participate in subsequent processing can be selected based on the actual situation described and defined in the scene description. For example, in a scenario where the preceding vehicle cuts in or out, the scene description and definition focus on the timing of the preceding vehicle's entry and exit; therefore, this scene element can be considered a key scene element and participate in subsequent processing. Similarly, in a scenario where obstacle avoidance is required, the scene description and definition focus on the obstacle situation in the driver's vision; therefore, the visual obstacle scene element can be considered a key scene element and participate in subsequent processing.

[0120] Typically, there are a large number of scene elements, allowing for a richer description of candidate scenes and making them more concretely represent a possible driving scenario. To reduce computational load, another possible implementation is to use principal component analysis (PCA) to select principal components and then utilize them in subsequent processing. This reduces the dimensionality of multiple scene elements, thus decreasing the computational cost of subsequent clustering.

[0121] That is, in specific implementation of the aforementioned S203, the server can perform principal component analysis on multiple scene elements based on the element values ​​of the scene elements included in multiple candidate scenes, to obtain principal components describing the candidate scenes, and to obtain the features corresponding to the candidate scenes under the principal components. Then, the server can cluster the multiple candidate scenes based on the features corresponding to each candidate scene under the principal components, to obtain multiple scene clusters. The number of principal components is less than the number of scene elements.

[0122] As can be seen, after determining the principal components, the features corresponding to the candidate scenes under the principal components are used in subsequent clustering. That is, the features under the principal components represent the element values ​​originally under multiple scene elements. Since the number of principal components is less than the number of scene elements, it can achieve the purpose of dimensionality reduction for multiple scene elements, thereby helping to reduce the computational cost of the clustering process.

[0123] Principal Component Analysis (PCA) transforms multiple scene elements into a set of linearly independent principal component representations. These transformed principal component representations are then sorted by variance. Typically, the principal component representations with the largest variances are selected to approximate the original data; that is, the principal component representations with the largest variances are referred to as the principal components. In practical applications, to preserve as many features as possible from the original data and ensure that the features under the principal components are closer to the original data, principal component representations that represent at least a certain threshold (e.g., 80%) of the features in the original data can be selected as the principal components.

[0124] For ease of understanding, the embodiments of this application provide, as follows: Figure 6 The diagram shown illustrates the results of principal component analysis. Figure 6 In the diagram, the horizontal axis represents the linearly independent principal component representations obtained from principal component analysis, and the vertical axis represents the contribution ratio of each principal component representation to the total variance. This contribution ratio reflects the ability of the principal component representation to retain features in the original data. For example, using features representing at least 80% of the original data as the basis for determining principal components... Figure 6 In the example, the sum of the sharing ratios of the first three principal components exceeds 80%, therefore, the first three principal components can be used as the final determined principal components. That is, the PCA analysis results show that the optimal number of components is 3.

[0125] It should be noted that this application does not impose any limitations on the method for performing principal component analysis on multiple scene elements based on the element values ​​of each scene element. For ease of understanding, the following methods are provided as examples in the embodiments of this application:

[0126] Typically, the range of values ​​for elements in different scenes varies considerably, resulting in significant differences in the scale of these values. To improve the accuracy of principal component analysis (PCA), one possible approach is to first normalize the values ​​of each scene element to make them similar, thus eliminating scale differences and allowing for better PCA analysis and improved accuracy.

[0127] In practical implementation, the aforementioned principal component analysis (PCA) of multiple scene elements based on the element values ​​of scene elements included in multiple candidate scenes can include: first, normalizing the element values ​​of scene elements in each candidate scene; and then performing PCA on multiple scene elements based on the normalized element values. This normalization process makes the element values ​​of each scene element similar, eliminating scale differences in element values. Therefore, when performing PCA based on the normalized element values, the impact of scale differences in element values ​​on the PCA is avoided, which helps improve the accuracy of the PCA.

[0128] This application does not impose any restrictions on the method of normalization. For example, normalization can be performed using the min-max scaler method.

[0129] Furthermore, this application does not limit the method for clustering multiple candidate scenarios based on the features corresponding to each candidate scenario under the principal components. In practical applications, the clustering methods provided in the foregoing embodiments can still be used, and details can be found in the descriptions of the foregoing embodiments, which will not be repeated here. For better understanding, corresponding to the embodiments using principal component analysis, this application provides the following example, taking three determined principal components as an example:

[0130] If the principal components include a first principal component, a second principal component, and a third principal component, then the features corresponding to the candidate scene under the principal components include the first feature corresponding to the first principal component, the second feature corresponding to the second principal component, and the third feature corresponding to the third principal component. Accordingly, the aforementioned clustering of multiple candidate scenes based on the features corresponding to each candidate scene under the principal components to obtain multiple scene clusters can, in specific implementations, include:

[0131] Based on the first, second, and third features of the candidate scenes, their positions in the three-dimensional feature space are determined. Specifically, the first coordinate axis of the three-dimensional feature space indicates the first principal component, the second coordinate axis indicates the second principal component, and the third coordinate axis indicates the third principal component. Next, based on the positions of multiple candidate scenes in the three-dimensional feature space, multiple candidate scenes can be clustered to obtain multiple scene clusters.

[0132] As can be seen, when there are three principal components, the position of each candidate scene in the three-dimensional feature space can be determined based on the features corresponding to these three principal components. This means mapping multiple candidate scenes to the same three-dimensional feature space, and then directly reflecting the similarity between candidate scenes based on their positions, allowing for clustering. Therefore, reducing multiple scene elements to a three-dimensional level with three principal components and identifying candidate scenes by their positions in three-dimensional space enables more intuitive and faster clustering.

[0133] For ease of understanding, embodiments of this application also provide, as follows: Figure 7 The diagram shown illustrates a clustering result. Figure 7 In this context, the x-axis, y-axis, and z-axis can be used to indicate the aforementioned first, second, and third coordinate axes, respectively. Figure 7 In the 3D feature space shown, each sample point can be used to identify a candidate scene. The features corresponding to the candidate scene under the three principal components are used to determine the position of the sample point corresponding to the candidate scene in the 3D feature space. Then, clustering based on position yields results such as... Figure 7 The four scene clusters shown are scene cluster ①, scene cluster ②, scene cluster ③, and scene cluster ④.

[0134] Understandably, the combination-based approach identifies all possible combinations as candidate scenarios. However, in real-world applications, some combinations are not permitted to occur on real roads. Therefore, another possible implementation could be to filter the multiple candidate scenarios based on prior knowledge of vehicle operation on real roads, and then perform subsequent clustering.

[0135] That is, in the specific implementation of the aforementioned S203, the server can first obtain prior knowledge about the vehicle's driving on real roads. This prior knowledge can be used to indicate the rules, etc., for the vehicle's driving on real roads. Then, the server can filter candidate scenarios that conform to the prior knowledge from multiple candidate scenarios based on the element values ​​of the scene elements in each candidate scenario, and use these as pending scenarios. Based on the element values ​​of the scene elements in the pending scenarios, the server can cluster the pending scenarios to obtain multiple scene clusters.

[0136] Based on this, a mechanism for filtering based on prior knowledge is provided. The filtered undetermined scenarios are consistent with prior knowledge and can reflect driving scenarios that might actually occur when vehicles are driving on real roads. Therefore, the undetermined scenarios can also be considered reasonable and valid scenarios. Subsequent clustering and other processes are then performed based on the undetermined scenarios to ensure that the final determined test scenarios all conform to prior knowledge, avoiding invalid testing and improving testing efficiency. Furthermore, because invalid scenarios that do not conform to prior knowledge are filtered out, the computational load of the clustering process is reduced.

[0137] It should be noted that this application does not impose any restrictions on the method of acquiring prior knowledge. In practical applications, prior knowledge is used to instruct vehicles on rules for driving on real roads. Typically, prior knowledge can be determined based on the vehicle's own characteristics and the traffic rules of the real road. Specifically, based on vehicle dynamics and kinematic models, it can be determined that changes in the speed and acceleration of the vehicle and other road users must conform to kinematic models and physical laws. Based on the traffic rules of the real road, it can be determined that vehicles in certain lanes cannot make turns in certain directions.

[0138] For example, a kinematic model defines the rate of change of a car's speed and acceleration. If, in a candidate scenario, the rate of change of speed and acceleration is too large and does not conform to the definition of the kinematic model, then this candidate scenario does not conform to prior knowledge. Another example is that, under current traffic rules, a vehicle traveling in the rightmost lane cannot make a right cut-in, i.e., change to an adjacent lane. If, in a candidate scenario, the lane element is set to the rightmost lane and the direction of travel element is set to a right cut-in, then this candidate scenario does not conform to prior knowledge.

[0139] Of course, when constructing test scenarios for autonomous vehicles, prior knowledge can be determined by incorporating theoretical research on autonomous driving technology, in order to construct test scenarios that conform to prior knowledge related to autonomous driving. For example, the Responsibility Sensitive Safety (RSS) model is based on common sense about human driving, combined with specific driving scenarios, and derives corresponding safety rules through mathematical formulas to ensure the safety of autonomous vehicles. It is often used to evaluate the safety of autonomous vehicles under various conditions, so prior knowledge related to autonomous driving can be determined based on this model.

[0140] (III) Regarding the sampling method, the embodiments of this application provide the following examples for illustration:

[0141] To better understand the density clustering method provided in the foregoing embodiments, this application also provides a corresponding sampling method as an example:

[0142] In density clustering, the focus is on location distribution; therefore, one possible implementation is sampling based on location. Specifically, the server can first determine the core points and boundary points of a scene cluster from the sample points included in the cluster. Then, it samples from the candidate scenes identified by the core points and the candidate scenes identified by the boundary points to obtain the target scene corresponding to the scene cluster. Typically, the core points and boundary points of a scene cluster can be determined based on the location of each sample point during the density clustering process.

[0143] Core points are crucial for scene clustering; therefore, core points indicate the cluster center, while boundary points indicate the cluster edge. Candidate scenes identified by the core points and boundary points of a scene cluster are similar because they belong to the same cluster, but their location—one at the cluster center and the other at the edge—indicates the greatest difference within that cluster. Therefore, sampling from both core and boundary point-identified candidate scenes helps identify the most differentiated scenes within the cluster, preventing excessive similarity between target scenes. Consequently, the final test scenes determined based on the target scenes of each scene cluster will not contain overly similar scenes, avoiding scene redundancy and other issues.

[0144] Since the location of a sample point in the feature space depends on the values ​​of the scene elements in the candidate scene, extreme values ​​are generally more likely to reflect extreme driving scenarios. For example, if all scene elements take the maximum value within their respective ranges, this can be considered an extreme value. The sample points corresponding to such extreme values ​​are more likely to be located at the boundaries of the feature space, or more likely at the boundaries of a scene cluster. Therefore, sampling the target scene from the candidate scenes identified by the boundary points helps to identify potential extreme scenarios. This allows for better identification of potential safety hazards during subsequent simulation testing.

[0145] To ensure that the sampled target scene better represents the entire scene cluster, another possible implementation involves uniform sampling within the scene cluster. In practice, the server first divides the area marked by the edges of the scene cluster into multiple sampling units. Next, if candidate scenes are distributed within a sampling unit, the server samples a predetermined number of candidate scenes from these units as the target scene for that unit. Finally, the server determines the target scene for the scene cluster by combining the target scenes from each of the multiple sampling units.

[0146] As can be seen, by dividing the scene cluster into sampling units and then sampling a preset number of candidate scenes within each sampling unit, the goal of uniform sampling is achieved. Based on this, the distribution of the target scene within the scene cluster is similar to the distribution of all candidate scenes within the entire scene cluster, thus better representing the entire scene cluster. Correspondingly, the target scene within the scene cluster better preserves the differences between candidate scenes within the cluster, helping to avoid selecting overly similar scenes simultaneously, thereby preventing excessively similar scenes in the test scenario and avoiding scene redundancy and other problems.

[0147] Furthermore, based on the distribution of candidate scenes in the feature space within each scene cluster, the distance from each sample point to the cluster center can be calculated. This distance reflects the proximity of the sample point to the cluster center, i.e., the degree of difference between the candidate scene identified by that sample point and the cluster center. Then, uniform sampling can be performed based on distance, for example, sampling a candidate scene identified by a sample point as the target scene at preset distance threshold intervals. This also avoids including overly similar scenes in the sampled target scenes, thus preventing scene redundancy and other problems.

[0148] The above embodiments have provided a more detailed explanation of the method for determining test scenarios provided in this application. It is understood that, based on the implementation methods provided above, further combinations can be made to provide more implementation methods. For example, principal component analysis can be performed first, followed by density clustering to obtain multiple scenario clusters.

[0149] To better understand, this application summarizes the method for determining the test scenario provided in this application. For details, please refer to [link to relevant documentation]. Figure 8 The diagram shown illustrates a framework for determining a test scenario. Specifically:

[0150] The first part involves determining multiple candidate scenarios based on combinations. In specific implementation, multiple scenario elements and their corresponding value ranges can first be determined. For example, the scenario elements and their value ranges can be determined using methods such as sampling and analyzing the probability distribution of values, as provided in the aforementioned embodiments. Next, the element values ​​can be combined to obtain multiple candidate scenarios, as described above. Figure 5 As shown in the example.

[0151] The second part involves filtering multiple candidate scenarios. Specifically, this can include filtering candidate scenarios based on prior knowledge to eliminate unreasonable and invalid scenarios, ensuring the rationality and realism of the determined test scenarios, thereby improving the reliability and accuracy of simulation test results. Additionally, it can filter scenario elements related to the test objective to eliminate scenario elements of no interest to the test, thus reducing computational load. For detailed explanations of these aspects in the foregoing embodiments, they will not be repeated here.

[0152] The third part involves determining test scenarios based on clustering and sampling. First, the candidate scenarios selected in the second part can be clustered to obtain multiple scenario clusters. This clustering can be performed using methods such as machine learning. During this process, methods such as normalization and principal component analysis can be used to reduce dimensionality before clustering, thereby reducing the computational load. Next, representative target scenarios can be sampled from each scenario cluster. Finally, test scenarios are determined based on the target scenarios corresponding to each scenario cluster. This automates the determination of test scenarios, reducing the workload of manually designing test scenarios and improving testing efficiency, costs, and time investment.

[0153] Therefore, this avoids including too many similar scenarios in the test environment, solving the problem of test scenario redundancy, reducing duplicate testing, and improving testing efficiency. Furthermore, because sampling is done separately from each scenario cluster, the final test scenario retains the differences between each cluster, thus covering a wide variety of driving scenarios. Therefore, conducting simulation tests based on these test scenarios helps to identify potential safety hazards during vehicle operation, ensuring vehicle safety on real roads. For example, for autonomous driving, conducting more comprehensive simulation tests based on test scenarios with higher coverage allows for the discovery and timely remediation of potential safety hazards in the autonomous driving system, thereby improving the overall safety performance of the autonomous driving system.

[0154] In practical applications, in order to improve the efficiency of determining test scenarios, Figure 8 The framework shown may also include a basic configuration layer, which may specifically include a filtering rules module, a parameter setting module, and an exception description module.

[0155] The filtering rules module can be used to configure rules related to filtering candidate scenarios, such as the aforementioned prior knowledge and test objectives. Thus, when executing the second part, the corresponding rules can be directly read from the filtering rules module in the basic configuration layer.

[0156] The parameter setting module can be used to configure clustering-related parameters, such as the aforementioned radius parameter, neighborhood density threshold, and feature representation threshold for principal component analysis (e.g., 80% as mentioned above). Thus, when executing Part 3, the corresponding parameters can be directly read from the parameter setting module in the basic configuration layer.

[0157] The exception description module can be used to configure exception case descriptions for scenarios and their corresponding automatic repair methods. Thus, if an exception occurs during the process of determining a test scenario, the exception case description can be read from the exception description module in the basic configuration layer and compared with the current exception. If a match is found, the corresponding automatic repair method can be directly invoked to attempt to fix the exception. If the repair is successful, subsequent steps can proceed, which improves the efficiency of determining test scenarios.

[0158] In practical applications, there are often multiple test scenarios. To facilitate subsequent simulation testing, these scenarios can be merged into a single result dataset. This allows for the reading of multiple test scenarios and the execution of simulations on each scenario using a single call to the result dataset. Within the result dataset, each test scenario can be described by the values ​​of its corresponding scene elements. For example, a test scenario might be... Figure 5 Candidate scenario 1 in the example.

[0159] Typically, vehicle simulation tests can be performed in a simulation environment. To facilitate simulation in this environment, the resulting dataset can be converted into a standard data format recognizable by the simulation environment before output. Common standard data formats include the Open Driving Scene Description Format (OpenDRIVE) and OpenSCENARIO. OpenDRIVE focuses on defining a storage format for describing static road networks, enabling the description of road environments. Its format adheres to the syntax of Extensible Markup Language (XML). Typically, the OpenDRIVE format uses XML with the file extension .xodr as the basis for describing road networks.

[0160] Furthermore, OpenSCENARIO includes descriptions and file structure patterns for dynamic content in simulation applications, primarily used to describe complex multi-vehicle operating conditions, and for the virtual development, testing, and verification of assisted driving and autonomous driving functions. Typically, the OpenSCENARIO format uses Extensible Markup Language (XOSC) as its open scene description format. It aims to provide a universal, extensible scene description language for interoperability between different autonomous driving simulators and sensor simulators. XOSC defines a series of XML tags and attributes to describe various elements in the scene, such as vehicles, roads, and sensor data, for simulation and testing within the simulation environment.

[0161] It should be noted that, based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods.

[0162] based on Figure 2 Corresponding to the method for determining test scenarios provided in the embodiments, this application also provides a test scenario determination device 900, which includes an acquisition unit 901, a combination unit 902, a clustering unit 903, a sampling unit 904, and a determination unit 905.

[0163] The acquisition unit 901 is used to acquire multiple scene elements and acquire the value range of each element corresponding to the multiple scene elements. The multiple scene elements describe the driving scenario of the vehicle on the real road from different dimensions.

[0164] The combination unit 902 is used to combine the element values ​​of different scene elements to obtain multiple candidate scenes, wherein the element values ​​of the scene elements are determined within the range of element values ​​of the scene elements.

[0165] The clustering unit 903 is used to cluster multiple candidate scenes according to the element values ​​of scene elements in each candidate scene to obtain multiple scene clusters, and candidate scenes in the same scene cluster satisfy the condition of similar values.

[0166] The sampling unit 904 is used to sample the candidate scenes included in the scene cluster to obtain the target scene corresponding to the scene cluster;

[0167] The determining unit 905 is used to determine a test scenario based on the target scenarios corresponding to the multiple scene clusters, and the test scenario is used to perform simulation testing on the vehicle.

[0168] In one possible implementation, the clustering unit is further used for:

[0169] Based on the element values ​​of the scene elements in the candidate scene, the position of the sample point used to identify the candidate scene in the feature space is determined;

[0170] Based on the positions corresponding to the multiple sample points, density clustering is performed on the multiple sample points to obtain multiple scene clusters. The positions of sample points in the same scene cluster in the feature space satisfy the density connectivity condition.

[0171] In one possible implementation, the sampling unit is further used for:

[0172] From the sample points included in the scene cluster, determine the core point of the scene cluster and the boundary point of the scene cluster;

[0173] The target scene corresponding to the scene cluster is obtained by sampling from the candidate scenes identified by the core point of the scene cluster and the candidate scenes identified by the boundary points of the scene cluster.

[0174] In one possible implementation, the clustering unit is further used for:

[0175] Obtain the radius parameter and neighborhood density threshold;

[0176] Based on the radius parameter, the neighborhood density threshold, and the positions corresponding to the multiple sample points, density clustering is performed on the multiple sample points to obtain multiple scene clusters;

[0177] In density clustering, if the number of sample points in the neighborhood of a sample point is greater than or equal to the neighborhood density threshold, then the sample point is a core point. The neighborhood of the sample point is used to indicate the region in the feature space centered on the position of the sample point and determined based on the radius parameter. The scene cluster includes at least one core point and non-core points located in the neighborhood of the core point. The number of sample points in the neighborhood of the non-core point is less than the neighborhood density threshold.

[0178] In one possible implementation, the acquisition unit is further configured to:

[0179] The radius parameter and the neighborhood density threshold are determined based on the differences between the element values ​​of scene elements in multiple candidate scenes and the number of scene elements.

[0180] In one possible implementation, the sampling unit is further used for:

[0181] The area marked by the edge of the scene cluster is divided into multiple sampling units;

[0182] If there are candidate scenes distributed within the sampling unit, a preset number of candidate scenes are sampled from the candidate scenes distributed within the sampling unit as the target scene corresponding to the sampling unit.

[0183] The target scenes corresponding to the multiple sampling units are determined as the target scenes corresponding to the scene cluster.

[0184] In one possible implementation, the clustering unit is further used for:

[0185] Obtain test targets for the vehicle, the test targets being used to indicate the objectives to be achieved in testing the vehicle based on the test scenario;

[0186] From the multiple scene elements, select scene elements that are relevant to achieving the test objective;

[0187] Based on the element values ​​of the scene elements related to completing the test objective in the candidate scenes, multiple candidate scenes are clustered to obtain multiple scene clusters.

[0188] In one possible implementation, the clustering unit is further used for:

[0189] Based on the element values ​​of the scene elements included in the multiple candidate scenes, principal component analysis is performed on the multiple scene elements to obtain principal components used to describe the candidate scenes, and to obtain the features of the candidate scenes under the principal components. The number of principal components is less than the number of scene elements.

[0190] Based on the features corresponding to each candidate scene under the principal component, multiple candidate scenes are clustered to obtain multiple scene clusters.

[0191] In one possible implementation, if the principal components include a first principal component, a second principal component, and a third principal component, then the features corresponding to the candidate scene under the principal components include a first feature corresponding to the first principal component, a second feature corresponding to the second principal component, and a third feature corresponding to the third principal component. The clustering unit is further configured to:

[0192] Based on the first feature, second feature and third feature included in the candidate scene, the position of the candidate scene in the three-dimensional feature space is determined. The first coordinate axis of the three-dimensional feature space is used to indicate the first principal component, the second coordinate axis of the three-dimensional feature space is used to indicate the second principal component, and the third coordinate axis of the three-dimensional feature space is used to indicate the third principal component.

[0193] Based on the positions of the multiple candidate scenes in the three-dimensional feature space, the multiple candidate scenes are clustered to obtain multiple scene clusters.

[0194] In one possible implementation, the clustering unit is further used for:

[0195] The element values ​​of each scene element in each candidate scene are normalized;

[0196] Principal component analysis is performed on multiple scene elements based on the normalized element values.

[0197] In one possible implementation, the clustering unit is further used for:

[0198] Obtain prior knowledge about the vehicle's operation on real roads;

[0199] Based on the element values ​​of the scene elements in each candidate scene, candidate scenes that conform to the prior knowledge are selected from multiple candidate scenes and designated as undetermined scenes.

[0200] Based on the element values ​​of the scene elements in the undetermined scene, the undetermined scene is clustered to obtain multiple scene clusters.

[0201] As can be seen from the above technical solution, multiple candidate scenarios are obtained by combining the element values ​​of different scenario elements. Since real road data reflects driving scenarios that have already occurred, the actual values ​​of each scenario element are predetermined. In the combination method, the range of element values ​​indicates the possible values ​​of scenario elements in a driving scenario. Therefore, the combination of element values ​​is not limited by the already occurred driving scenarios. Thus, combination is beneficial for identifying potential scenarios that may occur but have not yet occurred on real roads, resulting in higher scenario coverage. For the multiple candidate scenarios obtained through combination, the element values ​​of the scenario elements in each candidate scenario reflect what kind of driving scenario the candidate scenario indicates. Therefore, clustering multiple candidate scenarios based on the element values ​​of scenario elements can group similar scenarios into one scenario cluster and scenarios with significant differences into different scenario clusters. Next, the candidate scenarios included in the scenario clusters are sampled to obtain representative target scenarios. Test scenarios are then determined based on the target scenarios corresponding to the multiple scenario clusters, and these test scenarios are used for vehicle simulation testing. As can be seen, for the multiple candidate scenarios combined, clustering them into scenario clusters first, and then sampling from each scenario cluster separately, avoids including too many similar scenarios in the test scenario, solves the problem of test scenario redundancy, helps reduce duplicate testing, and improves testing efficiency. Furthermore, because sampling is done separately from each scenario cluster, the final test scenario can retain the differences between the clusters, thus covering a wide variety of driving scenarios and achieving more comprehensive simulation testing. Based on this, it is possible to balance scenario coverage and testing efficiency, which is conducive to completing more comprehensive simulation testing faster and improving simulation testing results.

[0202] This application also provides a computer device, which can be a terminal, taking a smartphone as an example:

[0203] Figure 10 The diagram shown is a block diagram of a portion of the structure of a smartphone provided in an embodiment of this application. (Reference) Figure 10 The smartphone includes components such as a radio frequency (RF) circuit 1110, a memory 1120, an input unit 1130, a display unit 1140, a sensor 1150, an audio circuit 1160, a Wi-Fi module 1170, a processor 1180, and a power supply 1190. The input unit 1130 may include a touch panel 1131 and other input devices 1132, the display unit 1140 may include a display panel 1141, and the audio circuit 1160 may include a speaker 1161 and a microphone 1162. Those skilled in the art will understand that... Figure 10The smartphone structure shown does not constitute a limitation on smartphones and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0204] The memory 1120 can be used to store software programs and modules. The processor 1180 executes various functions and data processing of the smartphone by running the software programs and modules stored in the memory 1120. The memory 1120 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the smartphone (such as audio data, phonebook, etc.). In addition, the memory 1120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0205] The processor 1180 is the control center of the smartphone, connecting various parts of the smartphone via various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 1120 and calling data stored in the memory 1120. Optionally, the processor 1180 may include one or more processing units; preferably, the processor 1180 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1180.

[0206] In this embodiment, the steps performed by the processor 1180 in the smartphone can be based on Figure 10 The structure shown is implemented.

[0207] The computer device provided in this application embodiment can also be a server. Please refer to [link / reference]. Figure 11 As shown, Figure 11This is a structural diagram of the server 1200 provided in this application embodiment. The server 1200 can vary significantly due to different configurations or performance. It may include one or more processors, such as a central processing unit (CPU) 1222, and a memory 1232, and one or more storage media 1230 (e.g., one or more mass storage devices) for storing application programs 1242 or data 1244. The memory 1232 and storage media 1230 can be temporary or persistent storage. The program stored in the storage media 1230 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 1222 may be configured to communicate with the storage media 1230 and execute the series of instruction operations in the storage media 1230 on the server 1200.

[0208] Server 1200 may also include one or more power supplies 1226, one or more wired or wireless network interfaces 1250, one or more input / output interfaces 1258, and / or one or more operating systems 1241, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0209] In this embodiment, the central processing unit 1222 in server 1200 can perform the following steps:

[0210] Multiple scene elements are obtained, as well as the value range of each scene element. The multiple scene elements describe the driving scenario of the vehicle on the real road from different dimensions.

[0211] By combining the element values ​​of different scene elements, multiple candidate scenes are obtained, wherein the element values ​​of the scene elements are determined within the range of element values ​​of the scene elements;

[0212] Based on the element values ​​of the scene elements in each candidate scene, multiple candidate scenes are clustered to obtain multiple scene clusters. Candidate scenes in the same scene cluster satisfy the condition of similar values.

[0213] The candidate scenes included in the scene cluster are sampled to obtain the target scene corresponding to the scene cluster;

[0214] A test scenario is determined based on the target scenarios corresponding to the multiple scenario clusters, and the test scenario is used to conduct simulation tests on the vehicle.

[0215] According to one aspect of this application, a computer-readable storage medium is provided for storing a computer program that, when executed by a computer device, causes the computer device to perform the method for determining the test scenario described in the foregoing embodiments.

[0216] According to one aspect of this application, a computer program product is provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the methods provided in various optional implementations of the above embodiments.

[0217] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0218] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0219] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0220] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0221] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0222] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0223] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

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

Claims

1. A method for determining a test scenario, characterized in that, The method includes: Multiple scene elements are obtained, as well as the value range of each scene element. The multiple scene elements describe the driving scenario of the vehicle on the real road from different dimensions. By combining the element values ​​of different scene elements, multiple candidate scenes are obtained, wherein the element values ​​of the scene elements are determined within the range of element values ​​of the scene elements; Based on the element values ​​of the scene elements in each candidate scene, multiple candidate scenes are clustered to obtain multiple scene clusters. Candidate scenes in the same scene cluster satisfy the condition of similar values. The candidate scenes included in the scene cluster are sampled to obtain the target scene corresponding to the scene cluster; A test scenario is determined based on the target scenarios corresponding to the multiple scenario clusters, and the test scenario is used to conduct simulation tests on the vehicle.

2. The method according to claim 1, characterized in that, The step of clustering multiple candidate scenes based on the element values ​​of scene elements in each candidate scene to obtain multiple scene clusters includes: Based on the element values ​​of the scene elements in the candidate scene, the position of the sample point used to identify the candidate scene in the feature space is determined; Based on the positions corresponding to the multiple sample points, density clustering is performed on the multiple sample points to obtain multiple scene clusters. The positions of sample points in the same scene cluster in the feature space satisfy the density connectivity condition.

3. The method according to claim 2, characterized in that, The step of sampling the candidate scenes included in the scene cluster to obtain the target scene corresponding to the scene cluster includes: From the sample points included in the scene cluster, determine the core point of the scene cluster and the boundary point of the scene cluster; The target scene corresponding to the scene cluster is obtained by sampling from the candidate scenes identified by the core point of the scene cluster and the candidate scenes identified by the boundary points of the scene cluster.

4. The method according to claim 2, characterized in that, The step of performing density clustering on the multiple sample points based on their respective locations to obtain multiple scene clusters includes: Obtain the radius parameter and neighborhood density threshold; Based on the radius parameter, the neighborhood density threshold, and the positions corresponding to the multiple sample points, density clustering is performed on the multiple sample points to obtain multiple scene clusters; In density clustering, if the number of sample points in the neighborhood of a sample point is greater than or equal to the neighborhood density threshold, then the sample point is a core point. The neighborhood of the sample point is used to indicate the region in the feature space centered on the position of the sample point and determined based on the radius parameter. The scene cluster includes at least one core point and non-core points located in the neighborhood of the core point. The number of sample points in the neighborhood of the non-core point is less than the neighborhood density threshold.

5. The method according to claim 4, characterized in that, The acquisition of the radius parameter and the neighborhood density threshold includes: The radius parameter and the neighborhood density threshold are determined based on the differences between the element values ​​of scene elements in multiple candidate scenes and the number of scene elements.

6. The method according to claim 1, characterized in that, The step of sampling the candidate scenes included in the scene cluster to obtain the target scene corresponding to the scene cluster includes: The area marked by the edge of the scene cluster is divided into multiple sampling units; If there are candidate scenes distributed within the sampling unit, a preset number of candidate scenes are sampled from the candidate scenes distributed within the sampling unit as the target scene corresponding to the sampling unit. The target scenes corresponding to the multiple sampling units are determined as the target scenes corresponding to the scene cluster.

7. The method according to claim 1, characterized in that, The step of clustering multiple candidate scenes based on the element values ​​of scene elements in each candidate scene to obtain multiple scene clusters includes: Obtain test targets for the vehicle, the test targets being used to indicate the objectives to be achieved in testing the vehicle based on the test scenario; From the multiple scene elements, select scene elements that are relevant to achieving the test objective; Based on the element values ​​of the scene elements related to completing the test objective in the candidate scenes, multiple candidate scenes are clustered to obtain multiple scene clusters.

8. The method according to claim 1, characterized in that, The step of clustering multiple candidate scenes based on the element values ​​of scene elements in each candidate scene to obtain multiple scene clusters includes: Based on the element values ​​of the scene elements included in the multiple candidate scenes, principal component analysis is performed on the multiple scene elements to obtain principal components used to describe the candidate scenes, and to obtain the features of the candidate scenes under the principal components. The number of principal components is less than the number of scene elements. Based on the features corresponding to each candidate scene under the principal component, multiple candidate scenes are clustered to obtain multiple scene clusters.

9. The method according to claim 8, characterized in that, If the principal components include a first principal component, a second principal component, and a third principal component, then the features corresponding to the candidate scene under the principal components include a first feature corresponding to the first principal component, a second feature corresponding to the second principal component, and a third feature corresponding to the third principal component. The step of clustering multiple candidate scenes based on the features corresponding to each candidate scene under the principal components to obtain multiple scene clusters includes: Based on the first feature, second feature and third feature included in the candidate scene, the position of the candidate scene in the three-dimensional feature space is determined. The first coordinate axis of the three-dimensional feature space is used to indicate the first principal component, the second coordinate axis of the three-dimensional feature space is used to indicate the second principal component, and the third coordinate axis of the three-dimensional feature space is used to indicate the third principal component. Based on the positions of the multiple candidate scenes in the three-dimensional feature space, the multiple candidate scenes are clustered to obtain multiple scene clusters.

10. The method according to claim 8, characterized in that, The step of performing principal component analysis on the multiple scene elements based on the element values ​​of the scene elements included in the multiple candidate scenes includes: The element values ​​of each scene element in each candidate scene are normalized; Principal component analysis is performed on multiple scene elements based on the normalized element values.

11. The method according to any one of claims 1-10, characterized in that, The step of clustering multiple candidate scenes based on the element values ​​of scene elements in each candidate scene to obtain multiple scene clusters includes: Obtain prior knowledge about the vehicle's operation on real roads; Based on the element values ​​of the scene elements in each candidate scene, candidate scenes that conform to the prior knowledge are selected from multiple candidate scenes and designated as undetermined scenes. Based on the element values ​​of the scene elements in the undetermined scene, the undetermined scene is clustered to obtain multiple scene clusters.

12. A device for determining a test scenario, characterized in that, The device includes an acquisition unit, a combination unit, a clustering unit, a sampling unit, and a determination unit: The acquisition unit is used to acquire multiple scene elements and acquire the value range of each of the multiple scene elements. The multiple scene elements describe the driving scenario of the vehicle on the real road from different dimensions. The combination unit is used to combine the element values ​​of different scene elements to obtain multiple candidate scenes, wherein the element values ​​of the scene elements are determined within the range of element values ​​of the scene elements. The clustering unit is used to cluster multiple candidate scenes according to the element values ​​of scene elements in each candidate scene to obtain multiple scene clusters, and candidate scenes in the same scene cluster satisfy the condition of similar values. The sampling unit is used to sample the candidate scenes included in the scene cluster to obtain the target scene corresponding to the scene cluster; The determining unit is used to determine a test scenario based on the target scenarios corresponding to the multiple scene clusters, and the test scenario is used to perform simulation testing on the vehicle.

13. A computer device, characterized in that, The computer device includes a processor and memory: The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is configured to execute the method according to any one of claims 1-11 according to instructions in the computer program.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program, which, when executed by a computer device, causes the computer device to perform the method according to any one of claims 1-11.

15. A computer program product, comprising a computer program, characterized in that, When it is run on a computer device, it causes the computer device to perform the method according to any one of claims 1-11.

Images