Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
CONTROL UNIT TEST DEVICE FOR TESTING, PROTECTING AND DEVELOPING FUNCTIONS
Document Type and Number:
WIPO Patent Application WO/2019/201400
Kind Code:
A1
Abstract:
The invention relates to a control unit test device for testing, protecting and/or developing a function of a driver assistance system or of an autonomous vehicle. The control unit test device has a database, in which sensor output data from sensors of the vehicle are each associated with a particular environmental scenario, and a computing unit. The computing unit is configured to use those sensor output data of the database that are associated with a selected environmental scenario to test, protect and/or develop the function or a control program of a control unit of the driver assistance system or of the autonomous vehicle.

Inventors:
BREITENBERGER THOMAS (DE)
Application Number:
PCT/DE2019/200025
Publication Date:
October 24, 2019
Filing Date:
March 22, 2019
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
CONTI TEMIC MICROELECTRONIC GMBH (DE)
International Classes:
B60W50/02
Foreign References:
DE10254388A12004-05-27
CN102991437A2013-03-27
DE102013212710A12014-11-20
Other References:
None
Download PDF:
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.

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.




 
Previous Patent: MULTI-PART VEHICLE WHEEL WITH A SEAL

Next Patent: HEAT EXCHANGER