Coverage-driven OSC2.0 format scene generation method and device

Abstract

The invention provides a coverage-driven OSC2.0 format scene generation method and device, and the method comprises the steps: analyzing an OSC2.0 abstract scene file, extracting parameters and constraint conditions, and discretizing continuous parameters according to a preset step length; defining a coverage index based on a k-wise combination test idea, and determining a to-be-covered parameter value and a combination set P; calculating a potential value of each parameter combination com and a vulnerability hole set, preferentially selecting the com with the most vulnerabilities, and determining a parameter value of the com; updating the vulnerability set for the remaining unassigned parameters, selecting the parameter with the most vulnerabilities, determining the value of the parameter in combination with the k-wise combination coverage improvement effect, adding the value into the current com, repeating until the remaining parameters have no vulnerabilities, and completing assignment according to constraints to generate an OSC1.0 concrete scene; and adding the concrete scene into the test set, updating the coverage degree and the vulnerability set, and stopping generation until the coverage degree reaches the standard or no vulnerability exists. According to the application, the OSC2.0 and the OSC1.0 can be efficiently connected, the scale of the test set is controlled, and the coverage integrity is guaranteed.

Description

Technical Field

[0001] This application relates to the field of virtual simulation technology, and in particular to a coverage-driven method and apparatus for generating OSC2.0 format scenes. Background Technology

[0002] Verifying the safety and reliability of autonomous driving systems is a core prerequisite for their research and development. However, the complexity of open road environments and the dynamic nature of interactions among traffic participants present significant bottlenecks to traditional real-vehicle testing. This not only requires substantial time and financial investment but also struggles to reproduce low-probability, high-risk scenarios such as "edge scenarios" (e.g., sudden interactions under extreme weather conditions), making it difficult to balance test coverage and efficiency. Against this backdrop, virtual simulation testing, with its advantages of repeatability, low cost, and controllable scenarios, has become a key technological path for verifying autonomous driving systems. Its core requirement lies in constructing a large-scale, high-fidelity set of scenarios that covers key testing dimensions to systematically verify the functional integrity of perception, decision-making, planning, and control modules.

[0003] To standardize the description of virtual simulation scenarios, the OpenSCENARIO (OSC) series of standards were developed. OSC1.x (OSC1.0), as an early version, could only describe "concrete scenarios" with fixed parameters, resulting in poor scenario reusability and an inability to express complex interactive logic. OpenSCENARIO 2.0 (OSC2.0), however, introduced a Domain-Specific Language (DSL), supporting the definition of "abstract scenario families" using parameters, variables, and constraints. This significantly improved the scalability and logical expression capabilities of scenarios, adapting to the needs of large-scale autonomous driving testing. However, the abstract nature of OSC2.0 also brings new challenges: First, abstract scenarios cannot be directly parsed by mainstream simulation engines and must be transformed into concrete OSC1.0 scenarios before execution; second, the parameter combination space of abstract scenarios is huge, which is prone to "combinatorial explosion," and traditional random generation or brute-force enumeration will lead to the uncontrolled size of the test set; third, the industry lacks a unified definition and quantification standard for coverage, making it difficult to evaluate the completeness of the test set, resulting in wasted test resources or omission of key scenarios. There is an urgent need for a scenario generation solution that can efficiently connect OSC2.0 and OSC1.0 and take into account both coverage and test set size. Summary of the Invention

[0004] In view of this, embodiments of this application provide a coverage-driven method and apparatus for generating OSC2.0 format scenes, which can efficiently connect OSC2.0 and OSC1.0, control the size of the test set, and ensure coverage integrity.

[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a coverage-driven method for generating OSC2.0 format scenes, comprising the following steps: Parse the OSC2.0 abstract scene file, extract the parameters and constraints between the parameters in the scene, and discretize the continuous parameters according to a preset step size; Based on the k-wise combinatorial testing concept, a coverage index is defined, and the values ​​of all parameters to be covered and the set of value combinations P are determined. Calculate the potential values ​​of each parameter combination com and the set of uncovered vulnerability holes, and prioritize the parameter combination with the most vulnerabilities and determine its parameter values; For the remaining unassigned parameters, update the vulnerability set based on the existing parameter value constraints, select the parameter with the most vulnerabilities, determine its value by combining the k-wise combination coverage improvement effect, and add it to the current parameter combination; repeat this step until there are no vulnerabilities in the remaining parameters, complete the assignment of all parameters according to the constraints, and generate a concrete scenario in OSC1.0 format; The generated concrete scenarios are added to the test set, and the coverage and vulnerability set of each parameter combination are updated until the coverage meets the preset requirements or there are no remaining vulnerabilities, at which point scenario generation stops.

[0006] Secondly, embodiments of this application also provide a coverage-driven OSC2.0 format scene generation apparatus, the apparatus comprising: The processing module is used to parse the OSC2.0 abstract scene file, extract the parameters in the scene and the constraints between the parameters, and discretize the continuous parameters according to a preset step size; The determination module is used to define coverage metrics based on the k-wise combinatorial testing concept, and to determine all parameter values ​​to be covered and the set of value combinations P. The calculation module is used to calculate the potential values ​​of each parameter combination com and the set of uncovered vulnerability holes, and prioritizes the parameter combination with the most vulnerabilities and determines its parameter value. The generation module is used to update the vulnerability set based on the existing parameter value constraints for the remaining unassigned parameters, select the parameter with the most vulnerabilities, determine its value by combining the k-wise combination coverage improvement effect, and add it to the current parameter combination; repeat this step until there are no vulnerabilities in the remaining parameters, complete the assignment of all parameters according to the constraints, and generate a concrete scenario in OSC1.0 format; The update module is used to add the generated concrete scenarios to the test set, update the coverage and the vulnerability set of each parameter combination until the coverage meets the preset requirements or there are no remaining vulnerabilities, and then stop scenario generation.

[0007] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the coverage-driven OSC2.0 format scene generation method described in any of the first aspects.

[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, performs the coverage-driven OSC2.0 format scene generation method described in any one of the first aspects.

[0009] The embodiments of this application have the following beneficial effects: First, by parsing OSC2.0 files and discretizing continuous parameters, abstract logic is transformed into structured data, bridging the technical gap between abstract scenarios and simulation execution and providing a reliable foundation for subsequent calculations. Second, based on the k-wise combinatorial approach, a coverage metric is defined, clarifying the quantitative objective of "what to cover," avoiding incomplete or redundant coverage issues caused by ambiguous coverage standards in traditional solutions. Third, by prioritizing parameter combinations based on the number of vulnerabilities and determining parameter values ​​in conjunction with coverage improvement effects, the goal of "covering the most uncovered combinations with the fewest scenarios" is achieved, effectively avoiding resource waste caused by combination explosion and significantly reducing the test set size. Finally, by iteratively updating coverage and vulnerability sets and dynamically determining termination conditions, the generated test set is ensured to meet preset coverage requirements while achieving automated generation without manual intervention, greatly improving scenario generation efficiency. This method ultimately achieves efficient and accurate conversion from OSC2.0 abstract scenarios to OSC1.0 executable scenarios, providing a "small-scale, comprehensive, and executable" test case generation solution for autonomous driving virtual simulation testing, strongly supporting the safety and reliability verification of autonomous driving systems. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating steps S101-S105 provided in the embodiments of this application; Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application; Figure 3 This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application; Figure 4 This is a flowchart illustrating steps S401-S404 provided in the embodiments of this application; Figure 5 This is a flowchart illustrating steps S501-S504 provided in the embodiments of this application; Figure 6 This is a flowchart illustrating steps S601-S604 provided in the embodiments of this application; Figure 7 This is a flowchart illustrating steps S701-S704 provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the coverage-driven OSC2.0 format scene generation device provided in the embodiments of this application; Figure 9 This is a schematic diagram of the composition structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0013] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0014] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0015] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application and is not intended to limit the scope of this application.

[0018] See Figure 1 , Figure 1 This is a flowchart illustrating steps S101-S105 of the coverage-driven OSC2.0 format scene generation method provided in this application embodiment, which will be combined with... Figure 1 Steps S101-S105 are explained below.

[0019] In step S101, the OSC2.0 abstract scene file is parsed, the parameters in the scene and the constraints between the parameters are extracted, and the continuous parameters are discretized according to a preset step size.

[0020] The OSC2.0 format describes scenarios using a domain-specific language (DSL) with abstract logic, including core information such as parameter definitions and constraints, but it cannot be directly executed by mainstream simulation engines. This application aims to "decompose" the abstract scenario description into quantifiable and operable basic units, laying the data foundation for subsequent scenario generation and coverage calculation.

[0021] The OSC2.0 syntax parser reads the scene file and extracts the core parameters in the scene (such as the speed of traffic participants, weather type, number of lanes, interaction distance, etc.), while identifying the constraints between parameters (such as "pedestrian crossing speed does not exceed 5m / s in rainy weather" and "the number of lanes in the highway scene is ≥3 and the minimum speed of vehicles is ≥60km / h" and other logical relationships).

[0022] In OSC2.0, some parameters are continuous (such as speed and distance), and their values ​​range from a continuous interval (e.g., "vehicle speed 30-120km / h"). If continuous values ​​are directly retained, subsequent k-wise combination coverage calculations cannot be performed (the combination space is an infinite set). Therefore, this step discretizes the continuous parameters according to the user-preset step size. For example, "30-120km / h" is discretized into 10 discrete values ​​{30, 40, ..., 120} with a step size of 10km / h. This ensures the representativeness of the values ​​while avoiding the infinite expansion of the combination space.

[0023] By parsing and discretizing, the "abstract logic" of OSC2.0 is transformed into "structured data," which solves the "data gap" problem between the abstract scene and subsequent quantization calculation and scene generation. At the same time, by discretizing, the number of parameter values ​​is controlled, which provides a foundation for avoiding "combinatorial explosion" in the future.

[0024] In step S102, a coverage index is defined based on the k-wise combinatorial testing concept, and the values ​​of all parameters to be covered and the set of value combinations P are determined.

[0025] Existing technologies lack a unified coverage standard, resulting in test sets that are either too large (e.g., brute-force enumeration) and wasteful of resources, or incomplete (e.g., random selection). This application's embodiments define coverage based on the k-wise combinatorial testing concept, aiming to provide a "clear goal orientation" for scenario generation. That is, the generated test set must cover all valid combinations of k parameters, ensuring test completeness while controlling its size.

[0026] k is an integer set by the user according to the testing requirements (e.g., k=2 means "pairwise coverage", which needs to cover all valid combinations of any 2 parameters; k=3 means "3-wise coverage", which needs to cover all valid combinations of any 3 parameters). For example, the scenario contains 3 parameters: "weather (sunny, rainy)", "number of lanes (2, 3)" and "vehicle speed (30, 60)". When k=2, the combinations to be covered are (sunny, 2), (sunny, 3), (rainy, 2), (rainy, 3), (sunny, 30), (sunny, 60), (rainy, 30), (rainy, 60), (2, 30), (2, 60), (3, 30), (3, 60), a total of 12 groups.

[0027] Iterate through all combinations of k parameters, and combine them with the extracted constraints to eliminate invalid combinations that do not meet the constraints (such as "rain + 2 lanes + 30km / h" is retained if it meets the constraints, and "rain + 1 lane + 30km / h" is eliminated if it violates the constraint "number of lanes on urban roads ≥ 2"). The final set of valid combinations is P, which is the "benchmark target" for subsequent coverage calculations.

[0028] The above approach, through k-wise combination and constraint filtering, ensures comprehensive coverage (covering all key parameter combinations) while avoiding ineffective combinations that waste resources, providing quantifiable "acceptance criteria" for subsequent scenario generation.

[0029] In step S103, the potential values ​​of each parameter combination com and the set of uncovered vulnerabilities are calculated, and the parameter combination with the most vulnerabilities is selected first and its parameter values ​​are determined.

[0030] Here, by prioritizing the parameter combinations with the most vulnerabilities, the goal of "covering the most uncovered combinations with the fewest scenarios" is achieved, solving the problem of low efficiency in existing technologies that rely on random selection or brute-force enumeration. A vulnerability refers to "a combination of values ​​in the set to be covered P that has not yet been covered by the current test set." For example, if the parameter combination (weather, number of lanes) has a set to be covered P containing (sunny, 2), (sunny, 3), (rainy, 2), (rainy, 3), and the current test set only contains (sunny, 2), then the vulnerability set for this combination is {(sunny, 3), (rainy, 2), (rainy, 3)}, with 3 vulnerabilities. This step requires traversing all parameter combinations (com) and calculating the vulnerability set and number of vulnerabilities for each com.

[0031] When prioritizing and determining values, compare the number of vulnerabilities across all coms and select the com with the most vulnerabilities (e.g., a com with 3 vulnerabilities takes precedence over a com with 1 vulnerabilities) to ensure that the number of uncovered combinations is maximized in the first step. Then, select a set of values ​​from the vulnerability set of that com (which can be selected randomly or sequentially, such as selecting (rain, 2) from {(sunny, 3), (rain, 2), (rain, 3)}) as the initial values ​​for the parameters in that com (i.e., "weather = rain" and "number of lanes = 2").

[0032] By adopting the strategy of "prioritizing the most vulnerabilities", we can achieve "efficient startup" of scenario generation and avoid the problems of "repeatedly covering existing combinations and omitting key uncovered combinations" that may be caused by random selection in existing technologies. The first step can cover more uncovered combinations, laying the foundation for reducing the size of the test set in the future.

[0033] In step S104, for the remaining unassigned parameters, the vulnerability set is updated based on the existing parameter value constraints. The parameter with the most vulnerabilities is selected, and its value is determined by combining the k-wise combination coverage improvement effect and added to the current parameter combination. This step is repeated until there are no vulnerabilities in the remaining parameters. All parameters are assigned values ​​according to the constraints to generate a concrete scenario in OSC1.0 format.

[0034] Here, after determining the values ​​of some parameters, the potential values ​​of the remaining parameters may change due to constraints (e.g., "number of lanes = 2" may limit "vehicle speed ≤ 80km / h"). This application's embodiments ensure that each newly added parameter maximizes coverage of uncovered combinations by dynamically updating vulnerabilities, prioritizing the parameters with the most vulnerabilities, and combining coverage improvement effects to filter values.

[0035] Specifically, based on the determined parameter values ​​(such as "weather = rain" and "number of lanes = 2"), combined with the scenario constraints, the potential values ​​of the remaining unassigned parameters (such as "vehicle speed") are updated (e.g., the original speed range of 30-120km / h may be reduced to 30-80km / h due to the "rain + 2 lanes" constraint). Then, the vulnerability set of all com containing the remaining parameters is updated (e.g., the combination of parameters (number of lanes, speed) to be covered changes from {(2,30), (2,60), (3,30), (3,60)} to {(2,30), (2,60)}).

[0036] Count the number of vulnerabilities in the remaining parameters and select the parameter with the most vulnerabilities as the target parameter (e.g., "vehicle speed" has 2 vulnerabilities, so it is prioritized over other parameters with fewer vulnerabilities). Then, the target parameter is combined with the parameters (weather, number of lanes) in the existing com to form a new k-wise combination (e.g., when k=2, it forms (weather, speed) and (number of lanes, speed)). The number of vulnerabilities covered by each potential value of the target parameter (30km / h, 60km / h, 80km / h) in these new combinations is calculated. For example, "speed=30km / h" can cover two vulnerabilities (rain, 30) and (2,30), "speed=60km / h" can cover two vulnerabilities (rain, 60) and (2,60), and "speed=80km / h" can cover two vulnerabilities (rain, 80) and (2,80) (if all meet the constraints). The value with the most coverage (e.g., any one, here we choose 30km / h) is selected as the target parameter value, and "vehicle speed=30km / h" is added to the existing com (at this time, the com contains three parameters: weather, number of lanes, and speed).

[0037] When the set of vulnerabilities with remaining unassigned parameters is empty, it means that all valid combinations of values ​​for these parameters have been covered by the current test set. There is no need to assign values ​​through the "coverage improvement" strategy. At this time, the assignment should be completed by randomly selecting values ​​that meet the constraints to ensure the integrity of the scenario.

[0038] Check the set of unassigned parameters (such as "number of pedestrians") to confirm that all k-wise combinations have been covered (e.g., all valid combinations of "number of pedestrians" with existing parameters have been covered in P).

[0039] Based on the original scene constraints (such as "number of pedestrians: 1-5 people"), a value that meets the constraints (such as "3 people") is randomly generated and assigned to the remaining parameters.

[0040] All parameter values ​​(weather = rain, number of lanes = 2, speed = 30km / h, number of pedestrians = 3) are organized according to the OSC1.0 format requirements. OSC1.0 needs to specify the specific behavior, path, and time sequence of each traffic participant. Therefore, the parameter values ​​need to be converted into executable instructions such as "rain angel activated, 2-lane road model loaded, vehicle travels at 30km / h along 2 lanes, 3 pedestrians cross the street in the designated area" to generate the final OSC1.0 concrete scene file.

[0041] The above approach, through "dynamically updating vulnerability and coverage improvement assessments," ensures that each newly added parameter value contributes to the coverage effect to the maximum extent, avoiding the problem of "blindly assigning values ​​leading to low coverage efficiency" in existing technologies. Simultaneously, it gradually improves scene parameters through combination and expansion, providing support for generating complete and concrete scenes. While ensuring coverage, it quickly completes scene completion through random constraint-compliant assignment, avoiding the inefficiency caused by "overly pursuing coverage." Furthermore, it completes the OSC1.0 format conversion, solving the core problem that OSC2.0 abstract scenes cannot be directly simulated, generating test cases that can be executed by mainstream simulation engines.

[0042] In step S105, the generated concrete scenario is added to the test set, and the coverage and vulnerability set of each parameter combination are updated until the coverage meets the preset requirements or there are no remaining vulnerabilities, and then the scenario generation is stopped.

[0043] Here, since scenario generation is an iterative process, it is necessary to continuously add scenarios and update coverage until the preset coverage requirements are met (e.g., coverage ≥ 95%) or no vulnerabilities remain. This ensures that the test set meets the integrity requirements without causing the scale to get out of control due to over-generation. The generated OSC1.0 scenarios are added to the test scenario set to form a new test set.

[0044] Recount the actual occurrence count m of each value combination x in the set to be covered P. x (e.g., m in the combination (rain, 2, 30)) x (Change from 0 to 1), substitute into the coverage formula to update the current coverage; at the same time, recalculate the vulnerability set of all com (e.g., the vulnerability set that originally contained (rain, 2, 30) needs to be removed).

[0045] If the current coverage meets the user's preset requirements (e.g., ≥95%), or if the vulnerability set of all COMs is empty (coverage = 100%), then the scenario generation will stop; if not, return to the previous step and repeat the process of "filtering the COM with the most vulnerabilities → determining the value → expanding the combination → generating the scenario" until the termination condition is met.

[0046] The above method achieves "dynamic optimization" of the test set through iterative updates and termination judgments, which ensures that the coverage meets the standard (test completeness) and avoids generating redundant scenarios (controlling the size of the test set). It solves the contradiction in existing technologies where the test set is "either incomplete or too large", and finally generates an efficient test set that is "small in size and has full coverage".

[0047] In some embodiments, see Figure 2 , Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application. The calculation steps of the coverage index include S201-S203, which will be explained in conjunction with each step.

[0048] In step S201, the set of values ​​and value combinations T in the test scenario is determined, and the required number of coverage times n for the value or value combination x to be covered is specified. x .

[0049] In step S202, the actual occurrence count m of the value or combination of values ​​x in the test scenario set is counted. x .

[0050] In step S203, based on the formula Calculate coverage, and only retain values ​​and combinations that meet the scenario constraints during the calculation process.

[0051] Combining steps S201-S203, coverage calculation requires clearly defining the "target range" (the set to be covered P) and the "actual range" (the set T covered by the test set), and also needs to define the "coverage strength requirement" (n) for each combination. x This avoids over- or under-covering of a single combination.

[0052] T is the set of all parameter value combinations in the current test set. For example, if the test set contains two scenarios, the combination of scenario 1 is (rain, 2, 30) and the combination of scenario 2 is (sunny, 3, 60), then T = {(rain, 2, 30), (sunny, 3, 60)}.

[0053] n x This is the minimum number of coverage attempts set by the user for each desired coverage combination x, used to ensure the reliability of critical combinations (such as n in high-risk scenarios like "rain + 2 lanes + 30km / h"). x=2, n in a normal scenario "sunny + 3 lanes + 60km / h" x =1). n x It can be dynamically adjusted according to testing requirements; the default value is 1.

[0054] Next, count the actual number of times m is covered for each combination. x This is the core data for calculating coverage, reflecting the actual coverage of the target combination by the test set.

[0055] Specifically, iterate through all scenarios in the current test set, extract the parameter value combinations for each scenario, and count the occurrences of each combination x in P to obtain m. x For example, if P contains (rain, 2, 30), and the test set contains 3 scenes, where 2 scenes are combined as (rain, 2, 30), then m x =2.

[0056] During the statistical process, it is necessary to re-verify whether combination x meets the scenario constraints (to avoid invalid combinations being counted due to omissions in the initial screening). If x violates the constraints, it will not be included in m. x Statistics (i.e., m) x =0).

[0057] Coverage formula The numerator of "" is the combination x that is "both in the set to be covered P and in the test set covered T", taking "the actual number of coverages m". x "and "required number of coverage times n" x The smaller value of " (i.e., if m x ≥n x Take n x This indicates that the combination has met the coverage requirements; if m x <n x Take m x This indicates that the combination still needs additional coverage. Summing this value over all x values ​​reflects the "total contribution" to the test set meeting the coverage requirements. The denominator represents the required coverage count n for all combinations x to be covered. x The summation reflects the "total target amount" of the coverage requirement. The coverage value ranges from 0 to 1 (or 0% to 100%), and the higher the value, the more fully the test set covers the target combination.

[0058] The above method, through explicit formulas and constraints, achieves "quantitative calculation" of coverage, solving the problem in existing technologies that coverage "can only be qualitatively described and cannot be quantitatively evaluated," and providing an objective and repeatable basis for the termination judgment of scene generation.

[0059] In some embodiments, see Figure 3 , Figure 3This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application. Discretizing continuous parameters according to a preset step size can be achieved through steps S301-S303, which will be explained in conjunction with each step.

[0060] In step S301, the parameter types are distinguished and divided into numerical parameters and categorical parameters. Numerical parameters are quantifiable indicators, including speed and distance; categorical parameters are discrete categories, including weather and number of lanes.

[0061] In step S302, for numerical parameters, discretization is performed according to the user-preset step size, transforming the continuous value range into a discrete value set.

[0062] In step S303, the value ranges of all parameters are sorted out, and invalid values ​​that do not meet the constraints are eliminated in combination with the scenario constraints.

[0063] Combining steps S301-S303, the parameters in the OSC2.0 scenario can be divided into two categories according to their value characteristics: numerical parameters (values ​​are continuous or discrete numerical values ​​with quantitative significance) and categorical parameters (values ​​are discrete categories with no quantitative significance). The two types of parameters are handled differently and need to be classified first.

[0064] Numerical parameters include quantifiable indicators such as the speed (km / h), distance (m), acceleration (m / s²), and travel time (s) of traffic participants, such as "vehicle speed 30-120km / h" and "safe distance between vehicles 5-50m".

[0065] The categorization parameters include discrete categories such as weather (sunny, rainy, snowy, foggy), road type (urban road, highway, rural road), number of lanes (2, 3, 4), and traffic participant type (car, truck, pedestrian, bicycle), for example, "weather = rain" and "road type = highway".

[0066] Continuous parameters have an infinite range of values ​​(e.g., "speed 30-120km / h" contains an infinite number of values). If they are directly used in k-wise combination calculations, the combination space becomes an infinite set, making it impossible to calculate coverage and generate scenes. Therefore, discretization is needed to transform the infinite range into a finite set of discrete values.

[0067] During discretization, users set the discretization step size according to the required test accuracy. The smaller the step size, the denser the discretized values, resulting in higher test accuracy, but also a greater number of combinations. Conversely, the larger the step size, the sparser the values, resulting in lower test accuracy, but also a smaller number of combinations. For example, "speed 30-120km / h" can be processed with a step size of 5km / h (discrete into 19 values) or a step size of 10km / h (discrete into 10 values).

[0068] Starting from the minimum value of the parameter, increment the value step by step until the maximum value is reached, generating a discrete set of values. For example, the discrete set of values ​​for "speed 30-120km / h, step size 10km / h" is {30,40,50,60,70,80,90,100,110,120}.

[0069] In the OSC2.0 scenario, the parameters are subject to constraints, and some parameter values ​​may violate the constraints (e.g., if "number of lanes in the highway scenario = 2" violates the constraint "number of lanes in the highway ≥ 3", then it is an invalid value). If invalid values ​​are retained, subsequent combination calculations will include invalid combinations, wasting computing resources and affecting the accuracy of coverage.

[0070] The specific removal operations include: Constraint traversal: Traverse all extracted constraints (such as "Highway → Number of lanes ≥ 3", "Rainy day → Pedestrian speed ≤ 5m / s", "Truck → Maximum speed ≤ 90km / h").

[0071] Value validation: For each parameter value (discrete numerical value or categorical value), check whether it meets all relevant constraints. If any constraint is violated, the value is deemed invalid and removed. For example, "In the highway scenario, the '2' in the lane number value {2,3,4} violates the constraint 'lane number ≥ 3', so the lane number value is {3,4} after removal."

[0072] By eliminating invalid values, we reduce the "invalid inputs" in subsequent combination calculations, reduce the size of the combination space, and avoid resource waste; at the same time, we ensure that all values ​​involved in the combination conform to the logic of the actual scenario, and guarantee the rationality of subsequent coverage calculations and scenario generation.

[0073] In some embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating steps S401-S404 provided in the embodiments of this application. The steps for determining the parameter combination and initial values ​​include S401-S404, which will be explained in conjunction with each step.

[0074] In step S401, any k different parameters are selected from the n parameters to form a parameter combination com, which is represented in tuple form. All parameter combinations are generated according to the combination number formula C(n,k).

[0075] In step S402, the potential values ​​for each parameter combination are calculated, and the valid values ​​that meet the constraints are selected based on the scenario constraints.

[0076] In step S403, the number of vulnerabilities of each parameter combination is compared, and the parameter combination with the most vulnerabilities is selected.

[0077] In step S404, the initial values ​​of each parameter in the selected parameter combination are determined by random selection or sequential selection from the vulnerability set of the selected parameter combination.

[0078] Combining steps S401-S404, k-wise combination requires covering "all valid combinations of values ​​for any k parameters". Therefore, it is necessary to first generate "all possible combinations of k parameters" (i.e., com). Each com corresponds to a set of parameters that need to be covered. For example, if the scenario contains 4 parameters A, B, C, and D, when k=2, com includes 6 combinations: (A,B), (A,C), (A,D), (B,C), (B,D), and (C,D).

[0079] The total number of combinations is calculated using the formula C(n,k)=n! / (k!(nk)!), where n is the total number of parameters in the scene and k is the preset coverage order. For example, when n=5 and k=3, C(5,3)=10, meaning 10 combinations are generated. Each combination is stored as a tuple to ensure the uniqueness and immutability of parameter combinations (avoiding accidental changes to parameter order or content during subsequent processing). For example, the combination (weather, number of lanes, speed) is represented as a (weather, number of lanes, speed) tuple.

[0080] The potential values ​​of a com refer to "the valid combinations of all parameter values ​​in the com that meet the scenario constraints", which is the basis for subsequent vulnerability calculations (a vulnerability is a combination of potential values ​​that is not covered by the test set).

[0081] For the k parameters in com, iterate through the valid values ​​of each parameter (the set of values ​​after removing invalid values) to generate all possible combinations of values. For example, in com(weather, number of lanes), the weather values ​​are {sunny, rainy} and the number of lanes values ​​are {3, 4}. Then all possible combinations of values ​​are (sunny, 3), (sunny, 4), (rainy, 3), (rainy, 4).

[0082] Check if each value combination meets all constraints in the scenario (e.g., "Rainy day + highway → number of lanes ≥ 3", "Sunny day + city road → number of lanes ≥ 2"). Eliminate combinations that violate constraints, and the remaining combinations are the potential values ​​for that com. For example, if the scenario is "highway", then (Sunny, 3), (Sunny, 4), (Rainy, 3), and (Rainy, 4) all meet the constraints and are potential values; if the scenario is "city road" and there is a constraint "city road rainy day → number of lanes ≤ 3", then (Rainy, 4) violates the constraint and is eliminated, and the potential values ​​are (Sunny, 3), (Sunny, 4), and (Rainy, 3).

[0083] A COM with more vulnerabilities means that there are more uncovered valid combinations within that COM. Prioritizing the processing of that COM can cover more uncovered combinations in the first step, maximizing coverage and reducing the number of subsequent scenario generation.

[0084] For each com, compare its set of potential values ​​with the coverage set of the current test set (when the initial test set is empty, all potential values ​​are vulnerabilities), and count the number of vulnerabilities (i.e., the number of combinations of potential values ​​that do not appear in the test set). For example, the com (weather, number of lanes) has 4 potential values, and the initial test set is empty, so the number of vulnerabilities is 4; another com (speed, number of pedestrians) has 3 potential values, so the number of vulnerabilities is 3. Therefore, the former has more vulnerabilities.

[0085] Sort all .com files by the number of vulnerabilities from most to least, and select the .com file with the most vulnerabilities as the priority for handling; if multiple .com files have the same number of vulnerabilities (e.g., two .com files both have 4 vulnerabilities), then randomly select one of them.

[0086] The above approach, through a "most vulnerabilities first" screening strategy, ensures "efficient coverage" during the scenario generation startup phase, avoiding the "low coverage efficiency and need to generate more scenarios" problem caused by randomly selecting COM in existing technologies, thus laying the foundation for reducing the size of the test set.

[0087] When selecting initial values ​​from the vulnerability set, it is necessary to ensure the "validity" (compliance with constraints) and "randomness / orderliness" of the values ​​(to avoid coverage bias caused by fixed selection), while avoiding overly complex evaluation (because the initial values ​​are only for the initial stage, and subsequent steps will further optimize the coverage effect).

[0088] In specific selection, a combination is randomly selected from the vulnerability set of com using a random number generator as the initial value. For example, in the vulnerability set {(sunny, 3), (sunny, 4), (rainy, 3), (rainy, 4)}, if (rainy, 3) is randomly selected, then in com, "weather = rain" and "number of lanes = 3".

[0089] Alternatively, select the first combination as the initial value according to the order of the combinations in the vulnerability set (e.g., by parameter values ​​from smallest to largest / from first to last). For example, if the vulnerability set is sorted as (Sunny, 3), (Sunny, 4), (Rainy, 3), (Rainy, 4), select (Sunny, 3) as the initial value.

[0090] After selection, it is necessary to re-verify whether the combination meets the scenario constraints (to avoid invalid values ​​due to omissions in the early screening). If it meets the constraints, it is determined as the initial value; otherwise, it is re-selected.

[0091] The above method quickly determines the initial value of com through a simple and effective value selection method, avoiding inefficiency caused by a complex value selection process; at the same time, through constraint secondary verification, the validity of the initial value is ensured, providing a reliable parameter basis for subsequent steps.

[0092] In some embodiments, see Figure 5 , Figure 5 This is a flowchart illustrating steps S501-S504 provided in the embodiments of this application. The steps for determining the values ​​of the remaining parameters include S501-S504, which will be explained in conjunction with each step.

[0093] In step S501, based on the determined parameter values ​​and combined with the scenario constraints, the vulnerability set of the remaining unassigned parameters is updated.

[0094] In step S502, the number of vulnerabilities in each remaining parameter is counted, and the parameter with the most vulnerabilities is selected as the target parameter.

[0095] In step S503, the target parameter is k-wise combined with the parameters in the existing parameter combination, and the number of vulnerabilities that the combination can cover under different values ​​of the target parameter is calculated.

[0096] In step S504, the value with the most covered vulnerabilities is selected as the final value of the target parameter, and the target parameter is added to the current parameter combination.

[0097] Combining steps S501-S504, since the values ​​of some parameters have been determined previously (such as "weather = rain" and "number of lanes = 3"), these values ​​will affect the potential values ​​of the remaining parameters through constraints (such as "rain + 3 lanes" may limit "vehicle speed ≤ 80km / h"). This will cause the potential values ​​of com, which includes the remaining parameters, to change, and the vulnerability set must also be updated synchronously. Otherwise, the vulnerability will be calculated based on the old potential values, resulting in a bias in the coverage assessment.

[0098] Analyze the constraints corresponding to the determined parameter values ​​(such as "weather = rain" and "number of lanes = 3"), and clarify the restrictions these values ​​place on the remaining unassigned parameters (such as "speed" and "number of pedestrians"). For example, "rainy weather → pedestrian speed ≤ 5m / s" and "3-lane highway → vehicle speed ≥ 60km / h and ≤ 100km / h".

[0099] For the remaining parameter values, the effective set of remaining parameter values ​​is adjusted according to the constraint transmission results. For example, the original value of "speed" {30,40,...,120} is adjusted to {60,70,...,100}.

[0100] For all com containing remaining parameters (such as (weather, speed), (number of lanes, speed), (speed, number of pedestrians)), recalculate their potential values ​​(based on the adjusted remaining parameter values), compare with the current test set coverage, and update the vulnerability set (remove vulnerabilities that are invalid due to parameter value adjustments, and retain vulnerabilities that are still valid).

[0101] Among the remaining parameters, the more vulnerabilities a parameter has, the more uncovered combinations there are in the COM structure formed by that parameter and other parameters. Prioritizing the processing of this parameter can determine more uncovered combinations to be covered by taking its value once, thus maximizing the coverage efficiency.

[0102] Specifically, for each remaining unassigned parameter, the total number of vulnerabilities in all com containing that parameter is counted (i.e., the total number of uncovered combinations among all k-wise combinations in which that parameter participates). For example, if the remaining parameter "speed" participates in 3 coms, the number of vulnerabilities is 2, 1, and 3 respectively, totaling 6; if the remaining parameter "number of pedestrians" participates in 2 coms, the number of vulnerabilities is 1 and 2 respectively, totaling 3, then "speed" has more vulnerabilities.

[0103] Sort the remaining parameters from highest to lowest total number of vulnerabilities, and select the parameter with the most vulnerabilities as the target parameter; if multiple parameters have the same total number of vulnerabilities, randomly select one of them.

[0104] The target parameter has multiple potential values ​​(such as the values ​​of "speed" after adjustment {60,70,...,100}), and different values ​​have different effects on improving coverage (such as "speed=60km / h" can cover 2 vulnerabilities, and "speed=80km / h" can cover 3 vulnerabilities). It is necessary to select the value with the best improvement effect through evaluation to ensure the "efficiency" of parameter assignment.

[0105] Combine the target parameter with the determined existing parameters (such as weather and number of lanes) to form all possible k-wise combinations (e.g., when k=2, the target parameter "speed" is combined with the existing parameters to form (weather, speed) or (number of lanes, speed); when k=3, it is formed as (weather, number of lanes, speed)).

[0106] For each potential value of the target parameter, calculate the number of vulnerabilities that this value can cover in all the above k-wise combinations (i.e., the number of combinations of this value with existing parameter values ​​in the vulnerability set of the corresponding COM). For example, the potential values ​​for the target parameter "speed" are 60, 80, and 100 km / h: The combination of "speed = 60km / h" (rain, 60) covers 2 vulnerabilities in the vulnerability set of com (weather, speed) and (3, 60) covers 2 vulnerabilities in the vulnerability set of com (lane number, speed). The combination (rain, 80) and (3, 80) consisting of "speed = 80km / h" are in the vulnerability set of the corresponding com, while (rain, 3, 80) is in the vulnerability set of com (weather, number of lanes, speed), covering a total of 3 vulnerabilities; The number of coverage vulnerabilities for "speed = 80km / h" is 3, which is better than the 2 vulnerabilities for 60km / h.

[0107] The value that covers the most vulnerabilities is selected as the final value of the target parameter. If multiple values ​​cover the same number of vulnerabilities (e.g., "speed = 80km / h" and "speed = 100km / h" both cover 3 vulnerabilities), one of them is randomly selected to ensure the effectiveness and efficiency of the value.

[0108] In the process of selecting the optimal value, the number of vulnerabilities covered by all potential values ​​of the target parameter is compared, and the value with the most vulnerabilities is selected as the final value. For example, "speed = 80km / h" covers 3 vulnerabilities, so it is the optimal value and "speed = 80km / h" is determined.

[0109] The determined target parameters and their values ​​are added to the existing com to form a new com (e.g., the original com (weather, number of lanes) is expanded to (weather, number of lanes, speed)), providing a more complete parameter combination basis for the processing of other remaining parameters in subsequent steps.

[0110] By determining the optimal values ​​and expanding the combinations, we can maximize the current coverage and gradually improve the parameter combinations, providing a more comprehensive combination framework for the processing of the remaining parameters and ensuring "efficient iteration" in the scene generation process.

[0111] In some embodiments, see Figure 6 , Figure 6 This is a flowchart illustrating steps S601-S604 provided in the embodiments of this application. The steps for completing the assignment of the remaining parameters include S601-S604, which will be explained in conjunction with each step.

[0112] In step S601, the set of vulnerabilities with remaining unassigned parameters is checked to confirm that no vulnerabilities remain.

[0113] In step S602, values ​​that meet the constraints are randomly generated based on the original scene constraints.

[0114] In step S603, the generated values ​​are assigned to the remaining unassigned parameters, thus completing the assignment of values ​​to all parameters.

[0115] In step S604, in accordance with the OSC1.0 format requirements, all parameters and their values ​​are converted into a concrete scene file.

[0116] Combining steps S601-S604, an empty vulnerability set means that all valid combinations of values ​​for the remaining parameters have been covered by the current test set, and there is no need to assign values ​​through the "coverage enhancement" strategy (continuing to assign values ​​according to the coverage strategy will lead to duplicate coverage and waste of resources). At this time, it is necessary to switch to the "fast completion" strategy to ensure the integrity of the scenario.

[0117] The specific confirmation process includes: Traverse the remaining parameters: Check all unassigned remaining parameters one by one (such as "number of pedestrians" and "traffic light status").

[0118] Vulnerability set check: For each remaining parameter, check whether the vulnerability set of all com containing that parameter is empty (i.e., all valid combinations of this parameter with other parameters have been covered by the test set). For example, if the vulnerability sets of coms (speed, pedestrian count) and (weather, pedestrian count) involving the remaining parameter "pedestrian count" are both empty, then it is determined that there are no remaining vulnerabilities for this parameter.

[0119] Overall confirmation: If no vulnerabilities remain in any of the remaining parameters, proceed to the subsequent assignment step; if any parameter has a vulnerability remaining, return to continue processing according to the coverage strategy.

[0120] By confirming the vulnerability empty set, we can accurately determine when to switch from "coverage priority" to "integrity priority" in scenario generation, avoid inefficient assignment caused by "overly pursuing coverage", and ensure that the coverage meets the basic requirements when switching.

[0121] When there are no vulnerabilities in the remaining parameters, their values ​​only need to meet the scenario constraints (without considering coverage). Therefore, random assignment is adopted, which is both fast and avoids scenario homogenization caused by fixed assignment (such as all scenarios having "number of pedestrians = 2"), thus ensuring the diversity of the test set.

[0122] The specific assignment operations include: Constraint Extraction: Extract all constraints related to the remaining parameters in the scene. For example, the constraint for "number of pedestrians" is "1-5 people" and "when the traffic light is red, the number of pedestrians is ≥1".

[0123] Random value generation: Based on constraints, a random number generator generates values ​​that meet the constraints. For example, "number of pedestrians" is randomly generated as "3 people" from 1 to 5 people, and "traffic light status" is randomly generated as "red" from {red, yellow, green}.

[0124] Constraint verification: After generating a value, verify again whether it meets all constraints (to avoid randomly generated values ​​violating constraints). If it meets the constraints, assign the value; otherwise, regenerate the value.

[0125] By randomly assigning values ​​that meet constraints, the remaining parameters can be completed quickly, avoiding the complex and time-consuming assignment process. At the same time, randomness ensures the diversity of test set scenarios, improving the test set's "generalization verification capability" for the autonomous driving system (avoiding the system from only adapting to fixed scenarios).

[0126] By combining the determined parameter values ​​with random assignments, a complete set of parameter values ​​is formed, providing a complete "data input" for subsequent OSC1.0 format conversion.

[0127] OSC2.0 is an abstract logical description, while mainstream simulation engines (such as Prescan and Carsim) only support concrete scenarios in OSC1.0 format (requiring explicit details of traffic participants' behaviors, paths, and time series). Therefore, parameter values ​​need to be converted to OSC1.0 format to ensure the scenario can be simulated and executed. Following OSC1.0 format requirements, parameter values ​​are mapped to corresponding XML tags and attributes, for example: "Weather = Rain" is mapped to <weather> <precipitation type="rain" intensity="medium" / > < / weather> ; "Vehicle speed = 80km / h" is mapped to <vehicle id="v1"> <speed value="80" unit="km / h" / > < / vehicle> ; "Traffic light status = red" is mapped to <trafficlight id="tl1"> <state value="red" duration="10" unit="s" / > < / trafficlight> .

[0128] Based on the parameter values, the specific behaviors and paths of traffic participants are supplemented. For example, if "number of pedestrians = 3 people", the pedestrian crossing path (such as "crossing the street from the zebra crossing on the east side of the road to the west side") and crossing time (such as "completing the crossing within 10 seconds") need to be defined; if "vehicle speed = 80km / h", the vehicle driving path (such as "driving straight along the middle lane of the 3 lanes") needs to be defined.

[0129] Use the OSC1.0 syntax checker to check whether the generated scene file conforms to the format specifications. If there are syntax errors, correct them to ensure that the file can be parsed normally by the simulation engine.

[0130] By converting the OSC1.0 format, abstract parameter values ​​are transformed into executable, concrete scenarios, solving the core problem that OSC2.0 scenarios cannot be directly simulated. The generated scenarios can be directly used for virtual simulation testing of autonomous driving systems, providing an "executable tool" for subsequent testing and verification.

[0131] In some embodiments, see Figure 7 , Figure 7 This is a flowchart illustrating steps S701-S704 provided in the embodiments of this application. The steps of updating coverage and stopping scene generation include S701-S704, which will be explained in conjunction with each step.

[0132] In step S701, the OSC1.0 format concrete scene generated in the previous step is added to the test scene set.

[0133] In step S702, the actual occurrence count m of each value or combination of values ​​to be covered is recounted. x Update coverage.

[0134] In step S703, based on the updated coverage, the vulnerability set for each parameter combination is recalculated.

[0135] In step S704, it is determined whether the coverage meets the preset requirements or whether the vulnerability set is empty. If it meets the requirements, the scenario generation stops. If it does not meet the requirements, it returns to continue calculating the potential values ​​of each parameter combination com and the set of uncovered vulnerability holes.

[0136] Combining steps S701-S704, the generated OSC1.0 scenarios are added to the test set, gradually accumulating the number of scenarios. At the same time, this provides the "latest test set data" for subsequent coverage and vulnerability updates, ensuring that the coverage assessment is based on the current complete test set.

[0137] Specifically, the generated OSC1.0 scene files (e.g., "scene_001.xosc") are stored in a preset path (e.g., ". / test_set / scene_001.xosc"), and a test set index table is created to record information such as scene ID, generation time, and core parameter values ​​for easy management and querying later. The total number of scenes in the test set is updated (e.g., if the original test set had 5 scenes, adding 1 scene increases it to 6), and metrics such as the storage capacity and average scene generation time of the test set are statistically analyzed to provide data reference for subsequent optimization of generation efficiency.

[0138] By updating the test set, we can achieve "iterative accumulation" of scenarios and provide the latest data for coverage and vulnerability updates. At the same time, through the index table and scale statistics, we can facilitate the management and subsequent analysis of the test set (such as analyzing the scenario diversity and generation efficiency of the test set).

[0139] The addition of new scenarios will cover some uncovered combinations, resulting in an increase in the actual number of times the combinations to be covered (m). x Changes occur, thus affecting coverage calculation results. If not updated in a timely manner, the results will be based on the old m... x The assessment of coverage may lead to a termination of the assessment due to bias (e.g., the actual coverage has met the standard, but the scene continues to be generated).

[0140] Iterate through all combinations x in the set P to be covered, and check if the parameter combination of the new scene contains x. If it does, then add m. x Add 1 (e.g., x = (rain, 3, 80), if the new scene contains this combination, then m) x (Change from 0 to 1). The updated m x Substitute into the coverage formula " Recalculate the current coverage (e.g., if the original coverage was 80%, it increases to 85% after adding new scenes). Record the coverage value and the corresponding number of scenes after each update to form a "coverage-number of scenes" curve, which is convenient for analyzing the trend of coverage changes with the number of scenes (e.g., coverage ≥ 95% when the number of scenes reaches 10).

[0141] By timely updating coverage and m x This ensures that the coverage calculation results can accurately reflect the coverage of the current test set, providing an accurate basis for subsequent termination judgments and avoiding over-generation or under-generation of scenarios due to lag in coverage data.

[0142] New scenario coverage combinations will be removed from the vulnerability set of the corresponding COM. Therefore, it is necessary to recalculate the vulnerability set of all COMs to ensure that when generating scenarios in subsequent iterations, the vulnerability statistics are based on the latest test set coverage, and to avoid repeatedly covering already covered combinations.

[0143] Examine all parameter combinations (com) in the scenario one by one. For each com, check whether each combination in its potential value set has been covered by the current test set (i.e., whether the combination is in T and m). x If a combination is already covered (≥1), it is removed from the vulnerability set; otherwise, it is retained. For example, if the vulnerability set for com (weather, number of lanes) originally included (rain, 3) and (sunny, 4), and a new scenario includes (rain, 3), then the updated vulnerability set will only retain (sunny, 4), and the number of vulnerabilities for each com will be updated to provide data for com selection in subsequent iteration steps (if more scenarios need to be generated).

[0144] By updating the vulnerability set, the "real-time" nature of vulnerability statistics is ensured, avoiding the problem of "repeatedly covering already covered combinations and wasting resources" when selecting COM based on the old vulnerability set during subsequent iterations to generate scenarios. At the same time, it provides a basis for subsequent termination judgments to empty the vulnerability set.

[0145] Scenario generation will terminate if one of two conditions is met: First, the coverage reaches the user's preset requirements (e.g., ≥95%), at which point the test set has met the basic coverage requirements and there is no need to continue generating; second, all COM vulnerability sets are empty (coverage = 100%), at which point the test set has achieved complete coverage and there is no need to continue generating. If neither condition is met, the process will return to iterating and generating scenarios again.

[0146] Compare the current coverage with the preset coverage threshold (e.g., 95%). If the current coverage is greater than or equal to the threshold, the coverage is considered satisfactory. Check if the vulnerability sets for all COMs are empty. If they are all empty, full coverage is considered. If any of the above conditions are met, stop scenario generation and output the final test set (containing all generated OSC1.0 scenarios). If none of the above conditions are met, return and repeat the process of "filtering the COM with the most vulnerabilities → determining the value → expanding the combination → generating scenarios" until the termination condition is met.

[0147] By establishing clear termination criteria and process control, the system achieves "automated iteration" of scenario generation, generating test sets that meet coverage requirements without manual intervention. At the same time, it avoids the problem of "unlimited scenario generation and uncontrolled scale" caused by the lack of termination conditions, ultimately generating a highly efficient test set that is "small in scale and comprehensive in coverage," thus resolving the core contradiction of "incomplete coverage" and "excessive scale" in existing technologies.

[0148] In summary, the embodiments of this application have the following beneficial effects: On the one hand, based on the k-wise combinatorial testing approach, the coverage metrics and calculation logic are clearly defined. Combined with parameter classification and discretization and dynamic constraint verification, the precise quantification of test coverage targets is achieved, avoiding incomplete coverage and resource waste caused by traditional random selection or brute-force enumeration. On the other hand, through a parameter combination selection strategy prioritizing the most vulnerabilities, a parameter value evaluation method oriented towards coverage improvement, and an iterative scenario generation and termination judgment mechanism, the test set size is significantly reduced while ensuring that the coverage meets preset requirements (such as above 95%). This greatly reduces the computational resource consumption and scenario generation issues caused by combinatorial explosion. The solution reduces testing time and ensures test scenario diversity by randomly filling in unassigned parameters. Furthermore, it automates the entire process from OSC2.0 abstract scenario parsing, parameter processing, coverage calculation to OSC1.0 concrete scenario generation. This not only solves the technical bottleneck that the OSC2.0 format cannot be directly parsed by simulation engines, but also improves testing efficiency and repeatability through standardized processes. Ultimately, it provides efficient, reliable, and low-cost technical support for large-scale, high-fidelity verification of the perception, decision-making, planning, and control modules of autonomous driving systems, effectively guaranteeing the safety and reliability verification results during the autonomous driving system development process.

[0149] Based on the same inventive concept, this application also provides a coverage-driven OSC2.0 format scene generation device corresponding to the coverage-driven OSC2.0 format scene generation method in the first embodiment. Since the principle of the device in this application is similar to the coverage-driven OSC2.0 format scene generation method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0150] like Figure 8 As shown, Figure 8 This is a schematic diagram of the structure of the coverage-driven OSC2.0 format scene generation device 800 provided in this application embodiment. The coverage-driven OSC2.0 format scene generation device 800 includes: The processing module 801 is used to parse the OSC2.0 abstract scene file, extract the parameters in the scene and the constraints between the parameters, and discretize the continuous parameters according to a preset step size; Module 802 is used to define coverage metrics based on the k-wise combinatorial testing concept and determine all parameter values ​​to be covered and the set of value combinations P. The calculation module 803 is used to calculate the potential values ​​of each parameter combination com and the set of uncovered vulnerability holes, and prioritizes the parameter combination with the most vulnerabilities and determines its parameter value. The generation module 804 is used to update the vulnerability set based on the existing parameter value constraints for the remaining unassigned parameters, select the parameter with the most vulnerabilities, determine its value by combining the k-wise combination coverage improvement effect, and add it to the current parameter combination; repeat this step until there are no vulnerabilities in the remaining parameters, complete the assignment of all parameters according to the constraints, and generate a concrete scenario in OSC1.0 format; The update module 805 is used to add the generated concrete scenarios to the test set, update the coverage and the vulnerability set of each parameter combination until the coverage meets the preset requirements or there are no remaining vulnerabilities, and then stop scenario generation.

[0151] Those skilled in the art should understand that Figure 8 The functions of each unit in the coverage-driven OSC2.0 format scene generation device 800 shown can be understood by referring to the relevant description of the coverage-driven OSC2.0 format scene generation method described above. Figure 8 The functions of each unit in the coverage-driven OSC2.0 format scene generation device 800 shown can be implemented by a program running on a processor or by specific logic circuits.

[0152] In one possible implementation, the calculation steps of the coverage index include: Determine the set of values ​​and combinations of values ​​T in the test scenario, and clarify the required number of coverage times n for the value or combination of values ​​x to be covered. x ; Count the actual number of times m of a value or combination of values ​​x appears in the test scenario set. x ; Based on formula Calculate coverage, and only retain values ​​and combinations that meet the scenario constraints during the calculation process.

[0153] In one possible implementation, the continuous parameter is discretized according to a preset step size, including: The parameters are categorized into numerical parameters and categorical parameters. Numerical parameters are quantifiable indicators, including speed and distance; categorical parameters are discrete categories, including weather and number of lanes. For numerical parameters, discretization is performed according to the user-preset step size, transforming the continuous range of values ​​into a set of discrete values; Organize the value ranges of all parameters, and in conjunction with the scenario constraints, eliminate invalid values ​​that do not meet the constraints.

[0154] In one possible implementation, the steps of determining the parameter combination and initial values ​​include: Select any k different parameters from n parameters to form a parameter combination com, which is represented in tuple form. Generate all parameter combinations according to the combination number formula C(n,k). Calculate the potential values ​​for each parameter combination, and filter out the valid values ​​that meet the constraints based on the scenario conditions. Compare the number of vulnerabilities for each parameter combination and select the parameter combination with the most vulnerabilities; In the vulnerability set of the selected parameter combination, the initial values ​​of each parameter in the combination are determined by random selection or sequential selection.

[0155] In one possible implementation, the step of determining the values ​​of the remaining parameters includes: Based on the determined parameter values ​​and combined with the scenario constraints, update the vulnerability set of the remaining unassigned parameters; Count the number of vulnerabilities for each remaining parameter, and select the parameter with the most vulnerabilities as the target parameter; The target parameter is k-wise combined with the parameters in the existing parameter combinations to calculate the number of vulnerabilities that the combination can cover under different values ​​of the target parameter. Select the value with the highest number of covered vulnerabilities as the final value of the target parameter, and add the target parameter to the current parameter combination.

[0156] In one possible implementation, the steps for assigning values ​​to the remaining parameters include: Check the remaining set of unassigned parameters to confirm that no vulnerabilities remain; Based on the original scene constraints, randomly generate values ​​that meet the constraints; The generated values ​​are then assigned to the remaining unassigned parameters, completing the assignment of all parameters; In accordance with the OSC1.0 format requirements, all parameters and their values ​​are converted into a concrete scene file.

[0157] In one possible implementation, the steps of updating coverage and stopping scene generation include: Add the OSC1.0 format concrete scene generated in the steps to the test scene set; Recount the actual occurrence count m of each value or combination of values ​​to be covered. x Update coverage; Based on the updated coverage, the vulnerability set for each parameter combination is recalculated; Determine whether the coverage meets the preset requirements or whether the vulnerability set is empty. If it meets the requirements, stop the scenario generation. If it does not meet the requirements, return to continue calculating the potential values ​​of each parameter combination com and the set of uncovered vulnerabilities.

[0158] The aforementioned coverage-driven OSC2.0 format scene generation device has the following beneficial effects: On the one hand, based on the k-wise combinatorial testing approach, the coverage metrics and calculation logic are clearly defined. Combined with parameter classification and discretization and dynamic constraint verification, the precise quantification of test coverage targets is achieved, avoiding incomplete coverage and resource waste caused by traditional random selection or brute-force enumeration. On the other hand, through a parameter combination selection strategy prioritizing the most vulnerabilities, a parameter value evaluation method oriented towards coverage improvement, and an iterative scenario generation and termination judgment mechanism, the test set size is significantly reduced while ensuring that the coverage meets preset requirements (such as above 95%). This greatly reduces the computational resource consumption and scenario generation issues caused by combinatorial explosion. The solution reduces testing time and ensures test scenario diversity by randomly filling in unassigned parameters. Furthermore, it automates the entire process from OSC2.0 abstract scenario parsing, parameter processing, coverage calculation to OSC1.0 concrete scenario generation. This not only solves the technical bottleneck that the OSC2.0 format cannot be directly parsed by simulation engines, but also improves testing efficiency and repeatability through standardized processes. Ultimately, it provides efficient, reliable, and low-cost technical support for large-scale, high-fidelity verification of the perception, decision-making, planning, and control modules of autonomous driving systems, effectively guaranteeing the safety and reliability verification results during the autonomous driving system development process.

[0159] like Figure 9 As shown, Figure 9 This is a schematic diagram of the composition structure of the electronic device 900 provided in the embodiments of this application. The electronic device 900 includes: The device 900 includes a processor 901, a storage medium 902, and a bus 903. The storage medium 902 stores machine-readable instructions executable by the processor 901. When the electronic device 900 is running, the processor 901 communicates with the storage medium 902 via the bus 903. The processor 901 executes the machine-readable instructions to perform the steps of the coverage-driven OSC2.0 format scene generation method described in the embodiments of this application.

[0160] In practical applications, the various components in the electronic device 900 are coupled together via a bus 903. It is understood that the bus 903 is used to achieve communication between these components. In addition to a data bus, the bus 903 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 9 The general designated all buses as Bus 903.

[0161] The above-mentioned electronic devices have the following beneficial effects: On the one hand, based on the k-wise combinatorial testing approach, the coverage metrics and calculation logic are clearly defined. Combined with parameter classification and discretization and dynamic constraint verification, the precise quantification of test coverage targets is achieved, avoiding incomplete coverage and resource waste caused by traditional random selection or brute-force enumeration. On the other hand, through a parameter combination selection strategy prioritizing the most vulnerabilities, a parameter value evaluation method oriented towards coverage improvement, and an iterative scenario generation and termination judgment mechanism, the test set size is significantly reduced while ensuring that the coverage meets preset requirements (such as above 95%). This greatly reduces the computational resource consumption and scenario generation issues caused by combinatorial explosion. The solution reduces testing time and ensures test scenario diversity by randomly filling in unassigned parameters. Furthermore, it automates the entire process from OSC2.0 abstract scenario parsing, parameter processing, coverage calculation to OSC1.0 concrete scenario generation. This not only solves the technical bottleneck that the OSC2.0 format cannot be directly parsed by simulation engines, but also improves testing efficiency and repeatability through standardized processes. Ultimately, it provides efficient, reliable, and low-cost technical support for large-scale, high-fidelity verification of the perception, decision-making, planning, and control modules of autonomous driving systems, effectively guaranteeing the safety and reliability verification results during the autonomous driving system development process.

[0162] This application also provides a computer-readable storage medium storing executable instructions. When the executable instructions are executed by at least one processor 901, the coverage-driven OSC2.0 format scene generation method described in this application is implemented.

[0163] In some embodiments, the storage medium may be a magnetic random access memory (FRAM), a read-only memory (ROM), or a programmable read-only memory (PROM). Erasable Programmable Read-Only Memory (EPROM) Electrically Erasable Programmable Read-Only Memory (EEPROM) Read-only memory, flash memory, magnetic surface storage, optical disc, or CD-ROM ROM, Compact Disc Read It can be a memory such as a memory only; or it can be a device that includes one or any combination of the above-mentioned memories.

[0164] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0165] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0166] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0167] The aforementioned computer-readable storage media have the following beneficial effects: On the one hand, based on the k-wise combinatorial testing approach, the coverage metrics and calculation logic are clearly defined. Combined with parameter classification and discretization and dynamic constraint verification, the precise quantification of test coverage targets is achieved, avoiding incomplete coverage and resource waste caused by traditional random selection or brute-force enumeration. On the other hand, through a parameter combination selection strategy prioritizing the most vulnerabilities, a parameter value evaluation method oriented towards coverage improvement, and an iterative scenario generation and termination judgment mechanism, the test set size is significantly reduced while ensuring that the coverage meets preset requirements (such as above 95%). This greatly reduces the computational resource consumption and scenario generation issues caused by combinatorial explosion. The solution reduces testing time and ensures test scenario diversity by randomly filling in unassigned parameters. Furthermore, it automates the entire process from OSC2.0 abstract scenario parsing, parameter processing, coverage calculation to OSC1.0 concrete scenario generation. This not only solves the technical bottleneck that the OSC2.0 format cannot be directly parsed by simulation engines, but also improves testing efficiency and repeatability through standardized processes. Ultimately, it provides efficient, reliable, and low-cost technical support for large-scale, high-fidelity verification of the perception, decision-making, planning, and control modules of autonomous driving systems, effectively guaranteeing the safety and reliability verification results during the autonomous driving system development process.

[0168] In the several embodiments provided in this application, it should be understood that the disclosed methods and electronic devices can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0169] The modules described as separate components may or may not be physically separate. The components shown as modules 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.

[0170] In addition, 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.

[0171] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion 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 personal computer, a platform server, or a 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, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A coverage-driven method for generating OSC2.0 format scenes, characterized in that, Includes the following steps: Parse the OSC2.0 abstract scene file, extract the parameters and constraints between the parameters in the scene, and discretize the continuous parameters according to a preset step size; Based on the k-wise combinatorial testing concept, a coverage index is defined, and the values ​​of all parameters to be covered and the set of value combinations P are determined. Calculate the potential values ​​of each parameter combination com and the set of uncovered vulnerability holes, and prioritize the parameter combination with the most vulnerabilities and determine its parameter values; For the remaining unassigned parameters, update the vulnerability set based on the existing parameter value constraints, select the parameter with the most vulnerabilities, determine its value by combining the k-wise combination coverage improvement effect, and add it to the current parameter combination; repeat this step until there are no vulnerabilities in the remaining parameters, complete the assignment of all parameters according to the constraints, and generate a concrete scenario in OSC1.0 format; The generated concrete scenarios are added to the test set, and the coverage and vulnerability set of each parameter combination are updated until the coverage meets the preset requirements or there are no remaining vulnerabilities, at which point scenario generation stops.

2. The method according to claim 1, characterized in that, The calculation steps for the coverage index include: Determine the set of values ​​and combinations of values ​​T in the test scenario, and clarify the required number of coverage times n for the value or combination of values ​​x to be covered. x ; Count the actual number of times m of a value or combination of values ​​x appears in the test scenario set. x ; Based on formula Calculate coverage, and only retain values ​​and combinations that meet the scenario constraints during the calculation process.

3. The method according to claim 1, characterized in that, Discretize the continuous parameters according to a preset step size, including: The parameters are categorized into numerical parameters and categorical parameters. Numerical parameters are quantifiable indicators, including speed and distance; categorical parameters are discrete categories, including weather and number of lanes. For numerical parameters, discretization is performed according to the user-preset step size, transforming the continuous range of values ​​into a set of discrete values; Organize the value ranges of all parameters, and in conjunction with the scenario constraints, eliminate invalid values ​​that do not meet the constraints.

4. The method according to claim 1, characterized in that, The steps to determine the parameter combination and initial values ​​include: Select any k different parameters from n parameters to form a parameter combination com, which is represented in tuple form. Generate all parameter combinations according to the combination number formula C(n,k). Calculate the potential values ​​for each parameter combination, and filter out the valid values ​​that meet the constraints based on the scenario conditions. Compare the number of vulnerabilities for each parameter combination and select the parameter combination with the most vulnerabilities; In the vulnerability set of the selected parameter combination, the initial values ​​of each parameter in the combination are determined by random selection or sequential selection.

5. The method according to claim 1, characterized in that, The steps to determine the values ​​of the remaining parameters include: Based on the determined parameter values ​​and combined with the scenario constraints, update the vulnerability set of the remaining unassigned parameters; Count the number of vulnerabilities for each remaining parameter, and select the parameter with the most vulnerabilities as the target parameter; The target parameter is k-wise combined with the parameters in the existing parameter combinations to calculate the number of vulnerabilities that the combination can cover under different values ​​of the target parameter. Select the value with the highest number of covered vulnerabilities as the final value of the target parameter, and add the target parameter to the current parameter combination.

6. The method according to claim 1, characterized in that, The steps to complete the assignment of the remaining parameters include: Check the remaining set of unassigned parameters to confirm that no vulnerabilities remain; Based on the original scene constraints, randomly generate values ​​that meet the constraints; The generated values ​​are then assigned to the remaining unassigned parameters, completing the assignment of all parameters; In accordance with the OSC1.0 format requirements, all parameters and their values ​​are converted into a concrete scene file.

7. The method according to claim 1, characterized in that, The steps for updating coverage and stopping scene generation include: Add the OSC1.0 format concrete scene generated in the steps to the test scene set; Recount the actual occurrence count m of each value or combination of values ​​to be covered. x Update coverage; Based on the updated coverage, the vulnerability set for each parameter combination is recalculated; Determine whether the coverage meets the preset requirements or whether the vulnerability set is empty. If it meets the requirements, stop the scenario generation. If it does not meet the requirements, return to continue calculating the potential values ​​of each parameter combination com and the set of uncovered vulnerabilities.

8. A coverage-driven OSC2.0 format scene generation device, characterized in that, The device includes: The processing module is used to parse the OSC2.0 abstract scene file, extract the parameters in the scene and the constraints between the parameters, and discretize the continuous parameters according to a preset step size; The determination module is used to define coverage metrics based on the k-wise combinatorial testing concept, and to determine all parameter values ​​to be covered and the set of value combinations P. The calculation module is used to calculate the potential values ​​of each parameter combination com and the set of uncovered vulnerability holes, and prioritizes the parameter combination with the most vulnerabilities and determines its parameter value. The generation module is used to update the vulnerability set based on the existing parameter value constraints for the remaining unassigned parameters, select the parameter with the most vulnerabilities, determine its value by combining the k-wise combination coverage improvement effect, and add it to the current parameter combination; repeat this step until there are no vulnerabilities in the remaining parameters, complete the assignment of all parameters according to the constraints, and generate a concrete scenario in OSC1.0 format; The update module is used to add the generated concrete scenarios to the test set, update the coverage and the vulnerability set of each parameter combination until the coverage meets the preset requirements or there are no remaining vulnerabilities, and then stop scenario generation.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the coverage-driven OSC2.0 format scene generation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the coverage-driven OSC2.0 format scene generation method as described in any one of claims 1 to 7.

Images