WO2022183227A1 - Verfahren und system zum erzeugen von szenariendaten zum testen eines fahrerassistenzsystems eines fahrzeugs - Google Patents

Verfahren und system zum erzeugen von szenariendaten zum testen eines fahrerassistenzsystems eines fahrzeugs Download PDF

Info

Publication number
WO2022183227A1
WO2022183227A1 PCT/AT2022/060055 AT2022060055W WO2022183227A1 WO 2022183227 A1 WO2022183227 A1 WO 2022183227A1 AT 2022060055 W AT2022060055 W AT 2022060055W WO 2022183227 A1 WO2022183227 A1 WO 2022183227A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
scenario
driver assistance
vehicle
assistance system
Prior art date
Application number
PCT/AT2022/060055
Other languages
English (en)
French (fr)
Inventor
Tobias DÜSER
Original Assignee
Avl List Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Avl List Gmbh filed Critical Avl List Gmbh
Priority to EP22715966.2A priority Critical patent/EP4302197A1/de
Priority to KR1020237032926A priority patent/KR20230148366A/ko
Priority to CN202280031472.6A priority patent/CN117222988A/zh
Priority to JP2023552229A priority patent/JP2024507997A/ja
Publication of WO2022183227A1 publication Critical patent/WO2022183227A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01M—TESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M17/00—Testing of vehicles
    • G01M17/007—Wheeled or endless-tracked vehicles
    • G01M17/06—Steering behaviour; Rolling behaviour
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01M—TESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M17/00—Testing of vehicles
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01M—TESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M17/00—Testing of vehicles
    • G01M17/007—Wheeled or endless-tracked vehicles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3696—Methods or tools to render software testable
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/15—Vehicle, aircraft or watercraft design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09B—EDUCATIONAL OR DEMONSTRATION APPLIANCES; APPLIANCES FOR TEACHING, OR COMMUNICATING WITH, THE BLIND, DEAF OR MUTE; MODELS; PLANETARIA; GLOBES; MAPS; DIAGRAMS
    • G09B9/00—Simulators for teaching or training purposes
    • G09B9/02—Simulators for teaching or training purposes for teaching control of vehicles or other craft
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09B—EDUCATIONAL OR DEMONSTRATION APPLIANCES; APPLIANCES FOR TEACHING, OR COMMUNICATING WITH, THE BLIND, DEAF OR MUTE; MODELS; PLANETARIA; GLOBES; MAPS; DIAGRAMS
    • G09B9/00—Simulators for teaching or training purposes
    • G09B9/02—Simulators for teaching or training purposes for teaching control of vehicles or other craft
    • G09B9/04—Simulators for teaching or training purposes for teaching control of vehicles or other craft for teaching control of land vehicles
    • G09B9/05—Simulators for teaching or training purposes for teaching control of vehicles or other craft for teaching control of land vehicles the view from a vehicle being simulated

Definitions

  • the invention relates to a computer-implemented method for generating scenario data for testing a driver assistance system of a vehicle. Furthermore, the invention relates to a corresponding system.
  • driver assistance systems Advanced Driver Assistance Systems - ADAS
  • autonomous Driving - AD autonomous driving
  • Driver assistance systems make an important contribution to increasing active traffic safety and serve to increase driving comfort.
  • ABS anti-lock braking system
  • ESP electronic stability program
  • Driver assistance systems that are already being used to increase active road safety include a parking assistant, an adaptive cruise control system, also known as adaptive cruise control (ACC), which adaptively regulates a desired speed selected by the driver based on the distance from the vehicle in front.
  • ACC stop-and-go systems which in addition to the ACC causes the vehicle to continue driving automatically in traffic jams or when vehicles are stationary
  • lane keeping or lane assist systems which automatically keep the vehicle in its lane and pre-crash systems which, in the event of a collision, prepare or initiate braking, for example, in order to take the kinetic energy out of the vehicle, and initiate other measures if a collision is unavoidable.
  • driver assistance systems both increase safety in traffic by warning the driver in critical situations and initiate an independent one Intervention to avoid or reduce accidents, for example by activating an emergency braking function.
  • driving comfort is increased by functions such as automatic parking, automatic lane keeping and automatic distance control.
  • the safety and comfort gain of a driver assistance system is only perceived positively by the vehicle occupants if the support from the driver assistance system is safe, reliable and - as far as possible - comfortable.
  • each driver assistance system depending on its function, must manage scenarios that occur in traffic with maximum safety for the vehicle and without endangering other vehicles or other road users.
  • the respective degree of automation of vehicles is divided into so-called automation levels 1 to 5 (see, for example, the SAE J3016 standard).
  • the present invention relates in particular to vehicles with driver assistance systems of automation level 3 to 5, which is generally considered to be autonomous driving.
  • the challenges for testing such systems are manifold. In particular, a balance must be found between the test effort and the test coverage.
  • the main task when testing ADAS/AD functions is to demonstrate that the function of the driver assistance system is guaranteed in all conceivable situations, especially in critical driving situations. Such critical driving situations have a certain degree of danger, since no reaction or an incorrect reaction of the respective driver assistance system can lead to an accident.
  • driver assistance systems therefore requires a large number of driving situations, which can arise in different scenarios, to be taken into account.
  • the range of possible scenarios is generally spanned by many dimensions (e.g. different road properties, behavior of other road users, weather conditions, etc.). From this almost infinite and multidimensional parameter space, it is particularly relevant for testing the driver assistance systems, such parameter constellations for to extract critical scenarios that can lead to unusual or dangerous driving situations.
  • a first aspect of the invention relates to a computer-implemented method for generating scenario data for testing a driver assistance system of a vehicle, having the following work steps:
  • Simulation of a virtual traffic situation which has a plurality of virtual road users, wherein at least a first road user of the plurality of road users can be controlled by a first user and wherein those road users who cannot be controlled by users are automated, in particular by artificial intelligence or logic-based, to be controlled,
  • the extracted scenario data are preferably output. This is preferably done via a user interface or a data interface.
  • a user within the meaning of the invention is a natural person, i. H. a human.
  • a driver assistance system within the meaning of the invention is preferably set up to support a driver when driving or to at least partially guide a vehicle, in particular a driver assistance system of automation level 3 to 5, or more particularly an autonomous driving function.
  • Traffic user within the meaning of the invention is preferably any object that participates in traffic.
  • a road user is a person, an animal or a vehicle.
  • extraction preferably means delimiting or isolating.
  • scenarios are delimited or isolated from the scenario data.
  • data areas in the scenario data are preferably selected.
  • Scenario data within the meaning of the invention are preferably characterized by the position and movement of road users and the position of static objects in relation to a scenario.
  • a scenario within the meaning of the invention is preferably formed from a chronological sequence of, in particular static, scenes.
  • the scenes give example, the spatial arrangement of the at least one other object relative to the ego object, z. B. the constellation of road users.
  • a scenario preferably considers dynamic and static content.
  • a model for the systematic description of scenarios is preferably used here, more preferably the model of the PEGASUS project (https://www.pegasusschreib.de) with the following six independent levels: 1st street (geometry,%) ; 2. Street furniture and rules (traffic signs,...); 3. Temporary changes and events (road construction,...); 4. Moving objects (traffic-related objects such as: vehicles, pedestrians,... that move relative to the vehicle to be tested); 5.
  • a scenario can contain, in particular, a driving situation in which a driver assistance system at least partially controls the vehicle, which is called the ego vehicle and is equipped with the driver assistance system, e.g. B. performs at least one vehicle function of the ego vehicle autonomously.
  • a traffic situation within the meaning of the invention preferably describes the totality of all circumstances in traffic with road users in a defined spatial area and/or in a defined period of time or point in time. These circumstances are preferably taken into account by road users for the selection of suitable behavior patterns at a specific point in time.
  • a traffic situation preferably includes all relevant conditions, possibilities and determinants of actions.
  • a traffic situation can, but does not have to, be represented from the point of view of a road user or object.
  • the simulated measured variables within the meaning of the invention are preferably selected from the following group: speed, in particular an initial speed, of a road user; a direction of movement, in particular a trajectory, of a road user; lighting conditions; Weather; road surface; Temperature; number and position of static and/or dynamic objects; a speed and a direction of movement, in particular a trajectory, of the dynamic objects; condition of signaling installations, in particular light signaling installations; traffic signs; number of lanes; Acceleration or deceleration of road users or objects.
  • a predefined constellation of measured variables within the meaning of the invention is preferably a constellation of values of one or more measured variables, in particular over time.
  • label means preferably provided with a categorizing designation.
  • An increased probability of an accident can be triggered in particular by a driving manoeuvre, for example an evasive reaction or strong gradient changes when steering, braking, accelerating (eg a vehicle gives way due to a strong steering movement).
  • An increased accident probability can, in particular, also with regard to the other road users (who are guided based on logic or AI) and in a critical driving situation have to leave their driving order or their actual trajectory (by a evasive maneuvers).
  • An increased probability of an accident can also arise, in particular, from external factors which affect the first road user or the other road users, for example if a driver is blinded.
  • a quality within the meaning of the invention preferably characterizes the simulated scenario.
  • a grade is preferably understood to mean a quality or nature and/or a relevance of the simulated scenario in relation to the dangerousness of a driving situation for a specific driver assistance system.
  • Relevance within the meaning of the invention is preferably understood to mean the frequency with which a scenario occurs in road traffic. For example, a backlit scenario is more relevant than a scenario in which an airplane lands on the street.
  • the relevance preferably also depends on the region for which the road traffic is relevant. For example, there are scenarios that are relevant in Germany but not in China.
  • An area surrounding the vehicle within the meaning of the invention is preferably formed at least by the road users and other objects relevant to the vehicle guidance by the driver assistance system.
  • the surroundings of the vehicle include scenery and dynamic elements.
  • the scenery preferably includes all stationary elements.
  • the invention is based on the approach of using real people to generate scenarios, but no test drives in real traffic are required.
  • At least one real driver moves a vehicle in a virtual environment or a virtual environment.
  • the invention makes the generation of scenarios accessible to a crowdsourcing approach.
  • One or more users can now navigate a road user of their choice through virtual traffic situations on a simulator. Due to the almost endless possibility of options when navigating the road user(s) and other random mechanisms when simulating the virtual traffic situation, an almost endless number of different scenarios can arise, just like in real traffic.
  • the invention uses predefined criteria to determine whether known or new scenarios occur. For this purpose, the simulation process and in particular the simulation data generated by it are continuously analyzed and monitored.
  • people's natural play instinct can be exploited. In this way, the method according to the invention or even a corresponding system can be made available to users.
  • the users can then drive around in the simulated traffic "for fun".
  • the users could also be given tasks, for example that they should get from a location A to a location B as quickly as possible while observing traffic regulations, or that they have to collect certain objects.
  • the user could be distracted when navigating through the simulated traffic, e.g. B. in which he has to make certain voice inputs or the like.
  • the physics in the simulation correspond to reality in order to generate scenario data that is as realistic as possible. This applies in particular to the physical properties of road users and those of the environment. It is not possible to drive through objects or the like. More preferably, multiple users navigate multiple road users in the simulated traffic.
  • the scenario data generated in this way are already labeled, in particular objects of the virtual traffic situation are labeled.
  • Information about the properties of objects is available in the simulation, so that the information can be assigned to the objects.
  • the scenario data are described during extraction in such a way that they can be used to simulate scenarios, preferably using OpenSCENARIO® or are output as OSI data. This means that the scenario data can be used directly to simulate scenarios.
  • the user is encouraged to be active by various actions in the simulated virtual traffic environment.
  • Such an activity can be, for example, the simulated behavior of another road user.
  • these other Road users behave in such a way that the user has to react.
  • this also has the following work steps:
  • Determining a quality of the extracted scenario data as a function of a predefined criterion the quality preferably being characterized by the dangerousness of an underlying scenario.
  • the quality indicates the quality of an underlying scenario.
  • the extracted scenario data are preferably output when the quality reaches a termination condition.
  • the quality is also preferably output to the user via a first or second user interface, in particular a display.
  • a termination condition can preferably be a calculated duration up to a collision time or a collision probability.
  • the quality is higher the more dangerous the scenario that has arisen is, in particular the shorter the calculated duration up to a collision time.
  • a reward in particular a fictitious one, is credited to the first user as a function of the quality of a scenario which has occurred. This gives the user motivation to create critical scenarios.
  • a traffic flow model in particular PTV-Vissim® or Eclipse SUMO, in particular version 1.8.0, is used to simulate the virtual traffic situation.
  • a particularly realistic traffic situation can be generated by using a traffic flow model.
  • a second aspect of the invention relates to a computer-implemented method for testing a driver assistance system of a vehicle, having the following work steps: Providing scenario data which characterize a scenario in which the vehicle is located and which has a plurality of other road users, the scenario data being generated using a method for generating scenario data according to the first aspect of the invention;
  • the driver assistance system is simulated. This means that only the software or the actual code of the driver assistance system is taken into account or implemented when simulating the virtual traffic situation, according to the “software-in-the-loop” concept. In this way, a driver assistance system can be tested in a pure simulation.
  • a driver assistance system when the driver assistance system is operated, data relating to the vehicle's surroundings are fed into the driver assistance system and/or the driver assistance system, in particular its sensors, are stimulated on the basis of the vehicle's surroundings.
  • This allows the driver assistance system, in particular its software or the entire hardware, to be tested on a test bench.
  • a hardware-in-the-loop method can be used for this.
  • a third aspect of the invention relates to a system for generating scenario data for testing a driver assistance system of a vehicle, having:
  • Means for simulating a virtual traffic situation which has a plurality of virtual road users, wherein at least a first road user of the plurality of road users can be controlled by a first user and wherein those road users who cannot be controlled by users are automated, in particular by artificial intelligence or logic-based, with simulation data being generated when simulating; a first, in particular at least optical, user interface for outputting, on the basis of the virtual traffic situation, a virtual environment of at least one first road user to the first user; and a second user interface for acquiring inputs from the first user for controlling the at least one first road user in a virtual environment surrounding the first road user, the means for simulating being further set up to use the acquired inputs from the first user and the resulting interaction of the at least to consider a first road user with his virtual environment when simulating the virtual traffic situation;
  • Means within the meaning of the invention can be hardware and/or software and in particular one, preferably with a memory and/or bus system data or signal connected, in particular digital, processing, in particular microprocessor units (CPU) and/or one or more Have programs or program modules.
  • the CPU can be designed to process commands that are implemented as a program stored in a memory system, to detect input signals from a data bus and/or to emit output signals to a data bus.
  • a storage system can have one or more, in particular different, storage media, in particular optical, magnetic, solid state and/or other non-volatile media.
  • the program may be designed to embody or perform the methods described herein is capable of, so that the CPU can execute the steps of such methods and then in particular can generate scenarios.
  • a fourth aspect of the invention relates to a system for testing a driver assistance system of a vehicle, comprising: a data memory for providing scenario data which characterize a scenario in which the vehicle is located and which has a plurality of other road users, the scenario data using a method according to any one of claims 1 to 8;
  • FIG. 1 shows a diagram of the probability of occurrence of scenarios as a function of their criticality
  • FIG. 2 shows a block diagram of an exemplary embodiment of a method for generating scenarios
  • FIG. 3a shows a first example of a simulated virtual traffic situation
  • FIG. 3b shows a second example of a simulated virtual traffic situation
  • FIG. 4 shows an exemplary embodiment of a system for generating scenario data for testing a driver assistance system of a vehicle
  • FIG. 5 shows a block diagram of an exemplary embodiment of a method for testing a driver assistance system of a vehicle
  • FIG. 6 shows an example of a simulated scenario
  • FIG. 7 shows an exemplary embodiment of a system for testing a driver assistance system of a vehicle.
  • Figure 1 shows the probability of occurrence of scenarios depending on the criticality of scenarios.
  • the probability of occurrence is the probability of scenarios occurring in real road traffic.
  • the first work step 101 In a first work step 101, simulation data are generated.
  • the first work step 101 preferably has three sub-processes.
  • a virtual traffic situation 3 is simulated, which has a plurality of virtual road users 1 , 4 , 5 a , 5 b , 5 c , 5 d , 6 .
  • this virtual traffic situation 3 at least one first road user 1 of the plurality of road users 1, 4, 5a, 5b, 5c, 5d, 6 can preferably be controlled by a first user 2 (cf. FIG. 4) and those road users 4, 5a, 5b , 5c, 5d, 6, which cannot be controlled by users, are controlled automatically.
  • a large number of road users can preferably be located in the simulated virtual traffic situation 3 and are controlled by users, ie people.
  • the simulation is based on data obtained in a real test drive.
  • the parameters of individual objects e.g. B. their speed can be changed by road users or be taken over as they were recorded during the real test drive.
  • the traffic situation 3 is created purely on the basis of mathematical algorithms. Both approaches can preferably also be mixed.
  • Such a simulated traffic situation 3 is shown, for example, in FIG. 3a.
  • a pedestrian 6 crosses a street.
  • a vehicle 1 which is controlled by the first user, approaches the pedestrian 6 in the lane facing the pedestrian 6 .
  • other vehicles 5b, 5c, 5d are parked, through which the pedestrian 6 is not or only poorly visible to a driver of the vehicle 1 controlled by the user.
  • Another vehicle 5a is driving in the second lane for oncoming traffic at the level of pedestrian 6.
  • a motorcyclist 4 is approaching behind the other vehicle 5a and is preparing to overtake the other vehicle 5a. Whether this motorcyclist 4 is visible to the driver of the vehicle controlled by the first user cannot be deduced from FIG. 3a.
  • the other vehicles 5a, 5b, 5c, 5d, the pedestrian 6 and the motorcyclist 4 form a virtual environment of the vehicle 1 controlled by the first user 2 in the traffic situation 3.
  • FIG. 3b shows the same virtual traffic situation 3 as FIG. 3a, in which the vehicle controlled by the first user 1 is in the same initial scenario as in FIG. 3a. As indicated by the movement arrow, which emanates from the vehicle 1 controlled by the first user, the first user continues to control this vehicle 1 with undiminished speed.
  • the virtual traffic situation 3 is output to the first user 2 via a first user interface 12 .
  • Possible user interfaces are shown as examples in Fig. 4 and preferably include optical user interfaces, in particular screens, audio user interfaces, in particular speakers, and/or a user interface for stimulating the sense of balance of the first user 2.
  • a third process 101 -3 of the first work step 101 inputs by the first user 2 for controlling the at least one road user in a virtual environment of the first road user 1 are recorded via a second user interface 13 .
  • the second user interfaces 13 are also shown in FIG. 4 . It is preferably the steering wheel, a gear shift, a handbrake, a brake pedal, a clutch and/or an accelerator pedal and other possible control instruments that are available to a driver in a vehicle. Depending on which type of road user 1, 4, 5a, 5b, 5c, 5d, 6 the user 2 controls, however, other input means can also be present as the user interface 13, for example a type of joystick.
  • the first road user 1 in FIGS. 3a and 3b is the black vehicle.
  • the recorded inputs of the first user 2 and the resulting interaction of the vehicle 1, i. H. of the first road user, with its virtual environment are simulating the traffic situation 3 shown in FIGS. 3a and 3b.
  • the interaction in the traffic situations 3 shown in FIGS. 3a and 3b is, for example, how the first user 2 reacts to the initial scenario.
  • the other road users in particular the other oncoming vehicle 5a and the motorcyclist 4 and the pedestrian 6, will also react.
  • the motorcyclist 4 will brake when he notices that the vehicle 1 controlled by the first user 2 is not reducing its speed.
  • the work step of generating 101 simulation data is therefore a continuous process which, as indicated in FIG. 2, runs constantly in a loop and generates simulation data in the process.
  • scenario data is used, for example, to test a driver assistance system, it can be reconstructed which objects the driver assistance system correctly detected and which it incorrectly detected.
  • labels are, for example, tree, pedestrian, car, truck, etc.
  • 3 actions are set in the driving situations, which encourage the first user to be active.
  • this could be one in the Driving situation 3 of FIGS. 3a and 3b can be a vehicle which follows the vehicle 1 controlled by the first user 2 and urges it to accelerate.
  • a surprising movement trajectory of the pedestrian 6, for example when he starts to run, can also be such an action.
  • the simulation data generated are checked for the occurrence of scenarios which arise from the interaction of the at least one first road user 1, the black vehicle in FIGS. 3a and 3b, with the virtual environment.
  • already known scenarios which have already occurred earlier or are predefined as templates, can be checked, as well as scenarios that have not yet been predefined.
  • Both types of scenarios are preferably defined by predefined constellations of simulated measurement variables, which can be determined from the virtual traffic situation 3 .
  • These predefined constellations either form the templates for scenarios or correspond to elementary maneuvers from which the occurrence of a scenario can be inferred. This could be, for example, a strong braking deceleration of the vehicle 1 in FIGS. 3a and 3b, which is used as a trigger condition for the occurrence of a scenario that has not yet been predefined.
  • scenario data relating to the scenario are extracted in a third work step 103 .
  • extraction means in particular delimiting or isolating a data area in the simulation data that is related to the determined scenario.
  • the scenario data are preferably described during extraction in such a way that they are suitable for simulating scenarios. These can preferably be used with OpenSCENARIO® or OpenDrive®. More preferably, these are output as OSI data or OSI streams.
  • a quality of the resulting scenario is preferably determined as a function of a predefined criterion, with the quality preferably being characterized by the dangerousness of one of the scenarios.
  • the quality is preferably all the higher, the more dangerous the resulting scenario is.
  • a degree of danger is preferably determined by so-called time-to-X metrics, such as those described in the publication “Metrics for assessing the criticality of traffic situations and scenarios”; P. Junietz et al., 11 . Workshop Driver Assistance Systems and Automated Driving”, FAS 2017.
  • duration up to a point in time at which a collision occurs time to collision
  • time to kickdown time to steer
  • time to react distance of closest encounter
  • Time to Closest Encounter Worst Time to Collision.
  • the level of danger is characterized by a probability of an accident.
  • a reward in particular a fictitious one, is credited to the first user 2 as a function of the quality of the scenario that has occurred.
  • FIG. 4 shows a system 10 for generating scenarios for testing a driver assistance system of a vehicle.
  • This system 10 preferably has means 11 for simulating a virtual traffic situation 3, which has a plurality of virtual road users.
  • the system In order to make road users 1 controllable by a first user 2 , the system also has at least one first user interface 12 and at least one second user interface 13 .
  • the at least one first user interface 12 is used to output a virtual environment of at least one first road user 1 to the first user 2 .
  • the virtual environment of the at least one first road user 1 is determined on the basis of the simulated virtual traffic situation 3 . It is essentially a representation of the virtual traffic situation 3 in the initial scenario from the point of view of the first road user 1, which the first user 2 controls.
  • these user interfaces 12 are visual user interfaces such as screens and audio interfaces such as Loudspeakers and possibly devices with which the sense of balance of the respective user 2 can be influenced.
  • the second user interface or user interfaces 13 are set up to record inputs from the respective user 2 . As shown in FIG. 4, these are preferably different operating elements. As already explained above, these can be dependent on the respective road user 1 controlled by the user 2 . If the road user 1 controlled by the first user 2 is a vehicle, the user interfaces 12, 13 are preferably arranged in the area of a so-called seat box 19, which forms a simulator together with the user interfaces 12, 13, as shown in FIG.
  • the system 10 preferably has means 14 for checking the generated simulation data for the occurrence of scenarios. Furthermore, the system 10 preferably has means 15 for extracting scenario data relating to the scenario and a data memory 16 for recording the scenario data. Further preferably, the system 10 preferably has means for determining a quality of the extracted scenario data as a function of a predefined criterion. Furthermore, the system 10 preferably has a further interface 18 which is preferably set up as a user interface in order to output the quality to the user 2 and/or as a data interface in order to output the scenario data for further processing.
  • the means 11, 14, 15, 16, 17, 18 are preferably part of a data processing device, which is preferably formed by a computer.
  • FIG. 5 shows a flow chart of an exemplary embodiment of a method 200 for testing a driver assistance system 7 of a vehicle 8, as illustrated in FIG.
  • scenario data which characterize a scenario in which the vehicle 8) is located and which preferably has a plurality of other road users 4', 5a', 5b', 5c', 5d', 6', in a first step 201 simulated.
  • scenario data are also preferably based on simulations, from which they were extracted according to the method 100 described above.
  • a scenario is simulated in a second step 202 on the basis of the scenario data.
  • the vehicle 8 with the driver assistance system 7 to be tested is located in this scenario.
  • the scenario preferably has a plurality of other road users or objects.
  • a virtual environment of the vehicle 8 is generated with the driver assistance system 7 and output.
  • a third work step 203 the virtual environment is output to driver assistance system 7 via an interface 23 .
  • driver assistance system 7 is operated in the virtual environment of vehicle 8 in a fourth work step 204 .
  • driver assistance system 7 The driving behavior of driver assistance system 7 in the scenario or environment can then be analyzed and evaluated.
  • the driver assistance system 7 can be optimized on the basis of such an analysis or evaluation.
  • the driver assistance system 7 of a vehicle 8 has a radar system which detects the objects located in the area surrounding the vehicle 8, in particular the road users 4', 5a', 5b', 5c', 5d', 6' detected.
  • driver assistance system 7 is integrated into passenger vehicle 8 .
  • the driver assistance system to be tested could also be integrated into the motorcycle 4'.
  • the motorcyclist could be warned at an early stage by sensors in the driver assistance system and therefore not pull out.
  • the driver assistance system of the motorcycle 4' reacts and the black car can continue driving without a collision occurring.
  • a system 20 for testing a driver assistance system 7, which is suitable for executing the method 200 described with reference to FIGS. 5 and 6, is shown in FIG.
  • Such a system 20 has a data memory 21 for providing scenario data which characterize a scenario in which the vehicle 8 is located.
  • Means 22 are set up to simulate a virtual environment of the vehicle on the basis of the scenario data. Furthermore, the means 22 are set up to also render this environment.
  • an interface 23 is set up to output the virtual environment of a driver assistance system 7 .
  • Such an interface can be a screen if the driver assistance system 7 has an optical camera.
  • the sensor of the driver assistance system is a radar sensor, which emits a signal S. This signal S is detected by radar antennas 23 .
  • the means 22 for simulating calculate a response signal S′, which in turn is output to the radar of the driver assistance system.
  • a response signal S′ which in turn is output to the radar of the driver assistance system.
  • the function of the driver assistance system 7 can be tested.
  • the simulated virtual environment as shown in FIG. 7, can be tested by emulating signals to the sensor of the driver assistance system 7 .
  • a signal can also be generated that is fed directly into the data processing unit 7 of the driver assistance system, or else a signal S′ that is only processed by the software of the driver assistance system 7 .
  • the data memory 21 and the means for simulating 22 are preferably part of a data processing device.

Abstract

Die Erfindung betrifft System (10) zum Erzeugen von Szenariendaten zum Testen eines Fahrerassistenzsystems eines Fahrzeugs und ein entsprechendes Verfahren, wobei das System aufweist: Mittel (11) zum Simulieren einer virtuellen Verkehrssituation (3) wobei wenigstens ein erster Verkehrsteilnehmer (1 ) von einem ersten Benutzer (2) steuerbar ist und wobei beim Simulieren Simulationsdaten erzeugt werden; eine erste Benutzerschnittstelle (12) zum Ausgeben, auf der Grundlage der virtuellen Verkehrssituation (3), eines virtuellen Umfelds des wenigstens einen ersten Verkehrsteilnehmers (1) an den ersten Benutzer (2); eine zweite Benutzerschnittstelle (13) zum Erfassen von Eingaben des ersten Benutzers (2) zum Steuern des wenigstens einen ersten Verkehrsteilnehmers (1) in einem virtuellen Umfeld des ersten Verkehrsteilnehmers (1); Mittel (14) zum Prüfen der erzeugten Simulationsdaten auf ein Auftreten von Szenarien; Mittel (15) zum Extrahiere von Szenariendaten in Bezug auf das Szenario; und einen Datenspeicher (16) zum Aufzeichnen der Szenariendaten zum Testen des Fahre rassiste nzsystems.

Description

Verfahren und System zum Erzeugen von Szenariendaten zum Testen eines Fahrerassistenzsystems eines Fahrzeugs
Die Erfindung betrifft ein computerimplementiertes Verfahren zum Erzeugen von Sze nariendaten zum Testen eines Fahrerassistenzsystems eines Fahrzeugs. Des Weite ren betrifft die Erfindung ein entsprechendes System.
Die Verbreitung von Fahrerassistenzsystemen (Advanced Driver Assistance Systems - ADAS), welche in einer Weiterentwicklung autonomes Fahren (Autonomous Driving - AD) ermöglichen, nehmen sowohl im Bereich der Personenkraftwagen als auch bei Nutzfahrzeugen ständig zu. Fahrerassistenzsysteme leisten einen wichtigen Beitrag zur Erhöhung der aktiven Verkehrssicherheit und dienen zur Steigerung des Fahrkom forts.
Neben den insbesondere der Fahrsicherheit dienenden Systemen wie ABS (Anti-Blo- ckier-System) und ESP (Elektronisches Stabilitätsprogramm) werden im Bereich der Personenkraftwagen und der Nutzfahrzeuge einer Vielzahl von Fahrerassistenzsyste men angeboten.
Fahrerassistenzsysteme, welche bereits zur Erhöhung der aktiven Verkehrssicherheit eingesetzt werden, sind ein Parkassistent, ein adaptiver Abstandsregeltempomat, der auch als Adaptive Cruise Control (ACC) bekannt ist, welcher eine vom Fahrer gewählte Wunschgeschwindigkeit adaptiv auf einen Abstand zu einem vorausfahrenden Fahr zeug einregelt. Ein weiteres Beispiel für solche Fahrerassistenzsysteme sind ACC- Stop-&-Go-Systeme, welche zusätzlich zum ACC die automatische Weiterfahrt des Fahrzeugs im Stau oder bei stehenden Fahrzeugen bewirkt, Spurhalte- oder Lane- Assist-Systeme, die das Fahrzeug automatisch auf der Fahrzeugspur halten, und Pre- Crash-Systeme, die im Fall der Möglichkeit einer Kollision beispielsweise eine Brem sung vorbereiten oder einleiten, um die kinetische Energie aus dem Fahrzeug zu neh men, sowie gegebenenfalls weitere Maßnahmen einleiten, falls eine Kollision unver meidlich ist.
Diese Fahrerassistenzsysteme erhöhen sowohl die Sicherheit im Verkehr, indem sie den Fahrer in kritischen Situationen warnen, bis zur Einleitung eines selbstständigen Eingriffs zur Unfallvermeidung oder Unfallverminderung, beispielsweise indem eine Notbremsfunktion aktiviert wird. Zusätzlich wird der Fahrkomfort durch Funktionen wie automatisches Einparken, automatische Spurhaltung und automatische Abstandskon trolle erhöht.
Der Sicherheits- und Komfortgewinn eines Fahrerassistenzsystems wird von den Fahr zeuginsassen nur dann positiv wahrgenommen, wenn die Unterstützung durch das Fahrerassistenzsystem sicher, verlässlich und in - soweit möglich - komfortabler Weise erfolgt.
Darüber hinaus muss jedes Fahrerassistenzsystem, je nach Funktion, im Verkehr auf tretende Szenarien mit maximaler Sicherheit für das eigene Fahrzeug und auch ohne Gefährdung anderer Fahrzeuge bzw. anderer Verkehrsteilnehmer bewerkstelligen.
Der jeweilige Automatisierungsgrad von Fahrzeugen wird dabei in sogenannte Auto- matisierungslevel 1 bis 5 unterteilt (vgl. beispielsweise Norm SAE J3016). Die vorlie gende Erfindung betrifft insbesondere Fahrzeuge mit Fahrerassistenzsystemen des Automatisierungslevels 3 bis 5, welches im Allgemeinen als autonomes Fahren be trachtet wird.
Die Herausforderungen zum Testen solcher Systeme sind vielfältig. Insbesondere muss ein Ausgleich zwischen dem Testaufwand und der Testabdeckung gefunden werden. Dabei ist die Hauptaufgabe beim Testen von ADAS/AD-Funktionen, zu de monstrieren, dass die Funktion des Fahrerassistenzsystems in allen vorstellbaren Si tuationen gewährleistet ist, insbesondere auch in kritischen Fahrsituationen. Solche kritischen Fahrsituationen weisen eine gewisse Gefährlichkeit auf, da keine oder eine falsche Reaktion des jeweiligen Fahrerassistenzsystems zu einem Unfall führen kann.
Das Testen von Fahrerassistenzsystemen erfordert daher eine Berücksichtigung einer großen Anzahl von Fahrsituationen, welche sich in verschiedenen Szenarien ergeben können. Der Variationsraum von möglichen Szenarien wird dabei im Allgemeinen durch viele Dimensionen aufgespannt (z. B. verschiedene Straßeneigenschaften, ein Verhalten von anderen Verkehrsteilnehmern, Wetterbedingungen, etc.). Aus diesem nahezu unendlichen und multidimensionalen Parameterraum ist es zum Testen der Fahrerassistenzsysteme besonders relevant, solche Parameterkonstellationen für kritische Szenarien zu extrahieren, welche zu ungewöhnlichen oder gefährlichen Fahr situationen führen können.
Wie in Fig. 1 dargestellt, haben solche kritischen Szenarien eine weit geringere Auf trittswahrscheinlichkeit als übliche Szenarien.
Wissenschaftliche Veröffentlichungen gehen davon aus, dass ein Betrieb eines Fahr zeugs im autonomen Fährbetrieb nur dann statistisch sicherer als ein von Menschen gesteuertes Fahrzeug ist, wenn mit dem entsprechenden Fahrerassistenzsystem 275 Millionen Meilen unfallfreier Fahrzeit absolviert wurden, um das entsprechende Fah rerassistenzsystem zu validieren. Dies ist mittels realer Testfahrten eigentlich nicht zu realisieren, insbesondere vor dem Flintergrund, dass die Entwicklungszyklen und Qua litätsstandards, welche in der Automobilindustrie gefordert sind, schon einen sehr en gen Zeitrahmen setzen. Auch wäre es unwahrscheinlich, dass eine ausreichende Menge von kritischen Szenarien bzw. sich aus diesen Szenarien ergebenden Fahrsi tuationen aus dem vorgenannten Grund enthalten wären.
Aus dem Stand der Technik ist es bekannt, reale Testfahrdaten einer realen Flotte von Testfahrzeugen zum Validieren und Verifizieren von Fahrerassistenzsystemen einzu setzen und aus den aufgezeichneten Daten Szenarien zu extrahieren. Des Weiteren ist es bekannt, zum Validieren und Verifizieren vollfaktorielle Versuchspläne einzuset zen.
Es ist eine Aufgabe der Erfindung, Fahrerassistenzsysteme, insbesondere Autonome Fahrfunktionen, in einer Vielzahl von Szenarien prüfen zu können. Insbesondere ist es eine Aufgabe der Erfindung, Szenarien zum Testen von Fahrerassistenzsystemen zu erzeugen.
Diese Aufgabe wird durch die Lehre der unabhängigen Ansprüche gelöst. Vorteilhafte Ausgestaltungen finden sich in den abhängigen Ansprüchen.
Ein erster Aspekt der Erfindung betrifft ein computerimplementiertes Verfahren zum Erzeugen von Szenariendaten zum Testen eines Fahrerassistenzsystems eines Fahr zeugs, folgende Arbeitsschritte aufweisend:
Erzeugen von Simulationsdaten durch folgende Unterschritte: Simulieren einer virtuellen Verkehrssituation, welche eine Mehrzahl an virtuellen Ver kehrsteilnehmern aufweist, wobei wenigstens ein erster Verkehrsteilnehmer der Mehr zahl an Verkehrsteilnehmern von einem ersten Benutzer steuerbar ist und wobei jene Verkehrsteilnehmer, welche nicht von Benutzern steuerbar sind, automatisiert, insbe sondere durch künstliche Intelligenz oder Logik-basiert, gesteuert werden,
Ausgeben, auf der Grundlage der virtuellen Verkehrssituation, eines virtuellen Umfelds des wenigstens einen ersten Verkehrsteilnehmers an den ersten Benutzer über eine erste, insbesondere wenigstens optische, Benutzerschnittstelle, und
Erfassen von Eingaben des ersten Benutzers zum Steuern des wenigstens einen ers ten Verkehrsteilnehmers in dem virtuellen Umfeld des ersten Verkehrsteilnehmers über eine zweite Benutzerschnittstelle, wobei beim Simulieren der virtuellen Verkehrs situation die erfassten Eingaben des ersten Benutzers und die daraus resultierende Wechselwirkung des wenigstens einen ersten Verkehrsteilnehmers mit seinem virtu ellen Umfeld berücksichtigt werden,
Prüfen der erzeugten Simulationsdaten auf ein Auftreten von Szenarien, welche aus der Wechselwirkung des wenigstens einen ersten Verkehrsteilnehmers mit dem virtu ellen Umfeld entstehen, wobei das Auftreten der Szenarien durch eine vordefinierte Konstellation simulierter Messgrößen, welche vorzugsweise elementaren Manövern entsprechen, charakterisiert sind;
Extrahieren, wenn ein Auftreten eines Szenarios festgestellt wird, von Szenariendaten in Bezug auf das Szenario; und
Aufzeichnen der Szenariendaten zum Testen des Fahrerassistenzsystems.
Vorzugsweise werden die extrahierten Szenariendaten ausgegeben. Vorzugsweise geschieht dies über eine Benutzerschnittstelle oder eine Datenschnittstelle.
Ein Benutzer im Sinne der Erfindung ist eine natürliche Person, d. h. ein Mensch.
Ein Fahrerassistenzsystem im Sinne der Erfindung ist vorzugsweise dazu eingerichtet, einen Fahrer beim Fahren zu unterstützen oder ein Fahrzeug wenigstens teilweise zu führen, insbesondere ein Fahrerassistenzsystem des Automatisierungslevels 3 bis 5, oder weiter insbesondere eine autonome Fahrfunktion. Verkehrsteilnehmer im Sinne der Erfindung ist vorzugsweise jegliches Objekt, welches am Verkehr teilnimmt. Insbesondere ist ein Verkehrsteilnehmer ein Mensch, ein Tier oder ein Fahrzeug.
Extrahieren im Sinne der Erfindung bedeutet vorzugsweise Abgrenzen oder Isolieren.
Insbesondere werden aus den Szenariendaten Szenarien abgegrenzt bzw. isoliert. Hierbei werden vorzugsweise Datenbereiche in den Szenariendaten ausgewählt.
Szenariendaten im Sinne der Erfindung sind vorzugsweise durch Position und Bewe gung der Verkehrsteilnehmer und Position von statischen Objekten in Bezug auf ein Szenario charakterisiert.
Ein Szenario im Sinne der Erfindung wird vorzugsweise aus einer zeitlichen Abfolge von, insbesondere statischen, Szenen gebildet. Die Szenen geben dabei beispiels weise die räumliche Anordnung von dem wenigstens einen anderen Objekt relativ zum Ego-Objekt, z. B. die Konstellation von Verkehrsteilnehmern, an. Ein Szenario berück sichtigt vorzugsweise dynamischen und statischen Inhalt. Vorzugsweise kommt hier bei ein Modell zur systematischen Beschreibung von Szenarien zum Einsatz, weiter vorzugsweise das Modell des PEGASUS-Projekts (https://www.pegasusprojekt.de) mit den folgenden sechs unabhängigen Ebenen: 1. Straße (Geometrie,...); 2. Straßen möbel und Regeln (Verkehrszeichen,...); 3. Vorübergehende Änderungen und Ereig nisse (Straßenbau,...); 4. Bewegende Objekte (verkehrsrelevante Objekte wie: Fahr zeuge, Fußgänger,... die sich relativ zum zu testenden Fahrzeug bewegen); 5. Umge bungsbedingungen (Lichtsituation, Straßenwetter,...); 6. Digitale Informationen (V2X, digitale Daten / Karte,...). Ein Szenario kann insbesondere eine Fahrsituation enthal ten, in der ein Fahrerassistenzsystem das Ego-Fahrzeug genannte, mit dem Fahrer assistenzsystem ausgestattete Fahrzeug zumindest teilweise steuert, z. B. wenigstens eine Fahrzeugfunktion des Ego-Fahrzeugs autonom ausführt.
Eine Verkehrssituation im Sinne der Erfindung beschreibt vorzugsweise die Gesamt heit aller Umstände in einem Verkehr mit Verkehrsteilnehmern in einem definierten räumlichen Bereich und/oder in einem definierten Zeitraum oder Zeitpunkt. Vorzugs weise werden diese Umstände von Verkehrsteilnehmern für die Auswahl geeigneter Verhaltensmuster zu einem bestimmten Zeitpunkt berücksichtigt. Vorzugsweise um fasst eine Verkehrssituation alle relevanten Bedingungen, Möglichkeiten und Determinanten von Handlungen. Eine Verkehrssituation kann, muss aber nicht, aus der Sicht eines Verkehrsteilnehmers oder Objekts repräsentiert werden.
Die simulierten Messgrößen im Sinne der Erfindung sind vorzugsweise aus der folgen den Gruppe ausgewählt: Geschwindigkeit, insbesondere eine initiale Geschwindigkeit, eines Verkehrsteilnehmers; eine Bewegungsrichtung, insbesondere eine Trajektorie, eines Verkehrsteilnehmers; Lichtverhältnisse; Witterung; Fahrbahnbeschaffenheit; Temperatur; Anzahl und Position statischer und/oder dynamischer Objekte; eine Ge schwindigkeit und eine Bewegungsrichtung, insbesondere eine Trajektorie, der dyna mischen Objekte; Zustand von Signalanlagen, insbesondere Lichtsignalanlagen; Ver kehrszeichen; Anzahl der Fahrspuren; Beschleunigung oder Bremsverzögerung von Verkehrsteilnehmern oder Objekten.
Eine vordefinierte Konstellation von Messgrößen im Sinne der Erfindung ist vorzugs weise eine Konstellation von Werten einer oder mehrerer Messgrößen, insbesondere in einem zeitlichen Verlauf.
Labein im Sinne der Erfindung bedeutet vorzugsweise mit einer kategorisierenden Be nennung versehen.
Eine Gefährlichkeit eines Szenarios im Sinne der Erfindung ist vorzugsweise die räum liche oder zeitliche Nähe zu einer Verkehrssituation ohne möglichen unfallfreien Aus gang (aus eigener Kraft und unter Berücksichtigung der genannten Ungewissheiten) bezeichnet. Wenn ein Unfall nicht mehr vermeidbar ist, ist die Gefährlichkeit maximal. Vorzugsweise wird die Gefährlichkeit auch als Kritikalität bezeichnet. Wird das Fahr verhalten oder Fahrkönnen eines Fahrerassistenzsystems berücksichtigt, kann die Gefährlichkeit eine Unfallwahrscheinlichkeit und/oder eine berechnete Dauer bis zu einem Kollisionszeitpunkt charakterisieren. Eine maximale Gefährlichkeit ist vorzugs weise gegeben, wenn die berechnete Dauer 0 Sekunden beträgt und/oder die Unfall wahrscheinlichkeit P = 1 beträgt. Eine erhöhte Unfallwahrscheinlichkeit kann insbe sondere durch ein Fahrmanöver ausgelöst werden, beispielsweise eine ausweichende Reaktion oder starke Gradientenänderungen beim Lenken, Bremsen, Gasgeben (also z.B. ein Fahrzeug weicht durch eine starke Lenkbewegung aus). Eine erhöhte Unfall wahrscheinlichkeit kann insbesondere auch in Bezug auf die anderen Verkehrsteilneh mer (die Logik- oder Kl-basiert geführt werden) und in einer kritischen Fahrsituation ihren Fahrauftrag bzw. ihre eigentliche Trajektorie verlassen müssen (durch ein Ausweichfahrmanöver). Eine erhöhte Unfallwahrscheinlichkeit kann insbesondere auch durch äußere Faktoren entstehen, welche auf den ersten Verkehrsteilnehmer oder die übrigen Verkehrsteilnehmer einwirken, beispielsweise wenn ein Fahrer ge blendet wird. Eine Güte im Sinne der Erfindung charakterisiert vorzugsweise das si mulierte Szenario. Unter einer Güte wird vorzugsweise eine Qualität oder Beschaffen heit und/oder eine Relevanz des simulierten Szenarios in Bezug auf die Gefährlichkeit einer Fahrsituation für ein bestimmtes Fahrerassistenzsystem verstanden.
Unter einer Relevanz im Sinne der Erfindung wird vorzugsweise verstanden, mit wel cher Häufigkeit ein Szenario im Straßenverkehr auftritt. Beispielsweise ist ein Szenario unter Gegenlicht relevanter als ein Szenario, in welchem ein Flugzeug auf der Straße landet. Die Relevanz hängt vorzugsweise auch von der Region ab, für welche der Straßenverkehr relevant ist. Beispielsweise existieren Szenarien, die in Deutschland relevant sind, in China aber nicht.
Ein Umfeld des Fahrzeugs im Sinne der Erfindung wird vorzugsweise wenigstens durch die für die Fahrzeugführung durch das Fahrerassistenzsystem relevanten Ver kehrsteilnehmer und anderen Objekte gebildet. Insbesondere umfasst das Umfeld des Fahrzeugs eine Szenerie und dynamische Elemente. Die Szenerie umfasst vorzugs weise alle stationären Elemente.
Die Erfindung basiert auf dem Ansatz, reale Menschen zum Erzeugen von Szenarien einzusetzen, wobei jedoch keine Testfahrten im realen Verkehr erforderlich sind.
Erfindungsgemäß bewegt wenigstens ein realer Fahrer jeweils ein Fahrzeug nämlich in einem virtuellen Umfeld bzw. einer virtuellen Umgebung. Durch die Erfindung wird das Erzeugen von Szenarien einem Crowdsourcing-Ansatz zugänglich gemacht. Ein oder mehrere Benutzer können nun an einem Simulator einen Verkehrsteilnehmer ih rer Wahl durch virtuelle Verkehrssituationen navigieren. Durch die nahezu unendliche Möglichkeit an Optionen beim Navigieren des oder der Verkehrsteilnehmer sowie wei terer aleatorischer Mechanismen beim Simulieren der virtuellen Verkehrssituation kön nen, wie im realen Straßenverkehr, eine nahezu unendlich große Anzahl an verschie denen Szenarien entstehen. Ein Auftreten von bekannten oder neuen Szenarien wird durch die Erfindung anhand von vordefinierten Kriterien festgestellt. Hierfür wird der Simulationsprozess und insbesondere die mittels diesem erzeugten Simulationsdaten kontinuierlich analysiert bzw. überwacht. In Bezug auf den Crowdsourcing-Ansatz kann hierbei der natürliche Spieltrieb von Menschen ausgenutzt werden. So kann das erfindungsgemäße Verfahren oder sogar ein entsprechendes System Benutzern zur Verfügung gestellt werden. Diese Benutzer können dann „zum Spaß“ in dem simulierten Verkehr herumfahren. Alternativ könnten den Benutzern auch Aufgaben gestellt werden, beispielsweise dass diese möglichst zügig von einem Ort A zu einem Ort B gelangen sollen, unter Einhaltung von Verkehrs regeln, oder dass sie gewisse Objekte einsammeln müssen. Des Weiteren könnte der Benutzer beim Navigieren durch den simulierten Verkehr abgelenkt werden, z. B. in dem er gewisse Spracheingaben oder Ähnliches vornehmen muss.
Die Physik in der Simulation entspricht hierbei der Realität, um möglichst reale Szena riendaten zu erzeugen. Dies gilt insbesondere in Bezug auf die physikalischen Eigen schaften der Verkehrsteilnehmer und jener des Umfelds. Ein Durchfahren von Objek ten oder Ähnliches ist nicht möglich. Besonders bevorzugt navigieren mehrere Benut zer mehrere Verkehrsteilnehmer in dem simulierten Verkehr.
Die auf diese Weise erzeugten Szenariendaten sind in einer vorteilhaften Ausgestal tung des Verfahrens bereits gelabelt, insbesondere Objekte der virtuellen Verkehrssi tuation sind gelabelt. In der Simulation steht Information über Eigenschaften von Ob jekten zur Verfügung, so dass die Information den Objekten zugeordnet werden kann.
Dies ist insbesondere ein Vorteil gegenüber Daten aus einem realen Testbetrieb, bei welchen alle Objekte gelabelt werden müssen. Dieses Labelling ist im Allgemeinen sehr aufwendig, da es nur durch Menschen durchgeführt werden kann.
In einer weiteren vorteilhaften Ausgestaltung des Verfahrens werden die Szenarien daten beim Extrahieren in der Weise beschrieben, dass diese zum Simulieren von Szenarien verwendbar sind, vorzugsweise mittels OpenSCENARIO® oder als OSI- Daten ausgebeben werden. Hierdurch können die Szenariendaten direkt zum Simu lieren von Szenarien weiterverwendet werden.
In einer weiteren vorteilhaften Ausgestaltung des Verfahrens wird der Benutzer durch verschiedene Aktionen in der simulierten virtuellen Verkehrsumgebung zur Aktivität angeregt. Eine solche Aktivität kann beispielsweise das simulierte Verhalten eines an deren Verkehrsteilnehmers sein. Insbesondere können sich diese anderen Verkehrsteilnehmer so verhalten, dass der Benutzer reagieren muss. In einer weiteren vorteilhaften Ausgestaltung weist dieses des Weiteren die folgenden Arbeitsschritte auf:
Ermitteln einer Güte der extrahierten Szenariendaten in Abhängigkeit eines vordefi nierten Kriteriums, wobei die Güte vorzugsweise durch eine Gefährlichkeit eines zu grundeliegenden Szenarios charakterisiert ist. Die Güte gibt die Qualität eines zugrun deliegenden Szenarios an. Vorzugsweise werden die extrahierten Szenariendaten dann ausgegeben, wenn die Güte eine Abbruchbedingung erreicht. Weiter vorzugs weise wird die Güte an den Benutzer über eine erste oder zweite Benutzerschnittstelle, insbesondere ein Display ausgegeben. Eine Abbruchbedingung kann hierbei vorzugs weise eine berechnete Dauer bis zu einem Kollisionszeitpunkt oder eine Kollisions wahrscheinlichkeit sein.
In einer weiteren vorteilhaften Ausgestaltung der Erfindung ist die Güte höher, je ge fährlicher das jeweils entstandene Szenario ist, insbesondere je kürzer eine berech nete Dauer bis zu einem Kollisionszeitpunkt ist.
In einer weiteren vorteilhaften Ausgestaltung des Verfahrens wird dem ersten Benutzer in Abhängigkeit von der Güte eines aufgetretenen Szenarios eine, insbesondere fik tive, Belohnung gutgeschrieben. Hierdurch erhält der Benutzer eine Motivation, kriti sche Szenarien zu erzeugen.
In einer weiteren vorteilhaften Ausgestaltung des Verfahrens kommt zum Simulieren der virtuellen Verkehrssituation ein Verkehrsflussmodell, insbesondere PTV-Vissim® oder Eclipse SUMO, insbesondere Version 1.8.0, zum Einsatz. Durch den Einsatz ei nes Verkehrsflussmodells kann eine besonders realistische Verkehrssituation erzeugt werden.
Die im Vorhergehenden genannten Merkmale und Vorteile in Bezug auf den ersten Aspekt der Erfindung gelten entsprechend auch für die anderen Aspekte der Erfindung und umgekehrt.
Ein zweiter Aspekt der Erfindung betrifft ein computerimplementiertes Verfahren zum Testen eines Fahrerassistenzsystems eines Fahrzeugs, die folgenden Arbeitsschritte aufweisend: Bereitstellen von Szenariendaten, welche ein Szenario charakterisieren, in welchem sich das Fahrzeug befindet und welches eine Mehrzahl an anderen Verkehrsteilneh mern aufweist, wobei die Szenariendaten mittels eines Verfahren zum Erzeugen von Szenariendaten gemäß dem ersten Aspekt der Erfindung erzeugt sind;
Simulieren eines virtuellen Umfelds des Fahrzeugs auf der bereitgestellten Szenarien daten;
Ausgeben des virtuellen Umfelds an das Fahrerassistenzsystem über eine Schnitt stelle; und
Betreiben des Fahrerassistenzsystems in dem virtuellen Umfeld des Fahrzeugs.
In einer vorteilhaften Ausgestaltung des Verfahrens zum Testen eines Fahrerassis tenzsystems wird das Fahrerassistenzsystem simuliert. Dies bedeutet, dass nur die Software bzw. der tatsächliche Code des Fahrerassistenzsystems beim Simulieren der virtuellen Verkehrssituation berücksichtigt wird bzw. implementiert ist, gemäß dem Konzept „Software-in-the-Loop“. Flierdurch kann das Testen eines Fahrerassistenz systems in einer reinen Simulation durchgeführt werden.
In einer weiteren vorteilhaften Ausgestaltung des Verfahrens zum Testen eines Fah rerassistenzsystems werden beim Betreiben des Fahrerassistenzsystems Daten in Bezug auf das Umfeld des Fahrzeugs in das Fahrerassistenzsystem eingespeist und/oder das Fahrerassistenzsystem, insbesondere dessen Sensoren, werden auf der Grundlage des Umfelds des Fahrzeugs stimuliert. Hierdurch kann das Fahrerassis tenzsystem, insbesondere dessen Software oder die gesamte Hardware auf einem Prüfstand getestet werden. Insbesondere kann hierfür ein Hardware-in-the-Loop-Ver- fahren zum Einsatz kommen.
Ein dritter Aspekt der Erfindung betrifft ein System zum Erzeugen von Szenariendaten zum Testen eines Fahrerassistenzsystems eines Fahrzeugs, aufweisend:
Mittel zum Simulieren einer virtuellen Verkehrssituation, welche eine Mehrzahl an vir tuellen Verkehrsteilnehmern aufweist, wobei wenigstens ein erster Verkehrsteilnehmer der Mehrzahl an Verkehrsteilnehmern von einem ersten Benutzer steuerbar ist und wobei jene Verkehrsteilnehmer, welche nicht von Benutzern steuerbar sind, automati siert, insbesondere durch künstliche Intelligenz oder Logik-basiert, gesteuert werden, wobei beim Simulieren Simulationsdaten erzeugt werden; eine erste, insbesondere wenigstens optische, Benutzerschnittstelle zum Ausgeben, auf der Grundlage der virtuellen Verkehrssituation, eines virtuellen Umfelds des we nigstens einen ersten Verkehrsteilnehmers an den ersten Benutzer; und eine zweite Benutzerschnittstelle zum Erfassen von Eingaben des ersten Benutzers zum Steuern des wenigstens einen ersten Verkehrsteilnehmers in einem virtuellen Umfeld des ersten Verkehrsteilnehmers, wobei die Mittel zum Simulieren des Weiteren eingerichtet sind, um die erfassten Eingaben des ersten Benutzers und die daraus resultierende Wechselwirkung des wenigstens einen ersten Verkehrsteilnehmers mit seinem virtuellen Umfeld beim Simulieren der virtuellen Verkehrssituation zu berück sichtigten;
Mittel zum Prüfen der erzeugten Simulationsdaten auf ein Auftreten von Szenarien, welche aus der Wechselwirkung des wenigstens einen ersten Verkehrsteilnehmers mit dem übrigen Umfeld entstehen, wobei das Auftreten der Szenarien durch eine vorde finierte Konstellation simulierter Messgrößen, welche vorzugsweise elementaren Ma növern entsprechen, charakterisiert sind;
Mittel zum Extrahieren, wenn ein Auftreten eines Szenarios durch die Mittel zum Prü fen der erzeugten Simulationsdaten festgestellt wird, von Szenariendaten in Bezug auf das Szenario; und einen Datenspeicher zum Aufzeichnen der Szenariendaten zum Testen des Fahreras sistenzsystems.
Mittel im Sinne der Erfindung können hard- und/oder softwaretechnisch ausgebildet sein und insbesondere eine, vorzugsweise mit einem Speicher- und/oder Bussystem daten- bzw. signalverbundene, insbesondere digitale, Verarbeitungs-, insbesondere Mikroprozessoreinheiten (CPU) und/oder ein oder mehrere Programme oder Pro- grammmodule aufweisen. Die CPU kann dabei dazu ausgebildet sein, Befehle, die als ein in einem Speichersystem abgelegtes Programm implementiert sind, abzuarbeiten, Eingangssignale von einem Datenbus zu erfassen und/oder Ausgangssignale an ei nen Datenbus abzugeben. Ein Speichersystem kann ein oder mehrere, insbesondere verschiedene, Speichermedien, insbesondere optische, magnetische, Festkörper und/oder andere nicht-flüchtige Medien, aufweisen. Das Programm kann derart be schaffen sein, dass es die hier beschriebenen Verfahren verkörpert bzw. auszuführen imstande ist, sodass die CPU die Schritte solcher Verfahren ausführen kann und dann insbesondere Szenarien erzeugen kann.
Ein vierter Aspekt der Erfindung betrifft ein System zum Testen eines Fahrerassistenz systems eines Fahrzeugs, aufweisend: einen Datenspeicher zum Bereitstellen von Szenariendaten, welche ein Szenario cha rakterisieren, in welchem sich das Fahrzeug befindet und welches eine Mehrzahl an anderen Verkehrsteilnehmern aufweist, wobei die Szenariendaten mittels eines Ver fahrens nach einem der Ansprüche 1 bis 8 erzeugt sind;
Mittel zum Simulieren eines virtuellen Umfelds des Fahrzeugs auf der Grundlage der Szenariendaten; und eine Schnittstelle zum Ausgeben des virtuellen Umfelds an das Fahrerassistenzsys tem in der Weise, dass das das Fahrerassistenzsystem in dem virtuellen Umfeld des Fahrzeugs auf der Grundlage des simulierten Szenarios betrieben werden kann.
Weitere Aspekte der Erfindung betreffen ein Computerprogramm, welches Anweisun gen enthält, die, wenn sie von einem Computer ausgeführt werden, diesen dazu ver anlassen ein Verfahren gemäß dem ersten oder zweiten Aspekt der Erfindung auszu führen.
Weitere Merkmale und Vorteile ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen in Bezug auf die Figuren. Es zeigt wenigstens teilweise schematisch:
Figur 1 ein Diagramm einer Auftrittswahrscheinlichkeit von Szenarien in Abhängigkeit ihrer Kritikalität;
Figur 2 ein Blockdiagramm eines Ausführungsbeispiels eines Verfahrens zum Erzeu gen von Szenarien;
Figur 3a ein erstes Beispiel für eine simulierte virtuelle Verkehrssituation;
Figur 3b ein zweites Beispiel für eine simulierte virtuelle Verkehrssituation;
Figur 4 ein Ausführungsbeispiel eines Systems zum Erzeugen von Szenariendaten zum Testen eines Fahrerassistenzsystems eines Fahrzeugs; Figur 5 ein Blockdiagramm eines Ausführungsbeispiels eines Verfahrens zum Testen eines Fahrerassistenzsystems eines Fahrzeugs;
Figur 6 ein Beispiel eines simulierten Szenarios; und
Figur 7 ein Ausführungsbeispiel eines Systems zum Testen eines Fahrerassistenz systems eines Fahrzeugs.
Figur 1 zeigt die Auftrittswahrscheinlichkeit von Szenarien in Abhängigkeit der Kritika- lität von Szenarien. Die Auftrittswahrscheinlichkeit ist jene Wahrscheinlichkeit, in wel cher Szenarien im realen Straßenverkehr Vorkommen.
In Fig. 1 fällt auf, dass die Mehrzahl an Szenarien von vergleichsweise geringer Kom plexität und/oder Kritikalität sind, was auch der allgemeinen Lebenserfahrung eines Autofahrers entspricht. Der Bereich dieser Szenarien ist in Fig. 1 mit „A“ bezeichnet. Szenarien von hoher Komplexität und/oder Kritikalität, deren Bereich in Fig. 1 mit „B“ bezeichnet ist, kommen dagegen vergleichsweise selten vor. Gerade jene Szenarien „B“ mit großer Komplexität und/oder Kritikalität sind jedoch zum Untersuchen der Funk tionstüchtigkeit von Fahrerassistenzsystemen von hoher Relevanz.
Um eine ausreichende Anzahl und Diversität an verschiedenen Szenarien mit hoher Komplexität „B“ während des Tests eines Fahrerassistenzsystems zu erreichen, muss daher, unter Zugrundelegung der gezeigten Verteilungskurve, eine sehr hohe Anzahl an Szenarien durchlaufen werden.
Ein Verfahren zum Erzeugen einer großen Anzahl von verschiedenen Szenarien zum Testen von Fahrerassistenzsystemen wird nachfolgend in Bezug auf die Fig. 2 bis Fig. 3b beschrieben.
In einem ersten Arbeitsschritt 101 werden Simulationsdaten erzeugt. Vorzugsweise weist der erste Arbeitsschritt 101 drei untergeordnete Prozesse auf.
In dem ersten dieser Prozesse 101 -1 wird eine virtuelle Verkehrssituation 3 simuliert, welche eine Mehrzahl an virtuellen Verkehrsteilnehmern 1 , 4, 5a, 5b, 5c, 5d, 6 auf weist. Vorzugsweise ist in dieser virtuellen Verkehrssituation 3 wenigstens ein erster Verkehrsteilnehmer 1 der Mehrzahl an Verkehrsteilnehmern 1 , 4, 5a, 5b, 5c, 5d, 6 von einem ersten Benutzer 2 (vgl. Fig. 4) steuerbar und jene Verkehrsteilnehmer 4, 5a, 5b, 5c, 5d, 6, welche nicht von Benutzern steuerbar sind, werden automatisiert gesteuert. Hierbei kommt vorzugsweise eine künstliche Intelligenz, ein logisches Modell oder ein Verkehrsflussmodell, insbesondere PTV-Vissim® oder Eclipse SUMO, zum Einsatz zum Einsatz. Vorzugsweise kann sich in der simulierten virtuellen Verkehrssituation 3 eine Vielzahl an Verkehrsteilnehmern befinden, welche durch Benutzer, d.h. Men schen, gesteuert werden.
In Bezug auf das Simulieren der virtuellen Verkehrssituation gibt es im Wesentlichen zwei Ansätze: Die Simulation beruht auf Daten, welche in einer realen Testfahrt ge wonnen wurden. In diesem Fall können die Parameter einzelner Objekte, z. B. deren Geschwindigkeit von Verkehrsteilnehmern, verändert werden oder aber so übernom men werden, wie sie während der realen Testfahrt erfasst wurden. In einer alternativen Ausgestaltung des Verfahrens wird die Verkehrssituation 3 rein auf der Grundlage von mathematischen Algorithmen erstellt. Vorzugsweise können beide Ansätze auch ver mischt werden.
Eine solche simulierte Verkehrssituation 3 ist beispielsweise in Fig. 3a gezeigt. Bei der in Fig. 3a gezeigten Verkehrssituation 3 überquert ein Fußgänger 6 eine Straße. Ein Fahrzeug 1 , welches von dem ersten Benutzer gesteuert wird, nähert sich dem Fuß gänger 6 auf dem zum Fußgänger 6 hin liegenden Fahrstreifen. Neben dem Fahrstrei fen sind weitere Fahrzeuge 5b, 5c, 5d geparkt, durch welche der Fußgänger 6 für einen Fahrer des durch den Benutzer gesteuerten Fahrzeugs 1 nicht oder nur schlecht sicht bar ist. Auf dem zweiten Fahrstreifen für den entgegenkommenden Verkehr fährt auf Höhe des Fußgängers 6 ein weiteres Fahrzeug 5a. Hinter dem weiteren Fahrzeug 5a nähert sich ein Motorradfahrer 4, welcher zum Überholen des weiteren Fahrzeugs 5a ansetzt. Ob dieser Motorradfahrer 4 für den Fahrer des von dem ersten Benutzer ge steuerten Fahrzeugs sichtbar ist, lässt sich aus Fig. 3a nicht erschließen.
Die weiteren Fahrzeuge 5a, 5b, 5c, 5d, der Fußgänger 6 sowie der Motorradfahrer 4 bilden ein virtuelles Umfeld des durch den ersten Benutzer 2 gesteuerten Fahrzeugs 1 in der Verkehrssituation 3.
Je nachdem, wie der erste Benutzer 2 im initialen Szenario, welches sich aus der Ver kehrssituation 3 ergibt, reagiert oder agiert, d. h. welches Fahrverhalten der erste Be nutzer in dem virtuellen Umfeld des von ihm gesteuerten Fahrzeugs 1 zeigt, wird sich eine Fahrsituation bzw. ein weiteres Szenario ergeben, welche bzw. welches gefähr lich oder weniger gefährlich ist. Wird der erste Benutzer 2 das Fahrzeug 1 beispielsweise, wie in Figur 3a durch den Balken vor dem Bewegungspfeil des Fahr zeugs 1 angedeutet, durch ein Bremsen zum Stehen bringen, so kann der Motorrad fahrer 4 das auf dem anderen Fahrstreifen 5a entgegenkommende Fahrzeug 5a un gestört überholen.
Figur 3b zeigt dieselbe virtuelle Verkehrssituation 3 wie Fig. 3a, in welchem sich das von dem ersten Benutzer 1 gesteuerte Fahrzeug in demselben initialen Szenario be findet wie in Fig. 3a. Wie durch den Bewegungspfeil, welcher von dem durch den ers ten Benutzer gesteuerten Fahrzeug 1 ausgeht, angedeutet ist, steuert der erste Be nutzer dieses Fahrzeug 1 mit unverminderter Geschwindigkeit weiter.
Flieraus wird sich mit hoher Wahrscheinlichkeit eine nachfolgende Fahrsituation bzw. ein nachfolgendes Szenario entwickeln, in welchem der Motorradfahrer 4 mit dem durch den ersten Benutzer 1 gesteuerten Fahrzeug 1 kollidiert. Auch dies ist in Fig. 3b angedeutet. Eine solche Fahrsituation bzw. ein solches Szenario würde einer sehr ho hen Gefährlichkeit entsprechen.
In einem zweiten Prozess 101 -2 des ersten Arbeitsschritts 101 wird die virtuelle Ver kehrssituation 3 an den ersten Benutzer 2 über eine erste Benutzerschnittstelle 12 ausgegeben.
Mögliche Benutzerschnittstellen sind in Fig. 4 beispielhaft dargestellt und umfassen vorzugsweise optische Benutzerschnittstellen, insbesondere Bildschirme, Audio-Be- nutzerschnittstellen, insbesondere Lautsprecher, und/oder eine Benutzerschnittstelle zur Stimulierung des Gleichgewichtssinns des ersten Benutzers 2.
In einem dritten Prozess 101 -3 des ersten Arbeitsschritts 101 werden Eingaben des ersten Benutzers 2 zum Steuern des wenigstens einen Verkehrsteilnehmers in einem virtuellen Umfeld des ersten Verkehrsteilnehmers 1 über eine zweite Benutzerschnitt stelle 13 erfasst.
Auch die zweiten Benutzerschnittstellen 13 sind in Fig. 4 gezeigt. Vorzugsweise han delt es sich dabei um das Lenkrad, eine Gangschaltung, eine Handbremse, ein Brems pedal, eine Kupplung, und/oder ein Gaspedal sowie weitere etwaige Steuerinstru mente, welche einem Fahrer in einem Fahrzeug zur Verfügung stehen. Je nachdem, welche Art von Verkehrsteilnehmer 1 , 4, 5a, 5b, 5c, 5d, 6 der Benutzer 2 steuert, können jedoch auch andere Eingabemittel als Benutzerschnittstelle 13 vor handen sein, beispielsweise eine Art Joystick.
Wie bereits erläutert, ist der erste Verkehrsteilnehmer 1 in den Fig. 3a und 3b das schwarze Fahrzeug. Beim Simulieren der in den Fig. 3a und 3b gezeigten Verkehrssi tuation 3 werden die erfassten Eingaben des ersten Benutzers 2 und die daraus resul tierende Wechselwirkung des Fahrzeugs 1 , d. h. des ersten Verkehrsteilnehmers, mit seinem virtuellen Umfeld berücksichtigt.
Die Wechselwirkung in den in Fig. 3a und 3b gezeigten Verkehrssituationen 3 ist bei spielsweise, wie der erste Benutzer 2 auf das initiale Szenario reagiert. Je nach Reak tion des ersten Benutzers 2 auf dieses initiale Szenario werden auch die anderen Ver kehrsteilnehmer, insbesondere das weitere entgegenkommende Fahrzeug 5a und der Motorradfahrer 4 sowie der Fußgänger 6, reagieren. Beispielsweise ist damit zu rech nen, dass der Motorradfahrer 4 abbremst, wenn er bemerkt, dass das durch den ersten Benutzer 2 gesteuerte Fahrzeug 1 seine Geschwindigkeit nicht reduziert. Diese Wech selwirkungen haben wiederum einen Einfluss auf die Entwicklung der virtuellen Ver kehrssituation 3.
Der Arbeitsschritt des Erzeugens 101 von Simulationsdaten ist mithin ein kontinuierli cher Prozess, welcher beständig, wie in Fig. 2 angedeutet, in einer Schleife verläuft und dabei Simulationsdaten erzeugt.
Während des Simulierens werden die Objekte, welche Teil der virtuellen Verkehrssi tuation 3 sind, bereits mit Metainformation gekennzeichnet. Ein gesondertes Labein ist daher nicht mehr erforderlich. Dies betrifft sowohl statische als auch dynamische Ob jekte. Flierdurch umfassen spätere Daten, welche aus den Simulationsdaten gewon nen werden können, die sogenannte Ground-Truth-Information.
Werden die Szenariendaten beispielsweise zum Testen eines Fahrerassistenzsys tems eingesetzt, kann nachvollzogen werden, welche Objekte das Fahrerassistenz system zutreffend und welche es unzutreffend erfasst hat. Solche Labels sind bei spielsweise Baum, Fußgänger, Personenkraftwagen, Lastkraftwagen, etc.
Weiter vorzugsweise werden in den Fahrsituationen 3 Aktionen gesetzt, welche den ersten Benutzer zur Aktivität anregen. Beispielsweise könnte dies ein in der Fahrsituation 3 der Fig. 3a und 3b ein Fahrzeug sein, welches dem durch den ersten Benutzer 2 gesteuerten Fahrzeug 1 folgt und dieses zum Beschleunigen drängt. Auch eine überraschende Bewegungstrajektorie des Fußgängers 6, beispielsweise indem dieser anfängt zu rennen, kann eine solche Aktion sein.
In einem zweiten Arbeitsschritt 102 des Verfahrens 100 werden die erzeugten Simu lationsdaten auf ein Auftreten von Szenarien, welche aus der Wechselwirkung des wenigstens einen ersten Verkehrsteilnehmers 1 , in den Fig. 3a und 3b das schwarze Fahrzeug, mit dem virtuellen Umfeld entstehen. Hierbei können sowohl bereits be kannte Szenarien, welche schon früher aufgetreten sind oder als Schablone vordefi niert sind, abgeprüft werden, als auch noch nicht vordefinierte Szenarien.
Beide Arten von Szenarien sind vorzugsweise durch vordefinierte Konstellationen si mulierter Messgrößen, welche aus der virtuellen Verkehrssituation 3 bestimmt werden können, definiert. Diese vordefinierten Konstellationen bilden entweder die Schablo nen für Szenarien, oder entsprechen elementaren Manövern, von welchen auf das Auftreten eines Szenarios geschlossen werden kann. Dies könnte beispielsweise eine starke Bremsverzögerung des Fahrzeugs 1 in den Fig. 3a und 3b sein, welche als Triggerbedingung für das Auftreten eines noch nicht vordefinierten Szenarios einge setzt wird.
Wird ein Auftreten eines Szenarios festgestellt, so werden Szenariendaten in Bezug auf das Szenario in einem dritten Arbeitsschritt 103 extrahiert. Extrahieren bedeutet in diesem Zusammenhang insbesondere ein Abgrenzen oder Isolieren eines Datenbe reichs in den Simulationsdaten, welche im Zusammenhang mit dem festgestellten Sze nario stehen. Vorzugsweise werden die Szenariendaten beim Extrahieren in der Weise beschrieben, dass diese sich zum Simulieren von Szenarien eignen. Vorzugsweise sind diese mittels OpenSCENARIO® oder OpenDrive® verwendbar. Weiter vorzugs weise werden diese als OSI-Daten bzw. OSI-Stream ausgegeben.
In einem vierten Arbeitsschritt 104 des Verfahrens 100 werden die Szenariendaten zum Testen des Fahrerassistenzsystems aufgezeichnet. Danach stehen diese Daten zum Testen eines Fahrerassistenzsystems bereit. Ein solches Testverfahren 200 wird weiter unten in Bezug auf Figur 5 beschrieben. In einem fünften Arbeitsschritt 105 wird vorzugsweise eine Güte des entstandenen Szenarios in Abhängigkeit eines vordefinierten Kriteriums ermittelt, wobei die Güte vor zugsweise durch eine Gefährlichkeit eines des Szenarios charakterisiert ist. Vorzugs weise ist die Güte umso höher, je gefährlicher das entstandene Szenario ist. Eine Ge fährlichkeit wird vorzugsweise durch sogenannte Time-to-X-Metriken bestimmt, wie sie beispielsweise in der Veröffentlichung „Metrik zur Bewertung der Kritikalität von Ver kehrssituationen und -Szenarien“; P. Junietz et al., 11 . Workshop Fahrerassistenzsys teme und automatisiertes Fahren“, FAS 2017 beschrieben werden. Insbesondere kön nen hierbei als Kriterien zum Einsatz kommen: Dauer bis zu einem Kollisionszeitpunkt (Time-to-Collision), Time-to-Kickdown, Time-to-Steer, Time-to-React, Distance-of-Clo- sest-Encounter, Time-to-Closest-Encounter, Worst-Time-to-Collision. Weiter vorzugs weise wird die Gefährlichkeit durch eine Unfallwahrscheinlichkeit charakterisiert.
Weiter vorzugsweise wird dem ersten Benutzer 2 in Abhängigkeit von der Güte des aufgetretenen Szenarios eine, insbesondere fiktive, Belohnung gutgeschrieben.
In Fig. 4 ist ein System 10 zum Erzeugen von Szenarien zum Testen eines Fahreras sistenzsystems eines Fahrzeugs dargestellt.
Dieses System 10 weist vorzugsweise Mittel 11 zum Simulieren einer virtuellen Ver kehrssituation 3, welche eine Mehrzahl an virtuellen Verkehrsteilnehmern aufweist, auf. Um Verkehrsteilnehmer 1 durch einen ersten Benutzer 2 steuerbar zu machen, weist das System des Weiteren wenigstens eine erste Benutzerschnittstelle 12 und wenigstens eine zweite Benutzerschnittstelle 13 auf.
Die wenigstens eine erste Benutzerschnittstelle 12 dient zum Ausgeben eines virtuel len Umfelds wenigstens einen ersten Verkehrsteilnehmer 1 an den ersten Benutzer 2. Das virtuelle Umfeld des wenigstens einen ersten Verkehrsteilnehmers 1 ist hierbei auf der Grundlage der simulierten virtuellen Verkehrssituation 3 ermittelt. Im Wesent lichen handelt es sich dabei um eine Darstellung der virtuellen Verkehrssituation 3 in dem initialen Szenario aus der Sicht des ersten Verkehrsteilnehmers 1 , welche der erste Benutzer 2 steuert.
Wie in Fig. 4 dargestellt, handelt es sich bei diesen Benutzerschnittstellen 12 um opti sche Benutzerschnittstellen wie Bildschirme und Audio-Schnittstellen wie Lautsprecher und gegebenenfalls Vorrichtungen, mit welchen der Gleichgewichtssinn des jeweiligen Benutzers 2 beeinflusst werden kann.
Die zweite Benutzerschnittstelle bzw. Benutzerschnittstellen 13 sind eingerichtet, um Eingaben des jeweiligen Benutzers 2 zu erfassen. Hierbei handelt es sich, wie in Fig. 4 gezeigt, vorzugsweise um verschiedene Bedienelemente. Diese können, wie bereits oben erläutert, in Abhängigkeit des jeweiligen von dem Benutzer 2 gesteuerten Ver kehrsteilnehmers 1 abhängig sein. Ist der durch den ersten Benutzer 2 gesteuerte Ver kehrsteilnehmer 1 ein Fahrzeug, so sind die Benutzerschnittstellen 12, 13 vorzugs weise im Bereich einer sogenannten Sitzkiste 19 angeordnet, welche zusammen mit den Benutzerschnittstellen 12, 13 ein Simulator bildet, wie in Fig. 4 dargestellt.
Des Weiteren weist das System 10 vorzugsweise Mittel 14 zum Prüfen der erzeugten Simulationsdaten auf ein Auftreten von Szenarien auf. Weiterhin weist das System 10 vorzugsweise Mittel 15 zum Extrahieren von Szenariendaten in Bezug auf das Szena rio und einen Datenspeicher 16 zum Aufzeichnen der Szenariendaten auf. Weiter vor zugsweise weist das System 10 vorzugsweise Mittel zum Ermitteln einer Güte der extrahierten Szenariendaten in Abhängigkeit eines vordefinierten Kriteriums auf. Wei ter vorzugsweise weist das System 10 eine weitere Schnittstelle 18 auf, welche vor zugsweise als Benutzerschnittstelle eingerichtet ist, um die Güte an den Benutzer 2 auszugeben und/oder als Datenschnittstelle eingerichtet ist, um die Szenariendaten zur weiteren Verarbeitung auszugeben. Vorzugsweise sind die Mittel 11 , 14, 15, 16, 17, 18 Teil einer Datenverarbeitungseinrichtung, welche vorzugsweise durch einen Computer gebildet wird.
Figur 5 zeigt ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens 200 zum Testen eines Fahrerassistenzsystems 7 eines Fahrzeugs 8, wie in Fig. 6 darge stellt.
Bei diesem Verfahren 200 werden Szenariendaten, welche ein Szenario charakterisie ren, in welchem sich das Fahrzeug 8) befindet und welches vorzugsweise eine Mehr zahl an anderen Verkehrsteilnehmern 4‘, 5a‘, 5b‘, 5c‘, 5d‘, 6‘ aufweist, in einem ersten Arbeitsschritt 201 simuliert. Auch diese Szenariendaten beruhen vorzugsweise wiede rum auf Simulationen, aus welchen diese gemäß dem weiter oben beschriebenen Ver fahren 100 extrahiert wurden. Ein Szenario wird in einem zweiten Arbeitsschritt 202 auf der Grundlage der Szenari endaten simuliert. In diesem Szenario befindet sich das Fahrzeug 8 mit dem zu tes tenden Fahrerassistenzsystem 7. Darüber hinaus weist das Szenario vorzugsweise eine Mehrzahl an anderen Verkehrsteilnehmern oder Objekten auf.
In dem in Fig. 6 dargestellten Beispiel eines Szenarios sind dies parkende Fahrzeuge 5b', 5c', 5d', ein Fußgänger 6', ein entgegenkommendes Fahrzeug 5a' auf dem ande ren Fahrstreifen sowie ein ebenfalls auf diesem Fahrstreifen befindliches Motorrad 5' in Analogie zu den in den Fig. 3a, 3b gezeigten Fahrsituationen 3.
Auf der Grundlage des simulierten Szenarios wird in einem dritten Arbeitsschritt 203 ein virtuelles Umfeld des Fahrzeugs 8 mit dem Fahrerassistenzsystem 7 erzeugt und ausgegeben.
Das virtuelle Umfeld wird in einem dritten Arbeitsschritt 203 an das Fahrerassistenz system 7 über eine Schnittstelle 23 ausgegeben. Schließlich wird das Fahrerassistenz system 7 in dem virtuellen Umfeld des Fahrzeugs 8 in einem vierten Arbeitsschritt 204 betrieben.
Das Fahrverhalten des Fahrerassistenzsystems 7 in dem Szenario bzw. Umfeld kann im Weiteren analysiert und bewertet werden. Auf der Grundlage einer solchen Analyse oder Bewertung kann das Fahrerassistenzsystem 7 optimiert werden.
In dem in Fig. 6 gezeigten Szenario weist das Fahrerassistenzsystem 7 eines Fahr zeugs 8 ein Radarsystem auf, welches die in dem Umfeld des Fahrzeugs 8 angeord neten Objekte, insbesondere die Verkehrsteilnehmer 4', 5a', 5b', 5c', 5d', 6' erfasst.
Beim dargestellten Beispielszenario ist das Fahrerassistenzsystem 7 in den Personen kraftwagen 8 integriert. Ebenso könnte das zu testende Fahrerassistenzsystem aber auch in das Motorrad 4‘ integriert sein. Beispielsweise könnte der Motorradfahrer durch Sensorik des Fahrerassistenzsystems bereits frühzeitig gewarnt werden und daher nicht ausscheren. Damit reagiert das Fahrerassistenzsystem des Motorrads 4‘ und das schwarze Auto kann weiterfahren, ohne, dass es zu einer Kollision kommt. Ein System 20 zum Testen eines Fahrerassistenzsystems 7, welches geeignet ist, um das in Be zug auf die Fig. 5 und 6 beschriebene Verfahren 200 auszuführen, ist in Fig. 7 darge stellt. Ein solches System 20 weist einen Datenspeicher 21 zum Bereitstellen von Szenari endaten auf, welche ein Szenario charakterisieren, in welchem sich das Fahrzeug 8 befindet. Mittel 22 sind eingerichtet, um ein virtuelles Umfeld des Fahrzeugs auf der Grundlage der Szenariendaten zu simulieren. Des Weiteren sind die Mittel 22 einge richtet, um dieses Umfeld auch zu rendern.
Eine Schnittstelle 23 ist schließlich eingerichtet, um das virtuelle Umfeld eines Fahrer assistenzsystems 7 auszugeben. Eine solche Schnittstelle kann, wenn das Fahreras sistenzsystem 7 eine optische Kamera aufweist, ein Bildschirm sein. In dem in Fig. 7 dargestellten Beispiel ist der Sensor des Fahrerassistenzsystems ein Radarsensor, welcher ein Signal S aussendet. Dieses Signal S wird von Radarantennen 23 erfasst.
Die Mittel 22 zum Simulieren berechnen auf der Grundlage des erfassten Signals und des simulierten Umfelds ein Antwortsignal S', welches wiederum an das Radar des Fahrerassistenzsystems ausgegeben wird. Auf diese Weise kann die Funktion des Fahrerassistenzsystems 7 getestet werden. Je nachdem, welche Komponenten eines Fahrerassistenzsystems 7 getestet werden sollen, kann das simulierte virtuelle Um feld, wie in Fig. 7 gezeigt, durch Emulation von Signalen an den Sensor des Fahreras sistenzsystems 7 getestet werden. Alternativ kann aber auch ein Signal erzeugt wer den, welches direkt in die Datenverarbeitungseinheit 7 des Fahrerassistenzsystems eingespeist wird oder auch ein Signal S', welches lediglich durch die Software des Fahrerassistenzsystems 7 verarbeitet wird.
Vorzugsweise sind der Datenspeicher 21 und die Mittel zum Simulieren 22 Teil einer Datenverarbeitungseinrichtung.
Es wird darauf hingewiesen, dass es sich bei den Ausführungsbeispielen lediglich um Beispiele handelt, die den Schutzbereich, die Anwendung und den Aufbau in keiner Weise einschränken sollen. Vielmehr wird dem Fachmann durch die vorausgehende Beschreibung ein Leitfaden für die Umsetzung mindestens eines Ausführungsbei spiels gegeben, wobei diverse Änderungen, insbesondere im Hinblick auf die Funktion und Anordnung der beschriebenen Bestandteile, vorgenommen werden können, ohne den Schutzbereich zu verlassen, wie er sich aus den Ansprüchen und diesen äquiva lenten Merkmalskombinationen ergibt.

Claims

Patentansprüche
1. Computerimplementiertes Verfahren (100) zum Erzeugen von Szenariendaten zum Testen eines Fahrerassistenzsystems (7) eines Fahrzeugs (8), folgende Ar beitsschritte aufweisend:
Erzeugen (101) von Simulationsdaten durch
Simulieren (101-1) einer virtuellen Verkehrssituation (3), welche eine Mehrzahl an virtuellen Verkehrsteilnehmern (1 , 4, 5a, 5b, 5c, 5d, 6) auf weist, wobei wenigstens ein erster Verkehrsteilnehmer (1) der Mehrzahl an Verkehrsteilnehmern (1 , 4, 5a, 5b, 5c, 5d, 6) von einem ersten Benut zer (2) steuerbar ist und wobei jene Verkehrsteilnehmer (4, 5a, 5b, 5c, 5d, 6), welche nicht von Benutzern steuerbar sind, automatisiert, insbe sondere durch künstliche Intelligenz oder Logik-basiert, gesteuert wer den,
Ausgeben (101 -2), auf der Grundlage der virtuellen Verkehrssituation (3), eines virtuellen Umfelds des wenigstens einen ersten Verkehrsteilneh mers (1) an den ersten Benutzer (2) über eine erste, insbesondere we nigstens optische, Benutzerschnittstelle (12), und
Erfassen (101-3) von Eingaben des ersten Benutzers (2) zum Steuern des wenigstens einen ersten Verkehrsteilnehmers (1) in dem virtuellen Umfeld des ersten Verkehrsteilnehmers (1) über eine zweite Benutzer schnittstelle (13), wobei beim Simulieren der virtuellen Verkehrssituation (3) die erfassten Eingaben des ersten Benutzers (2) und die daraus re sultierende Wechselwirkung des wenigstens einen ersten Verkehrsteil nehmers (1) mit seinem virtuellen Umfeld berücksichtigt werden;
Prüfen (102) der erzeugten Simulationsdaten auf ein Auftreten von Szenarien, welche aus der Wechselwirkung des wenigstens einen ersten Verkehrsteilneh mers (1 ) mit dem virtuellen Umfeld entstehen, wobei das Auftreten der Szenarien durch eine vordefinierte Konstellation simulierter Messgrößen, welche vorzugs weise elementaren Manövern entsprechen, charakterisiert sind;
Extrahieren (103), wenn ein Auftreten eines Szenarios festgestellt wird, von Sze nariendaten in Bezug auf das Szenario; und
Aufzeichnen (104) der Szenariendaten zum Testen des Fahrerassistenzsystems (7).
2. Verfahren (100) nach Anspruch 1 , wobei Objekte der virtuellen Verkehrssituation (3) gelabelt sind.
3. Verfahren (100) nach Anspruch 1 oder 2, wobei die Szenariendaten beim Extra hieren in der Weise beschrieben werden, dass diese zum Simulieren von Szena rien verwendbar sind, vorzugsweise mittels OpenSCENARIO®, oder als OSI- Daten ausgegeben werden.
4. Verfahren (100) nach Anspruch 1 oder 2, wobei der erste Benutzer (2) durch eine Aktion oder Aktionen in der simulierten virtuellen Verkehrsumgebung zu Aktivität angeregt wird.
5. Verfahren (100) nach einem der vorangehenden Ansprüche 1 bis 4, des Weiteren die folgenden Arbeitsschritte aufweisend:
Ermitteln (105) einer Güte der extrahierten Szenariendaten in Abhängigkeit eines vordefinierten Kriteriums, wobei die Güte vorzugsweise durch eine Gefährlichkeit eines zugrundeliegenden Szenarios charakterisiert ist.
6. Verfahren (100) nach Anspruch 5, wobei die Güte höher ist, je gefährlicher das jeweils entstandene Szenario ist, insbesondere je kürzer eine berechnete Dauer bis zu einem Kollisionszeitpunkt ist.
7. Verfahren (100) nach einem der vorangehenden Ansprüche 1 bis 6, wobei dem ersten Benutzer (2), insbesondere in Abhängigkeit von der Güte eines aufgetre tenen Szenarios, eine, insbesondere fiktive, Belohnung gutgeschrieben wird.
8. Verfahren (100) nach einem der vorangehenden Ansprüche 1 bis 7, wobei zum Simulieren der virtuellen Verkehrssituation (3) ein Verkehrsflussmodell, insbe sondere PTV Vissim®, zum Einsatz kommt.
9. Computerimplementiertes Verfahren (200) zum Testen eines Fahrerassistenz systems (7) eines ersten Fahrzeugs (8), die folgenden Arbeitsschritte aufwei send:
Bereitstellen (201) von Szenariendaten, welche ein Szenario charakterisieren, in welchem sich das ersten Fahrzeug (8) befindet und welches eine Mehrzahl an anderen Verkehrsteilnehmern (4‘, 5a‘, 5b‘, 5c‘, 5d‘, 6‘) aufweist, wobei die Sze nariendaten mittels eines Verfahrens (100) nach einem der Ansprüche 1 bis 8 erzeugt sind;
Simulieren (202) eines virtuellen Umfelds des ersten Fahrzeugs (8) auf der be reitgestellten Szenariendaten;
Ausgeben (203) des virtuellen Umfelds an das Fahrerassistenzsystem (7) über eine Schnittstelle (23); und
Betreiben (204) des Fahrerassistenzsystems (7) in dem virtuellen Umfeld des ersten Fahrzeugs (8).
10. Verfahren nach Anspruch 9, wobei das Fahrerassistenzsystem (7) simuliert wird.
11. Verfahren nach Anspruch 10, wobei beim Betreiben des Fahrerassistenzsystems (7) Daten in Bezug auf das Umfeld des ersten Fahrzeugs (8) in das Fahrerassis tenzsystem (7) eingespeist werden und/oder das Fahrerassistenzsystem (7), ins besondere dessen Sensoren, auf der Grundlage des Umfelds des ersten Fahr zeugs (8) stimuliert werden.
12. Computerprogramm, das Anweisungen umfasst, welche, wenn sie von einem Computer ausgeführt werden, diesen dazu veranlassen, die Schritte eines Ver fahrens gemäß einem der Ansprüche 1 bis 11 auszuführen.
13. Computer-lesbares Medium, auf dem ein Computerprogramm nach Anspruch 12 gespeichert ist.
14. System (10) zum Erzeugen von Szenariendaten zum Testen eines Fahrerassis tenzsystems eines Fahrzeugs, aufweisend:
Mittel (11) zum Simulieren einer virtuellen Verkehrssituation (3), welche eine Mehrzahl an virtuellen Verkehrsteilnehmern aufweist, wobei wenigstens ein ers ter Verkehrsteilnehmer (1) der Mehrzahl an Verkehrsteilnehmern (1 , 4, 5a, 5b, 5c, 5d, 6) von einem ersten Benutzer (2) steuerbar ist und wobei jene Verkehrs teilnehmer (4, 5a, 5b, 5c, 5d, 6), welche nicht von Benutzern steuerbar sind, au tomatisiert, insbesondere durch künstliche Intelligenz oder Logik-basiert, gesteu ert werden, wobei beim Simulieren Simulationsdaten erzeugt werden; eine erste, insbesondere wenigstens optische, Benutzerschnittstelle (12) zum Ausgeben, auf der Grundlage der virtuellen Verkehrssituation (3), eines virtuellen Umfelds des wenigstens einen ersten Verkehrsteilnehmers (1 ) an den ersten Be nutzer (2); und eine zweite Benutzerschnittstelle (13) zum Erfassen von Eingaben des ersten Benutzers (2) zum Steuern des wenigstens einen ersten Verkehrsteilnehmers (1) in einem virtuellen Umfeld des ersten Verkehrsteilnehmers (1), wobei die Mittel (11) zum Simulieren des Weiteren eingerichtet sind, um die erfassten Eingaben des ersten Benutzers (2) und die daraus resultierende Wechselwirkung des we nigstens einen ersten Verkehrsteilnehmers (1 ) mit seinem virtuellen Umfeld beim Simulieren der virtuellen Verkehrssituation (3) zu berücksichtigten;
Mittel (14) zum Prüfen der erzeugten Simulationsdaten auf ein Auftreten von Sze narien, welche aus der Wechselwirkung des wenigstens einen ersten Verkehrs teilnehmers (1) mit dem übrigen Umfeld entstehen, wobei das Auftreten der Szenarien durch eine vordefinierte Konstellation simulierter Messgrößen, welche vorzugsweise elementaren Manövern entsprechen, charakterisiert sind;
Mittel (15) zum Extrahieren, wenn ein Auftreten eines Szenarios durch die Mittel (14) zum Prüfen der erzeugten Simulationsdaten festgestellt wird, von Szenari endaten in Bezug auf das Szenario; und einen Datenspeicher (16) zum Aufzeichnen der Szenariendaten zum Testen des Fahrerassistenzsystems.
15. System (20) zum Testen eines Fahrerassistenzsystems (7) eines ersten Fahr zeugs (8), die aufweisend: einen Datenspeicher (21 ) zum Bereitstellen von Szenariendaten, welche ein Sze nario charakterisieren, in welchem sich das erste Fahrzeug (8) befindet und wel ches eine Mehrzahl an anderen Verkehrsteilnehmern (4‘, 5a‘, 5b‘, 5c‘, 5d‘, 6‘) aufweist, wobei die Szenariendaten mittels eines Systems (10) nach einem der Ansprüche 1 bis 8 erzeugt sind;
Mittel (22) zum Simulieren eines virtuellen Umfelds des ersten Fahrzeugs (8) auf der Grundlage der Szenariendaten; und eine Schnittstelle (23) zum Ausgeben des virtuellen Umfelds an das Fahrerassis tenzsystem (7) in der Weise, dass das das Fahrerassistenzsystem (7) in dem virtuellen Umfeld des ersten Fahrzeugs (8) auf der Grundlage des simulierten Szenarios betrieben werden kann.
PCT/AT2022/060055 2021-03-01 2022-02-28 Verfahren und system zum erzeugen von szenariendaten zum testen eines fahrerassistenzsystems eines fahrzeugs WO2022183227A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP22715966.2A EP4302197A1 (de) 2021-03-01 2022-02-28 Verfahren und system zum erzeugen von szenariendaten zum testen eines fahrerassistenzsystems eines fahrzeugs
KR1020237032926A KR20230148366A (ko) 2021-03-01 2022-02-28 차량의 운전자 보조 시스템의 시험을 위한 시나리오 데이터를 생성하기 위한 방법 및 시스템
CN202280031472.6A CN117222988A (zh) 2021-03-01 2022-02-28 用于产生用于测试车辆的驾驶员辅助系统的场景数据的方法和系统
JP2023552229A JP2024507997A (ja) 2021-03-01 2022-02-28 乗物の運転者支援システムを試験するためのシナリオデータを生成する方法およびシステム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ATA50138/2021A AT524821A1 (de) 2021-03-01 2021-03-01 Verfahren und System zum Erzeugen von Szenariendaten zum Testen eines Fahrerassistenzsystems eines Fahrzeugs
ATA50138/2021 2021-03-01

Publications (1)

Publication Number Publication Date
WO2022183227A1 true WO2022183227A1 (de) 2022-09-09

Family

ID=81307071

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AT2022/060055 WO2022183227A1 (de) 2021-03-01 2022-02-28 Verfahren und system zum erzeugen von szenariendaten zum testen eines fahrerassistenzsystems eines fahrzeugs

Country Status (6)

Country Link
EP (1) EP4302197A1 (de)
JP (1) JP2024507997A (de)
KR (1) KR20230148366A (de)
CN (1) CN117222988A (de)
AT (1) AT524821A1 (de)
WO (1) WO2022183227A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116465647A (zh) * 2023-04-18 2023-07-21 日照朝力信息科技有限公司 一种基于虚拟现实技术的汽车性能测试方法及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170270236A1 (en) * 2016-03-18 2017-09-21 Toyota Jidosha Kabushiki Kaisha Vehicle simulation device for crowd-sourced vehicle simulation data
EP3745382A1 (de) * 2019-05-27 2020-12-02 Zenuity Ab Verfahren und server zur unterstützung der erzeugung von szenarien zum testen von autonomem fahr- und/oder erweiterten fahrerassistenzsystemfunktionen

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160210382A1 (en) * 2015-01-21 2016-07-21 Ford Global Technologies, Llc Autonomous driving refined in virtual environments
DE102017213217A1 (de) * 2017-08-01 2019-02-07 Ford Global Technologies, Llc Testfahrtszenario-Datenbanksystem für realitätsnahe virtuelle Testfahrtszenarien
DE102018200011A1 (de) * 2018-01-02 2019-07-04 Ford Global Technologies, Llc Testsystem und Verfahren zum Testen einer Steuerung eines zumindest teilweise autonom fahrenden Fahrzeugs in einer virtuellen Umgebung
DE102019105340A1 (de) * 2019-02-09 2020-08-13 Elmos Semiconductor Aktiengesellschaft Verfahren für ein Ultraschallmesssystem im Fahrzeug zur Erkennung und Klassifizierung von Objekten im Umfeld des Fahrzeugs mit Hilfe eines Deep-Learning Verfahrens
DE102019206049A1 (de) * 2019-04-26 2020-10-29 Robert Bosch Gmbh Erkennung und Behebung von Rauschen in Labels von Lern-Daten für trainierbare Module

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170270236A1 (en) * 2016-03-18 2017-09-21 Toyota Jidosha Kabushiki Kaisha Vehicle simulation device for crowd-sourced vehicle simulation data
EP3745382A1 (de) * 2019-05-27 2020-12-02 Zenuity Ab Verfahren und server zur unterstützung der erzeugung von szenarien zum testen von autonomem fahr- und/oder erweiterten fahrerassistenzsystemfunktionen

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "ASAM OpenSCENARIO: User Guide", 16 March 2020 (2020-03-16), XP055920173, Retrieved from the Internet <URL:https://releases.asam.net/OpenSCENARIO/1.0.0/ASAM_OpenSCENARIO_BS-1-2_User-Guide_V1-0-0.html#_catalogs> [retrieved on 20220511] *
MSC SOFTWARE: "Virtual Test Drive (VTD): Webinar-Leverage Simulation to Achieve Safety for Autonomous Vehicles", 10 June 2019 (2019-06-10), XP055920212, Retrieved from the Internet <URL:https://www.youtube.com/watch?v=NksyrGA8Cek> [retrieved on 20220615] *
P. JUNIETZ ET AL.: "11. Workshop Fahrerassistenzsysteme und automatisiertes Fahren", 2017, FAS, article "Metrik zur Bewertung der Kritikalität von Verkehrssituationen und -szenarien"
VERNAZA ARIEL ET AL: "Simul-A2: Agent-based simulator for evaluate ADA systems", 17TH INTERNATIONAL CONFERENCE ON INFORMATION FUSION (FUSION), INTERNATIONAL SOCIETY OF INFORMATION FUSION, 7 July 2014 (2014-07-07), pages 1 - 7, XP032653912 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116465647A (zh) * 2023-04-18 2023-07-21 日照朝力信息科技有限公司 一种基于虚拟现实技术的汽车性能测试方法及系统
CN116465647B (zh) * 2023-04-18 2024-03-26 日照朝力信息科技有限公司 一种基于虚拟现实技术的汽车性能测试方法及系统

Also Published As

Publication number Publication date
KR20230148366A (ko) 2023-10-24
CN117222988A (zh) 2023-12-12
EP4302197A1 (de) 2024-01-10
JP2024507997A (ja) 2024-02-21
AT524821A1 (de) 2022-09-15

Similar Documents

Publication Publication Date Title
DE102006044086B4 (de) System und Verfahren zur Simulation von Verkehrssituationen, insbesondere unfallkritischen Gefahrensituationen, sowie ein Fahrsimulator
DE102017112634B4 (de) Kraftfahrzeug mit Fahrmodus und Simulationsmodus
EP3438901A1 (de) Testfahrtszenario-datenbanksystem für realitätsnahe virtuelle testfahrtszenarien
DE102007053501A1 (de) Verfahren zur Entwicklung und/oder zum Testen wenigstens eines Sicherheits- und/oder Fahrerassistenzsystems für ein Kraftfahrzeug und Simulationsumgebung
DE102018200011A1 (de) Testsystem und Verfahren zum Testen einer Steuerung eines zumindest teilweise autonom fahrenden Fahrzeugs in einer virtuellen Umgebung
AT521832B1 (de) Testterminal zur Unterstützung einer ausführenden Person
DE102019203712B4 (de) Verfahren zum Trainieren wenigstens eines Algorithmus für ein Steuergerät eines Kraftfahrzeugs, Computerprogrammprodukt, Kraftfahrzeug sowie System
EP4302196A1 (de) Verfahren zum testen eines fahrerassistenzsystems eines fahrzeugs
DE112017007596T5 (de) Strategieerzeugungsvorrichtung und Fahrzeug
AT523834B1 (de) Verfahren und System zum Testen eines Fahrerassistenzsystems
DE10309934A1 (de) Fahrsimulator und Verfahren zum Simulieren des Fahrzeugstands eines Fahrzeuges
WO2022183227A1 (de) Verfahren und system zum erzeugen von szenariendaten zum testen eines fahrerassistenzsystems eines fahrzeugs
DE10114433A1 (de) Simulationssystem und -verfahren für ein Fahrzeug
WO2022251890A1 (de) Verfahren und system zum testen eines fahrerassistenzsystems für ein fahrzeug
DE102019004076A1 (de) Verfahren zum Unterstützen eines Fahrers eines Fahrzeuges
EP4226248A1 (de) Verfahren und ein system zum testen eines fahrerassistenzsystems für ein fahrzeug
EP4105811A1 (de) Computerimplementiertes verfahren zum szenariobasierten testen und/oder homologation von zu testenden zumindest teilweise autonomen fahrfunktionen durch key performance indicators (kpi)
DE102020130748A1 (de) Verfahren, System sowie ein Computerprogramm zum Erzeugen einer virtuellen Umgebung eines Fahrzeugs
AT525369B1 (de) Testumfeld für urbane Mensch-Maschine Interaktion
EP3622451A1 (de) Produktreifebestimmung eines technischen systems und insbesondere eines autonom fahrenden fahrzeugs
AT526259A1 (de) Verfahren zum Trainieren eines künstlichen neuronalen Netzes eines Fahrermodells
DE102022114913A1 (de) Computerimplementiertes Verfahren zur Verwendung von gespeicherten Spezifikationsanteilen
WO2023193996A1 (de) Test einer automatischen fahrsteuerfunktion mittels semi-realer verkehrsdaten
WO2023275401A1 (de) Simulation von verkehrsteilnehmern mit emotionen
EP4086773A1 (de) Computerimplementiertes verfahren zum automatischen bereitstellen eines hinweises für testprozesse

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22715966

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023552229

Country of ref document: JP

ENP Entry into the national phase

Ref document number: 20237032926

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2022715966

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022715966

Country of ref document: EP

Effective date: 20231002