DE102013212710A1

DE102013212710A1 - Sensorprodukt, Simulator und Verfahren zur Simulation von Sensormessungen, zur Fusion von Sensormessungen, zur Validierung eines Sensormodells und zum Entwurf eines Fahrerassistenzsystems

Info

Publication number: DE102013212710A1
Application number: DE201310212710
Authority: DE
Inventors: Michael Fiegert; Wendelin Feiten
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2013-05-16
Filing date: 2013-06-28
Publication date: 2014-11-20
Also published as: WO2014183945A1; DE102013213807A1; DE102013215032A1; DE102013215115A1; WO2014183948A2; WO2014183949A1; WO2014183953A1; DE102013218678A1; WO2014183944A1

Abstract

Zusätzlich zu einem Sensor (1) wird ein Sensormodell (10) bereitgestellt, welches eine Hardware und/oder physikalische Eigenschaften des Sensors (1) beschreibt und/oder virtuell modelliert derart, dass ein Simulator in die Lage versetzt wird, virtuelle Messungen (30) des Sensors (1) in einem Umgebungsmodell (20) zu simulieren. Das Sensormodell (10) ist von dem Umgebungsmodell (20) modular getrennt und unabhängig. Für jede Art von Sensormodell (10), die verwendet werden soll, werden im Umgebungsmodell (20) die entsprechenden physikalischen Eigenschaften der Umgebung berücksichtigt. Für eine Videokamera sind das beispielsweise die Geometrie und die Texturen der Objekte. Die Aufteilung zwischen Sensormodell (10) und Umgebungsmodell (20) ist in dieser Weise bisher nicht üblich, führt jedoch dazu, dass das spezielle Wissen der Entwickler der Sensor-Hardware und das Wissen über die Applikationsdomäne nicht in einer Person oder in einem Team vereint sein müssen, sondern unabhängig voneinander erfasst und verwendet bzw. wiederverwendet werden können. Des Weiteren ist es hierbei möglich, einen Sensor (1) für eine Mehrzahl von Fahrerassistenzapplikationen zu nutzen, da die strikte Kopplung zwischen Sensor (1) und Fahrerassistenzapplikation durch das modular wiederverwendbare Sensormodell (10) aufgebrochen ist. Folglich wird Redundanz im Gesamtsystem Fahrerassistenzsystem besser ausgenutzt.

Description

Für die folgenden Ausführungen müssen die Begriffe ”Modell” und ”Repräsentation” unterschiedlich definiert werden. Als Modell werden im Folgenden Datenstrukturen bezeichnet, welche Aspekte einer realen Umgebung weitgehend exakt modellieren und daher als zuverlässige Eingabe und/oder Vorgabe für Algorithmen zur Sensorfusion sowie zu deren Training verwendet werden können. Derartige Modelle werden in der Regel von Experten mit großer Sorgfalt und hohem Zeitaufwand erstellt.
Abweichend davon soll der Begriff ”Repräsentation” diejenigen geschätzten Annahmen und Meinungen bezeichnen, welche sich eine Software, beispielsweise ein Algorithmus zur Sensorfusion, selbst über eine Umgebung bilden muss. Eine derartige Repräsentation ist folglich Arbeitsergebnis eines Computerprogrammablaufs und muss gegenüber den zuvor genannten Modellen notwendigerweise sowohl in ihrem Detaillierungsgrad als auch in ihrer Zuverlässigkeit zurückbleiben.
Entsprechend bezeichnet im Folgenden ein Umgebungsmodell ein weitgehend exaktes Modell einer realen Umgebung, welches ein Experte beispielsweise durch exakte manuelle Vermessung einer Testumgebung und anschließende Konstruktion eines fein aufgelösten Polygonmodells erstellt hat. Demgegenüber bezeichnet im Folgenden eine Umgebungsrepräsentation eine interne Repräsentation einer Umgebung, welche beispielsweise durch einen Algorithmus zur Sensorfusion als Gitterkarte erzeugt wird und notwendigerweise sowohl in ihrem Detaillierungsgrad als auch in ihrer Zuverlässigkeit gegenüber dem Umgebungsmodell zurückbleiben muss. Die Begriffe Umgebungsrepräsentation und interne Umgebungsrepräsentation sind hierbei synonym zu verstehen. Die Begriffe Messwerte, Sensordaten und Sensorsignale werden ebenfalls synonym verwendet.
Analog hierzu bezeichnet im Folgenden ein Fahrzeugmodell ein weitgehend exaktes Modell eines Fahrzeugs, beispielsweise in Form eines hochauflösenden 3D-Modells oder Bauplans. Demgegenüber bezeichnet im Folgenden eine Fahrzeugrepräsentation geschätzte Zustände des Fahrzeugs, beispielsweise ob ein Schleudern vorliegt oder nicht.
Weiterhin bezeichnet im Folgenden ein Fahrermodell ein weitgehend exaktes Modell eines Fahrers, beispielsweise in Form eines animierten humanoiden 3D-Modells, welches realistische Kopf, Augen- und Lidbewegungen zeigt. Demgegenüber bezeichnet im Folgenden eine Fahrerrepräsentation geschätzte bzw. vermutete Zustände des Fahrers, beispielsweise ob er ermüdet ist oder nicht.
Häufig wird es sich bei der Umgebung um eine Umgebung eines Fahrzeugs handeln. Als Sonderfall kann es sich bei der Umgebung jedoch auch um das Fahrzeug selbst bzw. um dessen Fahrer handeln. Sofern nicht genauer bezeichnet, soll der Begriff Umgebungsmodell daher im Folgenden auch die Sonderfälle Fahrzeugmodell und Fahrermodell beinhalten. Ebenso soll der Begriff Umgebungsrepräsentation, sofern nicht genauer bezeichnet, im Folgenden auch die Sonderfälle Fahrzeugrepräsentation und Fahrerrepräsentation beinhalten.
Die im Folgenden beschriebenen Algorithmen können jedoch auch ein Umgebungsmodell, ein Fahrzeugmodell und/oder ein Fahrermodell sowie eine Umgebungsrepräsentation, eine Fahrzeugrepräsentation und/oder eine Fahrerrepräsentation nebeneinander verwenden, wobei diese dann in getrennten Modulen vorliegen und in geeigneter Weise gemeinsam zusammenwirken.
In einem Fahrzeug werden heutzutage mehrere Fahrerassistenzapplikationen oder Applikationen integriert. Da die Applikationen von unabhängigen Herstellern stammen und unabhängig voneinander entwickelt werden, sind die von einer bestimmten Applikation verwendeten Sensorsignale von einer anderen Applikation nicht verwendbar. Wesentlicher Grund hierfür ist die vertikale Integration der Applikationen, das heißt die Applikationen inklusive der dafür notwendigen Hardware und Software werden unabhängig voneinander entwickelt und in das Fahrzeug eingebaut. So hat die jeweilige Applikation eigens vorgesehene Sensoren, eine eigene Umgebungsrepräsentation und eine eigene Ausgabe, nämlich die Anwendung der jeweiligen Fahrerassistenzapplikation.
Die enge Kopplung von Sensoren und Applikationen führt dazu, dass die einzelnen Bearbeitungsschritte von der Erfassung der Umwelt durch den Sensor bis hin zur Reaktion, das heißt der Anwendung der Fahrerassistenzapplikation, häufig nicht getrennt werden, sondern als ein Block umgesetzt werden. Dieser Block umfasst herkömmlicherweise drei Ebenen, nämlich die Erfassung der Umwelt durch den Sensor, die Interpretation der Sensorwerte auf Basis einer Umgebungsrepräsentation und die Reaktion durch die Fahrerassistenzapplikation.
Die Übersetzung der Sensordaten in eine Umgebungsrepräsentation, welche die interne, durch die Fahrerassistenzapplikation wahrgenommene Schätzung der Umgebung darstellt, sowie die Implementierung der eigentlichen Applikation auf Grund dieser Umgebungsrepräsentation liegt herkömmlicherweise in der Hand des jeweiligen Entwicklers.
Wie dabei die Sensordaten in Bezug auf einen Typ der Umgebungsrepräsentation (beispielsweise Gitterkarte oder Objektliste) zu interpretieren sind, bleibt dabei der Erfahrung und dem Fingerspitzengefühl des jeweiligen Entwicklers überlassen. Der jeweilige Entwickler muss die Eigenheiten der eingesetzten Sensoren und den Typ der Umgebungsrepräsentation genau kennen.
Die Umrechnungsvorschrift, nach der die Sensordaten in die Umgebungsrepräsentation hinein umgerechnet werden, ist dabei herkömmlicherweise in einem Fusionsalgorithmus integriert. Wenn ein neuer Sensortyp in das System integriert werden soll, muss der gesamte Fusionsalgorithmus wieder aufgeschnürt werden. Dann muss der Fusionsalgorithmus wieder unter Berücksichtigung des neuen Sensortyps neu formuliert werden. Auch hierzu muss der Entwickler wieder die Eigenheiten dieses neuen Sensortyps genau kennen.
Das Dokument DE 10 2004 052 242 A1 zeigt ein Sensorfusionssystem und Fahrzeugsteuersystem mit einem Sensorfusionssystem. Jede von mehreren Wahrscheinlichkeitsverteilungs-Ausgabeeinheiten berechnet eine Wahrscheinlichkeitsverteilung eines Datenwerts, der von einem entsprechenden Sensor oder Algorithmus in einer Bilderkennungsverarbeitung erfasst wird. Die jeweiligen Wahrscheinlichkeitsverteilungen der mehreren Wahrscheinlichkeitsverteilungs-Ausgabeeinheiten werden als Ausgabe zu einer Synthesebestimmungs-Bearbeitungseinheit gegeben. Datenformate der Ausgaben der Synthesebestimmungs-Verarbeitungseinheit können dadurch standardisiert werden. Daher wird die Synthesebestimmungs-Verarbeitungseinheit davon ausgenommen, zu berücksichtigen, auf welchem Typ des Sensors oder Algorithmus jede der Ausgaben basiert. Auch dann, wenn ein Sensor oder Algorithmus hinzugefügt oder geändert wird, kann der gleiche datenfusionierende Algorithmus in der Synthesebestimmungs-Verarbeitungseinheit eingesetzt werden. Allerdings sind hier Wahrscheinlichkeitsverteilungs-Ausgabeeinheiten und eine Synthesebestimmungs-Verarbeitungseinheit nötig.
Das Dokument WO 2007/017308 A1 zeigt ein Verfahren zum Erstellen von Umwelthypothesen für Fahrerassistenzfunktionen.
Wie bereits erläutert, ist ein wesentlicher Schritt im Entwurf von Fahrerassistenzsystemen die Herleitung von internen Repräsentationen der Umgebung, des Fahrzeugs und des Fahrers aus den Messwerten von einem oder mehreren Sensoren. Bisher werden hierzu pauschale Modelle gebildet, in welche sowohl vertiefte Kenntnisse über die Physik des Sensors als auch über die Eigenschaften der Einsatzumgebung eingehen.
Es stellt sich die Aufgabe, ein Sensorprodukt und einen Simulator sowie Verfahren zur Simulation von Sensormessungen, zur Fusion von Sensormessungen, zur Validierung eines Sensormodells und zum Entwurf eines Fahrerassistenzsystems anzugeben, welche eine Wiederverwendbarkeit der entsprechenden Produkte und Verfahren erhöhen und/oder einen Einsatz der entsprechenden Produkte und Verfahren vereinfachen.
Diese Aufgabe wird erfindungsgemäß durch ein Sensorprodukt gelöst, welches einen Sensor umfasst, eingerichtet zur Erzeugung realer Messungen, welche reale Sensordaten erzeugen, die eine reale Umgebung zumindest teilweise abbilden,

– wobei die reale Umgebung insbesondere eine Umgebung eines Fahrzeugs, ein Fahrzeug mit Zuständen und/oder ein Fahrer eines Fahrzeugs ist,
– wobei der Sensor, insbesondere eine 2D- oder 3D-Kamera, ein Ultraschallsensor, ein 2D- oder 3D-Laserscanner, ein 2D- oder 3D-Radar, ein Lidar, ein Raddrehungssensor, ein Inertialsensor, ein Beschleunigungssensor, ein Drehratensensor, ein Temperatursensor, ein Luftfeuchtesensor, ein Positionssensor zur Bestimmung zumindest eines Parameters der Fahrdynamik eines Fahrzeuges, ein Sitzbelegungssensor oder ein Entfernungssensor ist, gekennzeichnet durch ein Sensormodell,
– welches, insbesondere als Programmcode oder XML-Dokument, auf einem Datenträger gespeichert ist, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer Cloud,
– welches eine Hardware und/oder physikalische Eigenschaften des Sensors beschreibt und/oder virtuell modelliert derart, dass ein Simulator, welcher nicht Teil des Sensorprodukts ist, durch Einlesen des Sensormodells von dem Datenträger in die Lage versetzt wird, virtuelle Messungen des Sensors in einem Umgebungsmodell, welches nicht Teil des Sensorprodukts ist, zu simulieren, indem das Sensormodell Programmcode für den Simulator bereitstellt oder Programmcode des Simulators parametriert, und
– welches von dem Umgebungsmodell, welches nicht Teil des Sensorprodukts ist, modular getrennt und unabhängig ist.

Der Simulator beinhaltet eine Recheneinheit, welche programmiert ist zur Simulation von virtuellen Messungen mindestens eines Sensors des Sensorprodukts in mindestens einem Umgebungsmodell basierend auf dem Sensormodell des Sensorprodukts.
Weiterhin wird die Aufgabe erfindungsgemäß durch ein Verfahren zur Simulation von Sensormessungen gelöst,

– bei dem eine Recheneinheit ein Sensormodell von einem Datenträger einliest,
– bei dem das Sensormodell eine Hardware und/oder physikalische Eigenschaften eines Sensors beschreibt und/oder virtuell modelliert, wobei der Sensor zur Abbildung einer realen Umgebung mittels realer Messungen, die reale Sensordaten erzeugen, eingerichtet ist,
– wobei die reale Umgebung insbesondere eine Umgebung eines Fahrzeugs, ein Fahrzeug mit Zuständen oder ein Fahrer eines Fahrzeugs ist,
– bei dem die Recheneinheit anhand des Sensormodells virtuelle Messungen des Sensors in einem Umgebungsmodell simuliert, und
– bei dem das Sensormodell von dem Umgebungsmodell modular getrennt und unabhängig ist.

Außerdem wird die Aufgabe erfindungsgemäß durch ein Verfahren zur Fusion von Sensormessungen gelöst,

– bei dem
– mit mindestens einem Sensorprodukt reale Messungen in einer realen Umgebung durchgeführt werden, wodurch reale Sensordaten erzeugt werden, oder
– für mindestens ein Sensorprodukt virtuelle Messungen mittels der Simulator-Software nach Anspruch 10, mittels des Simulators nach Anspruch 11 oder 12 oder mittels des Verfahrens nach einem der Ansprüche 13 bis 15 in einem Umgebungsmodell simuliert werden, wodurch virtuelle Sensordaten erzeugt werden, und
– bei dem eine Recheneinheit Wahrscheinlichkeitsdichtefunktionen, welche in dem Sensormodell des Sensorprodukts enthalten sind, verwendet, um die realen Sensordaten oder virtuellen Sensordaten als Zufallsvariable und/oder Wahrscheinlichkeitsdichtefunktionen in einer Umgebungsrepräsentation eines vorgegebenen Typs abzuspeichern,
– bei dem
- die realen Sensordaten oder virtuellen Sensordaten zu unterschiedlichen Zeitpunkten erzeugt und in der Umgebungsrepräsentation zeitlich fusioniert werden,
– die realen Sensordaten oder virtuellen Sensordaten für Sensoren mit unterschiedlichen Positionen erzeugt und in der Umgebungsrepräsentation örtlich fusioniert werden, und/oder
– die realen Sensordaten oder virtuellen Sensordaten für Sensoren unterschiedlichen Typs erzeugt und in der Umgebungsrepräsentation fusioniert werden, und
– bei dem der vorgegebene Typ der Umgebungsrepräsentation insbesondere eine 2D- oder 3D-Gitterkarte, eine Objektliste oder eine Liste von Zuständen ist.

Weiterhin wird die Aufgabe erfindungsgemäß durch ein Verfahren zur Validierung eines Sensormodells gelöst,

– bei dem mit dem Sensorprodukt reale Sensormessungen in einer realen Umgebung durchgeführt werden, wodurch reale Sensordaten erzeugt werden,
– bei dem mit dem Verfahren zur Simulation von Sensormessungen virtuelle Sensormessungen in einem Umgebungsmodell, welches die reale Umgebung nachbildet, simuliert werden, wodurch virtuelle Sensordaten erzeugt werden,
– bei dem die realen Sensordaten mit den virtuellen Sensordaten verglichen werden, und
– bei dem aus dem Vergleich eine Güteinformation abgeleitet wird, welche in das Sensormodell des Sensorprodukts aufgenommen wird.

Ferner wird die Aufgabe erfindungsgemäß durch ein Verfahren zum Entwurf eines Fahrerassistenzsystems gelöst,

– bei dem das Sensorprodukt für den Einsatz in einem Fahrerassistenzsystem vorgesehen wird,
– bei dem unter Nutzung des Verfahrens zur Simulation von Sensormessungen oder des Verfahrens zur Fusion von Sensormessungen ein geeigneter Typ für die Umgebungsrepräsentation 6 für das Fahrerassistenzsystem ausgewählt wird, und
– bei dem das Sensorprodukt in den mechanischen und elektrischen Entwurf integriert wird, wobei diesbezügliche Informationen im Sensormodell verwendet werden.

Auf dem computerlesbaren Datenträger ist ein Computerprogramm gespeichert, welches eines der Verfahren ausführt, wenn es in einem Mikroprozessor abgearbeitet wird.
Das Computerprogramm wird in einem Mikroprozessor abgearbeitet und führt dabei eines der Verfahren aus.
Die im Folgenden genannten Vorteile müssen nicht notwendigerweise durch die Gegenstände der unabhängigen Patentansprüche erzielt werden. Vielmehr kann es sich hierbei auch um Vorteile handeln, welche lediglich durch einzelne Ausführungsformen, Varianten oder Weiterbildungen erzielt werden.
Das Sensorprodukt erlaubt es, die verschiedenen Einflussbereiche für das Sensormodell getrennt voneinander zu modellieren. Ein Gesamtmodell ergibt sich durch Simulation der Sensormessungen aufgrund der getrennt aufgestellten Modelle – insbesondere dem Sensormodell und getrennt hiervon einem Umgebungsmodell – und eines geeigneten Simulationssystems.
Das Umgebungsmodell enthält diejenigen physikalischen Eigenschaften der Umgebung, die zur Simulation oder Herleitung der ”ground truth” einer Umgebungsrepräsentation benötigt werden. Unter ”ground truth” wird hierbei die tatsächliche Wahrheit verstanden, welche einer Messung zugrunde liegt. Um etwa Messvarianzen eines kostengünstigen Sensors zu ermitteln, wird zunächst ein Objekt mit einem sehr hochwertigen Sensor vermessen, um vorab eine exakte Messung (”ground truth”) zu erhalten. Danach wird mit dem endgültigen Sensor eine Vielzahl von Messungen vorgenommen, wodurch sich z. B. eine Gaußkurve von Messwerten in Relation zu der vorab ermittelten exakten Messung (”ground truth”) ergibt. Bei der Simulation von Sensormessungen ergibt sich die ”ground truth” unmittelbar aus dem Umgebungsmodell.
Für jede Art von Sensormodell, die verwendet werden soll, werden im Umgebungsmodell die entsprechenden physikalischen Eigenschaften der Umgebung berücksichtigt. Für eine Videokamera sind das beispielsweise die Geometrie und die Texturen der Objekte. Für einen Ultraschallsensor kann eine Approximation der Geometrie zusammen mit den akustischen Reflexionseigenschaften ausreichen.
Indem das Umgebungsmodell aus dem Sensormodell ausgeklammert wird, kann das Sensormodell unabhängig von seiner jeweiligen spezifischen Verwendung entwickelt werden. Dies ermöglicht insbesondere einen Einsatz einer formalisierten Beschreibung für das jeweilige Sensorsignal.
Die Aufteilung zwischen Sensormodell und Umgebungsmodell ist in dieser Weise bisher nicht üblich, führt jedoch dazu, dass das spezielle Wissen der Entwickler der Sensor-Hardware und das Wissen über die Applikationsdomäne nicht in einer Person oder in einem Team vereint sein müssen, sondern unabhängig voneinander erfasst und verwendet bzw. wiederverwendet werden können. Neben der Erhöhung der Wiederverwendbarkeit wird hierdurch auch der Einsatz der jeweiligen Produkte und Verfahren vereinfacht.
Durch die Sensormodelle ist eine modulare und hybride Fusionierung von Sensorsignalen unterschiedlicher Sensoren möglich. Insbesondere muss dabei ein Entwickler die spezifischen Eigenschaften des jeweiligen Sensors nicht kennen oder erforschen, da er das Sensormodell entweder direkt von dem Sensor oder auf einen anderen Weg, zum Bespiel über einen USB-Stick oder als herunterladbare Datei über das Internet, erhält.
Des Weiteren ist es hierbei möglich, einen Sensor für eine Mehrzahl von Fahrerassistenzapplikationen zu nutzen, da die strikte Kopplung zwischen Sensor und Fahrerassistenzapplikation durch das modular wiederverwendbare Sensormodell aufgebrochen ist. Folglich wird Redundanz im Gesamtsystem Fahrerassistenzsystem besser ausgenutzt.
Ein weiterer Aspekt neben der Möglichkeit der Nutzung von Redundanz ist, dass die für das Fahrerassistenzsystem notwenige Hardware reduziert werden kann, da einzelne Sensoren mehrfach genutzt werden. Auch ist die Komplexität des Gesamtsystems Fahrerassistenzsystem einfacher zu beherrschen. Des Weiteren ermöglichen die Sensormodelle, dass getrennt arbeitende Gruppen von Entwicklern – beispielsweise für die Sensoren, die Sensorsimulation, die Sensorfusion und den Entwurf – mittels definierter Schnittstellen wie den Sensormodellen zusammenarbeiten.
Ein weiterer Vorteil liegt in der Möglichkeit, Fahrerassistenzsysteme durch die geschaffene erhöhte Modularität schrittweise weiter zu entwickeln. Statt wie herkömmlich jede Applikation mit eigenen Sensoren auszustatten, können die bestehenden Sensoren wieder verwendet werden. Der Mehrpreis einer neuen Fahrerassistenzapplikation orientiert sich dann nur noch an den gegebenenfalls zusätzlich verbauten Sensoren und den Kosten für neue Software.
Bei dem Verfahren zum Entwurf eines Fahrerassistenzsystems wird der geeignete Typ für die Umgebungsrepräsentation für das Fahrerassistenzsystem beispielsweise unter folgenden ausgewählt: 2D-Gitterkarte, 3D-Gitter- oder Würfelkarte, Polygonmodell, Objektlisten (Liste der Mittelpunkte von Objekten oder von Rechteckhüllen mit Größenangabe) oder einfache Listen von Zuständen.
Der jeweilige Sensor kann das Sensormodell direkt ausgeben, um eine entsprechende Zertifizierung zu erfüllen. Alternativen hierzu liegen in solchen Ausführungsformen, in welchen das Sensormodell auf einem anderen Weg bereitgestellt wird. Beispiele für solche andere Wege umfassen die Verwendung eines USB-Sticks oder eine von dem Internet herunterladbare Datei. Der USB-Stick ist beispielsweise mit einem Engineering-System koppelbar. Zur Zertifizierung könnte der Sensor selbst in diesem Fall eine sichere Hash-Summe bereitstellen, über welche sich die Authentizität des Sensormodells verifizieren lässt.
Die Recheneinheit kann hardwaretechnisch und/oder auch softwaretechnisch implementiert sein. Bei einer hardwaretechnischen Implementierung kann die Recheneinheit als Vorrichtung oder als Teil einer Vorrichtung, zum Beispiel als Computer oder als Mikroprozessor oder als Steuerrechner eines Fahrzeuges ausgebildet sein. Bei einer softwaretechnischen Implementierung kann die jeweilige Einheit als Computerprogrammprodukt, als eine Funktion, als eine Routine, als Teil eines Programmcodes oder als ausführbares Objekt ausgebildet sein.
Bei dem computerlesbaren Datenträger handelt es sich beispielsweise um eine Speicherkarte, einen USB-Stick, eine CD-ROM, eine DVD oder auch um einen Datenträger eines Servers, von welchem eine Datei mit dem Computerprogramm in einem Netzwerk bereitgestellt oder geliefert wird. Dies kann zum Beispiel in einem drahtlosen Kommunikationsnetzwerk durch die Übertragung der entsprechenden Datei erfolgen.
Gemäß einer Ausführungsform der Erfindung weist das Sensormodell ein vorbestimmtes Format und/oder eine Schnittstelle eines vorbestimmten Formats auf.
Das vorbestimmte Format des Sensormodells ist beispielsweise ein XML-Schema.
In einer Weiterbildung ist die Beschreibung und/oder virtuelle Modellierung der Hardware und/oder der physikalischen Eigenschaften des Sensors zumindest teilweise eine probabilistische Beschreibung mit Wahrscheinlichkeitsdichtefunktionen.
Probabilistische Beschreibungen sind besonders geeignet, Sensordaten unterschiedlicher Sensoren mit unterschiedlichen Modalitäten, zum Beispiel Radarsensor und Lasersensor, auf eine Umgebungsrepräsentation oder ein fusioniertes Sensorsignal zu fusionieren.
Gemäß einer Ausführungsform modelliert das Sensormodell zufällige Abweichungen in den realen Sensordaten, deren Ursachen in einer Hardware des Sensors liegen, als Wahrscheinlichkeitsdichtefunktion.
In einer Weiterbildung modelliert das Sensormodell zufällige Abweichungen in den realen Sensordaten, deren Ursachen in Schwankungen in einem Übertragungsmedium oder unterschiedlichen abgebildeten Materialien liegen, als Wahrscheinlichkeitsdichtefunktion modelliert.
Gemäß einer Ausführungsform ergibt sich ein Sensorprodukt,

– bei dem der Sensor ein Ultraschall-Entfernungssensor ist, und
– bei dem das Sensormodell mehrere oder alle der folgenden physikalischen Eigenschaften des Sensors modelliert:
– Sende- und Empfangsfrequenzbereiche bzw. Frequenzgänge,
– Richtcharakteristik,
– Filtereigenschaften,
– Sendeenergie, und
– Empfangsempfindlichkeit.

In einer Weiterbildung ergibt sich ein Sensorprodukt,

– welches zusätzlich mindestens ein Umgebungsmodell umfasst, welches auf einem Datenträger, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer Cloud, gespeichert ist,
– wobei das Umgebungsmodell eine Beschreibung einer virtuellen Umgebung enthält, welche einem Simulator erlaubt, anhand des Sensormodells virtuelle Messungen des Sensors in der virtuellen Umgebung zu simulieren,
– wobei die virtuelle Umgebung insbesondere eine virtuelle Welt, ein Fahrer in einem Fahrzeugcockpit oder ein Fahrzeug mit internen Zuständen ist,
– wobei das Umgebungsmodell von dem Sensormodell modular getrennt und unabhängig ist, und
– wobei das Umgebungsmodell ein standardisiertes Format aufweist, welches die Verwendung des Umgebungsmodells mit unterschiedlichen Sensormodellen und/oder Simulatoren erlaubt.

Gemäß einer Ausführungsform ergibt sich ein Sensorprodukt,

– bei dem der Sensor eine Kamera ist und das Umgebungsmodell einem Simulator erlaubt, ein Kamerabild zu simulieren,
– bei dem das Umgebungsmodell insbesondere enthält:
– ein 3D-Modell mit texturierten Polygonen, welches ein reales Vorbild approximiert,
– Trübungen des Übertragungsmediums durch Nebel, Regen oder Schnee, und/oder
– Beleuchtungsverhältnisse.

In einer Weiterbildung ergibt sich ein Sensorprodukt,

– bei dem der Sensor ein Ultraschallsensor ist und das Umgebungsmodell einem Simulator erlaubt, ein Ultraschallbild zu simulieren,
– indem das Umgebungsmodell insbesondere ein 3D-Modell enthält, welches ein reales Vorbild approximiert und vereinfacht, und wobei das 3D-Modell Polygone und Angaben zu Reflexionseigenschaften und/oder Oberflächennormalen der Polygone enthält.

Gemäß einer Ausführungsform ergibt sich ein Sensorprodukt,

– welches zusätzlich eine modulare Simulator-Software umfasst, welche auf einem Datenträger, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer Cloud, gespeichert ist, und welche zu einer Simulation von virtuellen Messungen des Sensors in dem Umgebungsmodell nach einem Einlesen des Sensormodells eingerichtet ist.

In einer Weiterbildung ergibt sich ein Simulator,

– mit einem Sensor-Simulationsmodul, welches dazu eingerichtet ist, das Sensormodell von dem Datenträger einzulesen,
– wodurch Programmcode für das Sensor-Simulationsmodul bereitgestellt wird, oder
– wodurch Programmcode des Sensor-Simulationsmoduls parametriert wird, und
– wobei der Sensor durch das Sensor-Simulationsmodul simuliert wird, und
– wobei das Sensor-Simulationsmodul eine eigene Hardware umfasst und/oder virtuell in einer Recheneinheit als Programmcode ausgeführt wird.

Das Sensor-Simulatormodul liest also beispielsweise ein in XML kodiertes Sensormodell ein und verhält sich daraufhin wie der reale Sensor.
Gemäß einer Ausführungsform ergibt sich ein Verfahren zur Simulation von Sensormessungen,

– bei dem ein Fahrzeugmodell eine geometrische Position des Sensors relativ zu einem Fahrzeug und insbesondere eine Versorgungsspannung angibt, mit der der Sensor von dem Fahrzeug versorgt wird, und
– bei dem das Fahrzeugmodell bei der Simulation berücksichtigt wird.

Das Fahrzeugmodell beschreibt insbesondere, wo sich die Sensoren relativ zum Fahrzeug befinden. In erster Linie sind dabei geometrische Verhältnisse relevant. Es können aber auch elektrische Verhältnisse verwendet werden, wenn zum Beispiel gemäß Sensormodell Schwankungen in der Versorgungsspannung zu einem erhöhten Rauschen bei den Messwerten führen können. In diesem Fall kann auch die Versorgungsspannung, gegebenenfalls als Zufallsvariable, als Teil des Fahrzeugmodells verwendet werden.
In einer Weiterbildung ergibt sich ein Verfahren zur Simulation von Sensormessungen,

– bei dem die Recheneinheit zur Simulation der virtuellen Messungen für eine Anzahl von von dem Sensor ausgehenden Strahlen Schnittpunkte mit Polygonen im Umgebungsmodell berechnet, wobei insbesondere Normalenvektoren der Polygone an den Schnittpunkten bei der Ermittlung eines Ultraschall-Echos berücksichtigt werden.

Im Folgenden werden Ausführungsbeispiele der Erfindung anhand von Figuren näher erläutert. In den Figuren sind gleiche oder funktionsgleiche Elemente mit denselben Bezugszeichen versehen, sofern nichts anderes angegeben ist. Es zeigen:
1 einen Stand der Technik beim Aufbau einer Umgebungsrepräsentation aus Sensordaten,
2A–2D typische Ingredienzien einer Modellierung von Ultraschallmessungen,
2A eine Wahrscheinlichkeitsdichtefunktion p_hit eines Messwertes bei ungestörter Messung auf ein Objekt,
2B tatsächlich ermittelte Entfernungsmessungen, die auf nicht statische Objekte in der Umgebung zurückzuführen sind,
2C einen Fall, in dem gar kein Echo gemessen wird,
2D zufällige Messwerte,
3 aus den 2A–2D resultierende Verteilung für die Modellierung von Ultraschallmessungen,
4 ein Ablaufdiagramm einer Simulation virtueller Messungen, und
5 ein Ablaufdiagramm zur Validierung eines Sensormodells.
Bei der Entwicklung von Fahrerassistenzsystemen ist die angemessene Interpretation der Messwerte der Sensoren in verschiedenen Einsatzumgebungen eine entscheidende Voraussetzung für die Funktion des Fahrerassistenzsystems. Es kommt also darauf an, möglichst genau zu verstehen, welche Phänomene zu welchen Messwerten führen, damit dann aus den Messwerten auf die Phänomene zurückgeschlossen werden kann, d. h. damit aus den Messwerten eine im Fahrzeug bzw. im Fahrerassistenzsystem interne Repräsentation der Umgebung, des Fahrzeugs oder des Fahrers hergeleitet werden kann.
Bisher werden im Entwurf von Fahrerassistenzsystemen die Verfahren zur Fusionierung der Messwerte bzw. Sensordaten zu einer internen Repräsentation aufgrund von Erfahrungswissen und Ingenieurskunst der Entwickler aufgestellt. Die Details dieser Verfahren hängen stark ab von den Eigenschaften der Sensordaten, d. h. davon, welche Messwerte die Sensoren erzeugen, gegeben die spezifische Sensor-Hardware und die spezifische Einsatzumgebung.
Der bisherige Stand beim Aufbau einer Umgebungsrepräsentation aus Sensordaten wird grob in 1 gezeigt. Ein Sensor 1 führt eine reale Messung 3 in einer realen Umgebung 2 durch und erzeugt hierbei reale Sensordaten 4. Die realen Sensordaten 4 bzw. ihre Eigenschaften über eine Anzahl von Anwendungen hinweg werden also experimentell ermittelt. Die Eigenschaften der realen Sensordaten 4 – über die eigentlichen Messwerte hinaus, also auf einer Meta-Ebene – betreffen dabei insbesondere die Streuung der Daten, das Vorkommen von Zufallswerten abseits einer im Detail nachvollziehbaren physikalischen Erklärung, Begrenzungen der Messwerte etc.
Für die Übersetzung der realen Sensordaten 4 in eine Umgebungsrepräsentation 6 ist im Grunde immer eine Sensordatenfusion 5 erforderlich. Denn ab der zweiten Messung muss bereits eine zeitliche Fusion vorgenommen werden. Mehrere Sensoren an unterschiedlichen Orten erfordern eine örtliche Fusion der realen Sensordaten 4. Weiterhin müssen auch unterschiedliche Sensortypen, etwa Ultraschall und Kamera, unter besonderer Berücksichtigung ihrer Eigenschaften durch die Sensordatenfusion 5 fusioniert werden.
Ein erstes Ausführungsbeispiel betrifft ein Sensormodell für Ultraschallsensoren in einer Fahrerassistenzfunktion zum automatischen Einparken. Dieses Beispiel ist angelehnt an die Darstellungen in Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, Kap. 6. Die Applikation zum automatischen Einparken braucht als interne Umgebungsrepräsentation eine Karte der Umgebung, in der eine Parklücke identifiziert werden kann und dann eine Bahn in diese Parklücke hinein geplant werden kann. Diese Karte wird in der Regel eine Belegungsgitterkarte sein. Dazu wird die Ebene, in der sich das Fahrzeug befindet, meistens in quadratische, gleich große Zellen aufgeteilt, für die festgehalten wird, ob diese Zelle belegt ist oder nicht. Die Kantenlänge einer Zelle liegt meist zwischen 0.05 m und 1.0 m, kann aber auch kleiner oder größer sein. Eine solche Gitterkarte ist ein Beispiel für eine Umgebungsrepräsentation m der Umgebung.
Die Umgebungsrepräsentation kann beispielsweise über einen gewissen Zeitraum hinweg statisch sein, d. h. in ihr sollen die Teile der realen Umgebung e modelliert sein, die sich über eine gewisse Zeit hinweg nicht ändern. Alternativ bietet sich eine dynamische Umgebungsrepräsentation an, bei der Objekte mit ihrer Bewegungsrichtung und Geschwindigkeit eingetragen werden. Die Messung hängt ab von der realen Umgebung e. Bei der Herleitung der Umgebungsrepräsentation, z. B. nach 2A–2D und 3, wie auch sonst in der Literatur, wird dies gerne synonym genommen zu der Information in der Umgebungsrepräsentation m, also der Karte der Umgebung.
Im Folgenden fassen wir die Modellierung der Sensormesswerte zusammen, wie sie aus der Robotik bekannt ist (Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, Kap. 6). Um die passenden Algorithmen zur Herleitung einer internen Umgebungsrepräsentation aus Sensormesswerten zu entwickeln, versucht man zu modellieren, wie wahrscheinlich eine Messung z k / t ist, wenn das Fahrzeug an einer Position x_t in der Umgebung m ist, also die Wahrscheinlichkeitsdichtefunktion p(z k / t|x_t, m). Dabei hängt diese Wahrscheinlichkeitsdichtefunktion sowohl von den Eigenschaften des jeweiligen Sensors ab, als auch von Merkmalen der realen Umgebung.
In den 2A bis 2D werden vier typische Ingredienzien gezeigt (angelehnt an Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, Kap. 6). Die vertikale Achse bezeichnet jeweils p(z k / t|x_t, m). Die horizontale Achse bezeichnet den gemessenen Abstand und erreicht auf halbem Weg den tatsächlichen Abstand z k* / t.
In 2A ist die Wahrscheinlichkeitsdichtefunktion p_hit des Messwertes bei ungestörter Messung auf ein Objekt gezeigt. Auch hier ist der Messwert nicht immer gleich dem tatsächlichen Abstand z k* / t, sondern er streut abhängig von nicht modellierten und damit auch nicht kontrollierbaren Einflussgrößen (Wind, Luftfeuchtigkeit, Temperatur, Reflexionseigenschaften des Objekts, ...). Diese Streuung wird durch eine Normalverteilung modelliert. Sie spiegelt hauptsächlich physikalische Eigenschaften des Sensors wieder.
In 2B sind tatsächlich ermittelte Entfernungsmessungen erfasst, die auf nicht statische Objekte in der Umgebung zurückzuführen sind (Blätter, die vorbei wehen, Fußgänger etc.). Weil mehrere Objekte gleichzeitig und unabhängig voneinander auftreten können, und weil von mehreren Objekten immer das nächste gesehen wird und die anderen nicht, häuft sich diese Wahrscheinlichkeit bei kürzeren Abstandswerten. Diese Wahrscheinlichkeit p_short ist von der Umgebung abhängig.
In 2C ist die Tatsache erfasst, dass viele Ultraschallsensorsysteme in dem Fall, dass gar kein Echo gemessen wird, einen festen Maximalwert zurückgeben. Dieser Beitrag p_max ist sowohl von der Hardware des Sensors als auch von der Umgebung abhängig, besteht in Wirklichkeit also aus zwei Bestandteilen: z. B. welches Material wird vom Sensor nicht wahrgenommen, und wie häufig kommt dieses Material in der Umgebung vor.
In 2D wird schließlich modelliert, dass manche Sensoren gelegentlich rein zufällige Messwerte produzieren. Die Ursache könnte alles Mögliche sein: EMV-Probleme im Fahrzeug, elektromagnetische oder akustische Störstrahlung aus der Umgebung oder ähnliches. Der Fachmann geht dem mangels Daten und mangels hinreichend strenger Untersuchungsbedingungen nicht unbedingt nach, weshalb p_rand als Grundrauschen im Modell verbleibt.
Diese Komponenten werden mit nicht negativen Gewichten z_hit, z_short, z_max, z_rand zu einer Mixture Distribution zusammengefasst (wobei die Summe der Gewichte 1 ergibt): p(z k / t|x_t, m) = z_hit·p_hit(z k / t|x_t, m) + z_short·p_short(z k / t|x_t, m) + z_max·p_max(z k / t|x_t, m) + z_rand·p_rand(z k / t|x_t, m)
Diese Verteilung ist gezeigt in 3 (angelehnt an Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, Kap. 6). Alternativ lassen sich die Parameter in den Beiträgen aus 2A bis 2D und die Gewichte auch durch eine Maximum-Likelihood-Estimation aus den Messwerten ermitteln.
Es zeigt sich also deutlich, dass das aggregierte Vorwärts-Sensormodell, also die Schätzung der Messwerte, gegeben die Umgebung und den Zustand des Fahrzeugs in der Umgebung, nicht vom Sensor-Hardware-Experten allein erstellt werden kann, ebenso wenig wie vom Domänen-Experten allein. Vielmehr ist hierzu Expertise aus beiden Bereichen notwendig. In der Praxis werden die entsprechenden Kompetenzen im Entwicklungsteam für das jeweilige Modul zusammengeführt, und dann werden die Modelle durch Ingenieurskunst so lange angepasst, bis sie dem Sensorverhalten in der anvisierten Umgebung entsprechen.
Gemäß den folgenden Ausführungsbeispielen erfolgt nun eine separate und explizite Modellierung der Sensoreigenschaften (Sensormodell), der Umgebungseigenschaften (Umgebungsmodell) und des Typs und Inhalts der internen Umgebungsrepräsentation. Dabei wird im Entwurfsprozess die erforderliche Expertise über die Sensorhardware von der Expertise über Anwendungsbereiche entkoppelt.
4 zeigt ein Sensormodell 10, ein Fahrzeugmodell 15 und ein Umgebungsmodell 20, welche die Simulation einer virtuellen Messung 30 ermöglichen, woraus virtuelle Sensordaten 40 resultieren. Die zuvor angesprochene Entkopplung geschieht dadurch, dass im Sensormodell 10 zum Einen die Sensorhardware so ausführlich physikalisch modelliert wird, dass mittels einer geeigneten Simulation und aufgrund des entsprechend ausführlichen Umgebungsmodells 20 die virtuelle Messungen 30 für den Sensor simuliert werden können. Dabei wird nicht etwa ein deterministischer, also immer gleicher Messwert ermittelt, sondern die virtuellen Sensordaten 40 unterliegen den gleichen zufälligen Schwankungen wie die in Experimenten ermittelten realen Sensordaten (vgl. 1).
Das Sensormodell 10 enthält die physikalischen Eigenschaften des Sensors. Welche das sind, hängt natürlich von den jeweiligen Sensortypen ab. Im Folgenden werden die Anforderungen an das Sensormodell 10 am Beispiel eines Ultraschall-Entfernungssensors illustriert, bei dem nur das erste eintreffende Echo ausgewertet, bzw. der dem entsprechende Abstandswert zurückgeliefert wird.
Die erste Art von Ursachen der zufälligen Abweichungen in den Messwerten liegt dabei in der Sensor-Hardware. Hier können unterschiedliche physikalische Abhängigkeiten der Messwerte von entweder nicht modellierten oder nicht ermittelbaren Phänomenen innerhalb des Sensors zu Grunde liegen. Dies können z. B. Schwankungen in der Versorgungsspannung sein, zufällige Streuungen im Verhalten von analogen Schaltungsteilen wie Verstärkern oder Filtern, Diskretisierungsrauschen durch zufällige Verschiebungen von Abtastzeitpunkten, oder ähnliche mehr. Durch solche Phänomene können Pseudo-Messungen entstehen, die gar keinem äußeren physikalischen Sachverhalt entsprechen.
Eine weitere Art von Ursachen der zufälligen Abweichungen kann im Übertragungsmedium liegen. So hängen bei Ultraschallmessungen die Schallgeschwindigkeit und damit die Entfernungsmessung ab von Lufttemperatur, Luftdruck und Luftfeuchtigkeit (sowie von der Wellenlänge des Signals). Ebenso haben die Windverhältnisse einen wesentlichen Einfluss. Diese Einflüsse sind oft nicht bekannt. Oft ist auch nicht möglich, diese Größen aus anderen Messwerten zu schätzen, da das Phänomen selbst sich zufallsmäßig verhält, wie z. B. bei stark wechselnden Windverhältnissen. Diese Ursachen können zu scheinbar zufallsmäßigen Abweichungen, aber auch zum vollständigen Ausfall von Messungen führen.
Bei vielen Sensoren wird in dem Fall, dass gar keine Messung durchgeführt wird, dieses Ergebnis kodiert als ”maximaler Abstand” (vgl. 2C). Dieser ist im Grunde dann ebenfalls ein ”abweichender” Messwert, da diesem Wert kein Objekt in der Umgebung entspricht.
Diese Arten von Ursachen für abweichende Messwerte fallen in den Kompetenzbereich der Entwickler der Sensor-Hardware und der sensornahen Signalverarbeitungssoftware. Diese Experten können die entsprechenden Eigenschaften der von ihnen entwickelten Sensorhardware und Sensorsoftware am besten modellieren. Folglich werden diese Faktoren durch das Sensormodell 10 modelliert und dort beispielsweise durch Wahrscheinlichkeitsdichtefunktionen repräsentiert.
Im Sensormodell 10 müssen weiterhin die informationstheoretisch wichtigen Eigenschaften aufgeführt werden. Im Falle eines Ultraschallsensors umfassen diese die Sende- und Empfangsfrequenzbereiche bzw. Frequenzgänge, wie auch die Richtcharakteristik, die Filtereigenschaften, die Sendeenergie, die Empfangsempfindlichkeit. Das Sensormodell muss zum Zweck der aussagefähigen Simulation der Signale deutlich über die bisher üblichen Angaben hinausgehen.
Weiterhin sollte im Sensormodell 10 modelliert werden, welchen Einfluss die unterschiedlichen Zustände des Übertragungsmediums haben können, wobei dieser Einfluss am geeignetsten als Wahrscheinlichkeitsdichteverteilung über den Messwert, gegeben den Abstand zu einem normalisierten Objekt, modelliert wird. Da sich hier viele unterschiedliche Einflüsse überlagern, ist der Messwert, gegeben ein Objekt in einer bestimmten Entfernung, oft annähernd normalverteilt.
Ebenso sollten für die Integration in den mechanischen und elektrischen Entwurf die Abmessungen, das Gewicht, die elektrischen Anschlusswerte (Versorgungsspannung inkl. Toleranzbereichen, Versorgungsleistung) im Sensormodell 10 aufgeführt werden.
Diese Angaben sollten möglichst aus sich heraus unmissverständlich sein, also sollten bei allen physikalischen Werten auch die Einheiten und möglichen Schwankungen mit genannt sein. Vorteilhaft ist es, sie als Zufallsvariable zu modellieren, da dafür aus der Mathematik anerkannte, aussagefähige Modelle und Algorithmen zur Verfügung stehen.
Das Umgebungsmodell 20 enthält diejenigen physikalischen Eigenschaften der Umgebung, die zur Simulation bzw. Herleitung der ”ground truth” der internen Umgebungsrepräsentation benötigt werden: Für jedes Sensormodell 10, das verwendet werden soll, müssen im Umgebungsmodell 20 die entsprechenden physikalischen Eigenschaften der Umgebung enthalten sein.
Für eine Videokamera als Sensor umfassen diese Eigenschaften die Geometrie und die Texturen (optischen Reflexionseigenschaften) der Objekte. Zahlreiche sehr weit entwickelte Beispiele für solche Umgebungsmodelle 20 finden sich in den Bereichen Computeranimation für Filme, Computerspiele, Architektursimulation, etc. Bei diesen Umgebungsmodellen 20 werden z. T. auch Eigenschaften des Übertragungsmediums mit simuliert (Nebel, Regen, Schnee, ...) sowie Eigenschaften der Beleuchtung.
Für die Simulation eines Ultraschallsensors reicht als Umgebungsmodell 20 eine Approximation der Geometrie zusammen mit den akustischen Reflexionseigenschaften. Je nach Simulationsprinzip werden die Objekte im Umgebungsmodell 20 so modelliert, dass Schnitte mit Strahlen berechnet werden können, oder dass die Reflektion von Wellen an den Oberflächen berechnet werden kann. Dazu werden dann auch die Normalen auf den Oberflächen benötigt.
Die Formate, in denen zum Einen das Sensormodell 10 und zum Anderen das Umgebungsmodell 20 aufgestellt sind, müssen zu den entsprechenden Simulatoren passen. Hierzu empfiehlt sich eine Standardisierung, die allerdings einen gewissen Freiraum lassen sollte. Aussichtsreichster Kandidat dafür ist auch hier eine probabilistische Formulierung, d. h. die entsprechenden Parameter werden als Zufallsvariable aufgefasst.
Im Umgebungsmodell 20 werden grundsätzlich die Phänomene repräsentiert, die zu Messungen führen. Das ist natürlich in jedem Fall eine Approximation, da in der Regel nicht jedes Blatt eines Baumes einzeln modelliert werden kann. Hier gilt es dann, geeignete approximative Modelle zu formulieren und zu validieren, z. B. dass ein Gebüsch Ultraschallsignale in alle Richtungen reflektieren wird, die allerdings aufgrund von Dämpfung oder nicht genau passenden Flächennormalen nur mit einer gewissen Wahrscheinlichkeit als Echo aufgenommen werden.
Es werden im Umgebungsmodell 20 auch die Phänomene repräsentiert, die zu Messungen führen, die aber nicht zu Einträgen in die interne Umgebungsrepräsentation beitragen sollen. Zum Beispiel kann für die Planung einer Bahn zum automatischen Einparken eine interne Umgebungsrepräsentation der statischen Anteile der Umgebung des Fahrzeugs erforderlich sein. Dynamische Objekte wären dagegen Blätter, die vorbeiwehen, oder Fußgänger, die vorbeigehen (vgl. 2B). Diese Phänomene kann am besten der Domänenexperte auswählen und beschreiben. Die resultierenden Messwerte sind Rauschen in Bezug auf die statischen Anteile der Umgebung. Soll die interne Umgebungsrepräsentation auch die dynamischen Objekte erfassen, dann sind die resultierenden Messwerte nicht mehr Rauschen, sondern Teil des Signals.
In diesem Kontext beschreibt das Fahrzeugmodell 15, wo sich die Sensoren relativ zum Fahrzeug befinden. In erster Linie sind hier die geometrischen Verhältnisse relevant. Es können aber auch elektrische Verhältnisse relevant werden, wenn z. B. laut Sensormodell 10 Schwankungen in der Versorgungsspannung zu erhöhtem Rauschen bei den Messwerten führen können. In diesem Fall ist auch die Versorgungsspannung (ggf. als Zufallsvariable) Teil des Fahrzeugmodells 15.
Die Sensorsimulation erstellt aus dem Sensormodell 10 und dem Umgebungsmodell 20 die gleichen virtuellen Sensordaten 40, wie sie auch die echten Sensoren in einer realen Einsatzumgebung erzeugen würden. Die Simulation kann als Eingangswerte Zufallsvariable verarbeiten, und auch die virtuellen Sensordaten 40 sind Zufallsvariable, und ihre Wahrscheinlichkeitsdichteverteilung wird mit simuliert.
Die Simulation kann dabei auf sehr unterschiedlichen Genauigkeitsstufen erfolgen, wobei in der Regel ein umso höherer Speicherplatz- und Rechenzeitbedarf entsteht, je genauer die Simulation ist.
Eine sehr einfache Simulation beruht darauf, dass für eine diskrete, oft sehr kleine Zahl von vom Sensor ausgehenden Strahlen die Schnittpunkte dieser Strahlen mit Objekten in der Umgebung gebildet werden. Dazu müssen also im Umgebungsmodell 20 die Schnittpunkte von Strahlen mit Objekten gebildet werden können. Diese Simulation vernachlässigt die Reflektion von akustischen Wellen an Flächen und liefert somit mehr Messwerte als der physikalische Sensor.
In einer anderen Simulationsmethode werden zusätzlich zu den Schnittpunkten der Strahlen mit den Oberflächen auch die Normalenvektoren auf den Oberflächen an den Schnittpunkte berücksichtigt. Dadurch kann man beurteilen, ob eine Schallwelle zu einem Empfänger hin reflektiert wird (dies kann auch der Sender sein) und somit ein Echo gemessen wird, oder ob kein Echo gemessen wird.
Eine weitere Simulationsmethode wird deutlich stärker von einem Typ der internen Umgebungsrepräsentation geprägt. Konkret wird hier das Volumen der internen Umgebungsrepräsentation in Gitterzellen zerlegt und der Verlauf der Druckverteilung über die Zeit simuliert. Dieses Verfahren (je nach Auflösung, d. h. Größe der Gitterzellen und Zeitintervalle) simuliert die Echos von sehr zerklüfteten Hindernissen, und simuliert auch Echos die über mehrere Reflektoren zu einem Empfänger gelangen, so genannte Multi-Path Echos.
Beispielsweise sendet der Ultraschallsensor ein kegelförmiges Signal aus. Ein Echo kann durch einen Kreissegment innerhalb dieses Kegels beschrieben werden, dessen Radius der gemessenen Entfernung entspricht. Entsprechend wird eine Wahrscheinlichkeit eines Hindernisses in allen Zellen erhöht, die von dem Kreissegment geschnitten werden, und in allen Zellen erniedrigt, die auf dem Weg dorthin vom Strahl passiert wurden.
Durch die Vereinbarung von Formaten können das Sensormodell 10, das Umgebungsmodell 20 und das Fahrzeugmodell 15 von verschiedenen Lieferanten stammen und dennoch zusammenpassen. Ähnliche de facto Standards existieren bereits im Bereich CAD (z. B. das STEP Format). Im Kontext der Ausführungsbeispiele werden Standards benötigt, in denen auch die Wahrscheinlichkeitsdichtefunktionen beschrieben werden können.
Bei der expliziten Trennung der Modellierung kann das Sensormodell 10 vom Sensorhersteller stammen. Das Umgebungsmodell 20 kann von einer Firma stammen, die sich auf die 3D Modellierung spezialisiert hat. Der Simulator kann wiederum von einer Firma stammen, die sich auf Simulation spezialisiert hat. Das Fahrzeugmodell steuert in Zukunft der Systemintegrator bei. Verwendet werden die Modelle und der Simulator normalerweise vom Systemintegrator, also einem Automobilhersteller oder -designer.
Damit auf die Aussagefähigkeit der Sensormodelle Verlass ist, sollen diese Modelle validiert werden. 5 zeigt ein Validierungsverfahren, die virtuellen Sensordaten 40 mit experimentell ermittelten realen Sensordaten 4 zu vergleichen, wobei jede der beteiligten Parteien mit ihren eigenen Modellen zusammen mitteilt, welche anderen Modelle bzw. Simulationstools dem Vergleich zugrunde liegen.
Der Sensorhersteller z. B. stellt eine Reihe von repräsentativen Testumgebungen her, d. h. er baut sie tatsächlich auf. Eine solche Testumgebung ist in 5 als reale Umgebung 2 eingezeichnet. Diese Testumgebungen werden nach den Maßgaben der Umgebungsmodellhersteller (und idealerweise von einem Mitarbeiter eines Umgebungsmodellherstellers) im Hinblick auf die physikalischen Wirkprinzipien des Sensors 1 und auf die formalen Anforderungen der Simulationstools modelliert. Hier zeigt sich dann bereits, dass diese Formate standardisiert sein sollten.
Der Sensor 1 misst in einer realen Messung 3 in der realen Umgebung 2 die realen Sensordaten 4. Unabhängig davon werden in einem Simulator anhand eines Sensormodells 10 und eines Umgebungsmodell 20 virtuelle Messungen 30 durchgeführt, die virtuelle Sensordaten 40 ergeben.
Schließlich werden die realen Sensordaten 4 mit den virtuellen Sensordaten 40 verglichen. Das Ergebnis dieses Vergleichs stellt der Sensorhersteller zusammen mit seinem Sensormodell 10 zur Verfügung. Das erlaubt dem Systemintegrator, die Güte der Approximation der realen Verhältnisse durch das Sensormodell 10 (unter Mitwirken von Umgebungsmodell 20 und Simulation) zu beurteilen. Diese Güte der Approximation ist relevant bei dem weiteren Entwurfsprozess eines Fahrerassistenzsystems.
Durch die getrennte Modellierung (im Sensormodell 10) und physikalische Simulation (im Umgebungsmodell 20) lassen sich die verschiedenen Beiträge von physikalischer Sensorhardware und von Sensorsignalkonditionierung (Sensormodell 10) auf der Ebene der Systemintegration trennen von den Einflüssen aus der Einsatzumgebung (Umgebungsmodell 20). Dabei braucht der Systemintegrator keine Expertise mehr über die Sensorhardware, da diese im Sensormodell 10 erfasst ist. Durch die Simulation des Gesamtsystems (Sensormodell 10 + Fahrzeugmodel 15 + Umgebungsmodell 20) wird so das für die gegebene Applikation relevante Vorwärtssensormodell entwickelt.
Davon unbenommen bleibt die Möglichkeit, das simulierte Vorwärtssensormodell an echten Daten zu validieren bzw. Parameter in diesem Modell zu schätzen.
Das Umgebungsmodell 20 muss sich nicht auf eine Geometrie beschränken, sondern kann auch Domänenwissen bezüglich einer Wahrscheinlichkeit von Ereignissen und/oder Relevanz von Objekten enthalten, beispielsweise, wie häufig Personen auf einer Fahrbahn auftauchen, oder dass Kindern eine höhere Relevanz als geparkten Autos zukommt.
Ferner kann das Umgebungsmodell modular in die beiden zuvor genannten Komponenten Geometrie und Domänenwissen aufgetrennt und von verschiedenen Herstellern bereitgestellt werden.
Die beschriebenen Ausführungsbeispiele, Ausführungsformen, Varianten und Weiterbildungen lassen sich frei miteinander kombinieren.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102004052242 A1 [0013]
WO 2007/017308 A1 [0014]

Zitierte Nicht-Patentliteratur

Thrun, Burgard und Fox: ”Probabilistic Robotics”, MIT Press 2005, Kap. 6 [0069]
Thrun, Burgard und Fox: ”Probabilistic Robotics”, MIT Press 2005, Kap. 6 [0071]
Thrun, Burgard und Fox: ”Probabilistic Robotics”, MIT Press 2005, Kap. 6 [0072]
Thrun, Burgard und Fox: ”Probabilistic Robotics”, MIT Press 2005, Kap. 6 [0078]

Claims

Sensorprodukt, – umfassend einen Sensor (1), eingerichtet zur Erzeugung realer Messungen (3), welche reale Sensordaten (4) erzeugen, die eine reale Umgebung (2) zumindest teilweise abbilden, – wobei die reale Umgebung insbesondere eine Umgebung eines Fahrzeugs, ein Fahrzeug mit Zuständen und/oder ein Fahrer eines Fahrzeugs ist, – wobei der Sensor insbesondere eine 2D- oder 3D-Kamera, ein Ultraschallsensor, ein 2D- oder 3D-Laserscanner, ein 2D- oder 3D-Radar, ein Lidar, ein Raddrehungssensor, ein Inertialsensor, ein Beschleunigungssensor, ein Drehratensensor, ein Temperatursensor, ein Luftfeuchtesensor, ein Positionssensor zur Bestimmung zumindest eines Parameters der Fahrdynamik eines Fahrzeuges, ein Sitzbelegungssensor oder ein Entfernungssensor ist, gekennzeichnet durch ein Sensormodell (10), – welches, insbesondere als Programmcode oder XML-Dokument, auf einem Datenträger gespeichert ist, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer Cloud, – welches eine Hardware und/oder physikalische Eigenschaften des Sensors (1) beschreibt und/oder virtuell modelliert derart, dass ein Simulator, welcher nicht Teil des Sensorprodukts ist, durch Einlesen des Sensormodells (10) von dem Datenträger in die Lage versetzt wird, virtuelle Messungen (30) des Sensors (1) in einem Umgebungsmodell (20), welches nicht Teil des Sensorprodukts ist, zu simulieren, indem das Sensormodell (10) Programmcode für den Simulator bereitstellt oder Programmcode des Simulators parametriert, und – welches von dem Umgebungsmodell (20), welches nicht Teil des Sensorprodukts ist, modular getrennt und unabhängig ist.
Sensorprodukt nach Anspruch 1, – bei dem das Sensormodell (10) ein vorbestimmtes Format und/oder eine Schnittstelle eines vorbestimmten Formats aufweist.
Sensorprodukt nach Anspruch 1 oder 2, – bei dem die Beschreibung und/oder virtuelle Modellierung der Hardware und/oder der physikalischen Eigenschaften des Sensors (1) zumindest teilweise eine probabilistische Beschreibung mit Wahrscheinlichkeitsdichtefunktionen ist.
Sensorprodukt nach Anspruch 3, – bei dem das Sensormodell (10) zufällige Abweichungen in den realen Sensordaten (4), deren Ursachen in einer Hardware des Sensors (1) liegen, als Wahrscheinlichkeitsdichtefunktion modelliert.
Sensorprodukt nach Anspruch 3 oder 4, – bei dem das Sensormodell (10) zufällige Abweichungen in den realen Sensordaten (4), deren Ursachen in Schwankungen in einem Übertragungsmedium oder unterschiedlichen abgebildeten Materialien liegen, als Wahrscheinlichkeitsdichtefunktion modelliert.
Sensorprodukt nach einem der vorangegangenen Ansprüche, – bei dem der Sensor (1) ein Ultraschall-Entfernungssensor ist, und bei dem das Sensormodell (10) mehrere oder alle der folgenden physikalischen Eigenschaften des Sensors (1) modelliert: – Sende- und Empfangsfrequenzbereiche bzw. Frequenzgänge, – Richtcharakteristik, – Filtereigenschaften, – Sendeenergie, und – Empfangsempfindlichkeit; oder – bei dem der Sensor (1) eine Kamera ist, und bei dem das Sensormodell (10) mehrere oder alle der folgenden physikalischen Eigenschaften des Sensors (1) modelliert: – Auflösung, – Farbspektrum, – Brennweite, und – Blende und Verschlusszeit.
Sensorprodukt nach einem der vorangegangenen Ansprüche, – welches zusätzlich mindestens ein Umgebungsmodell (20) umfasst, welches auf einem Datenträger, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer Cloud, gespeichert ist, – wobei das Umgebungsmodell (20) eine Beschreibung einer virtuellen Umgebung enthält, welche einem Simulator erlaubt, anhand des Sensormodells (10) virtuelle Messungen (30) des Sensors (1) in der virtuellen Umgebung zu simulieren, – wobei die virtuelle Umgebung insbesondere eine virtuelle Welt, ein Fahrer in einem Fahrzeugcockpit oder ein Fahrzeug mit internen Zuständen ist, – wobei das Umgebungsmodell (20) von dem Sensormodell (10) modular getrennt und unabhängig ist, und – wobei das Umgebungsmodell (20) ein standardisiertes Format aufweist, welches die Verwendung des Umgebungsmodells (20) mit unterschiedlichen Sensormodellen (10) und/oder Simulatoren erlaubt.
Sensorprodukt nach Anspruch 7, – bei dem der Sensor (1) eine Kamera ist und das Umgebungsmodell (20) einem Simulator erlaubt, ein Kamerabild zu simulieren, – bei dem das Umgebungsmodell (20) insbesondere enthält: – ein 3D-Modell mit texturierten Polygonen, welches ein reales Vorbild approximiert, – Trübungen des Übertragungsmediums durch Nebel, Regen oder Schnee, und/oder – Beleuchtungsverhältnisse.
Sensorprodukt nach Anspruch 7, – bei dem der Sensor (1) ein Ultraschallsensor ist und das Umgebungsmodell (20) einem Simulator erlaubt, ein Ultraschallbild zu simulieren, – indem das Umgebungsmodell insbesondere ein 3D-Modell enthält, welches ein reales Vorbild approximiert und vereinfacht, und wobei das 3D-Modell Polygone und Angaben zu Reflexionseigenschaften und/oder Oberflächennormalen der Polygone enthält.
Sensorprodukt nach einem der Ansprüche 7 bis 9, – welches zusätzlich eine modulare Simulator-Software umfasst, welche auf einem Datenträger, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer Cloud, gespeichert ist, und welche zu einer Simulation von virtuellen Messungen (30) des Sensors (1) in dem Umgebungsmodell (20) nach einem Einlesen des Sensormodells (10) eingerichtet ist.
Simulator, – mit einer Recheneinheit, welche programmiert ist zur Simulation von virtuellen Messungen (30) mindestens eines Sensors (1) eines Sensorprodukts nach einem der Ansprüche 1 bis 10 in mindestens einem Umgebungsmodell (20) basierend auf dem Sensormodell (10) des Sensorprodukts.
Simulator nach Anspruch 11, – mit einem Sensor-Simulationsmodul, welches dazu eingerichtet ist, das Sensormodell (10) von dem Datenträger einzulesen, – wodurch Programmcode für das Sensor-Simulationsmodul bereitgestellt wird, oder – wodurch Programmcode des Sensor-Simulationsmoduls parametriert wird, und – wobei der Sensor (1) durch das Sensor-Simulationsmodul simuliert wird, und – wobei das Sensor-Simulationsmodul eine eigene Hardware umfasst und/oder virtuell in einer Recheneinheit als Programmcode ausgeführt wird.
Verfahren zur Simulation von Sensormessungen, – bei dem eine Recheneinheit ein Sensormodell (10) von einem Datenträger einliest, – bei dem das Sensormodell (10) eine Hardware und/oder physikalische Eigenschaften eines Sensors (1) beschreibt und/oder virtuell modelliert, wobei der Sensor (1) zur Abbildung einer realen Umgebung (2) mittels realer Messungen (3), die reale Sensordaten (4) erzeugen, eingerichtet ist, – wobei die reale Umgebung insbesondere eine Umgebung eines Fahrzeugs, ein Fahrzeug mit Zuständen oder ein Fahrer eines Fahrzeugs ist, – bei dem die Recheneinheit anhand des Sensormodells (10) virtuelle Messungen (30) des Sensors (1) in einem Umgebungsmodell (20) simuliert, und – bei dem das Sensormodell (10) von dem Umgebungsmodell (20) modular getrennt und unabhängig ist.
Verfahren nach Anspruch 13, – bei dem ein Fahrzeugmodell (15) eine geometrische Position des Sensors (1) relativ zu einem Fahrzeug und insbesondere eine Versorgungsspannung angibt, mit der der Sensor (1) von dem Fahrzeug versorgt wird, und – bei dem das Fahrzeugmodell (15) bei der Simulation berücksichtigt wird.
Verfahren nach Anspruch 13 oder 14, – bei dem die Recheneinheit zur Simulation der virtuellen Messungen (30) für eine Anzahl von von dem Sensor (1) ausgehenden Strahlen Schnittpunkte mit Polygonen im Umgebungsmodell (20) berechnet, wobei insbesondere Normalenvektoren der Polygone an den Schnittpunkten bei der Ermittlung eines Ultraschall-Echos berücksichtigt werden.
Verfahren zur Fusion von Sensormessungen, – bei dem – mit mindestens einem Sensorprodukt nach einem der Ansprüche 1 bis 10 reale Messungen (3) in einer realen Umgebung (2) durchgeführt werden, wodurch reale Sensordaten (4) erzeugt werden, oder – für mindestens ein Sensorprodukt nach einem der Ansprüche 1 bis 10 virtuelle Messungen (30) mittels der Simulator-Software nach Anspruch 10, mittels des Simulators nach Anspruch 11 oder 12 oder mittels des Verfahrens nach einem der Ansprüche 13 bis 15 in einem Umgebungsmodell (20) simuliert werden, wodurch virtuelle Sensordaten (40) erzeugt werden, und – bei dem eine Recheneinheit Wahrscheinlichkeitsdichtefunktionen, welche in dem Sensormodell (10) des Sensorprodukts enthalten sind, verwendet, um die realen Sensordaten (4) oder virtuellen Sensordaten (40) als Zufallsvariable und/oder Wahrscheinlichkeitsdichtefunktionen in einer Umgebungsrepräsentation (6) eines vorgegebenen Typs abzuspeichern, – bei dem – die realen Sensordaten (4) oder virtuellen Sensordaten (40) zu unterschiedlichen Zeitpunkten erzeugt und in der Umgebungsrepräsentation (6) zeitlich fusioniert werden, – die realen Sensordaten (4) oder virtuellen Sensordaten (40) für Sensoren (1) mit unterschiedlichen Positionen erzeugt und in der Umgebungsrepräsentation (6) örtlich fusioniert werden, und/oder – die realen Sensordaten (4) oder virtuellen Sensordaten (40) für Sensoren (1) unterschiedlichen Typs erzeugt und in der Umgebungsrepräsentation (6) fusioniert werden, und – bei dem der vorgegebene Typ der Umgebungsrepräsentation (6) insbesondere eine 2D- oder 3D-Gitterkarte, eine Objektliste oder eine Liste von Zuständen ist.
Verfahren zur Validierung eines Sensormodells (10), – bei dem mit einem Sensorprodukt nach einem der Ansprüche 1 bis 10 reale Sensormessungen (3) in einer realen Umgebung (2) durchgeführt werden, wodurch reale Sensordaten (4) erzeugt werden, – bei dem mit dem Verfahren nach einem der Ansprüche 13 bis 15 virtuelle Sensormessungen (30) in einem Umgebungsmodell (20), welches die reale Umgebung (2) nachbildet, simuliert werden, wodurch virtuelle Sensordaten (40) erzeugt werden, – bei dem die realen Sensordaten (4) mit den virtuellen Sensordaten (40) verglichen werden, und – bei dem aus dem Vergleich eine Güteinformation abgeleitet wird, welche in das Sensormodell (10) des Sensorprodukts nach einem der Ansprüche 1 bis 10 aufgenommen wird.
Verfahren zum Entwurf eines Fahrerassistenzsystems, – bei dem ein Sensorprodukt nach einem der Ansprüche 1 bis 10 für den Einsatz in einem Fahrerassistenzsystem vorgesehen wird, – bei dem unter Nutzung des Simulationsverfahrens nach einem der Ansprüche 13 bis 15 und/oder des Fusionsverfahren nach Anspruch 16 – ein geeigneter Typ für die Umgebungsrepräsentation (6) für das Fahrerassistenzsystem ausgewählt wird, und/oder – geeignete Typen und/oder geeignete Positionen für Sensoren für das Fahrerassistenzsystem ausgewählt werden, und – bei dem das Sensorprodukt in den mechanischen und elektrischen Entwurf integriert wird, wobei diesbezügliche Informationen im Sensormodell (10) verwendet werden.
Computerlesbarer Datenträger, – auf dem ein Computerprogramm gespeichert ist, welches das Verfahren nach einem der Ansprüche 13 bis 18 ausführt, wenn es in einem Mikroprozessor abgearbeitet wird.
Computerprogramm, – welches in einem Mikroprozessor abgearbeitet wird und dabei das Verfahren nach einem der Ansprüche 13 bis 18 ausführt.