-
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. 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. 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