DE102019124504A1 - Verfahren und Vorrichtung zur Simulation und Bewertung eines Sensorsystems für ein Fahrzeug sowie Verfahren und Vorrichtung zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug - Google Patents

Verfahren und Vorrichtung zur Simulation und Bewertung eines Sensorsystems für ein Fahrzeug sowie Verfahren und Vorrichtung zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug Download PDF

Info

Publication number
DE102019124504A1
DE102019124504A1 DE102019124504.4A DE102019124504A DE102019124504A1 DE 102019124504 A1 DE102019124504 A1 DE 102019124504A1 DE 102019124504 A DE102019124504 A DE 102019124504A DE 102019124504 A1 DE102019124504 A1 DE 102019124504A1
Authority
DE
Germany
Prior art keywords
sensor
environment
virtual
vehicle
sensor system
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.)
Pending
Application number
DE102019124504.4A
Other languages
English (en)
Inventor
Maike Hartstern
Matthias Traub
Monish Gogri
Mario Walk
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.)
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke AG
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 Bayerische Motoren Werke AG filed Critical Bayerische Motoren Werke AG
Priority to DE102019124504.4A priority Critical patent/DE102019124504A1/de
Publication of DE102019124504A1 publication Critical patent/DE102019124504A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G01MEASURING; TESTING
    • G01MTESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M17/00Testing of vehicles
    • G01M17/007Wheeled or endless-tracked vehicles
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/20Design optimisation, verification or simulation
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01SRADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S13/00Systems using the reflection or reradiation of radio waves, e.g. radar systems; Analogous systems using reflection or reradiation of waves whose nature or wavelength is irrelevant or unspecified
    • G01S13/88Radar or analogous systems specially adapted for specific applications
    • G01S13/93Radar or analogous systems specially adapted for specific applications for anti-collision purposes
    • G01S13/931Radar or analogous systems specially adapted for specific applications for anti-collision purposes of land vehicles
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/10Geometric CAD
    • G06F30/15Vehicle, aircraft or watercraft design

Landscapes

  • Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • Traffic Control Systems (AREA)

Abstract

Es werden ein Verfahren zur Simulation und Bewertung eines Sensorsystems für ein Fahrzeug sowie eine korrespondierende Vorrichtung angegeben. Das Sensorsystem (10) weist einen oder mehrere Umfeldsensoren (1, 2, 3, n) auf. Das Verfahren umfasst die Schritte:A1) Bereitstellen jeweils eines Sensormodells (SM) für jeden der Umfeldsensoren (1-n) des Sensorsystems (10), das jeweils repräsentativ ist für physikalische Eigenschaften des jeweiligen Umfeldsensors (1-n) bei Abbildung eines realen Umfelds des Fahrzeugs (100) mittels realer Messung durch den jeweiligen Umfeldsensor (1-n),B1) Bereitstellen eines Umfeldmodells (UM), das repräsentativ ist für ein virtuelles Umfeld eines virtuellen Fahrzeugs (100),C1) Ermitteln virtueller Sensordaten (SD) für jeden der Umfeldsensoren (1-n) des Sensorsystems (100) abhängig von dem Umfeldmodell (UM) und dem jeweiligen Sensormodell (SM), D1) Evaluieren der virtuellen Sensordaten (SD) abhängig von dem Umfeldmodell (UM).Darüber hinaus werden ein Verfahren zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug sowie eine korrespondierende Vorrichtung angegeben.

Description

  • Die Erfindung betrifft ein Verfahren zur Simulation und Bewertung eines Sensorsystems für ein Fahrzeug sowie eine korrespondierende Vorrichtung. Darüber hinaus betrifft die Erfindung ein Verfahren zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug sowie eine korrespondierende Vorrichtung. Schließlich werden ein Computerprogramm und ein computerlesbares Speichermedium angegeben.
  • Mit steigendem Automatisierungsgrad von (Kraft-)fahrzeugen wachsen auch die Anforderungen an Sensorsysteme der Fahrzeuge zur Umfelddetektion. Derartige Sensorsysteme umfassen einen oder mehrere Umfeldsensoren, um Hindernisse im Umfeld des jeweiligen Fahrzeugs bzw. die Umgebung selbst frühzeitig, sicher und präzise zu erkennen. Auf dem Markt existieren bereits zahlreiche solcher Umfeldsensoren und zugrundeliegende Sensortechnologien werden beständig weiterentwickelt. Eine Herausforderung in diesem Zusammenhang liegt insbesondere darin, ein Zusammenwirken einzelner Umfeldsensoren in einem Sensorsystem zu bewerten, ohne aufwändige Testfahrten vornehmen zu müssen.
  • Eine Aufgabe, die der Erfindung zugrunde liegt, ist es, ein Verfahren und eine korrespondierende Vorrichtung zu schaffen, das bzw. die eine einheitliche, kostengünstige Bewertung verschiedener Sensorsysteme ermöglicht. Insbesondere soll beigetragen werden, das Sensorsystem derart zu konfigurieren, dass ein sicherer Betrieb des Fahrzeugs gewährleistet ist.
  • Die Aufgabe wird gelöst durch die unabhängigen Patentansprüche. Vorteilhafte Ausgestaltungen sind in den Unteransprüchen gekennzeichnet.
  • Gemäß einem ersten Aspekt betrifft die Erfindung ein Verfahren zur Simulation eines Sensorsystems für ein Fahrzeug. Das Sensorsystem weist einen oder mehrere Umfeldsensoren auf. Bei den Umfeldsensoren handelt es sich beispielhaft um eine Kamera und/oder einen Radar und/oder einen Lidar und/oder einen Ultraschallsensor.
  • Das Verfahren umfasst folgende Schritte:
    • In einem Schritt A1) wird jeweils ein Sensormodell für jeden der Umfeldsensoren des Sensorsystems bereitgestellt. Das Sensormodell ist jeweils repräsentativ für physikalische Eigenschaften des jeweiligen Umfeldsensors bei Abbildung eines realen Umfelds des Fahrzeugs mittels realer Messung durch den jeweiligen Umfeldsensor. In anderen Worten beschreibt das jeweilige Sensormodell eine Datenstruktur, die eine Übersetzung von einer realen Gegebenheit auf eine Messung der realen Gegebenheit durch den jeweiligen Umfeldsensors auf Basis physikalischer Eigenschaften und/oder vorgegebenen Testmessungen des jeweiligen Umfeldsensors modelliert.
  • In einem Schritt B1) wird ein Umfeldmodell bereitgestellt. Das Umfeldmodell ist repräsentativ für ein virtuelles Umfeld eines virtuellen Fahrzeugs. Das Umfeldmodell bezeichnet insbesondere eine Datenstruktur, die eine weitgehend exakte Nachbildung eines realen Umfelds eines realen Fahrzeugs modelliert. Beispielhaft kann das reale Umfeld zur Erzeugung eines solchen Umfeldmodells vermessen und als virtuelles Polygonmodell konstruiert werden. Es kann jedoch auch ein beliebiges Umfeld mit diversen Polygon-Elementen virtuell designt und generiert werden. Polygonmodelle des Umfelds bieten den Vorteil, dass sie den Sensormodellen wichtige physikalische Informationen (Formkontur, Oberflächeneigenschäften wie Reflexion/Absorption) bereitstellen können. Alternativ kann das Umfeldmodell vereinfacht auch in Form von Objektlisten umgesetzt werden, was eine Simulation auf „High-Level-Ebene“ ermöglicht.
  • In einem Schritt C1) werden virtuelle Sensordaten für jeden der Umfeldsensoren des Sensorsystems abhängig von dem Umfeldmodell und dem jeweiligen Sensormodell ermittelt. In anderen Worten werden in dem Schritt C1) virtuelle Messungen in dem durch das Umfeldmodell repräsentierten virtuellen Umfeld durchgeführt. Hierzu können etwa Schnittpunkte einer Anzahl von Strahlen ausgehend von dem jeweiligen Umfeldsensor mit virtuellen Objekten des Umfeldmodells ermittelt werden. Bei einer Simulation auf „High-Level-Ebene“ können die virtuellen Sensordaten alternativ hierzu auch in Form von Objektlisten umgesetzt werden. Die virtuellen Sensordaten repräsentieren insbesondere eine virtuelle Abbildung des virtuellen Umfelds durch den jeweiligen Umfeldsensor.
  • In einem Schritt D1) werden die virtuellen Sensordaten abhängig von dem Umfeldmodell evaluiert. Als derartige Evaluierung wird hier und im Folgenden ein Vergleich des durch die Umfeldsensoren erfassten virtuellen Umfelds und des durch das Umfeldmodell repräsentierten virtuellen Umfelds bezeichnet. Abhängig von dem Vergleich können dabei ein oder mehrere Bewertungskennzahlen (sogenannte „key performance indicators“, KPIs) vergeben werden, wobei das durch die Umfeldsensoren erfasste virtuelle Umfeld im Idealfall mit dem durch das Umfeldmodell repräsentierten virtuellen Umfeld übereinstimmt.
  • In vorteilhafter Weise kann das Sensorsystem so ohne aufwändige Testfahrten durchführen zu müssen bereits in einer frühen Entwicklungsphase einheitlich bewertet werden, was insbesondere einen effizienten Vergleich mehrerer Sensorsysteme ermöglicht. Mit dem erfindungsgemäßen Verfahren wird beigetragen, auch bei hoher Komplexität hinsichtlich einer Anzahl denkbarer, unterschiedlicher Sensorsysteme anhand von Kosten-Nutzen-Analysen ein optimales Sensorsystem für einen jeweiligen Fahrzeugtyp festzulegen. Automobilherstellern wird damit insbesondere erleichtert, geeignete Sensorsysteme zu definieren, welche sämtliche (Sicherheits-)Anforderungen berücksichtigen bzw. erfüllen. Neben einer Leistungsfähigkeit der einzelnen Umfeldsensoren und einer bevorzugt vollständigen Sichtfeldabdeckung um das Fahrzeug (d.h. 360° um das Fahrzeug im Nah- und Fernbereich) können weitere Faktoren wie Gesamtkosten des jeweiligen Sensorsystems und Integration der einzelnen Umfeldsensoren bzw. des gesamten Sensorsystems in das Fahrzeug, insbesondere Anordnung und Ausrichtung der einzelnen Umfeldsensoren im Hinblick auf ein Design des Fahrzeugs berücksichtigt werden. Darüber hinaus können ein redundanter Aufbau des Sensorsystems und störende Umwelteinflüsse wie Wetter- und Lichtbedingungen sowie Verschmutzung berücksichtigt werden. Zusammenfassend kann somit auch beigetragen werden, das Sensorsystem derart zu konfigurieren, dass ein sicherer Betrieb des Fahrzeugs gewährleistet ist.
  • In einer vorteilhaften Ausgestaltung gemäß dem ersten Aspekt werden in dem Schritt A1) zu dem jeweiligen Umfeldsensor Konfigurationsparameter bereitgestellt, die repräsentativ sind für eine Konfiguration des jeweiligen Umfeldsensors. Die Konfigurationsparameter können insbesondere einen oder mehrere der folgenden Parameter umfassen: eine Position des Umfeldsensors im bzw. am Fahrzeug, eine Ausrichtung des Umfeldsensors bezüglich eines vorgegebenen Bezugskoordinatensystems des Fahrzeugs.
  • Darüber hinaus werden in dem Schritt C1) die virtuellen Sensordaten des jeweiligen Umfeldsensors abhängig von den Konfigurationsparametern ermittelt. In vorteilhafter Weise können so etwa unterschiedliche Einbaupositionen verschiedener Umfeldsensoren berücksichtigt werden.
  • In einer vorteilhaften Ausgestaltung gemäß dem ersten Aspekt wird wenigstens ein wichtiger Bereich um das virtuelle Fahrzeug vorgegeben. Als wichtiger Bereich wird hier und im Folgenden eine sogenannte „region of interest“, ROI, bezeichnet. Der wichtige Bereich beschreibt etwa einen Bereich um das Fahrzeug, welcher bevorzugt von dem Sensorsystem überwacht werden soll. Derartige Bereiche können sich etwa aus Vorschriften und Randbedingungen in diesem Zusammenhang ergeben. So kann beispielsweise ein minimaler Kurvenradius eines Straßenabschnitts bei einer vorgegebenen Höchstgeschwindigkeit gesetzlich geregelt sein, so dass eine nötige Sichtweite auf den Straßenverlauf in Fahrtrichtung und schräg zur Fahrtrichtung geometrisch erschlossen werden können.
  • Darüber hinaus werden in dem Schritt D1) die virtuellen Sensordaten bezüglich des wichtigen Bereichs gewichtet.
  • Einzelne wichtige Bereiche können sich dabei in ihrer Gewichtung unterscheiden, etwa je nach Wahrscheinlichkeit eines Unfalls und einem zu erwartenden Ausmaß im Falle eines Unfalls. In die Gewichtung kann bzw. können etwa eine Relativgeschwindigkeit des Fahrzeugs zu anderen Verkehrsteilnehmern und/oder ein Abstand zwischen dem Fahrzeug und anderen Verkehrsteilnehmern und/oder ein Typ der anderen Verkehrsteilnehmer und eine damit verbundene Kritikalität im Falle eines Unfalls einfließen.
  • In einer vorteilhaften Ausgestaltung gemäß dem ersten Aspekt wird in dem Schritt D1) abhängig von den virtuellen Sensordaten sämtlicher Umfeldsensoren eine Sensordatenfusion ermittelt. Die Sensordatenfusion wird dabei abhängig von dem Umfeldmodell evaluiert. Insbesondere erfolgt die Ermittlung der Sensordatenfusion nach dem Schritt C1) und bevor das Umfeldmodell in dem Schritt D1) evaluiert wird. Bei dem Ermitteln der Sensordatenfusion werden in anderen Worten die Informationen aller Sensoren zusammengeführt und ein Abbild des Umfeldmodells aus Sicht des gesamten Sensorsetups generiert. Bei der Durchführung einer derartigen Datenfusion können Algorithmen (typischerweise Kalman Filter) zum Einsatz kommen, welche bei der Erstellung dieses Gesamtbilds die Performance der jeweiligen Sensoren berücksichtigen. Einem Sensor mit geringerer Genauigkeit wird beispielhaft weniger Gewichtung zugeteilt als Performance-stärkeren Sensoren.
  • In einer vorteilhaften Ausgestaltung gemäß dem ersten Aspekt umfasst das Umfeldmodell Umfelddaten, die repräsentativ sind für eine Vielzahl dreidimensionaler Koordinaten virtueller Objektbegrenzungen im virtuellen Umfeld des virtuellen Fahrzeugs. Die Umfelddaten können auch als „Ground Truth“-Daten bezeichnet werden (kurz „GT“).
  • Die virtuellen Sensordaten eines jeweiligen Umfeldsensors sind jeweils repräsentativ für eine Vielzahl dreidimensionaler Koordinaten einer virtuellen Messung des jeweiligen Umfeldsensors im virtuellen Umfeld des virtuellen Fahrzeugs.
  • Die ermittelte Sensordatenfusion umfasst Fusionsdaten, die repräsentativ sind für eine Vielzahl dreidimensionaler Koordinaten virtueller Objektbegrenzungen im virtuellen Umfeld des virtuellen Fahrzeugs. Die Fusionsdaten stellen in anderen Worten Ergebnisse einer durchgeführten Fusion der Sensordaten dar und können auch als „Tracks“ bezeichnet werden.
  • In dem Schritt D1) werden die Fusionsdaten mit den Umfelddaten mittels Bewertungskennzahlen evaluiert. In anderen Worten wird in dem Schritt D1) ein Zusammenwirken sämtlicher (zur Sensordatenfusion beitragender) Umfeldsensoren bewertet. Als Bewertungskennzahlen kommen insbesondere eine oder mehrere Metriken in Frage, die die Fusionsdaten mit den Umfelddaten in Relation setzen.
  • In einer vorteilhaften Ausgestaltung gemäß dem ersten Aspekt werden die Fusionsdaten in dem Schritt D1) mit den Umfelddaten anhand einer oder einer Kombination aus mehreren der folgenden statistischen Bewertungskennzahlen evaluiert:
    • - Hausdorff,
    • - optimal subpattern assignment, OSPA,
    • - Positions-/Geschwindigkeits-/Beschleunigungsfehler,
    • - normalized estimation error squared, NEES,
    • - multiple object tracker accuracy, MOTA,
    • - multiple object tracker performance, MOTP,
    • - Detektionsrate, oder
    • - Falsch-Alarm-Rate.
  • Alternativ zu den vorgenannten Metriken können auch beliebige andere Metriken, insbesondere andere statistische Bewertungskennzahlen, zum Einsatz kommen.
  • Bei der Hausdorff-Metrik wird ein größter Abstand zwischen einem Track und einem zugehörigen GT-Wert (Ausreißer) bewertet.
  • Bei der OSPA-Metrik wird zwischen GT und Tracks ein globales Optimum hinsichtlich Übereinstimmung (subpattern) gesucht und der gemittelte Abstand zwischen Tracks und zugehörigen GT-Werten ermittelt. Gibt es mehr GT-Werte als Tracks (oder umgekehrt), fließt dies negativ in die OSPA-Metrik ein, so dass Falsch-Positive bzw. Falsch-Negative berücksichtigt werden können.
  • Bei dem Positions-/Geschwindigkeits-/Beschleunigungsfehler wird ein Abstand zwischen Tracks und GT-Werten (in Metern) ermittelt, sodass der entsprechende Fehler die Genauigkeit der Sensordaten angibt.
  • Bei der NEES-Metrik wird ein Abstand zwischen Tracks und GT-Werten in Einheiten der Unsicherheit ermittelt. Die NEES-Metrik kann auch ein Indikator dafür sein, ob eine Unsicherheit wie ein Messfehler eines Umfeldsensors oder ein Prozessrauschen im Sensormodell als zu groß oder zu klein angenommen wurde.
  • Bei der MOTA-Metrik werden Abweichungen zwischen Tracks und zugehörigen GT-Werten aufsummiert und geteilt durch die Anzahl aller Zuordnungen (gemittelter Fehler).
  • Bei der MOTP-Metrik werden Falsch-Positive, Falsch-Negative und Falsch-Zuordnungen aufsummiert und geteilt durch eine Anzahl an Objekten im virtuellen Umfeld des Fahrzeugs.
  • Bei der Detektionsrate wird eine Anzahl der Tracks geteilt durch eine Anzahl der GTs innerhalb der Sichtkegel der Umfeldsensoren.
  • Bei der Falsch-Alarm-Rate wird eine Anzahl an Tracks, die keinem GT-Wert zugeordnet werden konnten, geteilt durch die Gesamtanzahl an Zuordnungen ermittelt.
  • In einer vorteilhaften Ausgestaltung gemäß dem ersten Aspekt werden die Fusionsdaten in dem Schritt D1) mit den Umfelddaten anhand einer oder einer Kombination aus mehreren der folgenden globalen Bewertungskennzahlen evaluiert:
    • - Objekt-Detektionszeit,
    • - Erfassungsrate,
    • - Sensor-aufgelöste Erfassungsrate.
  • Alternativ zu den vorgenannten Metriken können auch beliebige andere Metriken, insbesondere andere globale Bewertungskennzahlen, zum Einsatz kommen.
  • Die globalen Bewertungskennzahlen dienen insbesondere zur Differenzierung verschiedener Sensorsysteme.
  • Bei der Objekt-Detektionszeit wird ermittelt, wann ein Objekt vom jeweiligen Sensorsystem erkannt wurde. Insbesondere kann in diesem Zusammenhang geprüft werden, wann ein Track angelegt wurde. Darüber hinaus wird ermittelt, welcher Abstand zum Objekt vorliegt. Ferner wird ermittelt, ob ein Bremsweg insbesondere bei einer vorgegebenen Geschwindigkeit höher als der ermittelte Abstand zum Objekt ist, sodass es zu einem Unfall kommen würde oder ob genügend Zeit verbleibt, um einen Unfall durch Bremsen verhindern zu können.
  • Bei der Erfassungsrate wird eine Anzahl der Tracks geteilt durch eine Anzahl aller GTs ermittelt, insbesondere unabhängig davon, ob die GT-Werte innerhalb eines Sichtkegels eines der Umfeldsensoren liegen oder nicht.
  • Bei der Sensor-aufgelösten Erfassungsrate wird eine Übersicht ermittelt, welcher Umfeldsensor zu welchem Track beigetragen hat, um so eine Redundanz im Sensorsystem hervorzuheben.
  • Gemäß einem zweiten Aspekt betrifft die Erfindung ein Verfahren zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug. Sämtliche im Zusammenhang mit dem ersten Aspekt beschriebenen Merkmale gelten ebenso für den zweiten Aspekt und umgekehrt.
  • Das Verfahren gemäß dem zweiten Aspekt umfasst folgende Schritte: In einem Schritt A2) wird eine Vielzahl von Umfeldsensoren bereitgestellt. Ferner wird für jeden der Umfeldsensoren ein Sensormodell erzeugt. Das Sensormodell ist jeweils repräsentativ für physikalische Eigenschaften des jeweiligen Umfeldsensors bei Abbildung eines realen Umfelds des Fahrzeugs mittels realer Messung durch den jeweiligen Umfeldsensor. Die Vielzahl von Umfeldsensoren weist insbesondere mehrere unterschiedliche Typen von Umfeldsensoren auf. Das Sensormodell wird beispielhaft anhand von Messprotokollen, bei Prototypen etwa im Rahmen von sogenannten „Proof-of-Concepts“, POCs, erzeugt. Bei den Messprotokollen können insbesondere sogenannte „Corner Cases“ geprüft werden, um systematisch Schlüsselkriterien des jeweiligen Umfeldsensors zu testen. Alternativ oder zusätzlich kann bei Erzeugung des Sensormodells ein Datenblatt des Herstellers oder ein bereits bestehendes Sensormodell herangezogen werden.
  • In einem Schritt B2) wird wenigstens ein Umfeldmodell erzeugt. Das jeweilige Umfeldmodell ist repräsentativ für ein virtuelles Umfeld eines virtuellen Fahrzeugs. Bei der Erzeugung des jeweiligen Umfeldmodells kann insbesondere jeweils ein Szenario anhand von Szenarioparametern abgebildet werden, das gezielt relevante Schlüsselkriterien des Sensorsystems adressiert (z.B. Corner Cases). Ein Szenario kann etwa das rechtzeitige Erkennen eines Stauendes oder ein Hindernis einer Kurve betreffen.
  • In einem Schritt C2) werden mehrere verschiedene virtuelle Sensorsysteme erzeugt. Ein virtuelles Sensorsystem weist jeweils einen oder mehrere Umfeldsensoren der Vielzahl von Umfeldsensoren auf. In anderen Worten wird aus der bereitgestellten Vielzahl von Umfeldsensoren mit zum Teil unterschiedlichen Typen von Umfeldsensoren jeweils eine Untermenge ausgewählt, um ein Zusammenwirken dieser Umfeldsensoren bewerten zu können.
  • In einem Schritt D2) wird jeweils eine Simulation gemäß dem ersten Aspekt eines der mehreren verschiedenen virtuellen Sensorsysteme durchgeführt abhängig von dem jeweiligen Sensormodell der Umfeldsensoren des entsprechenden Sensorsystems und dem wenigstens einen Umfeldmodell. In anderen Worten wird in dem Schritt A1) das für jeden der Umfeldsensoren des zu simulierenden Sensorsystems erzeugte Sensormodell bereitgestellt, in dem Schritt B1) eines der Umfeldmodelle bereitgestellt und die Evaluierung in dem Schritt D1) ermittelt.
  • In einem Schritt E2) wird eine Evaluierung des jeweiligen Sensorsystems abhängig von der Simulation ausgegeben oder gespeichert.
  • In vorteilhafter Weise können die mehreren verschiedenen virtuellen Sensorsysteme so in einem einheitlichen, reproduzierbaren Bewertungsprozess beurteilt werden, der objektive und vergleichbare Ergebnisse liefert, etwa in Form von KPIs. Das Verfahren trägt zu einer zeitsparenden und kostengünstigen Lösung zur Beurteilung verschiedener Sensorsystem-Varianten für eine Vorauswahl oder eine Festlegung auf ein final zu verbauendes Sensorsystem im Fahrzeug bei. Hierbei kann mit Vorteil eine Analyse hinsichtlich verschiedener Einbaupositionen, Kombinationen und Sensortechnologien der verschiedenen Umfeldsensoren umgesetzt werden, insbesondere im Hinblick auf Wirkzusammenhänge beim Zusammenspiel verschiedener Umfeldsensoren.
  • In einer vorteilhaften Ausgestaltung gemäß dem zweiten Aspekt wird abhängig von der Evaluierung des jeweiligen Sensorsystems eine Auswahl des wenigstens eines Umfeldsensors getroffen. Alternativ oder zusätzlich wird abhängig von der Evaluierung des jeweiligen Sensorsystems eine Platzierung des Umfeldsensors im Fahrzeug vorgenommen. Alternativ oder zusätzlich wird abhängig von der Evaluierung des jeweiligen Sensorsystems eine Ausrichtung des Umfeldsensors bezüglich des Fahrzeugs vorgenommen. In anderen Worten kann das Simulationsergebnis gezielt dazu genutzt werden, die Umfeldsensoren des realen Sensorsystems bestmöglich im realen Fahrzeug zu integrieren, um so zu einem sicheren Betrieb des Fahrzeugs beizutragen.
  • In einer vorteilhaften Ausgestaltung gemäß dem zweiten Aspekt wird das jeweilige Sensormodell in dem Schritt A2) abhängig von einem vorgegebenen Satz an Sensorparametern ermittelt, die repräsentativ sind für die physikalischen Eigenschaften des jeweiligen Umfeldsensors bei Abbildung eines realen Umfelds des Fahrzeugs mittels realer Messung durch den jeweiligen Umfeldsensor. Die Sensorparameter können insbesondere einen oder mehrere folgender Parameter umfassen: eine Messgenauigkeit des Umfeldsensors, eine Detektionswahrscheinlichkeit des Umfeldsensors, eine Reichweite des Umfeldsensors, einen Sichtkegel des Umfeldsensors (sogenanntes „Field of view“, FOV). Die Sensorparameter entsprechen beispielhaft Erkenntnissen aus Testmessungen und/oder Datenblattangaben. Die Sensorparameter sind variabel und werden insbesondere so eingestellt, dass sie den zu betrachtenden Umfeldsensor möglichst gut repräsentieren und so den für den entsprechenden Umfeldsensor den vorgegebenen Satz an Sensorparametern bilden. Zum Einstellen der Sensorparameter können Angaben aus Sensor-Datenblättern und Messprotokollen entnommen oder aus Testmessungen mit dem einzelnen Umfeldsensor abgeleitet werden. Alternativ ist es möglich, ein durch den Hersteller des Umfeldsensors bereitgestelltes Sensormodell heranzuziehen, das den entsprechenden Umfeldsensor mit hoher Übereinstimmung repräsentiert. Wird solch ein Sensormodell des jeweiligen Sensorherstellers genutzt, so kann auf eine Einstellung der Sensorparameter verzichtet werden. Sind Sensormodelle seitens der Sensorhersteller zu dem Zeitpunkt des Sensorsetup-Entwurfs nicht verfügbar, können durch Einstellung der Sensorparameter eigene Sensormodelle erstellt und zusätzlich neue Sensoreigenschaften getestet werden, die in verfügbaren Sensoren noch nicht realisiert sind, um so auch Anforderungen an zukünftige Sensortechnologien ableiten zu können.
  • Das Verfahren wird im Anschluss an den Schritt E2) in dem Schritt A2) iterativ fortgesetzt. Abhängig von der Evaluierung wird bzw. werden wenigstens einer der Sensorparameter und/oder einer der Konfigurationsparameter variiert. Das Verfahren wird solange iteriert, bis die Evaluierung des jeweiligen Sensorsystems einen Hochpunkt erreicht oder sämtliche Sensorparameter des Satzes variiert wurden. Ein solcher iterativer Prozess wird im Folgenden auch als „Closed-loop Simulation“ bezeichnet. Durch Rückkopplung der Evaluierung, insbesondere KPIs, können die dem Sensormodell bzw. den virtuellen Sensordaten zugrundeliegenden Einflussgrößen und damit auch das entsprechende Sensorsystem variiert und optimiert werden. Beispielhaft kann der vorgegebene Satz an Sensorparametern in jeder Iteration geändert werden, bis alle möglichen Kombinationen variiert wurden. Alternativ können auch Modellbildungsstrategien aus dem sogenannten Bereich „Design of Experiments“, DoE, zum Einsatz kommen. Sobald erkennbar wird, dass die Variation einer Einflussgröße nach mehreren Durchläufen nicht zu einer Änderung der Evaluierung führt, wird zum nächsten Einflussgröße übergegangen, so dass nur relevante Einflussgrößen in Richtung des gesuchten Optimums variiert werden müssen.
  • In einer vorteilhaften Ausgestaltung gemäß dem zweiten Aspekt dienen die in dem Schritt C2) erzeugten mehreren verschiedenen virtuellen Sensorsysteme als initiale Population eines genetischen Algorithmus. Die mehreren verschiedenen virtuellen Sensorsysteme bestehen dabei jeweils aus einem oder mehreren Konfigurationsbereichen. Als Konfigurationsbereich wird hier und im Folgenden ein austauschbarer Teil eines virtuellen Sensorsystems verstanden, welcher durch einen Teil eines anderen virtuellen Sensorsystems ersetzt werden kann. Beispielhaft umfasst ein solcher Teil einen oder mehrere spezifische Umfeldsensoren samt entsprechender Konfiguration wie Position, Ausrichtung und Typ.
  • Der genetische Algorithmus umfasst folgende Schritte: In einem Schritt A3) wird für jedes der mehreren verschiedenen virtuellen Sensorsysteme abhängig von einer Anzahl von Umfeldsensoren des jeweiligen Sensorsystems sowie eines jeweiligen Sensortyps der Umfeldsensoren des jeweiligen Sensorsystems ein Kostenkennwert des jeweiligen Sensorsystems ermittelt. Als Kostenkennwert kommt neben den Anschaffungs- bzw. Herstellungskosten des jeweiligen Umfeldsensors auch ein Aufwand, welcher mit einem Einbau des entsprechenden Umfeldsensors in das Fahrzeug verbunden ist, in Betracht.
  • In einem Schritt B3) wird abhängig von der Evaluierung des jeweiligen Sensorsystems ein Nutzenkennwert des jeweiligen Sensorsystems ermittelt. Der Nutzenkennwert kann beispielsweise aus den KPIs abgeleitet werden. Zusätzlich können beispielsweise vorgenannte wichtige Bereiche berücksichtigt werden.
  • In einem Schritt C3) wird ein Verhältnis aus dem Nutzenkennwert zu dem Kostenkennwert ermittelt und geprüft, ob das Verhältnis einen vorgegebenen Schwellenwert überschreitet. Im Falle, dass der vorgegebene Schwellenwert überschritten wird, wird das entsprechende Sensorsystem ausgegeben oder gespeichert.
  • Anderenfalls werden in einem Schritt D3) abhängig von dem jeweiligen Verhältnis unterschiedliche Konfigurationsbereiche wenigstens zwei der Sensorsysteme ausgewählt. Dies kann auch als „Select“ Schritt des genetischen Algorithmus bezeichnet werden. Insbesondere werden hierbei die Konfigurationsbereiche der zwei bis drei Sensorsysteme mit dem besten, ermittelten Verhältnis gewählt.
  • In einem Schritt E3) werden die ausgewählten Konfigurationsbereiche in zufälliger Weise zu mehreren virtuellen Sensorsystemen als neue Population des genetischen Algorithmus zusammengesetzt und der genetische Algorithmus mit der neuen Population in dem Schritt A3) iterativ fortgesetzt. Dies kann auch als „Crossover“ Schritt des genetischen Algorithmus bezeichnet werden. Den derart neu erstellten Sensorsystemen können nun in dem Schritt A3) wiederum Kostenkennwerte zugeordnet werden, bis das ermittelte Verhältnis eines der Sensorsysteme in dem Schritt C3) den vorgegebenen Schwellenwert überschreitet. In vorteilhafter Weise kann so eine Optimierung der Einflussgrößen der Umfeldsensoren hinsichtlich der wichtigen Bereiche umgesetzt werden, und insbesondere analysiert werden, wie die Kosten eines Sensorsystems im Verhältnis zu dessen Nutzen stehen.
  • In einer vorteilhaften Ausgestaltung gemäß dem zweiten Aspekt wird nach dem Schritt D3) in einem Schritt F3) eine zufällige Variation wenigstens eines der ausgewählten Konfigurationsbereiche als Mutation in dem genetischen Algorithmus vorgenommen. In vorteilhafter Weise kann so eine Diversität der erzeugten Sensorsysteme erhöht werden.
  • In einer vorteilhaften Ausgestaltung gemäß dem zweiten Aspekt wird das wenigstens eine Umfeldmodell in dem Schritt B2) abhängig von einem vorgegebenen Satz an Szenarioparametern ermittelt. Die Szenarioparameter sind repräsentativ für ein vorgegebenes Fahrmanöver des virtuellen Fahrzeugs. Als Szenarioparameter sind beispielhaft eine Geschwindigkeit des virtuellen Fahrzeugs oder ein Kurvenradius der virtuell befahrenen Strecke zu nennen.
  • Das Verfahren wird im Anschluss an den Schritt E2) in dem Schritt B2) iterativ fortgesetzt. Abhängig von der Evaluierung wird wenigstens einer der Szenarioparameter variiert. Das Verfahren wird solange iteriert, bis die Evaluierung des jeweiligen Sensorsystems einen Tiefpunkt erreicht oder sämtliche Szenarioparameter des Satzes variiert wurden. Ein solcher iterativer Prozess wird wie bereits erläutert auch als „Closed-loop Simulation“ bezeichnet. Durch Rückkopplung der Evaluierung, insbesondere KPIs, können die dem Umfeldmodell zugrundeliegenden Einflussgrößen und damit auch das entsprechende Sensorsystem variiert und optimiert werden. Beispielhaft kann der vorgegebene Satz an Szenarioparametern in jeder Iteration geändert werden, bis alle möglichen Kombinationen variiert wurden. Alternativ können auch Modellbildungsstrategien aus dem sogenannten Bereich „Design of Experiments“, DoE, zum Einsatz kommen. Sobald erkennbar wird, dass die Variation einer Einflussgröße nach mehreren Durchläufen nicht zu einer Änderung der Evaluierung führt, wird zum nächsten Einflussgröße übergegangen, so dass nur relevante Einflussgrößen in Richtung des gesuchten Optimums variiert werden müssen. Durch Variieren der Szenarioparameter, bis die Evaluierung, insbesondere die entsprechenden KPIs, einen Tiefpunkt erreicht bzw. erreichen, kann eine negative Optimierung umgesetzt werden, durch die automatisiert ein Worst-Case-Szenario einschließlich der Leistungsfähigkeit des jeweiligen Sensorsystems hierin bestimmt werden kann.
  • Gemäß einem dritten Aspekt betrifft die Erfindung eine Vorrichtung zur Simulation eines Sensorsystems für ein Fahrzeug. Das Sensorsystem weist einen oder mehrere Umfeldsensoren auf. Die Vorrichtung ist eingerichtet, das Verfahren gemäß dem ersten Aspekt auszuführen. Bei der Vorrichtung handelt es sich insbesondere um eine Recheneinheit wie einen Computer.
  • Gemäß einem vierten Aspekt betrifft die Erfindung eine Vorrichtung zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug. Die Vorrichtung ist eingerichtet, das Verfahren gemäß dem zweiten Aspekt auszuführen. Bei der Vorrichtung handelt es sich insbesondere um eine Recheneinheit wie einen Computer.
  • Gemäß einem fünften Aspekt betrifft die Erfindung ein Computerprogramm umfassend Befehle, die bei der Ausführung des Computerprogramms durch einen Computer diesen veranlassen, das Verfahren gemäß dem ersten oder zweiten Aspekt auszuführen.
  • Gemäß einem sechsten Aspekt betrifft die Erfindung ein computerlesbares Speichermedium, auf dem das Computerprogramm gemäß dem fünften Aspekt gespeichert ist.
  • Ausführungsbeispiele der Erfindung sind im Folgenden anhand der schematischen Zeichnungen näher erläutert.
  • Es zeigen:
    • 1 ein Fahrzeug mit einem Sensorsystem zur Umfelddetektion,
    • 2 ein Schema zur Bewertung eines Sensorsystems,
    • 3 eine Datenverarbeitungskette zur Umfelddetektion im automatisierten Fahrzeug,
    • 4 ein weiteres Schema zur Bewertung eines Sensorsystems,
    • 5 eine schematische Darstellung eines Verfahrens zur Simulation eines Sensorsystems,
    • 6 beispielhafter Vergleich statistischer und globaler Bewertungskennzahlen,
    • 7 beispielhafte Illustration globaler Bewertungskennzahlen,
    • 8 eine schematische Darstellung eines weiteren Verfahrens zur Simulation eines Sensorsystems,
    • 9 beispielhaftes Schema zur Optimierung eines Sensorsystems mittels Rückkopplung,
    • 10 eine beispielhafte gewichtete Evaluierung anhand wichtiger Bereiche,
    • 11 ein Ablaufdiagramm eines beispielhaften Verfahrens zur Erzeugung eines Umfeldmodells,
    • 12 ein Ablaufdiagramm eines beispielhaften Verfahrens zur Simulation eines Sensorsystems für ein Fahrzeug, und
    • 13 ein Ablaufdiagramm eines beispielhaften Verfahrens zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug.
  • Elemente gleicher Konstruktion oder Funktion sind figurenübergreifend mit den gleichen Bezugszeichen versehen.
  • Anhand 1 ist Fahrzeug 100 mit einem Sensorsystem 10 zur Umfelddetektion dargestellt. Das Sensorsystem 10 weist eine Vielzahl von Umfeldsensoren 1-n auf, die jeweils eingerichtet sind, Objekte 30, 31 in der Umgebung des Fahrzeugs 100 zu erfassen. Das Sensorsystem 10 weist dabei einen spezifischen Aufbau auf, gemäß dem sich eine Anzahl sowie jeweilige Typen und Verbaupositionen und -ausrichtungen der einzelnen Umfeldsensoren 1-n ergeben. Dieser Aufbau wird im Folgenden auch als „Setup“ oder „Sensorsetup“ bezeichnet. Beispielhaft handelt es sich bei dem Umfeldsensor 1 im dargestellten Setup um eine Kamera, die Objekte 30, 31 im Sichtfeld erfasst und ausgibt. Bei den Objekten 30, 31 handelt es sich insbesondere um (dynamische) Objekte wie andere Verkehrsteilnehmer. Bei dem Umfeldsensor 2 handelt es sich beispielhaft um einen Radar-Sensor. Der Umfeldsensor 3 ist beispielhaft als Lidar-Sensor ausgebildet. Bei dem Umfeldsensor n handelt es sich beispielhaft um einen Ultraschallsensor. Dem Sensorsystem 10 kann eine Steuereinheit 11 zugeordnet sein, die signaltechnisch mit den Umfeldsensoren 1-n gekoppelt und zur Sensordatenfusion SF eingerichtet ist.
  • Mit steigendem Automatisierungsgrad von Fahrzeugen 100 wachsen auch die Anforderungen an die Umfeldsensoren 1-n, um eine Umgebung des Fahrzeugs 100 frühzeitig, sicher und präzise zu erkennen. Bei Ausarbeitung zukünftiger Fahrzeugkonzepte spielt eine Konfiguration des Sensorsetups daher eine zentrale Rolle. Es gibt zahlreiche Umfeldsensoren 1-n auf dem Markt und es kommen stets neue Sensortechnologien hinzu. Automobilhersteller stehen jedoch vor der Herausforderung, eine geeignete Sensoranordnung zu definieren, welche alle (Sicherheits-)Anforderungen erfüllt: Neben einer Einzelsensor-Performance und einer Sichtfeldabdeckung (360°, Nah- und Fernbereich) sollten weitere Faktoren wie Setup-Gesamtkosten, Fahrzeugintegration und Design berücksichtigt werden. Darüber hinaus sollten das Sensorsetup redundant aufgebaut und störende Umwelteinflüsse (Wetter- und Lichtbedingungen, Verschmutzung) berücksichtigt werden. Daraus resultiert eine hohe Komplexität im Sinne möglicher Sensorsetup-Konfigurationen. Bislang existiert keine standardisierte Bewertungsmethode, um verschiedene Setup-Varianten einheitlich zu beurteilen und anhand von Kosten-Nutzen-Analysen ein optimales Sensorsetup für einen jeweiligen Fahrzeugtyp festzulegen. In einem frühen Entwicklungsstadium ist es praktisch nicht möglich, jede denkbare Sensorkombination mit Testfahrten zu untersuchen.
  • In 2 ist eine Sensorsetup-Bewertung skizziert. Die Bewertung der einzelnen Sensoren 1-n basiert zum einen auf den von den jeweiligen Sensorherstellern H bereitgestellten Spezifikationen im Datenblatt D und gegebenenfalls zur Verfügung gestellten Mess-protokollen M. Diese Informationen über den Sensor 1-n stellen einen ersten Anhaltspunkt dar, um eine Vorauswahl zu treffen. Da die Angaben jedoch herstellerabhängig unter unterschiedlichen sowie idealen Messbedingungen zustande kamen, ist zum anderen eine einheitliche Überprüfung dieser Werte seitens der Automobilhersteller O üblich. Dazu wird der jeweilige Sensor 1-n in seinem derzeitigen Entwicklungsstand 1*-n* (z.T. Prototypenstatus) für Testzwecke, meist im Rahmen von Proof-of-Concepts (POCs), ausgeliehen und eigene Messprotokolle M* angefertigt, um die Angaben im Datenblatt zu überprüfen und zu ergänzen. Dabei kann eine Liste an „Corner Cases“ zum Tragen kommen, um systematisch die Schlüsselkriterien zu testen. Anhand der gewonnenen Erkenntnisse können die Sensoren 1-n, 1*-n* charakterisiert (Charakterisierung C des Einzelsensors 1-n, 1*-n*) und bewertet (Sensor-Bewertung B) werden.
  • Das Sensorverhalten SV im Verbund sowie die Gesamtsetup-Performance werden durch Testfahrten T ermittelt. Typischerweise finden die Testfahrten T jedoch zu einem späteren Zeitpunkt der Fahrzeug-entwicklung statt (zwecks Feinjustage/Optimierung, wenn das finale Setup schon feststeht), da hierzu die Gesamtwirkkette (vgl. 3 - Umfeldsensoren 1-n erfassen das Umfeld des Fahrzeugs 100. Nach einem Vorverarbeitungsschritt P von durch die Umfeldsensoren 1-n ausgegebenen Umfelddaten erfolgt eine Sensordatenfusion SF, anhand der ein Umgebungsmodell U ermittelt werden kann, das repräsentativ ist für Objekte im Umfeld des Fahrzeugs 100 aus Sicht des Sensorsystems 10. Das Umgebungsmodell U kann daraufhin FAS-Funktionen F bereitgestellt werden, die zur Umsetzung der Funktion Aktuatoren A des Fahrzeugs 100 ansteuern) benötigt wird. Da die Entwicklung der Erkennungsfunktions- und Fusionsalgorithmen auf dem jeweiligen Sensorsetup aufbauen, stehen diese zum Zeitpunkt der Sensorauswahl und Setup-Auslegung noch nicht zur Verfügung. Aufgrund des hohen Zeit- und Kostenfaktors von Testfahrten und deren Datenauswertung sowie des Nichtvorhandenseins der benötigten Gesamtwirkkette zum Zeitpunkt des frühen Entwicklungsstadiums können Testfahrten T nicht zur Bewertung beliebig vieler verschiedener Setup-Varianten herangezogen werden. Testfahrten können lediglich im Rahmen der Einzelsensorbewertung eine Erweiterung der Corner Case Liste darstellen, um das dynamische Verhalten des Sensors besser einschätzen zu können.
  • Bei der Sensor-Bewertung B und Sensor-Auswahl kann ein Benchmark einzelner Sensoren gleichen Typs (über eine Charakterisierung C des Einzelsensors), ein Benchmark verschiedener Sensortechnologien und Sensorsetup-Konfigurationen (Einbauposition), eine Kosten-Nutzen-Analyse, eine Auswertung einer Sensorperformance in der Datenverarbeitungskette bzw. im Gesamtsystem sowie eine Auswahl nach Redundanz erfolgen.
  • Für die Bewertung verschiedener Sensorsetup-Konfigurationen zum Zeitpunkt der Fahrzeug-Konzepterstellung existiert aktuell kein methodisches Vorgehen. Bislang waren die Setups für die Fahrerassistenzsysteme (FAS) mit bspw. einer Kamera, einem Radar und vier Ultraschallsensoren jeweils vorne und hinten am Fahrzeug 10 noch überschaubar. Bei der Auslegung des Setups werden Sichtkegel der Sensoren (Field of Views, FOVs) in Seitenansichten und der Draufsicht der Fahrzeugsilhouette skizziert und so angeordnet und ausgerichtet, dass der vom FAS zu überblickende Sichtbereich möglichst gut abgedeckt wird. Mit steigendem Automatisierungsgrad wachsen jedoch die Anforderungen an das Setup, da deutlich größere Bereiche um das Fahrzeug 100 erfasst werden müssen. Eine Fahrzeug-Skizze mit eingezeichneten FOVs kann dabei schnell unübersichtlich werden und verliert hinsichtlich der Setup-Bewertung an Aussagekraft. Auch eine 3D-Ansicht der FOVs um das Fahrzeug 100 innerhalb einer Computer-Aided-Design(CAD)-Umgebung (wie CATIA) bietet lediglich einen visuellen Eindruck. Zur Bewertung und Vergleichbarkeit verschiedener Setup-Varianten bedarf es daher einer simulationsbasierten Methodik, die anhand von Bewertungskriterien und Key Performance Indicators (KPIs) neben qualitativen auch quantitative Aussagen erlaubt. Zum aktuellen Stand fehlt es jedoch an solch einer Simulationsinfrastruktur. Bestehende Simulationstools adressieren die Entwicklung und Optimierung von Erkennungs- und Fusionsalgorithmen sowie der FAS, nicht jedoch die Bewertung der Sensorsetup-Konfiguration.
  • Ein Ziel ist es daher, ein konsistentes und objektives Bewertungs- und Auswahlverfahren für Sensorsetups zu schaffen. Der hohen Komplexität, die sich aus steigenden (Sicherheits-)Anforderungen an das Setup, der Vielzahl an möglichen Setup-Variationen und der Diversität für verschiedene Fahrzeugtypen / Derivate ergibt, gilt es entgegenzutreten. Es soll eine Alternative geschaffen werden zu Setup-Betrachtungen anhand von Skizzen/3D-Ansichten der Sensor-Sichtbereiche, die mit zunehmender Sensoranzahl unübersichtlich werden und keine aussagekräftige Bewertung bezüglich der Erkennungs-Performance erlauben. Derartige Setup-Betrachtungen diskutieren die Sensor-Anordnung und Integration am jeweiligen Fahrzeugtyp ohne quantitative Bewertung und Vergleichbarkeit verschiedener Lösungsmöglichkeiten. Auch eine ledigliche Betrachtung des Fahrzeugs 100 ohne Berücksichtigung der Umgebungssituationen/Fahrszenarien soll vermieden werden. Insbesondere sollen zeit- und kostenintensive Testfahrten und anschließende Datenaufbereitung /-Auswertung reduziert werden, auch im Hinblick darauf, dass zur Bewertung der Setup-Performance im Rahmen von Testfahrten bereits Erkennungs- und Fusionsalgorithmen zur Datenaufbereitung benötigt werden, die zum Zeitpunkt der Setup-Auslegung noch nicht existieren. Ähnlich hierzu sind auch neuartige Sensoren zu einem frühen Entwicklungszeitpunkt oftmals noch nicht (sinnvoll) einsatzbereit für Testfahrten (Prototypen). Darüber hinaus ist es wünschenswert, einige wichtige Fahrszenarien und Fahrmanöver, die durch Testfahrten nicht nachbildbar sind, z.B. Gefahrensituationen, zu berücksichtigen. Das Risiko, dass einige Setup-Konfigurationen aufgrund des Zeit- und Kostenaufwands für Testfahrten nicht näher untersucht werden, soll reduziert werden. Schließlich gilt es, eine Simulationsinfrastruktur zur Sensorsetup-Bewertung zu schaffen, die die Sensorsetup-Auslegung adressiert statt lediglich Entwicklung und Optimierung der nachfolgenden Datenverarbeitung.
  • Für die Auslegung und Bewertung von Sensorsetups und neuen Sensortechnologien wird daher ein dreistufiges Verfahren vorgeschlagen (siehe 4). Zwischen der Bewertung der Einzelsensoren im Rahmen des Benchmarkings (Stufe I) und Testfahrten zur Bewertung der Setup-Performance im Gesamtsystem unter realen Bedingungen (Stufe III) soll als Zwischenschritt (Stufe II) eine simulationsbasierte Bewertung des Sensorsetups erfolgen. Schritt I und III dieses dreistufigen Verfahrens entsprechen den obigen Ausführungen zu 2 und 3. In dem Schritt I sollen Sensor-Spezifikationen identifiziert werden. Hierbei erfolgt eine Bestimmung der Performance eines einzelnen Sensors anhand von Datenblatt, Messprotokollen und Corner Case Tests. Zwischenstufe II stellt ein neues Entwicklungswerkzeug dar, mit dessen Hilfe zeit- und kosteneffizient verschiedene Setup-Varianten/Sensor-Kombinationen konfiguriert, getestet und bewertet werden sollen, um die Sensorsetup-Performance zu diesem frühen Zeitpunkt in qualitativer und quantitativer Weise fundiert zu beschreiben. Hierbei soll eine Simulation des Sensorsetups erfolgen, wobei eine Konfiguration des Sensorsetups und eine Sensorparametereinstellung anhand gewonnener Informationen aus Schritt I, eine Simulation der Setup-Performance und eine Analyse von Wirkzusammenhängen durchgeführt werden. In dem Schritt III können schließlich Testfahrten vorgenommen werden, um die Sensorsetup-Performance im Gesamtsystem unter realen Umgebungsbedingungen zu validieren. Dies erfolgt bevorzugt nur für die Setup-Varianten, die innerhalb der Simulation in Schritt II vielversprechende Ergebnisse gezeigt haben. Schritt III dient damit vordergründig der Optimierung und Feinjustage des Ziel-Setups.
  • Die im Schritt I anhand von Datenblättern, Messprotokollen und Corner Case Tests ermittelten Sensoreigenschaften dienen als Input für die Parameter-Einstellungen generischer Sensormodelle / virtueller Sensoren der Simulationsinfrastruktur im Schritt II. In dieser Konzeptphase liegen typischerweise noch keine Sensormodelle seitens der Sensorhersteller vor, welche in den Simulationsworkflow eingebaut werden könnten. Daher ist eine Verwendung generischer Sensormodelle und ein Befüllen von Stellparametern nach den Erkenntnissen aus Testmessungen/Datenblattangaben angezeigt. Innerhalb der Simulationsumgebung können verschiedene Sensorsetups gestaltet und die jeweiligen Sensoreigenschaften individuell eingestellt werden. Anschließend kann für beliebige virtuelle Testfahrten die jeweilige Sensorsetup-Performance ermittelt und in Form von Bewertungskennzahlen übersichtlich dargestellt werden. Auf diese Weise wird eine schnelle, systematische und objektive Analyse der verschiedenen Setup-Varianten möglich, was eine fundierte Entscheidungsgrundlage zur Festlegung auf das finale Setup bietet. Im Schritt III werden nur noch die wenigen Setups, die in der Simulation vielversprechende Ergebnisse gezeigt haben oder auch nur das auf dieser Basis final festgelegte Setup, in realen Testfahrten evaluiert, um die Setup-Performance im Fahrzeug-Gesamtsystem und unter realen Umgebungsbedingungen zu erfassen.
  • Anhand der 5 und 8 ist jeweils ein detaillierter Simulationsablauf skizziert, der die gesamte Prozesskette von der Datenerfassung (Ground Truth und Sensordaten), der Datenverarbeitung (Datenfusion), der Datenauswertung (Metriken) bis hin zur Datenanalyse (KPIs, Kosten-Nutzen-Abwägung) zur Ableitung von Wissen (Setup-Performance) abdeckt.
  • Hierbei ist vorgesehen, dass der folgende Simulationsworkflow auf „High-Level-Ebene“ abläuft, d.h. die Ground Truth Daten UD und die simulierten Sensordaten SD liegen in Form von Objektlisten vor. Prinzipiell wäre es auch denkbar, den Simulationsworkflow mit physikalisch basierten Sensormodellen und Umgebungssimulation aufzusetzen. Allerdings fehlt es für die Erstellung und Parametrierung von physikalischen Sensormodellen zumeist an tiefgründigem Wissen über die Funktionsweise der zu bewertenden Sensoren 1-n, das den Sensorherstellern H vorenthalten ist. Weiterhin fehlt es für die Performance-Bewertung an Erkennungsfunktionen, die aus den „Sensor-Rohdaten“ für die Fusion verwertbare Daten liefert (klassifizierte Objekte, wie bei Objektlisten-Format). Schließlich fehlt es ebenso an einem etablierten Umgebungssimulationstool, das die nötigen Parameter wie Materialeigenschaften in ausreichender Güte liefert.
  • Die Simulation kann in zwei verschiedenen Modi, einem Open-Loop Modus sowie einem Closed-Loop Modus genutzt werden. In einer ersten Ausführungsvariante wird die Simulation im Open-Loop Modus betrieben (5).
  • Der Simulationsworkflow ist in zwei Teile gegliedert: Im ersten Teil werden mit einer Umgebungssimulation US virtuelle Fahrszenarien SZ (Fahrzeug-Umgebung, Straßenverlauf, Verkehrsteilnehmer und das Fahrmanöver des Ego-Fahrzeugs) gestaltet (Fahrszenarien-Generierung SG), die der Setup-Bewertung zugrunde gelegt werden sollen. Entgegen dem Vorgehen bei der Funktionsabsicherung / Validierung eines Gesamtfahrzeugs kurz vor Produktionsstart, bei dem mehrere hunderte oder tausende verschiedene Szenarien und Millionen Kilometer simulativ abgefahren werden, soll bei der Bewertung der Setup-Konfiguration in der frühen Konzeptphase eine begrenzte Anzahl an ausgewählten Szenarien zum Einsatz kommen, welche gezielt die für die Setup-Bewertung relevanten Punkte adressieren (z.B. Corner Cases).
  • Die in dem ersten Teil generierten virtuellen Fahrszenarien SZ dienen als Ground Truth eines Umfeldmodells UM mit Umfelddaten UD als Ground Truth Daten. Diese simulierten Ground Truth Daten der Szenarios werden an den zweiten Teil des Simulationsworkflows übergeben. Der zweite Teil adressiert die Sensorsimulation SS und den Analyse-Part AP. Der zweite Teil läuft beispielhaft innerhalb der integrierten Entwicklungsumgebung Microsoft Visual Studio. Die eingehenden Ground Truth Daten UD aus der vorherigen Umgebungssimulation US können entweder im Live-Modus L verarbeitet oder in einem Aufzeichnungs-Modus R aufgezeichnet und später abgerufen werden. Letzteres ermöglicht die persistente Speicherung vieler Szenarien in einen Szenarienkatalog K. Die gespeicherten Szenarien können dann für die Setup-Bewertung wieder abgespielt werden; der erste Workflow-Teil (virtuelle Umgebungssimulation US) ist für das Arbeiten mit der Sensorkonfiguration- und Bewertungssimulation im Open-Loop-Modus dann nicht mehr notwendig. Der zweite Teil ist somit ein eigenständiges Framework, das zu einem flexiblen Arbeitsmittel führt.
  • Der Sensorsimulations- SS und Analyse-Part AP umfasst drei Module:
    • Ein erstes Modul betrifft die Simulation der Sensordaten SD aller Sensoren 1-n eines Setups 10: Hier wird das virtuelle Sensorsetup konfiguriert und Sensormodelle SM der einzelnen Sensoren 1-n erstellt. Über eine grafische Benutzeroberfläche (GUI) können zudem Eigenschaften SE der einzelnen Sensoren des Setups (entsprechend der gewonnenen Informationen aus Schritt I des Drei-Stufen-Modells in 4) eingestellt werden. Insbesondere können hierbei sowohl die im allgemeinen Teil der Beschreibung genannten Sensorparameter als auch die im allgemeinen Teil der Beschreibung genannten Konfigurationsparameter als Eigenschaften SE variiert werden. Bei den Sensormodellen SM handelt es sich um generische probabilistische Sensormodelle, die für jeden virtuellen Sensor des Setups entsprechend der jeweiligen sensorspezifischen Werte SK (u.a. Sensorposition am Fahrzeug, Messgenauigkeit, Detektionswahrscheinlichkeit) eingestellt werden, um den realen Sensor 1-n möglichst präzise in der Simulation zu repräsentieren. Bei Bedarf ist es jedoch auch möglich, über ein Software Development Kit (SDK) / ProgrammCode neue Sensormodelle SM hinzuzufügen oder die bestehenden Sensormodelle SM anzupassen, um das Tool für neuartige Sensortechnologien zu erweitern. An dieser Stelle besteht die Möglichkeit, die Parameter der Sensorsetup-Konfiguration über ein Optimierungstool automatisiert zu optimieren wie anhand 8 und dem Closed-Loop Modus geschildert. Zusammengefasst werden in dem ersten Modul die Ground Truth Daten UD entsprechend den Einstellungen der probabilistischen Sensormodelle SM modifiziert und als simulierte Sensordaten SD ausgegeben.
  • In einem zweiten Modul werden die simulierten Sensordaten SD in einem Datenfusionsmodul SF, das z.B. auf erweiterten Kalman-Filtern basiert, fusioniert und in das nachfolgende Umgebungsmodell U gespeist. Die Datenfusion bzw. die zugrunde liegende Algorithmik wie bspw. die Kalman Filter können beim Fusionieren der verschiedenen Sensorinformationen denjenigen Sensoren höheres Gewicht verleihen, die auch eine höhere Messgenauigkeit aufweisen. Diese Information über die jeweilige Sensormessgenauigkeit kann anhand der Einstellungen in den Sensormodellen entnommen werden.
  • In einem dritten Modul werden anschließend die simulierten und fusionierten Sensordaten FD (Tracks) mit den Ground Truth (GT) Daten UD anhand von diversen Metriken verglichen (Evaluierung E). Dieser Part gibt für das getestete Setup einen Ergebnis-Report P aus, das die Bewertungskennzahlen (KPIs) für jedes Szenario auflistet.
  • Die KPIs können in zwei Typen untergliedert werden:
    1. 1. Statistische KPIs, beispielsweise die folgenden Metriken:
      • - Hausdorff Metrik: größter Abstand zwischen einem Track und dem zugehörigen GT-Wert (Ausreißer).
      • - Optimal SubPattern Assignment (OSPA): Zwischen GT und Tracks wird ein globales Optimum hinsichtlich Übereinstimmung (subpattern) gesucht und der gemittelte Abstand zwischen Tracks und den zugehörigen GT-Werten ermittelt. Gibt es mehr GT-Werte als Tracks (oder umgekehrt), fließt dies negativ in die Metrik ein, um False-Positives / False Negatives zu berücksichtigen.
      • - Position/Velocity/Acceleration Error: Abstand zwischen Tracks und GT-Werten (in Metern). Gibt die Genauigkeit der Sensordaten an.
      • - Normalized Estimation Error Squared (NEES): Abstand zwischen Tracks und GT-Werten in Einheiten der Unsicherheit. Diese Metrik kann auch ein Indikator dafür sein, ob die Unsicherheit (Sensor-Messfehler, Prozessrauschen) als zu groß oder zu klein angenommen wurde (im Sensormodell).
      • - Multiple Object Tracker Accuracy (MOTA): Abweichungen zwischen Tracks und zugehörigen GT-Werten aufsummiert und geteilt durch die Anzahl aller Zuordnungen (gemittelter Fehler).
      • - Multiple Object Tracker Performance (MOTP): False-Positives, False-Negatives und Falsch-Zuordnungen aufsummiert und geteilt durch die Objektanzahl.
      • - Detektionsrate: Anzahl der Tracks geteilt durch die Anzahl der GTs (innerhalb von Sensor-FOVs).
      • - Falsch-Alarm-Rate: Anzahl an Tracks, die keinem GT-Wert zugeordnet werden konnten, geteilt durch die Gesamtanzahl an Zuordnungen.
    2. 2. Globale KPIs (zur Differenzierung verschiedener Setup-Konfigurationen), beispielsweise die folgenden Metriken:
      • - Objekt-Detektionszeit: Wann wurde ein Objekt vom Sensorsystem erkannt (Track angelegt); Welcher Abstand liegt hier zum Objekt vor? Ist der Bremsweg (bei gegebener Geschwindigkeit) höher als der vorhandene Abstand zum Objekt, sodass es zu einem Unfall kommen würde oder reicht die Zeit aus, um noch bremsen zu können?
      • - Erfassungsrate: Anzahl der Tracks geteilt durch die Anzahl aller GTs (unabhängig davon, ob die GT-Werte innerhalb eines Sensor-FOVs liegen oder nicht).
      • - Sensor-aufgelöste Erfassungsrate: Übersicht, welcher Sensor zu welchem Track beigetragen hat, um Redundanz aufzuzeigen.
  • Anhand dieser Ergebnisse kann die Performance der getesteten Sensorsetups quantitativ und objektiv bewertet werden. Die KPI-Berichte P sowie anschließend mögliche Kosten-Nutzen-Analysen K/N bieten eine fundierte Entscheidungsbasis zur Festlegung des optimalen Sensorsetups, welches später mittels Testfahrten T tiefergehend evaluiert und optimiert werden kann.
  • Anhand der 6 und 7 sind zum besseren Verständnis verschiedene KPIs beispielhaft dargestellt.
  • 6 zeigt links eine erstes Setup, mittig und recht jeweils ein zweites Setup. Würde man nur „Statistische KPIs“ betrachten, die sich nur auf die Genauigkeit zwischen Tracks und GT-Werten konzentrieren, wäre keine Aussage zur Gesamtsetup-Performance möglich. Im ersten Setup könnten die Statistischen KPIs mittelmäßig ausfallen, weil manche Sensoren eine geringere Genauigkeit besitzen. Das zweite Setup dagegen könnte sehr gute statistische KPIs aufweisen aufgrund hochwertigerer Sensoren. Allerdings deckt das zweite Setup nur einen kleinen Bereich um das Fahrzeug 100 ab. Ohne „Globale KPIs“ ist dazu aber keine Aussage möglich (Mitte). Um die „Umfeld-Abdeckung“ und damit Unterschiede zwischen Setups zu berücksichtigen, können daher globale KPIs eingesetzt werden, die berücksichtigen, wie viele der GT-Werte vom Setup gar nicht erfasst wurden (Rechts).
  • 7 verdeutlicht ferner verschiedene globale KPIs:
    • Links (1.) ist die Erkennungszeit „Zuerst gesehen“ und/oder Abstandsrate „Bremsweg / Objektabstand“ verschiedener Objekte (Objekt IDs #1-#4) dargestellt. Es wird geprüft, wann ein Objekt zum ersten Mal gesehen wird, insbesondere um eine „Unfallprognose“ unter Berücksichtigung des Bremsweges in die Evaluierung einfließen lassen zu können.
  • Mittig links (2.) sind die Erkennungszeiträume „insgesamt“ dargestellt. Es wird geprüft, welche Objekte bei jedem Zeitschritt erkannt werden.
  • Mittig rechts sind die Erfassungszeiträume „pro Sensor“ dargestellt, und zwar für einen Lidar (3a), einen Radar (3b) und eine Kamera (3c). Es wird geprüft, welche Objekte von welchem Sensor zu jedem Zeitpunkt erfasst werden.
  • Rechts (4.) ist die globale Erkennungsrate dargestellt, um eine Abdeckung der Umgebung zu berücksichtigen.
  • In einer zweiten Ausführungsvariante wird die Simulation im Closed-Loop Modus betrieben (8). Dieser weist einen im Wesentlichen gleichen Open-Loop-Anteil OL wie der anhand 5 beschriebene Open-Loop Modus auf, welcher durch eine Rückkopplung CL ergänzt ist.
  • In einem ersten Ausführungsbeispiel gemäß der zweiten Ausführungsvariante wird die Rückkopplung CL zur Szenario-Variation herangezogen.
  • Mithilfe eines Optimierungstools OP zur Parametrisierung können die einzelnen Variablen eines Szenarios (wie bspw. Geschwindigkeit des Ego-Fahrzeugs oder Kurvenradius) variiert werden, um von einem Szenario mehrere Varianten automatisiert zu generieren. Die Parametrisierung kann die Variablen dabei schrittweise ändern (z.B. Ego-Geschwindigkeit zwischen 30 km/h und 100 km/h in Schritten von 10 km/h). Auf diese Weise kann der Szenarienkatalog K komfortabel aufgebaut und in der späteren Analyse die kritischen Szenarien-Varianten/Grenzfälle aufgedeckt werden.
  • Es ist auch möglich, die KPIs direkt als Feedback an ein Optimierungstool OP für die Szenarien-Erstellung zurückzugeben, und damit eine geschlossene Simulationskette (Closed-Loop) zu schaffen (9). Das Optimierungstool OP variiert die Szenarien-Parameter (wie z.B. die Ego-Geschwindigkeit) solange, bis die KPIs einen Tiefpunkt erreicht haben. Nach Generierung relevanter Szenarien (im Schritt SG) wird ein Szenarien-Set SZ an den Sensorsimulations- SS und Analyse-Part AP übermittelt, der entsprechend KPIs ausgibt. In dem Prüfschritt NO wird geprüft, ob ein jeweiliges Szenario kritischer geworden ist. Im Anschluss werden in einem Änderungsschritt VSP die Szenarien Parameter schrittweise geändert, beispielhaft die Parameter Ego-Geschwindigkeit zwischen 0 km/h und 100 km/h, Objekt- Geschwindigkeit zwischen 0 km/h und 100 km/h und der Kurvenradius zwischen 50 m und 100 m. Die Szenarien-Parameter fließen als neue Subvariante SZ* jedes Szenarios wiederum in die Generierung SG relevanter Szenarien SZ ein. Über diese „negative Optimierung“ kann automatisiert das Worst-Case-Szenario einschließlich der dort ermittelten Setup-Performance bestimmt werden.
  • Die Änderung der Szenarien-Parameter innerhalb des Optimierungstools OP kann dabei durch Kombinatorik oder Optimierungsstrategien erfolgen, indem in jedem Durchlauf ein Parameter geändert und die anderen Parameter unverändert belassen werden, bis alle Kombinationen durchgespielt wurden (Full-Raster), so dass sehr viele Szenarien-Varianten entstehen, die im Nachgang nach ihrer „Kritikalität“ geordnet werden können (Kombinatorik). Alternativ können Modellbildungsstrategien der Optimierungstools aus dem Bereich Design of Experiments, DoE, zum Einsatz kommen. Sobald erkennbar wird, dass das Erhöhen/Erniedrigen eines Parameters nach mehreren Durchläufen nicht zu einer Erhöhung der Kritikalität eines Szenarios (KPI-Verschlechterung) beigetragen hat, wird zum nächsten Parameter übergegangen, so dass nicht alle Kombinationen durchgespielt werden, sondern nur die relevanten in Richtung des gesuchten Optimums (Optimierungsstrategien).
  • In einer optionalen Ausgestaltung können bei der Szenarien-Betrachtung vorab die sogenannten „Regions of Interest“ (ROI) definiert werden. Die ROIs beschreiben die Bereiche um ein Fahrzeug 100, welche von dem zu entwerfendem Setup abgedeckt sein sollten. Die ROIs werden abgeleitet aus diversen Gesetzmäßigkeiten und daraus sich ergebende Zusammenhänge. Anhand 10 ist ein beispielhaftes Schema zur Ableitung der ROIs dargestellt. Zunächst wird eine Situation bzw. ein Szenario gewählt (R1), das für die Sensorik relevant ist, etwa ein rechtzeitiges Erkennen eines Stauendes oder Hindernisses in einer Kurve. Hierauf werden Randbedingungen für Stadt-, Land- oder Autobahn-Segmente als Parameter angewandt, um ROIs zu ermitteln (R2) wie z.B. gesetzliche Bestimmungen (Kurvenradien, Höchstgeschwindigkeit) und/oder Abstand und Relativgeschwindigkeit zwischen Ego-Fahrzeug und Hindernis. Im Betrachtungsfall Stauende in einer Kurve dienen als Parameter, welcher minimale Kurvenradius bei gegebener Geschwindigkeit gesetzlich für Stadt-, Land-, oder Autobahn-Segmente geregelt ist und welcher Bremsweg sich bei der gegebenen Geschwindigkeit ergibt. Darüber hinaus kann aus geometrischen Betrachtungen die nötige Sicht-Reichweite noch vorne und seitlich (FOV) abgeleitet werden und so das „ROI“ definiert werden. Die ROI-Bereiche können sich in ihrer Wichtigkeit (je nach Wahrscheinlichkeit/Häufigkeit eines Unfalls und dem zu erwartenden Ausmaß im Falle eines Unfalls) unterscheiden und daher mit einem kritischen Faktor gewichtet werden (R3), z.B. anhand des Ausmaß oder Folgen bei Eintreten eines Unfalls (Unfallstatistik, Gebrauchssicherheits-Anforderungen). In die Gewichtung fließen beispielhaft die Relativgeschwindigkeit und der Abstand zwischen Ego-Fahrzeug und anderen Verkehrsteilnehmern ein, sowie ein Faktor, der die Kritikalität bei Eintreten eines Zusammenstoßes berücksichtigt (Fußgänger ist kritischer als ein anderes Fahrzeug). Die gewichteten ROI*s können als „Heatmap“ in Form von gewichteten Punkten um das Ego-Fahrzeug angezeigt werden. Anhand dieser Darstellung können konkrete Fahrszenarien designt werden, welche eine fundierte Basis zur Bewertung der Sensorsetup-Performance bereitstellen. Außerdem kann die Heatmap dazu genutzt werden, die Variation der Sensormodell-Eigenschaften und Setupkonfigurationen zu bewerten (Wieviel wurde von den sehr wichtigen Bereichen abgedeckt, wieviel von den mittelwichtigen Bereichen, und wieviel von den weniger wichtigen Bereichen), wie beispielhaft im Folgenden näher erläutert wird.
  • In einem zweiten Ausführungsbeispiel gemäß der zweiten Ausführungsvariante wird die Rückkopplung CL zur Variation der Setup-Konfiguration und Sensoreigenschaften herangezogen.
  • Ähnlich zu der Szenarien-Variation gemäß dem ersten Ausführungsbeispiel können auch die Setup-Konfigurationen sowie die einzelnen Parameter der Sensormodelle SM (Reichweite, Genauigkeit, FOV) durch die KPI-Feedbackschleife automatisiert variiert und im Closed-Loop-Verfahren optimiert werden. Dabei ist denkbar, eine Optimierung hinsichtlich der KPIs oder eine Optimierung hinsichtlich der Heatmap vorzunehmen.
  • Die Optimierung hinsichtlich der KPIs kann analog zu den Szenarien erfolgen. Der Parametersatz wird beispielhaft nach dem Schema gemäß 9 in jedem Durchlauf geändert, bis alle Kombinationen durchgespielt wurden oder nach Modellbildungsstrategien aus dem Bereich Design of Experiments, DoE, ein Optimum gefunden wurde. Die verschiedenen Setup-Varianten können anschließend anhand der KPIs nach ihrer Performance geordnet werden und das optimale Setup leicht ausgewählt werden. Wichtig hierbei ist, dass für dieses Vorgehen ein „allumfassendes Szenario“ erstellt wird, auf welches die KPIs hin optimiert werden. Das zugrundeliegende Szenario sollte demnach alle zu betrachtenden Punkte für die Setup-Bewertung abdecken und auch die Situationsverhältnisse berücksichtigen (wichtige/häufige/relevantere Situationen sollten öfter vorkommen als weniger wichtige Situationen).
  • Bei der Optimierung hinsichtlich der Heatmap kann wie oben beschrieben eine Heatmap erstellt werden, die die Bereiche um das Fahrzeug 100 gewichtet. Diese Information kann im Optimierungsprozess dazu beitragen, dass bei der Setup-Erstellung und Optimierung den wichtigeren Bereichen mehr Bedeutung zugewendet wird. Über eine Kosten-Nutzen-Betrachtung kann analysiert werden, wie die Kosten eines Setups (Anzahl der Sensoren und Kosten der jeweiligen Sensortypen) im Verhältnis zum Nutzen stehen (welche Bereiche werden von diesen Sensoren abgedeckt). Für diesen Optimierungsablauf kann beispielsweise ein genetischer Algorithmus zum Einsatz kommen, der schematisch anhand der 11 dargestellt ist.
  • Mithilfe eines genetischen Algorithmus kann automatisiert ein optimales Setup gefunden werden. Hierzu wird zunächst ein initiales Set an verschiedenen Setups definiert (C2), welches als Startpunkt für die Optimierung dient. Darüber hinaus wird eine Kostenfunktion definiert, die das Setup-Set bewertet (A3, B3). Neben den Kosten kann die Kostenfunktion die KPIs (Feedback aus dem Simulationsworkflow entsprechend Closed Loop Modus) und/oder die Heatmap (gewichtete ROIs G) als Werte zur Optimierung berücksichtigen. Weiterhin wird definiert (G3), ab wann das Setup optimal ist (Verhältnis Kosten zu Umfeld-Abdeckung wichtiger Bereiche), so dass geprüft werden kann, wann der genetische Algorithmus beendet werden kann (C3).
  • Aus dem vorherigen (im ersten Durchlauf aus dem initialen) Setup-Set (Population) werden aus den laut Kostenfunktion besten 2-3 Setups jeweils unterschiedliche Bereiche ausgewählt (D3) („Selection“) und im nächsten Schritt (E3) („Crossover“) in zufälliger Weise zu einem neuen Setup zusammengesetzt. Einige Bereiche können zusätzlich zufällige variiert werden (F3), um die Diversität zu erhöhen („Mutation“).
  • Das neu erstellte Setup wird wieder anhand der Kostenfunktion bewertet und der Kreislauf beginnt erneut, bis nach mehreren Durchläufen das Setup die Anforderungen der Kostenfunktion erfüllt.
  • Anhand der Ablaufdiagramme der 12 und 13 werden im Folgenden Programmschritte bei Simulation eines Sensorsystems 10 (12) bzw. bei Entwurf eines Sensorsystems 10 ( 13) zur Umsetzung obiger Ausführungen näher erläutert. Sämtliche im allgemeinen Teil der Beschreibung offenbarten Merkmale sind auf nachfolgende Programmschritte anwendbar und umgekehrt.
  • Das Programm zur Simulation eines Sensorsystems gemäß 12 wird in einem Schritt A1) gestartet, in dem jeweils ein Sensormodell SM für jeden der Umfeldsensoren 1-n des Sensorsystems 10 bereitgestellt wird. In einem darauffolgenden Schritt B1) wird ein Umfeldmodell UM bereitgestellt. Daraufhin werden in einem Schritt C1) virtuelle Sensordaten SD für jeden der Umfeldsensoren 1-n des Sensorsystems 10 abhängig von dem Umfeldmodell UM und dem jeweiligen Sensormodell SM ermittelt. Schließlich werden die virtuellen Sensordaten SD fusioniert und abhängig von dem Umfeldmodell UM evaluiert. Das Programm gemäß 12 kann insbesondere bei Entwurf eines Sensorsystems 10 in dem Programm gemäß 13 eingesetzt werden.
  • Das Programm gemäß 13 wird in einem Schritt A2) gestartet, in dem ein Sensormodell SM für jeden einer Vielzahl von Umfeldsensoren 1-n erzeugt wird. In einem darauffolgenden Schritt B2) wird wenigstens ein Umfeldmodell UM erzeugt. Daraufhin werden in einem Schritt C2) mehrere verschiedene virtuelle Sensorsystem 10 erzeugt, die jeweils einen oder mehrere der Umfeldsensoren 1-n aufweisen. Im Anschluss wird in einem Schritt D2) jeweils eine Simulation durchgeführt, indem dem Programm gemäß 12 jeweils eines der Sensorsysteme 10 zugrunde gelegt wird und die jeweiligen Sensormodelle der Umfeldsensoren 1-n des entsprechenden Sensorsystems 10 und das wenigstens einen Umfeldmodell UM bereitgestellt werden. Schließlich wird eine Evaluierung des jeweiligen Sensorsystems abhängig von der Simulation ausgegeben oder gespeichert.
  • Die beschriebene simulationsbasierte Bewertung von Sensorsetup-Konfigurationen für die Fahrzeug-Umfelderfassung bietet folgende Vorteile:
    • Es kann eine virtuelle Testsuite für die Auslegung und Bewertung von Sensorsetups für beliebige Fahrszenarien/Fahrmanöver erzielt werden. Hierbei kann ein einheitlicher, reproduzierbarer Bewertungsprozess, der objektive und vergleichbare Ergebnisse in Form von KPIs liefert, erreicht werden. Dies bietet eine zeitsparende und kostengünstige Lösung zur Beurteilung verschiedener Setup-Varianten für die Vorauswahl / Festlegung auf ein finales Setup. Hierdurch wird ein wichtiges Werkzeug in der frühen Phase der Fahrzeugkonzept-Entwicklung angegeben, das Entwickler beim Setup-Entwurf unterstützt und als fundierte Entscheidungsgrundlage dient. Eine Setup-Analyse hinsichtlich verschiedener Sensor-Einbaupositionen, Sensor-Kombinationen und verschiedener Sensoren/Sensortechnologien wird ermöglicht. Darüber hinaus bietet sich die Möglichkeit einer Performance-Analyse für zu untersuchende Setups (Open-Loop Simulation) oder eine automatisierte Setup-Optimierung für gegebene Fahrzeugmodelle (Closed-Loop Simulation). Es wird zur Aufdeckung von Wirkzusammenhängen beim Zusammenspiel verschiedener Sensoren beigetragen. Eine einfache Nutzung der Simulationsumgebung über eine nutzerfreundliche GUI zum Konfigurieren des virtuellen Sensorsetups und schnelles Anpassen/Einstellen der Sensorparameter wird ermöglicht; gleichzeitig besteht aber auch die Möglichkeit, über das Software Development Kit die Sensormodelle in ihrer Funktionsweise im Programmcode anzupassen oder neue Sensormodelle selbst zu erstellen. Dies kann entscheidend für die Evaluation zukünftiger Sensortechnologien sein, die Anpassungen der bisherigen Sensormodelle erfordern. KPIs ermöglichen eine quantitative und objektive Bewertung der verschiedenen Sensorsetups. Es kann eine übersichtliche Ergebnisübersicht über die jeweilige Setup-Performance in diversen Fahrszenarien erzielt werden. Durch eine implementierte, standardisierte OSI-Schnittstelle kann eine hohe Kompatibilität mit diversen Umgebungssimulationstools erreicht werden. Schließlich kann die Simulation als kompaktes und flexibles Simulationswerkzeug (lauffähig auf einem Notebook) implementiert werden.
  • Bezugszeichenliste
  • 100
    Fahrzeug
    10
    Sensorsystem
    30, 31
    Objekt
    1, 1*
    Kamera (Prototyp*)
    2, 2*
    Radar (Prototyp*)
    3, 3*
    Lidar (Prototyp*)
    n, n*
    Ultraschallsensor (Prototyp*)
    11
    Steuereinheit
    SF
    Sensordatenfusion
    H
    Sensorersteller
    D
    Datenblatt
    M, M*
    Messprotokoll (Automobilhersteller*)
    O
    Automobilhersteller
    C
    Sensor-Charakterisierung
    B
    Sensor-Bewertung
    SV
    Sensorverhalten im Verbund
    T
    Testfahrt
    P
    Vorverarbeitungsschritt
    U
    Umgebungsmodell
    F
    FAS-Funktion
    A
    Aktuator
    I-III
    Schritte
    US
    Umgebungssimulation
    SZ, SZ*
    virtuelle Fahrszenarien (optimiert *)
    SG
    Fahrszenarien-Generierung
    UM
    Umfeldmodell
    UD
    Umfelddaten
    SS
    Sensorsimulation
    AP
    Analyse-Part
    L
    Live-Modus
    R
    Aufzeichnungs-Modus
    K
    Szenarienkatalog
    SE
    Sensor-Eigenschaften
    SM, SM*
    Sensormodell (optimiert*)
    SK
    sensorspezifische Werte
    SD
    simulierte Sensordaten
    FD
    Fusionsdaten
    P
    Ergebnis-Report
    K/N
    Kosten-Nutzen-Analyse
    OL
    Open-Loop-Anteil
    CL
    Rückkopplung
    OP
    Optimierungstool
    NO
    Prüfschritt
    VSP
    Änderungsschritt
    R1-R3
    ROI-Ermittlungsschritt
    ROI, ROI*
    wichtiger Bereich (gewichtet*)
    KPI
    Bewertungskennzahl
    A1-G3
    Programmschritte

Claims (15)

  1. Verfahren zur Simulation eines Sensorsystems (10) für ein Fahrzeug (100), wobei das Sensorsystem (10) einen oder mehrere Umfeldsensoren (1, 2, 3, n) aufweist, und das Verfahren folgende Schritte umfasst: A1) Bereitstellen jeweils eines Sensormodells (SM) für jeden der Umfeldsensoren (1-n) des Sensorsystems (10), das jeweils repräsentativ ist für physikalische Eigenschaften des jeweiligen Umfeldsensors (1-n) bei Abbildung eines realen Umfelds des Fahrzeugs (100) mittels realer Messung durch den jeweiligen Umfeldsensor (1-n), B1) Bereitstellen eines Umfeldmodells (UM), das repräsentativ ist für ein virtuelles Umfeld eines virtuellen Fahrzeugs (100), C1) Ermitteln virtueller Sensordaten (SD) für jeden der Umfeldsensoren (1-n) des Sensorsystems (100) abhängig von dem Umfeldmodell (UM) und dem jeweiligen Sensormodell (SM), D1) Evaluieren der virtuellen Sensordaten (SD) abhängig von dem Umfeldmodell (UM).
  2. Verfahren nach Anspruch 1, wobei in dem Schritt A1) zu dem jeweiligen Umfeldsensor (1-n) Konfigurationsparameter bereitgestellt werden, die repräsentativ sind für eine Konfiguration des jeweiligen Umfeldsensors (1-n), und in dem Schritt C1) die virtuellen Sensordaten (SD) des jeweiligen Umfeldsensors (1-n) abhängig von den Konfigurationsparameter ermittelt werden.
  3. Verfahren nach einem der vorstehenden Ansprüche, bei dem wenigstens ein wichtiger Bereich (ROI*) um das virtuelle Fahrzeug (100) vorgegeben wird, und die virtuellen Sensordaten (SD) bezüglich des wichtigen Bereichs (ROI*) in dem Schritt D1) gewichtet werden.
  4. Verfahren nach einem der vorstehenden Ansprüche, wobei in dem Schritt D1) abhängig von den virtuellen Sensordaten (SD) sämtlicher Umfeldsensoren (1-n) eine Sensordatenfusion (SF) ermittelt wird, die abhängig von dem Umfeldmodell (UM) evaluiert wird.
  5. Verfahren nach Anspruch 4, wobei - das Umfeldmodell (UM) Umfelddaten (UD) umfasst, die repräsentativ sind für eine Vielzahl dreidimensionaler Koordinaten virtueller Objektbegrenzungen im virtuellen Umfeld des virtuellen Fahrzeugs (100), - die virtuellen Sensordaten (SD) eines jeweiligen Umfeldsensors (1-n) jeweils repräsentativ sind für eine Vielzahl dreidimensionaler Koordinaten einer virtuellen Messung des jeweiligen Umfeldsensors (1-n) im virtuellen Umfeld des virtuellen Fahrzeugs (100), - die Sensordatenfusion (SF) Fusionsdaten (FD) umfasst, die repräsentativ sind für eine Vielzahl dreidimensionaler Koordinaten virtueller Objektbegrenzungen im virtuellen Umfeld des virtuellen Fahrzeugs (100), und in dem Schritt D1) die Fusionsdaten (FD) mit den Umfelddaten (UD) mittels Bewertungskennzahlen (KPI) evaluiert werden.
  6. Verfahren nach Anspruch 5, wobei in dem Schritt D1) die Fusionsdaten (FD) mit den Umfelddaten (UD) anhand einer oder einer Kombination aus mehreren der folgenden statischen Bewertungskennzahlen (KPI) evaluiert werden: - Hausdorff, - optimal subpattern assignment, OSPA, - Positions-/Geschwindigkeits-/Beschleunigungsfehler, - normalized estimation error squared, NEES, - multiple object tracker accuracy, MOTA, - multiple object tracker performance, MOTP, - Detektionsrate, oder - Falsch-Alarm-Rate.
  7. Verfahren nach Anspruch 5 oder 6, wobei in dem Schritt D1) die Fusionsdaten (FD) mit den Umfelddaten (UD) anhand einer oder einer Kombination aus mehreren der folgenden globalen Bewertungskennzahlen (KPI) evaluiert werden: - Objekt-Detektionszeit, - Erfassungsrate, - Sensor-aufgelöste Erfassungsrate.
  8. Verfahren zum Entwurf eines Sensorsystems (10) zur Umfelddetektion für ein Fahrzeug (100) mit den Schritten: A2) Bereitstellen einer Vielzahl von Umfeldsensoren (1-n) und Erzeugen eines Sensormodells (SM) für jeden der Umfeldsensoren (1-n), das jeweils repräsentativ ist für physikalische Eigenschaften des jeweiligen Umfeldsensors (1-n) bei Abbildung eines realen Umfelds des Fahrzeugs (100) mittels realer Messung durch den jeweiligen Umfeldsensor (1-n), B2) Erzeugen wenigstens eines Umfeldmodells (UM), das jeweils repräsentativ ist für ein virtuelles Umfeld eines virtuellen Fahrzeugs (100), C2) Erzeugen mehrerer verschiedener virtueller Sensorsysteme (10), wobei ein virtuelles Sensorsystem (10) jeweils einen oder mehrere Umfeldsensoren (1-n) der Vielzahl von Umfeldsensoren (1-n) aufweist, D2) Durchführen jeweils einer Simulation eines der mehreren verschiedenen virtuellen Sensorsysteme (10) nach einem der Ansprüche 1 bis 7 abhängig von dem jeweiligen Sensormodell (SM) der Umfeldsensoren (1-n) des entsprechenden Sensorsystems (10) und dem wenigstens einen Umfeldmodell (UM), und E2) Ausgabe oder Speichern einer Evaluierung (E) des jeweiligen Sensorsystems (10) abhängig von der Simulation.
  9. Verfahren nach Anspruch 8, bei dem abhängig von der Evaluierung (E) des jeweiligen Sensorsystems (10) eine Auswahl des wenigstens eines Umfeldsensors (1-n) getroffen wird und/oder eine Platzierung des Umfeldsensors (1-n) im Fahrzeug (100) und/oder eine Ausrichtung des Umfeldsensors (1-n) bezüglich des Fahrzeugs (100) vorgenommen wird.
  10. Verfahren nach einem der vorstehenden Ansprüche 8 oder 9, bei dem - das jeweilige Sensormodell (SM) in dem Schritt A2) abhängig von einem vorgegebenen Satz an Sensorparametern ermittelt wird, die repräsentativ sind für die physikalischen Eigenschaften des jeweiligen Umfeldsensors bei Abbildung eines realen Umfelds des Fahrzeugs (100) mittels realer Messung durch den jeweiligen Umfeldsensor (1-n), und - das Verfahren im Anschluss an den Schritt E2) in dem Schritt A2) iterativ fortgesetzt wird, - abhängig von der Evaluierung (E) wenigstens einer der Sensorparameter und/oder einer der Konfigurationsparameter variiert wird bzw. werden, und - das Verfahren solange iteriert wird, bis die Evaluierung (E) des jeweiligen Sensorsystems (10) einen Hochpunkt erreicht oder sämtliche Sensorparameter des Satzes variiert wurden.
  11. Verfahren nach einem der vorstehenden Ansprüche 8 oder 9, bei dem die in dem Schritt C2) erzeugten mehreren verschiedenen virtuellen Sensorsysteme (10) als initiale Population eines genetischen Algorithmus dienen und jeweils aus einem oder mehreren Konfigurationsbereichen bestehen, wobei bei dem genetischen Algorithmus A3) für jedes der mehreren verschiedenen virtuellen Sensorsysteme (10) abhängig von einer Anzahl von Umfeldsensoren (1-n) des jeweiligen Sensorsystems (10) sowie eines jeweiligen Sensortyps der Umfeldsensoren (1-n) des jeweiligen Sensorsystems (10) ein Kostenkennwert des jeweiligen Sensorsystems (10) ermittelt wird, B3) abhängig von der Evaluierung (E) des jeweiligen Sensorsystems (10) ein Nutzenkennwert des jeweiligen Sensorsystems (10) ermittelt wird, C3) ein Verhältnis (N/K) aus dem Nutzenkennwert zu dem Kostenkennwert ermittelt wird, und geprüft wird, ob das Verhältnis (N/K) einen vorgegebenen Schwellenwert überschreitet, wobei im Falle dass der vorgegebene Schwellenwert überschritten wird, das entsprechende Sensorsystem (10) ausgegeben oder gespeichert wird, und anderenfalls D3) abhängig von dem jeweiligen Verhältnis (N/K) unterschiedliche Konfigurationsbereiche wenigstens zwei der Sensorsysteme (10) ausgewählt werden, E3) die ausgewählten Konfigurationsbereiche in zufälliger Weise zu mehreren virtuellen Sensorsystemen (10) als neue Population des genetischen Algorithmus zusammengesetzt werden, und der genetische Algorithmus mit der neuen Population in dem Schritt A3) iterativ fortgesetzt wird.
  12. Verfahren nach Anspruch 11, wobei nach dem Schritt D3) F3) eine zufällige Variation wenigstens eines der ausgewählten Konfigurationsbereiche als Mutation in dem genetischen Algorithmus vorgenommen wird.
  13. Verfahren nach einem der vorstehenden Ansprüche 7 bis 12, bei dem - das wenigstens eine Umfeldmodell (UM) in dem Schritt B2) abhängig von einem vorgegebenen Satz an Szenarioparametern ermittelt wird, die repräsentativ sind für ein vorgegebenes Fahrmanöver des virtuellen Fahrzeugs (100), und - das Verfahren im Anschluss an den Schritt E2) in dem Schritt B2) iterativ fortgesetzt wird, - abhängig von der Evaluierung (E) wenigstens einer der Szenarioparameter variiert wird, und - das Verfahren solange iteriert wird, bis die Evaluierung des jeweiligen Sensorsystems (10) einen Tiefpunkt erreicht oder sämtliche Szenarioparameter des Satzes variiert wurden.
  14. Vorrichtung zur Simulation eines Sensorsystems (10) für ein Fahrzeug (100), wobei das Sensorsystem (10) einen oder mehrere Umfeldsensoren (1-n) aufweist, und die Vorrichtung eingerichtet ist, das Verfahren nach einem der Ansprüche 1 bis 7 auszuführen.
  15. Vorrichtung zum Entwurf eines Sensorsystems (10) zur Umfelddetektion für ein Fahrzeug (100), wobei die Vorrichtung eingerichtet ist, das Verfahren nach einem der Ansprüche 8 bis 13 auszuführen.
DE102019124504.4A 2019-09-12 2019-09-12 Verfahren und Vorrichtung zur Simulation und Bewertung eines Sensorsystems für ein Fahrzeug sowie Verfahren und Vorrichtung zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug Pending DE102019124504A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102019124504.4A DE102019124504A1 (de) 2019-09-12 2019-09-12 Verfahren und Vorrichtung zur Simulation und Bewertung eines Sensorsystems für ein Fahrzeug sowie Verfahren und Vorrichtung zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102019124504.4A DE102019124504A1 (de) 2019-09-12 2019-09-12 Verfahren und Vorrichtung zur Simulation und Bewertung eines Sensorsystems für ein Fahrzeug sowie Verfahren und Vorrichtung zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug

Publications (1)

Publication Number Publication Date
DE102019124504A1 true DE102019124504A1 (de) 2021-04-01

Family

ID=74872897

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019124504.4A Pending DE102019124504A1 (de) 2019-09-12 2019-09-12 Verfahren und Vorrichtung zur Simulation und Bewertung eines Sensorsystems für ein Fahrzeug sowie Verfahren und Vorrichtung zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug

Country Status (1)

Country Link
DE (1) DE102019124504A1 (de)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114802284A (zh) * 2022-02-16 2022-07-29 武汉路特斯汽车有限公司 车辆感知性能评价方法及***
DE102021205072A1 (de) 2021-05-19 2022-11-24 Zf Friedrichshafen Ag Computerimplementiertes Verfahren und Computerprogramm zum Erhalten einer Leistungskennzahl für wenigstens einen Sensor
DE102021206033A1 (de) 2021-06-14 2022-12-15 Continental Autonomous Mobility Germany GmbH Verfahren zur Bestimmung der der Position und Ausrichtung von Ultraschallsensoren an einem Fahrzeug
EP4198482A1 (de) * 2021-12-17 2023-06-21 dSPACE GmbH Erstellen von testdaten mit konsistenten anfangsbedingungen zum stimulieren eines zu testenden steuergeräts
DE102022107158A1 (de) 2022-03-25 2023-09-28 Iav Gmbh Ingenieurgesellschaft Auto Und Verkehr Verfahren zum Testen automatisiert agierender Systeme
DE102022118631A1 (de) 2022-07-26 2024-02-01 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verfahren, System und Computerprogrammprodukt zur Validierung eines Fahrerassistenzsystems (ADAS) und/oder eines automatisierten Fahrsystems (ADS)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008001256A1 (de) * 2008-04-18 2009-10-22 Robert Bosch Gmbh Verkehrsobjekt-Erkennungssystem, Verfahren zum Erkennen eines Verkehrsobjekts und Verfahren zum Einrichten eines Verkehrsobjekt-Erkennungssystems
DE102009053509A1 (de) * 2009-11-16 2011-05-19 Valeo Schalter Und Sensoren Gmbh Verfahren zum simulativen Ermitteln von Messeigenschaften eines Sensors eines Kraftfahrzeugs und Rechensystem
DE102010013943A1 (de) * 2010-04-06 2011-10-06 Audi Ag Verfahren und Vorrichtung für eine Funktionsprüfung einer Objekt-Erkennungseinrichtung eines Kraftwagens
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

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008001256A1 (de) * 2008-04-18 2009-10-22 Robert Bosch Gmbh Verkehrsobjekt-Erkennungssystem, Verfahren zum Erkennen eines Verkehrsobjekts und Verfahren zum Einrichten eines Verkehrsobjekt-Erkennungssystems
DE102009053509A1 (de) * 2009-11-16 2011-05-19 Valeo Schalter Und Sensoren Gmbh Verfahren zum simulativen Ermitteln von Messeigenschaften eines Sensors eines Kraftfahrzeugs und Rechensystem
DE102010013943A1 (de) * 2010-04-06 2011-10-06 Audi Ag Verfahren und Vorrichtung für eine Funktionsprüfung einer Objekt-Erkennungseinrichtung eines Kraftwagens
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 (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021205072A1 (de) 2021-05-19 2022-11-24 Zf Friedrichshafen Ag Computerimplementiertes Verfahren und Computerprogramm zum Erhalten einer Leistungskennzahl für wenigstens einen Sensor
DE102021206033A1 (de) 2021-06-14 2022-12-15 Continental Autonomous Mobility Germany GmbH Verfahren zur Bestimmung der der Position und Ausrichtung von Ultraschallsensoren an einem Fahrzeug
WO2022262909A1 (de) * 2021-06-14 2022-12-22 Continental Autonomous Mobility Germany GmbH Verfahren zur bestimmung der der position und ausrichtung von ultraschallsensoren an einem fahrzeug
EP4198482A1 (de) * 2021-12-17 2023-06-21 dSPACE GmbH Erstellen von testdaten mit konsistenten anfangsbedingungen zum stimulieren eines zu testenden steuergeräts
CN114802284A (zh) * 2022-02-16 2022-07-29 武汉路特斯汽车有限公司 车辆感知性能评价方法及***
DE102022107158A1 (de) 2022-03-25 2023-09-28 Iav Gmbh Ingenieurgesellschaft Auto Und Verkehr Verfahren zum Testen automatisiert agierender Systeme
DE102022118631A1 (de) 2022-07-26 2024-02-01 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verfahren, System und Computerprogrammprodukt zur Validierung eines Fahrerassistenzsystems (ADAS) und/oder eines automatisierten Fahrsystems (ADS)

Similar Documents

Publication Publication Date Title
DE102019124504A1 (de) Verfahren und Vorrichtung zur Simulation und Bewertung eines Sensorsystems für ein Fahrzeug sowie Verfahren und Vorrichtung zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug
EP3695244B1 (de) Verfahren und vorrichtung zum erzeugen eines inversen sensormodells und verfahren zum erkennen von hindernissen
DE102016220670A1 (de) Verfahren und System zum Testen von Software für autonome Fahrzeuge
DE102010013943B4 (de) Verfahren und Vorrichtung für eine Funktionsprüfung einer Objekt-Erkennungseinrichtung eines Kraftwagens
DE102007053501A1 (de) Verfahren zur Entwicklung und/oder zum Testen wenigstens eines Sicherheits- und/oder Fahrerassistenzsystems für ein Kraftfahrzeug und Simulationsumgebung
DE102014208009A1 (de) Erfassen von statischen und dynamischen Objekten
DE102018128289A1 (de) Verfahren und vorrichtung für eine autonome systemleistung und zur einstufung
EP3767403B1 (de) Machine-learning gestützte form- und oberflächenmessung zur produktionsüberwachung
DE102005037837A1 (de) Verfahren und Vorrichtung zur Erstellung eines Messplans zur Vermessung eines 3D-Messobjekts
DE102019124018A1 (de) Verfahren zum Optimieren von Tests von Regelsystemen für automatisierte Fahrdynamiksysteme
DE102021100149A1 (de) Computerimplementiertes Verfahren zum Bereitstellen eines Test-Verlaufs zu testender Verkehrsszenarien
WO2021058223A1 (de) Verfahren zur effizienten, simulativen applikation automatisierter fahrfunktionen
DE102022112059B3 (de) Verfahren, System und Computerprogrammprodukt zur Kalibrierung und Validierung eines Fahrerassistenzsystems (ADAS) und/oder eines automatisierten Fahrsystems (ADS)
EP3757795A1 (de) Verfahren und vorrichtung zur optimalen aufteilung von testfällen auf unterschiedliche testplattformen
DE102021100351A1 (de) Adaptive untersuchung für lidar-basiertes gruppieren
DE102022100549A1 (de) Mit einem rang versehene fehlerzustände
WO2019119011A1 (de) Verhaltensmodell eines umgebungssensors
DE102019130096A1 (de) Verfahren zur Ermittlung einer Radarinformation, Simulationsverfahren, Klassifizierungsverfahren, Computerprogramm und Berechnungssystem
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
WO2021165077A1 (de) Verfahren und vorrichtung zur bewertung eines bildklassifikators
DE102017201796A1 (de) Steuervorrichtung zum Ermitteln einer Eigenbewegung eines Kraftfahrzeugs sowie Kraftfahrzeug und Verfahren zum Bereitstellen der Steuervorrichtung
WO2023099066A1 (de) Simulation zur validierung einer automatisierenden fahrfunktion für ein fahrzeug
AT524932B1 (de) Verfahren und System zum Testen eines Fahrerassistenzsystems für ein Fahrzeug
DE102021133977A1 (de) Verfahren und System zur Klassifikation von Szenarien eines virtuellen Tests sowie Trainingsverfahren
DE102005044411A1 (de) Fahrerbelastungsmessverfahren, -vorrichtung und -programm für ein von Lageänderungen begleitetes Fahrzeug, sowie Speichermedium zum Speichern des Programms

Legal Events

Date Code Title Description
R163 Identified publications notified