DE102019211009B4 - Method and computer program for simulating an autonomous vehicle in a plurality of test cases - Google Patents

Abstract

Method for simulating an autonomous vehicle in a plurality of test cases, the method comprising: detecting (110) a plurality of driving environments (10), a plurality of driving intentions (20) of the autonomous vehicle for the plurality of driving environments (10), and a plurality of scenarios (30) for the plurality of driving projects (20), wherein the plurality of scenarios (30) each depict an influence of one or more changeable objects on a driving project of the plurality of driving projects;generating (120) the plurality of test cases for the simulating the autonomous vehicle based on the plurality of driving environments (10), the plurality of driving projects (20), and the plurality of scenarios (30);providing (130) an expected behavior of the autonomous vehicle for each test case of the plurality of test cases;simulating ( 140) of the autonomous vehicle in the plurality of test cases; andautomatically evaluating (150) a deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle.

Description

The invention relates to a method and a computer program for simulating an autonomous vehicle in a plurality of test cases.

The development of autonomous vehicles is a current focus in vehicle development. Rule-based and/or experience-based implementations are often used, which are first simulated and then tested on test tracks under real conditions.

the US20190213290A1 describes a method for simulating the test environment for a highly automated vehicle, comprising a large number of objects, terrain forms, roads and road conditions.

Further describes DE102006044086B4 a system for virtual simulation of traffic situations, with a display unit for pictorial display of the virtual traffic situations and an input unit, and with at least one non-deterministically configured reference vehicle and at least one further modeled road user.

The number of situations in which such an autonomous vehicle is to be used is unmanageably large, so that even with careful planning, not all situations that can occur in reality can be simulated and tested.

The object is therefore to provide an improved method for simulating an automated vehicle that makes it possible to identify and simulate situations that have not been simulated before.

The invention is based on the idea of generating a hierarchical list of driving environments, driving projects and scenarios from which a number of test cases are generated. A test case can be generated for each combination of driving environment (such as a roundabout, intersection, bus stop, factory premises, etc.), driving project (such as turning right, turning left, driving straight ahead, parking, etc.) and scenario (influence of different moving objects on the autonomous vehicle). will. An expected/desired behavior is deterministically defined for each of the test cases, and a simulation of the test cases is carried out, which is automatically compared with the expected behavior. The simulation of a test case can include at least one parameter that can be changed. This can be varied in order to determine system limits of the autonomous vehicle, outside which the autonomous vehicle can be operated in a safety mode.

Embodiments therefore provide a method for simulating an autonomous vehicle in a plurality of test cases. The method includes detecting a plurality of driving environments, a plurality of driving plans of the autonomous vehicle for the plurality of driving environments, and a plurality of scenarios for the plurality of driving plans. The plurality of scenarios each depict an influence of one or more changeable objects on a driving project of the plurality of driving projects. The method further includes generating the plurality of test cases for simulating the autonomous vehicle based on the plurality of driving environments, the plurality of driving projects, and the plurality of scenarios. The method further includes providing an expected behavior of the autonomous vehicle for each test case of the plurality of test cases. The method further includes simulating the autonomous vehicle in the plurality of test cases. The method also includes an automated evaluation of a deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle. By generating the majority of test cases, gaps in the simulation of the autonomous vehicle can be detected, the deterministic definition of the expected behavior enables an automated evaluation of the simulation, and the simulation of the majority of test cases makes it possible to identify those constellations for which programming of the autonomous vehicle is to be improved.

The test cases of the plurality of test cases can each have at least one changeable parameter. The simulation of the autonomous vehicle can be carried out for different values of the at least one changeable parameter. This enables system limits of the autonomous vehicle to be determined.

The automated evaluation of the deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle can determine those values of the at least one changeable parameter at which there is a deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle around system limits of the autonomous vehicle. These system boundaries can be used to define in which situations the vehicle uses a safe driving mode.

The method may further include adjusting programming of the autonomous vehicle based on the determined system boundaries such that the programming places the autonomous vehicle in a safe driving mode outside of the system boundaries. Additionally, the method may further include adjusting the expected behavior of the autonomous vehicle such that the expected behavior outside of system boundaries is based on the autonomous vehicle utilizing a safe driving mode. This enables the autonomous vehicle to be used at a reduced speed if it is in a situation that has led to a deviation between the expected behavior and the simulated behavior in a simulation.

In at least some embodiments, the method includes identifying a subset of the test cases for which no expected behavior is defined. This makes it possible to recognize which situations have not yet been examined by the method.

For example, the expected behavior can be defined deterministically. This enables the automated comparison of the simulation with the expected behavior.

The expected behavior can be defined as a sequence of expected activities of the autonomous vehicle. Such a sequence can be automatically compared with the simulation, but at the same time also enables a definition and/or an understanding of the expected behavior by a developer.

In some exemplary embodiments, the behavior also includes detecting at least one external influencing factor. The generation of the plurality of test cases for the simulation of the autonomous vehicle can also be based on the at least one external influencing factor. The at least one external influencing factor can be used as an additional layer in the generation of the plurality of test cases.

The at least one external influencing factor can include at least one element from the group of weather, a road condition, an optical signal and an acoustic signal. This enables the generation of a large number of possible constellations.

In this case, the plurality of test cases can be formed as a quantity product from the plurality of driving environments, the plurality of driving projects, the plurality of scenarios (and optionally the at least one external influencing factor). In this way, a catalog of test cases can be generated that (if possible) covers all case constellations.

Embodiments also provide a program with program code for performing the method when the program code is executed on a computer, a processor, a control module or a programmable hardware component.

• 1a und 1b zeigen Flussdiagramme von Ausführungsbeispielen eines Verfahrens zum Simulieren eines autonomen Fahrzeugs in einer Mehrzahl von Testfällen.
• 2 zeigt ein schematisches Diagramm einer Generierung eines funktionalen Katalogs für ein Fahrzeug;
• 3 zeigt ein schematisches Diagramm, das illustriert, wie aus einer Fahrumgebung, einem Fahrvorhaben und veränderbaren Objekten ein Testfall generiert wird;
• 4 zeigt ein übergreifendes schematisches Diagramm, das eine Mehrzahl von Testfällen basierend auf einer Mehrzahl von Fahrumgebungen, einer Mehrzahl von Fahrvorhaben, einer Mehrzahl von Szenarien, Wetter und einem Straßenzustand generiert wird;
• 5 zeigt ein schematisches Diagramm, das illustriert, wie aus einer Route ein Missions-Plan generiert wird;
• 6 zeigt ein Beispiel eines Benennungsschemas;
• 7a bis 7i zeigt beispielhafte Szenarien;
• 8 zeigt ein Objektdiagramm von Objekten der Testfälle;
• 9 zeigt ein beispielhaftes Aktivitätsdiagramm; und
• 10 zeigt ein Diagramm eines Verfahrens zum Simulieren einer Mehrzahl von Testfällen.

Further advantageous configurations are described in more detail below with reference to the exemplary embodiments illustrated in the drawings, to which exemplary embodiments are generally but not limited overall. Show it:

• 1a and 1b show flow charts of exemplary embodiments of a method for simulating an autonomous vehicle in a plurality of test cases.
• 2 FIG. 12 shows a schematic diagram of a functional catalog generation for a vehicle; FIG.
• 3 shows a schematic diagram that illustrates how a test case is generated from a driving environment, a driving project and changeable objects;
• 4 12 shows an overall schematic diagram that generates a plurality of test cases based on a plurality of driving environments, a plurality of driving intentions, a plurality of scenarios, weather and a road condition;
• 5 shows a schematic diagram illustrating how a mission plan is generated from a route;
• 6 shows an example of a naming scheme;
• 7a until 7i shows exemplary scenarios;
• 8th shows an object diagram of objects of the test cases;
• 9 shows an example activity diagram; and
• 10 Figure 12 shows a diagram of a method for simulating a plurality of test cases.

Various embodiments will now be described in more detail with reference to the accompanying drawings, in which some embodiments are illustrated. In the following description of the accompanying figures, which only show a few exemplary embodiments, the same reference symbols can designate the same or comparable components. Unless otherwise defined, all terms used herein (including tech technical and scientific terms) have the same meaning as those of ordinary skill in the art to which the exemplary embodiments pertain. Further, it is understood that terms, such as those defined in commonly used dictionaries, are to be interpreted as having the meaning consistent with their meaning in the context of the relevant art, and not in an idealized or overly formal sense are to be interpreted unless expressly defined herein.

the 1a and 1b FIG. 12 shows flowcharts of exemplary embodiments of a method, such as a computer-implemented method, for simulating an autonomous vehicle in a plurality of test cases. The method includes detecting 110 a plurality of driving environments 10, a plurality of driving projects 20 of the autonomous vehicle for the plurality of driving environments 10, and a plurality of scenarios 30 for the plurality of driving projects 20. The plurality of scenarios 30 each form an influence of one or more changeable objects on a driving project of the plurality of driving projects. The method also includes generating 120 the plurality of test cases for simulating the autonomous vehicle based on the plurality of driving environments 10, the plurality of driving projects 20 and the plurality of scenarios 30. The method also includes providing 130 an expected behavior of the autonomous vehicle for each test case of the plurality of test cases. The method further includes simulating 140 the autonomous vehicle in the plurality of test cases. The method also includes an automated evaluation 150 of a deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle.

Embodiments deal with a method and a corresponding computer program that can be used to simulate a behavior of an autonomous vehicle in a plurality of test cases in order to automatically find out whether the programming of the automated vehicle controls the automated vehicle in such a way that the simulated behavior of the vehicle corresponds to the expected behavior of the vehicle. In order to cover as many relevant constellations as possible, even for test situations that may not be recorded in real tests, the majority of test cases are formed in the procedure based on a combination of driving environments, driving projects and scenarios.

For example, the driving environment may be an intersection. When the autonomous vehicle reaches the intersection, it can have different driving intentions, such as turning right, turning left or continuing straight. These driving projects can be carried out differently depending on the scenario, i.e. the autonomous vehicle will be able to turn left more easily if there is no oncoming traffic or if a left-turn traffic light is switched on, or the autonomous vehicle must also be able to react to unexpected situations, for example if a vehicle is driving ahead Cyclist falls at the intersection or if another vehicle gives way to the autonomous vehicle. In other words, the situations arise because one or more changeable objects, such as moving objects such as vehicles or pedestrians, or changeable objects such as traffic lights, have an impact on the driving intentions of the vehicle.

Based on a combination of the different driving environments (such as intersection, highway, country road, roundabout, bus stop, etc.), driving intentions (such as turn left, turn right, go straight, overtake, follow traffic, stop), and scenarios (the influence the one or more changeable objects) the majority of test cases can be generated. For example, the plurality of test cases can be referred to as a catalog of test cases. In other words, the majority of test cases map those test cases with which the autonomous vehicle should be able to cope.

The method includes detecting 110 the plurality of driving environments 10, the plurality of driving projects 20 of the autonomous vehicle for the plurality of driving environments 10, and the plurality of scenarios 30 for the plurality of driving projects 20. For example, detecting 110 the driving environments, the driving projects and the scenarios include reading out the driving environment from a database or from one or more files in a file system. The driving environments, the driving plan and the scenarios can be specified in one or more databases or in the one or more files. For example, the one or more databases or files may include the driving environments, the driving plan, and the scenarios. In some exemplary embodiments, the driving project is specified as a function of the driving environment, ie which driving projects can be carried out can be specified for each driving environment. Alternatively, the driving project can be specified independently of the driving environments. In addition, the scenarios can be specified as a function of the driving environment and/or as a function of the driving project, ie which scenarios can occur for each driving environment, or which scenario can be specified for each combination of driving environment and driving project riae can occur. In at least some exemplary embodiments, the driving environments, the driving project and the scenarios can be implemented and/or illustrated in a layer model, as is shown in FIGS 2 and 3 you can see.

A driving environment can represent a place where a vehicle can move on at least one road or on at least one area. The driving environment can be locally limited, i.e. it can be a place where there is a special traffic feature. For example, a driving environment can be a roundabout, an intersection, a railroad crossing, the vicinity of a bus stop, a freeway entrance, an area around a pedestrian traffic light, or even an area of a country road or freeway that is used to represent a "normal" road. A driving project can represent a driving maneuver that the autonomous vehicle should carry out in the driving environment. For example, a driving intention may be a member of the group of "turn right," "turn left," "go straight," "follow the vehicle in front," "overtake," and "stop." The plurality of scenarios 30 each depict an influence of one or more changeable objects on a driving project of the plurality of driving projects. "Changeable" refers to the fact that the objects within the scenarios can change. In this case, the one or more changeable objects can include, for example, one or more moving objects, such as vehicles (automobiles or bicycles) or pedestrians, which move (and thereby change) in the scenarios. Additionally, the one or more changeable objects may include one or more traffic lights that change within the scenarios. As a result of these changes, the one or more changes have an influence on the respective driving project of the autonomous vehicle.

Both the driving environment and the driving project can be embedded in a larger context. Thus, the plurality of driving environments can be part of a route, i.e. the route can include the plurality of driving environments (without a mission). In addition, a global travel plan (also “mission plan”) can be defined for the route, which includes the majority of travel plans. A mission plan can include a lot of situations (driving projects) (with one mission). A mission can be a set of scenes (driving environments), situations (driving projects) and scenarios. A scene (i.e. driving environment) can be a sub-component of a route, and represent a static environment. A situation (driving intention) can be a description of a local mission in a specific scene (driving environment). The situation can be a sub-component of a mission plan and represent the simplest/baseline scenario. A scenario can be a situation together with a dynamic environment (i.e. other participants). A scenario can define required activities, such as deviations from a mission. A scenario thus represents, for example, a variation or variant of a situation/driving project.

The method includes generating 120 the plurality of test cases for the simulation of the autonomous vehicle based on the plurality of driving environments 10, the plurality of driving projects 20 and the plurality of scenarios 30. The plurality of test cases for (all) possible combinations of the Driving environments, the driving projects and the scenarios are formed. In other words, the plurality of test cases can be formed as a quantity product from the plurality of driving environments 10, the plurality of driving projects 20 and the plurality of scenarios 30. It can be defined beforehand which combinations of driving environment, driving project and scenario are possible, for example if these are specified as dependent on one another. Alternatively, the driving environment, the driving project and the scenarios can be specified independently of one another, and those test cases that do not make sense can be removed from the set of possible combinations.

In some exemplary embodiments, the test cases are not only formed from the combination of the driving environments, the driving projects and the scenarios, but other “layers” can also be adopted, which enable further variations of the test cases. For example, external influencing factors can be included, such as weather, road conditions, an optical signal (e.g. from another road user or from a traffic light/barrier) or an acoustic signal. Accordingly, the method can also detect 115 at least one external influencing factor 40; 50 include. These can be recorded in a similar way to the driving environments, the driving project and the scenarios. The generation of the plurality of test cases for the simulation of the autonomous vehicle can also be based on the at least one external influencing factor. The at least one external influence factor can include at least one element from the group of weather 40, a road condition 50, a visual signal and an acoustic signal.

The method further includes providing 130 the expected behavior of the autonomous vehicle for each test case of the plurality of test cases. There can be one or more for each test case expected, and thus also desired, behavior of the autonomous vehicle. The expected behavior of the autonomous vehicle can specify how the autonomous vehicle should behave in the respective test cases. The expected behavior can be defined deterministically, ie a specific behavior (or several specific behaviors) of the vehicle can be defined in a combination of driving environment, driving behavior and scenario (ie in a test case). This can be done, for example, by specifying one or more activities of the autonomous vehicle for each test case, which are to be carried out by the vehicle in a specific order. The expected behavior may correspond to the one or more activities. In other words, the expected behavior can be defined as a sequence of expected activities of the autonomous vehicle. For example, the expected behavior can be presented as an activity diagram, as shown in 9 shown, displayed and/or entered.

In some exemplary embodiments, part of the expected behavior of the autonomous vehicle is also the definition of a safety driving mode. In a safety driving mode, the autonomous vehicle can, for example, reduce its speed, keep greater distances, let other vehicles pass despite having the right of way, or rely on the help of a remote driver. The expected behavior of the autonomous vehicle can also include boundary conditions from which the safety driving mode is used. In some exemplary embodiments, these limit conditions correspond to the system limits of the programming of the autonomous vehicle. The system limits can be drawn where a "normal" operating mode of the autonomous vehicle is no longer sufficient to enable safe operation of the vehicle. The system limits are exceeded where environmental parameters are (far) outside of normal, for example in particularly bad weather, very narrow streets, tight curve radii or on streets that have an unusual flow of traffic due to an accident or a construction site.

Like the driving environment, driving plans and scenarios, the expected behavior of the autonomous vehicle can be read from a database and/or from one or more files. The expected behavior can, for example, be represented as an activity diagram and/or entered, for example via a web-based input interface or via an application program. Alternatively, the expected behavior of the vehicle can be generated based on the simulation, i.e. the simulation of the one or more test cases can be used to generate the expected behavior. The simulated behavior can be checked, for example by a rule-based computer program or by a human operator, to determine whether it corresponds to a desired behavior and can then be used as the expected behavior.

In some cases, when the method is first performed, an expected behavior is not defined for each test case. In these cases, the method may include identifying 170 a subset of the test cases for which no expected behavior is defined. This subset of test cases can then be provided based on the simulation or based on input from a user.

The method further includes simulating 140 the autonomous vehicle in the plurality of test cases. In the simulation of the autonomous vehicle, the vehicle is confronted with one test case of the plurality of test cases in a simulated environment, i.e. the autonomous vehicle is instructed to carry out the driving project in the driving environment of the test case, taking into account the changeable objects of the respective scenario. In this case, the simulation 140 of the autonomous vehicle can be carried out via a computer simulation that generates the physical events of the test case for the autonomous vehicle, for example by providing simulated sensor data.

Different variants of the respective test case can be simulated, ie different cases can be considered within the same test case, such as different road widths, different curve radii, different visibility conditions, etc. These differences can be specified using at least one changeable parameter. In other words, the test cases of the plurality of test cases can each have at least one changeable parameter. The at least one changeable parameter can be designed to generate different variants within a test case in order to determine the system limits of the programming of the autonomous vehicle. The simulation of the autonomous vehicle can be carried out for different values of the at least one changeable parameter. For example, the at least one changeable parameter can be at least one element from the group of a width of a road, a radius of curvature of a road, a coefficient of friction of a road, a weather situation, a distance between the autonomous vehicle and the one or more changeable objects, a position of a or more changeable objects within the driving environment, a behavior of one or more reren changeable objects, an irregular behavior of the one or more changeable objects, a maximum distance from the object of the one or more changeable objects or an object of the driving environment is detected, and a speed of the autonomous vehicle.

The method further includes the automated evaluation 150 of the deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle. In a simple example, it can first be determined in which test cases the autonomous vehicle deviates from the expected behavior in the simulation. The deviation can be determined, for example, based on an automatic comparison of characteristics of a simulated behavior of the autonomous vehicle in the respective test case with the expected behavior of the autonomous vehicle in the test case. For example, the expected behavior can specify a sequence of activities of the autonomous vehicle in the test case, for example with time constraints for the activities, and the automated comparison can determine whether the specified activities of the sequence and the respective time constraints have been met. If the simulated behavior of the vehicle deviates from the expected behavior, at least in variants of the simulation, if necessary including a tolerance threshold, then a deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle for the test case, or certain parameters -Variations of the test case are detected.

In this case, the system limits of the programming of the autonomous vehicle can be systematically determined by a targeted change of the at least one changeable parameter. In other words, the automated evaluation 150 of the deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle can determine those values of the at least one changeable parameter at which there is a deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle to determine the system limits of the autonomous vehicle. The system boundaries can exist, for example, where the simulation differs from the expected behavior.

Based on the determined system limits, the programming of the autonomous vehicle as well as the expected behavior can then be adjusted. In other words, the method includes, in some exemplary embodiments, an adjustment 160 of the programming of the autonomous vehicle based on the determined system boundaries, such that the programming places the autonomous vehicle in a safety driving mode outside of the system boundaries, i.e. the programming is changed in such a way that this is designed to activate the safety driving mode when the autonomous vehicle is outside the system limits. The method may further include adjusting 165 the expected behavior of the autonomous vehicle. The expected behavior can be adjusted such that the expected behavior outside the system limits is based on the autonomous vehicle using a safety driving mode.

But apart from adjustments based on the system limits, the programming of the autonomous vehicle can be adjusted (automatically or by manual adjustment), for example if a deviation between the expected behavior and the simulation is detected.

More details and aspects of the method are mentioned in connection with the concept or examples that are described later. The method may include one or more additional optional features corresponding to one or more aspects of the proposed concept or the described examples as previously or hereinafter described.

At least some example embodiments deal with the use of a system specification in textual form to test an autonomous vehicle via simulations. For example, it is examined how an autonomous vehicle should behave in road traffic, factory traffic or in restricted areas. A description of non-deterministic vehicle behavior in road traffic, factory traffic or in restricted areas that are not publicly accessible is created. With the help of exemplary embodiments, proof of the completeness of the vehicle behavior to be described can be created, for example in textual form.

Exemplary embodiments create a vehicle function catalog that, for example, maps the majority of test cases. The catalog is based on a procedure for describing driving behavior in road traffic. The catalog includes a deterministic description of the vehicle behavior per situation/scenario by providing the expected behavior of the autonomous vehicle for each test case of the plurality of test cases. A layer structure allows for easier gap analysis and verification, which functionality has not yet been described and therefore not yet simulated and tested.

• - Szene (Statische Umgebung, die Fahrumgebung), z.B. Kreuzung;
• - Situation (Eigendynamik - angewandt auf spezifische Szene, das Fahrvorhaben), z.B. Rechtsabbiegen in der Kreuzung; und
• - Szenario (Eigendynamik an bewegbare Objekte angepasst - angewandt auf spezifische Szene), z.B. Rechtsabbiegen in der Kreuzung und gleichzeitig geradeausfahrender Fahrerfahrer in der Spur.

The invention is based at least in part on describing a non-deterministic vehicle behavior in a deterministic manner, for example by providing an expected behavior of the autonomous vehicle for each test case of the plurality of test cases. A catalog of test cases (the majority of test cases) is generated in at least a three-level layer structure that includes at least the following layers:

• - Scene (static environment, the driving environment), eg intersection;
• - Situation (momentum - applied to specific scene, driving intention), e.g. turning right in the intersection; and
• - Scenario (dynamics adapted to moving objects - applied to specific scene), e.g. turning right in the intersection and at the same time driver driving straight ahead in the lane.

A clear separation of the static environment, its own dynamics and the influence of movable objects is maintained.

• - Wetter
• - Straßenbedingungen
• - Optische Signale
• - Akustische Signale

In addition, other factors that influence vehicle behavior can be included or mapped by adding one or more additional layers. These layers can include, for example, one or more elements of the following external influencing factors:

• - Weather
• - road conditions
• - Optical signals
• - Acoustic signals

• - Objekt 1:
  • Objekt-Typ: Zweispuriges Fahrzeug; Position: dynamisch; relative Position: vorausfahrend; Zugewiesene Spur: in derselben Spur; Zustand: beschleunigt
• - Objekt 2:
  • Objekt-Typ: Verkehrszeichen; Position: statisch; relative Position: voraus; Verkehrszeichen ID: siehe Bast; Verkehrszeichen Typ: z.B.: Bushaltestelle

The moveable objects can be limited by their attributes (such as position, relative position, status, track assignment). For example, two objects, a two-lane vehicle and a traffic sign, can be dominant:

• - Object 1:
  • Object type: Two-track vehicle; position: dynamic; relative position: ahead; Assigned lane: in the same lane; Condition: accelerated
• - Object 2:
  • Object Type: Traffic Sign; position: static; relative position: ahead; Traffic sign ID: see Bast; Traffic sign type: eg: bus stop

Precisely defined objects and their attributes can be permitted for each scenario, with new objects or new states leading to a new scenario.

The vehicle behavior as a reaction to the objects in the environment is described in at least some exemplary embodiments in the form of activity diagrams (effect chains). A “minimum risk manoeuvre” (manoeuvre with minimal risk, maneuver that the vehicle executes in a safety driving mode) can be defined for each chain of effects. A configuration file can be created for each scenario. Using suitable parameter spaces (per scenario), the system limits can be identified and the requirements for vehicle behavior can be sharpened. A calculation sheet can be created for each scenario, which shows the calculation regulations relevant to the scenario, such as calculating the time/distance when braking to a standstill or for the duration of cornering. Missing scenarios can be identified through sufficient test drives and included in the catalogue.

2 FIG. 12 shows a schematic diagram of a functional catalog generation for a vehicle. 2 shows a layered model 200 with the levels driving environment 10 (also “scene”/“scene”), situation 20 (also driving project 20), scenario 30, weather 40 and road condition 40. A scene/driving environment represents the static environment and is one Subcomponent of a route. A situation includes the description of a local mission of a vehicle to be moved for a specific scene. A situation is a sub-component of a mission plan and represents the simplest scenario (with no moving objects). The scenario describes a situation including a dynamic environment (due to other road users). A scenario defines actions to be carried out, such as a deviation from a mission.

3 shows a schematic diagram 300 that illustrates how a test case is generated from a driving environment 10 , a driving project 20 and changeable objects 30 . At this time, a driving intention such as “Turn left” is added to the driving environment 10 to obtain the situation (with the driving intention). Moving objects, such as a cyclist, are added to the situation 20 to obtain a scenario 30 .

4 FIG. 4 shows an overall schematic diagram 400 that encompasses a plurality of test cases based on a plurality of driving conditions Exercises 10, a plurality of driving projects 20, a plurality of scenarios 30, weather 40 and a road condition 50 is generated. The majority of test cases are part of a mission that includes a route, a mission plan, driving environment identifiers, situation identifiers and scenario identifiers. In this case, in at least some exemplary embodiments, a strict layer structure is maintained, in which layers may not be skipped.

5 shows a schematic diagram that illustrates how a mission plan is generated from a route. Thus, a global driving mission is added to a route 510 including a plurality of driving environments to obtain the mission plan 520 including a lot of situations.

The situations and scenarios can be named according to a naming convention/a naming scheme. Thus, in an exemplary embodiment, in the driving environments ("Scenes") between the driving environments C - Crossing, E - Entry/Exit, F - Follow Road on a road), L - Lay-By and R - Round-About. In addition, a distinction can be made between priority Y - Yes (Yes) and N - No (No). When giving way, it is indicated whether the moving vehicle has the right of way, taking traffic regulations and other road users into account. In the driving plans, for example, a distinction can be made between L - Left (left), R - Right (right) and S - Straight (straight ahead). The driving plan states the intention of the moving vehicle in the current driving environment. With respect to an object direction, B - Behind Coming (Approaching from behind), F - Far Side (on the driver's side), N - Near Side (on the passenger's side), O - Oncoming (Oncoming), and P - Preceding (Driving ahead) can be distinguished. The object direction specifies how other moving objects are positioned relative to the moving vehicle. Finally, an object type can be defined. For example, the object types C - Cyclist (cyclists), P - Pedestrian (pedestrians) and V - Vehicle (motor vehicle) can be distinguished. 6 shows an example of the naming scheme. The vehicle 610 is the moving/objective vehicle with the driving intention "Turn right" 615, and bicycle 620 is a moving object with the driving intention "Straight ahead" 625. As a result, for the driving environment with the moving vehicle 610 and the bicycle 620, the code C - Crossing, N - No, R - Right, N - Near Side and C - Cyclist (for the 620 bike).

7a until 7i shows exemplary scenarios. These scenarios can, for example, be key scenarios of a Mobility as a Service concept.

7a shows scenarios where the driving environment 710 is a one-lane roundabout. Vehicle 712a has a driving intent of "Turn right", vehicle 712b has a driving intent of "Straight on" but needs to be aware of bicycle 714a with a driving intent of "Straight ahead" and vehicle 714b with a driving intent of "Straight on", and vehicle 712c has a driving intent of "Links", but must pay attention to vehicle 716 with the driving plan "Straight ahead".

7b shows scenarios in which the driving environment 720 represents following traffic. Vehicle 722a intends to stop to the right and is to pull onto vehicle 724a. Vehicle 722b follows vehicle 724b while vehicle 726 (with the driving intent "Straight on") is coming oncoming. Vehicle 722c has the driving intent "Straight on" and follows vehicle 724c, which also has the driving intent "Straight on".

7c shows scenarios in which the driving environments 730a; 730b; 730c represent a merge track. The driving environments 730a and 730c show the beginning of the merging lane and driving environment 730b shows the end of the merging lane. Vehicle 732a enters a straight dual carriageway via the merge lane, but must watch out for vehicle 734a with a "Straight On" driving intent. Vehicle 732b enters a dual carriageway at the end of the merge lane and must also look out for vehicle 734b with a "Straight On" driving intent. Vehicle 732c is traveling on the dual carriageway and needs to be aware of vehicle 734c attempting to enter the dual carriageway.

7d shows scenarios in which the driving environment 740 represents an intersection where the vehicle 742a; 742b has the right of way. In the first example, vehicle 742a has the driving intention "Right" but has to watch out for bicycle 744a with driving intention "Straight ahead". In the second example, vehicle 742b has the "Right" driving intention, but has to watch out for vehicle 744b with the "Straight ahead" driving intention.

7e shows scenarios in which the driving environments 750a; 750b represents intersections where the vehicles 752a; 752b have no right of way. In doing so, vehicle 752a (with driving intention "Left") must pay attention to vehicle 754a (with driving intention "Right"), and vehicle 752b (with driving intention have "Left" must pay attention to vehicle 754b (with driving intention "straight ahead").

7f shows rescue vehicle scenarios 762a; 762b on road 760. In the first example, rescue vehicle 762a wants to overtake vehicle 764 standing on the edge, but at the same time has to watch out for oncoming vehicle 766. In the second example, emergency vehicle 762b wants to overtake vehicle 768.

7g shows scenarios at a bus stop where vehicle 772a; 772b wants to stop, in the case of driving environment 770a at a bus stop marked on a lane of a dual carriageway, in the case of driving environment 770b in a lay-by of the bus stop.

7h shows scenarios with intersections 780a-780e with traffic lights where vehicles 782a-782e respond to the traffic lights. Vehicle 782a wants to turn left, the straight lane traffic light is green and the left turn lane traffic light is red. Vehicle 782b also wants to turn left, the traffic light (for all lanes) is red. Vehicle 782c wants to turn right and the light (for all lanes) is green. Vehicle 782d wants to make a right turn, the left turn light is red, the straight turn light is green, and there is a right turn lane that is not dependent on the lights. Vehicle 782 wants to turn left, the traffic light is yellow.

7i shows scenarios of driving environments 790a-790c with particularly vulnerable road users. In the first example, vehicle 792a has to watch for a bicycle 794 traveling in a bicycle lane. In the second example, vehicle 792b has to watch out for a pedestrian 796 who wants to cross the street using a traffic island, and vehicle 792c is at an intersection 790c where a pedestrian 798 wants to cross a crosswalk.

The objects involved in the test cases can be represented in object diagrams, for example. 8th shows an object diagram of test case objects. An object 810, such as a vehicle or a pedestrian, includes or consists of n attributes 820, such as a position, a relative position, an object type, an object state or an assigned lane. An object can be, for example, a vehicle driving in front that is stopping on a roadway, or a cyclist on the passenger side who is riding in a (dedicated) bicycle lane.

The system reacts to these specific objects. The system response can be described by activity diagrams. 9 shows an example activity diagram for a situation/scenario. In the activity diagram of 9 the system responds to an object 910 with a set of start criteria, with one or more actions of a system response 920, to arrive at an end state 930.

10 Figure 12 shows a diagram of a method for simulating a plurality of test cases. In the diagram of 10 an expected vehicle behavior is described 1010, for a specific scene and for specific values. The expected vehicle behavior includes system requirements for describing vehicle behavior. Activity diagrams are derived 1020 from the described vehicle behavior 1010. These activity diagrams serve as input for a functional architecture, and as input for HARA (functional safety, hazard and risk assessment, hazard and risk analysis). Based on this, a parameter space can be defined 1030 with the aim of moving from a specific description to a general description. Based on the previous steps, the method includes a simulation 140 of scenarios for all possible combinations (based on the parameter space). The simulation is configured, system limits are determined with the help of the simulation, for example based on a comparison of an expected and an implemented vehicle behavior. Based on the simulation, an iterative adaptation of the expected vehicle behavior takes place (e.g. by specifying the system limits from which a minimum risk maneuver is carried out), and the implemented vehicle behavior is also iteratively adapted. The method may be used, for example, to provide system requirements for vehicle behavior, to provide input to a functional architecture, to provide input to HARA, and/or to determine a configuration of the simulation (usable for development or testing), such as by generating the plurality of test cases.

A further exemplary embodiment is a computer program for carrying out at least one of the methods described above when the computer program runs on a computer, a processor or a programmable hardware component. A further exemplary embodiment is also a digital storage medium which is machine or computer readable and which has electronically readable control signals which can interact with a programmable hardware component in such a way that one of the methods described above is carried out.

In the foregoing description, the following claims and the appended Features disclosed in the figures can be important and implemented both individually and in any combination for the realization of an exemplary embodiment in its various configurations.

Although some aspects have been described in the context of a device, it is understood that these aspects also represent a description of the corresponding method, so that a block or a component of a device is also to be understood as a corresponding method step or as a feature of a method step. Similarly, aspects described in connection with or as a method step also constitute a description of a corresponding block or detail or feature of a corresponding device.

Depending on particular implementation requirements, embodiments of the invention may be implemented in hardware or in software. The implementation may be performed using a digital storage medium such as a floppy disk, a DVD, a Blu-ray disk, a CD, a ROM, a PROM, an EPROM, an EEPROM or a FLASH memory, a hard disk or other magnetic or optical memory, on which electronically readable control signals are stored, which can interact or interact with a programmable hardware component in such a way that the respective method is carried out.

Reference List

10

driving environment/scene

20

Driving plans/situation

30

scenario

40

weather

50

road condition

110

Capturing a plurality of driving environments, a plurality of driving projects, and a plurality of scenarios

115

Capture at least one external influencing factor

120

Generating a plurality of test cases

130

Providing an expected behavior

140

Simulating an autonomous vehicle

150

Automated evaluation

160

Customize programming

165

Customize expected behavior

170

Identify a subset of the test cases

200

layers model

300

Schematic Diagram

400

Schematic Diagram

510

route

520

mission plan

610

vehicle

615

Driving intentions of the vehicle

620

bicycle

625

Driving project of the bicycle

710-798

Elements of example scenarios

810

object

820

Attributes of the object

910

object

920

system reaction

930

final state

1010

Describing an expected vehicle behavior

1020

Deriving activity diagrams

1030

Defining a parameter space

1040

Simulating scenarios

Claims (12)

Method for simulating an autonomous vehicle in a plurality of test cases, the method comprising: detecting (110) a plurality of driving environments (10), a plurality of driving intentions (20) of the autonomous vehicle for the plurality of driving environments (10), and a plurality of scenarios (30) for the plurality of driving projects (20), the plurality of scenarios (30) each depicting an influence of one or more changeable objects on a driving project of the plurality of driving projects; generating (120) the plurality of test cases for the simulation of the autonomous vehicle based on the plurality of driving environments (10), the plurality of driving projects (20) and the plurality of scenarios (30); providing (130) an expected behavior of the autonomous vehicle for each test case of the plurality number of test cases; simulating (140) the autonomous vehicle in the plurality of test cases; and Automated evaluation (150) of a deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle. The procedure according to claim 1 , wherein the test cases of the plurality of test cases each have at least one changeable parameter, wherein the simulation of the autonomous vehicle is carried out for different values of the at least one changeable parameter. The procedure according to claim 2 , wherein the automated evaluation (150) of the deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle determines those values of the at least one changeable parameter at which there is a deviation between the simulation of the autonomous vehicle and the expected behavior of the autonomous vehicle to determine system limits of the autonomous vehicle. The procedure according to claim 3 , further comprising adjusting (160) programming of the autonomous vehicle based on the determined system boundaries such that the programming places the autonomous vehicle in a safe driving mode outside of the system boundaries. The method according to one of claims 3 or 4 , further comprising adjusting (165) the expected behavior of the autonomous vehicle such that the expected behavior outside of system boundaries is based on the autonomous vehicle utilizing a safe driving mode. The method of any preceding claim, further comprising identifying (170) a subset of the test cases for which no expected behavior is defined. The method according to any one of the preceding claims, wherein the expected behavior is deterministically defined. The method according to any one of the preceding claims, wherein the expected behavior is defined as a sequence of expected activities of the autonomous vehicle. The method according to any one of the preceding claims, further comprising detecting (115) at least one external influencing factor (40; 50), wherein the generation of the plurality of test cases for the simulation of the autonomous vehicle is also based on the at least one external influencing factor. The procedure according to claim 9 , wherein the at least one external influence factor comprises at least one element from the group of weather (40), a road condition (50), a visual signal and an acoustic signal. The method according to one of the preceding claims, wherein the plurality of test cases is formed as a quantity product from the plurality of driving environments (10), the plurality of driving projects (20) and the plurality of scenarios (30). Program with a program code for carrying out the method according to one of the preceding claims, if the program code is executed on a computer, a processor, a control module or a programmable hardware component.

Images