DE102013215115A1

DE102013215115A1 - Entwurfssystem und Verfahren zum Entwurf eines Fahrerassistenzsystems

Info

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

Abstract

Das Entwurfssystem verarbeitet maschinenlesbare semantische Metadaten (92), welche beispielsweise Eigenschaften realer oder virtueller Sensordaten (4, 40) beschreiben, und stellt anhand der semantischen Metadaten (92) eine Gültigkeit von Nutzdaten (91) in einer Umgebungsrepräsentation (1) eines Fahrerassistenzsystems sicher. Hierdurch wird erstmals eine einheitliche, durchgängige und formale Beschreibung der Verfahren und Daten im Entwurfsprozess von Fahrerassistenzsystemen mittels semantischer Metadaten (92) bereitgestellt. Dies hat unter anderem den Vorteil, dass die im Fahrzeug verbauten Sensoren grundsätzlich für alle auf dem Fahrzeug zu realisierenden Fahrerassistenzfunktionen bzw. Applikationen verfügbar werden. Weiterhin wird der Entwurfsprozess deutlich vereinfacht und beschleunigt. Die semantischen Metadaten (92) enthalten beispielsweise einen Zeitstempel (93), eine Herkunftsangabe (94), eine Plausibilität (95) und eine Zeitskala (96), welche angibt, wie sich die Plausibilität (95) der Nutzdaten (91) zeitlich entwickelt.

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.
Der Entwurfsprozess von Fahrerassistenzsystemen ist dadurch geprägt, dass ein sehr breites Spektrum von Expertenwissen im Entwicklungsteam vertreten sein muss. Der Grund dafür ist, dass Aufbau und Leistungsvermögen eines Fahrerassistenzsystems von sehr vielen Aspekten abhängen.
Zunächst wird in der Regel eine Umgebung eines Fahrzeugs, ggf. auch ein interner Zustand des Fahrzeugs und ein Zustand des Fahrers mittels Sensoren physikalisch oder chemisch erfasst. Aus diesen Sensordaten wird eine geeignete Umgebungsrepräsentationen, Fahrzeugrepräsentation und Fahrerrepräsentation hergeleitet. Geeignet bedeutet hier, dass eine oder mehrere Assistenzfunktionen bzw. Applikationen auf Grundlage der genannten Repräsentationen Steuersignale für das Fahrzeug und/oder optische oder akustische Signale für den Fahrer erzeugen können, die zu einem erwünschten Verhalten des Fahrzeugs oder einer Information für den Fahrer führen.
In diesem weiten Bogen von physikalischen Sensoren hin zu Steuersignalen und Informationen für den Fahrer müssen viele unterschiedliche Wissensdomänen integriert werden.
Eine explizite Beschreibung der Bedeutung von Variablen findet sich in CAD-Systemen zum Beispiel in dem neuen Standard Step AP 242 und ist aus dem Dokument "Schemas" ersichtlich, erhältlich im Internet am 25.07.2013 unter http://www.steptools.com/support/stdev_docs/express/ap242/htm l/index.html. Hier wird ein Typsystem verwendet, in dem eine physikalische Bedeutung einer Variablen durch einen Typ der Variablen ausgedrückt wird. Diese Typen umfassen auch SI-Einheiten und davon abgeleitete Einheiten.
Für Sensornetze sind im Zusammenhang mit Geoinformationssystemen semantische Beschreibungen der Sensoren und Signale entwickelt worden, wie unter anderem beschrieben in Michael Compton et. al., "The SSN ontology of the W3C semantic sensor network incubator group", Web Semantics: Science, Services and Agents on the World Wide Web, Volume 17, Dezember 2012, p. 25–32, ISSN 1570-8268. Hierbei ist vorgesehen, dass zusammen mit den Sensoren Eigenschaften der Messungen abgelegt werden, wie zum Beispiel die Genauigkeit.
In der WO 2007017308 A1 wird ein Ansatz beschrieben, die Sensordaten zunächst in einer "Sensorsprache" zu beschreiben, die keine Angaben über das Fahrzeug bzw. die Fahrerassistenzfunktion enthält, und die in dieser Sensorsprache beschriebenen Phänomene später in eine "Funktionssprache" zu übersetzen, welche nicht auf die spezifischen Sensoren eingeht. In dieser Funktionssprache findet dann auch die Fusionierung statt. Dies wird dort am Beispiel eines Abstandsregeltempomaten illustriert.
In der WO 2006089941 A1 wird ein Informationsaustauschmodul beschrieben, in dem Sensorinformationen gesammelt und Applikationen zur Verfügung gestellt werden.
Es stellt sich die Aufgabe, ein Entwurfssystem und ein Verfahren zum Entwurf eines Fahrerassistenzsystems anzugeben, welche den Entwurf des Fahrerassistenzsystems vereinfachen.
Diese Aufgabe wird erfindungsgemäß durch ein Entwurfssystem für ein Fahrerassistenzsystem gelöst,

– umfassend mindestens ein Modul, eingerichtet zur Erzeugung realer Sensordaten oder virtueller Sensordaten, und
– umfassend mindestens ein Modul, eingerichtet zur rechnergestützten Ableitung einer Umgebungsrepräsentation aus den realen Sensordaten oder virtuellen Sensordaten.

Das Entwurfssystem ist dadurch gekennzeichnet, dass

– das Entwurfssystem zur rechnergestützten Verarbeitung maschinenlesbarer semantischer Metadaten eingerichtet ist, welche Eigenschaften der realen Sensordaten und/oder der virtuellen Sensordaten und/oder von Daten in der Umgebungsrepräsentation beschreiben, und
– das Entwurfssystem eingerichtet ist zur rechnergestützten Überprüfung und/oder Sicherstellung einer Gültigkeit von Daten in der Umgebungsrepräsentation anhand der semantischen Metadaten.

Die Aufgabe wird ferner erfindungsgemäß dadurch gelöst, dass

– mindestens ein Modul reale Sensordaten oder virtuelle Sensordaten erzeugt,
– mindestens ein Modul aus den realen Sensordaten oder virtuellen Sensordaten rechnergestützt eine Umgebungsrepräsentation ableitet.

Das Verfahren ist dadurch gekennzeichnet, dass

– das Entwurfssystem maschinenlesbare semantische Metadaten rechnergestützt verarbeitet, welche Eigenschaften der realen Sensordaten und/oder der virtuellen Sensordaten und/oder der Umgebungsrepräsentation beschreiben, und
– das Entwurfssystem anhand der semantischen Metadaten rechnergestützt eine Gültigkeit von Daten in der Umgebungsrepräsentation überprüft und/oder sicherstellt.

Auf dem computerlesbaren Datenträger ist ein Computerprogramm gespeichert, welches das Verfahren ausführt, wenn es in einem Mikroprozessor abgearbeitet wird.
Das Computerprogramm wird in einem Mikroprozessor abgearbeitet und führt dabei das 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.
Es wird eine Formalisierung des Entwurfsprozesses von Fahrerassistenzsystemen mittels der semantischen Metadaten sowie eine Unterstützung dieses Entwurfsprozesses durch ein entsprechendes Entwurfssystem vorgeschlagen.
Hierdurch wird erstmals eine einheitliche, durchgängige und formale Beschreibung der Verfahren und Daten im Entwurfsprozess von Fahrerassistenzsystemen mittels semantischer Metadaten bereitgestellt. Dies hat unter anderem den Vorteil, dass die im Fahrzeug verbauten Sensoren grundsätzlich für alle auf dem Fahrzeug zu realisierenden Fahrerassistenzfunktionen bzw. Applikationen verfügbar werden. Weiterhin wird der Entwurfsprozess deutlich vereinfacht und beschleunigt.
Die Module sowie weitere benötigte Recheneinheiten, Simulatoren etc. können hardwaretechnisch und/oder auch softwaretechnisch implementiert werden. Bei einer hardwaretechnischen Implementierung kann jedes Modul als Vorrichtung oder als Teil einer Vorrichtung, zum Beispiel als Computer, 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 Weiterbildung ergibt sich ein Entwurfssystem,

– mit einem Speicher und mit einem Mikroprozessor, welcher programmiert ist zur Abspeicherung – der realen Sensordaten oder der virtuellen Sensordaten, oder – von Daten in der Umgebungsrepräsentation, oder – von weiteren Daten, welche in den Modulen enthalten sind, jeweils als Nutzdaten in einer Informationseinheit in dem Speicher,
– wobei jede Informationseinheit einen Header aufweist, welcher zumindest einige der folgenden semantischen Metadaten enthält, welche Eigenschaften der Nutzdaten beschreiben: – ein Zeitstempel, welcher angibt, zu welchem Zeitpunkt die Nutzdaten gültig sind oder waren, – eine Herkunftsangabe, welche – einen Sensor bezeichnet, von dem die Nutzdaten erzeugt wurden, oder – mindestens einen Operator und Quell-Informationseinheiten angibt, anhand derer die Nutzdaten hergeleitet wurden,
– eine Plausibilität, welche angibt, in welchem Umfang sich nachfolgende Inferenzschritte auf die Nutzdaten stützen dürfen, und/oder
– eine Zeitskala, welche angibt, wie sich die Plausibilität der Nutzdaten zeitlich entwickelt.

In einer besonderen Weiterbildung ergibt sich ein Entwurfssystem,

– bei dem der Header sämtliche der zuvor genannten semantischen Metadaten enthält.

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

– bei dem in dem Header oder in dem Zeitstempel ein Zeitformat des Zeitstempels abgespeichert ist, und
– bei dem in dem Header oder in dem Zeitstempel eine Uhr, auf welche sich der Zeitstempel bezieht, angegeben ist.

In einer Weiterbildung ergibt sich ein Entwurfssystem,

– bei dem der Mikroprozessor programmiert ist zur Überprüfung für alle Informationseinheiten, ob der Zeitstempel vorhanden ist und das Zeitformat des Zeitstempels bekannt ist, und
– bei dem der Mikroprozessor programmiert ist – zur Verknüpfung einer ersten und einer zweiten Informationseinheit mit einem Herleitungsoperator, – zur Herleitung einer dritten Informationseinheit aus der Verknüpfung, und – zur Abspeicherung der dritten Informationseinheit in dem Speicher, – wobei der Mikroprozessor programmiert ist zur Überprüfung, ob das Zeitformat des Zeitstempels der ersten Informationseinheit mit dem Zeitformat des Zeitstempels der zweiten Informationseinheit übereinstimmt, und andernfalls zur Konvertierung des Zeitstempels der ersten Informationseinheit in das Zeitformat des Zeitstempels der zweiten Informationseinheit, – wobei der Mikroprozessor programmiert ist zur Überprüfung, ob die Uhr des Zeitstempels der ersten Informationseinheit mit der Uhr des Zeitstempels der zweiten Informationseinheit identisch ist, und andernfalls zur Umrechnung des Zeitstempels der ersten Informationseinheit anhand einer bekannten Abweichung der Uhren, sodass er sich ebenfalls auf die Uhr des Zeitstempels der zweiten Informationseinheit bezieht, und – wobei der Mikroprozessor programmiert ist zur Normalisierung des Zeitstempels der ersten Informationseinheit und des Zeitstempels der zweiten Informationseinheit unter Berücksichtigung der Zeitskalen der ersten Informationseinheit und der zweiten Informationseinheit auf einen gemeinsamen neuen Zeitstempel, und zur Abspeicherung des gemeinsamen neuen Zeitstempels im Header der dritten Informationseinheit im Speicher.

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

– bei dem das Entwurfssystem – die realen Sensordaten oder die virtuellen Sensordaten oder – Daten in der Umgebungsrepräsentation oder – weitere Daten, welche in den Modulen enthalten sind, jeweils als Nutzdaten in einer Informationseinheit speichert,
– wobei jede Informationseinheit einen Header aufweist, welcher zumindest einige der folgenden semantischen Metadaten enthält, welche Eigenschaften der Nutzdaten beschreiben: – ein Zeitstempel, welcher angibt, zu welchem Zeitpunkt die Nutzdaten gültig sind oder waren, – eine Herkunftsangabe, welche – einen Sensor bezeichnet, von dem die Nutzdaten erzeugt wurden, oder – mindestens einen Operator und Quell-Informationseinheiten angibt, anhand derer die Nutzdaten hergeleitet wurden, – eine Plausibilität, welche angibt, in welchem Umfang sich nachfolgende Inferenzschritte auf die Nutzdaten stützen dürfen, und/oder – eine Zeitskala, welche angibt, wie sich die Plausibilität der Nutzdaten zeitlich entwickelt.

Gemäß einer besonderen Ausführungsform ergibt sich ein Verfahren,

In einer Weiterbildung ergibt sich ein Verfahren,

– bei dem in dem Header oder in dem Zeitstempel ein Zeitformat des Zeitstempels abgespeichert wird, und
– bei dem in dem Header oder in dem Zeitstempel eine Uhr, auf welche sich der Zeitstempel bezieht, angegeben wird.

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

– bei dem das Entwurfssystem rechnergestützt für alle Informationseinheiten überprüft, ob der Zeitstempel vorhanden ist und das Zeitformat des Zeitstempels bekannt ist, und
– bei dem das Entwurfssystem eine erste und eine zweite Informationseinheit mit einem Herleitungsoperator verknüpft und dadurch eine dritte Informationseinheit herleitet, – wobei das Entwurfssystem überprüft, ob das Zeitformat des Zeitstempels der ersten Informationseinheit mit dem Zeitformat des Zeitstempels der zweiten Informationseinheit übereinstimmt, und den Zeitstempel der ersten Informationseinheit andernfalls in das Zeitformat des Zeitstempels der zweiten Informationseinheit konvertiert, – wobei das Entwurfssystem überprüft, ob die Uhr des Zeitstempels der ersten Informationseinheit mit der Uhr des Zeitstempels der zweiten Informationseinheit identisch ist, und den Zeitstempel der ersten Informationseinheit andernfalls anhand einer bekannten Abweichung der Uhren umrechnet, sodass er sich ebenfalls auf die Uhr des Zeitstempels der zweiten Informationseinheit bezieht, und – wobei das Entwurfssystem den Zeitstempel der ersten Informationseinheit und den Zeitstempel der zweiten Informationseinheit unter Berücksichtigung der Zeitskalen der ersten Informationseinheit und der zweiten Informationseinheit auf einen gemeinsamen neuen Zeitstempel normalisiert, welcher im Header der dritten Informationseinheit abgespeichert wird.

In einer Weiterbildung ergibt sich ein Verfahren,

– bei dem das Entwurfssystem für eine Informationseinheit anhand der Herkunftsangabe sowie der Herkunftsangaben in den Quell-Informationseinheiten, aus denen die Informationseinheit hergeleitet wurde, rekursiv einen Herleitungsgraphen erstellt,
– bei dem das Entwurfssystem durch Graphenalgorithmen rekonvergente Zweige in dem Herleitungsgraphen identifiziert, und
– bei dem das Entwurfssystem Abhängigkeiten, welche sich aus den rekonvergenten Zweigen im Herleitungsgraphen ergeben, durch eine Modifikation der Herleitung der Informationseinheit kompensiert.

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

– bei dem das Entwurfssystem eine erste und eine zweite Informationseinheit mit einem Herleitungsoperator verknüpft und dadurch eine dritte Informationseinheit herleitet, und
– bei dem das Entwurfssystem in Abhängigkeit von dem Herleitungsoperator die Plausibilität der dritten Informationseinheit aus den Plausibilitäten der ersten und der zweiten Informationseinheit berechnet.

In einer Weiterbildung ergibt sich ein Verfahren,

– bei dem das Entwurfssystem anhand einer Langzeitbeobachtung eines typischen Verlaufs einer Zufallsvariable eine geeignete Zeitskala durch maschinelles Lernen ermittelt, und
– bei dem das Entwurfssystem einem Entwickler bei der Definition einer neuen Informationseinheit, in welcher die Zufallsvariable abgespeichert werden soll, die geeignete Zeitskala zur Eintragung als Zeitskala im Header vorschlägt.

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 Ausführungsbeispiel für ein Entwurfssystem für ein Fahrerassistenzsystem,
3 ein Ausführungsbeispiel für eine Informationseinheit,
4 ein Ausführungsbeispiel für einen Zeitstempel,
5 ein Ausführungsbeispiel für eine Herkunftsangabe, und
6 ein Ausführungsbeispiel für eine Datenstruktur für Nutzdaten.
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 die in 1 gezeigte Architektur auch als Entwurfssystem für Fahrerassistenzsysteme verstanden werden. 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 in diesem Beispiel 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.
Im Extremfall wird der Entwurf wie in 1 gezeigt ohne Simulation des Sensors 1 und der realen Umgebung 2 durchgeführt. Das bedeutet aber, dass die Entwickler die Fahrerassistenzfunktion als Ganzes experimentell überprüfen müssen. Dies macht den Entwicklungsprozess langsam und teuer: für jede Modifikation und jede Weiterentwicklung müssen die Entwickler ein Fahrzeug aufbauen, eine aufgabengemäße reale Umgebung 2 suchen oder selbst aufbauen, Datenfusionsalgorithmen und Applikationsalgorithmen schreiben und dann so lange analysieren und ändern, bis das Verhalten des Fahrzeugs den Erwartungen entspricht.
Wenn alle Module von einer Entwicklungsgruppe bearbeitet werden, fehlt es auch an einigen Stellen an der Notwendigkeit zur expliziten Modellierung. Dies kann insbesondere die zugrundegelegte Sensorhardware und die Beschreibung von Eigenschaften der Sensoren 1 betreffen, aber auch die Eigenschaften der realen Sensordaten 4 auf der Metaebene.
Eine weitere Folge dieser Herangehensweise ist daher, dass Entwicklungsstände bzw. Kenntnisstände für einzelne Module nur mit hohem Aufwand zwischen Entwicklergruppen ausgetauscht werden können. Deswegen werden bei solcher Entwurfsmethodik oft große Teile der Entwicklungsarbeiten mit jeder Fahrerassistenzfunktion neu geleistet. Noch schwerer wiegt, dass bei dieser Entwicklungsmethodik auch die Hardware nicht von verschiedenen Fahrerassistenzfunktionen gemeinsam genutzt werden kann.
2 zeigt eine separate und explizite Modellierung der Sensoreigenschaften mit einem Sensormodell 10, der Umgebungseigenschaften mit einem Umgebungsmodell 20, des Umgebungsrepräsentations-Typs 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 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.
Im Sensormodell 10 müssen 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.
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 müssen aus sich heraus unmissverständlich sein, also müssen 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.
Bei der Sendefrequenz ist für einen Ultraschallsensor also als Einheit z.B. Hz anzugeben oder KHz, bei Radarsensoren wird man MHz oder GHz spezifizieren. Entscheidend ist, dass die physikalische Einheit mit angegeben wird.
Nicht nur die Frequenz ist für den Messvorgang relevant, sondern ebenso können Frequenz und Amplitude des gesendeten Signals über die Zeit variieren. In diesem Fall sind formale Angaben dieses Signals erforderlich. Dabei ist es wesentlich, dass das Format, in dem diese Signale beschrieben sind, explizit genannt wird.
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 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.
Im in 3 gezeigten Ausführungsbeispiel werden die realen Sensordaten 4 aus 1, die virtuellen Sensordaten 40 und die Daten in der Umgebungsrepräsentation 6 aus 2 und/oder weitere Daten, beispielsweise Signale und Variable, welche von den Modulen bereitgestellt oder verarbeitet werden, jeweils als Nutzdaten 91 in einer Informationseinheit 90 abgespeichert. Jede Informationseinheit 90 enthält einen Header 92, welcher neben einem Identifikator zumindest einige der folgenden semantischen Metadaten enthält, welche als semantische Annotationen Eigenschaften der Nutzdaten 91 beschreiben:

– ein Zeitstempel 93, welcher angibt, zu welchem Zeitpunkt die Nutzdaten 91 gültig sind oder waren,
– eine Herkunftsangabe 94, welche – einen Sensor bezeichnet, von dem die Nutzdaten 91 erzeugt wurden, oder – mindestens einen Operator und Quell-Informationseinheiten angibt, anhand derer die Nutzdaten 91 hergeleitet wurden,
– eine Plausibilität 95, welche angibt, in welchem Umfang sich nachfolgende Inferenzschritte auf die Nutzdaten 91 stützen dürfen, und/oder
– eine Zeitskala 96, welche angibt, wie sich die Plausibilität 95 der Nutzdaten 91 zeitlich entwickelt, d.h. für wie persistent die Nutzdaten 91 gehalten werden.

4 zeigt den Zeitstempel 93 aus 3 im Detail. Im Bereich Fahrerassistenzfunktionen hat man es in aller Regel mit zeitlich veränderlichen Zuständen der Umgebung, des Fahrzeugs und des Fahrers zu tun. Die im Kontext der 1 und 2 beschriebenen realen Sensordaten 4, virtuellen Sensordaten 40, und Umgebungsrepräsentationen 6 haben somit lediglich zu einem bestimmten Zeitpunkt Gültigkeit, und sind infolgedessen nur im Hinblick auf diesen Zeitpunkt interpretierbar. Daher müssen alle realen Sensordaten 4, virtuellen Sensordaten 40, und in Konsequenz auch jede aus den Sensordaten hergeleiteten Information z.B. in der Umgebungsrepräsentation 6 mit dem Zeitstempel 93 versehen werden, welcher angibt, zu welchem Zeitpunkt diese Information als gültig betrachtet werden kann. Dies ist insbesondere dann erforderlich, wenn Informationen, die zu unterschiedlichen Zeitpunkten gültig waren, miteinander fusioniert werden sollen. In diesen Fällen ist zusätzlich noch die in 3 gezeigte Zeitskala 96 zu berücksichtigen.
Für ein in 4 gezeigtes Zeitformat 932 der durch Parameter 933 gebildeten Zeitangabe des Zeitstempels 93 sind sehr viele Konventionen möglich. Zu nennen sind hier die Normen ISO 8601, eine Fülle damit verwandter nationaler Normen oder die "Unix-Time". Eine für die Datenverarbeitung geeignete Systematisierung der Zeitformate mittels einer Ontologie wird in dem Dokument "Time Ontology in OWL" beschrieben, erhältlich im Internet am 27.07.2013 unter http://www.w3.org/TR/owl-time. Ob mit dieser oder einer anderen Formalisierung, wichtig ist, dass das Zeitformat 932 des Zeitstempels 93 innerhalb der Informationseinheit 90 explizit angegeben wird, um Interpretationsfehler zu vermeiden.
Ebenso muss im Zeitstempel 93 vermerkt sein, auf welche Uhr 93l sich der Zeitstempel 93 bezieht. Module (z.B. Sensoren), in denen Zeitstempel 93 vergeben werden, haben häufig ihre eigene Uhr 931. In diesem Fall muss diese Uhr 931 im Zeitstempel 93 angegeben werden. Damit im Entwurfssystem überprüft werden kann, ob zwei Zeitstempel 93 zu einander kompatibel sind, und ob bzw. wie sich die durch diese Zeitstempel 93 annotierten Informationseinheiten 90 fusionieren lassen, müssen die jeweiligen Uhren 931 genannt und eindeutig identifiziert sein.
Dann kann im Entwurfssystem nach einer aktuell gültigen Information gesucht werden, die eine Aussage über die Zeitdifferenz zwischen den beteiligten Uhren 931 macht, d.h. eine Aussage über die Kalibrierung der Uhren 931. Da diese Kalibrierung meist selbst das Ergebnis einer Messung ist, ist die Zeitdifferenz zwischen zwei Uhren 931 im Allgemeinen eine Zufallsvariable.
Das Entwurfssystem kann ferner überprüfen, ob jeder Header 92 einer Informationseinheit 90 im System einen Zeitstempel 93 in einem bekannten Format aufweist.
Bei der Verknüpfung von zwei Informationseinheiten kann das Entwurfssystem überprüfen, ob beide Zeitstempel-Formate gleich sind oder durch im Entwurfssystem vorhandene Formatumsetzer in das gleiche Format gebracht werden können. Ebenso wird überprüft, ob beide Zeitstempel 93 sich auf die gleiche Uhr 931 beziehen, oder ob im Entwurfssystem eine Information über die Synchronizität der beiden verwendeten Uhren vorliegt, die es erlaubt, beide Zeitstempel 93 auf die gleiche Uhr 931 zu beziehen, die dann auch für eine aus den beiden Informationseinheiten hergeleitete Informationseinheit verwendet werden kann.
5 zeigt die Herkunftsangabe 94 aus 3 im Detail. Es muss berücksichtigt werden, ob Informationseinheiten, die in einem Modul zusammengeführt werden, eine gemeinsame Herkunft aufweisen. Andernfalls wird in der Regel die Sicherheit der resultierenden Information überschätzt. Im Falle, dass die fusionierten Informationen durch Normalverteilungen dargestellt werden, ergibt sich unter der Annahme der Unabhängigkeit eine stärker konzentrierte Kovarianzmatrix, als wenn die Abhängigkeit berücksichtigt würde.
Daher wird für jede Informationseinheit, die entweder Sensordaten enthält oder direkt oder indirekt von Sensordaten hergeleitet wird, die Herkunft der Information in der Herkunftsangabe 94 vermerkt. Die Herkunftsangabe 94 beinhaltet entweder den Sensor, der den entsprechenden Messwert geliefert hat, oder – wie in 5 gezeigt – einen Operator 940, mittels dem die Nutzdaten 91 hergeleitet wurden, sowie die in diese Operation eingeflossenen Quell-Informationseinheiten 941...94n.
Das Entwurfssystem erhält durch Zusammensetzung dieser Herkunftsangaben 94 ein Netz der Herleitungen und Abhängigkeiten, in dem in sehr vielen Fällen die einzelnen Zufallsvariablen genau berechnet werden können. Insbesondere im aktuellen Forschungsgebiet der "Graphical Models" sind hierzu in den letzten Jahren gute Fortschritte erzielt worden, die von dem Entwurfssystem für Fahrerassistenzsysteme genutzt werden können.
Ein einfaches Beispiel ist die Herleitung einer normalverteilten Zufallsvariablen (z. B. einer Längenmessung), die auf drei normalverteilten Beobachtungen {z₁, z₂, z₃} beruht, in zwei Schritten. Die Beobachtung bzw. hergeleitete Größe hat also die Verteilung z_i ~ N(ì_i, Σ_i). Mit der üblichen Fusionierung nach dem Prinzip der "Maximum Likelihood Estimation" ist die fusionierte Information aus z₁und z₂ normalverteilt mit dem Mittelwert ì₄ = (Σ –1 / 1 + Σ –1 / 2)^–1·Σ₂·ì₁ + (Σ –1 / 1 + Σ –1 / 2)^–1·Σ₁·ì₂ und der Kovarianzmatrix Σ₄ = (Σ –1 / 1 + Σ –1 / 2)^–1.
Entsprechend ergibt die Fusionierung von z₂und z₃ die normalverteilte Zufallsvariable z₅ mit ì₅ = (Σ –1 / 2 + Σ –1 / 3)^–1·Σ₃·ì₂ + (Σ –1 / 2 + Σ –1 / 3)^–1·Σ₂·ì₃ und Σ₅ = (Σ –1 / 2 + Σ –1 / 3)^–1.
Fusioniert man diese beiden Zwischenergebnisse unter der Annahme der Unabhängigkeit, dann erhält man die Kovarianzmatrix Σ₆ =(Σ –1 / 4 + Σ –1 / 5)^–1 = (Σ –1 / 1 + 2·Σ –1 / 2 + Σ –1 / 3)^–1.
Fusioniert man die Informationen unter Berücksichtigung der Abhängigkeiten, dann erhält man Σ₇ = (Σ –1 / 1 + Σ –1 / 2 + Σ –1 / 3)^–1, man sieht also, dass die zweite Information doppelt verwendet wurde.
Nachdem das Entwurfssystem wie oben beschrieben die Abhängigkeiten ermittelt hat, kann es also aus dem Fusionsergebnis unter Annahme der Unabhängigkeit das richtige Ergebnis dadurch ermitteln, dass es die doppelt verwendete Information einmal wieder abzieht.
Das Entwurfssystem unterstützt die Entdeckung und Kompensation von verborgenen Abhängigkeiten in der Herleitung durch die Analyse des Herleitungsgraphen, der aus den formal gegebenen Herkunftsangaben 94 über die Quelle der Informationseinheiten 90 aufgebaut wird. In diesem Graphen werden durch entsprechende Graphenalgorithmen rekonvergente Zweige und damit Abhängigkeiten entdeckt.
Weiter kann das Entwurfssystem Algorithmen aus dem Gebiet der "Graphical Models" enthalten, die analog dem im vorigen Abschnitt gegebenen Beispiel die korrekte Information aufgrund der ermittelten Abhängigkeiten herleiten.
Im Folgenden wird erneut auf 3 Bezug genommen. Diejenigen Nutzdaten 91, die entweder unmittelbar aus Sensordaten bestehen oder aus Sensordaten hergeleitet werden, sind in der Regel nicht sicher. Sie sind möglicherweise verrauscht und weisen eine gewisse Streuungsbreite auf, oder sie entsprechen gar keinem physikalischen Phänomen (d.h. sie sind Artefakte), oder sie entsprechen einem Phänomen der physikalischen Welt, das aber in einer gegebenen Umgebungsrepräsentation 6 nicht gespiegelt wird.
Es ist also sinnvoll, mit der Plausibilität 95 im Header 92 eine Metainformation darüber zu geben, wie sehr einer gegebenen Informationseinheit 90 bzw. deren Nutzdaten 91 getraut werden soll. Falls die Nutzdaten 91 eine Wahrscheinlichkeitsdichteverteilung aufweisen, kann die Plausibilität 95 auch als gleichverteilte Komponente einer Mischverteilung repräsentiert werden. Nachdem aber auch Aspekte der Welt beschrieben werden sollen, die am besten durch Relationen ausgedrückt werden, welchen nicht ohne weiteres auf natürliche Weise eine Wahrscheinlichkeitsdichteverteilung zugewiesen werden kann, wird die Plausibilität 95 als Bestandteil des Headers 92 für jede Informationseinheit 90 im Entwurfssystem gefordert.
Die Plausibilität 95 wird bei Fusionierung, Verknüpfung oder Weiterverarbeitung der Informationseinheiten 90 ebenfalls verknüpft. Die hierbei anzuwendenden Verknüpfungsregeln liegen dabei nicht a priori fest, sondern sie richten sich nach den Inhalten der Nutzdaten 91. Das Entwurfssystem berechnet daher nach den für die jeweiligen Nutzdaten 91 geeigneten Verknüpfungsregeln zur Herleitung einer neuen Informationseinheit 90 eine Plausibilität 95 ausgehend von den Plausibilitäten 95 der in die Herleitung einfließenden Informationseinheiten 90.
Die Verknüpfungsregeln für die Plausibilität 95, die für einen gegebenen Typ von Nutzdaten 91 der Informationseinheiten 90 angewendet werden sollen, sind im Entwurfssystem abgelegt. Damit unterstützt das Entwurfssystem die korrekte Komposition von Herleitungen im Gesamtsystem der verschiedenen Fahrerassistenzsysteme.
Für jede Informationseinheit 90 wird im Zeitstempel 93 vermerkt, zu welchem Zeitpunkt die jeweiligen Nutzdaten 91 für gültig gehalten werden sollen. Wenn zwei (oder mehr) Informationseinheiten 90 fusioniert werden sollen, müssen diese Zeitpunkte zusammenpassen. Allerdings werden in der Regel die Zeitstempel 93 nicht völlig übereinstimmen. Daher müssen Informationseinheiten 90, die fusioniert werden sollen, auf einen gemeinsamen neuen Zeitstempel 93 normalisiert werden. Hierzu wird die Zeitskala 96 im Header 92 benötigt.
Die Zeitskala 96 einer Informationseinheit 90 gibt an, in welcher Weise und in welchem Ausmaß die Nutzdaten 91 „veralten“. Dies hängt vom Inhalt der Nutzdaten 91 ab. Wenn die Nutzdaten 91 z.B. die Position eines Gebäudes betreffen, dann ist die Zeitskala 96 "lang": es ist nicht zu erwarten, dass sich die tatsächliche Position des Gebäudes innerhalb der Dauer einer Ausführung der Fahrerassistenzfunktion verändert.
Wenn die Nutzdaten 91 dagegen ein Fahrzeug betreffen, etwa eine Schätzung des Ortes eines anderen Fahrzeugs, dann wird bei bewegten Fahrzeugen die Ortsschätzung zunehmend unzutreffender, je länger die entsprechende Messung zurückliegt. Ein Spezialfall dieser Betrachtung ist das Prozessrauschen im Kalmanfilter, das die Zunahme der Unsicherheit durch die Addition eines zusätzlichen Rauschens ausdrückt.
Technisch kann die Zeitskala 96 implementiert werden als eine Abbildung ó:(x_t, ΔT) → x_t+ΔT einer Zufallsvariablen x_t auf eine Zufallsvariable x_t+ΔT, wobei die zweite Zufallsvariable in der Regel eine größere Streuung aufweist.
Da die Informationseinheiten 90 im Entwurfssystem auf einer Metaebene ihrer Bedeutung nach durch die Header 92 charakterisiert werden, kann das Entwurfssystem einem Entwickler geeignete Zeitskalen 96 für die jeweilige Zufallsvariable, welche als Nutzdaten 91 in der Informationseinheit 90 enthalten ist, vorschlagen. Dieser Vorschlag kann auf Langzeitbeobachtungen des tatsächlichen typischen Verlaufs der Zufallsvariablen mit dieser bestimmten Interpretation auf der Metaebene beruhen. Die Zeitskalen 96 können also gelernt werden.
6 zeigt die Nutzdaten 91 aus 3 im Detail. Hierbei kann es sich um unterschiedliche Informationen handeln. Zum Einen werden die Inhalte der Fahrerassistenzsysteme selbst modelliert bzw. mit semantischer Metainformation versehen. Zum Anderen werden auch verschiedene Aspekte der Umwelt, des Fahrzeugs oder des Fahrers modelliert. Da die Nutzdaten 91 somit von sehr verschiedener Art sein können, sind in den Nutzdaten 91 von Fall zu Fall andere Strukturelemente enthalten. Wesentlich dabei ist, dass die Unsicherheit der Nutzdaten 91 angemessen repräsentiert wird.
Nutzdaten 91, die physikalische Sachverhalte wiederspiegeln (z.B. eine gemessene Distanz), lassen sich im Allgemeinen nicht mit einer Zahl erfassen, sondern sind meistens aus Messungen gewonnene Zufallsvariablen. Daher werden diese Variablen auch als Zufallsvariablen modelliert und so als Wert 915 in die Nutzdaten 91 eingetragen, dass auch die Wahrscheinlichkeitsdichtefunktion explizit angegeben wird. Als Approximation an extrem wenig streuende Zufallsvariablen ist auch die Dirac-Verteilung zulässig. Analog gilt das auch für nicht streng physikalische Sachverhalte, wie z.B. einen Ermüdungszustand des Fahrers, Grad der Ungeduld eines anderen Verkehrsteilnehmers, etc.
Für Nutzdaten 91, die physikalische Gegebenheiten beschreiben, wird eine Einheit für die physikalische Größe (also z.B. für einen Entfernungswert die SI-Maßeinheit m) beispielsweise im Kommentarfeld 911 in die Datenstruktur der Nutzdaten 91 aufgenommen.
Weiterhin muss die Datenstruktur der Nutzdaten 91 eine Kodierung 914 der Nutzdaten 91 angeben, sofern hierfür unterschiedliche Möglichkeiten vorliegen (z.B. für Längenmessung eine lineare oder eine logarithmische Skala). Auch bei der Beschreibung von Position und Orientierung im Raum gibt es eine große Anzahl durchaus geläufiger Kodierungen. Hier ist die Angabe im Feld Kodierung 914 erforderlich um Fehler zu vermeiden.
Ggf. muss die Datenstruktur der Nutzdaten 91 auch eine formale Spezifikation eines Kontexts der Nutzdaten 91 angeben – z.B. bei einem Abstandswert das Objekt, von dem aus gemessen wird, und das Objekt, bis zu dem hin gemessen wird, wie im Folgenden noch beschrieben wird.
Angaben zu Auflösung, Diskretisierung und mögliche Datentypen in der Implementierung, sowie zu einem Rechenbedarf eines Datenverarbeitungsschrittes (z.B. Schätzung der Anzahl der Operationen in einem Rechenwerk und der Anzahl der Speicherzugriffe) können ebenfalls erforderlich sein und werden beispielsweise im Kommentarfeld 911 hinterlegt.
Ohne Einschränkung der Allgemeinheit wird im Folgenden anhand der 3 bis 6 ein Beispiel für die Ausgestaltung einer Informationseinheit 90 mit einem Header 92 und Nutzdaten 91 zum Zwecke einer Entfernungsangabe dargestellt.
Eine Entfernungsangabe bezeichnet einen Abstand zwischen zwei verschiedenen Objekten. Nachdem die Objekte nicht am gleichen Ort bleiben müssen, gehört zur Entfernungsangabe auch der Zeitpunkt, zu dem eine gewisse Entfernung gegeben war. Ebenso lässt sich den Umständen entnehmen, welche Gültigkeitsdauer der getroffenen Aussage über die Entfernung beizumessen ist. Diese Aspekte betreffen alle Aussagen, die von Sensoren direkt oder auf dem Wege der Herleitung innerhalb von Fahrerassistenzfunktionen getroffen werden, und sie werden deshalb im Header 92 zusammengefasst, wie dies bereits zuvor erläutert wurde. Die jeweils unterschiedlichen Aspekte einer Messung bzw. einer aus den Messungen hergeleiteten Aussage finden sich hingegen in den Nutzdaten 91 selbst.
Beispielsweise geht aus verschiedenen Sensormessungen hervor, dass der (kürzeste) Abstand zwischen Fahrzeug und einem Hindernis in der Umgebung (z.B. Baum Nr. 15 aus einer Objektliste) 5.32 m beträgt. Dann enthält der Header 92 als Plausibilität 95, dass diese Aussage gilt (z.B. in einem Bereich von 0 bis 1 den Plausibilitätswert 0.99 im Feld Plausibiltät 95). Im Zeitstempel 93 wird eingetragen, dass die Aussage galt zum Zeitpunkt 2013/05/26/17/59/234/345 (als Parameter 933 aus 4) MESZ (als Zeitformat 932 aus 4) nach der Uhr des Navigationsrechners im Fahrzeug (als Uhr 931 aus 4). Aus der Fahrzeuggeschwindigkeit und dem Typ des Objekts soll folgen, dass die Plausibilität 95 dieser Aussage sich alle 0.2 s halbiert. Diese Information wird als Zeitskala 96 im Header 92 hinterlegt. Die Herkunftsangabe 94 zeigt an, dass der Abstandswert aus einer Folge von Messungen gefolgert wird, wobei als Operator 940 (vgl. 5) der Fusionsoperator angegeben wird, der den letzten Inferenzschritt ausgeführt hat; weiter sind alle Quell-Informationseinheiten 941...94n (vgl. 5) aufgelistet, aus denen der Operator 940 die Inferenz gebildet hat.
Die Nutzdaten 91 selbst hingegen enthalten die spezifischen Angaben zu dieser Aussage und sind in ihrem schematischen Aufbau in 6 auf der linken Seite gezeigt. Als Referenz 912, d.h. als Bezugspunkt, wird das Fahrzeug und als Referenzierer 913, d.h. ein Objekt, welches sich auf den Bezugspunkt bezieht, ein Baum Nr. 15 in die Datenstruktur eingetragen. Naturgemäß ist der Abstandswert eine Zufallsvariable – der wahre Abstand ist möglicherweise im Mittel der angegebene Wert, Abweichungen sind jedoch möglich. Es wird daher als Wert 915 eine approximierende Wahrscheinlichkeitsdichteverteilung (WDV) angegeben.
Der Wert 915 ist im rechten Teil der 6 detailliert gezeigt. Neben einem WDV-Kommentarfeld 916 ist als WDV-Typ 917 beispielsweise eine Normalverteilung und als WDV-Parameter 918 ein Mittelwert 5.32 und eine Varianz 0.1 eingetragen.
Das Entwurfssystem unterstützt einen Entwickler zum Beispiel, indem Plausibilität und Konsistenz hergeleiteter Größen durch Inferenz über den zuvor erläuterten Metainformationen, welche den jeweiligen Informationseinheiten 90 entnommen werden, überprüft wird. Bei einer Positionsschätzung, die sich durch Komposition zweier Positionsschätzungen ergibt, überprüft das Entwurfssystem, ob der Referenzierer der ersten Positionsschätzung gleich der Referenz der zweiten Positionsschätzung ist, d.h. ob die Komposition in der richtigen Reihenfolge ausgeführt ist.
Ebenso wie die übrigen Daten sind auch die Daten in der in 2 gezeigten Umgebungsrepräsentation 6 explizit auf der Metaebene wie im Kontext der 3 bis 6 erläutert beschrieben. Dies gilt also auch für den Zeitstempel 93, zu dem Informationen für gültig gehalten werden und für die Zeitskala 96.
Beispielsweise handelt es sich bei der Umgebungsrepräsentation 6 um eine Belegungsgitterkarte. Dann werden zusätzlich in den Nutzdaten 91 die Größe der Gitterzellen, die Anzahl der Gitterzellen, und die Belegungswahrscheinlichkeit vermerkt. Für die Belegungswahrscheinlichkeit sind unterschiedliche Optionen möglich, die je nach Einsatzzweck gewählt werden. Wie auch bei den Aussagen über den Abstand wird der Typ der Wahrscheinlichkeitsdichteverteilung explizit genannt.
Zuvor wurde beschrieben, dass die Informationseinheit 90 als Nutzdaten 91 Sensordaten oder z.B. eine Entfernungsangabe enthalten kann. Aus solchen Informationseinheiten 90 lassen sich durch Herleitung komplexere Informationseinheiten 90 bilden, welche höher aggregierte Nutzdaten 91 enthalten als die in die Herleitung eingeflossenen Informationseinheiten 90. Die hergeleitete Informationseinheit 90 kann eine Objekthypothese enthalten, während die eingeflossenen Informationseinheiten 90 einzelne Merkmale enthalten. In diesem Sinne kann eine Informationseinheit 90 auch eine Gitterkarte und somit die Umgebungsrepräsentation 6 selbst enthalten. Alternativ kann auch jede einzelne Gitterzelle durch eine Informationseinheit 90 modelliert 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

WO 2007017308 A1 [0013]
WO 2006089941 A1 [0014]

Zitierte Nicht-Patentliteratur

Standard Step AP 242 [0011]
http://www.steptools.com/support/stdev_docs/express/ap242/htm l/index.html [0011]
Michael Compton et. al., "The SSN ontology of the W3C semantic sensor network incubator group", Web Semantics: Science, Services and Agents on the World Wide Web, Volume 17, Dezember 2012, p. 25–32, ISSN 1570-8268 [0012]
Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, Kap. 6 [0050]
Normen ISO 8601 [0071]
http://www.w3.org/TR/owl-time [0071]

Claims

Entwurfssystem für ein Fahrerassistenzsystem, – umfassend mindestens ein Modul, eingerichtet zur Erzeugung realer Sensordaten (4) oder virtueller Sensordaten (40), und – umfassend mindestens ein Modul, eingerichtet zur rechnergestützten Ableitung einer Umgebungsrepräsentation (6) aus den realen Sensordaten (4) oder virtuellen Sensordaten (40), dadurch gekennzeichnet, dass – das Entwurfssystem zur rechnergestützten Verarbeitung maschinenlesbarer semantischer Metadaten eingerichtet ist, welche Eigenschaften der realen Sensordaten (4) und/oder der virtuellen Sensordaten (40) und/oder von Daten in der Umgebungsrepräsentation (6) beschreiben, und – das Entwurfssystem eingerichtet ist zur rechnergestützten Überprüfung und/oder Sicherstellung einer Gültigkeit von Daten in der Umgebungsrepräsentation (6) anhand der semantischen Metadaten.
Entwurfssystem nach Anspruch 1, – mit einem Speicher und mit einem Mikroprozessor, welcher programmiert ist zur Abspeicherung – der realen Sensordaten (4) oder der virtuellen Sensordaten (40), oder – von Daten in der Umgebungsrepräsentation (6), oder – von weiteren Daten, welche in den Modulen enthalten sind, jeweils als Nutzdaten (91) in einer Informationseinheit (90) in dem Speicher, – wobei jede Informationseinheit (90) einen Header (92) aufweist, welcher zumindest einige der folgenden semantischen Metadaten enthält, welche Eigenschaften der Nutzdaten (91) beschreiben: – ein Zeitstempel (93), welcher angibt, zu welchem Zeitpunkt die Nutzdaten (91) gültig sind oder waren, – eine Herkunftsangabe (94), welche – einen Sensor bezeichnet, von dem die Nutzdaten (91) erzeugt wurden, oder – mindestens einen Operator (940) und Quell-Informationseinheiten (941...94n) angibt, anhand derer die Nutzdaten (91) hergeleitet wurden, – eine Plausibilität (95), welche angibt, in welchem Umfang sich nachfolgende Inferenzschritte auf die Nutzdaten (91) stützen dürfen, und/oder – eine Zeitskala (96), welche angibt, wie sich die Plausibilität (95) der Nutzdaten (91) zeitlich entwickelt.
Entwurfssystem nach Anspruch 2, – bei dem der Header (92) sämtliche der in Anspruch 2 genannten semantischen Metadaten enthält.
Entwurfssystem nach Anspruch 2 oder 3, – bei dem in dem Header (92) oder in dem Zeitstempel (93) ein Zeitformat (932) des Zeitstempels (93) abgespeichert ist, und – bei dem in dem Header (92) oder in dem Zeitstempel (93) eine Uhr (931), auf welche sich der Zeitstempel (93) bezieht, angegeben ist.
Entwurfssystem nach Anspruch 4, – bei dem der Mikroprozessor programmiert ist zur Überprüfung für alle Informationseinheiten (90), ob der Zeitstempel (93) vorhanden ist und das Zeitformat (932) des Zeitstempels (93) bekannt ist, und – bei dem der Mikroprozessor programmiert ist – zur Verknüpfung einer ersten und einer zweiten Informationseinheit mit einem Herleitungsoperator, – zur Herleitung einer dritten Informationseinheit aus der Verknüpfung, und – zur Abspeicherung der dritten Informationseinheit in dem Speicher, – wobei der Mikroprozessor programmiert ist zur Überprüfung, ob das Zeitformat (932) des Zeitstempels (93) der ersten Informationseinheit mit dem Zeitformat (932) des Zeitstempels (93) der zweiten Informationseinheit übereinstimmt, und andernfalls zur Konvertierung des Zeitstempels (93) der ersten Informationseinheit in das Zeitformat (932) des Zeitstempels (93) der zweiten Informationseinheit, – wobei der Mikroprozessor programmiert ist zur Überprüfung, ob die Uhr (931) des Zeitstempels (93) der ersten Informationseinheit mit der Uhr (931) des Zeitstempels (93) der zweiten Informationseinheit identisch ist, und andernfalls zur Umrechnung des Zeitstempels (93) der ersten Informationseinheit anhand einer bekannten Abweichung der Uhren, sodass er sich ebenfalls auf die Uhr (931) des Zeitstempels (93) der zweiten Informationseinheit bezieht, und – wobei der Mikroprozessor programmiert ist zur Normalisierung des Zeitstempels (93) der ersten Informationseinheit und des Zeitstempels (93) der zweiten Informationseinheit unter Berücksichtigung der Zeitskalen (96) der ersten Informationseinheit und der zweiten Informationseinheit auf einen gemeinsamen neuen Zeitstempel, und zur Abspeicherung des gemeinsamen neuen Zeitstempels im Header (92) der dritten Informationseinheit im Speicher.
Verfahren zum Entwurf eines Fahrerassistenzsystems, – bei dem mindestens ein Modul reale Sensordaten (4) oder virtuelle Sensordaten (40) erzeugt, – bei dem mindestens ein Modul aus den realen Sensordaten (4) oder den virtuellen Sensordaten (40) rechnergestützt eine Umgebungsrepräsentation (6) ableitet, dadurch gekennzeichnet, dass – das Entwurfssystem maschinenlesbare semantische Metadaten rechnergestützt verarbeitet, welche Eigenschaften der realen Sensordaten (4) und/oder der virtuellen Sensordaten (40) und/oder der Umgebungsrepräsentation (6) beschreiben, und – das Entwurfssystem anhand der semantischen Metadaten rechnergestützt eine Gültigkeit von Daten in der Umgebungsrepräsentation (6) überprüft und/oder sicherstellt.
Verfahren nach Anspruch 6, – bei dem das Entwurfssystem – die realen Sensordaten (4) oder die virtuellen Sensordaten (40) oder – Daten in der Umgebungsrepräsentation (6) oder – weitere Daten, welche in den Modulen enthalten sind, jeweils als Nutzdaten (91) in einer Informationseinheit (90) speichert, – wobei jede Informationseinheit (90) einen Header (92) aufweist, welcher zumindest einige der folgenden semantischen Metadaten enthält, welche Eigenschaften der Nutzdaten (91) beschreiben: – ein Zeitstempel (93), welcher angibt, zu welchem Zeitpunkt die Nutzdaten (91) gültig sind oder waren, – eine Herkunftsangabe (94), welche – einen Sensor bezeichnet, von dem die Nutzdaten (91) erzeugt wurden, oder – mindestens einen Operator (940) und Quell-Informationseinheiten (941...94n) angibt, anhand derer die Nutzdaten (91) hergeleitet wurden, – eine Plausibilität (95), welche angibt, in welchem Umfang sich nachfolgende Inferenzschritte auf die Nutzdaten (91) stützen dürfen, und/oder – eine Zeitskala (96), welche angibt, wie sich die Plausibilität (95) der Nutzdaten (91) zeitlich entwickelt.
Verfahren nach Anspruch 7, – bei dem der Header (92) sämtliche der in Anspruch 7 genannten semantischen Metadaten enthält.
Verfahren nach Anspruch 7 oder 8, – bei dem in dem Header (92) oder in dem Zeitstempel (93) ein Zeitformat (932) des Zeitstempels (93) abgespeichert wird, und – bei dem in dem Header (92) oder in dem Zeitstempel (93) eine Uhr (931), auf welche sich der Zeitstempel (93) bezieht, angegeben wird.
Verfahren nach Anspruch 9, – bei dem das Entwurfssystem rechnergestützt für alle Informationseinheiten (90) überprüft, ob der Zeitstempel (93) vorhanden ist und das Zeitformat (932) des Zeitstempels (93) bekannt ist, und – bei dem das Entwurfssystem eine erste und eine zweite Informationseinheit mit einem Herleitungsoperator verknüpft und dadurch eine dritte Informationseinheit herleitet, – wobei das Entwurfssystem überprüft, ob das Zeitformat (932) des Zeitstempels (93) der ersten Informationseinheit mit dem Zeitformat (932) des Zeitstempels (93) der zweiten Informationseinheit übereinstimmt, und den Zeitstempel (93) der ersten Informationseinheit andernfalls in das Zeitformat (932) des Zeitstempels (93) der zweiten Informationseinheit konvertiert, – wobei das Entwurfssystem überprüft, ob die Uhr (931) des Zeitstempels (93) der ersten Informationseinheit mit der Uhr (931) des Zeitstempels (93) der zweiten Informationseinheit identisch ist, und den Zeitstempel (93) der ersten Informationseinheit andernfalls anhand einer bekannten Abweichung der Uhren umrechnet, sodass er sich ebenfalls auf die Uhr (931) des Zeitstempels (93) der zweiten Informationseinheit bezieht, und – wobei das Entwurfssystem den Zeitstempel (93) der ersten Informationseinheit und den Zeitstempel (93) der zweiten Informationseinheit unter Berücksichtigung der Zeitskalen (96) der ersten Informationseinheit und der zweiten Informationseinheit auf einen gemeinsamen neuen Zeitstempel normalisiert, welcher im Header (92) der dritten Informationseinheit abgespeichert wird.
Verfahren nach einem der Ansprüche 7 bis 10, – bei dem das Entwurfssystem für eine Informationseinheit (90) anhand der Herkunftsangabe (94) sowie der Herkunftsangaben (94) in den Quell-Informationseinheiten (941...94n), aus denen die Informationseinheit (90) hergeleitet wurde, rekursiv einen Herleitungsgraphen erstellt, – bei dem das Entwurfssystem durch Graphenalgorithmen rekonvergente Zweige in dem Herleitungsgraphen identifiziert, und – bei dem das Entwurfssystem Abhängigkeiten, welche sich aus den rekonvergenten Zweigen im Herleitungsgraphen ergeben, durch eine Modifikation der Herleitung der Informationseinheit (90) kompensiert.
Verfahren nach einem der Ansprüche 7 bis 11, – bei dem das Entwurfssystem eine erste und eine zweite Informationseinheit mit einem Herleitungsoperator verknüpft und dadurch eine dritte Informationseinheit herleitet, und – bei dem das Entwurfssystem in Abhängigkeit von dem Herleitungsoperator die Plausibilität (95) der dritten Informationseinheit aus den Plausibilitäten (95) der ersten und der zweiten Informationseinheit berechnet.
Verfahren nach einem der Ansprüche 7 bis 12, – bei dem das Entwurfssystem anhand einer Langzeitbeobachtung eines typischen Verlaufs einer Zufallsvariable eine geeignete Zeitskala durch maschinelles Lernen ermittelt, und – bei dem das Entwurfssystem einem Entwickler bei der Definition einer neuen Informationseinheit, in welcher die Zufallsvariable abgespeichert werden soll, die geeignete Zeitskala zur Eintragung als Zeitskala (96) im Header (92) vorschlägt.
Computerlesbarer Datenträger, – auf dem ein Computerprogramm gespeichert ist, welches das Verfahren nach einem der Ansprüche 6 bis 13 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 6 bis 13 ausführt.