Test case design method, device and equipment for autonomous driving scene, and medium

Abstract

The application discloses a kind of automatic driving scene test case design method, device, equipment and medium, the case design method includes: extracting front-end function requirement;According to the extracted front-end function requirement, seed scene test case is generated using standard generalization evaluation system;The scene classification required by the seed scene test case is carried out, and the key information scene parameter of the seed scene test case is extracted according to category;Set the reasonable value range and value step of the key information parameter;According to the value range and value step, different parameter combinations are formed by changing the value of the key information scene parameter of each seed scene test case, and each parameter combination is used as the subcase of the corresponding seed scene test case. Using the application can effectively generalize some key scene test cases, so as to effectively cover the function boundary and key problem point of the automatic driving system.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of simulation testing of automatic driving of vehicles, and in particular to a test case design method, device and equipment for automatic driving scenes and a medium. BACKGROUND

[0002] With the development of the intelligent and networked trend of automobiles, simulation technology has more room to play, such as simulation testing and verification of automatic driving systems.

[0003] Before the real commercial application of automatic driving vehicles, a large number of road tests need to be carried out to meet the commercial requirements. The time and cost of using road tests to optimize automatic driving algorithms are too high, and open road tests are still subject to regulatory restrictions, it is difficult to reproduce extreme traffic conditions and scenes, and there are hidden dangers in test safety. In view of the low efficiency and high cost of finding problems in public road tests, simulation testing based on a scene library is the main route to solve the testing challenges of automatic driving research and development. Automatic driving system testing is different from traditional vehicle or component testing, and more refers to the model and process of software development and testing. In order to verify the effectiveness of simulation testing, a software-in-the-loop simulation testing method can be selected to reproduce the effects of vehicle road testing.

[0004] For testing pre-set scenes, targeted simulation testing can help automatic driving systems to discover scenes that may cause system problems in advance. At present, scene-based testing methods have been effectively developed, but the test method of automatic driving provided in the prior art cannot effectively generalize some key scene test cases, nor can it effectively cover the function boundaries and key problem points of the automatic driving system. SUMMARY

[0005] In view of the above-mentioned shortcomings of the prior art, the purpose of the present application is to provide a test case design method, device, equipment and medium for automatic driving scenes to solve the above technical problems.

[0006] To achieve the above-mentioned purposes and other related purposes, the present application provides a test case design method for automatic driving scenes, comprising:

[0007] extracting front-end function requirements;

[0008] generating seed scene test cases using a standard generalizable evaluation system according to the extracted front-end function requirements;

[0009] classifying the required scenes of the seed scene test cases, and extracting key information scene parameters of the seed scene test cases according to the categories;

[0010] setting a reasonable value range and a value step length for the key information parameters;

[0011] According to the value range and the value step length, different parameter combinations are formed by changing the value of the key information scene parameter of each seed scene test case, and each parameter combination serves as a sub-case of the corresponding seed scene test case.

[0012] In an optional embodiment of the present application, the method further comprises: testing the sub-case, and if the test passes, outputting a test report, otherwise, modifying the reasonable value range and the value step length of the key information parameter of the sub-case and retesting.

[0013] In an optional embodiment of the present application, the required scene of the seed scene test case is classified, specifically comprising: classifying the required scene of the seed scene test case according to a static road network and a dynamic traffic flow.

[0014] In an optional embodiment of the present application, in the step of extracting the key information scene parameter of the seed scene test case according to the category, when the required scene of the seed scene test case is the static road network scene, the key information scene parameter at least includes one of a road speed limit, a lane line, a curvature of a lane, a ramp type, and a ramp mouth length.

[0015] In an optional embodiment of the present application, in the dynamic traffic flow scene, the key information scene parameter at least includes vehicle information, target vehicle information, and a relative relationship between the vehicle and the target vehicle.

[0016] In an optional embodiment of the present application, the front-end functional requirement at least includes a road test question, a user typical scene, or a simulation iteration test question item.

[0017] In an optional embodiment of the present application, in the step of setting the reasonable value range and the value step length of the key information parameter, the value step length is set as an equal step length.

[0018] To achieve the above object and other related objects, the present application further provides a test case design device based on an automatic driving scene, which comprises:

[0019] A parameter acquisition module is used to acquire a front-end functional requirement.

[0020] A seed scene test case generation module is used to generate a seed scene test case according to the acquired front-end functional requirement by using a standard generalizable evaluation system.

[0021] A feature parameter extraction module is used to classify a required scene of the seed scene test case, and extract a key information scene parameter of the seed scene test case according to the category.

[0022] a parameter range setting module, configured to set a reasonable value range and a value step of the key information parameter;

[0023] a sub-case generation module, configured to form different parameter combinations by changing the value of the key information scene parameter of each seed scene test case according to the value range and the value step, and each parameter combination is taken as a sub-case corresponding to the seed scene test case.

[0024] To achieve the above object and other related objects, the present application also provides an apparatus, comprising:

[0025] one or more processors;

[0026] a storage device, configured to store one or more programs, which, when executed by the one or more processors, cause the electronic device to perform the above method.

[0027] To achieve the above object and other related objects, the present application also provides a medium, which has computer readable instructions stored thereon, and the computer readable instructions, when executed by a processor of a computer, cause the computer to perform the above method.

[0028] The present application has the following beneficial effects:

[0029] The test case design method based on automatic driving simulation scene disclosed by the present application extracts front-end function requirements, generates seed scene test cases by using a standard generalizable evaluation system according to the extracted front-end function requirements, classifies the required scenes of the seed scene test cases, extracts key information scene parameters of the seed scene test cases according to the categories, sets a reasonable value range and a value step of the key information parameter, forms different parameter combinations by changing the value of the key information scene parameter of each seed scene test case according to the value range and the value step, and each parameter combination is taken as a sub-case corresponding to the seed scene test case, so that some key scene test cases are effectively generalized, and the effective coverage of the function boundary and key problem points of the automatic driving system is achieved. BRIEF DESCRIPTION OF DRAWINGS

[0030] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and serve to explain the principles of the present application. It is apparent that the accompanying drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings. In the drawings:

[0031] Figure 1 A block diagram of an automatic driving vehicle is shown for an exemplary embodiment of the present application.

[0032] Figure 2 A flowchart of a test case design method of an autonomous driving simulation scene according to an example embodiment of the present application.

[0033] Figure 3 A flowchart of testing generated sub-cases according to an example embodiment of the present application.

[0034] Figure 4 A block diagram of a test case design device of an autonomous driving simulation scene according to an example embodiment of the present application.

[0035] Figure 5 A structural schematic diagram of a computer system of an electronic device suitable for implementing embodiments of the present application. DETAILED DESCRIPTION

[0036] The present application is described below by way of specific embodiments, and those skilled in the art can easily understand other advantages and effects of the present application from the disclosure. The present application can also be implemented or applied by different specific embodiments, and various modifications or changes can be made to the details in the specification based on different views and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0037] It should be noted that the diagrams provided in the following embodiments only illustrate the basic concept of the present application in a schematic manner, and only show the components related to the present application in the diagrams, not the number, shape and size of the components when actually implemented. The actual implementation of each component may be a random change, and the component layout pattern may be more complex.

[0038] In the following description, a large number of details are discussed to provide a more thorough explanation of the embodiments of the present application, however, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details, and in other embodiments, the known structures and devices are shown in the form of block diagrams rather than in the form of details, to avoid making the embodiments of the present application difficult to understand.

[0039] The terms "first", "second", and the like in the specification and claims of the embodiments of the present disclosure and the above-described drawings are used to distinguish similar objects, and do not necessarily have to describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present disclosure described herein can be implemented. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion.

[0040] Unless otherwise specified, the term "a plurality of" means two or more.

[0041] In the embodiments of the present disclosure, the character " / " represents an "or" relationship between the preceding and following objects. For example, A / B represents: A or B.

[0042] The term "and / or" is a description of the association relationship between objects, which means that there can be three relationships. For example, A and / or B means: A or B, or, A and B, three relationships.

[0043] It should be noted that the software-in-the-loop test method is a test method that sets the relevant signals of the ECU through specific control software instead of the hardware in the hardware-in-the-loop test, integrates the code information of the ECU to be tested into a virtual ECU, simulates various sensor signals required by the controller through the I / O model in the virtual controller and the vehicle model in the system environment, receives the control signals sent by the virtual ECU and the signals of the bench sensor, thereby connecting the code information of the ECU to be tested and the system environment model, and finally realizing a closed-loop simulation.

[0044] Figure 1 It is a structure schematic diagram of an automatic driving vehicle 100 shown in an exemplary embodiment of the present application, and the automatic driving vehicle 100 comprises a vehicle body 101, a central processing system 102, an execution system 103, a vehicle body sensor 104 and a control system 105. Before the automatic driving vehicle 100 is truly commercialized, a large amount of road tests need to be experienced to meet the commercial requirements. The time and cost consumed by the road test for optimizing the automatic driving algorithm are too high, and the open road test is still limited by regulations, the extreme traffic conditions and scene reproduction are difficult, and the test safety has hidden dangers. In view of the low efficiency and high cost of the problems found by the public road test, the simulation test based on the scene library is the main route to solve the test challenge of the automatic driving research and development. The automatic driving system test is different from the traditional automobile whole vehicle or part test, and more refers to the model and process of software development and test. In order to verify the effectiveness of the simulation test, the software-in-the-loop simulation test method can be selected to reproduce the vehicle road test effect.

[0045] For the pre-set scene test, the simulation test can help the automatic driving system to find the scene that may cause system problems in advance. At present, the scene-based test method has been effectively developed, but the test method of the automatic driving provided in the prior art cannot effectively generalize some key scene test cases, and cannot effectively cover the function boundary and key problem points of the automatic driving system.

[0046] Therefore, the present application discloses a test case design method for an automatic driving scene, Figure 2A test case design method of an automatic driving scene of an example embodiment of the present application is shown, which comprises at least steps S210 to S250, and is described in detail as follows.

[0047] In step S210, front-end function requirements are extracted.

[0048] It should be noted that the front-end function requirements comprise at least one of a road test question, a user typical scene and a simulation iteration test question item. The user typical scene is the most important front-end input item. The scene is decomposed from system product form definition, and the logical performance of the tested system function is discussed from the scene level. The typical scene is extracted, such as a scene involving TTC and time interval of target obstacles, which can fully test the logical performance of the system, such as acceleration, deceleration, lane changing, back-off, avoidance and the like.

[0049] The road test question and the simulation iteration test question item are effective and key logical function questions found in actual tests. In order to ensure the reliability and stability of the automatic driving system algorithm in subsequent iteration tests, such questions can be used as the key design objects of the test cases.

[0050] It should be noted that the test case of the automatic driving simulation scene provided by the present application is built under a scene design software VTD (Virtual Test Drive). The VTD is a tool kit for creating, configuring, simulating and evaluating virtual environments, involving highway and rail transit simulation. It is used for the development of advanced driver assistance systems and automatic driving systems, and is also used as a training simulator. It covers the process from the creation of a three-dimensional virtual world to the simulation of complex traffic scenes, including simple or physical level sensor simulation. It is applied to software-in-the-loop, driver-in-the-loop, vehicle-in-the-loop and hardware-in-the-loop stages, and can be cooperatively simulated with third-party or customer's own applications. Its open and modular design concept makes it easy to use interfaces and integrated work.

[0051] In step S220, according to the extracted front-end function requirements, a seed scene test case is generated by using a standard generalizable evaluation system.

[0052] It should be noted that in the present embodiment, since the generalization of the test case based on the scene is required, the change of the CAN bus protocol and the software signal interface cannot be used as the main observation signal of the test case. In order to ensure that the seed scene test case can have universality and general applicability, it is necessary to use the common signals such as whether the vehicle changes lanes, the apparent vehicle speed after acceleration and deceleration to evaluate. Such signals can be used as the judgment criteria of the seed scene test case by the internal signals in the scene design software VTD. The design steps of the seed scene test case should also be simplified as much as possible, and the function performance of the system in the ODD (design operating domain) defined according to the required design scene and the lower limit of the range of the function to be calibrated should be used as the process step judgment condition of the seed scene test case. Based on the above principles, the standard and universal evaluation system is extracted to generate the seed test case.

[0053] In step S230, the required scene of the seed scene test case is classified, and the key information scene parameters of the seed scene test case are extracted according to the category.

[0054] The simulation test scene is mainly composed of static road network and dynamic traffic flow based on the static road network, so when the seed scene test case is designed, the key information scene parameters that can be generalized in the scene should be fully considered. In the static road network, the main key information scene parameters that can be generalized are road speed limit, lane line, lane curvature, ramp type, ramp length, etc.; in the dynamic traffic flow, the main generalization parameters are the host vehicle HV, the target vehicle RV (player) with a driver model, and the relative longitudinal distance S between the host vehicle and the target vehicle. The static road network information in the xodr file of VTD can be changed in batches, such as the road speed limit 60kph <speed soffset="max="1.66666666666666666668e+01”">; can change the relevant key parameter information based on the xodr generated xml file, such as modifying the initial speed in the vehicle scene to 60kph, that is, by modifying the <speed value=""1.6666666666666668e+01”">.

[0055] Step S240, set the reasonable value range of the key information parameter and the value step.

[0056] In this embodiment, after the key information parameter is extracted, the reasonable value range of the key information parameter and the generalization value step need to be considered. In addition, after the reasonable value range of the key information parameter is determined, in order to ensure the coverage, the method of equal step value can be selected, and the step range can be selected by the test personnel according to the related system requirement design condition.

[0057] Now taking a specific scene of dynamic traffic flow as an example, the setting of the reasonable value range of the key information parameter is described. For example, in the front vehicle cutting-in scene, the key information parameters are the speed difference Vx between the host vehicle and the target vehicle and the longitudinal distance Sx between the host vehicle and the target vehicle. According to the dynamics model factor (the dynamics model factor refers to the vehicle performance test data obtained by real vehicle test, and the simulation model of the engine, transmission, steering system, suspension system and other vehicle control systems is established.) and the maximum deceleration of deceleration, and the probability factor of identifying the front target vehicle cutting-in, obviously when Vx=50 m / s and Sx=20 m, the host vehicle cannot be effectively stopped, so it is naturally meaningless to test at this lower limit, and when Vx=50 m / s and Sx=90 m, such a situation basically has no effect on the host vehicle. In summary, the value range of the combined parameter factor of <Vx, Sx> is <50, 20>≤<Vx, Sx>≤<50, 90>. It should be noted that the reasonable value range of <Vx, Sx> determined here is only an exemplary embodiment, and does not mean that the value range of <Vx, Sx> in all cases is the same.

[0058] It should be noted that in different scenes, the basis for setting the reasonable value range of the key information parameter is different. For example, in the scene of the host vehicle entering the ramp, the key information parameters are the length of the ramp and the curvature of the ramp road, at this time, the basis for judging the value range of these parameters is the upper limit of the road curvature in the lateral control and the distance requirement of the longitudinal ramp lane change requirement in the system design. It should be noted that although the basis for setting the reasonable value range of the key information parameter is different in different scenes, the analysis process is similar to the determination of the reasonable value range of the speed difference Vx between the host vehicle and the target vehicle and the longitudinal distance Sx between the host vehicle and the target vehicle in the above front vehicle cutting-in scene.

[0059] Step S250, according to the value range and the value step, different parameter combinations are formed by changing the value of the key information scene parameter of each seed scene test case, and each parameter combination is used as a sub-case corresponding to the seed scene test case.

[0060] In the present embodiment, the sub-test cases and the corresponding scenes are automatically combined and generated by a python script. According to the parameter value range and the value step set in the scene, the script can automatically crawl the parameters in the xml files related to the static scene xodr and the dynamic traffic flow, so as to change the key parameter combination of the seed scene that needs to be generalized. Each case that generalizes the key parameters in the seed scene test case corresponds to the generation of the corresponding seed test case sub-case. The case number is also numbered based on the number of the seed scene test case, forming a sub-case set.

[0061] It should be noted that in other embodiments, the sub-test cases and the corresponding scenes can also be automatically combined and generated by programming languages such as C++.

[0062] Please refer to Figure 3 The flowchart, the test case design method of the automatic driving scene, also includes testing the sub-cases, if the test is passed, outputting a test report, otherwise, the reasonable value range and the value step of the key information parameters of the sub-cases need to be modified, and the test is re-performed. Through this step, the boundary of the automatic driving system function logic can be more effectively covered.

[0063] To sum up, the test case design method of the automatic driving simulation scene disclosed in the present application extracts the front-end function requirements; generates seed scene test cases according to the extracted front-end function requirements; classifies the scenes required by the seed scene test cases, and extracts the key information scene parameters of the seed scene test cases according to the categories; sets the reasonable value range and the value step of the key information parameters; according to the value range and the value step, different parameter combinations are formed by changing the value of the key information scene parameters of each seed scene test case, each parameter combination is used as a sub-case corresponding to the seed scene test case, and the effective generalization of some key scene test cases is realized, so as to effectively cover the function boundary and the key problem point of the automatic driving system.

[0064] Figure 4 A block diagram of an automatic driving scene test case design device 400 according to an example embodiment of the present application is shown. The automatic driving scene test case design device 400 includes a parameter acquisition module 401, a seed scene test case generation module 402, a feature parameter extraction module 403, a parameter range setting module 404, and a sub-case generation module 405.

[0065] The parameter acquisition module 401 is configured to extract front-end function requirements; the seed scene test case generation module 402 is configured to generate seed scene test cases according to the extracted front-end function requirements by using a standard generalization evaluation system; the feature parameter extraction module 403 is configured to classify scenes required by the seed scene test cases, and extract key information scene parameters of the seed scene test cases according to the categories; the parameter range setting module 404 is configured to set reasonable value ranges and value steps of the key information parameters; and the sub-case generation module 405 is configured to form different parameter combinations by changing values of the key information scene parameters of each seed scene test case according to the value ranges and the value steps, and each parameter combination is used as a sub-case corresponding to the seed scene test case.

[0066] It should be noted that the automatic driving scene test case design device 400 provided in the above embodiment and the automatic driving scene test case design method provided in the above embodiment belong to the same concept, and the specific operation manner of each module and unit has been described in detail in the method embodiment, which will not be repeated here. The automatic driving scene test case design device 400 provided in the above embodiment can be used in actual application, and the above functions can be completed by different functional modules according to the needs, that is, the internal structure of the system is divided into different functional modules to complete all or part of the above described functions, and this is not limited herein.

[0067] Embodiments of the present application also provide an electronic device, including: one or more processors; a storage device configured to store one or more programs, when the one or more programs are executed by the one or more processors, the electronic device implements the automatic driving scene test case design method provided in each of the above embodiments.

[0068] Figure 5 The structure schematic diagram of the computer system of the electronic device suitable for implementing the embodiments of the present application is shown. It should be noted that, Figure 5 The computer system 500 of the electronic device shown is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0069] As Figure 5 As shown, the computer system 500 includes a central processing unit (CPU) 501 which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 502 or loaded into a random access memory (RAM) 503 from a storage section 508, such as performing the methods described in the above embodiments. Various programs and data required for the operation of the system are also stored in the RAM 503. The CPU 501, the ROM 502, and the RAM 503 are connected to each other through a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0070] The following are connected to the I / O interface 505: an input section 506 including a keyboard, a mouse, etc.; an output section 507 including a display device such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; the storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as necessary. A removable recording medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 510 as necessary, so that a computer program read therefrom is installed into the storage section 508 as necessary.

[0071] In particular, according to embodiments of the present application, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, embodiments of the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing a computer program for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via the communication section 509, and / or installed from the removable recording medium 511. When the computer program is executed by the central processing unit (CPU) 501, various functions defined in the system of the present application are performed.

[0072] It should be noted that the computer-readable medium in the embodiments shown in the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium may, for example, be an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (Compact Disc Read-Only Memory, CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer-readable signal medium can include a data signal propagating in a baseband or as a carrier wave in a propagated data signal, in which the computer-readable computer program is carried. Such a propagated data signal can take various forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, which can send, propagate or transmit programs for use by or in connection with an instruction execution system, device or component. The computer program contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to wireless, wired, or the like, or any suitable combination of the above.

[0073] The flowcharts and block diagrams in the drawings illustrate the possible implementation architectures, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In the flowcharts or block diagrams, each block can represent a module, a program segment or a part of code, which contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in different order than that shown in the drawings. For example, two blocks represented in succession can actually be executed substantially in parallel, and sometimes they can be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, and the combination of blocks in the block diagram or flowchart, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0074] The units described in the embodiments of the present application can be implemented in the form of software, or can be implemented in the form of hardware, and the described units can also be arranged in a processor. In some cases, the names of the units do not constitute a limitation on the units themselves.

[0075] Another aspect of the present application also provides a computer readable storage medium having stored thereon a computer program, which, when executed by a processor, implements the touch screen split-screen method as described above. The computer readable storage medium can be included in the electronic device described in the above embodiments, or can exist separately and not be assembled into the electronic device.< / speed> < / speed>

Claims

1. A test case design method for an autonomous driving scenario, characterized in that, include: Extract front-end functional requirements, which include at least road test issues, typical user scenarios, or simulation iteration test issues. Based on the extracted front-end functional requirements, seed scenario test cases are generated using a standard and universally applicable evaluation system. The standard universal evaluation system includes using the external performance of the whole vehicle as the judgment criterion for seed scenario test cases, and using the functional performance that the system can achieve in the required design scenario within the defined design operating domain and the range to be calibrated as the process step judgment condition for seed scenario test cases; the external performance of the whole vehicle includes at least whether lane changing behavior occurs and the displayed vehicle speed after acceleration and deceleration. The required scenarios for the seed scenario test cases are categorized, and key information scenario parameters are extracted based on the categories. Specifically, the required scenarios for the seed scenario test cases are categorized into static road networks and dynamic traffic flows. When extracting key information scenario parameters based on the categories, if the required scenario is a static road network scenario, the key information scenario parameters include at least one of the following: road speed limit, lane markings, lane curvature, ramp type, and ramp length. In the dynamic traffic flow scenario, the key information scenario parameters include at least the vehicle's information, the target vehicle's information, and the relative relationship between the vehicle and the target vehicle. Set a reasonable range of values ​​and a step size for the key information scenario parameters; Based on the value range and value step size, different parameter combinations are formed by changing the values ​​of the key information scene parameters of each seed scene test case. Each parameter combination serves as a sub-case of the corresponding seed scene test case.

2. The test case design method for autonomous driving scenarios according to claim 1, characterized in that, The method further includes: testing the sub-case; if it passes the test requirements, outputting a test report; otherwise, modifying the reasonable range and step size of the key information scenario parameters of the sub-case and retesting.

3. The test case design method for autonomous driving scenarios according to claim 1, characterized in that, In setting the reasonable range of values ​​and the step size of the key information scenario parameters, the step size is set to an equal step size.

4. A test case design device for autonomous driving scenarios, characterized in that, The device includes: The parameter acquisition module is used to extract front-end functional requirements, which include at least road test questions, typical user scenarios, or simulation iteration test questions. The seed scenario test case generation module is used to generate seed scenario test cases based on the extracted front-end functional requirements using a standard universal evaluation system. The standard universal evaluation system includes using the external performance of the entire vehicle as the judgment criterion for seed scenario test cases, and using the lower limit of the functional performance that the required design scenario system can achieve within the defined design operating domain and the calibrated range of functional design as the process step judgment condition for seed scenario test cases. The external performance of the entire vehicle includes at least whether lane-changing behavior occurs and the displayed vehicle speed after acceleration and deceleration. The feature parameter extraction module is used to classify the required scenarios of the seed scenario test cases and extract key information scenario parameters of the seed scenario test cases according to the categories. Specifically, the required scenarios of the seed scenario test cases are classified into static road networks and dynamic traffic flows. When extracting key information scenario parameters of the seed scenario test cases according to categories, if the required scenario of the seed scenario test case is a static road network scenario, the key information scenario parameters include at least one of the following: road speed limit, lane markings, lane curvature, ramp type, and ramp length. In the dynamic traffic flow scenario, the key information scenario parameters include at least the vehicle's information, the target vehicle's information, and the relative relationship between the vehicle and the target vehicle. The parameter range setting module is used to set the reasonable value range and value step size of the key information scenario parameters; The sub-case generation module is used to form different parameter combinations by changing the values ​​of the key information scenario parameters of each seed scenario test case according to the value range and value step size. Each parameter combination serves as a sub-case of the corresponding seed scenario test case.

5. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to perform the method as described in any one of claims 1 to 3.

6. A computer-readable storage medium, characterized in that, It stores computer-readable instructions that, when executed by the computer's processor, cause the computer to perform the method of any one of claims 1 to 3.

Images