DE102013213807A1

DE102013213807A1 - Anordnung und Verfahren zur Sensorfusion sowie Herstellungsverfahren zur Erstellung eines Fusionsmodells

Info

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

Abstract

Als Fusionsmodell (8) wird eine Rechenregel eingeführt, welche es erlaubt, anhand Sensordaten (4, 40) geeignete Änderungen in einer Umgebungsrepräsentation (6), d. h. in der internen, durch eine Fahrerassistenzapplikation wahrgenommene Schätzung der Umgebung, zu ermitteln. Es handelt sich bei dem Fusionsmodell (8) somit beispielsweise um eine Rechenregel, welche angibt, wie die Sensordaten (4, 40) in Bezug auf einen Umgebungsrepräsentations-Typ (beispielsweise Gitterkarte oder Objektliste) zu interpretieren sind, und nach der die Sensordaten (4, 40) in die Umgebungsrepräsentation (6) umgerechnet werden können. Die tatsächlichen Änderungen in der Umgebungsrepräsentation (6) werden jedoch von einer modular getrennten Inferenzmaschine (80) vorgenommen, welche hierzu das Fusionsmodell (8) interpretiert. Die modulare Aufteilung der Sensorfusion in Fusionsmodell (8) und Inferenzmaschine (80) verringert Abhängigkeiten bei der Entwicklung von Fahrerassistenzsystemen und ermöglicht somit eine flexiblere Arbeitsteilung. Ferner wird ein Aufwand bei Entwurfs- und Testzyklen reduziert. Durch die Modularisierung können die Entwicklungsaufgaben stärker unter den Lieferanten aufgeteilt werden. Weiterhin lässt sich das Fusionsmodell (8) nun durch maschinelles Lernen erstellen, indem es beispielsweise als Faktorgraph formuliert und durch Lösung eines gemischt diskretkontinuierlichen Optimierungsproblems parametriert wird.

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.
Ein wesentlicher Schritt im Entwurf von Fahrerassistenzsystemen ist die Herleitung von internen Repräsentationen der Umgebung, des Fahrzeugs und des Fahrers aus den Messwerten von einem oder mehreren Sensoren, im Folgenden als Fusionsalgorithmus bezeichnet. In einem Fahrzeug werden heutzutage mehrere Fahrerassistenzapplikationen integriert. Die Festlegung des Fusionsalgorithmus sowie die Implementierung der eigentlichen Applikation auf Grund der verwendeten Umgebungsrepräsentation liegen herkömmlicherweise in der Hand des jeweiligen Entwicklers.
Der konkrete Fusionsalgorithmus bleibt dabei der Erfahrung und dem Fingerspitzengefühl des jeweiligen Entwicklers überlassen und wird in der Regel von Hand entwickelt. Ein entscheidendes Element dieser Entwicklung ist die Art und Weise, wie aus Sensordaten auf die Umgebungsrepräsentation geschlossen werden kann, also das inverse Sensormodell. Der manuelle Entwurf bzw. das manuelle Parametrieren dieses inversen Sensormodells erfordert allerdings wieder Expertise über sämtliche anderen verwendeten Systeme, Modelle und Repräsentationen. Der jeweilige Entwickler muss daher die Eigenheiten der eingesetzten Sensoren und des Umgebungsrepräsentations-Typs genau kennen. Ferner benötigt er Expertenwissen über die Techniken des Schließens unter Unsicherheit.
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.
Nach gegenwärtigem Stand ist es im Entwurf von Fahrerassistenzsystemen somit üblich, den Fusionsalgorithmus von Hand zu entwerfen und anschließend experimentell bzw. in Simulation zu überprüfen, wie gut die resultierende Umgebungsrepräsentation den Ansprüchen der Fahrerassistenzapplikation genügt.
Es stellt sich die Aufgabe, eine Anordnung und ein Verfahren zur Sensorfusion sowie ein Herstellungsverfahren zur Erstellung eines Fusionsmodells anzugeben, welche eine Wiederverwendbarkeit der entsprechenden Anordnungen und Verfahren erhöhen und/oder Entwicklungsarbeiten im Bereich der Sensorfusion vereinfachen.
Diese Aufgabe wird erfindungsgemäß durch eine Anordnung zur Sensorfusion gelöst,

– umfassend eine Schnittstelle zum Empfang realer Sensordaten oder virtueller Sensordaten,
– umfassend einen Speicher, auf welchem eine Umgebungsrepräsentation gespeichert ist, welche einem vorgegebenen Umgebungsrepräsentations-Typ entspricht, gekennzeichnet durch
– eine Inferenzmaschine, in welcher ein Computerprogramm abgearbeitet wird, welches eingerichtet ist, anhand eines modular von der Inferenzmaschine getrennten Fusionsmodells Änderungen in der Umgebungsrepräsentation vorzunehmen, welche die realen Sensordaten oder virtuellen Sensordaten mit der Umgebungsrepräsentation fusionieren.

Auf dem computerlesbaren Datenträger ist ein Fusionsmodell gespeichert, welches für eine Verwendung durch die Inferenzmaschine der Anordnung eingerichtet ist.
Weiterhin wird die Aufgabe erfindungsgemäß durch ein Verfahren zur Sensorfusion gelöst,

– bei dem reale Sensordaten oder virtuelle Sensordaten empfangen werden,
– bei dem auf eine Umgebungsrepräsentation zugegriffen wird, welche einem vorgegebenen Umgebungsrepräsentations-Typ entspricht, dadurch gekennzeichnet, dass
– eine Inferenzmaschine rechnergestützt anhand eines modular von der Inferenzmaschine getrennten Fusionsmodells Änderungen in der Umgebungsrepräsentation vornimmt, welche die realen Sensordaten oder virtuellen Sensordaten mit der Umgebungsrepräsentation fusionieren.

Außerdem wird die Aufgabe erfindungsgemäß durch ein Herstellungsverfahren zur Erstellung eines Fusionsmodells gelöst,

– bei dem rechnergestützt anhand eines Sensormodells virtuelle Messungen in einem Umgebungsmodell simuliert und anhand der virtuellen Messungen virtuelle Sensordaten erzeugt werden, die ein Umgebungsmodell zumindest teilweise abbilden,
– bei dem ein Fusionsmodell mindestens eine Rechenregel, mindestens eine Datenstruktur, mindestens eine Funktion und/oder mindestens einen Algorithmus angibt, welche die virtuellen Sensordaten als Eingabe erhält und als Ausgabe entsprechende Änderungen in einer Umgebungsrepräsentation mit einem vorgegeben Umgebungsrepräsentations-Typ vorschreibt,
– bei dem das Fusionsmodell durch rechnergestütztes maschinelles Lernen erstellt wird, wobei
– eine Ziel-Umgebungsrepräsentation aus dem Umgebungsmodell und dem Umgebungsrepräsentations-Typ hergeleitet wird, welche ein Trainingsziel für das maschinelle Lernen vorgibt,
– das Fusionsmodell durch Lösung eines kontinuierlichen Optimierungsproblems parametriert wird,
– eine von dem Fusionsmodell modular getrennte Inferenzmaschine rechnergestützt anhand des Fusionsmodells (8) und der realen Sensordaten oder virtuellen Sensordaten Änderungen in der Umgebungsrepräsentation vornimmt, welche die realen Sensordaten oder virtuellen Sensordaten mit der Umgebungsrepräsentation fusionieren,
– die Umgebungsrepräsentation mit der Ziel-Umgebungsrepräsentation verglichen wird, woraus sich ein Fehler ergibt, welcher bei der Lösung des kontinuierlichen Optimierungsproblems minimiert wird.

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 ausgeführten Vorteile und Erläuterungen müssen nicht notwendigerweise die Gegenstände der unabhängigen Patentansprüche betreffen. Vielmehr kann es sich hierbei auch um Vorteile oder Aspekte handeln, welche lediglich einzelne Ausführungsformen, Varianten oder Weiterbildungen betreffen.
Als Fusionsmodell wird mindestens eine Rechenregel, mindestens eine Datenstruktur, mindestens eine Funktion und/oder mindestens ein Algorithmus verstanden, welche(r) es erlaubt, anhand Sensordaten geeignete Änderungen in einer Umgebungsrepräsentation zu ermitteln. Wie eingangs definiert ist die Umgebungsrepräsentation hierbei eine interne, durch eine Fahrerassistenzapplikation wahrgenommene Schätzung der Umgebung. Es handelt sich bei dem Fusionsmodell somit beispielsweise um eine Rechenregel, welche die Sensordaten in die Umgebungsrepräsentation übersetzt – mit anderen Worten eine Umrechnungsvorschrift, welche angibt, wie die Sensordaten in Bezug auf einen Umgebungsrepräsentations-Typ (beispielsweise Gitterkarte oder Objektliste) zu interpretieren sind, und nach der die Sensordaten in die Umgebungsrepräsentation umgerechnet werden können.
Die tatsächlichen Änderungen in der Umgebungsrepräsentation werden nicht von dem Fusionsmodell, sondern von der Inferenzmaschine vorgenommen, welche hierzu das Fusionsmodell interpretiert. Folglich besteht zumindest funktional eine modulare Trennung zwischen der Inferenzmaschine und dem Fusionsmodell. Die modulare Trennung bedeutet hierbei, dass das Fusionsmodell austauschbar, trainierbar oder veränderbar ist, ohne dass hierbei eine Anpassung der Inferenzmaschine zu erfolgen hätte, welche über die bloße Bereitstellung des neuen Fusionsmodells hinausgehen würde. Folglich kann das Fusionsmodell außerhalb oder innerhalb der Inferenzmaschine angeordnet sein. Ferner kann die Inferenzmaschine als Mikroprozessor, Softwareprogramm oder virtuelle Maschine implementiert werden. Es handelt sich bei der modularen Trennung somit um eine funktionale bzw. logische Trennung. Ergänzend kann optional auch eine räumliche Trennung vorgesehen werden, indem der Speicherort des Fusionsmodells von der Inferenzmaschine separiert wird.
Die funktionale Trennung des Sensormodells ermöglicht es, einem Entwickler von Fahrerassistenzfunktionen eine Entwurfsbibliothek mit einer Vielzahl hochentwickelter Fusionsmodelle zur Verfügung zu stellen, ohne dass der Entwickler selbst eine vollständige Expertise über die jeweiligen Algorithmen besitzen muss.
Bei dem Herstellungsverfahren für das Fusionsmodell wird als Umgebungsrepräsentations-Typ beispielsweise einer der folgenden vorgegeben: 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.
Die modulare Aufteilung der Sensorfusion in Fusionsmodell und Inferenzmaschine verringert Abhängigkeiten bei der Entwicklung von Fahrerassistenzsystemen und ermöglicht somit eine flexiblere Arbeitsteilung. Ferner wird ein Aufwand bei Entwurfs- und Testzyklen reduziert. Durch die Modularisierung können die Entwicklungsaufgaben stärker unter den Lieferanten aufgeteilt werden.
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 bestehende Sensoren und Inferenzmaschinen zur Sensorfusion wiederverwendet werden, indem deren Fusionsmodelle geeignet modifiziert 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.
Die Inferenzmaschine sowie weitere benötigte Recheneinheiten, Simulatoren etc. können hardwaretechnisch und/oder auch softwaretechnisch implementiert werden. Bei einer hardwaretechnischen Implementierung kann sie 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 ist die Inferenzmaschine ein graphenbasierter generischer probabilistischer Inferenzapparat. Das Fusionsmodell beinhaltet einen Faktorgraphen.
Weiterhin existiert eine Weiterbildung,

– bei der sowohl die Umgebungsrepräsentation auch die virtuellen Sensordaten Zufallsvariable enthalten,
– bei der der Faktorgraph des Fusionsmodells jede dieser Zufallsvariablen in einem Variablenknoten abbildet, und
– bei der der Faktorgraph Faktorknoten enthält, welche die Variablenknoten verbinden und bedingte Wahrscheinlichkeiten zwischen den Variablenknoten beschreiben.

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

– bei dem der Fehler anhand einer Fehlerfunktion ermittelt wird, welche Anforderungen einer Fahrerassistenzfunktion berücksichtigt.

In einer Weiterbildung ergibt sich ein Herstellungsverfahren,

– bei dem das Umgebungsmodell eine Umgebung eines Fahrzeugs, ein Fahrzeug mit Zuständen und/oder einen Fahrer eines Fahrzeugs modelliert, und
– bei dem das Sensormodell eine 2D- oder 3D-Kamera, einen Ultraschallsensor, einen 2D- oder 3D-Laserscanner, ein 2D- oder 3D-Radar, ein Lidar, einen Raddrehungssensor, einen Inertialsensor, einen Beschleunigungssensor, einen Drehratensensor, einen Temperatursensor, einen Luftfeuchtesensor, einen Positionssensor zur Bestimmung zumindest eines Parameters der Fahrdynamik eines Fahrzeuges, einen Sitzbelegungssensor oder einen Entfernungssensor modelliert, und
– bei dem der vorgegebene Umgebungsrepräsentations-Typ eine 2D- oder 3D-Gitterkarte, eine Objektliste oder eine Liste von Zuständen ist.

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

– bei dem das Fusionsmodell durch Lösung eines gemischt diskret-kontinuierlichen Optimierungsproblems aus einer Menge von Fusionsmodellen ausgewählt und parametriert wird.

In einer Weiterbildung ergibt sich ein Herstellungsverfahren,

– bei dem die Inferenzmaschine ein probabilistischer Inferenzapparat ist,
– bei dem das Fusionsmodell einen Faktorgraphen beinhaltet,
– bei dem sowohl die Umgebungsrepräsentation als auch die realen Sensordaten oder die virtuellen Sensordaten Zufallsvariable enthalten,
– bei dem der Faktorgraph des Fusionsmodells jede dieser Zufallsvariablen in einem Variablenknoten abbildet, und
– bei dem der Faktorgraph Faktorknoten enthält, welche die Variablenknoten verbinden und bedingte Wahrscheinlichkeiten zwischen den Variablenknoten beschreiben,
– bei dem die Faktorknoten und die Verbindungen jedes Faktorknotens durch den diskreten Teil des Optimierungsproblems bestimmt werden, wodurch das Fusionsmodell aus der Menge möglicher Faktorgraphen ausgewählt wird, und
– bei dem kontinuierliche Parameter der Faktorknoten durch den kontinuierlichen Teil des Optimierungsproblems bestimmt werden, wodurch das Fusionsmodell parametriert wird.

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

– bei dem das gemischt diskret-kontinuierliche Optimierungsproblem gelöst wird mithilfe
– von genetischen Algorithmen,
– von Ameisen-Algorithmen, oder
– einer nichtlinearen Optimierung, insbesondere mittels eines Branch-and-Bound-Algorithmus.

In einer Weiterbildung ergibt sich ein Herstellungsverfahren,

– bei dem der Umgebungsrepräsentations-Typ (7) eine 2D- oder 3D-Gitterkarte ist,
– bei dem die Zufallsvariablen in der Umgebungsrepräsentation (6) jeweils für Zellen oder Würfel eingetragen und aktualisiert werden, und
– bei dem die Zufallsvariablen eine Unsicherheit einer Information ausdrücken, insbesondere eine Belegungswahrscheinlichkeit für die jeweilige Zelle oder den jeweiligen Würfel.

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 eine Architektur eines Fahrerassistenzsystems,
2 ein maschinelles Lernverfahren für ein Fusionsmodell,
3 eine Anordnung bzw. ein Verfahren zur Sensorfusion.
1 zeigt eine Architektur eines Fahrerassistenzsystems und insbesondere den Aufbau einer Umgebungsrepräsentation 6 aus realen Sensordaten 4. Ein Sensor 1 führt eine reale Messung 3 in einer realen Umgebung 2 durch und erzeugt hierbei die realen Sensordaten 4. Für die Übersetzung der realen Sensordaten 4 in die 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.
Ohne Einschränkung der Allgemeinheit kann das hier beschriebene Ausführungsbeispiel als Entwurfsprozess und Entwurfssystem für Fahrerassistenzsysteme verstanden werden. Die in 1 gezeigte generische Architektur eines Fahrerassistenzsystems ist also nicht auf eine Formalisierung des Entwurfsprozesses beschränkt, sondern eignet sich auch als Systemarchitektur zur Sensorfusion sowie zur Implementierung einer Fahrerassistenz-Anwendung 9, welche ein Fahrzeugverhalten 100 steuert.
Bei dieser Architektur kommt der Sensordatenfusion 5 eine zentrale Rolle zu. Sie ist dafür verantwortlich, aus der Folge der realen Sensordaten 4 verschiedener Sensoren 1 die Umgebungsrepräsentation 6, d. h. wie eingangs definiert eine interne Repräsentation der Umgebung, des Fahrzeugzustandes und/oder des Zustandes des Fahrers herzuleiten. Die Einträge in der Umgebungsrepräsentation 6 stammen folglich aus Beobachtungen, d. h. den realen Sensordaten 4.
Meist wird dabei ein Umgebungsrepräsentations-Typ 7, d. h. der Typ der Umgebungsrepräsentation 6, vom Entwickler vorab festgelegt. Der Umgebungsrepräsentations-Typ 7 kann z. B. eine Belegungsgitterkarte sein oder eine Objektliste, er kann Parameter des Fahrzeugzustandes festlegen oder eine Menge möglicher Zustände für den Fahrer vorgeben (”müde”, ”wach”, ”gleichmütig”, ”angespannt”, ...).
Die zustandsabhängigen Einträge in der Umgebungsrepräsentation 6 werden modifiziert, je nachdem, was die Sensoren 1 messen. Z. B. kann die Belegungswahrscheinlichkeit in einer Zelle einer Belegungsgitterkarte erhöht werden, wenn der Sensor 1 einen Abstand zu einem Hindernis in entsprechendem Abstand misst. Die Einträge in der Umgebungsrepräsentation 6, wie z. B. eine Belegungswahrscheinlichkeit, drücken in der Regel eine Unsicherheit der Information aus. Daher entsprechen sie meist einem der bekannten Unsicherheitskalküle, insbesondere aus der Fuzzy-Theorie, dem Dempster-Shafer-Kalkül oder der Wahrscheinlichkeitsrechnung. Meistens wird Wahrscheinlichkeitsrechnung verwendet, und die Einträge sind Zufallsvariable. Aus Effizienzgründen wird oft eine parametrische Wahrscheinlichkeitsdichteverteilung zugrunde gelegt, es kann aber auch eine stichprobenbasierte Darstellung gewählt werden, wie es im Gebiet der autonomen Roboter üblich ist.
Die Rechenregel, nach der die Einträge in der Umgebungsrepräsentation 6 aufgrund der realen Sensordaten 4 modifiziert werden, ist in 1 als Fusionsmodell 8 eingetragen.
Ein Beispiel für die Fahrerassistenz-Anwendung 9 ist eine Fahrerassistenzfunktion zum automatischen Einparken. Dieses Beispiel ist angelehnt an die Darstellungen in Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, Kap. 6. Die Fahrerassistenz-Anwendung 9 zum automatischen Einparken braucht als Umgebungsrepräsentation 6 eine Karte der Umgebung, in der eine Parklücke identifiziert werden kann und dann eine Bahn in diese Parklücke hinein geplant werden kann. Der Umgebungsrepräsentations-Typ 7 dieser 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 6 der Umgebung.
Die Umgebungsrepräsentation 6 soll also grundsätzlich über einen gewissen Zeitraum hinweg statisch sein, d. h. in ihr sollen die Teile der realen Umgebung 2 modelliert sein, die sich über eine gewisse Zeit hinweg nicht ändern. Die Messung hängt eigentlich ab von der realen Umgebung 2. Bei der Herleitung der Umgebungsrepräsentation 6, wird dies in der Literatur häufig synonym genommen zu der Information in der Umgebungsrepräsentation 6, also der Karte der Umgebung.
2 zeigt eine separate und explizite Modellierung der Sensoreigenschaften mit einem Sensormodell 10, der Umgebungseigenschaften mit einem Umgebungsmodell 20, des Umgebungsrepräsentations-Typ 7 und der Umgebungsrepräsentation 6 selbst. Dabei wird im Entwurfsprozess die erforderliche Expertise über die Sensorhardware von der Expertise über Anwendungsbereiche entkoppelt.
Das Sensormodell 10, ein nicht gezeigtes Fahrzeugmodell und das Umgebungsmodell 20 ermöglichen hierbei die Simulation virtueller Messungen 30, 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 virtuellen 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 folglich die physikalischen Eigenschaften des Sensors. Welche das sind, hängt natürlich von den jeweiligen Sensortypen ab.
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.
In diesem Kontext beschreibt das Fahrzeugmodell, 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.
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 vom Umgebungsrepräsentations-Typ 7 der Umgebungsrepräsentation 6 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 ein Kreissegment (2D) bzw. einen Kugelschalenabschnitt (3D) 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 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.
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.
Im Folgenden wird, nach wie vor im Kontext der 2, ein Ausführungsbeispiel für die Ableitung einer Ziel-Umgebungsrepräsentation 60 zur Vorbereitung eines maschinellen Lernens des Fusionsmodells 8 erläutert.
Um den Entwurf des Fusionsmodells 8 zu unterstützen, wird wie in 2 gezeigt aus vielen Gründen eine Simulation aller wesentlichen Aspekte aller Module im System durchgeführt. In 2 ist einerseits ein Ausschnitt aus dem Fahrerassistenzsystem gezeigt, bei dem die physikalischen Sensoren 1 und die reale Umgebung 2 aus 1 durch entsprechende Modelle ersetzt sind, und in dem die realen Messungen 3 aus 1 durch virtuelle Messungen 30 ersetzt sind. Der Ausschnitt reicht bis zur Umgebungsrepräsentation 6, die in diesem Fall also aus den virtuellen Sensordaten 40 hergeleitet wird. Zusätzlich ist in 2 eine gewünschte wahrgenommene Umgebungsrepräsentation gezeigt, die Ziel-Umgebungsrepräsentation 60. Diese ist vom gleichen Umgebungsrepräsentations-Typ 7 wie die Umgebungsrepräsentation 6.
Auf Grundlage der beabsichtigten Fahrerassistenzfunktion ist es möglich, im Rahmen einer direkten Herleitung 70 zu entscheiden, welche Informationen aus dem Umgebungsmodell 20 in der Umgebungsrepräsentation 6 geschätzt werden sollen. Für ein automatisches Einparken wird z. B. ein Abbild der Parklücke benötigt, also der in einem bestimmten Bereich vorhandenen statischen Hindernisse. In diese Umgebungsrepräsentation 6 sollen bewegte Objekte nicht eingetragen werden, insbesondere, wenn sie die Parklücke wieder verlassen. Ziel ist also eine Belegungsgitterkarte, in der jede Zelle, die einem statischen Objekt entspricht, mit hoher Wahrscheinlichkeit als belegt gekennzeichnet ist, und jede Zelle, die nicht einem statischen Objekt entspricht, mit hoher Wahrscheinlichkeit als frei gekennzeichnet ist.
Diese Wahrscheinlichkeiten können nach den Erfordernissen der Applikation, z. B. des Einparkens, gewichtet sein. So kann verlangt werden, dass die richtige Schätzung der belegten Zellen vor der richtigen Schätzung der freien Zellen in unmittelbarer Umgebung der belegten Zellen Vorrang hat. Dies führt dazu, dass ein geplanter Weg in die Parklücke mit hoher Wahrscheinlichkeit auch fahrbar ist, während es vorkommen kann, dass ein an sich physikalisch möglicher Weg in die Parklücke wegen der ungenauen Umgebungsrepräsentation 6 nicht gefunden wird.
Ebenso werden Eigenheiten der Sensoren berücksichtigt. So können Sensoren von Fahrerassistenzsystemen in der Regel nicht das Innere von Gegenständen abbilden. Daher kann der Belegungszustand von Zellen der Belegungsgitterkarte, die zu inneren Punkten der statischen Objekte im Umgebungsmodell 20 gehören, als ”unbekannt” spezifiziert werden (unabhängig davon, wie dieser Zustand im Zusammenhang mit einem spezifischen probabilistischen Modell von ”belegt” oder ”frei” im Einzelfall kodiert ist).
Sämtliche dieser Aspekte werden berücksichtigt, um die Ziel-Umgebungsrepräsentation 60 im Rahmen der direkten Herleitung 70 entsprechend auszugestalten.
Im Folgenden wird, nach wie vor im Kontext der 2, ein Ausführungsbeispiel für das maschinelle Lernen des Fusionsmodells 8 erläutert.
Das Fusionsmodell 8 wird nun danach beurteilt, wie genau die mittels dieses Fusionsmodells 8 aus den virtuellen Sensordaten 40 erstellte Umgebungsrepräsentation 6 mit der Ziel-Umgebungsrepräsentation 60 übereinstimmt. Dabei kann wie oben angedeutet diese Fehlerfunktion auch auf die Anforderungen der Fahrerassistenzfunktion abgestimmt sein. So kann es z. B. als sehr großer Fehler bewertet werden, wenn eine Zelle in der Umgebungsrepräsentation 6 eine höhere Bewertung für ”frei” enthält als in der Ziel-Umgebungsrepräsentation 60, während umgekehrt eine höhere Bewertung für ”belegt” in der Umgebungsrepräsentation 6 mit einem geringeren Fehlerwert bewertet wird.
Ohne Einschränkung der Allgemeinheit wird im Folgenden anhand eines Beispiels aus Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, S. 294 ff, ein vergleichsweise einfacher Ansatz illustriert und für ein maschinelles Lernens des Fusionsmodells 8 adaptiert.
Ziel ist es, die Umgebungsrepräsentation 6 aus dem (hier zur Vereinfachung als bekannt angenommenen) Fahrzeugzustand und den virtuellen Sensordaten 40 zu schätzen, genauer gesagt aus einer Folge von Fahrzeugzuständen x_1:t und einer Folge von Sensordaten z_i:t. Gesucht ist also die Belegungswahrscheinlichkeit p(m|z_1:t,x_1:t). In der Praxis wird hier wegen Begrenzungen bei Speicherplatz und Rechenzeit bevorzugt inkrementell gerechnet, also p(m_t|m_t-1, z_t, x_t). Diese Wahrscheinlichkeit zu ermitteln ist die Rolle der in 2 gezeigten Sensordatenfusion 5.
Die Sensordatenfusion 5 wird hierbei von einer Inferenzmaschine 80 unter Rückgriff auf das Fusionsmodell 8 durchgeführt. Eine eingehende Erläuterung dieser Zusammenhänge erfolgt im Kontext der 3 sowie im Kontext der weiter unten beschriebenen Faktorgraphen.
Wie in Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, S. 294 ff beschrieben, wird jeder Gitterzelle der Belegungsgitterkarte eine binäre (d. h. zweiwertige) Zufallsvariable zugewiesen, mit den beiden Werten free und occ, für ”frei” und ”belegt”. Für jede Zelle muss gelten p(free) + p(occ) = 1, daher muss nur eine Zahl gespeichert werden, z. B. p(occ). Wenn p(occ) = 1 ist, dann ist die entsprechende Zelle sicher belegt, und wenn p(occ) = 0 ist, dann ist diese Zelle sicher frei. Im folgenden Beispiel gilt 0 < p(occ) < 1, was in der Praxis völlig ausreicht.
Es wird weiterhin angenommen, dass diese Belegungswahrscheinlichkeit für eine Zelle unabhängig ist von der Belegungswahrscheinlichkeit anderer Zellen (was nicht mit der Wirklichkeit übereinstimmt). Damit kann dann jede Zelle für sich genommen aktualisiert werden.
Selbst die Aktualisierung einer einzelnen Zelle kann noch auf sehr unterschiedliche Art erfolgen. Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, S. 94 gibt mit einem binären Bayes-Filter mit statischem Zustand ein einfaches Beispiel, welches hierzu verwendet werden kann. Aufgrund von Vorteilen bei der numerischen Berechnung (insbesondere bei Näherung an die Intervallgrenzen 0 und 1), wird in der Zelle nicht p(occ) eingetragen, sondern der Quotient

die „log odds ratio” bzw. das logaritmische Quotenverhältnis. Da dies für jede Zelle ein anderer Wert sein wird, wird als Zufallsvariable die Belegungswahrscheinlichkeit m_i der Zelle i gewählt.
Damit wird neue Wert einer Zelle berechnet als

wobei p(m_i|z_t, x_t), genannt das inverse Sensormodell, eine Vergrößerung oder Verringerung der Belegungswahrscheinlichkeit der Zelle i beschreibt und
eine generelle a-priori-Belegungswahrscheinlichkeit ist (ohne Kenntnis des Fahrzeugzustands oder einer Messung, also nur abhängig von der Umgebung).
In diesem Beispiel besteht die genaue Auslegung des Fusionsmodells 8 darin, wie der Term
aus den virtuellen Sensordaten 40 zu interpretieren ist. In einem einfachen Fall werden dafür verschiedene Konstanten gewählt, wobei diese Wahl eher einem empirischen Ansatz entspricht als einer formal strengen Herleitung. Damit ist das Fusionsmodell 8 gegeben durch

–
wenn die Zelle im Sichtbereich des Sensors liegt (z. B. Öffnungswinkel einer Ultraschallkeule) und der Messwert zu dem Abstand zwischen Zelle und Sensor passt,
–
wenn die Zelle im Sichtbereich des Sensors liegt (z. B. Öffnungswinkel der Ultraschallkeule) und der Messwert kleiner als der Abstand zwischen Zelle und Sensor ist, oder
–
sonst, d. h. die Belegungswahrscheinlichkeit ändert sich nicht.

Zur Bestimmung der numerischen Werte von l_occ und l_free sind also genaue Kenntnisse des Sensors erforderlich. Zur Bestimmung von l₀ sind sowohl Kenntnisse der Umgebung als auch des Verwendungszwecks der Karte erforderlich.
Diese Kenntnisse sind aber in der vorgeschlagenen Entwicklungsumgebung bereits in die Sensormodelle 10, die Umgebungsmodelle 20 und die Simulationsalgorithmen eingeflossen, ebenso wie in die direkte Herleitung 70 der Ziel-Umgebungsrepräsentation 60.
Daher können die Parameter l_occ, l_free und l₀ auch durch einen Optimierungsalgorithmus gefunden werden, der die Qualität der in der Simulation entstandenen Umgebungsrepräsentation 6 optimiert. Dies ist in diesem Fall ein kontinuierliches Optimierungsproblem, welches in 2 durch eine Fusionsmodell-Optimierung 50 gelöst wird.
Die Unterstützung der Entwickler lässt sich auch auf die Auswahl einer geeigneten Klasse des Fusionsmodells 8 erweitern, wobei die Wahl der Klasse als diskrete Variable aufgefasst werden kann. Damit erweitert sich das Problem zum gemischt diskret-kontinuierlichen Optimierungsproblem. Bei der Lösung dieser Probleme sind in letzter Zeit erhebliche Fortschritte erzielt worden.
Eine mögliche Ausführung eines Fusionsmodells 8, welches durch diskrete und/oder kontinuierliche Parameter für eine spezifische Sensordatenfusionsaufgabe konfiguriert wird, besteht in einem Faktorgraph, wie er in dem Dokument "Factor graph" beschrieben ist, erhältlich im Internet am 11.07.13 unter http://en.wikipedia.org/wiki/Factorgraph. In diesem Formalismus werden Zufallsvariable, die den momentanen Zustand der Umgebungsrepräsentation charakterisieren, aufgefasst als Variablenknoten eines Graphen. Ebenso werden die Zufallsvariablen, die den realen Sensordaten oder den virtuellen Sensordaten 40 entsprechen, als Variablenknoten aufgefasst. Die Variablenknoten sind verbunden mit Faktorknoten, die die bedingten Wahrscheinlichkeiten zwischen diesen Zufallsvariablen beschreiben. Diese bedingten Wahrscheinlichkeiten können zu verschiedenen parametrischen Klassen von Verteilungen gehören, z. B. zu Exponentialverteilungen.
Für viele praktische Einsatzfälle existieren effiziente Algorithmen zur Implementierung der Inferenzmaschine 80, welche die Wahrscheinlichkeiten der Variablenknoten im Faktorgraphen ermitteln. Eine entsprechende Implementierung dieser Algorithmen findet sich beispielsweise in dem Softwarepaket GTSAM des Georgia Institute of Technology, dokumentiert in dem Dokument "The Borg Lab", erhältlich im Internet am 11.07.13 unter https://collab.cc.gatech.edu/borg/. Eine weitere Implementierung ist G2O der Universität Freiburg bzw. des OpenSLAM Konsortiums, dokumentiert in dem Dokument "g2o: A General Framework for Graph Optimization", erhältlich im Internet am 11.07.13 unter http://openslam.org/g2o.html.
Mit der Inferenzmaschine 80 in Verbindung mit dem Faktorgraphen als Fusionsmodell 8 ist es möglich, den Zustand der Umgebungsrepräsentation 6 aus realen Sensordaten oder den virtuellen Sensordaten 40 zu ermitteln. Insofern stellen diese Algorithmen ein Beispiel für einen generischen Inferenzapparat dar. Das Fusionsmodell 8 besteht aus einem Faktorgraphen, dessen Struktur durch diskrete Parameter beschreibbar ist (Variablenknoten und Faktorknoten nach Typ und Verbindungsstruktur), während die Parameter zur näheren Festlegung der Faktorknoten – ebenfalls Teil des Fusionsmodells 8 – in der Regel kontinuierliche Parameter sind, z. B. Mittelwert und Kovarianz in einer Normalverteilung.
Durch diese Charakterisierung des entsprechenden Faktorgraphen wird das Auffinden einer Ausprägung des Fusionsmodells 8, hier durch Definition des Faktorgraphen, eine Aufgabe der gemischt diskret-kontinuierlichen Optimierung mit den diskreten und kontinuierlichen Parametern als Variablen. Diese Art von Problemen ist unter der Bezeichnung MINLP (Mixed Integer and Non Linear Programming) seit längerem Gegenstand einer aktiven und sehr erfolgreichen Forschung. Als Lösungen für die MINLP Problem wurden neben den seit längerem bekannten Genetischen Algorithmen (als ein Beispiel für stochastische Optimierung) auch Ameisen-Algorithmen angegeben. Letztere sind unter anderem aus dem Dokument "Ameisenalgorithmus", erhältlich im Internet am 11.07.13 unter http://de.wikipedia.org/wiki/Ameisenalgorithmus , bekannt.
Auf Prinzipien der nichtlinearen Optimierung bauen NLP basierte ”Branch and Bound”-Verfahren und viele weitere, welche sich ebenfalls eignen. Ein Überblick findet sich in dem Dokument P. Bonami, M. Kilinc, und J. Linderoth: "Algorithms and Software for Convex Mixed Integer Nonlinear Programs", in Jon Lee and Sven Leyffer, editors, Mixed Integer Nonlinear Programming, The IMA Volumes in Mathematics and its Applications, Volume 154, 2012, Seiten 1–39.
Ein Überblick über weitere hier anwendbare Verfahren des Maschinellen Lernens wie z. B. Bayessche Netze findet sich in D. Koller und N. Friedman: "Probabilistic Graphical Models: Principles and Techniques", MIT Press, 2009, Seiten 134–141.
3 zeigt ein Ausführungsbeispiel für eine Anordnung 105 und ein Verfahren zur Sensorfusion. Über eine Schnittstelle 104, beispielsweise eine Anbindung zu einem Fahrzeug-Bussystem, ein USB-, WLAN-, Ethernet- oder Bluetooth-Port, werden reale Sensordaten 4 oder virtuelle Sensordaten 40 empfangen. In einem Speicher 106, beispielsweise eine Festplatte, ein Flash-Speicher oder ein RAM-Baustein, ist eine Umgebungsrepräsentation 6 gespeichert ist, welche einem vorgegebenen Umgebungsrepräsentations-Typ entspricht.
In einer Inferenzmaschine 80, beispielsweise ein in geeigneter Weise programmierter Mikroprozessor, wird ein Computerprogramm abgearbeitet, welches eingerichtet ist, anhand eines modular von der Inferenzmaschine 80 getrennten Fusionsmodells 8 Änderungen in der Umgebungsrepräsentation 6 vorzunehmen, welche die realen Sensordaten 4 oder virtuellen Sensordaten 40 mit der Umgebungsrepräsentation 6 fusionieren.
Die modulare Trennung bedeutet hierbei, dass das Fusionsmodell 8 austauschbar oder veränderbar ist, ohne dass hierbei eine Anpassung der Inferenzmaschine 80 zu erfolgen hätte, welche über die bloße Bereitstellung des neuen Fusionsmodells 8 hinausgehen würde. Folglich kann das Fusionsmodell 8 wahlweise wie in 3 gezeigt im Speicher 106 oder auf einem computerlesbaren Datenträger, welcher in der Inferenzmaschine 80 selbst angeordnet ist, gespeichert sein, beispielsweise auf einer SD-Karte, einem USB-Stick, einem RAM-Baustein oder Mikrochip.
Ferner kann die Inferenzmaschine 80 auch als Softwareprogramm oder virtuelle Maschine implementiert werden, welche ihrerseits dann beispielsweise in einem in 3 durch die Anordnung 105 repräsentierten Mikroprozessor abgearbeitet werden.
Es handelt sich bei der modularen Trennung somit um eine funktionale bzw. logische Trennung. Ergänzend kann optional auch eine räumliche Trennung vorgesehen werden, indem der Speicherort des Fusionsmodells 8 von der Inferenzmaschine separiert wird.
Die beschriebenen Ausführungsbeispiele, Ausführungsformen, Varianten und Weiterbildungen lassen sich frei miteinander kombinieren. Insbesondere können beliebige Teilaspekte der Ausführungsbeispiele im Kontext von 1 und 2 in das im Kontext der 3 beschriebene Ausführungsbeispiel aufgenommen werden.
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 Nicht-Patentliteratur

Thrun, Burgard und Fox: ”Probabilistic Robotics”, MIT Press 2005, Kap. 6. [0046]
Thrun, Burgard und Fox: ”Probabilistic Robotics”, MIT Press 2005, S. 294 ff [0073]
Thrun, Burgard und Fox: ”Probabilistic Robotics”, MIT Press 2005, S. 294 ff [0076]
Thrun, Burgard und Fox: ”Probabilistic Robotics”, MIT Press 2005, S. 94 [0078]
”Factor graph” beschrieben ist, erhältlich im Internet am 11.07.13 unter http://en.wikipedia.org/wiki/Factorgraph [0085]
”The Borg Lab”, erhältlich im Internet am 11.07.13 unter https://collab.cc.gatech.edu/borg/ [0086]
”g2o: A General Framework for Graph Optimization”, erhältlich im Internet am 11.07.13 unter http://openslam.org/g2o.html [0086]
”Ameisenalgorithmus”, erhältlich im Internet am 11.07.13 unter http://de.wikipedia.org/wiki/Ameisenalgorithmus [0088]
P. Bonami, M. Kilinc, und J. Linderoth: ”Algorithms and Software for Convex Mixed Integer Nonlinear Programs”, in Jon Lee and Sven Leyffer, editors, Mixed Integer Nonlinear Programming, The IMA Volumes in Mathematics and its Applications, Volume 154, 2012, Seiten 1–39 [0089]
D. Koller und N. Friedman: ”Probabilistic Graphical Models: Principles and Techniques”, MIT Press, 2009, Seiten 134–141 [0090]

Claims

Anordnung zur Sensorfusion, – umfassend eine Schnittstelle (104) zum Empfang realer Sensordaten (4) oder virtueller Sensordaten (40), – umfassend einen Speicher (106), auf welchem eine Umgebungsrepräsentation (6) gespeichert ist, welche einem vorgegebenen Umgebungsrepräsentations-Typ (7) entspricht, gekennzeichnet durch – eine Inferenzmaschine (80), in welcher ein Computerprogramm abgearbeitet wird, welches eingerichtet ist, anhand eines modular von der Inferenzmaschine (80) getrennten Fusionsmodells (8) Änderungen in der Umgebungsrepräsentation (6) vorzunehmen, welche die realen Sensordaten (4) oder virtuellen Sensordaten (40) mit der Umgebungsrepräsentation (6) fusionieren.
Anordnung nach Anspruch 1, – bei der das Fusionsmodell (8) mindestens eine Rechenregel, mindestens eine Datenstruktur, mindestens eine Funktion und/oder mindestens einen Algorithmus angibt, welche die realen Sensordaten (4) oder die virtuellen Sensordaten (40) als Eingabe erhält und als Ausgabe entsprechende Änderungen in der Umgebungsrepräsentation (6) vorschreibt.
Anordnung nach Anspruch 2, – bei der die Inferenzmaschine (80) ein graphenbasierter generischer probabilistischer Inferenzapparat ist, und – bei der das Fusionsmodell (8) einen Faktorgraphen beinhaltet.
Anordnung nach Anspruch 3, – bei der sowohl die Umgebungsrepräsentation (6) als auch die virtuellen Sensordaten (40) Zufallsvariable enthalten, – bei der der Faktorgraph des Fusionsmodells (8) jede dieser Zufallsvariablen in einem Variablenknoten abbildet, und – bei der der Faktorgraph Faktorknoten enthält, welche die Variablenknoten verbinden und bedingte Wahrscheinlichkeiten zwischen den Variablenknoten beschreiben.
Computerlesbarer Datenträger, – auf dem ein Fusionsmodell (8) gespeichert ist, welches für eine Verwendung durch die Inferenzmaschine (80) der Anordnung nach einem der Ansprüche 1 bis 4 eingerichtet ist.
Computerlesbarer Datenträger nach Anspruch 5, – bei dem das Fusionsmodell (8) einen Faktorgraphen beinhaltet, – bei dem sowohl die Umgebungsrepräsentation (6) als auch die virtuellen Sensordaten (40) Zufallsvariable enthalten, – bei dem der Faktorgraph jede dieser Zufallsvariablen in einem Variablenknoten abbildet, und – bei der der Faktorgraph Faktorknoten enthält, welche die Variablenknoten verbinden und bedingte Wahrscheinlichkeiten zwischen den Variablenknoten beschreiben.
Verfahren zur Sensorfusion, – bei dem reale Sensordaten (4) oder virtuelle Sensordaten (40) empfangen werden, – bei dem auf eine Umgebungsrepräsentation (6) zugegriffen wird, welche einem vorgegebenen Umgebungsrepräsentations-Typ (7) entspricht, dadurch gekennzeichnet, dass – eine Inferenzmaschine (80) rechnergestützt anhand eines modular von der Inferenzmaschine (80) getrennten Fusionsmodells (8) Änderungen in der Umgebungsrepräsentation (6) vornimmt, welche die realen Sensordaten (4) oder virtuellen Sensordaten (40) mit der Umgebungsrepräsentation (6) fusionieren.
Verfahren nach Anspruch 7, – bei dem das Fusionsmodell (8) mindestens eine Rechenregel, mindestens eine Datenstruktur, mindestens eine Funktion und/oder mindestens einen Algorithmus angibt, welche die realen Sensordaten (4) oder die virtuellen Sensordaten (40) als Eingabe erhält und als Ausgabe entsprechende Änderungen in der Umgebungsrepräsentation (6) vorschreibt.
Verfahren nach Anspruch 8, – bei der die Inferenzmaschine (80) ein graphenbasierter generischer probabilistischer Inferenzapparat ist, und – bei der das Fusionsmodell (8) einen Faktorgraphen beinhaltet.
Verfahren nach Anspruch 9, – bei dem sowohl die Umgebungsrepräsentation (6) als auch die realen Sensordaten (4) oder virtuellen Sensordaten (40) Zufallsvariable enthalten, – bei dem der Faktorgraph des Fusionsmodells (8) jede dieser Zufallsvariablen in einem Variablenknoten abbildet, und – bei dem der Faktorgraph Faktorknoten enthält, welche die Variablenknoten verbinden und bedingte Wahrscheinlichkeiten zwischen den Variablenknoten beschreiben.
Herstellungsverfahren zur Erstellung eines Fusionsmodells (8), – bei dem rechnergestützt anhand eines Sensormodells (10) virtuelle Messungen (30) in einem Umgebungsmodell (20) simuliert und anhand der virtuellen Messungen (30) virtuelle Sensordaten (40) erzeugt werden, die ein Umgebungsmodell (20) zumindest teilweise abbilden, – bei dem ein Fusionsmodell (8) mindestens eine Rechenregel, mindestens eine Datenstruktur, mindestens eine Funktion und/oder mindestens einen Algorithmus angibt, welche die virtuellen Sensordaten (40) als Eingabe erhält und als Ausgabe entsprechende Änderungen in einer Umgebungsrepräsentation (6) mit einem vorgegeben Umgebungsrepräsentations-Typ (7) vorschreibt, – bei dem das Fusionsmodell (8) durch rechnergestütztes maschinelles Lernen erstellt wird, wobei – eine Ziel-Umgebungsrepräsentation (60) aus dem Umgebungsmodell (20) und dem Umgebungsrepräsentations-Typ (7) hergeleitet wird, welche ein Trainingsziel für das maschinelle Lernen vorgibt, – das Fusionsmodell (8) durch Lösung eines kontinuierlichen Optimierungsproblems parametriert wird, – eine von dem Fusionsmodell (8) modular getrennte Inferenzmaschine (80) rechnergestützt anhand des Fusionsmodells (8) und der realen Sensordaten (4) oder virtuellen Sensordaten (40) Änderungen in der Umgebungsrepräsentation (6) vornimmt, welche die realen Sensordaten (4) oder virtuellen Sensordaten (40) mit der Umgebungsrepräsentation (6) fusionieren, – die Umgebungsrepräsentation (6) mit der Ziel-Umgebungsrepräsentation (60) verglichen wird, woraus sich ein Fehler ergibt, welcher bei der Lösung des kontinuierlichen Optimierungsproblems minimiert wird.
Herstellungsverfahren nach Anspruch 11, – bei dem das Fusionsmodell (8) mindestens eine Rechenregel, mindestens eine Datenstruktur, mindestens eine Funktion und/oder mindestens einen Algorithmus angibt, welche die realen Sensordaten (4) oder die virtuellen Sensordaten (40) als Eingabe erhält und als Ausgabe entsprechende Änderungen in der Umgebungsrepräsentation (6) vorschreibt.
Herstellungsverfahren nach Anspruch 11 oder 12, – bei dem der Fehler anhand einer Fehlerfunktion ermittelt wird, welche Anforderungen einer Fahrerassistenzfunktion berücksichtigt.
Herstellungsverfahren nach einem der Ansprüche 11 bis 13, – bei dem das Umgebungsmodell (20) eine Umgebung eines Fahrzeugs, ein Fahrzeug mit Zuständen und/oder einen Fahrer eines Fahrzeugs modelliert, und – bei dem das Sensormodell (10) eine 2D- oder 3D-Kamera, einen Ultraschallsensor, einen 2D- oder 3D-Laserscanner, ein 2D- oder 3D-Radar, ein Lidar, einen Raddrehungssensor, einen Inertialsensor, einen Beschleunigungssensor, einen Drehratensensor, einen Temperatursensor, einen Luftfeuchtesensor, einen Positionssensor zur Bestimmung zumindest eines Parameters der Fahrdynamik eines Fahrzeuges, einen Sitzbelegungssensor oder einen Entfernungssensor modelliert, und – bei dem der vorgegebene Umgebungsrepräsentations-Typ (7) eine 2D- oder 3D-Gitterkarte, eine Objektliste oder eine Liste von Zuständen ist.
Herstellungsverfahren nach einem der Ansprüche 11 bis 14, – bei dem das Fusionsmodell (8) durch Lösung eines gemischt diskret-kontinuierlichen Optimierungsproblems aus einer Menge von Fusionsmodellen (8) ausgewählt und parametriert wird.
Herstellungsverfahren nach Anspruch 15, – bei dem die Inferenzmaschine (80) ein probabilistischer Inferenzapparat ist, – bei dem das Fusionsmodell (8) einen Faktorgraphen beinhaltet, – bei dem sowohl die Umgebungsrepräsentation (6) als auch die realen Sensordaten (4) oder die virtuellen Sensordaten (40) Zufallsvariable enthalten, – bei dem der Faktorgraph des Fusionsmodells (8) jede dieser Zufallsvariablen in einem Variablenknoten abbildet, und – bei dem der Faktorgraph Faktorknoten enthält, welche die Variablenknoten verbinden und bedingte Wahrscheinlichkeiten zwischen den Variablenknoten beschreiben, – bei dem die Faktorknoten und die Verbindungen jedes Faktorknotens durch den diskreten Teil des Optimierungsproblems bestimmt werden, wodurch das Fusionsmodell aus der Menge möglicher Faktorgraphen ausgewählt wird, und – bei dem kontinuierliche Parameter der Faktorknoten durch den kontinuierlichen Teil des Optimierungsproblems bestimmt werden, wodurch das Fusionsmodell (8) parametriert wird.
Herstellungsverfahren nach Anspruch 16, – bei dem das gemischt diskret-kontinuierlichen Optimierungsproblem gelöst wird mithilfe – von genetischen Algorithmen, – von Ameisen-Algorithmen, oder – einer nichtlinearen Optimierung, insbesondere mittels eines Branch-and-Bound-Algorithmus.
Herstellungsverfahren nach Anspruch 16 oder 17, – bei dem der Umgebungsrepräsentations-Typ (7) eine 2D- oder 3D-Gitterkarte ist, – bei dem die Zufallsvariablen in der Umgebungsrepräsentation (6) jeweils für Zellen oder Würfel eingetragen und aktualisiert werden, und – bei dem die Zufallsvariablen eine Unsicherheit einer Information ausdrücken, insbesondere eine Belegungswahrscheinlichkeit für die jeweilige Zelle oder den jeweiligen Würfel.
Computerlesbarer Datenträger, – auf dem ein Computerprogramm gespeichert ist, welches das Verfahren nach einem der Ansprüche 7 bis 10 oder das Herstellungsverfahren nach einem der Ansprüche 11 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 7 bis 10 oder das Herstellungsverfahren nach einem der Ansprüche 11 bis 18 ausführt.