Virtual test scenario construction method and device

Abstract

The application provides a virtual test scene construction method and device, which can solve the problems that the constructed virtual test scene cannot interact with the unmanned vehicle, is incomplete and unreasonable, thereby improving the virtual test efficiency of the unmanned vehicle, and can be applied to the test scene of the unmanned vehicle. The method comprises the following steps: constructing a static ontology model in combination with road specifications and expert experience. The static ontology model is used to describe the design constraints of the static ontology, and the static ontology comprises one or more of the following: road topology, road infrastructure, traffic control, or environment. A dynamic ontology model is constructed based on the static ontology model. The dynamic ontology comprises one or more of the following: vehicle, pedestrian, or animal. In combination with traffic flow simulation, the driving trajectory of the dynamic ontology is determined according to the design constraints of the static ontology and the behavior constraints of the dynamic ontology, so as to generate a test scene model.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of testing, in particular to a virtual testing scene construction method and device. BACKGROUND

[0002] To ensure driving safety, an unmanned vehicle needs to be fully tested before going on the road, such as testing in a virtual testing scene. At present, the following methods can be used to construct a virtual testing scene: extracting a virtual testing scene from natural driving data, and generating a virtual testing scene based on expert experience.

[0003] However, since natural driving data is a kind of playback test, all driving trajectories of the background traffic flow cannot be changed, resulting in that the background traffic flow cannot interact with the unmanned vehicle in both directions, such as reacting to the driving behavior of the unmanned vehicle. Moreover, the above-mentioned scheme of generating a virtual testing scene based on expert experience has the following problems: due to the subjectivity of virtual testing scene classification, it is difficult to cover all testing scenes, and the virtual testing scene is constructed by a computer through a parameter combination traversal method, only considering the reasonable value of each parameter itself, without considering the relevance between parameters, resulting in a large number of unreasonable virtual testing scenes. That is, the virtual testing scene constructed based on the above two methods has the problems of being unable to interact with the unmanned vehicle, being incomplete, being unreasonable, etc., thereby resulting in low virtual testing efficiency of the unmanned vehicle. SUMMARY

[0004] The embodiments of the present application provide a virtual testing scene construction method and device, which can solve the problems of the constructed virtual testing scene being unable to interact with the unmanned vehicle, being incomplete, and being unreasonable, and can improve the virtual testing efficiency of the unmanned vehicle.

[0005] To achieve the above-mentioned purpose, the present application adopts the following technical solutions:

[0006] In a first aspect, a virtual testing scene construction method is provided. The virtual testing scene construction method comprises: constructing a static ontology model in combination with road specifications and expert experience. The static ontology model is used to describe design constraints of a static ontology, and the static ontology includes one or more of the following: road topology, road infrastructure, traffic control, or environment. A dynamic ontology model is constructed based on the static ontology model. The dynamic ontology model is used to describe behavior constraints of a dynamic ontology, and the dynamic ontology includes one or more of the following: vehicle, pedestrian, or animal. In combination with traffic flow simulation, driving trajectories of the dynamic ontology are determined according to the design constraints of the static ontology and the behavior constraints of the dynamic ontology. A testing scene model is generated. The testing scene model includes the driving trajectories, which are used to test whether the driving behavior of the unmanned vehicle meets the design requirements.

[0007] Based on the virtual test scene construction method of the first aspect, the static ontology model constructed in combination with expert experience and road specifications can reflect the design constraints between static ontologies, and can solve the problem that the values of the parameter combinations traversed by the computer are unreasonable due to the virtual test scene constructed not meeting the road specifications. Moreover, the dynamic ontology model constructed based on the static ontology model can reflect the behavior constraints between dynamic ontologies and static ontologies, and then determine the driving trajectory of the dynamic ontology based on the above behavior constraints and traffic flow simulation, which can solve the problem that the dynamic ontology in the virtual test scene extracted based on natural driving data cannot dynamically interact with the unmanned vehicle, and can eliminate unreasonable behaviors of the dynamic ontology. In this way, a large number of reasonable, complete, and dynamically interactive virtual test scenes with the unmanned vehicle can be constructed, which can improve the testing efficiency of the unmanned vehicle.

[0008] In a possible design scheme, the static ontology model constructed in combination with road specifications and expert experience can include: defining a static ontology class. The static ontology class is used to describe one or more of the following corresponding to the static ontology: a virtual test scene, a road, a median strip, a lane, a traffic sign, weather, or light conditions. Defining static object attributes and static data attributes. The static object attributes are used to describe the mapping relationship between the static ontology classes, and the static data attributes are used to describe the parameter set of the static ontology class. Defining static design rules. The static design rules are used to describe the mapping relationship between the static ontology class, the static object attributes, and the static data attributes, and the static design rules are used to determine the rationality of the generated virtual test scene. Based on the defined static object attributes and static design rules, the static ontologies with the mapping relationship can be associated. In this way, the associativity between the static ontologies can be considered in the process of generating the static scene by the static ontology model, and a reasonable static scene can be generated.

[0009] Optionally, the design constraints of the static ontology can include one or more of the following: a position relationship between roads, a position relationship between a road and a lane, a position relationship between lanes, a position relationship between a lane and a median strip, a constraint relationship between the position and type of a lane line and a lane and / or a median strip, and a position relationship between a traffic sign and a lane and / or a median strip. Since the static object attributes and the static design rules are defined by the design constraints related to road specifications, when the road specifications are updated, the static object attributes and the static design rules can be redefined according to the new design constraints, which facilitates modification of the constructed static ontology model.

[0010] Further, the method of constructing the dynamic ontology model based on the static ontology model can include defining a dynamic ontology class. The dynamic ontology class is used to describe one or more of the following: a vehicle, a pedestrian, or an animal corresponding to the dynamic ontology. Defining dynamic object attributes and dynamic data attributes. The dynamic object attributes are used to describe the mapping relationship between the dynamic ontology classes and the constraint relationship between the dynamic ontology and the static ontology, and the dynamic data attributes are used to describe the parameter set of the dynamic ontology class. Defining dynamic design rules. The dynamic design rules are used to describe the mapping relationship between the dynamic ontology class, the dynamic object attribute, and the dynamic data attribute, and the dynamic design rules are used to determine the rationality of the generated test scene. By defining the dynamic object attribute and the dynamic design rule, the dynamic ontology is constrained so that the dynamic ontologies with a mapping relationship and the dynamic ontology and the static ontology are associated. In this way, in the process of generating a dynamic scene by the dynamic ontology model, the association between the dynamic ontologies and the dynamic ontology and the static ontology is considered, and a reasonable dynamic scene is generated.

[0011] Optionally, the behavior constraints of the dynamic ontology can include one or more of the following: a position relationship between a vehicle and a lane, a position relationship between vehicles, a vehicle speed limit, a vehicle driving direction constraint, a vehicle turning constraint, a vehicle lane changing constraint, a vehicle cutting in constraint, and a vehicle cutting out constraint. Since the dynamic object attributes and the dynamic design rules are defined by the behavior constraints related to the driving behavior specification, when the driving behavior specification is updated, the dynamic object attributes and the dynamic design rules can be redefined according to the new behavior constraints, facilitating modification of the constructed dynamic ontology model.

[0012] Further, the method of constructing the dynamic ontology model based on the static ontology model can include defining a dynamic ontology class. The dynamic ontology class is used to describe one or more of the following: a vehicle, a pedestrian, or an animal corresponding to the dynamic ontology. Defining dynamic object attributes and dynamic data attributes. The dynamic object attributes are used to describe the mapping relationship between the dynamic ontology classes and the constraint relationship between the dynamic ontology and the static ontology, and the dynamic data attributes are used to describe the parameter set of the dynamic ontology class. Defining dynamic design rules. The dynamic design rules are used to describe the mapping relationship between the dynamic ontology class, the dynamic object attribute, and the dynamic data attribute, and the dynamic design rules are used to determine the rationality of the generated test scene. By defining the dynamic object attribute and the dynamic design rule, the dynamic ontology is constrained so that the dynamic ontologies with a mapping relationship and the dynamic ontology and the static ontology are associated. In this way, in the process of generating a dynamic scene by the dynamic ontology model, the association between the dynamic ontologies and the dynamic ontology and the static ontology is considered, and a reasonable dynamic scene is generated.

[0013] Optionally, the method of constructing the dynamic ontology model based on the static ontology model can include defining a dynamic ontology class. The dynamic ontology class is used to describe one or more of the following: a vehicle, a pedestrian, or an animal corresponding to the dynamic ontology. Defining dynamic object attributes and dynamic data attributes. The dynamic object attributes are used to describe the mapping relationship between the dynamic ontology classes and the constraint relationship between the dynamic ontology and the static ontology, and the dynamic data attributes are used to describe the parameter set of the dynamic ontology class. Defining dynamic design rules. The dynamic design rules are used to describe the mapping relationship between the dynamic ontology class, the dynamic object attribute, and the dynamic data attribute, and the dynamic design rules are used to determine the rationality of the generated test scene. By defining the dynamic object attribute and the dynamic design rule, the dynamic ontology is constrained so that the dynamic ontologies with a mapping relationship and the dynamic ontology and the static ontology are associated. In this way, in the process of generating a dynamic scene by the dynamic ontology model, the association between the dynamic ontologies and the dynamic ontology and the static ontology is considered, and a reasonable dynamic scene is generated.

[0014] Optionally, the behavior model of the dynamic ontology can include one or more of a car-following model, a lane-changing model, a signal light reaction model, a random disturbance model, a bus and pedestrian behavior model, a gap acceptance model, a merging model, a cooperation model, or a conflict avoidance model.

[0015] In a possible design, the virtual test scene construction method provided by the first aspect can further include: obtaining a driving behavior of the unmanned vehicle in the first test scene; determining a second test scene; wherein the second test scene is a test scene in which the driving behavior of the unmanned vehicle in the first test scene does not meet the design requirement; performing encrypted sampling on a parameter interval corresponding to the second test scene to generate a third test scene; and performing a test on the third test scene. The first test scene is constructed by using coarse-grained parameter values, and the parameter interval corresponding to the first test scene in which the driving behavior does not meet the design requirement is sampled encryptedly according to the driving behavior of the unmanned vehicle in the first test scene, to generate the third test scene. In this way, the virtual test scene that does not meet the design requirement is sampled and tested multiple times, which can solve the problem of low test efficiency caused by too many virtual test scenes constructed by using too fine parameter values, and can improve the virtual test efficiency and test pertinence of the unmanned vehicle, and is more suitable for unmanned test than a traditional test scene design based on human driving behavior.

[0016] In a possible design, the virtual test scene construction method provided by the first aspect can further include: adding a label to the virtual test scene based on an interaction relationship between the static ontology and the dynamic ontology. The label is used to manage the virtual test scene. By labeling the virtual test scene, such as classifying according to the function or danger level of the virtual test scene, the virtual test scene can be managed in the virtual test scene library.

[0017] In a possible design, the virtual test scene construction method provided by the first aspect can further include: adding a label to the virtual test scene based on an interaction relationship between the static ontology and the dynamic ontology. The label is used to manage the virtual test scene. By labeling the virtual test scene, such as classifying according to the function or danger level of the virtual test scene, the virtual test scene can be managed in the virtual test scene library.

[0018] In a possible design, the construction module is further configured to define a static ontology class. The static ontology class is used to describe one or more of the following corresponding to the static ontology: a virtual test scene, a road, a median strip, a lane, a traffic sign, weather, or a lighting condition. The construction module is further configured to define a static object attribute. The static object attribute is used to describe a mapping relationship between the static ontology classes. The construction module is further configured to define a static data attribute. The static data attribute is used to describe a parameter set of the static ontology class. The construction module is further configured to define a static design rule. The static design rule is used to describe a mapping relationship between the static ontology class, the static object attribute, and the static data attribute, and the static design rule is used to determine rationality of the generated virtual test scene.

[0019] Optionally, the design constraint of the static ontology includes one or more of the following: a position relationship between roads, a position relationship between a road and a lane, a position relationship between lanes, a position relationship between a lane and a median strip, a constraint relationship between a position and a type of a lane line and a lane and / or a median strip, and a position relationship between a traffic sign and a lane and / or a median strip.

[0020] Further, the construction module is further configured to define a dynamic ontology class. The dynamic ontology class is used to describe one or more of the following corresponding to the dynamic ontology: a vehicle, a pedestrian, or an animal. The construction module is further configured to define a dynamic object attribute. The dynamic object attribute is used to describe a mapping relationship between the dynamic ontology classes and a constraint relationship between the dynamic ontology and the static ontology. The construction module is further configured to define a dynamic data attribute. The dynamic data attribute is used to describe a parameter set of the dynamic ontology class. The construction module is further configured to define a dynamic design rule. The dynamic design rule is used to describe a mapping relationship between the dynamic ontology class, the dynamic object attribute, and the dynamic data attribute, and the dynamic design rule is used to determine rationality of the generated test scene.

[0021] Optionally, the behavior constraint of the dynamic ontology includes one or more of the following: a position relationship between a vehicle and a lane, a position relationship between vehicles, a speed limit of a vehicle, a driving direction constraint of a vehicle, a turning constraint of a vehicle, a lane changing constraint of a vehicle, a cut-in constraint of a vehicle, and a cut-out constraint of a vehicle.

[0022] Still further, the determination module is further configured to determine an initial state of the dynamic ontology according to the design constraint of the static ontology, the behavior constraint of the dynamic ontology, and the scene design requirement. The determination module is further configured to determine a driving trajectory of the dynamic ontology according to the initial state of the dynamic ontology in combination with traffic flow simulation.

[0023] Optionally, the construction module is further configured to determine the initial state of the dynamic ontology according to the design constraint of the static ontology, the behavior constraint of the dynamic ontology, and the scene design requirement, and a test target and a behavior model of the dynamic ontology.

[0024] Optionally, the behavior model of the dynamic ontology includes one or more of a car-following model, a lane-changing model, a signal light reaction model, a random disturbance model, a bus and pedestrian behavior model, a gap acceptance model, a merging model, a cooperation model, or a conflict avoidance model.

[0025] In a possible design, the virtual test scenario construction apparatus provided in the second aspect can further include an obtaining module and a testing module. The obtaining module is configured to obtain the driving behavior of the unmanned vehicle in the first test scenario. The determining module is further configured to determine a second test scenario. The second test scenario is a test scenario in which the driving behavior of the unmanned vehicle in the first test scenario does not meet the design requirement. The generating module is further configured to perform encrypted sampling on a parameter interval corresponding to the second test scenario to generate a third test scenario. The testing module is configured to perform testing on the third test scenario.

[0026] In a possible design, the virtual test scenario construction apparatus provided in the second aspect can further include an adding module. The adding module is configured to add a label to the virtual test scenario based on an interaction relationship between the static ontology and the dynamic ontology. The label is used to manage the virtual test scenario.

[0027] Optionally, the virtual test scenario construction apparatus provided in the second aspect can further include a storage module that stores a program or an instruction. When the processing module executes the program or the instruction, the virtual test scenario construction apparatus provided in the second aspect can execute the virtual test scenario construction method provided in the first aspect.

[0028] It should be noted that the virtual test scenario construction apparatus provided in the second aspect can be a network device, for example, a server, or a chip (system) or other components or assemblies arranged in the network device, and the present application does not limit this.

[0029] In addition, the technical effects of the virtual test scenario construction apparatus provided in the second aspect can refer to the technical effects of the virtual test scenario construction method provided in the first aspect, which will not be described here again.

[0030] In the third aspect, a virtual test scenario construction apparatus is provided. The virtual test scenario construction apparatus is configured to execute the virtual test scenario construction method provided in the first aspect.

[0031] In the fourth aspect, a virtual test scenario construction apparatus is provided. The virtual test scenario construction apparatus includes a processor configured to execute the virtual test scenario construction method provided in the first aspect.

[0032] Fifthly, a virtual test scenario construction apparatus is provided. The virtual test scenario construction apparatus includes: a processor coupled to a memory for storing a computer program; the processor is configured to execute the computer program stored in the memory, such that the virtual test scenario construction apparatus performs the virtual test scenario construction method as described in the possible implementation of the first aspect.

[0033] It should be noted that the virtual test scenario construction device described in the fifth aspect can be a terminal device or a network device, such as a computer or a server, or a chip (system) or other component or part set in a terminal device or network device. This application does not limit it in this regard.

[0034] Furthermore, the technical effects of the virtual test scenario construction device described in the fifth aspect can be referred to the technical effects of the virtual test scenario construction method described in the first aspect, and will not be repeated here.

[0035] Sixthly, a virtual test scenario construction system is provided. This virtual test scenario construction system includes one or more network devices.

[0036] In a seventh aspect, a computer-readable storage medium is provided, comprising: a computer program or instructions; when the computer program or instructions are executed on a computer, causing the computer to perform the virtual test scenario construction method described in the possible implementation of the first aspect.

[0037] Eighthly, a computer program product is provided, including a computer program or instructions that, when run on a computer, cause the computer to perform the virtual test scenario construction method described in the possible implementation of the first aspect. Attached Figure Description

[0038] Figure 1 Traffic scene diagrams provided for embodiments of this application;

[0039] Figure 2 A flowchart illustrating the virtual test scenario construction method provided in this application embodiment. Figure 1 ;

[0040] Figure 3 A schematic diagram of static scene construction provided in the embodiments of this application. Figure 2 ;

[0041] Figure 4 A schematic diagram of a test scenario provided in an embodiment of this application;

[0042] Figure 5 A flowchart illustrating the virtual test scenario construction method provided in this application embodiment. Figure 3 ;

[0043] Figure 6 A flowchart of traffic flow simulation provided for an embodiment of the present application is shown in FIG. 1.

[0044] Figure 7 A schematic diagram of an expressway provided for an embodiment of the present application is shown in FIG. 2.

[0045] Figure 8 A schematic diagram of connection between different road segments provided for an embodiment of the present application is shown in FIG. 3.

[0046] Figure 9 A schematic diagram of car-following under merging provided for an embodiment of the present application is shown in FIG. 4.

[0047] Figure 10 A schematic diagram of car-following under diverging provided for an embodiment of the present application is shown in FIG. 5.

[0048] Figure 11 A schematic diagram of a three-order Bezier curve provided for an embodiment of the present application is shown in FIG. 6.

[0049] Figure 12 A schematic diagram of vehicle conflict avoidance provided for an embodiment of the present application is shown in FIG. 7.

[0050] Figure 13 A structure schematic diagram of a virtual test scene construction device provided for an embodiment of the present application is shown in FIG. 8. Figure 1

[0051] Figure 14 A structure schematic diagram of a virtual test scene construction device provided for an embodiment of the present application is shown in FIG. 9. Figure 2 DETAILED DESCRIPTION

[0052] The technical solutions in the present application will be described below with reference to the accompanying drawings.

[0053] The present application will present various aspects, embodiments or features around a system which can include a plurality of devices, components, modules, etc. It should be understood and appreciated that each system can include additional devices, components, modules, etc., and / or can not include all of the devices, components, modules, etc. discussed in connection with the accompanying drawings. Furthermore, combinations of these solutions can also be used.

[0054] In addition, in the embodiments of the present application, the words such as "exemplary", "for example", etc. are used to represent an example, illustration or description. Any embodiment or design scheme described as "exemplary" in the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the word "exemplary" is intended to present the concept in a specific manner.

[0055] ​​In the embodiments of this application, "of", "corresponding (relevant)" and "corresponding" can sometimes be used interchangeably. It should be noted that when their differences are not emphasized, their meanings are consistent.

[0056] In the embodiments of this application, sometimes the subscript such as W1 may be mistakenly written as a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0057] The traffic scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. As those skilled in the art will know, with the evolution of road regulations and driving behavior regulations and the emergence of new traffic scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

[0058] Since the virtual test scenario is constructed based on real traffic scenarios, to facilitate understanding of the embodiments of this application, we will first use... Figure 1 The traffic scenario shown in the diagram serves as an example to illustrate the virtual test scenario applicable to the embodiments of this application. For example, Figure 1 A traffic scene diagram applicable to the virtual test scene construction method provided in the embodiments of this application.

[0059] like Figure 1 As shown, this traffic scenario includes, but is not limited to: traffic lights, traffic signs, stop lines, directional arrows, zebra crossings, lane dividers, road medians, and motor vehicles. Traffic lights, which direct traffic, are part of road infrastructure. Traffic lights generally consist of red, green, and yellow lights. A red light indicates "stop," a green light indicates "go," and a yellow light indicates "warning." Traffic signs are road facilities that use text or symbols to convey guidance, restrictions, warnings, and instructions. Figure 1 Traffic signs in traffic signs are used to instruct vehicles to slow down on the road ahead. A stop line is a solid white line perpendicular to the center line of a road intersection, indicating the position of vehicles waiting for the green light to give way. The stop line is a prohibitory marking under traffic signs. Directional arrows are traffic signs used to indicate the direction of travel for vehicles. Figure 1The two guide arrows in FIG. 1 show that the vehicle can go straight and the vehicle can go straight or right turn. The zebra crossing is a marking line that constitutes a pedestrian crossing, which is used to mark the walking range of pedestrians crossing the lane. The lane boundary is a traffic marking used to separate traffic flows in the same direction or in opposite directions. The lane boundary is generally divided into solid lines and dashed lines. The dashed line indicates that the vehicle can change lanes, and the solid line also indicates that the vehicle cannot change lanes. The road separation strip is used to separate opposite traffic flows to avoid serious traffic accidents caused by vehicles entering opposite lanes. The motor vehicle refers to a wheeled vehicle driven or pulled by a power device.

[0060] It should be understood that Figure 1 The virtual test scene construction scene can also include other traffic signs and road traffic markings in the simplified schematic diagram shown for ease of understanding. For example, other traffic signs can include direction signs, road construction safety signs, tourist area signs, etc.; other road traffic markings can include no overtaking lines, left turn waiting area lines, highway distance confirmation markings, etc.

[0061] It should be noted that Figure 2- Figure 11 The traffic scene shown in FIG. 1 is only an example. The virtual test scene construction method provided by the embodiments of the present application can also be applied to other traffic scenes, such as crossroads, T-shaped intersections, one-way roads, roundabouts, overpasses, highways, mountain roads, and rural roads, which will not be described here.

[0062] The virtual test scene construction method provided by the embodiments of the present application will be described in detail below. Figure 2 The virtual test scene construction method provided by the embodiments of the present application will be described in detail below.

[0063] Exemplarily, Figure 1 The flowchart of the virtual test scene construction method provided by the embodiments of the present application is shown in Figure 1 The virtual test scene construction method can be applied to the traffic scene shown in Figure 2 .

[0064] As shown in Figure 3 , the virtual test scene construction method includes the following steps:

[0065] S201, constructing a static ontology model in combination with road specifications and expert experience.

[0066] The road specifications are the specification design of the road by the state and / or region, such as the design of road layout and road infrastructure. The specification design of road layout includes but is not limited to the design of lane marking and road topological relationship. The specification design of road infrastructure includes but is not limited to the design of road separation strip, traffic sign, and traffic signal. The expert experience refers to the construction of the static ontology model by relying on the experience and knowledge of experts.

[0067] Figure 2Fig. 1 is a schematic diagram of a static scene construction according to an embodiment of the present application Figure 3 As shown in Figure 3 , parameters available for the simulation scene are divided into two categories: static layer and dynamic layer. The static layer corresponds to the static ontology. The static layer includes four types of parameters: road topology, road infrastructure, traffic control, and environment. The dynamic layer corresponds to the dynamic ontology, which includes one type of parameter: the behavior of traffic participants.

[0068] In combination with Figure 3 , the static ontology model is used to describe the design constraints of the static ontology, which includes one or more of the following: road topology, road infrastructure, traffic control, or environment. The road topology includes but is not limited to: road type, number of lanes and positional relationship, lane line, stop line, or arrow indication. The road infrastructure includes but is not limited to: road median, traffic sign, traffic signal. The traffic control refers to short-term planned control measures, including but not limited to: road construction, temporary road closure caused by major events. The environment refers to the environmental information of the virtual test scene, including but not limited to: weather, such as rainy day, sunny day; light, such as daytime, nighttime.

[0069] By way of example, the design constraints of the above-mentioned static ontology include one or more of the following: the positional relationship between roads, the positional relationship between roads and lanes, the positional relationship between lanes, the positional relationship between lanes and medians, the positional relationship between lane lines and lanes and / or medians, the positional relationship between traffic signs and lanes and / or medians.

[0070] The positional relationship between roads includes but is not limited to: connection between road segments through left-turn intersections, right-turn intersections, T-shaped intersections, roundabouts, or cross intersections. The positional relationship between roads and lanes includes but is not limited to: the type, width, or number of lanes set on the road. The type of lane can include one-way lane, two-way lane, motor lane, non-motor lane, etc. The positional relationship between lanes includes but is not limited to: adjacent lanes, lanes of the same road segment separated by lane dividers or central medians, or lanes of different road segments connected through left-turn intersections, right-turn intersections, T-shaped intersections, roundabouts, or cross intersections. The positional relationship between lanes and medians includes but is not limited to: lanes adjacent to medians on the left or right. The positional relationship between lane lines and lanes and / or medians includes but is not limited to: from the road center line, the central median, the solid lane line, the dashed lane line, the solid lane line, and the road outside median can be set in turn according to the position. The positional relationship between traffic signs and lanes and / or medians includes but is not limited to: traffic signs cannot be set on the lane, traffic signs can be suspended in the road, and traffic signs are placed on the road side median.

[0071] As shown in Figure 1As shown, after the static layer is constructed, it is necessary to define the class corresponding to the static layer, the object attribute of the class, the data attribute of the class, and the design rule of the class according to the parameters in the static layer. Thus, in a possible design scheme, the static ontology model is constructed in combination with the road specification and the expert experience, and the class corresponding to the static ontology is defined in combination with the road specification and the expert experience. Figure 3 The step S201 of constructing the static ontology model in combination with the road specification and the expert experience can include the following steps.

[0072] Step 11: Defining the static ontology class.

[0073] A class is a concept for describing a field. For example, a class of a road represents all roads, and one road is an instance of the class of the road. A class can have a subclass. For example, the road can be divided into urban roads and highways, or the road can be divided into expressway trunk roads, secondary trunk roads, and branch roads according to the level. Based on this concept, the static ontology class can be used to describe one or more of the following: a virtual test scene, a road, a median strip, a lane, a traffic sign, weather, or a light condition.

[0074] Step 12: Defining the static object attribute.

[0075] The static object attribute refers to the mapping relationship between one static ontology class and another static ontology class. The static object attribute can include the positional relationship between static objects. For example, the positional relationship between a lane and a median strip. The positional relationship includes but is not limited to: the median strip is left adjacent to the lane, and the median strip is right adjacent to the lane. The static object attribute can also include the inclusion relationship between static objects. For example, the inclusion relationship between a road, a lane, and a median strip. The inclusion relationship includes but is not limited to: the road includes the lane and the median strip. The static object attribute can also include the relationship between a virtual test scene and weather. The definition domain and the value domain of the static data attribute are defined in combination with the expert experience, and the static data attribute is exemplified by Table 1 as follows:

[0076] Table 1

[0077]

[0078] As shown in Table 1, the adjacent relationship of the lane includes the adjacent relationship between the lanes and the adjacent relationship between the lane and the median strip. For example, the median strip is left adjacent to the lane or the median strip is right adjacent to the lane. The inclusion and the included relationship includes: the road includes the lane and the median strip, and the lane and the median strip are included in the road. The relationship between the traffic sign and the lane includes that the traffic sign is suspended above the lane. The weather of the static scene can be rain, high temperature, and the like.

[0079] It should be understood that Table 1 is only a few examples of the above-mentioned static object attribute, and the static object in Table 1 can also include other relationships. For example, the relationship between the traffic sign and the lane can also include that the traffic sign is arranged on both sides of the lane.

[0080] It should be noted that the static object attributes shown in Table 1 are only a few examples. The static object attributes provided by the embodiments of the present application can also be applicable to the relationships between other static objects, such as, for example, the positional relationship between roads includes connection between road segments through left-turn intersections, right-turn intersections, T-shaped intersections, or cross intersections. For another example, the positional relationship between a road and a lane includes the lane type, width, or number of lanes provided on the road, and the like, which will not be described herein again.

[0081] Step 13, defining static data attributes.

[0082] The static data attributes are used to describe a parameter set of the static ontology class. For example, the data attributes of a lane can include, but are not limited to, the number of lanes and the width of the lane. The data attributes of a traffic sign can include, but are not limited to, the type and position of the traffic sign. The data attributes of a median strip can include, but are not limited to, the width and type of the median strip.

[0083] Step 14, defining static design rules.

[0084] The static design rules are used to describe the mapping relationship between the static ontology class, the static object attributes, and the static data attributes, and are used to determine the rationality of the generated virtual test scene.

[0085] The following illustrates the static design rules by way of example:

[0086] (1) For a road, the central median strip, the outer median strip of the road, the lane, and the shoulder need to be included.

[0087] (2) Between the lane and the median strip, the left-right adjacent rule needs to be followed, for example, from the center line of the road outward, the central median strip, the driving lane, the shoulder, and the outer median strip of the road can be sequentially provided according to the position.

[0088] (3) For a road with a single-lane number less than 3, the central median strip can not be used, and a marking line is used instead.

[0089] (4) The marking line between the lanes is a dashed line, and the marking line between the lane and the median strip is a solid line.

[0090] (5) The traffic sign needs to be suspended in the road or placed on the road side median strip.

[0091] It should be noted that the static design rules include, but are not limited to, the examples described above.

[0092] After the static ontology class, the static object attributes, the static data attributes, and the static design rules are defined, the static scene can be generated by traversing the static data attributes. However, the static data attributes are subject to the constraints of the static object attributes and the static design rules when being traversed. In this way, unreasonable static scenes can be avoided.

[0093] The static object attribute and the static design rule are both defined according to a static design constraint related to a road specification, that is, for the static design constraint, the road specification needs to be designed. For example, the road specification stipulates that the left-turn lane needs to be provided with a guide arrow on the lane to indicate the vehicle left turn, and the corresponding static design constraint needs to include: the left-turn lane is provided with a left-turn guide arrow. For another example, the road specification stipulates that a warning sign needs to be provided on both sides of the pedestrian sidewalk, and the corresponding static design constraint can be as shown in Figure 3

[0094] Based on the defined static object attribute and the static design rule, the static ontology can be constrained so that the static ontologies with the mapping relationship are associated. In this way, in the process of generating the static scene by the static ontology model, the associativity between the static ontologies can be considered, and then a reasonable static scene can be generated. Further, since the static object attribute and the static design rule are defined by the design constraint related to the road specification, when the road specification is updated, the static object attribute and the static design rule only need to be redefined according to the new design constraint, which facilitates the modification of the constructed static ontology model.

[0095] S202, constructing a dynamic ontology model based on the static ontology model.

[0096] The dynamic ontology model is used to describe the behavior constraint of the dynamic ontology, and the dynamic ontology includes one or more of the following: a vehicle, a pedestrian, or an animal. The vehicle can include a motor vehicle and a non-motor vehicle. Further, the motor vehicle can include a car, a bus, a truck, a motorcycle, and the like; and the non-motor vehicle can include a bicycle, a tricycle, and the like.

[0097] For example, the behavior constraint of the above dynamic ontology can include one or more of the following: a position relationship between the vehicle and the lane, a position relationship between the vehicles, a vehicle speed limit, a vehicle driving direction constraint, a vehicle turning constraint, a vehicle lane-changing constraint, a vehicle cutting-in constraint, and a vehicle cutting-out constraint.

[0098] The position relationship between the vehicle and the lane includes but is not limited to that the vehicle needs to be located on the lane. The position relationship between the vehicles includes but is not limited to that different vehicles cannot be located at the same position; the front vehicle and the rear vehicle are located on the same lane, and the relative distance between the two vehicles is less than or equal to a set value, then the front vehicle and the rear vehicle have a following relationship. The set value can be set according to expert experience. For example, if the relative distance between the front vehicle and the rear vehicle on the same lane is less than 50 meters, then it can be considered that the front vehicle and the rear vehicle have a following relationship.

[0099] ​The vehicle speed limit includes but is not limited to: there are corresponding speed limit requirements on different road sections, and the vehicle needs to travel according to the speed limit requirements of the road section when traveling on the road section. The vehicle driving direction constraint includes but is not limited to: the vehicle needs to travel according to the direction indicated by the traffic sign. For example, the traffic sign indicates that the front intersection can only go straight, and the vehicle can only go straight at the front intersection.

[0100] The vehicle turning constraint includes but is not limited to: when the vehicle needs to turn, it needs to determine whether to turn according to the surrounding vehicle conditions and whether the lane boundary is a dashed line. For example, before the front vehicle turns left, it needs to confirm that the lane boundary on the left side of the vehicle is a dashed line, and the relative safety distance between the front vehicle and the rear vehicle meets the turning requirement, and then the front vehicle can turn left; or when the vehicle is located on the leftmost lane of the lane, the vehicle cannot turn left again; or when the vehicle is located on the rightmost lane of the lane, the vehicle cannot turn right again.

[0101] The vehicle cut-in constraint includes but is not limited to: when the vehicle needs to cut in, it needs to determine whether to cut in according to the surrounding vehicle conditions; for example, before the vehicle cuts in to the left, it needs to confirm that the relative safety distance between the vehicle and the rear vehicle meets the cut-in requirement, and then the vehicle can cut in to the left. The vehicle cut-out constraint includes but is not limited to: when the vehicle needs to cut out, it needs to determine whether to cut out according to the surrounding vehicle conditions; for example, before the vehicle cuts out to the right, it needs to confirm that the relative safety distance between the vehicle and the rear vehicle meets the cut-out requirement, and then the vehicle can cut out to the right.

[0102] As shown in FIG. 8, after the dynamic layer is constructed, the classes corresponding to the dynamic layer, the object attributes of the classes, the data attributes of the classes, and the design rules of the classes need to be defined according to the parameters in the dynamic layer. Thus, in a possible design scheme, in combination with FIG. 8, the above S202 of constructing the dynamic ontology model can include the following steps: Dynamic object properties Explanation The above S202 of constructing the dynamic ontology model can include the following steps:

[0103] Step 21, defining a dynamic ontology class.

[0104] The dynamic ontology class is used to describe one or more of the following: vehicle, pedestrian, or animal corresponding to the dynamic ontology. In this step 21, the vehicle needs to be divided into motor vehicle and non-motor vehicle. Further, the motor vehicle can include vehicles such as car, bus, truck, and motorcycle; and the non-motor vehicle can include vehicles such as bicycle and tricycle.

[0105] Step 22, defining dynamic object attributes.

[0106] ​The dynamic object attribute is used to describe the mapping relationship between dynamic ontology classes and the constraint relationship between the dynamic ontology and the static ontology. The mapping relationship between dynamic ontology classes can include the car-following relationship between vehicles, which includes but is not limited to the relative distance between vehicles. The constraint relationship between the dynamic ontology and the static ontology can include the relationship between the vehicle and the lane, which includes but is not limited to whether the vehicle is located on the lane. The definition domain and value domain of the dynamic object attribute are defined in combination with expert experience, and the following Table 2 illustrates the dynamic data attribute:

[0107] Table 2

[0108] Domain Value range On lane / with vehicle Vehicle's relation to lane Vehicle Driving lane Following / being followed Inter-vehicle following relation Vehicle Vehicle Lane change motivation Vehicle's lane change motivation Vehicle Driving lane Lane change scenario Vehicle's lane change scenario Scenario Lane Cut-in scenario Vehicle's cut-in scenario Scenario Lane Figure 4 Figure 4

[0109] As shown in Table 2, the dynamic object attribute of being located on the lane / having a vehicle means that the positional relationship between the vehicle and the lane can include that the vehicle is located on the lane or there is a vehicle on the lane. The definition domain corresponding to being located on the lane or having a vehicle is a vehicle, and the value domain corresponding thereto is a driving lane. The dynamic object attribute of car-following / be followed means that the car-following relationship between vehicles can include that the following vehicle meets the car-following condition with the leading vehicle or the following vehicle has followed the leading vehicle to drive. The car-following condition is that the leading vehicle and the following vehicle are located on the same lane, and the relative distance between the two vehicles is less than or equal to a set value. The set value can be set according to expert experience. For example, if the relative distance between the leading vehicle and the following vehicle on the same lane is less than 50 meters, it can be considered that the leading vehicle and the following vehicle have a car-following relationship. The definition domain corresponding to car-following / be followed is a vehicle, and the value domain corresponding thereto is a vehicle. Similarly, the dynamic object attribute of lane-changing motive means the lane-changing motive of the vehicle. The definition domain corresponding to the lane-changing motive is a vehicle, and the value domain corresponding thereto is a vehicle. The dynamic object attribute of lane-changing scene means the lane-changing scene of the vehicle. The definition domain corresponding to the lane-changing scene is a scene, and the value domain corresponding thereto is a lane. The dynamic object attribute of cut-in scene means the cut-in scene of the vehicle. The definition domain corresponding to the cut-in scene is a scene, and the value domain corresponding thereto is a lane.

[0110] It should be understood that Table 2 is only a few examples of the above-mentioned dynamic object attributes, and the dynamic object attributes can also include other relationships. For example, the relationship between the vehicle and the lane can also include that the vehicle turns on the lane according to the corresponding directional arrow. For example, the vehicle drives on the left-turn lane, and after reaching the front intersection, it can only turn left.

[0111] In addition, the dynamic object attribute can also be applicable to the relationship between other static objects, such as the relationship between the vehicle and the road, which can also include the speed limit requirements of different road sections. For example, the minimum speed limit on the highway is 60 kilometers per hour, and the maximum speed limit is 120 kilometers per hour. When the vehicle drives on the highway, it needs to drive according to the speed limit requirements of the highway. For another example, the positional relationship between the vehicle and the traffic sign can also include that the vehicle needs to drive according to the direction indicated by the traffic sign, and the like, which will not be described herein.

[0112] Step 23, defining dynamic data attributes.

[0113] Wherein, the dynamic data attributes are used to describe the parameter set of the dynamic ontology class. The following is illustrated by Table 3 for static data attributes and dynamic data attributes:

[0114] Table 3

[0115]

[0116] As shown in Table 3, when the class is lane, the data attributes of the lane can include lane number and lane width. Wherein, the lane number represents the number of lanes on a road. For example, when the lane number takes the value of 1 in the reference value range in Table 3, it means that there is only one lane on a road. The lane width represents the width of the lane. The value range of the lane width in Table 3 is “2.75:0.05:3.75”, which means that the value range of the lane width is 2.75 meters to 3.75 meters, and the step is 0.05 meters, i.e., the lane width can be 2.75 meters, 2.80 meters, …, 3.70 meters, 3.75 meters.

[0117] In Table 3, when the class is a separation belt, the data attributes of the separation belt can include width and type. The value range of the separation belt width is “1:0.1:3”, which means that the value range of the separation belt width is 1 meter to 3 meters, and the step is 0.1 meters, i.e., the separation belt width can be 1 meter, 1.1 meters, …, 2.9 meters, 3.0 meters. The type of the separation belt can include hard separation belt, flexible separation belt, and green separation belt.

[0118] In Table 3, when the class is a vehicle, the data attributes of the vehicle include lane coordinate, longitudinal coordinate, speed, and lane changing motive. The lane coordinate of the vehicle refers to which lane the vehicle is located on, therefore, the reference value range of the lane coordinate is less than the lane number or equal to the lane number. For example, there are 2 lanes on a road, and the coordinates of the first lane and the second lane are 1 and 2 respectively in the order from left to right. When the lane coordinate of the vehicle on the road is 1, it means that the vehicle is located on the first lane; when the lane coordinate of the vehicle on the road is 2, it means that the vehicle is located on the second lane. The value of the longitudinal coordinate of the vehicle corresponds to the length of the lane, therefore, the reference value range of the longitudinal coordinate of the vehicle is less than the lane length or equal to the lane length. The value range of the speed of the vehicle is “0:10:120 km / h”, which means that the value range of the speed of the vehicle is 0 to 120 km / h, and the step is 10 km / h, i.e., the speed of the vehicle can be 0 km / h, 10 km / h, …, 110 km / h, 120 km / h. When the vehicle has a lane changing motive, the value of the lane changing motive is yes; when the vehicle does not have a lane changing motive, the value of the lane changing motive is no.

[0119] In Table 3, when the class is traffic sign, the data attributes of the traffic sign can include the kind, the lateral position and the longitudinal position. Among them, the value of the kind of the traffic sign can be speed limit sign, indication sign. According to the static design constraint, the traffic sign cannot be set in the middle of the road. When the traffic sign is set on both sides of the road, the lateral position of the traffic sign needs to be greater than or equal to the road width. The value of the longitudinal coordinate of the traffic sign corresponds to the length of the lane, so the reference value range of the longitudinal coordinate of the traffic sign is less than or equal to the length of the lane.

[0120] It should be noted that the above Table 3 is only a few examples of the above static data attributes and dynamic data attributes. In actual application, other static data attributes and dynamic data attribute instances can also be used, which are not listed one by one here.

[0121] Step 24, defining dynamic design rules.

[0122] Among them, the dynamic design rule is used to describe the mapping relationship between the dynamic ontology class, the dynamic object attribute and the dynamic data attribute, and the dynamic design rule is used to determine the rationality of the generated test scene.

[0123] After defining the dynamic ontology class, the dynamic object attribute, the dynamic data attribute and the dynamic design rule, the dynamic scene can be generated by traversing the dynamic data attribute. However, when traversing the dynamic data attribute, it is constrained by the dynamic object attribute and the dynamic design rule. In this way, unreasonable dynamic scenes can be avoided.

[0124] The dynamic object attribute and the dynamic design rule are both defined according to the dynamic behavior constraint related to the driving behavior specification, that is, the dynamic behavior constraint of the dynamic ontology needs to be designed according to the driving behavior specification. For example, the driving behavior specification stipulates that motor vehicles cannot drive on non-motor vehicle lanes, so the dynamic behavior constraint of the corresponding motor vehicle needs to include: allow motor vehicles to drive on motor vehicle lanes, prohibit motor vehicles to drive on non-motor vehicle lanes. For example, the driving behavior specification stipulates that vehicles cannot drive at high speed, so the dynamic behavior constraint of the corresponding vehicle needs to include: the vehicle needs to drive at the speed indicated by the speed limit sign. If the speed limit sign indicates that the maximum driving speed is 60 kilometers per hour, the maximum speed of the vehicle cannot exceed 60 kilometers per hour.

[0125] It should be noted that the dynamic object attribute and the dynamic design rule can be defined according to a scene design requirement in addition to the definition according to the dynamic behavior constraint related to the driving behavior specification. The scene design requirement includes a special scene that does not conform to the behavior constraint. For example, the special scene that does not conform to the behavior constraint can include a scene in which an animal activity exists in the driving direction of the vehicle, a person enters the motor vehicle lane, and the like. When the special scene that does not conform to the behavior constraint exists, the driving operation of the vehicle can be controlled by a random disturbance model to match various situations that can be encountered in a real traffic scene. For example, when the animal activity exists in the driving direction of the vehicle, the random disturbance model can control the vehicle to brake to wait for the animal to leave the driving lane.

[0126] Since the dynamic object attribute and the dynamic design rule are defined by the behavior constraint related to the driving behavior specification, when the driving behavior specification is updated, the dynamic object attribute and the dynamic design rule only need to be redefined according to the new behavior constraint, and the dynamic ontology model constructed is convenient to modify.

[0127] The following illustrates the dynamic design rule by way of example:

[0128] 1) The vehicle needs to be located on the lane when driving. Among them, the non-motor vehicle is only allowed to drive on the non-motor vehicle lane; and the motor vehicle is only allowed to drive on the motor vehicle lane.

[0129] 2) Different vehicles are located at different positions. That is, different vehicles cannot be located at the same position.

[0130] 3) For vehicles driving in the same direction, the front vehicle and the rear vehicle need to satisfy a safety distance (responsibility sensitive safety, RSS), such as a critical safety distance. The critical safety distance refers to: when the rear vehicle encounters the front vehicle suddenly braking, the limit distance between the rear vehicle and the front vehicle. At the limit distance, the rear vehicle can stop by braking without colliding with the front vehicle. If the limit distance between the rear vehicle and the front vehicle is less than the limit distance, the rear vehicle will collide with the front vehicle even if it brakes. The critical safety distance can be obtained by the following formula:

[0131]

[0132] Among them, S d is the critical safety distance, is the braking distance of the front vehicle, is the braking distance of the rear vehicle; is the reaction time of the front vehicle, is the reaction time of the rear vehicle; v 1 is the speed of the front vehicle, v 2 is the speed of the rear vehicle.

[0133] 4) When the vehicle changes lane in the leftmost lane or the rightmost lane, there are restrictions. For example, the vehicle cannot change lane to the left when it is in the leftmost lane, and the vehicle cannot change lane to the right when it is in the rightmost lane.

[0134] 5) When the vehicle changes lane, the vehicle first confirms the surrounding vehicle conditions, and then determines whether to change lane. For example, when there is no vehicle around, the vehicle can change lane if the conditions for changing lane are met. For another example, when the front vehicle changes lane to the left, if the rear vehicle in the left lane is very close to the front vehicle, the vehicle cannot change lane if the conditions for changing lane are not met.

[0135] 6) Whether there is a car-following relationship between two vehicles needs to determine whether the car-following conditions between the two vehicles are met. The car-following conditions can include that the two vehicles need to be in the same lane, and the relative distance between the two vehicles meets the value set by humans. For example, if the two vehicles are in the same lane and the relative distance between the two vehicles is less than 50 meters, it is considered that there is a car-following relationship between the two vehicles.

[0136] 7) To determine that the vehicle is in a cut-in scenario, the following conditions need to be met: the vehicle has a lane-changing tendency, and the surrounding vehicle conditions meet the conditions for the vehicle to change lane, that is, the vehicle can safely cut into the lane that needs to be changed. The vehicle is in a cut-in scenario.

[0137] It should be noted that the dynamic design rules include but are not limited to the examples described above.

[0138] Figure 4 A schematic diagram of a test scenario provided for the embodiments of the present application. In Figure 4 the dynamic ontology includes a vehicle, and the static ontology includes: a road, a driving lane, a separation belt, a lane, an outside separation belt of the road, and a central separation belt.

[0139] Figure 3 The relationship between different ontologies in a test scenario is shown. As Figure 3 shown, the arrow between the road and the driving lane indicates that the road contains the driving lane. The arrow between the road and the outside separation belt of the road indicates that the outside of the road is provided with a separation belt. The arrow between the road and the central separation belt indicates that the central part of the road is provided with a separation belt. The arrow between the driving lane and the lane indicates that the lane is provided with multiple driving lanes. The arrow between the vehicle and the lane indicates that the vehicle needs to drive on the lane. The arrow between the vehicle and the central separation belt indicates that the vehicle cannot cross the central separation belt when driving. The arrow between the separation belt and the driving lane indicates that the separation belt separates different driving lanes.

[0140] The behavior of the dynamic ontology is constrained by defining dynamic object attributes and dynamic design rules, so that the dynamic ontologies with mapping relationship are associated with each other and with static ontologies. In this way, in the process of generating a dynamic scene by the dynamic ontology model, the association between the dynamic ontologies and between the dynamic ontologies and the static ontologies is considered, and then a reasonable and complete dynamic scene is generated.

[0141] The static scene and the dynamic scene are illustrated below by Table 4.

[0142] Table 4

[0143]

[0144] As shown in Table 4, the scene constructed based on parameters such as road topology, road infrastructure, traffic control and environment is a static scene, and the scene constructed based on parameters such as traffic participants and behaviors is a dynamic scene. Among them, the functional scene refers to a scene expressed in natural language and understood by humans; the logical scene refers to a scene understood by computers through description logic; and the specific scene refers to a scene generated after each parameter in the logical scene takes a specific value.

[0145] As shown in Table 4, in the functional scene corresponding to the parameter such as road topology, the three-lane road with curvature indicates that the number of lanes of the road is three, and the road has a curve. In the logical scene corresponding to the parameter such as road topology, the lane width takes a value in the range of 3 to 3.5 meters, and the curvature radius of the curve takes a value in the range of 0.6 to 0.9 kilometers. In the specific scene corresponding to the parameter such as road topology, the value of the lane width is 3.2 meters, and the value of the curvature radius of the curve is 0.7 kilometers.

[0146] As shown in Table 4, in the functional scene corresponding to the road infrastructure, the speed limit 100 km / h sign indicates that there is a traffic sign on the road, which indicates that the maximum vehicle speed cannot exceed 100 km / h when driving on the front road section. In the logical scene corresponding to the road infrastructure, the value range of the position of the traffic sign is 0 to 200 meters, indicating that the traffic sign is longitudinally arranged in the range of 200 meters according to the driving lane direction. In the specific scene corresponding to the traffic sign, the value of the position of the traffic sign is 150 meters, indicating that the traffic sign is longitudinally arranged at 150 meters according to the driving lane direction.

[0147] As shown in Table 4, the functional scenarios corresponding to the traffic participants and behaviors include that the ego vehicle is driving on the central lane, and there is a congestion condition in the front road section, and the vehicles in the congestion condition are moving slowly. In the logical scenarios corresponding to the traffic participants and behaviors, the length of the front congestion road section is 10-200 meters, the moving speed of the vehicles in the congestion condition is 0-30 km / h, the distance between the ego vehicle and the front congestion road section is 50-300 meters, and the speed of the ego vehicle is 80-130 km / h. In the specific scenarios corresponding to the traffic participants and behaviors, the length of the front congestion road section is 40 meters, the moving speed of the vehicles in the congestion condition is 30 km / h, the distance between the ego vehicle and the front congestion road section is 200 meters, and the speed of the ego vehicle is 100 km / h.

[0148] As shown in Table 4, the functional scenarios corresponding to the environment include that the season is summer and it is a rainy day. In the logical scenarios corresponding to the environment, the temperature is 10-40 degrees Celsius, and the rainfall is 20-100 microns. In the specific scenarios corresponding to the environment, the temperature is 20 degrees Celsius, and the rainfall is 30 microns.

[0149] It should be noted that in Table 4, each scenario corresponding to the traffic control is blank, indicating that there is no control measure in the scenario. In addition, Table 4 above is only a few examples of the static scenarios and dynamic scenarios. In actual application, other static scenarios and dynamic scenarios may also be used, which are not listed one by one here.

[0150] In S203, the driving trajectory of the dynamic ontology is determined according to the design constraints of the static ontology and the behavior constraints of the dynamic ontology in combination with the traffic flow simulation.

[0151] The traffic flow simulation refers to the traffic flow constructed in the simulation scenario, or the simulation of the traffic flow in the real scenario, which is used to construct the dynamic simulation scenario and test the related functions and performance of the unmanned vehicle. Figure 5 As shown in Table 4, the functional scenarios corresponding to the traffic participants and behaviors include that the ego vehicle is driving on the central lane, and there is a congestion condition in the front road section, and the vehicles in the congestion condition are moving slowly. In the logical scenarios corresponding to the traffic participants and behaviors, the length of the front congestion road section is 10-200 meters, the moving speed of the vehicles in the congestion condition is 0-30 km / h, the distance between the ego vehicle and the front congestion road section is 50-300 meters, and the speed of the ego vehicle is 80-130 km / h. In the specific scenarios corresponding to the traffic participants and behaviors, the length of the front congestion road section is 40 meters, the moving speed of the vehicles in the congestion condition is 30 km / h, the distance between the ego vehicle and the front congestion road section is 200 meters, and the speed of the ego vehicle is 100 km / h.

[0152] In a possible design scheme, the driving trajectory of the dynamic ontology is determined according to the design constraints of the static ontology and the behavior constraints of the dynamic ontology in combination with the traffic flow simulation. Figure 3 The above S203, in combination with the traffic flow simulation, determines the driving trajectory of the dynamic ontology according to the design constraints of the static ontology and the behavior constraints of the dynamic ontology, which can include the following steps:

[0153] In S203, the driving trajectory of the dynamic ontology is determined according to the design constraints of the static ontology and the behavior constraints of the dynamic ontology in combination with the traffic flow simulation.

[0154] Specifically, determining the initial state of the dynamic ontology based on the design constraints of the static ontology, the behavioral constraints of the dynamic ontology, and the scenario design requirements can include the following steps: determining the initial state of the dynamic ontology based on the design constraints of the static ontology, the behavioral constraints of the dynamic ontology, the scenario design requirements, the test objective, and the behavioral model of the dynamic ontology. The design constraints of the static ontology, the behavioral constraints of the dynamic ontology, and the scenario design requirements have already been mentioned above. The test objective and the behavioral model of the dynamic ontology will be elaborated in detail below and will not be repeated here. Furthermore, examples of the initial state values ​​of the dynamic ontology can be found in Table 4 above, showing the values ​​of traffic participants and behaviors; these will not be repeated here.

[0155] Figure 3 A flowchart illustrating the virtual test scenario construction method provided in this application embodiment. Figure 5 .like Figure 5 and Figure 6 As shown, the trajectory of a dynamic entity needs to be determined by its initial state and temporal trajectory. The temporal trajectory refers to the trajectory of the dynamic entity over a future period.

[0156] like Figure 6 As shown, an initial state module can be set in the dynamic ontology. This initial state module is used to generate the initial state of the dynamic ontology. This initial state module can set scene initialization state generation rules and scene initialization cases. The scene initialization state generation rules define the initial state of the dynamic ontology.

[0157] The initial state includes basic information such as the dynamic entity's position, velocity, and heading angle, as well as behavioral information. Behavioral information includes action parameters that the dynamic entity will perform over a future period. For example, action parameters may include, but are not limited to: lane change, left turn, straight ahead, right turn, and U-turn. Behavioral information may also include the driver's driving style parameters. For example, driving style parameters may include, but are not limited to: comfort deceleration, desired speed, maximum acceleration, reaction time, and desired stopping distance.

[0158] The behavioral model of the dynamic ontology includes one or more of the following: car-following model, lane-changing model, traffic light response model, random interference model, bus and pedestrian behavior model, gap acceptance model, merging model, cooperation model, or conflict avoidance model. It should be noted that the behavioral model of the dynamic ontology will be explained in step 32 in conjunction with traffic flow simulation.

[0159] Step 32: Combine traffic flow simulation to determine the driving trajectory of the dynamic entity based on its initial state.

[0160] For example, Figure 7- Figure 12A traffic flow simulation flowchart is provided for embodiments of the present application. As shown in Figure 7 the traffic flow simulation can include the following steps:

[0161] Step 321, initialize the road network according to the road network structure, path generation, etc. model, and define the vehicle flow, origin-destination (OD) flow, etc. parameters on the road network.

[0162] Step 322, update the road network state.

[0163] The updating of the road network state refers to obtaining the road network information around the vehicle and updating the state of the traffic participants around the vehicle.

[0164] Step 323, the vehicle can be initialized according to the vehicle arrival model.

[0165] The vehicle arrival model refers to that when the traffic participants enter the road network, the vehicle state can be initialized based on the initialization module according to the vehicle flow, origin-destination flow, etc. information on the road network.

[0166] Step 324, select the vehicle in turn according to the road from the downstream to the upstream.

[0167] The selection of the vehicle refers to the calculation of the vehicle state in the road network in turn, and the updating of the calculated vehicle state.

[0168] Step 325, update the vehicle according to one or more of the following: lane selection model, car following model, lane changing model, signal light reaction model, random disturbance model, bus and pedestrian behavior model, gap acceptance model, merging model, cooperation model, or conflict avoidance model.

[0169] Step 326, judge whether the updated vehicle reaches the end of the lane.

[0170] The judgment method can be to compare whether the position of the updated vehicle is consistent with the position of the end of the lane. If the position of the updated vehicle is consistent with the position of the end of the lane, the updated vehicle reaches the end of the lane, and it is continued to judge whether the updated vehicle reaches the travel end point. For example, the vehicle position can be obtained in real time, and it is judged whether the vehicle reaches the set end point based on the vehicle position.

[0171] If the updated vehicle reaches the travel end point, the updated vehicle is deleted from the traffic flow. If the updated vehicle does not reach the travel end point or the position of the updated vehicle is not consistent with the position of the end of the lane, the updated vehicle is executed.

[0172] Step 327, judge whether the updated vehicle is the last vehicle.

[0173] Exemplarily, the last vehicle in the list which needs to calculate the updated vehicle state can be determined as the last vehicle. If the updated vehicle is not the last vehicle, return to step 324. If the updated vehicle is not the last vehicle, the dynamic scene can be output in the form of animation through visualization technology.

[0174] Step 328, determine whether it is the simulation termination time.

[0175] If it is the simulation termination time, end the simulation operation. If it is not the simulation termination time, perform the simulation of the next simulation step and return to the step of updating the road network state.

[0176] The above will be described in detail below Figure 7 The behavior model of the dynamic ontology is described in detail.

[0177] The car-following model can include a same-lane car-following model, a lane-changing car-following model, a car-following model under merging, and a car-following model under diverging.

[0178] The same-lane car-following model is applicable to a scenario in which the following vehicle (i.e., the controlled vehicle involved in the following formula) does not perform lane changing, and is used to simulate the behavior of the following vehicle following the leading vehicle in the scenario. In the scenario in which the following vehicle does not perform lane changing, the same-lane car-following model can control the behavior of the following vehicle according to the motion state information of the leading vehicle. The motion state information can include the position, speed, and the like of the leading vehicle. Alternatively, in the traffic state from congestion to non-congestion, and when the following vehicle follows the leading vehicle, the same-lane car-following model can adopt an intelligent driver model. The formula of the intelligent driver model is as follows:

[0179]

[0180]

[0181] In the above two formulas, is the acceleration of the controlled vehicle, v is the speed of the controlled vehicle, v0 is the desired speed of the controlled vehicle, and Δv is the difference between the speed of the controlled vehicle and the speed of the leading vehicle; s * is the desired distance between the controlled vehicle and the leading vehicle, s0 is the static safety distance, s is the distance between the controlled vehicle and the leading vehicle, s1 is the speed-related safety distance selection parameter of the controlled vehicle; a is the comfortable deceleration, b is the acceleration exponent, and T is the reaction time.

[0182] Lane-changing car-following model: for the rear vehicle with the motivation of lane-changing but without the completion of lane-changing due to insufficient gap, the lane-changing car-following model needs to control the rear vehicle to stop and wait at the end of the path. Until there is a suitable gap, the lane-changing car-following model controls the rear vehicle to perform lane-changing. The lane-changing car-following model needs to calculate the acceleration of the rear vehicle following the front vehicle and the acceleration (i.e. deceleration) of the rear vehicle to the stopping point, and select the more conservative acceleration (i.e. the acceleration of the rear vehicle following the front vehicle is smaller and / or the deceleration is larger) as the final following acceleration.

[0183] Exemplarily, Figure 7 A schematic diagram of an expressway is provided for the embodiments of the present application. Figure 8 The expressway shown includes a ramp, a first lane, a second lane, and a third lane. If a vehicle needs to change lanes to enter the ramp, there will be a minimum lane-changing distance between the vehicle and the ramp in the lane direction. If the distance between the vehicle and the ramp is less than the minimum lane-changing distance, the vehicle cannot ensure driving safety when changing lanes to enter the ramp.

[0184] Each lane corresponds to a minimum lane-changing distance. For example, in Figure 8 , if the vehicle is located on the third lane, the minimum lane-changing distance between the vehicle and the ramp when the vehicle needs to change lanes can be 80 meters. That is, if the vehicle is located on the third lane, the vehicle can ensure driving safety only when the distance between the vehicle and the ramp is greater than 80 meters before completing lane-changing. If the vehicle is located on the second lane, the minimum lane-changing distance between the vehicle and the ramp when the vehicle needs to change lanes is 40 meters. That is, if the vehicle is located on the second lane, the vehicle can ensure driving safety only when the distance between the vehicle and the ramp is greater than 40 meters before completing lane-changing. If the vehicle is located on the first lane, as long as the vehicle does not miss the ramp, the vehicle can change lanes to enter the ramp. It should be understood that the minimum lane-changing distance can be adjusted according to actual needs.

[0185] It should be noted that when the vehicle has the motivation to enter the ramp, the first lane near the ramp is the desired lane, i.e. the vehicle needs to change lanes to enter the first lane. Assuming that there is a situation that there are vehicles waiting to merge on the desired lane, and the vehicles on the second lane and the third lane also need to wait at the stopping point for a suitable gap to change lanes. In this case, if the stopping points of the vehicles on the second lane and the third lane are at the same place, the vehicles on the second lane and the third lane are likely to have no way to merge into the desired lane, causing congestion. Therefore, the stopping point of the vehicle on the lane farther from the desired lane should be located more upstream. That is, compared with the vehicle on the second lane, the stopping point of the vehicle on the third lane is farther from the ramp.

[0186] Exemplarily, Figure 8 A schematic diagram of the connection between different road sections is provided for the embodiments of the present application. As shown inFigure 9 As shown in FIG. 7, road section A includes lane 0, lane 1, and lane 2, vehicle 1 travels on lane 0, and vehicle 2 travels on lane 1. Road section B includes lane 3, lane 4, lane 5, and lane 6, vehicle 3 travels on lane 3, and vehicle 4 travels on lane 5. Path 10 is a path connecting lane 0 and lane 3, path 11 is a path connecting lane 0 and lane 4, path 12 is a path connecting lane 1 and lane 5, and path 13 is a path connecting lane 2 and lane 6. Road section D includes lane 7, lane 8, and lane 9. Path 15 is a path connecting lane 3 and lane 7, path 16 is a path connecting lane 4 and lane 8, path 17 is a path connecting lane 5 and lane 9, path 14 is a path connecting lane 0 and road section C, and path 18 is a path connecting lane 6 and road section E.

[0187] As shown in FIG. 8, on road section B, the expected lane of a right-turn vehicle is lane 3, the expected lane of a straight vehicle can include lane 4, lane 5, and lane 6, and the expected lane of a left-turn vehicle is lane 6. On road section A, the expected lane of a turning or straight vehicle needs to be determined by road section B downstream. For example, to find the expected lane of a right-turn vehicle on road section A, the lane of a right-turn vehicle on road section B, i.e., lane 3, is found. Then, the lane connected to lane 3 on road section A, i.e., lane 0, is deduced, which is the expected lane of a right-turn vehicle on road section A. Similarly, the expected lanes of a straight vehicle on road section A are lane 0 and lane 1, and the expected lane of a left-turn vehicle on road section A is lane 2. Figure 9

[0188] For the following model under merging: merging means that multiple lanes on an upstream road section are connected to one lane on a downstream road section. Please refer to FIG. 9. Figure 9 Figure 9 FIG. 10 is a schematic diagram of following under merging provided by an embodiment of the present application. Figure 10 As shown in FIG. 10, road section A includes lane 0, lane 1, lane 2, and lane 3, and road section B includes lane 4, lane 5, and lane 6. Vehicle 3 travels on lane 4, and vehicle 4 travels on lane 6. Path 7 is a path connecting lane 0 and lane 4, path 8 is a path connecting lane 1 and lane 4, path 9 is a path connecting lane 2 and lane 5, and path 10 is a path connecting lane 3 and lane 6.

[0189] As shown in FIG. 11, on road section B, the expected lane of a right-turn vehicle is lane 4, the expected lane of a straight vehicle can include lane 5 and lane 6, and the expected lane of a left-turn vehicle is lane 6. On road section A, the expected lane of a turning or straight vehicle needs to be determined by road section B downstream. For example, to find the expected lane of a right-turn vehicle on road section A, the lane of a right-turn vehicle on road section B, i.e., lane 4, is found. Then, the lane connected to lane 4 on road section A, i.e., lane 0, is deduced, which is the expected lane of a right-turn vehicle on road section A. Similarly, the expected lanes of a straight vehicle on road section A are lane 0 and lane 1, and the expected lane of a left-turn vehicle on road section A is lane 2. Figure 10 ​​As shown, vehicle 1 is traveling on path 8, and vehicle 2 is traveling on path 7. In this case, if vehicle 1 and vehicle 2 enter the merging range, it is necessary to determine which vehicle is the leading vehicle in the car-following model. The merging range refers to the distance between a vehicle and the end of the path within a first preset value range. For example, if the distance between a vehicle and the end of the path is less than 30 meters, it can be considered that the vehicle has entered the merging range. The process of determining the leading vehicle in the car-following model under merging is as follows: Obtain the first distance between vehicle 1 and the end of path 8, and the second distance between vehicle 2 and the end of path 7. Compare the magnitudes of the first and second distances; the vehicle corresponding to the smallest distance between the first and second distances is the leading vehicle in the car-following model.

[0190] For the car-following model under diversion: diversion refers to a connection between a lane on an upstream road segment and multiple lanes on a downstream road segment. Please refer to [reference needed]. Figure 10 , Figure 10 This is a schematic diagram of car-following under traffic splitting provided in an embodiment of this application. Figure 10 In the diagram, road segment A includes lanes 0, 1, and 2, and road segment B includes lanes 3, 4, 5, and 6. Path 7 connects lane 0 and lane 3, path 8 connects lane 0 and lane 4, path 9 connects lane 1 and lane 5, and path 10 connects lane 2 and lane 6.

[0191] like Figure 11 As shown, if vehicle 3 enters the diversion range, it is necessary to determine which vehicle is the preceding vehicle in the diversion. The diversion range refers to the distance between the vehicle and the end of the path within a second preset value range. For example, if the distance between the vehicle and the end of the path is less than 20 meters, the vehicle can be considered to have entered the diversion range. The preceding vehicle in the diversion refers to a vehicle whose rear end has not yet completely exited the lane on the upstream road segment, and this lane is connected to multiple lanes on the downstream road segment. In the car-following model under the diversion, the preceding vehicle in the diversion is used as the car-following object. For example, Figure 11 Vehicle 2 is the vehicle in front of the diverted vehicle, and vehicle 3 is following vehicle 2.

[0192] For lane-changing models: Lane-changing behavior is the process by which a driver changes lanes based on their own driving characteristics and the status information of surrounding vehicles. Lane changing is divided into mandatory lane changing (MLC) and discretionary lane changing (DLC). Both mandatory and discretionary lane changing can include the following four steps:

[0193] Step 41: Generate lane change motivation.

[0194] The following lists the conditions for generating lane-changing motives in descending order of priority.

[0195] (1) If it is detected that the current lane of the vehicle is not the desired lane, a forced lane-changing motivation is generated. It should be noted that once the forced lane-changing motivation is generated, it will not disappear until the lane change is completed, even if there is no lane-changing gap.

[0196] (2) If the speed of the host vehicle is greater than the speed of the front vehicle, the speed of the front vehicle is greater than the speed of the front vehicle of the front vehicle, and the distance between the host vehicle and the front vehicle on the target lane is greater than 2 times the length of the host vehicle plus the distance between the host vehicle and the front vehicle on the current lane, an arbitrary lane-changing motivation is generated. The target lane can be the desired lane or the lane between the vehicle and the desired lane.

[0197] (3) If the speed of the host vehicle is less than the desired speed (or the speed limit of the lane) by 20 km / h or less, the speed of the front vehicle is less than the speed of the host vehicle by 20% or more, the speed of the front vehicle on the target lane is greater than the speed of the front vehicle on the current lane by 10 km / h or more, and the distance between the host vehicle and the front vehicle on the target lane is greater than 2 times the length of the host vehicle plus the distance between the host vehicle and the front vehicle on the current lane, an arbitrary lane-changing motivation is generated.

[0198] (4) If the front vehicle on the current lane is a large vehicle, the distance between the host vehicle and the front large vehicle is less than 2 times the distance, the speed of the front vehicle on the target lane is greater than the speed of the large vehicle on the current lane, and the distance between the host vehicle and the front vehicle on the target lane is greater than 2 times the length of the host vehicle plus the distance between the host vehicle and the front vehicle on the current lane, an arbitrary lane-changing motivation is generated. Large vehicles include but are not limited to large trucks, large buses, large trucks, fire trucks.

[0199] It should be noted that if the vehicle is not on the desired lane, the arbitrary lane change needs to be changed in the direction of the desired lane. If the vehicle is on the desired lane, the vehicle can only change lanes between the desired lanes. Whether it is a forced lane change or an arbitrary lane change, the front vehicle on the current lane needs to be in a non-lane-changing state.

[0200] Step 42, select lane.

[0201] For arbitrary lane changing, if the current lane is not on the desired lane of the vehicle, the vehicle selects the direction of the desired lane to change lane; if the vehicle is on the desired lane, the vehicle can only change lane between the desired lanes. For example, the left lane is not the desired lane, so the vehicle cannot change lane to the left. If both sides of the lane are desired lanes, the probability of changing lane to the left or right is 50%. If the gap on the left lane does not meet the lane-changing requirement, the right lane is considered for lane-changing.

[0202] For forced lane changing, the vehicle will change lane to the lane closer to the target lane.

[0203] Step 43, select gap.

[0204] The vehicle that generates the lane-changing motivation needs to evaluate whether there is a suitable gap in the adjacent lane to allow the vehicle to safely perform the lane change, and if there is no suitable gap, the lane change cannot be performed. Take the TransModeler linear model as an example for illustration:

[0205]

[0206] where, is the set minimum gap; g is the front lead or rear lag gap; β g is the column vector parameter of the accepted front and rear gap; X i is the row vector value of the calibrated β; is the mean of 0, and the user sets the variance.

[0207] where, for the column vector β g {β g 0, β g 1, β g 2, βg3} calculation parameters are explained as follows:

[0208] β g 0 is a constant; β g 1 is the maximum value of 0 and ΔV i g ; β g 2 is the minimum value of 0 and ΔV i g ; β g 3 is V g . If g = lead, ΔV i g = V i subject -V i lead ; if g = lag, ΔV i g = V i lag -V i subject ; V g is V lead or V lag .

[0209] For mandatory lane changes, i = 4 corresponds to the formula of β g 4 as follows:

[0210]

[0211] In the above formula, α is the distance influence coefficient; d is the distance from the end of the mandatory lane change critical distance; that is, the position of the downstream decision point or accident point. If not, there is no d in the above formula. For example, driving into a no-entry lane.

[0212] Step 44, performing lane changing.

[0213] After the vehicle generates the lane changing motivation, the vehicle needs to plan the trajectory of the vehicle when performing lane changing. A third-order Bezier curve can be used for simulation. The third-order Bezier curve can guarantee the continuity and boundedness of the curve, and the vehicle can drive according to the planned curve.

[0214] The formula of the third-order Bezier curve is:

[0215] B(t) = P0(1-t) 3 + 3P1t(1-t) 2 + 3P2t 2 (1-t) + P3t 3 ,

[0216] Wherein, t∈[0,1], P0, P1, P2 and P3 are control points, and B(t) is a third-order Bezier curve, which starts from P0 and goes to P1, and comes from P2 to P3.

[0217] Figure 12 The schematic diagram of the third-order Bezier curve provided by the embodiment of the present application is shown. As shown in Figure 12 The vehicle 1 performs lane changing from lane 0 to lane 1. The initial position of the vehicle lane changing is P0, and the end position of the vehicle lane changing is P3. The selection method of the control point P1 and the control point P2 in the formula of the third-order Bezier curve includes the following steps:

[0218] Step 441, calculating the end position P3 of the vehicle lane changing according to the vehicle lane changing distance and the initial position P0 of the vehicle lane changing.

[0219] Step 442, drawing a ray 1 in the tangent direction from the initial position P0 of the vehicle lane changing, and drawing a ray 2 in the opposite direction of the tangent from the end position P3 of the vehicle lane changing.

[0220] Step 443, connecting the initial position P0 of the vehicle lane changing and the end position P3 of the vehicle lane changing, and taking three points 1 and three points 2 on the connecting line.

[0221] Step 444, drawing a perpendicular line from the three points 1 and the three points 2 to the ray 1 and the ray 2 respectively. Wherein, the perpendicular point of the perpendicular line drawn by the three points 1 to the ray 1 intersecting the ray 1 is the control point P1, and the perpendicular point of the perpendicular line drawn by the three points 2 to the ray 2 intersecting the ray 2 is the control point P2.

[0222] Step 445, generating a Bezier curve B(t) according to the control point P1 and the control point P2, and the initial position P0 and the end position P3.

[0223] ​For the signal light reaction model: a signal light is placed at the end of the import road section. When a vehicle enters the threshold range upstream of the signal light, the vehicle will generate a decision behavior according to the light color of the signal light. The threshold can be 50 meters, or other values, which are not limited in the present application. The following describes the decision behavior of the vehicle according to the light color of the signal light:

[0224] (1) When the signal light color is green, the vehicle follows the preceding vehicle according to the same lane following model.

[0225] (2) When the signal light is red, only the closest vehicle to the signal light will react to the signal light, and the vehicle behind the closest vehicle only needs to follow the preceding vehicle. At this time, the stop line can be assumed to be a stationary vehicle (the tail is flush with the stop line).

[0226] (3) When the signal light is yellow, the first vehicle downstream of the road section needs to determine whether it can pass the signal light at the current speed. If the result is that it cannot pass the signal light, a stationary virtual vehicle is placed behind the yellow light, the first vehicle slows down, and the following vehicles follow and queue; if the result is that it can pass, it continues to follow the preceding vehicle according to the same lane following model.

[0227] For the conflict avoidance model: the conflict avoidance model is used in situations where there are path intersections in the intersection or the ramp merging area or the ramp merging area. Please refer to Figure 12 , Figure 12 The vehicle conflict avoidance diagram provided by the embodiment of the present application.

[0228] In Figure 12 , road section A includes lane 0, lane 1, and lane 2, road section B includes lane 3 and lane 4. Road section C includes lane 5, lane 6, and lane 7, and road section D includes lane 8 and lane 9. Path 10 is a path connecting lane 3 and lane 8, path 11 is a path connecting lane 4 and lane 9, and path 12 is a path connecting lane 2 and lane 5. Vehicle 1 travels on path 12, vehicle 2 travels on path 10, vehicle 3 travels on path 11, and vehicle 4 travels on lane 4.

[0229] In Figure 12 , vehicle 1 traveling will conflict with vehicle 2 and vehicle 3. The point where path 10 intersects path 12 is conflict point 1, and the point where path 11 intersects path 12 is conflict point 2. At this time, the method of the conflict avoidance model for controlling the vehicle can include the following steps:

[0230] Step 51, confirming the order of the vehicles in conflict through the corresponding conflict points.

[0231] For each conflict point, the time of the conflict vehicle passing through the conflict point is calculated according to the distance from the conflict vehicle to the conflict point and the current speed of each vehicle. As shown in Figure 2 , it is assumed that the speeds of vehicle 1, vehicle 2 and vehicle 3 are consistent, and the times of vehicle 1 passing through conflict point 1 and conflict point 2, the time of vehicle 2 passing through conflict point 1 and the time of vehicle 3 passing through conflict point 2 need to be calculated. For conflict point 1, vehicle 1 passes through conflict point 1 earlier than vehicle 2. For conflict point 2, vehicle 3 passes through conflict point 2 earlier than vehicle 1.

[0232] Step 52, for each conflict point, the first vehicle passing through the conflict point is the front vehicle, and the other vehicles are the rear vehicles, which need to avoid the front vehicle.

[0233] Among them, the time difference of the front vehicle and the rear vehicle reaching the corresponding conflict point needs to be calculated, and if the time difference is less than or equal to the threshold value, the rear vehicle needs to take the avoidance action. That is, when the front vehicle and the rear vehicle reach the corresponding conflict point at close times, the rear vehicle needs to avoid the front vehicle and let the front vehicle pass through the conflict point first. The conflict avoidance model will assume that there is a stationary front vehicle at the conflict point, and calculate the following acceleration of the rear vehicle following this vehicle. If the same vehicle has multiple conflict avoidance requirements, the minimum value is taken among the multiple following accelerations.

[0234] As shown in Figure 2 , for conflict point 1, vehicle 1 passes through conflict 1 earlier than vehicle 2, so vehicle 1 is the front vehicle and vehicle 2 is the rear vehicle. If the time difference of vehicle 1 and vehicle 2 passing through conflict point 1 is less than 2s, vehicle 2 needs to take the avoidance action. For conflict point 2, vehicle 3 passes through conflict 2 earlier than vehicle 1, so vehicle 3 is the front vehicle and vehicle 1 is the rear vehicle. If the time difference of vehicle 1 and vehicle 3 passing through conflict point 2 is greater than 2s, vehicle 1 does not need to take the avoidance action.

[0235] After determining the initial state of the dynamic ontology, the dynamic ontology drives in different dynamic scenes under the control of the corresponding behavior model, that is, the driving trajectory of the dynamic ontology can be determined. By determining the initial state and driving trajectory of the dynamic ontology, complex dynamic interactions between traffic participants in the dynamic scene can be embodied. In this way, when the unmanned vehicle is tested in the virtual test scene, interaction test data meeting the design can be obtained, and the virtual test efficiency of the unmanned vehicle can be improved.

[0236] S204, generate a test scene model.

[0237] The test scene model includes a driving trajectory, which is used to test whether the driving behavior of the unmanned vehicle meets the design requirements.

[0238] Taking a static scene including 3 static ontologies and a dynamic scene including 1 dynamic ontology as an example:

[0239] The parameter space corresponding to the three static bodies in the static scene is defined as follows:

[0240] Central median type: marking median, barrier median;

[0241] Central median width: marking median width: 0.5 meters; barrier median width: 1.5 to 3 meters, sampling interval is 0.1 meters;

[0242] Lane number: 1 to 5;

[0243] Lane width: 3.5 to 4.5 meters, sampling interval is 0.05 meters;

[0244] Roadside median width: 1.5 to 3 meters, sampling interval is 0.05 meters;

[0245] The parameter space of the dynamic body in the dynamic scene is defined as follows:

[0246] Vehicle initial lane: 1 to 3;

[0247] Vehicle initial longitudinal coordinate: 0 to 50 meters, sampling interval is 10m;

[0248] Vehicle initial speed: 10 to 35 meters per second, sampling interval is 5 meters per second;

[0249] Vehicle initial lane change intention: 0: no lane change; 1: left lane change; 2: right lane change.

[0250] After determining the parameter space, various reasonable parameter combinations are continuously traversed using computer computing power, and finally 9600 static test scenes and 6326 dynamic test scenes are obtained.

[0251] In a possible design scheme, Figure 9 The virtual test scene construction method shown can further include the following steps:

[0252] Step 61, obtaining the driving behavior of the unmanned vehicle in the first test scene.

[0253] Based on the parameter space and rules of each body in the constructed virtual test scene, the first test scene is a virtual test scene formed by a larger sampling interval of the parameter space. The unmanned vehicle is put into the first test scene for testing to obtain the driving behavior of the unmanned vehicle in the first test scene.

[0254] Step 62, determining a second test scene.

[0255] The second test scene is a test scene in which the driving behavior of the unmanned vehicle in the first test scene does not meet the design requirements. That is, the search direction of the key scene is determined by the coarse-grained test, and the key scene refers to a scene in which the unmanned vehicle performs poorly.

[0256] In step 63, the parameter interval corresponding to the second test scene is encrypted and sampled to generate a third test scene.

[0257] For the key scene, the parameter interval corresponding to the key scene is finely encrypted and sampled to generate a third test scene. In this way, targeted testing can be performed to accelerate the testing effect.

[0258] In step 64, the third test scene is tested.

[0259] The first test scene can be constructed by coarse-grained parameter value, and the parameter interval corresponding to the first test scene in which the driving behavior does not meet the design requirements is encrypted and sampled according to the driving behavior of the unmanned vehicle in the first test scene to generate a third test scene. In this way, the virtual test scene that performs poorly for the unmanned vehicle is sampled and tested multiple times, which can solve the problem of low testing efficiency caused by too many virtual test scenes constructed by too fine parameter values, and can improve the virtual testing efficiency and testing specificity of the unmanned vehicle. Compared with the traditional test scene design based on human driving behavior, it is more suitable for unmanned testing.

[0260] Optionally, Figure 10 The virtual test scene construction method can also include adding a label to the virtual test scene based on the interaction relationship between the static ontology and the dynamic ontology. The label is used to manage the virtual test scene.

[0261] The driving trajectory of the dynamic ontology can provide a lot of information for the scene. For example, the expected test function of the scene can be defined according to the interaction behavior between vehicles. The interaction behavior includes but is not limited to: following, lane changing, merging in, and merging out. For example, a following label can be added to a virtual test scene in which the interaction behavior is following, indicating that the virtual test scene is a following scene. Figure 12 The following scene under merging can add a following label under merging. Figure 12 The following scene under splitting can add a following label under splitting. Figure 2 The conflict avoidance scene can add a conflict avoidance label.

[0262] Further, the danger level of the virtual test scene can be defined according to the intensity of the interaction between the interaction behaviors, that is, whether the virtual test scene is a dangerous working condition or a normal working condition. When the virtual test scene is a dangerous working condition, a danger label can also be added to the virtual test scene.

[0263] By tagging the virtual test scene, such as the function classification of the virtual test scene and the danger level of the virtual test scene, the virtual test scene library is facilitated to be managed, and the required virtual test scene is facilitated to be called for testing.

[0264] For example, when testing whether the driving behavior of the unmanned vehicle in the conflict avoidance scene conforms to the expectation, it can be determined by querying whether the conflict avoidance scene exists. For example, after querying in the scene library, if the conflict avoidance label exists, the conflict avoidance scene corresponding to the conflict avoidance label is called. Then, the simulated unmanned vehicle is put into the conflict avoidance scene. Then, the driving trajectory of the unmanned vehicle in the conflict avoidance scene is recorded. Finally, the driving trajectory of the unmanned vehicle is analyzed to confirm whether the driving behavior of the unmanned vehicle conforms to the driving behavior specification.

[0265] As shown in FIG. 1, Figure 2- Figure 12 The unmanned vehicle can be any one of vehicle 1, vehicle 2, or vehicle 3. Taking vehicle 1 as an example, the unmanned vehicle will collide with vehicle 2 and vehicle 3. Assuming that the speeds of the unmanned vehicle, vehicle 2, and vehicle 3 are consistent, the time for the unmanned vehicle to pass through conflict point 1 and conflict point 2, the time for vehicle 2 to pass through conflict point 1, and the time for vehicle 3 to pass through conflict point 2 need to be calculated.

[0266] For conflict point 1, if the unmanned vehicle passes through conflict 1 earlier than vehicle 2, the unmanned vehicle is the front vehicle and vehicle 2 is the rear vehicle. For conflict point 2, if vehicle 3 passes through conflict 2 earlier than the unmanned vehicle, vehicle 3 is the front vehicle and the unmanned vehicle is the rear vehicle. If the time difference between the unmanned vehicle and vehicle 3 passing through conflict point 2 is less than 2s, the unmanned vehicle needs to take avoidance action. By analyzing the driving trajectory of the unmanned vehicle, it can be confirmed whether the unmanned vehicle takes avoidance action when passing through conflict point 2. If the unmanned vehicle takes avoidance action, such as stopping or decelerating, the driving behavior of the unmanned vehicle in the conflict avoidance scene conforms to the driving behavior specification. If the unmanned vehicle does not take avoidance action, the driving behavior of the unmanned vehicle in the conflict avoidance scene does not conform to the driving behavior specification.

[0267] Based on Figure 13- Figure 14The virtual test scene construction method shown in the embodiment can embody the design constraint between the static ontology, and can solve the problem that the value of the parameter combination traversed by the computer is unreasonable due to the virtual test scene not meeting the road specification. Moreover, the dynamic ontology model constructed based on the static ontology model can embody the behavior constraint between the dynamic ontology and the static ontology, and then the driving trajectory of the dynamic ontology is determined based on the behavior constraint and the traffic flow simulation, which can solve the problem that the dynamic ontology in the virtual test scene extracted based on the natural driving data cannot dynamically interact with the unmanned vehicle, and can eliminate the unreasonable behavior of the dynamic ontology. In this way, a large number of reasonable, complete, and dynamically interactive virtual test scenes with the unmanned vehicle can be constructed, and the test efficiency of the unmanned vehicle can be improved.

[0268] The above Figure 13 The virtual test scene construction method provided by the embodiment is described in detail. The following Figure 1 The virtual test scene construction method provided by the embodiment is described in detail. The following

[0269] Exemplarily, Figure 13 The virtual test scene construction method provided by the embodiment is described in detail. The following Figure 13 As shown in Figure 1 The virtual test scene construction device 1300 includes a construction module 1301, a determination module 1302, and a generation module 1303. For ease of description, Figure 2 Only the main components of the virtual test scene construction device are shown.

[0270] In a possible design scheme, the virtual test scene construction device 1300 can be applied to Figure 13 The virtual test scene construction method shown in Figure 13 The virtual test scene construction method shown in

[0271] The construction module 1301 is configured to construct a static ontology model in combination with the road specification and the expert experience. The static ontology model is used to describe the design constraint of the static ontology. The static ontology includes one or more of the following: road topology, road infrastructure, traffic control, or environment.

[0272] The construction module 1301 is further configured to construct a dynamic ontology model based on the static ontology model. The dynamic ontology model is used to describe the behavior constraint of the dynamic ontology. The dynamic ontology includes one or more of the following: vehicle, pedestrian, or animal.

[0273] The determination module 1302 is configured to determine the driving trajectory of the dynamic ontology in combination with the traffic flow simulation, according to the design constraint of the static ontology and the behavior constraint of the dynamic ontology.

[0274] The generating module 1303 is configured to generate a test scenario model. The test scenario model includes a driving track, and the driving track is used to test whether a driving behavior of the unmanned vehicle meets a design requirement.

[0275] In a possible design, the constructing module 1301 is further configured to define a static ontology class. The static ontology class is used to describe the following one or more of the static ontology: a virtual test scenario, a road, a divider, a lane, a traffic sign, weather, or a light condition.

[0276] The constructing module 1301 is further configured to define a static object attribute. The static object attribute is used to describe a mapping relationship between the static ontology classes.

[0277] The constructing module 1301 is further configured to define a static data attribute. The static data attribute is used to describe a parameter set of the static ontology class.

[0278] The constructing module 1301 is further configured to define a static design rule. The static design rule is used to describe a mapping relationship between the static ontology class, the static object attribute, and the static data attribute, and the static design rule is used to determine rationality of the generated virtual test scenario.

[0279] Optionally, the design constraint of the static ontology includes one or more of the following: a position relationship between roads, a position relationship between a road and a lane, a position relationship between lanes, a position relationship between a lane and a divider, a constraint relationship between a position and a type of a lane line and a lane and / or a divider, and a position relationship between a traffic sign and a lane and / or a divider.

[0280] Further, the constructing module 1301 is further configured to define a dynamic ontology class. The dynamic ontology class is used to describe the following one or more of the dynamic ontology: a vehicle, a pedestrian, or an animal.

[0281] The constructing module 1301 is further configured to define a dynamic object attribute. The dynamic object attribute is used to describe a mapping relationship between the dynamic ontology classes and a constraint relationship between the dynamic ontology and the static ontology.

[0282] The constructing module 1301 is further configured to define a dynamic data attribute. The dynamic data attribute is used to describe a parameter set of the dynamic ontology class.

[0283] The constructing module 1301 is further configured to define a dynamic design rule. The dynamic design rule is used to describe a mapping relationship between the dynamic ontology class, the dynamic object attribute, and the dynamic data attribute, and the dynamic design rule is used to determine rationality of the generated test scenario.

[0284] Optionally, the behavior constraint of the dynamic ontology includes one or more of the following: a position relationship between the vehicle and a lane, a position relationship between vehicles, a vehicle speed limit, a vehicle driving direction constraint, a vehicle steering constraint, a vehicle lane changing constraint, a vehicle cutting-in constraint, and a vehicle cutting-out constraint.

[0285] Further, the determining module 1302 is further configured to determine the initial state of the dynamic ontology according to the design constraint of the static ontology, the behavior of the dynamic ontology, and the design requirement of the scene.

[0286] The determining module 1302 is further configured to determine a driving trajectory of the dynamic ontology according to the initial state of the dynamic ontology in combination with traffic flow simulation.

[0287] Optionally, the constructing module 1301 is further configured to determine the initial state of the dynamic ontology according to the design constraint of the static ontology, the behavior constraint of the dynamic ontology, and the design requirement of the scene, and the test target and the behavior model of the dynamic ontology.

[0288] Optionally, the behavior model of the dynamic ontology includes one or more of the following: a car following model, a lane changing model, a signal light reaction model, a random disturbance model, a bus and pedestrian behavior model, a gap acceptance model, a merging model, a cooperation model, or a conflict avoidance model.

[0289] In one possible design, as shown in Figure 13 the virtual test scene construction apparatus 1300 can further include an obtaining module 1304 and a testing module 1305. Specifically,

[0290] The obtaining module 1304 is configured to obtain the driving behavior of the unmanned vehicle in the first test scene.

[0291] The determining module 1302 is further configured to determine a second test scene. The second test scene is a test scene in which the driving behavior of the unmanned vehicle in the first test scene does not meet the design requirement.

[0292] The generating module 1303 is further configured to perform encrypted sampling on the parameter interval corresponding to the second test scene to generate a third test scene.

[0293] The testing module 1305 is configured to perform testing on the third test scene.

[0294] In one possible design, as shown in Figure 2 the virtual test scene construction apparatus 1300 can further include an adding module 1306. The adding module 1306 is configured to add a label to the virtual test scene based on the interaction relationship between the static ontology and the dynamic ontology. The label is used to manage the virtual test scene.

[0295] It should be noted that the construction module 1301, the determination module 1302, the generation module 1303, the acquisition module 1304, the test module 1305 and the addition module 1306 can be the same processing module. The processing module can perform the functions corresponding to the various modules described above.

[0296] Optionally, the virtual test scenario construction apparatus 1300 can further include a storage module (not shown) which stores programs or instructions. When the above processing module executes the programs or instructions, the virtual test scenario construction apparatus 1300 can perform the virtual test scenario construction method shown in the above. Figure 2 Figure 14

[0297] It should be noted that the virtual test scenario construction apparatus 1300 described above can be any network device, such as a server, or a chip (system) or other components or assemblies arranged in the above network device, and the embodiments of the present application do not limit this.

[0298] In addition, the technical effects of the virtual test scenario construction apparatus 1300 can be respectively referred to the technical effects of the virtual test scenario construction method shown in the above, which will not be described here. Figure 2

[0299] Exemplarily, Figure 14 The structure of the virtual test scenario construction apparatus provided by the embodiments of the present application is shown in the above. Figure 14 The virtual test scenario construction apparatus can be a network device, such as a server, or a chip (system) or other components or assemblies which can be arranged in a terminal device or a network device. As shown in the above, the virtual test scenario construction apparatus 1400 can include a processor 1401. Optionally, the virtual test scenario construction apparatus 1400 can further include a memory 1402 and / or a transceiver 1403. Wherein, the processor 1401 is coupled with the memory 1402 and the transceiver 1403, such as can be connected through a communication bus. Figure 14

[0300] The various constituent components of the virtual test scenario construction apparatus 1400 will be specifically introduced in the following: Figure 14

[0301] ​​​​​The processor 1401 is the control center of the virtual test scenario construction apparatus 1400, and can be one processor or a collective term of multiple processing elements. For example, the processor 1401 is one or more central processing units (CPUs), and can also be an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, such as one or more digital signal processors (DSPs), or one or more field programmable gate arrays (FPGAs).

[0302] Optionally, the processor 1401 can execute various functions of the virtual test scenario construction apparatus 1400 by running or executing software programs stored in the memory 1402 and calling data stored in the memory 1402.

[0303] In a specific implementation, as an embodiment, the processor 1401 can include one or more CPUs, such as the CPU0 and the CPU1 shown in FIG. 10. Figure 14

[0304] In a specific implementation, as an embodiment, the virtual test scenario construction apparatus 1400 can also include multiple processors, such as the processor 1401 and the processor 1404 shown in FIG. 10. Each of the processors can be a single-CPU or a multi-CPU. The processor herein can refer to one or more communication devices, circuits, and / or processing cores for processing data (for example, computer program instructions). Figure 14

[0305] The memory 1402 is configured to store software programs for implementing the schemes of the present application, and the processor 1401 controls the execution. The specific implementation can refer to the above method embodiments, and will not be repeated here.

[0306] ​​Optionally, the memory 1402 can be a read-only memory (ROM) or other type of static storage communication device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage communication device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disk storage, a magnetic disk storage or other magnetic storage devices, or any other medium capable of storing desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to this. The memory 1402 can be integrated with the processor 1401 or exist independently and be coupled with the processor 1401 through an input / output port (not shown in the figure) of the virtual test scenario construction device 1400. Figure 14

[0307] The transceiver 1403 is configured to communicate with other communication devices. For example, the virtual test scenario construction device 1400 is a network device, and the transceiver 1403 can be configured to communicate with a terminal device or another network device.

[0308] Optionally, the transceiver 1403 can include a receiver and a transmitter (not shown separately in the figure). The receiver is configured to implement the receiving function, and the transmitter is configured to implement the transmitting function. ​

[0309] Optionally, the transceiver 1403 can be integrated with the processor 1401 or exist independently and be coupled with the processor 1401 through an input / output port (not shown in the figure) of the virtual test scenario construction device 1400. ​

[0310] It should be noted that the structure of the virtual test scenario construction device 1400 shown in the figure does not constitute a limitation on the communication device, and the actual virtual test scenario construction device can include more or fewer components than those shown in the figure, or combine certain components, or different component arrangements. ​

[0311] An embodiment of the present application provides a virtual test scenario construction system. The virtual test scenario construction system includes one or more network devices. ​​​​

[0312] It should be appreciated that the processor in the embodiments of the present application can be a central processing unit (CPU), and can also be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0313] It should also be understood that the memory in the embodiments of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memory. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically EPROM (EEPROM) or a flash memory. The volatile memory can be a random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM) and direct rambus RAM (DR RAM).

[0314] The above-described embodiments can be implemented in part or in whole through software, hardware (e.g., circuitry), firmware, or any combination thereof. When implemented in software, the above-described embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When loaded and executed by a computer, the computer instructions or computer programs can produce the processes or functions described above in accordance with the embodiments of the present application. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable apparatus. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, such as from a website site, a computer, a server, or a data center to another website site, a computer, a server, or a data center, through a wired (e.g., infrared, wireless, microwave, etc.) manner. The computer-readable storage medium can be any available medium or a collection of medium accessible by a computer or a data storage device such as a server, a data center, etc. containing one or more available medium. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state disk.

[0315] It should be understood that the term "and / or" in this document is merely used to describe an associated relationship between associated objects, and can represent three relationships, for example, A and / or B can represent three cases of A alone, A and B together, and B alone, where A and B can be singular or plural. In addition, the character " / " in this document generally represents an "or" relationship between the front and rear associated objects, but can also represent an "and / or" relationship. The specific meaning can be understood according to the context before and after.

[0316] In this application, "at least one" means one or more, and "multiple" means two or more. "At least one of the following" or similar expressions means any combination of the items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent a, b, c, a-b, a-c, b-c, or a-b-c, where a, b, and c can be single or multiple.

[0317] It should be understood that in various embodiments of the present application, the size of the sequence number of the above-described processes does not mean the order of execution, and the execution order of the processes should be determined according to their functions and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0318] Those skilled in the art can clearly understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0319] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

[0320] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the above-described device embodiments are only schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0321] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0322] In addition, each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically independently, or two or more units can be integrated into one unit.

[0323] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the parts that contribute to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0324] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A virtual test scenario construction method, characterized by, The method comprises: constructing a static ontology model in combination with road specifications and expert experience, wherein the static ontology model is used to describe design constraints of a static ontology, and the static ontology comprises one or more of the following: road topology, road infrastructure, traffic control, or environment; constructing a dynamic ontology model based on the static ontology model, wherein the dynamic ontology model is used to describe behavior constraints of a dynamic ontology, and the dynamic ontology comprises one or more of the following: vehicle, pedestrian, or animal; determining a driving trajectory of the dynamic ontology in combination with traffic flow simulation according to the design constraints of the static ontology and the behavior constraints of the dynamic ontology; generating a test scenario model, wherein the test scenario model comprises the driving trajectory, and the driving trajectory is used to test whether the driving behavior of an unmanned vehicle meets design requirements; the constructing of the dynamic ontology model based on the static ontology model comprises: defining a dynamic ontology class, wherein the dynamic ontology class is used to describe one or more of the following corresponding to the dynamic ontology: vehicle, pedestrian, or animal; defining dynamic object attributes, wherein the dynamic object attributes are used to describe mapping relationships among the dynamic ontology classes, and constraint relationships between the dynamic ontology and the static ontology; defining dynamic data attributes, wherein the dynamic data attributes are used to describe a parameter set of the dynamic ontology class; defining dynamic design rules, wherein the dynamic design rules are used to describe mapping relationships among the dynamic ontology class, the dynamic object attributes, and the dynamic data attributes, and the dynamic design rules are used to determine the rationality of the generated test scenario.

2. The virtual test scenario construction method of claim 1, wherein, the constructing of the static ontology model in combination with road specifications and expert experience comprises: defining a static ontology class, wherein the static ontology class is used to describe one or more of the following corresponding to the static ontology: virtual test scenario, road, median strip, lane, traffic sign, weather, or lighting condition; defining static object attributes, wherein the static object attributes are used to describe mapping relationships among the static ontology classes; defining static data attributes, wherein the static data attributes are used to describe a parameter set of the static ontology class; defining static design rules, wherein the static design rules are used to describe mapping relationships among the static ontology class, the static object attributes, and the static data attributes, and the static design rules are used to determine the rationality of the generated virtual test scenario.

3. The virtual test scenario construction method of claim 2, wherein, the design constraints of the static ontology comprise one or more of the following: position relationship among roads, position relationship between road and lane, position relationship among lanes, position relationship between lane and median strip, constraint relationship between position and type of lane line and lane and / or median strip, position relationship between traffic sign and lane and / or median strip.

4. The virtual test scenario construction method of claim 1, wherein, the behavior constraints of the dynamic ontology comprise one or more of the following: position relationship between vehicle and lane, position relationship among vehicles, vehicle speed limit, vehicle driving direction constraint, vehicle turning constraint, vehicle lane changing constraint, vehicle cutting-in constraint, and vehicle cutting-out constraint.

5. The virtual test scenario construction method of claim 4, wherein, The method further comprises: acquiring driving behaviors of the unmanned vehicle in a first test scenario; determining a second test scenario; wherein the second test scenario is a test scenario in which the driving behaviors of the unmanned vehicle in the first test scenario do not meet the design requirements; 6. The virtual test scene construction method of claim 5, wherein, performing encrypted sampling on a parameter interval corresponding to the second test scenario to generate a third test scenario; performing testing on the third test scenario.

7. The virtual test scenario construction method of claim 6, wherein, The method further comprises:

8. The virtual test scenario construction method according to any one of claims 1-7, characterized in that, adding a label to the virtual test scenario based on the interaction relationship between the static ontology and the dynamic ontology; wherein the label is used to manage the virtual test scenario. The method comprises a constructing module, a determining module and a generating module; wherein, the constructing module is configured to construct a static ontology model in combination with road specifications and expert experience; wherein the static ontology model is used to describe design constraints of a static ontology, and the static ontology comprises one or more of the following: road topology, road infrastructure, traffic control, or environment; the constructing module is further configured to construct a dynamic ontology model based on the static ontology model; wherein the dynamic ontology model is used to describe behavior constraints of a dynamic ontology, and the dynamic ontology comprises one or more of the following: vehicle, pedestrian, or animal; the determining module is configured to determine a driving trajectory of the dynamic ontology in combination with traffic flow simulation, according to the design constraints of the static ontology and the behavior constraints of the dynamic ontology; 9. The virtual test scene construction method according to any one of claims 1-7, characterized in that, the generating module is configured to generate a test scenario model; wherein the test scenario model comprises the driving trajectory, and the driving trajectory is used to test whether the driving behaviors of the unmanned vehicle meet the design requirements; the constructing module is further configured to define a dynamic ontology class; wherein the dynamic ontology class is used to describe one or more of the following corresponding to the dynamic ontology: vehicle, pedestrian, or animal; 10. A virtual test scenario construction apparatus characterized by comprising: the constructing module is further configured to define dynamic object attributes; wherein the dynamic object attributes are used to describe mapping relationships between the dynamic ontology classes, and constraint relationships between the dynamic ontology and the static ontology. ​ ​ ​ ​ ​ ​ The constructing module is further configured to define dynamic data attributes, wherein the dynamic data attributes are used to describe parameter sets of the dynamic ontology classes. The constructing module is further configured to define dynamic design rules, wherein the dynamic design rules are used to describe mapping relationships among the dynamic ontology classes, the dynamic object attributes, and the dynamic data attributes, and the dynamic design rules are used to determine rationality of the generated test scene.

11. The virtual test scene constructing apparatus of claim 10, wherein The constructing module is further configured to define static ontology classes, wherein the static ontology classes are used to describe one or more of the following corresponding to the static ontology: virtual test scenes, roads, dividers, lanes, traffic signs, weather, or lighting conditions. The constructing module is further configured to define static object attributes, wherein the static object attributes are used to describe mapping relationships among the static ontology classes. The constructing module is further configured to define static data attributes, wherein the static data attributes are used to describe parameter sets of the static ontology classes. The constructing module is further configured to define static design rules, wherein the static design rules are used to describe mapping relationships among the static ontology classes, the static object attributes, and the static data attributes, and the static design rules are used to determine rationality of the generated virtual test scene.

12. The virtual test scene construction apparatus according to claim 11, wherein, The design constraints of the static ontology include one or more of the following: position relationships among roads, position relationships between roads and lanes, position relationships among lanes, position relationships between lane lines and dividers, constraint relationships between positions and types of lane lines and lanes and / or dividers, and position relationships between traffic signs and lanes and / or dividers.

13. The virtual test scene construction apparatus of claim 10, wherein, The behavior constraints of the dynamic ontology include one or more of the following: position relationships between vehicles and lanes, position relationships among vehicles, vehicle speed limits, vehicle direction constraints, vehicle turning constraints, vehicle lane-changing constraints, vehicle cut-in constraints, and vehicle cut-out constraints.

14. The virtual test scene constructing apparatus of claim 13, wherein The determining module is further configured to determine initial states of the dynamic ontology according to the design constraints of the static ontology, the behavior constraints of the dynamic ontology, and scene design requirements. The determining module is further configured to determine driving trajectories of the dynamic ontology according to the initial states of the dynamic ontology in combination with traffic flow simulation.

15. The virtual test scene constructing apparatus of claim 14, wherein The constructing module is further configured to determine initial states of the dynamic ontology according to the design constraints of the static ontology, the behavior constraints of the dynamic ontology, and scene design requirements, as well as test objectives and behavior models of the dynamic ontology.

16. The virtual test scene construction apparatus of claim 15, wherein, The behavior models of the dynamic ontology include one or more of the following: car-following models, lane-changing models, signal light reaction models, random disturbance models, bus and pedestrian behavior models, gap acceptance models, merging models, cooperation models, or conflict avoidance models.

17. The virtual test scene construction apparatus according to any one of claims 10-16, characterized by, The apparatus further includes an acquiring module and a testing module, wherein The acquiring module is configured to acquire driving behaviors of the unmanned vehicle in the first test scene. The determining module is further configured to determine a second test scenario; the second test scenario is a test scenario in which the driving behavior of the unmanned vehicle in the first test scenario does not meet the design requirement; The generating module is further configured to perform encrypted sampling on a parameter interval corresponding to the second test scenario to generate a third test scenario; The testing module is configured to perform testing on the third test scenario.

18. The virtual test scene construction apparatus according to any one of claims 10-16, characterized by, The apparatus further includes an adding module; wherein The adding module is configured to add a label to the virtual test scenario based on the interaction relationship between the static ontology and the dynamic ontology; the label is used to manage the virtual test scenario.

19. A virtual test scenario construction apparatus characterized by comprising: The virtual test scenario construction apparatus is configured to perform the virtual test scenario construction method according to any one of claims 1-9.

20. A virtual test scenario construction apparatus characterized by comprising: Comprise: A processor; wherein The processor is configured to perform the virtual test scenario construction method according to any one of claims 1-9.

21. A virtual test scenario construction apparatus characterized by comprising: Comprise: A processor coupled with a memory; The memory is configured to store a computer program; The processor is configured to execute the computer program stored in the memory, so that the virtual test scenario construction apparatus performs the virtual test scenario construction method according to any one of claims 1-9.

22. A computer-readable storage medium, characterized in that, The computer readable storage medium comprises a computer program or instructions, when the computer program or instructions run on a computer, so that the computer executes the virtual test scenario construction method according to any one of claims 1-9.

23. A computer program product, characterised in that, The computer program product comprises: a computer program or instructions, when the computer program or instructions run on a computer, so that the computer executes the virtual test scenario construction method according to any one of claims 1-9.

Images