WO2019201400A1 - Steuergerätetesteinrichtung zum testen, absichern und entwickeln von funktionen - Google Patents

Steuergerätetesteinrichtung zum testen, absichern und entwickeln von funktionen Download PDF

Info

Publication number
WO2019201400A1
WO2019201400A1 PCT/DE2019/200025 DE2019200025W WO2019201400A1 WO 2019201400 A1 WO2019201400 A1 WO 2019201400A1 DE 2019200025 W DE2019200025 W DE 2019200025W WO 2019201400 A1 WO2019201400 A1 WO 2019201400A1
Authority
WO
WIPO (PCT)
Prior art keywords
output data
sensor output
database
scenario
sensor
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/DE2019/200025
Other languages
English (en)
French (fr)
Inventor
Thomas Breitenberger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Aumovio Microelectronic GmbH
Original Assignee
Conti Temic Microelectronic 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 Conti Temic Microelectronic GmbH filed Critical Conti Temic Microelectronic GmbH
Priority to DE112019000361.5T priority Critical patent/DE112019000361A5/de
Publication of WO2019201400A1 publication Critical patent/WO2019201400A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures

Definitions

  • ECU testing device for testing, securing and
  • the invention relates to a control unit test device, a vehicle, which sensor output data from a
  • ECU test device receives, a method for testing and developing functions, a program element and a computer-readable medium.
  • ADAS Advanced Driver Assistance System
  • HIL test benches can apply test data to the functions to be tested, developed or to be protected, which were generated, for example, by sensors on test drives.
  • Functions or control programs can be tested on the HIL test bench without having to carry out a real test drive. In other words, test drives are simulated there.
  • certain situations such as the behavior after a Accident, not or only very difficult to be represented by real test data.
  • test data for the development, testing and protection of driver assistance systems (including sensors and ECUs) or functions and to stimulate these functions through the test data.
  • a first aspect of the invention relates to a
  • This ECU test device for testing, securing and / or developing a function or a control program of a driver assistance system or an autonomous vehicle.
  • This ECU testing device has a database in which sensor output data of sensors of the vehicle are each assigned to a specific environment scenario, and a
  • the arithmetic unit is set up to use those sensor output data of the database, which are assigned to a selected environment scenario, for testing, safeguarding and / or developing the function or the control program of a control device of the driver assistance system or of the autonomous vehicle.
  • Sensor output data of a corresponding sensor may be required. This sensor output data will be
  • a typical maximum distance of object and vehicle is about 200m, which is about 50000 - 65000 times the typical
  • Wavelength of a radar with a frequency of 77GHz This ratio leads to a very high resolution and computing time in direct numerical simulation, regardless of whether in spectral or in time space.
  • Less computationally intensive and expensive is the use of models on the basis of simplifying assumptions, which map the necessary physical effects with sufficient accuracy.
  • a ray tracing or shooting-bouncing ray method can be used to detect the optical propagation of rays in the
  • This beam propagation can be used directly as a virtual or simulated sensor output data for a laser scanner, as this the physical measurement principle is sufficiently accurately mapped or used by certain assumptions and further processing as the sensor output data of a radar. Assumptions for a radar would be, for example, at a certain distance (far field assumption) the propagation of radar waves, starting from a patch antenna, such as light waves or no diffraction at edges.
  • Geometry where the rays are reflected, absorbed or diffracted, to capture accurately.
  • a sensor for a driver assistance system which may be supplied with the virtual or simulated sensor output data in order to carry out the development, the protection or the tests.
  • the imposition may be at a higher semantic level on which the
  • Sensor output data have already been tracked and interpreted, such as the object or track level, or at a higher level in data processing, such as A / D data or the cluster level on a radar sensor.
  • the further forward in the data processing of the sensor the more sensor-specific the sensor output data, which can be virtually generated, simulated or provided for the stimulation of the function or control program to be tested, to be protected or developed.
  • Developing, securing and / or testing functions or control programs often requires sensor output data stimulation at a higher semantic level.
  • the ECU testing device can have a database and a computing unit.
  • the arithmetic unit can apply sensor output data to the function to be tested, to be protected or to be developed.
  • the sensor output data can be virtual, simulated or real (through test drives) to be generated.
  • the sensor output data which are assigned to a specific environment scenario and are determined by means of several input parameters, can also be taken from the database.
  • the database may have corresponding sensor output data for each possible environment scenario, which
  • control program may be executed on a control unit of a driver assistance system or an autonomous vehicle.
  • An environment scenario can here be a specific situation with which the function to be tested, to be protected or to be developed is to be confronted or acted upon. This can be described by sensor output data, or the
  • Sensor output data describes a specific environmental scenario from the perspective of a corresponding sensor.
  • the arithmetic unit can also access multiple databases for different sensors or sensor types, for example, a database for a
  • the sensor output data can cover the static as well as the dynamic environment scenario.
  • the idea can be the generation and mapping of the material property of the sensor environment in one
  • This database eg a table, can be loaded into the memory of the arithmetic unit before the simulation and, during the simulation, with the input parameters which correspond to the respective surrounding scenario, as required, to be tested or to be made available to be developed function or these are acted upon or stimulated.
  • Sensor output data can be simulated, determined or generated by means of ray tracing or a precise method, for example.
  • Such databases with sensor output data can on the one hand based on real sensor output data or by means of
  • the radar sensor can use the data from a number of measurement runs already available to simulate new scenarios, or perform calculations that use very computationally-intensive, accurate physical models to generate the database.
  • the arithmetic unit may include a processor unit and a memory unit.
  • the computing unit may be implemented by a computer (e.g., a personal computer), by an HIL test bench, by a diagnostic device, or by another controller.
  • An essential technical advantage can be the saving of the computing time. At the moment it is not possible to calculate the necessary equations, which are necessary for the detailed calculation of a radar sensor in complex driving scenarios, in real time or even faster. This makes it possible to rely on suitable sensor and environmental models that describe the physical behavior with sufficient accuracy. Only with this is the stimulation of an HIL test stand or the Simulation of more kilometers per time allows, as it would be possible by real test drives.
  • Another advantage may be the generation of test data and "early" sensor output data for environmental scenarios, which are not imageable in reality, as these are too expensive or too dangerous.
  • the environment scenario has at least one input parameter.
  • the input parameter is one of the list consisting of: temperature, air pressure, humidity, distance, vehicle speed, viewing angle, material of the object, frequency range (W-band or K-band of a radar), distance (near or far at a
  • Infrared sensor Infrared sensor
  • weather Infrared sensor
  • the frequencies of a radar sensor may be in the K and / or W bands of the radar, or the infrared sensor may be a near or far sensor.
  • the database has n dimensions and each dimension of the database
  • the database can have any number of input parameters which combine to describe a specific environment scenario.
  • a dimension can be provided in the database so that the database can have n-dimensions.
  • the respective input parameters of the database can be scaled linear, logarithmic or exponential.
  • certain areas of an input parameter or a dimension may be scaled differently.
  • Input parameters have a higher or lower resolution than another range. Furthermore, by means of Interpolation intermediate values are calculated to increase the resolution of the database.
  • the sensor output data are RCS values (radar cross section).
  • Arithmetic unit is also set up to determine the RCS values depending on the environment scenario and by means of the database.
  • the sensor output data are reflection values on objects.
  • the arithmetic unit is adapted to the reflection values depending on the
  • the sensor output data of the database correspond to sensor data of one
  • Radar sensor a LiDAR sensor, a laser scanner, a camera or an ultrasonic sensor.
  • control device test device is set up by the use of the sensor output data of the database, the function or the control program of the
  • the ECU testing device may perform the function or function
  • the computing time of the arithmetic unit is reduced by the use of the database such that the real-time criterion is met. This is particularly relevant for the development, protection and testing of HIL test benches, since the functions and control programs in the later vehicle also work reliably in real time have to. It also saves time because it does not require a large amount of time for each test, making it even more attractive to use a HIL test bench than a real test drive.
  • the data may be generated randomly or at predetermined times.
  • the time span can be, for example, 5, 10, 20 or 50 ms. In other words, it must be ensured that the respective function was executed in the respective time span.
  • the arithmetic unit is configured to read out the control commands issued by the control unit, which were generated on the basis of the sensor output data used.
  • the arithmetic unit can determine the outputs of the function to be tested, to be protected or to be developed
  • Read control program which represents a reaction to the provided sensor output data.
  • the arithmetic unit can compare the output of the function to be tested, protected or developed with an expected value.
  • the functions on a control unit in a vehicle can be checked for correct functionality. For example, a kind of TÜV for
  • Driving functions which checks the response of a particular function to a specific environment scenario, tests or hedges.
  • the arithmetic unit is designed to round the input parameters of the surrounding scenario in order to use assigned sensor output data from the database.
  • the input parameters of the environment scenario do not correspond directly to the entries in the database, the input parameters can be rounded to the next entry in the database accordingly. Thus, no error is returned by the database if the value of the
  • Input parameter does not exactly match the values of the database. It should be noted that rounded, rounded or even a combination of both can be used.
  • the arithmetic unit is designed to interpolate between the input parameters of the environment scenario in order to use assigned sensor output data from the database.
  • the database does not have a direct entry for the given input parameters of the surrounding scenario, then it is possible to interpolate between a plurality of sensor output data, which are closest to the given input parameters of the surrounding scenario. It should be noted that the
  • Interpolation can be linear, exponential, quadratic, logarithmic, trigonometric or polynomial.
  • the arithmetic unit is configured to generate the database based on real and / or simulated sensor output data.
  • the database can be generated in advance.
  • real sensor output data can be analyzed based on their environment scenarios and the corresponding input parameters and ordered or evaluated accordingly.
  • the database can generate the sensor output data by simulation by simulating the corresponding sensor output data of a sensor for a specific environment scenario with the corresponding input parameters, for example by means of ray tracing or an exact method.
  • Sensor output data can be stored in the database depending on the respective environment scenario.
  • the arithmetic unit for testing, hedging and developing functions or control programs does not have to do the same every time
  • Sensor output data which serve as input data to be tested, to be hedged and / or to be developed function, calculate or simulate, but the arithmetic unit can read the corresponding sensor output data from the database.
  • the database may consist of a
  • a further aspect of the invention relates to a method for testing, safeguarding and / or developing a function of a driver assistance system or an autonomous vehicle.
  • the method comprises the following steps:
  • the method may also have the properties associated with the
  • a vehicle which includes sensor output data from a preceding and following description
  • ECU test device receives and / or outputs responses to this sensor output data to this.
  • the vehicle is, for example, a
  • a motor vehicle such as a car, a bus, a motorcycle or a truck, an aircraft or a helicopter or a ship.
  • a further aspect of the present invention relates to a program element which, when executed by a computing unit of a controller test device, the
  • ECU test device to perform the method described in the context of the present invention.
  • Another aspect of the present invention relates to a computer-readable medium having a computer program thereon
  • Fig. 1 shows a controller testing device for testing
  • Fig. 2 shows a schematic representation of a database according to an embodiment of the invention.
  • Fig. 3 shows a vehicle which sensor output data of a
  • ECU test device receives, according to an embodiment of the invention.
  • Fig. 4 shows a flow chart for testing, saving
  • Fig. 1 shows a schematic representation of a
  • the ECU test device 1 for testing, safeguarding and / or developing a function or a control program of a driver assistance system or an autonomous vehicle.
  • the control unit test device 1 has a computing unit 10, a database 20 and a control unit 30, of which the function or the control program should be tested, secured and / or developed.
  • the function may be a control program for the control unit 30 here.
  • this control program can map the functionalities of a driver assistance system or of an autonomous vehicle.
  • FIG. 1 shows the function to be tested, to be protected and / or to be developed
  • Control program of the driver assistance system and / or the autonomous vehicle on the control unit 30 is present or is carried out by this.
  • the sensor output data 15, 25, which are required for testing, hedging and / or developing, are provided by the computing unit 10 and / or directly from the database 20. If the sensor output data 15, 25 are provided by the arithmetic unit 10, the arithmetic unit 10 can in turn still adapt, process, modify and / or filter the sensor output data 15, 25, so that changed sensor output data 15 results.
  • the function to be tested, protected and / or developed or the control program outputs an output value 35 based on the sensor output data 15, 25. This output value 35 can be output by the arithmetic unit 10 and / or another function (not shown).
  • the control unit 10 can read the sensor output data 25 from the database 20.
  • corresponding sensor output data 25 can be stored for a multiplicity of environment scenarios 11, 12, 13. Thus, not every surrounding scenario 11, 12, 13 has to be recalculated by the control unit 10 in order to calculate the sensor output data 25 as
  • the respective environment scenario 11, 12, 13 can be characterized by a variety of different
  • the input parameters can be: temperature, air pressure, humidity, Distance, speed of the vehicle, viewing angle, material of the object, frequency range (W-band or K-band of a radar), distance (near or far at one
  • the sensor output value 25 associated with a particular environment scenario 11, 12, 13 may be generated on the one hand by real sensor data that has been experienced in reality (e.g., test drives).
  • the sensor output value 25, which is assigned to a specific environment scenario 11, 12, 13, can be determined by means of a
  • Simulation generated or a combination of the latter needs to be simulated or calculated only once, and further testing, hedging, or development can rely on that simulation.
  • An advantage of simulated environment scenarios 11, 12, 13 and corresponding sensor output data 15, 25 is that even environmental scenarios 11, 12, 13, which in reality can not or only with difficulty be generated, can be tested, secured and / or developed, For example, the behavior of the function or the control program after an accident or at high speeds. Furthermore you can travel
  • Sensor output data 15, 25 are generated by sensors that do not exist in reality, so at a very early stage of development of the sensor.
  • the output 35 of the function of the control program can be evaluated or logged by the computing unit 10, so that it can be determined whether the tested, secured or developed function or the control program
  • the computing time of the computing unit 10 can be reduced by the database query in such a way that it is possible to test, secure and / or develop the function under real time.
  • the sensor output data 15, 25 may RCS values or
  • a multiplicity of sensors can be covered by the sensor output data 15, 25, for example radar sensors, LiDAR sensors, ultrasound sensors, cameras and / or laser scanners.
  • Computing unit 10 or a HIL test stand can be tested, hedged and / or developed.
  • the database 20 can also be present on the arithmetic unit 10 or the HIL test stand.
  • the database 20 may be located at a different physical location than the computing unit 10 and accessed via a network, such as the Internet, for example, as a cloud or server.
  • FIG. 2 shows a schematic view of a database 20 for a control unit test device.
  • This database 20 may have a variety of dimensions, each corresponding to an input parameter of the database 20. Furthermore, several input parameters of the database 20 result in a specific environment scenario 11, 12, 13. The various
  • Fig. 2 Dimensions and input parameters are shown in Fig. 2 by the mutually perpendicular axes 11, 12, 13, which result in a specific environment scenario. Furthermore, several tables are shown in succession in Fig. 2, each table is hereby represent the combination of two different input parameters and by the several tables, another input parameter can be varied.
  • the arithmetic unit 10 can supply the control unit 30 of the vehicle 2 with data 15, which can be sensor output data 25 of a database 20, but also generated by the arithmetic unit 10, changed or edited sensor output data 25 of the database 20.
  • the arithmetic unit 10 the sensor output data 25 obtained by the database 20.
  • the sensor output data 25 of the database correspond to a specific environment scenario 11, 12, 13 of the respective sensor.
  • the control program of the control unit 30 can be tested by the data 15 of the arithmetic unit. In this case, the output 35 of the control unit 30 or of the control program can be compared with an expected value.
  • the environment scenario 11, 12, 13 can in this case be generated by the arithmetic unit 10 and made available to the control unit 30.
  • a kind of TÜV for functions of a driver assistance system or an autonomous vehicle can be realized.
  • the output of a specific sensor of a vehicle 2 for a specific environment scenario 11, 12, 13 can be simulated by the computing unit 10.
  • FIG. 4 shows a flow chart for a method for testing, hedging and / or developing a function or a
  • step S1 Control program of a driver assistance system or an autonomous vehicle.
  • step S2 the search of a database is carried out in step S2 on the basis of the determined
  • step S3 the readout of sensor output data takes place on the basis of the specific environment scenario and the corresponding input parameters.
  • step S4 the read-out sensor output data is used to test, secure and / or develop the function or the control program of a driver assistance system or an autonomous vehicle.

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Traffic Control Systems (AREA)

Abstract

Die Erfindung betrifft eine Steuergerätetesteinrichtung zum Testen, Absichern und/oder Entwickeln einer Funktion eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs. Die Steuergerätetesteinrichtung weist eine Datenbank, in welcher Sensor-Ausgabedaten von Sensoren des Fahrzeugs jeweils einem bestimmten Umfeldszenario zugeordnet sind und eine Recheneinheit auf. Die Recheneinheit ist zur Verwendung derjenigen Sensor-Ausgabedaten der Datenbank eingerichtet, welche einem ausgewählten Umfeldszenario zugeordnet sind, zum Testen, Absichern und/oder Entwickeln der Funktion oder eines Steuerprogramms eines Steuergeräts des Fahrerassistenzsystems oder des autonomen Fahrzeugs.

Description

- Steuergerätetesteinrichtung zum Testen, Absichern und
Entwickeln von Funktionen -
Die Erfindung betrifft eine Steuergerätetesteinrichtung, ein Fahrzeug, welches Sensor-Ausgabedaten von einer
Steuergerätetesteinrichtung empfängt, ein Verfahren zum Testen und Entwickeln von Funktionen, ein Programmelement und ein computerlesbares Medium.
In der Automobilindustrie werden zunehmend neue
Fahrerassistenzsysteme (Advanced Driver Assistance System, ADAS) entwickelt. Einige dieser Fahrerassistenzsysteme dienen der Vorhersage und der Vermeidung von Zusammenstößen zwischen Verkehrsteilnehmern, insbesondere des eigenen Fahrzeugs mit einem anderen Verkehrsteilnehmer. Ferner werden zunehmend automatisierte oder automatische Fahrfunktionen entwickelt. Durch die Vermeidung von Zusammenstößen kann die Sicherheit im Straßenverkehr erhöht werden. Insbesondere wird ein Augenmerk auf Systeme zur frühzeitigen Erkennung von Zusammenstößen gelegt, denn je früher ein Zusammenstoß erkannt wird, desto höher stehen die Chancen, den Zusammenstoß gänzlich vermeiden zu können. Jedoch müssen diese Fahrerassistenzsysteme und
Fahrfunktionen bevor sie in Fahrzeuge eingebaut werden können, entwickelt, getestet und abgesichert werden. Dies kann zum einen anhand realer Testdaten und/oder realer Testfährten geschehen und zum anderen durch Hardware in the Loop (HIL) Prüfstände. Diese HIL-Prüfstände wiederum können die zu testenden, zu entwickelnde oder abzusichernden Funktionen mit Testdaten beaufschlagen, welche z.B. durch Sensoren auf Testfahrten generiert wurden. Auf dem HIL-Prüfstand können Funktionen oder Steuerprogramme getestet werden, ohne eine reale Testfahrt durchführen zu müssen. Mit anderen Worten werden dort Testfahrten simuliert. Jedoch können gewisse Situationen, wie z.B. das Verhalten nach einem Unfall, nicht oder nur sehr schwer durch reale Testdaten abgebildet werden.
Somit wird es in Zukunft immer wichtiger werden, virtuelle Testdaten für die Entwicklung, den Test und die Absicherung von Fahrerassistenzsystemen (inkl. Sensoren und Steuergeräte) oder Funktionen zu erzeugen bzw. zu nutzen und diese Funktionen durch die Testdaten zu stimulieren.
Es ist eine Aufgabe der Erfindung, das Entwickeln und Testen von Fahrfunktionen zu vereinfachen und zu beschleunigen.
Diese Aufgabe wird durch die Gegenstände der unabhängigen Ansprüche gelöst. Ausführungsformen und Weiterbildungen sind den abhängigen Ansprüchen, der Beschreibung und den Figuren zu entnehmen .
Ein erster Aspekt der Erfindung betrifft eine
Steuergerätetesteinrichtung zum Testen, Absichern und/oder Entwickeln einer Funktion oder eines Steuerprogramms eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs. Diese Steuergerätetesteinrichtung weist eine Datenbank, in welcher Sensor-Ausgabedaten von Sensoren des Fahrzeugs jeweils einem bestimmten Umfeldszenario zugeordnet sind, und eine
Recheneinheit auf. Die Recheneinheit ist zur Verwendung derjenigen Sensor-Ausgabedaten der Datenbank eingerichtet, welche einem ausgewählten Umfeldszenario zugeordnet sind, zum Testen, Absichern und/oder Entwickeln der Funktion oder des Steuerprogramms eines Steuergeräts des Fahrerassistenzsystems oder des autonomen Fahrzeugs.
Zum Testen, Absichern und/oder Entwickeln einer Funktion, insbesondere einer Fahrfunktion, und/oder eines Steuerprogramms eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs können Sensor-Ausgabedaten eines entsprechenden Sensors erforderlich sein. Diese Sensor-Ausgabedaten werden
üblicherweise von Fahrzeugsensoren erzeugt und dienen als Eingangsdaten für die zu testende, abzusichernde und/oder zu entwickelnde Funktion oder Steuerprogramm. Alternativ zu realen Sensor-Ausgabedaten können diese auch künstlich erzeugt bzw. berechnet werden, beispielsweise durch das Lösen der
entsprechenden mathematischen Gleichungen, welche die Physik exakt abbilden. Z.B. beim Radar durch lösen der entsprechenden Maxwell-Gleichungen. Möchte man zum Beispiel ein
Autobahnszenario mit Abstandsregeltempomat (Adaptive Cruise Control, ACC) und einem Long-Range-Radar simulieren, beträgt eine typische maximale Entfernung von Objekt und Fahrzeug ca. 200m, welche das ca. 50000 - 65000-fache der typischen
Wellenlänge eines Radars mit einer Frequenz von 77GHz entspricht. Dieses Verhältnis führt zu einer sehr hohen Auflösung und Rechenzeit bei direkter numerischer Simulation, unabhängig ob im spektralen oder im zeitlichen Raum. Weniger rechenintensiv und aufwändig ist die Verwendung von Modellen auf Basis von vereinfachenden Annahmen, welche die nötigen physikalischen Effekte hinreichend genau abbilden. Beispielsweise kann ein Raytracing oder Shooting-Bouncing-Ray Verfahren verwendet werden, um die optische Ausbreitung von Strahlen in dem
Sensorumfeld zu berechnen. Diese Strahlenausbreitung kann direkt als virtuelle oder simulierte Sensor-Ausgabedaten für einen Laser-Scanner verwendet werden, da dadurch das physikalische Messprinzip hinreichend genau abgebildet wird oder durch gewisse Annahmen und Weiterverarbeitung als Sensor-Ausgabedaten eines Radars genutzt werden. Annahmen für einen Radar wären zum Beispiel ab einer gewissen Entfernung (Fernfeldannahme) die Ausbreitung von Radarwellen, ausgehend von einer Patchantenne, wie Lichtwellen oder keine Beugung an Kanten. Durch die
Hinzunahme weiterer Modelle können Effekte wie Beugung an Kanten aber wiederum in betrachtet werden. Bei einem solchen Modell ist es wichtig, die Eigenschaften von Oberflächen und deren
Geometrie, an denen die Strahlen reflektiert, absorbiert oder gebeugt werden, genau zu erfassen.
Es sei angemerkt, dass verschiedene Ebenen der Datenverarbeitung in einem Sensor für ein Fahrerassistenzsystem existieren können, welche mit den virtuellen oder simulierten Sensor-Ausgabedaten beaufschlagt werden können, um die Entwicklung, die Absicherung oder die Tests durchführen zu können. Die Beaufschlagung kann auf einer höheren semantischen Ebene, auf welcher die
Sensor-Ausgabedaten schon zeitlich verfolgt und interpretiert wurden, wie zum Beispiel die Objekt- oder Spur-Ebene, oder auf einer in der Datenverarbeitung weiter vorne liegenden Ebene, wie A/D-Daten oder der Cluster Ebene auf einem Radarsensor, erfolgen. Je weiter in der Datenverarbeitung des Sensors zeitlich nach vorne gegangen wird, desto sensor-spezifischer werden die Sensor-Ausgabedaten, welche für die Stimulierung der zu testenden, abzusichernden oder zu entwickelnden Funktion oder Steuerprogramm virtuell erzeugt, simuliert oder bereitgestellt werden können. Um Funktionen oder Steuerprogramme zu entwickeln, abzusichern und/oder zu testen reicht oft die Stimulation durch Sensor-Ausgabedaten auf einer höheren semantischen Ebene. Je umfangreicher der Test oder die Absicherung der Funktionen oder des Sensors ausfallen soll, desto weiter vorne, zeitlich gesehen, muss in der Datenverarbeitung die Stimulation mit virtuellen Sensor-Ausgabedaten stattfinden.
Für das Testen, Absichern und/oder Entwickeln von Funktionen oder Steuerprogrammen des Fahrerassistenzsystems oder des autonomen Fahrzeugs kann die Steuergerätetesteinrichtung eine Datenbank und eine Recheneinheit aufweisen. Die Recheneinheit kann die zu testende, abzusichernde oder zu entwickelnde Funktion mit Sensor-Ausgabedaten beaufschlagen. Die Sensor-Ausgabedaten können virtuell, simuliert oder real (durch Testfahrten) generiert werden. Neben der Berechnung der entsprechenden Sensor-Ausgabedaten separat für jedes Umfeldszenario, können die Sensor-Ausgabedaten, welche einem bestimmten Umfeldszenario zugeordnet sind und anhand mehrere Eingangsparameter bestimmt werden, auch aus der Datenbank entnommen werden. Mit anderen Worten kann die Datenbank zu jedem möglichen Umfeldszenario entsprechende Sensor-Ausgabedaten aufweisen, welche
anschließend durch die Recheneinheit bedarfsgerecht ausgelesen werden können. Somit entfällt eine erneute Berechnung oder Simulation der Sensor-Ausgabedaten zu dem jeweiligen Zeitpunkt der Verwendung bei dem Test, der Absicherung oder der Entwicklung und die Rechenzeit kann signifikant reduziert werden.
Es ist zu verstehen, dass die Funktion oder das Steuerprogramm auf einem Steuergerät eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs ausgeführt werden können.
Ein Umfeldszenario kann hierbei eine bestimmte Situation sein, mit welcher die zu testende, abzusichernde oder zu entwickelnde Funktion konfrontiert oder beaufschlagt werden soll. Dieses kann durch Sensor-Ausgabedaten beschrieben werden, bzw. die
Sensor-Ausgabedaten beschreiben ein bestimmtes Umfeldszenario aus der Sicht eines entsprechenden Sensors.
Es sei angemerkt, dass die Recheneinheit auch auf mehrere Datenbanken für verschiedene Sensoren oder Sensortypen zugreifen kann, beispielsweise kann auf eine Datenbank für einen
Radarsensor und auf eine andere Datenbank für einen LiDAR-Sensor zurückgegriffen werden.
Mit Entwicklung von Sensoren ist sowohl Umfeldwahrnehmung wie Objekt- oder Freiraumdetektion, als auch Funktionsentwicklung wie ACC oder ein Notbremsassistent (Emergency Brake Assistent, EBA) gemeint. Die Sensor-Ausgabedaten können das statische, wie auch das dynamische Umfeldszenario abdecken.
Die Erzeugung von realen Sensor-Ausgabedaten für
Umfeldszenarien, in denen zum Beispiel die schwere eines unvermeidbaren Unfalls getestet werden soll, ist erst gar nicht möglich oder nur mit sehr großen Kosten und Risiken verbunden. Dies ist mit der vorhergehend und nachfolgend beschriebenen Einrichtung möglich, da hierfür die Sensor-Ausgabedaten auch simulativ erzeugt werden können.
Mit anderen Worten kann die Idee die Erzeugung und Kartierung der Materialeigenschaft des Sensorumfeldes in einer
Sensorsimulation vor dem eigentlichen Test, der Absicherung oder dem Entwickeln der Funktion oder des Steuerprogramms sein, und zwar aus Sicht des Sensors. Es kann eine Datenbank erstellt werden, in welcher abgelegt ist, wie ein Sensor das Umfeld detektiert, unabhängig von dem physikalischen Messprinzip des Sensors. So können zum Beispiel für einen Laser-Scanner (LiDAR) die Reflektivitäten von Oberflächen und für einen Radar der geschätzte Radarquerschnitt (RCS) der reflektierenden
Oberfläche in Abhängigkeiten von verschiedenen Parametern, wie zum Beispiel Entfernung, Betrachtungswinkel und Wettereinflüsse in der Datenbank abgelegt werden. Diese Sensor-Ausgabedaten können anschließend bedarfsgerecht mithilfe von den Parametern zur Simulationszeit wiederrum aus der Datenbank ausgelesen und zur Stimulation der Funktionen oder der Steuerprogramme des Steuergeräts verwendet werden, ohne diese „online" berechnen zu müssen. Der RCS Wert kann eine wesentliche Basis für die weitere Berechnung von Informationen auf dem Radar darstellen. Diese Datenbank, z.B. eine Tabelle, kann vor der Simulation in den Speicher der Recheneinheit geladen und während der Simulation mit den Eingangsparametern, welche dem jeweiligen Umfeldszenario entsprechen, bedarfsgerecht der zu testenden, abzusichernden oder zu entwickelnden Funktion zur Verfügung gestellt werden bzw. diese damit beaufschlagt oder stimuliert werden. Die
Sensor-Ausgabedaten können beispielsweise mittels Raytracing oder einem exakten Verfahren simulativ berechnet, bestimmt oder generiert werden.
Auf diese Art kann eine Simulationsgeschwindigkeit erreicht werden, welche die EchtZeitanforderung von HIL-Prüfständen erfüllt oder darunterliegt und somit Zeiteinsparungen und Kosteneinsparung gegenüber realen Testfahrten möglich sind.
Solche Datenbanken mit Sensor-Ausgabedaten können zum einen basierend auf realen Sensor-Ausgabedaten oder mittels
computergestützter Simulation erzeugt werden. Für einen
Radarsensor können zum Beispiel die Daten von etlichen, bereits zur Verfügungen stehenden Messfahrten genutzt werden, um neue Szenarien zu simulieren oder es können Berechnungen durchgeführt werden, in denen sehr rechenintensive, exakte physikalische Modelle genutzt werden, um die Datenbank zu erzeugen.
Es sei angemerkt, dass die Recheneinheit eine Prozessoreinheit und eine Speichereinheit aufweisen kann. Ferner kann die Recheneinheit durch einen Computer (z.B. ein PC), durch einen HIL-Prüfstand, durch ein Diagnosegerät oder durch ein weiteres Steuergerät realisiert werden.
Ein wesentlicher technischer Vorteil kann in der Einsparung der Rechenzeit liegen. Momentan ist es nicht möglich, die nötigen Gleichungen, die zum Beispiel für die detaillierte Berechnung eines Radarsensors in komplexen Fahrszenarien nötig sind, in Echtzeit oder sogar schneller zu berechnen. Hierdurch kann man auf geeignete Sensor- und Umfeldmodelle angewiesen sein, welche das physikalische Verhalten hinreichend genau beschreiben. Erst hiermit wird die Stimulation eines HIL-PrüfStands oder die Simulation von mehr Kilometern pro Zeit ermöglicht, als es durch reale Testfahrten möglich wäre. Ein weiterer Vorteil kann die Erzeugung von Testdaten und „frühen" Sensor-Ausgabedaten für Umfeldszenarien sein, welche in der Realität nicht abbildbar sind, da diese zu teuer oder zu gefährlich sind.
Gemäß einer Ausführungsform weist das Umfeldszenario wenigstens einen Eingangsparameter auf. Der Eingangsparameter ist einer aus der Liste bestehend aus: Temperatur, Luftdruck, Luftfeuchte, Entfernung, Geschwindigkeit des Fahrzeugs, Betrachtungswinkel, Material des Objekts, Frequenzbereich (W-Band oder K-Band eines Radars) , Entfernung (Nah- oder Fernbereich bei einem
Infrarotsensor) und/oder Witterung.
Die Frequenzen eines Radarsensors können in dem K- und/oder W-Band des Radars liegen oder es kann sich bei dem Infrarot-Sensor um ein Nah- oder Fernbereich Sensor handeln.
Gemäß einer weiteren Ausführungsform weist die Datenbank n-Dimensionen auf und jede Dimension der Datenbank
korrespondiert mit einem Eingangsparameter des Umfeldszenarios.
Die Datenbank kann beliebig viele Eingangsparameter aufweisen, welche kombiniert ein bestimmtes Umfeldszenario beschreiben. Für jeden Eingangsparameter kann in der Datenbank eine Dimension vorgesehen sein, sodass die Datenbank n-Dimensionen aufweisen kann. Die jeweiligen Eingangsparameter der Datenbank können linear, logarithmisch oder exponentiell skaliert sein.
Alternativ oder zusätzlich können auch bestimmte Bereiche eines Eingangsparameters bzw. einer Dimension anders skaliert sein. Mit anderen Worten kann ein gewisser Bereich eines
Eingangsparameters eine höhere oder niedrigere Auflösung aufweisen als ein anderer Bereich. Ferner können mittels Interpolation Zwischenwerte berechnet werden, um die Auflösung der Datenbank zu erhöhen.
Gemäß einer Ausführungsform sind die Sensor-Ausgabedaten RCS-Werte (Radar Cross Section, Radarquerschnitt) . Die
Recheneinheit ist ferner dazu eingerichtet, die RCS-Werte abhängig von dem Umfeldszenario und mittels der Datenbank zu bestimmen .
Gemäß einer Ausführungsform sind die Sensor-Ausgabedaten Reflektionswerte an Objekten. Die Recheneinheit ist dazu eingerichtet, die Reflektionswerte abhängig von dem
Umfeldszenario und mittels der Datenbank zu bestimmen.
Gemäß einer weiteren Ausführungsform korrespondieren die Sensor-Ausgabedaten der Datenbank mit Sensordaten eines
Radarsensors, eines LiDAR-Sensors , eines Laserscanners, einer Kamera oder eines Ultraschallsensors.
Gemäß einer Ausführungsform ist die Steuergerätetesteinrichtung dazu eingerichtet, durch die Verwendung der Sensor-Ausgabedaten der Datenbank die Funktion oder das Steuerprogramm des
Fahrerassistenzsystems oder des autonomen Fahrzeugs in Echtzeit zu testen.
Durch die Verwendung der Sensor-Ausgabedaten der Datenbank kann die Steuergerätetesteinrichtung die Funktion oder das
Steuerprogramm des Fahrerassistenzsystems oder des autonomen Fahrzeugs in Echtzeit testen. Mit anderen Worten reduziert sich die Rechenzeit der Recheneinheit durch die Verwendung der Datenbank derart, dass das Echtzeitkriterium erfüllt ist. Dies ist insbesondere für die Entwicklung, Absicherung und Tests an HIL-Prüfständen relevant, da die Funktionen und Steuerprogramme im späteren Fahrzeug auch in Echtzeit verlässlich arbeiten müssen. Ferner kann so Zeit eingespart werden, da nicht für jeden Test eine große Zeitspanne benötigt wird, wodurch die Verwendung eines HIL-PrüfStands weiter an Attraktivität gegenüber einer realen Testfahrt gewinnt.
Unter Echtzeit versteht man gemäß DIN ISO/IEC 2382 den Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen. Die Zeitspanne kann hierbei beispielsweise bei 5, 10, 20 oder 50ms liegen. Mit anderen Worten muss sichergestellt sein, dass die jeweilige Funktion in der jeweiligen Zeitspanne ausgeführt wurde.
Gemäß einer Ausführungsform ist die Recheneinheit dazu eingerichtet, die von dem Steuergerät ausgegebenen Steuerbefehle auszulesen, welche aufgrund der verwendeten Sensor-Ausgabedaten erzeugt wurden.
Ferner kann die Recheneinheit die Ausgaben der zu testenden, abzusichernde oder zu entwickelnden Funktion oder des
Steuerprogramms auslesen, welche eine Reaktion auf die zur Verfügung gestellten Sensor-Ausgabedaten darstellt. Somit kann die Recheneinheit die Ausgabe der zu testenden, abzusichernden oder zu entwickelnden Funktion mit einem Erwartungswert vergleichen. Ferner können auch die Funktionen auf einem Steuergerät in einem Fahrzeug auf korrekte Funktionalität hin überprüft werden. Beispielsweise kann eine Art TÜV für
Fahrfunktionen bereitgestellt werden, welche die Reaktion einer bestimmten Funktion auf ein bestimmtes Umfeldszenario hin überprüft, testet oder absichert. Gemäß einer weiteren Ausführungsform ist die Recheneinheit dazu ausgeführt, die Eingangsparameter des Umfeldszenarios zu runden, um zugeordnete Sensor-Ausgabedaten aus der Datenbank zu verwenden .
Für den Fall, dass die Eingangsparameter des Umfeldszenarios nicht direkt mit den Einträgen der Datenbank übereinstimmen, können die Eingangsparameter entsprechend auf den nächsten Eintrag der Datenbank gerundet werden. Somit wird kein Fehler durch die Datenbank zurückgegeben, wenn der Wert des
Eingangsparameters nicht exakt mit den Werten der Datenbank übereinstimmt. Es sei angemerkt, dass abgerundet, aufgerundet oder auch eine Kombination aus beiden verwendet werden kann.
Gemäß einer Ausführungsform ist die Recheneinheit dazu ausgeführt, zwischen den Eingangsparametern des Umfeldszenarios zu interpolieren, um zugeordnete Sensor-Ausgabedaten aus der Datenbank zu verwenden.
Sollte die Datenbank zu den gegebenen Eingangsparametern des Umfeldszenarios keinen direkten Eintrag aufweisen, so kann zwischen einer Mehrzahl von Sensor-Ausgabedaten interpoliert werden, welche nächstliegend zu den gegebenen Eingangsparametern des Umfeldszenarios sind. Es sei angemerkt, dass die
Interpolation hierbei linear, exponentiell, quadratisch, logarithmisch, trigonometrisch oder polynominal erfolgen kann.
Gemäß einer Ausführungsform ist die Recheneinheit dazu eingerichtet, die Datenbank anhand realer und/oder simulierter Sensor-Ausgabedaten zu erzeugen. Ein vordefiniertes
Umfeldszenario mit korrespondierenden Eingangsparametern führt zu bestimmten Sensor-Ausgabedaten. Die Datenbank kann im Vorfeld erzeugt werden. Zum einen können reale Sensor-Ausgabedaten anhand ihrer Umfeldszenarien und der entsprechenden Eingangsparameter analysiert und entsprechend geordnet oder ausgewertet werden. Zum anderen kann die Datenbank durch Simulation die Sensor-Ausgabedaten erzeugen, indem durch eine Recheneinheit die entsprechenden Sensor-Ausgabedaten eines Sensors für ein bestimmtes Umfeldszenario mit den entsprechenden Eingangsparametern simuliert wird, z.B. mittels Raytracing oder einem exakten Verfahren. Diese realen bzw. simulierten
Sensor-Ausgabedaten können in der Datenbank abhängig von dem jeweiligen Umfeldszenario hinterlegt werden. Somit muss die Recheneinheit zum Testen, Abzusichern und Entwickeln von Funktionen bzw. Steuerprogrammen nicht jedes Mal die
Sensor-Ausgabedaten, welche als Eingangsdaten der zu testenden, abzusichernden und/oder zu entwickelnden Funktion dienen, berechnen oder simulieren, sondern die Recheneinheit kann die entsprechenden Sensor-Ausgabedaten aus der Datenbank auslesen. Alternativ oder zusätzlich kann die Datenbank aus einer
Kombination aus realen und simulierten Sensor-Ausgabedaten aufgebaut sein. Somit können auch Sensor-Ausgabedaten von in Realität schweren oder gar nicht erzeugbaren Umfeldszenarien (Unfälle oder hohe Geschwindigkeiten) zur Verfügung gestellt werden .
Ein weiterer Aspekt der Erfindung betrifft ein Verfahren zum Testen, Absichern und/oder Entwickeln einer Funktion eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs. Das Verfahren weist folgende Schritte auf:
- Auswählen eines Umfeldszenarios und Bestimmen
korrespondierender Eingangsparameter;
- Durchsuchen einer Datenbank anhand des bestimmten
Umfeldszenarios und mit den korrespondierenden
Eingangsparametern; - Auslesen von Sensor-Ausgabedaten aus der Datenbank, welche mit den Eingangsparametern des Umfeldszenarios
korrespondieren;
- Verwenden der ausgelesenen Sensor-Ausgabedaten, um die Funktion oder ein Steuerprogramm eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs zu testen, abzusichern und/oder zu entwickeln.
Es sei angemerkt, dass das Verfahren auch die Eigenschaften aufweisen kann, welche im Zusammenhang mit der
Steuergerätetesteinrichtung beschrieben wurden.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein Fahrzeug bereitgestellt, welches Sensor-Ausgabedaten von einer vorhergehend und nachfolgend beschriebenen
Steuergerätetesteinrichtung empfängt und/oder Reaktionen auf diese Sensor-Ausgabedaten an dieses abgibt.
Bei dem Fahrzeug handelt es sich beispielsweise um ein
Kraftfahrzeug, wie ein Auto, einen Bus, ein Motorrad oder einen Lastkraftwagen, um ein Flugzeug oder einen Helikopter oder um ein Schiff .
Ein weiterer Aspekt der vorliegenden Erfindung betrifft ein Programmelement, das, wenn es von einer Recheneinheit einer Steuergerätetesteinrichtung ausgeführt wird, die
Steuergerätetesteinrichtung anleitet, das im Kontext der vorliegenden Erfindung beschriebene Verfahren durchzuführen.
Ein weiterer Aspekt der vorliegenden Erfindung betrifft ein computerlesbares Medium, auf dem ein Computerprogramm
gespeichert ist, das, wenn es von einer Recheneinheit einer Steuergerätetesteinrichtung ausgeführt wird, die Steuergerätetesteinrichtung anleitet, das im Kontext der vorliegenden Erfindung beschriebene Verfahren durchzuführen.
Weitere Merkmale, Vorteile und Anwendungsmöglichkeiten der Erfindung ergeben sich aus der nachfolgenden Beschreibung der Ausführungsbeispiele und Figuren.
Die Figuren sind schematisch und nicht maßstabsgetreu. Sind in der nachfolgenden Beschreibung in verschiedenen Figuren die gleichen Bezugszeichen angegeben, so bezeichnen diese gleichen oder ähnlichen Elemente.
Fig. 1 zeigt eine Steuergerätetesteinrichtung zum Testen und
Entwickeln von Funktionen gemäß einer Ausführungsform der Erfindung.
Fig. 2 zeigt eine schematische Darstellung einer Datenbank gemäß einer Ausführungsform der Erfindung.
Fig. 3 zeigt ein Fahrzeug, welches Sensor-Ausgabedaten einer
Steuergerätetesteinrichtung empfängt, gemäß einer Ausführungsform der Erfindung.
Fig. 4 zeigt ein Flussdiagramm zum Testen, Absichern und
Entwickeln einer Funktion eines
Fahrerassistenzsystems oder eines autonomen Fahrzeugs gemäß einer Ausführungsform der Erfindung.
Fig. 1 zeigt eine schematische Darstellung einer
Steuergerätetesteinrichtung 1 zum Testen, Absichern und/oder Entwickeln einer Funktion oder eines Steuerprogramms eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs. Die Steuergerätetesteinrichtung 1 weist eine Recheneinheit 10, eine Datenbank 20 und ein Steuergerät 30, von welcher die Funktion oder das Steuerprogramm getestet, abgesichert und/oder entwickelt werden soll, auf. Die Funktion kann hierbei ein Steuerprogramm für das Steuergerät 30 sein. Ferner kann dieses Steuerprogramm die Funktionalitäten eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs abbilden. In Fig. 1 ist die zu testende, abzusichernde und/oder zu entwickelnde Funktion oder
Steuerprogramm des Fahrerassistenzsystems und/oder des autonomen Fahrzeugs auf dem Steuergerät 30 vorhanden bzw. wird durch dieses ausgeführt. Die Sensor-Ausgabedaten 15, 25, welche zum Testen, Absichern und/oder Entwickeln benötigt werden, werden von der Recheneinheit 10 und/oder direkt von der Datenbank 20 bereitgestellt. Wenn die Sensor-Ausgabedaten 15, 25 durch die Recheneinheit 10 bereitgestellt werden, kann die Recheneinheit 10 die Sensor-Ausgabedaten 15, 25 ihrerseits noch anpassen, verarbeiten, verändert und/oder filtern, sodass geänderte Sensor-Ausgabedaten 15 entstehen. Die zu testende, abzusichernde und/oder zu entwickelnde Funktion oder das Steuerprogramm gibt, basierend auf den Sensor-Ausgabedaten 15, 25, einen Ausgabewert 35 aus. Dieser Ausgabewert 35 kann durch die Recheneinheit 10 und/oder einer weiteren Funktion (nicht dargestellt)
weiterverarbeitet werden. Zur Reduzierung der Rechenleistung auf der Recheneinheit 10 und zur Verbesserung der Leistungsfähigkeit der Recheneinheit 10, kann diese die Sensor-Ausgabedaten 25 aus der Datenbank 20 auslesen. In der Datenbank 20 können zu einer Vielzahl von Umfeldszenarien 11, 12, 13 korrespondierende Sensor-Ausgabedaten 25 gespeichert sein. Somit muss nicht jedes Umfeldszenario 11, 12, 13 durch die Steuereinheit 10 neu gerechnet werden, um die Sensor-Ausgabedaten 25 als
Eingangsdaten für die zu testende, abzusichernde oder zu entwickelnde Funktion zu erhalten, sondern es kann lediglich die Datenbank 20 durchsucht werden. Das jeweilige Umfeldszenario 11, 12, 13 kann durch eine Vielzahl an verschiedenen
Eingangsparametern beschrieben werden. Die Eingangsparameter können dabei sein: Temperatur, Luftdruck, Luftfeuchte, Entfernung, Geschwindigkeit des Fahrzeugs, Betrachtungswinkel, Material des Objekts, Frequenzbereich (W-Band oder K-Band eines Radars) , Entfernung (Nah- oder Fernbereich bei einem
Infrarotsensor) und/oder Witterung. Der Sensor-Ausgabewert 25, welcher einem bestimmten Umfeldszenario 11, 12, 13 zugeordnet ist kann einerseits durch reale Sensordaten, welche in Realität erfahren wurden (z.B. Testfahrten), erzeugt werden . Andererseits kann der Sensor-Ausgabewert 25, welcher einem bestimmten Umfeldszenario 11, 12, 13 zugeordnet ist, mittels einer
Simulation erzeugt werden oder einer Kombination aus den Letzt genannten. Somit muss ein bestimmtes Umfeldszenario für einen bestimmten Sensor nur einmal simuliert bzw. berechnet werden und die weiteren Tests, Absicherungen oder Entwicklungen können auf diese Simulation zurückgreifen.
Ein Vorteil von Simulierten Umfeldszenarien 11, 12, 13 und korrespondierenden Sensor-Ausgabedaten 15, 25 ist, dass auch Umfeldszenarien 11, 12, 13, welche in Realität nicht oder nur schwer erzeugt werden können, getestet, abgesichert und/oder entwickelt werden können, beispielsweise das Verhalten der Funktion oder des Steuerprogramms nach einem Unfall oder bei hohen Geschwindigkeiten. Des Weiteren können bereist
Sensor-Ausgabedaten 15, 25 von Sensoren erzeugt werden, welche in Realität noch nicht existieren, also bereits in einer sehr frühen Phase der Entwicklung des Sensors.
Ferner kann die Ausgabe 35 der Funktion des Steuerprogramms durch die Recheneinheit 10 ausgewertet oder protokolliert werden, sodass festgestellt werden kann, ob die getestete, abgesicherte oder entwickelte Funktion oder das Steuerprogramm
erwartungsgemäß auf die Sensor-Ausgabedaten 15, 25 des jeweiligen Umfeldszenarios 11, 12, 13 reagiert. Ferner ist zu verstehen, dass durch die Datenbankabfrage die Rechenzeit der Recheneinheit 10 derart reduziert werden kann, dass das Testen, Absichern und/oder Entwickeln der Funktion unter Echtzeit möglich ist.
Die Sensor-Ausgabedaten 15, 25 können RCS-Werte oder
Reflektionswerte an einer Oberfläche sein. Ferner können durch die Sensor-Ausgabedaten 15, 25 eine Vielzahl an Sensoren abgedeckt werden, beispielsweise Radarsensoren, LiDAR-Sensoren, Ultraschallsensoren, Kameras und/oder Laserscanner.
Es sei angemerkt, dass die Funktion des Fahrerassistenzsystems oder des autonomen Fahrzeugs auch komplett auf einer
Recheneinheit 10 oder einem HIL-Prüfstand getestet, abgesichert und/oder entwickelt werden kann. Ferner kann auch die Datenbank 20 auf der Recheneinheit 10 oder dem HIL-Prüfstand vorhanden sein. Alternativ oder zusätzlich kann sich die Datenbank 20 an einem anderen physischen Ort befinden wie die Recheneinheit 10 und über ein Netzwerk, wie das Internet, erreicht werden, beispielsweise als Cloud oder Server.
Fig. 2 zeigt eine schematische Ansicht einer Datenbank 20 für eine Steuergerätetesteinrichtung. Diese Datenbank 20 kann eine Vielzahl an Dimensionen aufweisen, welche jeweils mit einem Eingangsparameter der Datenbank 20 korrespondiert. Ferner ergeben mehrere Eingangsparameter der Datenbank 20 ein bestimmtes Umfeldszenario 11, 12, 13. Die verschiedenen
Dimensionen bzw. Eingangsparameter sind in Fig. 2 durch die senkrecht aufeinander stehenden Achsen 11, 12, 13, welche ein bestimmtes Umfeldszenario ergeben, dargestellt. Ferner sind in Fig. 2 mehrere Tabellen hintereinander dargestellt, jede einzelne Tabelle soll hierbei die Kombination von zwei verschiedenen Eingangsparametern darstellen und durch die mehreren Tabellen kann ein weiterer Eingangsparameter variiert werden .
Fig. 3 zeigt ein Fahrzeug 2 mit einem Steuergerät 30 und einer Steuergerätetesteinrichtung 1. Die Recheneinheit 10 kann das Steuergerät 30 des Fahrzeugs 2 mit Daten 15 beaufschlagen, welche Sensor-Ausgabedaten 25 einer Datenbank 20 sein können, jedoch auch durch die Recheneinheit 10 erzeugte, veränderte oder aufbereitete Sensor-Ausgabedaten 25 der Datenbank 20. Zur Vereinfachung und zur Reduzierung der Rechenleistung kann die Recheneinheit 10 die Sensor-Ausgabedaten 25 durch die Datenbank 20 erhalten. Hierbei korrespondieren die Sensor-Ausgabedaten 25 der Datenbank mit einem bestimmten Umfeldszenario 11, 12, 13 des jeweiligen Sensors. Das Steuerprogramm des Steuergeräts 30 kann durch die Daten 15 der Recheneinheit getestet werden. Hierbei kann die Ausgabe 35 des Steuergeräts 30 bzw. des Steuerprogramms mit einem Erwartungswert verglichen werden. Ferner kann überprüft werden, ob das Steuerprogramm oder die Funktion bei einem definierten Umfeldszenario 11, 12, 13 erwartungsgemäß regiert. Das Umfeldszenario 11, 12, 13 kann hierbei durch die Recheneinheit 10 erzeugt werden und dem Steuergerät 30 zu Verfügung gestellt werden. Alternativ oder zusätzlich kann so eine Art TÜV für Funktionen eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs realisiert werden.
Mit anderen Worten kann die Ausgabe eines bestimmten Sensors eines Fahrzeugs 2 für ein bestimmtes Umfeldszenario 11, 12, 13 durch die Recheneinheit 10 simuliert werden.
Fig. 4 zeigt ein Flussdiagramm für ein Verfahren zum Testen, Absichern und/oder Entwickeln einer Funktion oder eines
Steuerprogramms eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs. In Schritt S1 wird ein bestimmtes
Umfeldszenario ausgewählt und die entsprechenden Eingangsparameter bestimmt. Anschließend erfolgt in Schritt S2 die Durchsuchung einer Datenbank anhand des bestimmten
Umfeldszenarios mit den korrespondierenden Eingangsparametern. In Schritt S3 erfolgt das Auslesen von Sensor-Ausgabedaten anhand des bestimmten Umfeldszenarios und den korrespondierenden Eingangsparametern. Abschließend werden in Schritt S4 die ausgelesenen Sensor-Ausgabedaten verwendet, um die Funktion oder das Steuerprogramm eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs zu testen, abzusichern und/oder zu entwickeln.

Claims

Ansprüche :
1. Steuergerätetesteinrichtung (1) zum Testen, Absichern und/oder Entwickeln einer Funktion eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs, aufweisend:
- eine Datenbank (20), in welcher Sensor-Ausgabedaten (25) von Sensoren des Fahrzeugs (2) jeweils einem bestimmten
Umfeldszenario (11, 12, 13) zugeordnet sind; und
- eine Recheneinheit (10), eingerichtet zur Verwendung derjenigen Sensor-Ausgabedaten (25) der Datenbank (20), welche einem ausgewählten Umfeldszenario (11, 12, 13) zugeordnet sind, zum Testen, Absichern und/oder Entwickeln der Funktion oder eines Steuerprogramms eines Steuergeräts (30) des
Fahrerassistenzsystems oder des autonomen Fahrzeugs.
2. Steuergerätetesteinrichtung (1) gemäß Anspruch 1,
wobei das Umfeldszenario (11, 12, 13) wenigstens einen
Eingangsparameter aufweist, aus der Liste bestehend aus:
Temperatur, Luftdruck, Luftfeuchte, Entfernung, Geschwindigkeit des Fahrzeugs, Betrachtungswinkel, Material des Objekts, Frequenzbereich und/oder Witterung.
3. Steuergerätetesteinrichtung (1) gemäß Anspruch 1 oder 2, wobei die Datenbank (20) n-Dimensionen aufweist und jede
Dimension der Datenbank (20) mit einem Eingangsparameter des Umfeldszenarios (11, 12, 13) korrespondiert.
4. Steuergerätetesteinrichtung (1) gemäß Anspruch 1 bis 3, wobei die Sensor-Ausgabedaten (25) RCS-Werte sind, und wobei die Recheneinheit (10) dazu eingerichtet ist, die
RCS-Werte abhängig von dem Umfeldszenario (11, 12, 13) und mittels der Datenbank (20) zu bestimmen.
5. Steuergerätetesteinrichtung (1) gemäß Anspruch 1 bis 3, wobei die Sensor-Ausgabedaten (25) Reflektionswerte an
Objekten sind, und
wobei die Recheneinheit (10) dazu eingerichtet ist, die Reflektionswerte abhängig von dem Umfeldszenario (11, 12, 13) und mittels der Datenbank (20) zu bestimmen.
6. Steuergerätetesteinrichtung (1) gemäß einem der
vorhergehenden Ansprüche,
wobei die Sensor-Ausgabedaten (25) der Datenbank (20) mit Sensordaten eines Radarsensors, eines LiDAR-Sensors , eines Laserscanners, einer Kamera oder eines Ultraschallsensors korrespondieren .
7. Steuergerätetesteinrichtung (1) gemäß einem der
vorhergehenden Ansprüche,
wobei die Steuergerätetesteinrichtung (1) dazu
eingerichtet ist, durch die Verwendung der Sensor-Ausgabedaten (25) der Datenbank (20) die Funktion oder das Steuerprogramm des Fahrerassistenzsystems oder des autonomen Fahrzeugs in Echtzeit zu testen.
8. Steuergerätetesteinrichtung (1) gemäß einem der
vorhergehenden Ansprüche,
wobei die Recheneinheit (10) dazu eingerichtet ist, die von dem Steuergerät (30) ausgegebenen Steuerbefehle (35), welche aufgrund der verwendeten Sensor-Ausgabedaten (25) erzeugt wurden, auszulesen.
9. Steuergerätetesteinrichtung (1) gemäß einem der
vorhergehenden Ansprüche,
wobei die Recheneinheit (10) dazu ausgeführt ist, die Eingangsparameter des Umfeldszenarios (11, 12, 13) zu runden, um zugeordnete Sensor-Ausgabedaten (25) aus der Datenbank (20) zu verwenden .
10. Steuergerätetesteinrichtung (1) gemäß einem der Ansprüche 1 bis 8,
wobei die Recheneinheit (10) dazu ausgeführt ist, zwischen den Eingangsparametern des Umfeldszenarios (11, 12, 13) zu interpolieren, um zugeordnete Sensor-Ausgabedaten (25) aus der Datenbank (20) zu verwenden.
11. Steuergerätetesteinrichtung (1) gemäß einem der
vorhergehenden Ansprüche,
wobei die Recheneinheit (10) dazu eingerichtet ist, die Datenbank (20) anhand realer und/oder simulierter
Sensor-Ausgabedaten (25) zu erzeugen,
wobei ein vordefiniertes Umfeldszenario (11, 12, 13) mit korrespondierenden Eingangsparametern zu bestimmten
Sensor-Ausgabedaten (25) führt.
12. Fahrzeug (2), welches Sensor-Ausgabedaten (25) von einer Steuergerätetesteinrichtung (1) gemäß einem der vorhergehenden Ansprüche empfängt.
13. Verfahren zum Testen, Absichern und/oder Entwickeln einer Funktion eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs, folgende Schritte aufweisend:
- Auswählen (Sl) eines Umfeldszenarios und Bestimmen korrespondierender Eingangsparameter;
- Durchsuchen (S2) einer Datenbank anhand des bestimmten Umfeldszenarios und mit den korrespondierenden
Eingangsparametern;
- Auslesen (S3) von Sensor-Ausgabedaten aus der Datenbank, welche mit den Eingangsparametern des Umfeldszenarios
korrespondieren; - Verwenden (S4) der ausgelesenen Sensor-Ausgabedaten, um die Funktion eines Fahrerassistenzsystems oder eines autonomen Fahrzeugs zu testen, abzusichern und/oder zu entwickeln.
14. Programmelement, das, wenn es auf einer Recheneinheit einer
Steuergerätetesteinrichtung ausgeführt wird, die
Steuergerätetesteinrichtung anleitet, das Verfahren gemäß Anspruch 13 durchzuführen.
15. Computerlesbares Medium, auf dem ein Programmelement gemäß
Anspruch 14 gespeichert ist.
PCT/DE2019/200025 2018-04-17 2019-03-22 Steuergerätetesteinrichtung zum testen, absichern und entwickeln von funktionen Ceased WO2019201400A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE112019000361.5T DE112019000361A5 (de) 2018-04-17 2019-03-22 Steuergerätetesteinrichtung zum Testen, Absichern und Entwickeln von Funktionen

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102018205804.0 2018-04-17
DE102018205804.0A DE102018205804A1 (de) 2018-04-17 2018-04-17 Steuergerätetesteinrichtung zum Testen, Absichern und Entwickeln von Funktionen

Publications (1)

Publication Number Publication Date
WO2019201400A1 true WO2019201400A1 (de) 2019-10-24

Family

ID=66223548

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2019/200025 Ceased WO2019201400A1 (de) 2018-04-17 2019-03-22 Steuergerätetesteinrichtung zum testen, absichern und entwickeln von funktionen

Country Status (2)

Country Link
DE (2) DE102018205804A1 (de)
WO (1) WO2019201400A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113297530A (zh) * 2021-04-15 2021-08-24 南京大学 一种基于场景搜索的自动驾驶黑盒测试系统
WO2021253063A1 (de) * 2020-06-16 2021-12-23 Avl List Gmbh System zum testen eines fahrerassistenzsystems eines fahrzeugs
CN114355864A (zh) * 2021-12-28 2022-04-15 重庆长安汽车股份有限公司 用于智能驾驶模型开发的模型在环测试方法、系统及计算机可读存储介质
US12555417B2 (en) 2021-03-01 2026-02-17 Avl List Gmbh Method for testing a driver assistance system of a vehicle

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AT521992B1 (de) * 2020-02-20 2021-11-15 Avl List Gmbh System und Verfahren zum Testen eines Fahrerassistenzsystems eines Kraftfahrzeugs
DE102020118450A1 (de) 2020-07-13 2022-01-13 Bayerische Motoren Werke Aktiengesellschaft Verfahren und System zum Erzeugen von Testdaten für eine Simulation zur Absicherung einer Fahrfunktion zum automatisierten Fahren
DE102020213226A1 (de) 2020-10-20 2022-04-21 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zur Prüfung einer Funktionsfähigkeit eines Umfeldsensorsystems in einem zumindest teilautomatisierten Fahrzeug
DE102020130748A1 (de) 2020-11-20 2022-05-25 Bayerische Motoren Werke Aktiengesellschaft Verfahren, System sowie ein Computerprogramm zum Erzeugen einer virtuellen Umgebung eines Fahrzeugs
DE102022107845A1 (de) 2022-04-01 2023-10-05 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verfahren, System und Computerprogrammprodukt zur Auswahl von konkreten Szenarien
DE102022112060B3 (de) 2022-05-13 2023-04-20 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Szenariendatenbank für ein Verfahren und ein System zur Kalibrierung und Validierung eines Fahrerassistenzsystems (ADAS) und/oder eines automatisierten Fahrsystems (ADS)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10254388A1 (de) * 2002-11-18 2004-05-27 Volkswagen Ag Verfahren und Vorrichtung zum Bandende- oder Werkstatt-Test von Fahrzeug-Assistenzsystemen
CN102991437A (zh) * 2011-09-09 2013-03-27 罗伯特·博世有限公司 驾驶员辅助系统的使用方法
DE102013212710A1 (de) * 2013-05-16 2014-11-20 Siemens Aktiengesellschaft Sensorprodukt, Simulator und Verfahren zur Simulation von Sensormessungen, zur Fusion von Sensormessungen, zur Validierung eines Sensormodells und zum Entwurf eines Fahrerassistenzsystems

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014118625A1 (de) * 2014-12-15 2016-06-16 Valeo Schalter Und Sensoren Gmbh Sensoranordnung für einen Prüfstand eines Fahrerassistenzsystems eines Kraftfahrzeugs, Prüfstand sowie dazugehöriges Verfahren
US20170168920A1 (en) * 2015-12-09 2017-06-15 Dspace Digital Signal Processing And Control Engineering Gmbh Transfer of payload data
FR3045870B1 (fr) * 2015-12-21 2018-08-31 Valeo Equipements Electriques Moteur Procede hors ligne d'allocation d'un logiciel embarque temps reel sur une architecture multicontroleur multicoeur, et son utilisation pour des applications embarquees dans un vehicule automobile

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10254388A1 (de) * 2002-11-18 2004-05-27 Volkswagen Ag Verfahren und Vorrichtung zum Bandende- oder Werkstatt-Test von Fahrzeug-Assistenzsystemen
CN102991437A (zh) * 2011-09-09 2013-03-27 罗伯特·博世有限公司 驾驶员辅助系统的使用方法
DE102013212710A1 (de) * 2013-05-16 2014-11-20 Siemens Aktiengesellschaft Sensorprodukt, Simulator und Verfahren zur Simulation von Sensormessungen, zur Fusion von Sensormessungen, zur Validierung eines Sensormodells und zum Entwurf eines Fahrerassistenzsystems

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021253063A1 (de) * 2020-06-16 2021-12-23 Avl List Gmbh System zum testen eines fahrerassistenzsystems eines fahrzeugs
CN115699123A (zh) * 2020-06-16 2023-02-03 Avl 里斯脱有限公司 用于测试车辆的驾驶员辅助系统的系统
US12304510B2 (en) 2020-06-16 2025-05-20 Avl List Gmbh System for testing a driver assistance system of a vehicle
US12555417B2 (en) 2021-03-01 2026-02-17 Avl List Gmbh Method for testing a driver assistance system of a vehicle
CN113297530A (zh) * 2021-04-15 2021-08-24 南京大学 一种基于场景搜索的自动驾驶黑盒测试系统
CN113297530B (zh) * 2021-04-15 2024-04-09 南京大学 一种基于场景搜索的自动驾驶黑盒测试系统
CN114355864A (zh) * 2021-12-28 2022-04-15 重庆长安汽车股份有限公司 用于智能驾驶模型开发的模型在环测试方法、系统及计算机可读存储介质
CN114355864B (zh) * 2021-12-28 2024-05-03 重庆长安汽车股份有限公司 用于智能驾驶模型开发的模型在环测试方法、系统及计算机可读存储介质

Also Published As

Publication number Publication date
DE102018205804A1 (de) 2019-10-17
DE112019000361A5 (de) 2020-10-01

Similar Documents

Publication Publication Date Title
DE102018205804A1 (de) Steuergerätetesteinrichtung zum Testen, Absichern und Entwickeln von Funktionen
EP3695244B1 (de) Verfahren und vorrichtung zum erzeugen eines inversen sensormodells und verfahren zum erkennen von hindernissen
EP2564049B1 (de) STEUERGERÄT UND VERFAHREN ZUR BERECHNUNG EINER AUSGANGSGRÖßE FÜR EINE STEUERUNG
DE102013218678A1 (de) Entwurfssystem und Verfahren zum Entwurf eines Fahrerassistenzsystems
AT521120A1 (de) Verfahren und Vorrichtung zum Ermitteln eines Radarquerschnitts, Verfahren zum Trainieren eines Wechselwirkungsmodells sowie Radarzielemulator und Prüfstand
EP4055411B1 (de) Verfahren, vorrichtung und computerprogramm zur freigabe eines sensorsystems zur erfassung von objekten in einem umfeld eines fahrzeuges
EP4222470B1 (de) Computergestütztes verfahren und vorrichtung zur wahrscheinlichkeitsbasierten geschwindigkeitsprognose für fahrzeuge
DE102022108505A1 (de) Objekterfassung durch ein neuronales netz
DE102014114602A9 (de) Messungszuordnung bei Fahrzeugen
DE102021122407A1 (de) Segmentierung und klassifizierung von punktwolkendaten
DE102019211006B4 (de) Auswerten von Sensordaten eines Fahrzeugs
DE102017103683A1 (de) Ultraschall-Entfernungskorrektur
DE102018217268A1 (de) Vorrichtung und Verfahren zum Ermitteln von Höheninformationen eines Objekts in einer Umgebung eines Fahrzeugs
DE102021125773A1 (de) Verfahren zum gleichzeitigen schätzen von bewegung und form eines zielfahrzeugs mittels eines vorverteilungsmodells eines tracklets
DE102024108499A1 (de) Multi-task-lernen
AT524932B1 (de) Verfahren und System zum Testen eines Fahrerassistenzsystems für ein Fahrzeug
DE102021131484A1 (de) Messen von vertrauen in tiefen neuronalen netzwerken
DE102017218922A1 (de) Verfahren und Vorrichtung zur Datenerhebung
DE102023101585A1 (de) Fahrzeugwegverifizierung
WO2023131603A1 (de) Verfahren zur optimierung der umfeldwahrnehmung für ein fahrunterstützungssystem mittels zusätzlicher referenzsensorik
DE102020206641B4 (de) Verfahren und Vorrichtung zum Bereitstellen einer hochauflösenden digitalen Karte
WO2023099066A1 (de) Simulation zur validierung einer automatisierenden fahrfunktion für ein fahrzeug
DE102020214596A1 (de) Verfahren zum Erzeugen von Trainingsdaten für ein Erkennungsmodell zum Erkennen von Objekten in Sensordaten einer Umfeldsensorik eines Fahrzeugs, Verfahren zum Erzeugen eines solchen Erkennungsmodells und Verfahren zum Ansteuern einer Aktorik eines Fahrzeugs
DE102020215657A1 (de) Verfahren und System zum Testen eines Steuergeräts eines Fahrzeugs
DE102014118624A1 (de) Verfahren zum simulativen Bestimmen einer Interaktion zwischen einem Sensor eines Kraftfahrzeugs und einem virtuellen Objekt in einem virtuellen Umgebungsbereich des Kraftfahrzeugs sowie Recheneinrichtung

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: 19718239

Country of ref document: EP

Kind code of ref document: A1

REG Reference to national code

Ref country code: DE

Ref legal event code: R225

Ref document number: 112019000361

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19718239

Country of ref document: EP

Kind code of ref document: A1