Kollisionsvermeidung für Fahrzeuge als Beispielanwendung für ein

Transcription

Technische Universität München
Fakultät für Informatik
Lehrstuhl IX
Angewandte Informatik / Kooperative Systeme
Diplomarbeit in Informatik
Kollisionsvermeidung für Fahrzeuge als Beispielanwendung
für ein ontologisches Kontextmodell
Georg Lutz
Aufgabensteller:
Prof. Dr. Johann Schlichter
Betreuer:
Robert Eigner
Abgabedatum:
15.07.2007
Ich versichere, dass ich diese Diplomarbeit
selbständig verfasst und nur die angegebenen
Quellen und Hilfsmittel verwendet habe.
München, den 15.Juli 2007
Georg Lutz
2
Zusammenfassung
In dieser Arbeit wird sowohl eine Anwendung zur Kollisionsvermeidung für Fahrzeuge entwickelt, als auch ein ontologisches Kontextmodell, dessen sich die Anwendung bedient. Ziel der Arbeit ist es herauszufinden, inwieweit sich die Erwartungen, die mit dem Einsatz von Ontologien zur Kontextmodellierung verbunden
sind, erfüllen, und ob ihr Einsatz im Zusammenhang mit Berechnungen zur Kollisionsvermeidung überhaupt sinnvoll ist.
Um ontologische Modelle zu entwickeln und in ein Programm einbinden zu
können, benötigt man unterschiedliche Werkzeuge, wie zum Beispiel einen Ontologieeditor, eine Sprache zur Beschreibung der Ontologie und eine Programmierumgebung. Die in dieser Arbeit verwendeten Werkzeuge werden hier ebenso
vorgestellt wie mögliche Alternativen. Auch eine Abgrenzung zu anderen Varianten der Kontextmodellierung wird vorgenommen und die Vorteile des Einsatzes
von Ontologien werden untersucht.
Von der Anwendung zur Kollisionsvermeidung, genannt Fahrerassistent, werden
zwei Varianten entwickelt. Die erste Variante bedient sich eines einfachen Kontextmodells, das sich auf die Erfassung der Fahrzeugdaten aller Verkehrsteilnehmer,
die sich in der Nähe befinden, beschränkt. Die zweite Variante erweitert dieses
einfache Kontextmodell um eine Ontologie, die umweltbezogene Sensordaten wie
Temperatur oder Helligkeit modelliert, und eine Ontologie, die das Straßennetz
modelliert. Es zeigt sich, dass es mit Hilfe der zusätzlich zur Verfügung stehenden
Kontextinformationen möglich ist, sowohl bessere Unfallvorhersagen zu treffen, als
auch die Daten zur Verfügung zu stellen, die für die Ermittlung einer der Situation
angemessenen Reaktion auf die Unfallvorhersagen nötig sind.
Ein Vergleich der beiden Varianten zeigt, dass zusätzliche Kontextinformationen
einerseits zu einer besseren Qualität der Kollisionsvorhersage führen, andererseits
aber auch die Gefahr besteht, dass sie die Geschwindigkeit des Fahrerassistenten erheblich verringern. Die Untersuchung der Geschwindigkeiten führt zu dem
Ergebnis, dass Ontologien den Anforderungen des Fahrerassistenten als Echtzeitanwendung genügen, wenn sie nicht zu umfangreich und komplex sind. Auch die
Möglichkeit, externe Ontologien in das eigene Modell einzubinden, um zum Beispiel auf Herstellerdaten zugreifen zu können, wird untersucht.
Für beide Varianten werden mögliche Erweiterungen der Kontextmodelle und
der Funktionalität des Fahrerassistenten vorgestellt. Auch denkbare Verallgemeinerungen und sich daraus ergebende Einsatzmöglichkeiten der Ontologien im Straßenverkehr allgemein werden am Ende dieser Arbeit angedacht.
Inhaltsverzeichnis
1 Einleitung
1.1 Idee und Motivation
1.2 Aufgabenstellung . .
1.3 Begriffserläuterungen
1.4 Aufbau der Arbeit .
.
.
.
.
7
. 7
. 9
. 9
. 12
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
16
17
17
19
19
19
20
21
21
23
24
26
29
30
31
32
32
35
36
38
39
39
3 Erste Variante des Assistenten
3.1 Beschreibung des Szenarios . . . . . . . . . . . . . . . . . . . . . . .
3.2 Anforderungen an Ontologie und Architektur . . . . . . . . . . . . .
3.3 Ontologie und Regelsatz . . . . . . . . . . . . . . . . . . . . . . . .
41
41
41
43
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Architektur
2.1 Aufgabenstellung und Szenarien . . . . . . . . . . . . . . . . .
2.2 Anforderung an Anwendungen und Architektur . . . . . . . .
2.3 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Überblick über die logischen Komponenten . . . . . . .
2.3.2 Verkehrssimulator . . . . . . . . . . . . . . . . . . . . .
2.3.3 Hauptprogramm . . . . . . . . . . . . . . . . . . . . .
2.3.4 Ein- und Ausgabe . . . . . . . . . . . . . . . . . . . . .
2.3.5 Ontologie und Reasoner . . . . . . . . . . . . . . . . .
2.3.6 Anwendung . . . . . . . . . . . . . . . . . . . . . . . .
2.3.7 Auswertung der Kontrollsignale . . . . . . . . . . . . .
2.4 Verwendete Werkzeuge und Erwartungen an die Ontologie . .
2.4.1 Visual Traffic Simulation . . . . . . . . . . . . . . . . .
2.4.2 OWL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3 Protégé . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.4 SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.5 Jena . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.6 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.7 Erwartungen an die ontologische Kontextmodellierung
2.5 Alternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 Andere Verkehrssimulatoren . . . . . . . . . . . . . . .
2.5.2 OWL-QL . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.3 RDF und RDF Schema . . . . . . . . . . . . . . . . . .
2.5.4 Weitere Alternativen . . . . . . . . . . . . . . . . . . .
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.4
3.5
3.6
3.3.1 Grundsätzliches und Aufbau . . . . . . . . . . . . .
3.3.2 Fahrzeugontologie . . . . . . . . . . . . . . . . . . .
3.3.3 Importbeispiel . . . . . . . . . . . . . . . . . . . . .
3.3.4 Regelsatz . . . . . . . . . . . . . . . . . . . . . . .
Kollisionsberechnung . . . . . . . . . . . . . . . . . . . . .
3.4.1 Fahrzeuge als sich bewegende Rechtecke . . . . . .
3.4.2 Die Fourier-Motzkin-Elimination . . . . . . . . . .
3.4.3 Erfüllbarkeit und Lösung . . . . . . . . . . . . . . .
3.4.4 Zusammenfassung . . . . . . . . . . . . . . . . . . .
Implementierung des Fahrerassistenten . . . . . . . . . . .
3.5.1 Die Klasse OntoCar.java . . . . . . . . . . . . . . .
3.5.2 Die Klasse InputOutput.java . . . . . . . . . . . . .
3.5.3 Die Klasse OntoAssistant.java . . . . . . . . . . . .
3.5.4 Die Klasse ExtOntology.java . . . . . . . . . . . . .
3.5.5 Die Klasse Inquiry.java . . . . . . . . . . . . . . . .
3.5.6 Die Klasse Evaluation.java . . . . . . . . . . . . . .
3.5.7 Die Klasse FMElim.java . . . . . . . . . . . . . . .
3.5.8 Die Klasse CollisionLogic.java . . . . . . . . . . . .
3.5.9 Weitere Klassen . . . . . . . . . . . . . . . . . . . .
3.5.10 Änderungen am Verkehrssimulator . . . . . . . . .
Ergebnisse, Schwachpunkte und Erweiterungsmöglichkeiten
3.6.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . .
3.6.2 Schwachpunkte und mögliche Lösungen . . . . . . .
3.6.3 Erweiterungsmöglichkeiten . . . . . . . . . . . . . .
3.6.4 Zusammenfassung . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
49
50
53
54
57
59
63
64
65
67
67
68
68
69
70
70
71
71
74
74
78
80
83
4 Zweite Variante des Assistenten
4.1 Beschreibung des Szenarios . . . . . . . . . . . . . . . . . . . . . .
4.2 Unterschiede und Gemeinsamkeiten bei Ansprüchen an Ontologie,
Regeln und Architektur im Vergleich zum ersten Szenario . . . . .
4.3 Die neuen Ontologien und die Erweiterung der Fahrzeugontologie
4.3.1 Umweltontologie . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Straßenontologie . . . . . . . . . . . . . . . . . . . . . . .
4.3.3 Erweiterung der Fahrzeugontologie . . . . . . . . . . . . .
4.4 Änderungen an der restlichen Implementierung . . . . . . . . . . .
4.5 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
5 Vergleich und Schlussfolgerungen
5.1 Vergleich der beiden Szenarien . .
5.2 Weitere Einsatzmöglichkeiten . .
5.3 Mögliche Verallgemeinerungen . .
5.4 Anpassungsfähigkeit und Grenzen
101
. 101
. 106
. 110
. 112
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
. 84
85
85
85
91
96
96
98
6 Diskussion
114
6.1 Erwartungen und Ergebnisse . . . . . . . . . . . . . . . . . . . . . . 114
6.2 Eignung des Ansatzes der ontologischen Kontextmodellierung . . . 115
6.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Abbildungsverzeichnis
119
Literaturverzeichnis
120
Quellcode, Ontologien und Regeln
CD-ROM
6
1 Einleitung
1.1 Idee und Motivation
Moderne Fahrzeuge werden mit immer mehr Elektronik ausgerüstet. Eine Vielzahl von Sensoren liefern Informationen über das Fahrzeug und seine Umgebung.
Fahrzeugbezogene Informationen sind zum Beispiel die aktuelle Geschwindigkeit,
die Bremsbeschleunigung, eine eventuell eingestellte Höchstgeschwindigkeit oder
der Einschlagswinkel des Lenkrads. Beispiele für Umgebungssensoren sind Thermometer, Regensensoren, Helligkeitssensoren oder Sensoren, die den Abstand zum
nächsten Objekt vor oder hinter dem Fahrzeug messen.
Auch der Einsatz von Computern in Fahrzeugen nimmt zu. Sie unterstützen oder
korrigieren das Verhalten des Fahrers beziehungsweise übernehmen Funktionen
der Mechanik. So ist es zum Beispiel möglich die Bremssignale elektronisch zu
übertragen beziehungsweise die Bremskraft elektronisch so anzupassen, dass ein
Blockieren der Räder verhindert wird.
Eine weitere Neuerung, die mehr und mehr zunimmt, sind die Satelliten gestützten Navigationssysteme. Sie erlauben zum Beispiel die Bestimmung des genauen
Standorts und finden für den ortsunkundigen Fahrer den Weg zu seinem Ziel.
Diese vielzähligen Informationen sind bis jetzt noch auf das einzelne Fahrzeug
beschränkt, aber in Zukunft sollen die Fahrzeuge miteinander vernetzt werden, so
dass dem einzelnen Fahrzeug neben seinen eigenen Sensoren noch weitere Daten
über die anderen Verkehrsteilnehmer zur Verfügung stehen. Ein solches Netzwerk
von Fahrzeugen bezeichnet man auch als Vehicular Ad Hoc Network (VANet).
VANets sind eine spezielle Form der Mobile Ad Hoc Networks (MANet) [wik07a].
Da die Knoten eines VANets sich bewegende Fahrzeuge sind, ist seine Struktur
dezentral und selbstorganisierend.
Die zusätzlichen Daten sollten es einerseits ermöglichen, viele unterschiedliche
Dienste und Anwendungen in einem VANet einzusetzen. So könnten sich die Fahrzeuge zum Beispiel gegenseitig vor Unfällen oder Glatteis warnen. Auch wesentlich
verbesserte Systeme zur Kollisionsvermeidung sind denkbar. Andererseits muss eine solche Vielzahl von Informationen wohl strukturiert werden. Die Fahrzeuge
müssen ihre Daten in Formaten organisieren und übers Netzwerk senden, die austauschbar sind, da sonst keine wirkliche Kommunikation möglich ist.
Zur Lösung dieses Problems bieten sich die Techniken einer weiteren Entwicklung der letzten Jahre an, des Semantic Webs. Hier werden Informationen mit Hilfe
von Ontologien in maschinenlesbarer Form organisiert. Ontologien beschreiben Informationen durch abstrakte Konzepte, deren Eigenschaften und Beziehungen mit
7
Hilfe einer eindeutigen, formalen Sprache. In einem ontologischen Modell können
unter anderem Begriffshierarchien definiert werden. So kann man zum Beispiel
festlegen, dass sowohl ein PKW als auch ein LKW Fahrzeuge sind und der Begriff
Auto dasselbe beschreibt wie der Begriff PKW. Somit muss also ein Auto auch ein
Fahrzeug sein. Außerdem erlauben es Ontologien Regeln aufzustellen, wie aus vielen, relativ einfachen Daten, komplexere Informationen gewonnen werden können.
Des Weiteren ist es möglich festzulegen, wie zwei unterschiedliche Ontologien aufeinander abzubilden sind, was den Informationsaustausch zwischen Anwendungen,
die sich unterschiedlicher Ontologien bedienen, erheblich vereinfacht. Auch stehen
Reasoner zur Verfügung, die unter anderem den Zugriff auf implizites Wissen und
die Überprüfung der Widerspruchsfreiheit ermöglichen.
Ontologien bieten also die Möglichkeit, die große Anzahl von Sensorinformationen in einem Fahrzeug zu beschreiben und zu organisieren. Außerdem erlauben
sie es, dass Anwendungsprogramme auf diese Informationen zugreifen und auch
komplexere Schlüsse aus der Kombination von relativ einfachen Informationen wie
zum Beispiel der Temperatur oder der Luftfeuchtigkeit schließen.
Dank der Möglichkeit die semantische Gleichheit von unterschiedlichen Begriffen
zu definieren, ist es auch leichter mit Daten von unterschiedlichen Herstellern zu
arbeiten.
Somit bietet die steigende Anzahl und Qualität von Sensoren in Fahrzeugen,
verbunden mit der Vernetzung der Verkehrsteilnehmer, interessante Möglichkeiten
zur Entwicklung von unterstützenden Anwendungen, die sich der Technik der Modellierung der zur Verfügung stehenden Informationen in Ontologien bedienen.
Besonders interessant erscheinen die Möglichkeiten für Anwendungen zur Kollisionsvermeidung bei Fahrzeugen, die sich hier ergeben.
Zuerst lässt sich sagen, dass das Sicherheitsbewusstsein den Straßenverkehr betreffend in den letzten Jahren gestiegen ist. So hat die Schwedische Regierung
zum Beispiel 1997 beschlossen, bis 2015 alle Straßen so sicher zu gestalten, dass
es zu keinen Verkehrstoten mehr kommt1 und auch die Europäische Union hat
mit eSafety2 ein Projekt zur drastischen Reduzierung der Verkehrstoten ins Leben
gerufen. Verbesserungen an den Fahrzeugen haben allgemein zu einer erheblichen
Reduktion der Anzahl von Verkehrstoten geführt.
Allerdings führen viele Verbesserungen an Fahrzeugen nur zu leichteren Verletzungen im Falle eines Unfalls, helfen aber kaum Unfälle wirklich zu vermeiden.
Verbesserte Kollisionsvermeidung bei Fahrzeugen könnte die Anzahl von Unfällen
reduzieren und somit auch die Zahl von Toten und Verletzten im Strassenverkehr.
Eine elektronische Unterstützung des Fahrers kann bei der Unfallvermeidung helfen. Der Mensch hat zum Beispiel eine relativ lange Reaktionszeit, ein Computer
kann auf plötzlich auftretende Gefahrensituationen, so er sie erkennt, schneller reagieren. Auch schätzen Fahrer Situationen oft falsch ein oder übersehen Fahrzeuge,
1
2
http://www.vv.se
http://ec.europa.eu/information society/activities/esafety/index en.htm
8
entweder aus Unkonzentriertheit, oder weil die Sichtverhältnisse schlecht sind. Hier
kann der Computer zusätzliche Informationen zur Verfügung stellen beziehungsweise den Fahrer vor schwer sichtbaren Fahrzeugen warnen.
Vielfältige Sensordaten, Vernetzung der Fahrzeuge und Organisation von Informationen in einem ontologischen Kontextmodell sollten die Entwicklung einer
solchen elektronischen Fahrerunterstützung vereinfachen.
Es ist zu erwarten, dass mit den Informationen, die durch die Fahrzeugsensoren
und die Vernetzung der Fahrzeuge gewonnen werden, sich die Situation, in der sich
das Fahrzeug befindet, mit Hilfe eines ontologischen Kontextmodells genauer beschreiben lässt als ohne diese Kontextinformationen. Somit ist es für Anwendungen
möglich, die Umgebung und die allgemeine Situation besser zu berücksichtigen. Besonders bei der Unfallvermeidung ist dies wichtig, da hier meist mehrere Fahrzeuge
involviert sind.
Andere Möglichkeiten der Modellierung sind zwar ebenfalls denkbar, bieten aber
nicht dieselben Vorteile wie ein ontologisches Kontextmodell. Einen Überblick über
diese Alternativen findet sich in Abschnitt 2.4.7.
Wenn die Sensorinformationen in Fahrzeugen in Ontologien organisiert sind, sollte es also möglich sein, bessere Ergebnisse bei Anwendungen zur Kollisionsvermeidung zu erzielen, als bei Systemen, die den Kontext nicht oder nur kaum beachten.
Eine einfache Abstandsmessung zum vorderen Fahrzeug sollte wesentlich schlechtere Ergebnisse liefern als wenn man zusätzlich die unterschiedlichen Geschwindigkeiten, Beschleunigungen beziehungsweise Bremsbeschleunigungen und die Richtungen der Fahrzeuge in die Berechnungen miteinbezieht. Zusätzliche Kenntnis
über Straßenbedingungen und Straßenverlauf sollte zu einer noch besseren Vorhersage führen.
1.2 Aufgabenstellung
Ziel dieser Arbeit ist es also eine Anwendung zur Kollisionsvermeidung für Fahrzeuge zu entwickeln und sich dabei der ontologischen Kontextmodellierung als
Werkzeug zur Kontexterfassung zu bedienen. Es ist zu untersuchen in wieweit
die Erwartungen, die man an das ontologische Modell stellt, erfüllt werden, oder
allgemein ob ontologische Kontextmodellierung bei Anwendungen zur Kollisionsvermeidung Sinn macht.
1.3 Begriffserläuterungen
In diesem Abschnitt werden ein paar zentrale Begriffe, die für diese Arbeit von
Bedeutung sind, geklärt.
9
Modell
Eine allgemeine Definition des Begriffs Modell findet sich in [mey07a]:
“1) allgemein: Vorbild, Muster, Entwurf von Gegenständen, auch gedankliche Konstruktionen”
Ebenfalls aus [mey07a] entnommen ist folgende Definition des Begriffs Modell für
den Bereich von Naturwissenschaften und Technik:
“4) Naturwissenschaften, Technik: materielles Objekt oder theoretisches Konstrukt,
das einem Untersuchungsgegenstand in bestimmten Eigenschaften oder Relationen
entspricht...”
In dieser Arbeit bezieht sich der Begriff Modell natürlich auf ein theoretisches
Konstrukt. Nach [Sta73] hat ein Modell drei wesentliche Merkmale:
1. Das Abbildungsmerkmal besagt, dass Modelle stets Abbildungen eines
Originals sind. Dies kann auch wiederum ein Modell sein.
2. Das Verkürzungsmerkmal beschreibt die Tatsache, dass Modelle nicht alle Aspekte des zu modellierenden Originals wiedergeben. Der Erschaffer des
Modells beschränkt sich auf die ihm wichtig erscheinenden Aspekte des Originals.
3. Das pragmatische Merkmal besagt, dass Modelle eine Ersetzungsfunktion
erfüllen. Sie werden für bestimmte Benutzer erstellt, haben einen Zweck und
erfüllen ihre Ersetzungsfunktion nur eine Zeit lang.
Ein Modell bildet also immer nur die Wirklichkeit teilweise ab, da der Erschaffer
des Modells nur jene Aspekte in dem Modell erfasst, die ihm für den Zweck des
Modells wichtig erscheinen.
Kontext
Ebenfalls zu klären ist die Bedeutung des Begriffs Kontext. [AD99] definiert Kontext für das “context-aware computing field”, also den Bereich der kontextsensitiven
EDV, folgendermaßen:
“Context is any information that can be used to characterize the situation of an
entity. An entity is a person, place, or object that is considered relevant to the
interaction between a user and an application, including the user and applications
themselves.”
Kontext ist also jede Art von Information, die zur Beschreibung der Situation einer
Entität verwendet werden kann. Eine Entität kann entweder ein Ort, eine Person
oder ein Objekt sein, das für die Interaktion von Benutzer und Anwendung von
Interesse ist. Benutzer und Anwendung können ebenfalls Entitäten sein.
Situation
Im Zusammenhang mit dem Begriff des Kontexts sollte auch der Begriff der Situation geklärt werden. Eine Definition von Situation findet sich in [MH69]:
“A situation s is the complete state of the universe at an instant of time.”
10
Eine Situation ist also der Zustand des Universiums zu einer bestimmten Zeit.
Eine vollständige Erfassung der Situation ist nach dieser Definition nicht möglich,
es können immer nur bestimmte Fakten über eine Situation angegeben werde. Im
Gegensatz zum Kontext sagt die Situation nichts über die Relevanz der einzelnen
Aspekte für die Lage eines bestimmten Objekts aus und beschränkt sich auf einen
bestimmten Zeitpunkt.
Ontologie
Der Begriff der Ontologie kommt ursprünglich aus der Philosophie. Die Ontologie
ist die “philosophische Disziplin, die nach der grundlegenden Struktur des Seienden und der Wirklichkeit fragt” [mey07b]. In der Informatik versteht man unter
dem Begriff Ontologie nicht mehr die Lehre vom Sein, sondern eine “explicit specification of a conceptualization.” [Gru93]. Es gibt hier nicht die eine Ontologie
als wissenschaftliche Disziplin, sondern viele unterschiedliche Ontologien. Die oben
zitierte Definition von [Gru93] wurde später von [SBF98] verfeinert:
“An ontology is a formal, explicit specification of a shared conceptualization.”
Eine conceptualization ist ein abstraktes Modell eines Aspektes der Welt. Es besteht aus Definitionen von für diesen Aspekt wichtigen Konzepten, deren Eigenschaften und Beziehungen. Shared bedeutet, dass das modellierte Wissen allgemein
akzeptiert ist, also nicht die Sicht eines einzelnen auf die Welt darstellt. Die Forderung nach einer formal, explicit specification ist so zu verstehen, dass die Ontologie
in einer eindeutigen Sprache formalisiert werden muss, so dass sie nicht nur für
Menschen, sondern auch für Maschinen interpretierbar ist [SBF98, SS04].
Beschreibungslogik
Nach [SS04] sind Beschreibungslogiken (englisch Description Logics) “a family of
knowledge representation languages that can be used to represent knowledge of an
application domain in a structured and formally well-understood way.” Es handelt
sich also um Sprachen zur Wissensrepräsentation, mit deren Hilfe es möglich ist,
das Wissen um ein Gebiet strukturiert und formal darzustellen.
Die meisten Beschreibungslogiken sind Untermengen der Prädikatenlogik erster
Stufe, ihre Semantik ist formal und basiert auf Logik. Wichtige Aspekte des zu
modellierenden Gebiets werden durch abstrakte Konzepte beschrieben. Diese Konzepte werden aus einstelligen und zweistelligen Prädikaten, sogenannten atomaren
Konzepten und Rollen, konstruiert. Welche Konstruktoren, wie zum Beispiel das
logische Und oder die Negation, zur Verknüpfung von atomaren Konzepten und
Rollen zugelassen sind, hängt von der jeweiligen Beschreibungslogik ab.
Fast alle Beschreibungslogiken unterscheiden zwischen der sogenannten TBox
und der ABox [Baa03]. Die TBox besteht aus den Definitionen der Konzepte, also
den terminological axioms, die ABox aus den dazugehörigen konkreten Instanzen,
genannt assertions. Um die Widerspruchsfreiheit von TBox und ABox zeigen, und
auf das in ihnen enthaltene implizite Wissen zugreifen zu können, gehören zu
Beschreibungslogiken auch entsprechende Algorithmen, die dies ermöglichen.
11
Reasoner
Ein Reasoner ist ein solches Ableitungssystem für Beschreibungslogiken. Die ersten Systeme für Beschreibungslogiken bedienten sich sogenannter structural subsumption algorithms, moderne Systeme der tableau-based algorithms oder einer
Transformation in Modallogik [SS04, Baa03].
Mit Hilfe eines Reasoner ist es möglich eine Hierarchie von Konzepten einer Beschreibungslogik zu erstellen. Auch die Widerspruchsfreiheit von Konzepten und
Instanzen kann der Reasoner automatisch überprüfen. Ebenso ist es möglich Instanzen automatisch einem Konzept zuzuordnen. Beispiele für Reasoner sind RACER [HM01] und FaCT [Ian98].
OWL
In [SWM04] findet sich folgende Beschreibung von OWL: “The OWL Web Ontologoy Language is a language for defining and instantiating Web ontologies”. OWL
ist also eine Sprache zur Beschreibung von Ontologien, und speziell für den Einsatz im Internet konzipiert. Die Spezifikation wurde von der W3C Web Ontology
Working Group entwickelt und hat den Status einer W3C recommendation. In
Abschnitt 2.4.2 werden OWL und seine drei Versionen genauer beschrieben.
Semantic Web
Mit dem Semantic Web bezeichnet man eine mögliche Weiterentwicklung des jetzigen Internets. Während das Internet so, wie es zur Zeit existiert, seine Informationen hauptsächlich dem menschlichen Benutzer präsentiert, soll das Semantic
Web auch maschineninterpretierbare Informationen enthalten. Im Semantic Web
werden alle Dokumente mit Metainformationen, die ihren Inhalt beschreiben, erweitert. Diese Metainformationen können in Ontologien organisiert werden und
müssen maschinenlesbar sein. Somit können Programme unter anderem auf die
Informationen in den Dokumenten zugreifen und diese weiterverarbeiten. Das Ziel
des Semantic Web ist es, das menschliche Wissen, das zum Beispiel im Internet
enthalten ist, maschineninterpretierbarer zu machen und somit den Einsatz von
allerlei Anwendungen zu ermöglichen, die sich dieses Wissens bedienen [DFv03].
1.4 Aufbau der Arbeit
Am Anfang dieses ersten Kapitels wurden die Idee und Motivation dieser Arbeit
erläutert. Im zweiten und dritten Abschnitt wurde sowohl auf die Aufgabenstellung
eingegangen als auch ein paar wichtige Begriffe, die für das Verständnis der Arbeit
wichtig sind, geklärt.
Im zweiten Kapitel wird zuerst die Aufgabenstellung nochmals genauer erläutert.
Dann werden die Anforderungen an die zu entwickelnde Anwendung untersucht
und ihre Architektur vorgestellt. Die Wahl der verwendeten Sprachen, Frameworks
und Programme wird ebenso begründet wie mögliche Alternativen zu diesen analysiert werden. Außerdem wird noch auf die Erwartungen, die sich an den Einsatz
12
eines ontologischen Kontextmodells knüpfen, eingegangen.
Das zweite Kapitel beinhaltet eine ausführliche Beschreibung der ersten Version
der entwickelten Anwendung zur Kollisionsvermeidung. Hier wird besonders auf
die Ontologie und die Kollisionsberechnung eingegangen. Eine Beschreibung der
wichtigsten Java-Klassen der Anwendung findet sich in diesem Kapitel ebenso wie
eine Diskussion von Ergebnissen und Erweiterungsmöglichkeiten.
Im vierten Kapitel wird die zweite Version der entwickelten Anwendung vorgestellt. Der Schwerpunkt liegt hier auf den zwei neuen Ontologien und den Abweichungen von der ersten Version.
Die Unterschiede zwischen beiden Anwendungen werden im fünften Kapitel analysiert. Auch weitere Einsatzmöglichkeiten für die entwickelten Ontologien werden
hier genannt, ebenso wie mögliche Verallgemeinerungen, Anpassungsfähigkeit und
Grenzen der Ontologien.
Im sechsten Kapitel wird schließlich untersucht, inwieweit die Erwartungen an
den Einsatz eines ontologischen Kontextmodells erfüllt werden. Auch die grundsätzliche Eignung des Ansatzes sich eines ontologischen Kontextmodells für eine
Anwendung zur Kollisionsvermeidung bei Fahrzeugen zu bedienen, wird hier untersucht. Am Ende des Kapitels steht ein kurzer Ausblick.
13
2 Architektur
In diesem Kapitel wird allgemein die Architektur der zu entwickelnden Anwendung beschrieben. Zuerst wird die Aufgabenstellung genauer betrachtet, dann die
sich daraus ergebenden Anforderungen und der logische Aufbau der Anwendung.
Ebenso werden die Entscheidungen bezüglich der verwendeten Sprachen und Frameworks erläutert und zum Schluss des Kapitels werden noch mögliche Alternativen erwähnt.
2.1 Aufgabenstellung und Szenarien
In dieser Arbeit soll eine Anwendung zur Kollisionsvermeidung bei Fahrzeugen
entwickelt werden, die sich eines ontologischen Kontextmodells bedient.
Wichtig ist es zu erwähnen, dass Kollisionsvermeidung das Ziel der Anwendung
ist und sie somit klar von einem Autopiloten zu unterscheiden ist. Die Anwendung
soll nicht wie ein Autopilot dazu in der Lage sein, ein Fahrzeug autonom ohne
menschliches Eingreifen im Straßenverkehr zu steuern, sondern Funktionen zur
Kollisionsvermeidung bereitstellen. Sie dient also der Unterstützung eines menschlichen Fahrers. Diese Unterstützung geschieht durch die Gewinnung von Informationen, auf die entweder Fahrer oder auch das Fahrzeug reagieren können. Es
handelt sich also um einen Fahrerassistenten und nicht um einen Piloten.
In dieser Diplomarbeit werden zwei Ausführungen eines solchen Fahrerassistenten zur Kollisionsvermeidung erstellt. Beide Ausführungen bauen auf folgenden
Prämissen auf:
1. Alle Fahrzeuge können ihre Position und Richtung exakt bestimmen.
2. Die Fahrzeuge sind teil eines VANets und senden ihre Positions- und Geschwindigkeitsdaten regelmäßig an die anderen Verkehrsteilnehmer, die sich
in Reichweite ihrer Sender befinden.
Die beiden Varianten des Fahrerassistenten unterscheiden sich durch den Umfang
an Kontextinformationen, die in die Berechnungen zur Unfallvorhersage mit einfließen.
Erste Variante des Fahrerassistenten
In der ersten Variante des Fahrerassistenten werden relativ wenige Informationen über die Fahrzeuge und vor allem die restliche Umgebung verwendet. Sie beschränkt sich auf die aktuellen Positionswerte, die Richtung, die Geschwindigkeit,
14
die Beschleunigung und die Bremsbeschleunigung der Fahrzeuge. Natürlich müssen
auch die Maße der einzelnen Fahrzeuge bekannt sein. Informationen zum Streckenverlauf, Vorfahrtsregeln, Geschwindigkeitsbeschränkungen, Straßenverhältnisse usw
stehen nicht zur Verfügung.
Das Interessante an diesem Szenario ist es herauszufinden, welche Ergebnisse
sich mit diesen wenigen Daten erzielen lassen. Erstens soll untersucht werden, ob
man Unfälle korrekt vorhersagen kann und welche Arten von Fehleinschätzungen
auftreten. So könnten entweder mögliche Gefahren nicht erkannt werden, oder es
werden harmlose Situationen als gefährlich eingestuft. Zweitens ist zu beachten,
wie effizient eine Ontologie in diese Anwendung integriert werden kann, beziehungsweise ob der Einsatz eines ontologischen Modells hier überhaupt Sinn macht. Es
soll ermittelt werden, ob der Aufwand eine Ontologie in die Anwendung einzubinden gerechtfertigt ist und inwieweit zum Beispiel Zugriffe auf die Ontologie den
Fahrerassistenten verlangsamen.
Zweite Variante des Fahrerassistenten
In der zweiten Variante des Fahrerassistenten werden dem Programm mehr Kontextinformationen zur Verfügung gestellt. Bis jetzt beruhen die Berechnungen nur
auf fahrzeugbezogenen Daten, in dieser Variante kommen Informationen zum Straßennetz und zu allgemeinen Umweltbedingungen dazu.
Fahrzeuge erfassen zum Beispiel Informationen zur Helligkeit, und die Reaktionen des Assistenten werden den errechneten Sichtverhältnissen angepasst. Der
wesentliche Unterschied zum ersten Szenario ist aber die Modellierung des Straßennetzes. Jedes Fahrzeug kennt die Topographie des Straßennetzes. Um diese Informationen nutzen zu können, werden die reinen Fahrzeugdaten mit Daten zum
Straßennetz erweitert, das heißt die Fahrzeuge wissen sowohl auf welchem Straßenabschnitt sie sich befinden, als auch auf welchen Straßenabschnitten die restlichen
Verkehrsteilnehmer sind.
Ziel dieses Szenarios ist es zu untersuchen, ob und inwieweit sich mögliche
Mängel bezüglich der Unfallvorhersage der ersten Version des Assistenten durch
zusätzliche Kontextinformationen beheben lassen. Ebenso soll herausgefunden werden, wie aufwendig es ist das Kontextmodell, und somit die Ontologie des ersten
Szenarios, mit den zusätzlichen Konzepten, also Umweltbedingungen und Straßennetz, zu erweitern beziehungsweise die alte Ontologie mit neuen Ontologien zu
verknüpfen, die diese Konzepte modellieren. Auch der Einfluss des komplexeren
Modells auf die Performance des Assistenten ist bei der Bewertung dieses Szenarios
zu beachten.
15
2.2 Anforderung an Anwendungen und Architektur
Vor der Beschreibung des logischen Aufbaus des Fahrerassistenten sind zuerst die
Anforderungen an das Programm und die dazugehörende Architektur genauer zu
analysieren.
Situation
Die Anwendung soll in einer Situation eingesetzt werden, die sich in vielen Aspekten ständig ändert. Sowohl das eigene als auch die anderen Fahrzeuge ändern
laufend ihre Position, bremsen ab und beschleunigen und ändern dadurch ihre
Geschwindigkeit. Auch die Fahrtrichtung ist nicht konstant. Es ist sehr schwer
vorherzusagen wohin sich ein Fahrzeug bewegt, ob es an einer Kreuzung abbiegt,
ob die Spur gewechselt wird, ob es plötzlich abbremst oder mit konstanter Geschwindigkeit weiterfährt. Somit folgen die fahrzeugbezogenen Daten keinem Muster, auf das man sich verlassen kann. Auch wenn alle bisherigen Fahrzeuge an
einer Kreuzung geradeaus gefahren sind, heißt das noch lange nicht, dass es auch
alle nachfolgenden tun werden.
Anders sieht es bei den Umweltbedingungen aus. Temperaturschwankungen sind
meist nicht sehr plötzlich, Helligkeitsänderungen dagegen schon, zum Beispiel bei
der Einfahrt in einen Tunnel.
Das Straßennetz an sich ändert sich nur sehr langsam, Eingriffe in die Streckenführung kommen nur sehr selten vor. Probleme könnten temporäre Änderungen
zum Beispiel an Baustellen ergeben. Anders sieht es bei Vorfahrtsregeln aus, hier
müssten vor allem Ampeln beachtet werden.
Anforderungen
Aus dieser Situation ergeben sich mehrere Anforderungen an den Fahrerassistenten. Um sinnvolle Berechnungen durchführen zu können, benötigt man ständig die
aktuellen Daten aller Verkehrsteilnehmer. Aus veralteten Daten könnte man zwar
die neue Position abschätzen, dies ist aber sehr ungenau.
Auch die Sensordaten, die die Umweltbedingungen erfassen, sollten stets aktuell
sein. Änderungen der Sichtverhältnisse lassen sich ebenfalls nicht so leicht voraussagen. Allerdings ist der Einfluss auf die Qualität des Ergebnisses hier nicht so
dramatisch wie der einer falsch berechneten Fahrzeugposition.
Das Straßennetz dagegen muss nur sehr selten auf den neuesten Stand gebracht
werden. Der Straßenverlauf ändert sich quasi nicht, somit kann das Einlesen des
Straßennetzes länger dauern als die Aktualisierung von Fahrzeug und Sensordaten.
Vorfahrtsregeln dagegen müssten öfters überprüft werden, denn auch hier kann eine
falsche Schlussfolgerung fatale Folgen haben.
Wie sich diese von den Anforderungen an die Fahrzeugdaten unterschiedlichen
Forderungen an die Aktualität der Umwelt- und Straßendaten auf die Ontologien
zur Modellierung des Straßennetzes und der Umweltbedingungen auswirken, wird
in Abschnitt 4.2 und 4.3 genauer erläutert.
16
Zu beachten ist außerdem, dass Unfallvermeidung eine sicherheitskritische Anwendung ist. Somit müssen alle Berechnungen in Echtzeit durchgeführt werden
können. Fehler bei den Berechnungen sollten ebenfalls vermieden werden. Verspätete korrekte oder rechtzeitige falsche Ergebnisse können fatale Folgen haben,
wenn eine Gefahrensituation übersehen wird und es zum Unfall kommt. Problematisch ist hier, dass die Sensordaten immer mit Unsicherheit behaftet sind. Die
Messung der Position kann zum Beispiel nicht beliebig genau erfolgen und Messinstrumente können komplett ausfallen oder falsche Werte liefern. Nach [BK01]
können solche Unsicherheiten durch Erweiterung der zur Modellierung verwendeten Logik um Werte wie “notwendig” und “möglich” ausgedrückt werden. Diesen
Ansatz verfolgt zum Beispiel die Modallogik. Auch wahrscheinlichkeitstheoretische
Ansätze oder das Arbeiten mit unscharfen Mengen ist möglich [BK01]. In dieser
Arbeit wird aber nicht auf die Problematik unsicherer Daten eingegangen, der
Einfachheit halber wird angenommen, dass alle Daten korrekt und präzise sind.
Weitere Anforderungen an Architektur und Anwendung ergeben sich aus dem
Einsatzbereich. Da es im Straßenverkehr sehr viele verschiedene Fahrzeugtypen,
die von unterschiedlichen Herstellern produziert werden, gibt, ist ein hohes Abstraktionslevel der Anwendung von Vorteil. Eine abstrakte Anwendung, die nicht
auf einen Fahrzeugtyp abgestimmt ist, kann bei mehr Verkehrsteilnehmern zum
Einsatz kommen.
Von Vorteil wäre es auch, wenn es möglich wäre herstellerspezifische Daten zu
integrieren. Wenn also ein Hersteller Daten zu seinen Fahrzeugen in einer Ontologie
beschreibt, sollte es möglich sein, diese Daten in die Ontologie des Fahrerassistenten zu integrieren.
Als letzte Anforderung wäre die Ausbaufähigkeit um zusätzliche Kontextinformationen für andere Anwendungen zu erwähnen. Der Vorteil eines ontologischen
Kontextmodells ist seine Wiederverwertbarkeit für neue Anwendungen und seine
Erweiterbarkeit mit neuen Konzepten. Dies sollte bei den Ontologien des Fahrerassistenten ebenfalls gegeben sein.
2.3 Aufbau
Nach der Analyse der Voraussetzungen und Anforderungen wird in diesem Abschnitt der logische Aufbau des Assistenten erläutert. Der Aufbau unterscheidet
sich nicht für beide Szenarien, sie bestehen aus den selben logischen Komponenten.
Die Unterschiede zwischen beiden Anwendungen werden später in Kapitel 3 und
Kapitel 4 aufgezeigt.
2.3.1 Überblick über die logischen Komponenten
In Abbildung 2.1 wird ein Überblick über die einzelnen logischen Komponenten
gegeben. Dies sind im Einzelnen:
17
Abbildung 2.1: Die logischen Programmkomponenten
1. Der Simulator stellt die Inputdaten zur Verfügung, also zum Beispiel die Position und Geschwindigkeit aller Verkehrsteilnehmer und Daten zum Straßennetz, wenn die Anwendung diese benötigt. Außerdem reagiert der Simulator
auf den Output, das heißt Fahrzeuge werden gegebenenfalls abgebremst.
2. Mit Assistent wird in der Abbildung das Hauptprogramm des Fahrerassistenten bezeichnet. Es ist für die Koordination der einzelnen Anwendungskomponenten zuständig.
3. Über die Ein- und Ausgabe liest der Assistent die Daten der anderen
Fahrzeuge und die eigenen Sensordaten ein, leitet die Kontrollsignale weiter
und verschickt die Outputmessages mit den eigenen Fahrzeugdaten. Somit
stellt sie auch die Verbindung zum Netzwerk her.
4. Die Ontologie ist mit einem Reasoner verknüpft. Sie enthält das Kontextmodell in dem Fahrzeuge und gegebenenfalls auch Umweltsensoren und Straßennetz beschrieben sind. Die Ontologie wird regelmäßig mit neuen Daten
instanziiert und es können Anfragen an sie gestellt werden. Der Reasoner
leitet neue Fakten aus Modell und Daten ab.
5. Die eigentliche Anwendung stellt Anfragen an die Ontologie, wertet die
Daten aus und erstellt Kontrollkommandos, um die Reaktion auf die vorgefundene Situation zu steuern.
6. Die Kontrolleinheit im Fahrzeug reagiert auf die von der Anwendung erzeugten Signale, in dem sie zum Beispiel das Fahrzeug abbremst oder den
Fahrer warnt.
18
In den nächsten Abschnitten werden die Funktionen der einzelnen Komponenten
genauer erläutert.
2.3.2 Verkehrssimulator
Der Verkehrssimulator muss sowohl das eigene Fahrzeug und das Verhalten des
Fahrers, als auch die anderen Verkehrsteilnehmer in einem Straßennetz simulieren. Die durch die Verkehrssimulation erzeugten Daten bezüglich der Fahrzeuge
des Straßennetzes werden dem Assistenten als Inputdaten zur Verfügung gestellt.
Ebenso muss es möglich sein, den Simulator über die Anwendung zu steuern. Nur
so können die vom Fahrerassistenten errechneten Steuersignale auch umgesetzt
werden. Es ist also eine Schnittstelle zwischen Verkehrssimulator und Anwendung
nötig. Falls es in dem ausgewählten Verkehrssimulator nicht möglich ist die einzelnen Fahrzeuge direkt anzusprechen und zu steuern, muss der Simulator modifiziert
und an die Bedürfnisse des Fahrerassistenten angepasst werden.
Des Weiteren ermöglicht der Simulator auch eine Visualisierung der Anwendung.
Mit Hilfe des Simulators ist es möglich, die Reaktionen der einzelnen Fahrzeuge
auf die unterschiedlichen Verkehrssituationen zu veranschaulichen.
Ebenso hilfreich ist ein Verkehrssimulator zum Testen des Assistenten. Er stellt
einigermaßen realistische Verkehrsdaten zur Verfügung und erlaubt es, Mängel und
Fehlfunktionen des Assistenten zu finden. Auch der Einfluss des Assistenten auf
den Verkehrsfluss lässt sich mit dem Simulator untersuchen.
2.3.3 Hauptprogramm
Das Hauptprogramm des Assistenten koordiniert seine einzelnen Komponenten. Es
wird vom Fahrzeug, hier also vom Simulator, aus aufgerufen und mit Inputdaten
über eine spezielle Schnittstelle, die Ein- und Ausgabe, versorgt. Über dieselbe
Schnittstelle versendet es seine Outputmessages und die Kontrollsignale für die
Kontrolleinheit.
2.3.4 Ein- und Ausgabe
Die Ein- und Ausgabe dient als Schnittstelle zwischen dem Fahrzeugassistenten
und dem restlichen System. Über sie kommuniziert der Assistent mit dem Simulator und der Kontrolleinheit. Die Ein- und Ausgabe leitet die benötigten Sensordaten des Fahrzeugs vom Simulator an den Assistenten weiter, ebenso die Positionsund Geschwindigkeitsdaten der anderen Fahrzeuge. Der Assistent schreibt in umgekehrter Richtung seine zu verschickenden Outputmessages und die Steuerbefehle
in die Ein- und Ausgabe, von wo sie vom Simulator beziehungsweise der Kontrolleinheit im Fahrzeug ausgelesen und ausgewertet werden.
Somit ist der Assistent selber unabhängig vom verwendeten Simulator. Er sieht
nur die Ein- und Ausgabe und kommuniziert indirekt mit dem Simulator.
19
2.3.5 Ontologie und Reasoner
Die Ontologie beschreibt das abstrakte Modell des Kontextes, also je nach Szenario
entweder nur das der Fahrzeuge, oder auch der Umwelt und des Straßennetzes. Das
Modell ist in einer OWL1 -Datei beschrieben. Zum Erstellen einer solchen Datei ist
ein Editor sehr hilfreich (siehe Abschnitt 2.4.3).
Wenn die Ontologie auf andere Modelle zurückgreift, also zum Beispiel die Fahrzeugontologie um ein Modell des Straßennetzes erweitert wird, dann werden diese
Modelle, die ebenfalls in OWL-Dateien vorliegen müssen, geladen und in das ursprüngliche Modell importiert.
In der Ontologie wird aber nicht nur das abstrakte Modell selbst gespeichert,
sondern auch die aktuellen Fahrzeug-, Umwelt- und Straßendaten. Das Modell
wird also regelmäßig instanziiert.
Des Weiteren ist die Ontologie mit einem Reasoner verknüpft. Der Reasoner
muss natürlich die Sprache, in der die Ontologie beschrieben ist, verstehen, in diesem Fall also OWL, um die Sprachkonstrukte richtig zu interpretieren. Er leitet
aus dem Modell weitere Fakten ab, und zwar sowohl aus der Beschreibung des
Modells, als auch aus den Instanzen. So kann man zum Beispiel aus der transitiven Eigenschaft erreichbar schließen, dass wenn Straße B von Straße A aus
erreichbar ist, und Straße C von Straße B, auch Straße C von A erreichbar ist.
Weitere Möglichkeiten sind unter anderem die Klassifizierung von Instanzen und
das Überprüfen der Widerspruchsfreiheit von Datensatz oder Modell.
Von Vorteil ist es, wenn man den Reasoner mit eigenen Regeln erweitern kann.
So wäre es denkbar, eine Regel aufzustellen, dass wenn eine Straße nur eine Spur
hat und auf dieser Spur der Verkehr nur in eine Richtung erlaubt ist, die Straße
eine Einbahnstraße ist.
Das mit Daten instanziierte Modell beziehungsweise die Ontologie dienen der
eigentlichen Anwendung nun als “Datenbank”. Die Anwendung kann Anfragen an
die Ontologie stellen, also zum Beispiel gib mir alle Fahrzeuge vom Typ PKW oder
alle Fahrzeuge, die sich auf derselben Fahrbahn befinden und sich nicht bewegen.
In beiden Szenarien gibt es nicht nur eine Ontologie, sondern mehrere. So ist es
sinnvoll, die Sensordaten, wie zum Beispiel Temperatur und anderen Umweltfaktoren, von den Fahrzeugdaten getrennt zu halten. Ebenso werden die vom Reasoner
abgeleiteten Daten in eigenen Ontologien abgespeichert. Der Grund hierfür ist es,
dass kleinere, weniger komplexe und mit einer geringeren Anzahl von Instanzen
versehene Ontologien schneller auf Anfragen antworten können. Ebenso ist es leichter, komplett neue Ontologien mit einem Reasoner abzuleiten als das abgeleitete
Modell zu verändern, wenn quasi alle Daten sich laufend ändern, wie das in der
Fahrzeugontologie der Fall ist.
Mit jeder Ontologie kann ein eigener Reasoner verknüpft werden, der auf diese
Ontologie abgestimmt ist. Ebenso kann jeder Reasoner mit seinem eigenen Re1
http://www.w3.org/TR/owl-features/
20
gelsatz erweitert werden. Auch dies führt zu reduzierten und somit optimierten
Regelsätzen, die die Geschwindigkeit der Anfragen und des Reasoners erhöhen
können.
2.3.6 Anwendung
Die Anwendung führt die eigentlichen Berechnungen zur Kollisionsvermeidung
durch. Sie wird vom Hauptprogramm des Assistenten gestartet. Die nötigen Daten
für die Berechnungen erhält sie aus der Ontologie, an die sie Anfragen richtet. Das
Ergebnis dieser Anfragen wird ausgewertet und führt zu einer Abschätzung der Gefahrensituation. In beiden Szenarien wird der nächste Zeitpunkt einer möglichen
Kollision berechnet. Aus diesem Zeitpunkt wird ein Gefahrenlevel abgeleitet. Anhand des Gefahrenlevels werden die Signale erzeugt, mit denen die Kontrolleinheit
gesteuert wird. Die Signale werden über das Hauptprogramm an die Ein- und
Ausgabeeinheit weitergeleitet. Sowohl im ersten als auch im zweiten Szenario finden sich zwei Versionen dieser Anwendung, die beide vom Assistenten aufgerufen
werden. Eine berechnet, ob es zu einem Unfall kommt, wenn alle Fahrzeugdaten konstant bleiben, die andere überprüft bei niedrigen Geschwindigkeiten, ob es
möglich ist, zu beschleunigen ohne einen Unfall zu provozieren. Die Einführung
einer solchen zweiten Anwendung wird in Abschnitt 3.5.10 und 3.6.1 motiviert.
2.3.7 Auswertung der Kontrollsignale
Die letzte der logischen Komponenten ist die Einheit zur Reaktion auf die vom
Assistenten erzeugten Kontrollsignale. Sie empfängt ihre Daten über die Ein- und
Ausgabeeinheit, das heißt sie wertet die Kontrollsignale des Assistenten aus und
leitet aus ihnen die nötige Reaktion ab. Verschiedene Reaktionen sind möglich,
unter anderem kann die Kontrolleinheit gegebenenfalls in die Fahrzeugsteuerung
des Verkehrssimulators eingreifen.
Die auf eine erkannte Gefahr hin verschiedenen möglichen Reaktionen kann man
nach [DSK05] in vier Kategorien einteilen:
1. Autonomous: Das Fahrzeug reagiert selbstständig, ohne dass der Fahrer die
Kontrolle über die Reaktion hat.
2. Action: Der Fahrer wird gewarnt und muss sofort handeln um die Gefahr
abzuwenden.
3. Attention: Sicherheitsrelevante Informationen werden angezeigt. Sie erfordern aber keine sofortige Handlung.
4. Awareness: Informationen werden weitergeleitet, die der Fahrer wissen sollte.
21
Es ist also möglich, dem Fahrer entweder mit Hilfe von Warnsignalen auf die
drohende Gefahr aufmerksam zu machen oder direkt in das Fahrzeugverhalten
einzugreifen. Folgende Eingriffe in die Fahrzeugsteuerung sind denkbar:
• Übernahme der Lenkung
• Beschleunigen
• Abbremsen
In beiden Szenarien beschränkt sich die Reaktion auf die dritte Option, also das
Abbremsen. Eingriffe in die Lenkung sind zu kompliziert und Beschleunigen scheint
zu riskant, wenn der Assistent versagt.
Auch bei den Warnsignalen, mit denen der Fahrer auf eine drohende Gefahr
aufmerksam gemacht werden soll, gibt es unterschiedliche Möglichkeiten. Unter
anderem sind folgende Arten von Warnsignalen in einem Fahrzeug denkbar:
• Warnung durch Tonsignale oder Sprache
• Warnung durch Warnleuchten
• Graphische oder textuelle Informationen an einem Bildschirm
In diesem Programm wird die Art der Warnsignale, die erzeugt werden, nicht näher
spezifiziert. Wenn ein Fahrzeug von der Kontrolleinheit ein entsprechendes Signal
erhält, ändert sich je nach Signal seine Farbe auf dem Bildschirm.
Ob ein Fahrzeug abgebremst oder nur gewarnt wird, hängt vom berechneten
Gefahrenlevel ab. Je höher das Gefahrenlevel, desto intensiver die Warnung, also
die Farbe, und ab einem bestimmten Level bremst das Fahrzeug dann ab.
Welche Reaktion angemessen ist, beziehungsweise welches Gefahrenlevel sich
aus einer bestimmten Situation ergibt, ist relativ schwer zu entscheiden. Einerseits
besteht die Gefahr, dass die Unfallgefahr zu hoch eingeschätzt wird, andererseits
sollen möglichst alle Unfälle vermieden werden.
Bei zu häufigen Warnsignalen besteht die Gefahr der Abstumpfung. Die Fahrer
reagieren eventuell nicht mehr, wenn die ständigen Warnungen sich als falsch oder
übertrieben herausstellen. Im schlimmsten Fall schaltet der Fahrer das System
ab oder ignoriert es völlig. Ebenso müssen die Warnungen klar und übersichtlich
sein, da sie sonst nur zur Verwirrung oder Verunsicherung des Fahrers beitragen
[MH02].
Auch Eingriffe in die Fahrzeugsteuerung bergen Gefahren. Die meisten Autofahrer wollen die volle Kontrolle über ihr Fahrzeug behalten und unnötiges Abbremsen
oder gar Eingriffe ins Lenkverhalten können sowohl den Fahrer verärgern als auch
zu Gefahrensituationen führen, wenn der Fahrer versucht gegenzusteuern. Ebenso
können falsche Eingriffe Unfälle provozieren, zum Beispiel ein plötzliches unnötiges
Abbremsen des Fahrzeuges. Auch der Verkehrsfluss wird durch unnötige Eingriffe
gestört, was zu Staus führen könnte.
22
Warnsignale sollten also nicht zu oft produziert werden und nicht zu viele gleichzeitig. Auch Eingriffe in die Fahrzeugsteuerung sollten nur erfolgen, wenn es absolut notwendig ist.
Nicht alle Autofahrer haben denselben Fahrstil, manche fahren aggressiver, andere passiver. Da aggressive Fahrer oft viel später ausweichen als passive, sich diese
Ausweichmanöver aber nicht vorhersehen lassen, ist es schwierig ein System zu
entwickeln, das den Bedürfnissen von aggressiven Fahrern und denen von passiven
Fahrern entspricht. Wenn die aggressiven Fahrer nicht ständig von dem Assistenten
gewarnt oder abgebremst werden sollen, dann können nicht alle Kollisionen vermieden werden, da die Warnung eventuell zu spät erfolgt. Eine Berücksichtigung
des Fahrerverhaltens könnte hier zumindest teilweise Abhilfe schaffen [SSH98].
Es besteht aber immer noch das Problem, dass sich, besonders bei aggressivem
Fahrverhalten, nicht voraussagen lässt, ob der Fahrer rechtzeitig ausweichen wird.
Somit können, wenn die Zahl der Warnungen und Eingriffe nicht zu hoch sein soll,
nicht alle Unfälle verhindert werden.
Aber auch wenn eine Kollision nicht vollständig verhindert werden kann, heißt
das nicht, dass der Fahrerassistent sinnlos ist. Auch eine Reduktion der Geschwindigkeit vor der Kollision kann schon als Teilerfolg gewertet werden. Da die kinetische Energie, die bei einem Unfall wirkt, von der Geschwindigkeit quadratisch
abhängt (Ekin = 12 mv 2 ), führt Abbremsen auf jeden Fall zu weniger schweren
Unfällen und somit zu geringeren Personen- und Sachschäden.
Es ist also nötig genau abzuwägen wie hoch die Gefahr ist und welche Reaktion angemessen ist. Hier liegt ein entscheidender Vorteil des Ansatzes den Fahrerassistenten mit einem ontologischen Kontextmodell auszustatten. Die Einbeziehung weiterer Kontextinformationen, also nicht nur der reinen Fahrzeugdaten,
in die Berechnung des Gefahrenlevels macht es leichter die Gefahren richtig einzuschätzen und entsprechend zu reagieren. So wird zum Beispiel bei schlechten
Sichtverhältnissen das Gefahrenlevel von der Kontrolleinheit entsprechend erhöht,
da anzunehmen ist, dass der Fahrer andere Fahrzeuge vielleicht nicht mehr rechtzeitig sieht. Somit kann der Fahrer bei Dunkelheit oder Nebel früher gewarnt werden oder das Fahrzeug abgebremst werden. Von Vorteil ist es auch, dass es den
verschiedenen Anwendungen überlassen bleibt, wie sie auf den Kontext reagieren.
Dies wird durch die Maschinenlesbarkeit des Modells gewährleistet.
2.4 Verwendete Werkzeuge und Erwartungen an die Ontologie
Im letzten Abschnitt wurde der logische Aufbau des Assistenten und seine Verknüpfung mit einem Verkehrssimulator erläutert, hier werden die Techniken zur
Implementierung, also Werkzeuge wie Sprachen und Frameworks, beschrieben.
Ebenso werden die Entscheidungen für die einzelnen Werkzeuge genauer begründet.
Am Ende des Abschnitts werden die Erwartungen, die mit der Verwendung eines
ontologischen Kontextmodells im Assistenten verbunden sind, erläutert.
23
2.4.1 Visual Traffic Simulation
Nach [KR07] können Verkehrssimulatoren je nach dem Detailgrad der Simulation
in vier verschiedene Gruppen eingeteilt werden:
• Makroskopische Verkehrssimulatoren sind die abstraktesten. Sie verwenden
den Verkehrsfluss als Grundlage für die Simulation.
• Mesoskopische simulieren ein wenig detailliertes Fahrzeugverhalten. Das
Abstraktionslevel liegt zwischen den makroskopischen und den mikroskopischen Verkehrssimulatoren.
• Bei mikroskopischen Simulatoren wird jedes einzelne Fahrzeug simuliert,
das Fahzeugverhalten basiert auf Fahrzeugeigenschaften und Fahrerverhalten.
• Sub-Mikroskopische Simulatoren simulieren zusätzlich die einzelnen Bauteile der Fahrzeuge.
Ein mikroskopischer Verkehrssimulator ist ideal für die Zwecke dieser Arbeit geeignet. Es muss aber möglich sein die einzelnen Fahrzeuge zumindest abzubremsen, um die Reaktionen der Kontrolleinheit zu simulieren. Die Simulation einzelner Bauteile im Fahrzeug, wie sie ein submikroskopischer Simulator ermöglichen
würde, ist dagegen nicht nötig. Meso- und makroskopische Simulatoren sind andererseits zu abstrakt, da sie das Verhalten der einzelnen Fahrzeuge nicht oder nur
sehr ungenau simulieren.
In dieser Arbeit wird der Visual Traffic Simulation - Simulator [Fot02], kurz
VIS SIM, als Verkehrssimulator verwendet. Mögliche Alternativen werden in Abschnitt 2.5.1.1 und 2.5.1.2 beschrieben.
VIS SIM ist ein mikroskopischer Verkehrssimulator. Er erlaubt das Erzeugen
von einfachen und räumlich sehr beschränkten Straßennetzen mit Hilfe eines grafischen Editors. Dies hat den Vorteil, dass es sehr schnell und ohne großen Aufwand möglich ist ein simples Straßennetz zu erstellen. Die Straßennetze können
auch abgespeichert werden. Dass das simulierte Straßennetz nur relativ klein ist,
ist für Tests zur Funktionsweise der Kollisionsvermeidung keine gravierende Einschränkung.
Schwerer wiegt da schon die Tatsache, dass der Simulator nur die Arbeit eines
Studenten ist. Fehler im Simulator sind also keineswegs auszuschließen. Ein wissenschaftlich anerkannter Simulator wie SUMO (siehe Abschnitt 2.5.1.1) würde
hier zuverlässigere Testergebnisse liefern. Die Gründe, die trotzdem gegen eine
Verwendung von SUMO sprechen, werden in Abschnitt 2.5.1.1 erläutert.
Die Unzuverlässigkeit zeigt sich bei Unregelmäßigkeiten bezüglich der Maßeinheiten, also zum Beispiel der Umrechnung von mph in km/h, unrealistisch hohen
Beschleunigungswerten der Fahrzeuge und Fehlern bei der Umrechnung von Pixeln
24
in Meter. Diese Mängel wiegen aber nicht besonders schwer, da unrealistische Beschleunigung, falsche Geschwindigkeiten oder Fehler bei Längeneinheiten nicht die
Funktionsweise des Simulators an sich beeinträchtigen. Realistische Abschätzungen,
wann ein Fahrzeug abbremsen sollte, sind mit diesem Simulator zwar nicht möglich,
aber es ist möglich zu zeigen, ob der Fahrerassistent prinzipiell funktioniert oder
nicht. Die zu beobachtenden Vorteile oder Schwachstellen des Assistenten hängen
nicht von realistischen Fahrzeugmaßen oder korrekten Längeneinheiten ab.
VIS SIM hat wie die meisten Verkehrssimulatoren ein kollisionsfreies Verkehrsmodell, Unfälle treten also im normalen Betrieb nicht auf. Dies lässt sich aber bei
Kreuzungen mit einem einfachen Trick beheben. Da VIS SIM als Kreuzungstyp
auch Brücken zur Verfügung stellt, können Unfälle an Kreuzungen mit Hilfe von
Brücken simuliert werden. Wann immer ein Fahrzeug über die Brücke fährt, ein
anderes sich darunter befindet und sie sich teilweise übereinander befinden, wird
dies als Kollision angesehen. Es ist also sehr einfach möglich, Unfälle zu simulieren,
ohne in den Simulator einzugreifen.
Der Simulation von Unfällen kommt ebenfalls zu gute, dass VIS SIM die Position aller Fahrzeuge mehrmals pro Sekunde, und zwar alle 50 Millisekunden,
neu berechnet. Somit werden, zumindest bei normalen Geschwindigkeiten, keine
Kollisionen übersehen.
Ein weitere Vorteil ist die vorhandene Visualisierung, die zwar einfach, aber funktional ist. Dank dieser Visualisierung und dem schnellen Erzeugen von Straßennetzen ist es schon während des Programmierens ohne großen Aufwand möglich,
Fehler bei der Kollisionsberechnung zu finden.
Außerdem steht der Quellcode für VIS SIM zur Verfügung, es ist also möglich
nötige Anpassungen an dem Programm vorzunehmen und zum Beispiel die Kontrolleinheit in den Simulator zu integrieren. Des weiteren ist er in Java geschrieben,
was die Integration mit dem Fahrerassistenten, der ebenfalls in Java geschrieben
ist, ganz erheblich erleichtert.
Als letzter Vorteil ist noch der relativ geringe Umfang des Quellcodes zu nennen. Dies erleichtert es ebenfalls den Simulator an die Bedürfnisse des Assistenten
anzupassen und auch ein paar der erwähnten Mängel, speziell die zu hohen Beschleunigungswerte, zu korrigieren.
Insgesamt lässt sich sagen, dass VIS SIM zwar kein perfekter Verkehrssimulator
ist, aber Dank seiner Vorteile, speziell der einfachen Editierbarkeit, der simplen
Generierung von Straßennetzen und der Kompatibilität mit den restlichen Komponenten der Architektur, den anderen Alternativen auf jeden Fall vorzuziehen
ist.
25
2.4.2 OWL
Als Modellierungssprache für die Ontologie bietet sich OWL an. Es wird von der
W3C Web Ontology Working Group2 entwickelt und ging aus den beiden Sprachen
DAML und OIL hervor. OWL soll der zukünftige Standard zur Beschreibung von
Web-Ontologien werden [SWM04].
OWL besitzt eine wohldefinierte Syntax und eine formale Semantik. Eine weitere wichtige Eigenschaft ist die Möglichkeit einen Reasoner zur Unterstützung
einzusetzen. Die formale Semantik erlaubt es präzise, eindeutige Angaben zu machen, die wohldefinierte Syntax führt dazu, dass in OWL beschriebene Modelle
ohne weitere Informationen für Maschinen lesbar sind. Der Einsatz eines Reasoners ermöglicht es automatische Schlüsse auf der Grundlage des Modells sowohl
aus den Daten als auch aus dem Modell zu ziehen.
Die Sprache OWL verwendet eine auf XML basierende Syntax und baut auf
RDF und RDF Schema auf, ist aber nur teilweise mit RDF Schema kompatibel.
Die Unterschiede von OWL und RDF beziehungsweise RDF Schema werden in
Abschnitt 2.5.3 erläutert.
Abbildung 2.2: Einfache Klassenhierarchie und Properties
In OWL werden Klassen und Klassenhierarchien definiert. Diese Klassen können
gewisse Eigenschaften, sogenannte Properties haben. Auch Properties können in
Hierarchien strukturiert werden. Jede Property hat einen Definitionsbereich und eine Wertemenge, wobei hier zwischen Class und Datatype Properties unterschieden
wird. Class Properties bilden eine Klasse auf eine andere ab, Datatype Properties
Klassen auf vordefinierte Datentypen wie Integer, Float, String oder Date. Das Beispiel in Abbildung 2.2 zeigt die Klasse Kleinwagen, die als Unterklasse der Klasse
PKW definiert ist. Jeder PKW hat genau eine Datatype Property Geschwindigkeit, und eine Class Property Fahrer. Die Property Fahrer bildet die Klasse PKW
2
http://www.w3.org/TR/owl-features/
26
auf die Klasse Mensch ab, wobei die Beschränkung hier nicht bei genau einem
Fahrer liegt, sondern bei maximal einem Fahrer, da es auch parkende Autos gibt.
Des Weiteren könnte man sich überlegen, dass Geschwindigkeiten sowohl in
km/h, als auch in mph angegeben werden können und zwei Subproperties für Geschwindigkeit definieren. Folgende OWL-Datei beschreibt die einfache Hierarchie
der drei Properties:
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns="http://home.in.tum.de/lutzg/owl/geschwindigkeit.owl#"
xml:base="http://home.in.tum.de/lutzg/owl/geschwindigkeit.owl">
<owl:Ontology rdf:about=""/>
<owl:DatatypeProperty rdf:ID="kmh">
<rdfs:subPropertyOf>
<owl:DatatypeProperty rdf:ID="Geschwindigkeit"/>
</rdfs:subPropertyOf>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="mph">
<rdfs:subPropertyOf rdf:resource="#Geschwindigkeit"/>
</owl:DatatypeProperty>
</rdf:RDF>
Am Anfang der Datei werden die Namensräume (englisch namespace) definiert. Die
Datei selbst erhält http://home.in.tum.de/lutzg/owl/geschwindigkeit.owl#
als URI. Die Definition der Propertyhierarchie geschieht mit Hilfe von RDFSKonstrukten, die Property Geschwindigkeit wird in der Definition von kmh eingeführt. Abbildung 2.3 zeigt die daraus resultierende Hierarchie der Properties
Geschwindigkeit, kmh und mph.
Sowohl Datatype als auch Class Properties können mit Eigenschaften wie Kardinalität, Transitivität, Symmetrie usw versehen werden. Mit Hilfe der Kardinalität
von Properties kann man zum Beispiel festlegen, dass ein Fahrzeug genau eine
Geschwindigkeit hat. Symmetrie gilt unter anderem für eine Property Kollisionspartner, die zwei an einem Unfall beteiligte Fahrzeuge verknüpft, Transitivität für
die Erreichbarkeit von Knoten in einem Graphen. Auch bei den Definitionen von
Klassen bietet OWL Möglichkeiten, die über die simple Klassen und Subklassenhierarchie hinausgehen. In OWL ist es möglich neue Klassen als boolsche Klassen
von bereits existierenden Klassen zu definieren. Eine denkbare Definition wäre,
dass jedes Fahrzeug, das nicht mein eigenes ist, das eines anderen Verkehrsteilnehmers sein muss. Ebenso kann man definieren, dass ein Fahrzeug nicht sowohl ein
PKW als auch ein LKW sein kann, die beiden Klassen also disjunkt sind.
27
Abbildung 2.3: Einfache Propertyhierarchie
Das OWL-Modell, das aus Klassen und Properties besteht, kann mit Daten
instanziiert werden. Instanzen sind sozusagen Individuen der einzelnen Klassen.
Zum Beispiel kann Uli als Instanz der Klasse Mensch kreiert werden, der als Fahrer
in seinem blauen Auto, einem Kleinwagen, mit einer Geschwindigkeit von 60 km/h
fährt. In Beschreibungslogiken wird das Modell auch als TBox bezeichnet und die
Instanzen als ABox. Sowohl das Modell, als auch die Instanzen werden in OWL in
der selben Datei abgespeichert.
Eine Besonderheit von OWL ist, dass es in drei Varianten existiert. Die Eigenschaften der einzelnen Versionen sind [SWM04] und [Mv04] entnommen:
• OWL Full: Dies ist die komplette Sprache. Sie ist voll kompatibel mit RDFS.
Die strikte Trennung von Klassen und Individuen gilt hier nicht, außerdem
ist es möglich, die Konstruktoren von RDF und OWL neu zu definieren.
• OWL DL: Die Trennung von Individuen und Klassen ist hier gegeben, Neudefinitionen von RDF- oder OWL-Konstruktoren sind nicht möglich. OWL
DL enthält alle OWL-Konstrukte mit der Einschränkung, dass Properties
von Klassen verschieden und außerdem entweder Datatype oder Object Properties sein müssen. Es kann auf eine Beschreibungslogik abgebildet werden
und ist dadurch entscheidbar. Außerdem ermöglicht dies den Einsatz von
Reasonern, die für Beschreibungslogiken entwickelt wurden.
• OWL Lite: Dies ist die am wenigsten mächtige Version von OWL. Sie
erlaubt hauptsächlich die Definition einfacher Klassenhierarchien und Beschränkungen der Kardinalität von Properties mit den Werten Eins und Null.
OWL Full ist die mächtigste der drei Versionen, OWL Lite die am wenigsten
mächtige. Der Vorteil in der Staffelung in drei Sprachvarianten mit unterschiedlicher Geschwindigkeit liegt in der Möglichkeit, die Mächtigkeit der Sprache mit der
Geschwindigkeit und Qualität der Unterstützung durch Reasoner abzuwägen. Je
mächtiger die Sprache, desto langsamer sind die dazu passenden Reasoner. Probleme in OWL Full können auch unentscheidbar sein.
28
OWL DL hat den Vorteil, dass es auf eine Beschreibungslogik abgebildet werden
kann und ermöglicht es somit Reasoner, die für Beschreibungslogiken geschrieben
wurden, zu verwenden. Beispiele für solche Reasoner sind RACER3 [HM01] und
FaCT4 [Ian98].
Für OWL existiert das Java Framework Jena. Jena stellt weitere Reasoner für
OWL zur Verfügung. Ebenso gibt es Editoren zur Erstellung von OWL-Ontologien,
zum Beispiel Protégé (siehe Abschnitt 2.4.3), OntoEdit5 und OILed6 . Auch Querysprachen, mit deren Hilfe man Anfragen an die mit Daten instanziierte OWLOntologie stellen kann, sind vorhanden.
Auf Grund der oben aufgezählten Eigenschaften eignet sich OWL als Sprache
zur ontologischen Kontextmodellierung. Auch wegen der vorhandenen Werkzeuge
wird OWL zur Beschreibung der Ontologien im Fahrerassistenten gewählt.
Von Vorteil sind besonders die Möglichkeit zwischen Mächtigkeit und Geschwindigkeit abwägen zu können, ebenso wie die Tatsache, dass OWL der zukünftige
Standard für das semantische Web werden soll. Ersteres wiegt besonders schwer,
da die Kollisionsberechnung in Bruchteilen von Sekunden geschehen muss, also ein
möglichst effizienter Reasoner nötig ist. Auch die vorhandenen Editoren, Querysprachen und Frameworks einschließlich Reasoner sprechen für OWL.
2.4.3 Protégé
Protégé ist ein Editor zur Erstellung von Ontologien. [GMF+ 03] enthält einen
kurzen Überblick zur Entwicklung des Editors, weitere Informationen finden sich
auf der Homepage7 . Da OWL eine XML-basierte Syntax hat, ist es zwar möglich,
OWL-Dateien im Texteditor zu schreiben, aber äußerst mühsam und auch fehleranfällig. Deshalb ist es von Vorteil, einen speziellen Editor zur Formulierung
der OWL-Ontologie zu verwenden.
Protégé wird an der Stanford University entwickelt. Er unterstützt sowohl OWL
Full als auch OWL DL und OWL Lite [KFFM04]. Ontologien können in unterschiedlichen Formaten abgespeichert werden, sowohl in einem Protégé eigenen Format als auch zum Beispiel in RDF Schema, in N-Tripeln oder als OWL-Datei in
XML-Kodierung.
Es ist möglich sowohl das Modell zu definieren, als auch Instanzen für einzelne
Klassen zu erzeugen und anzuzeigen.
Protégé unterstützt den Benutzer während der Entwicklung einer Ontologie. So
kann man externe Reasoner wie FaCT oder RACER an Protégé anbinden. Diese
erlauben es das Modell und die Instanzen auf Konsistenz zu überprüfen. Auch das
Ableiten weiterer Klassen mit Hilfe eines Reasoners ist möglich.
3
http://www.racer-systems.com
http://www.cs.man.ac.uk/ horrocks/FaCT/
5
http://www.ontoprise.de
6
http://oiled.man.ac.uk
7
http://protege.stanford.edu/
4
29
Ein weiteres Merkmal des Protégé-Editors ist es, dass er Anfragen mittels SPARQL an die definierte Ontologie erlaubt. Die Query-Sprache SPARQL wird in Abschnitt 2.4.4 genauer beschrieben. Da SPARQL als Querysprache für den Fahrerassistenten gewählt wird, erleichtert dies die Zusammenstellung von korrekten
SPARQL-Queries ganz erheblich.
Protégé ist also ein sehr brauchbarer Editor zum Erstellen von OWL-Ontologien,
da er alle drei OWL-Varianten beherrscht und außerdem noch Anfragen in der
verwendeten Querysprache erlaubt. Zusätzlich ist der Umgang mit Protégé bei
Kenntnis von OWL auch sehr schnell erlernbar.
2.4.4 SPARQL
Um die in der Ontologie gespeicherten Daten auch nutzen zu können, muss es
möglich sein, Anfragen an die Ontologie zu stellen. Diese Anfragen werden in einer
Querysprache formuliert. Als Querysprache wird SPARQL ausgewählt.
SPARQL wird von W3C8 entwickelt. Es ist als Querysprache für RDF-Graphen
gedacht, es sind aber auch Anfragen an OWL-Dateien möglich, da diese sich der
RDF-Syntax bedienen.
Zur Veranschaulichung hier ein einfaches Beispiel eines SPARQL-Querys:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX kontext: <http://stud.tejp.de/georg/onto/fahrzeug.owl#>
SELECT ?x
WHERE { ?x rdf:type kontext:Eigenes_Fahrzeug }
Mit PREFIX werden die Namensräume definiert, hier also rdf: für die RDFSyntax, die unter der URI <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
definiert ist und kontext: für die OWL-Datei fahrzeug.owl mit der dazugehörenden URI <http://stud.tejp.de/georg/onto/fahrzeug.owl#>.
Die Anfrage liefert alle Treffer für die Variable x, die ein Vergleich der in der
WHERE-Klausel angegeben Tripel mit den in der Ontologie gespeicherten Tripeln
ergibt. In diesem Fall also alle Instanzen vom Typ Eigenes_Fahrzeug, wie er in
der Datei fahrzeug.owl definiert ist. Das Ergebnis wird als Menge von RDFTripeln zurückgegeben.
SPARQL ermöglicht es, auch auf unterschiedliche Datensätze zuzugreifen, indem zum Beispiel die Anfragen an die Vereinigung der RDF-Graphen gestellt
wird. Auch sind optionale Bedingungen möglich oder Tests auf Variablenwerte.
Man kann also nach allen Fahrzeugen suchen, die eine gewisse Geschwindigkeit
überschreiten. Auch Filter, die reguläre Ausdrücke beim Testen von Strings verwenden, sind möglich.
Ein Nachteil von SPARQL ist es, dass es keine Transitivität unterstützt. Dieses
Problem lässt sich aber umgehen, indem man vor einer Anfrage an die Ontologie
8
http://www.w3.org/TR/rdf-sparql-query/
30
mit Hilfe eines Reasoners die transitive Hülle erzeugt und die SPARQL-Anfrage
dann an die abgeleitete Ontologie gestellt wird.
SPARQL ist hinreichend mächtig für Anfragen des Fahrerassistenten, auch wenn
es keine auf OWL spezialisierte Sprache ist. Des Weiteren existiert noch keine ausgereifte OWL-Querysprache, die weitere Eigenschaften von OWL, wie zum Beispiel
die Definition von Transitivität bei Properties, unterstützt. Ein weiterer Grund für
die Wahl von SPARQL ist die Tatsache, dass es von Jena und Protégé (siehe Abschnitt 2.4.5 und Abschnitt 2.4.3) unterstützt wird.
2.4.5 Jena
Jena ist eine Java Programmierumgebung für RDF, RDF Schema, OWL und
SPARQL. Es ist ein Open Source Projekt. Ausführliche Informationen und eine
detaillierte Dokumentation finden sich auf der Homepage9 .
Jena bietet eine Programmierschnittstelle für RDF. Hier ist es unter anderem
möglich Modelle aus RDF-Dateien zu erzeugen, Tripel hinzuzufügen und die Modelle in RDF-Dateien zurückzuschreiben. Ebenso können einfache Anfragen an die
RDF-Modelle gestellt werden.
Interessanter ist die Programmierschnittstelle für Ontologien. Jena bietet umfassende Unterstützung bei der Verwaltung von Ontologien. Es kann sowohl Ontologien aus RDF Schema als auch DAML+OIL und OWL-Dateien erzeugen. Ebenso
ist es möglich diese Ontologien mit Klassen und Properties zu erweitern, zu instanziieren oder auch Teile wieder zu löschen.
Der Import von Ontologien kann gesteuert werden, das heißt zum Beispiel ob die
Imports überhaupt eingebunden werden sollen oder wo die Ontologie sich befindet,
also ob es eine lokale Kopie gibt oder sie aus dem Internet heruntergeladen werden
muss.
Wichtig ist auch die Unterstützung mit Reasonern. Es existieren die unteschiedlichsten Reasoner für OWL Full, OWL DL und OWL Lite ebenso wie ein DAML
Reasoner, eine RDF Schema Reasoner und ein Generic Rule Reasoner. Eine weitere
Möglichkeit ist es externe Reasoner zu verwenden.
Vor allem der Generic Rule Reasoner ist interessan. Es ist ein regelbasierter Reasoner, den man mit eigenen Regeln erweitern kann. Diese Regeln werden entweder
direkt im Programm angegeben, oder extern in einer eigenen Datei gespeichert.
Eine Regel rule0, die die Transitivität von Erreichbarkeit bei Straßen definiert,
könnte zum Beispiel folgende Form haben:
@prefix street: <http://stud.tejp.de/georg/onto/strassennetz.owl#>.
# Erreichbarkeit
[rule0: (?a street:erreichbar ?b) (?b street:erreichbar ?c)
-> (?a street:erreichbar ?c)]
9
http://jena.sourceforge.net/
31
Wenn also Straße b von Straße a aus erreichbar ist und Straße c von Straße b,
dann ist auch Straße c von Straße a aus erreichbar.
Mit jeder Ontologie kann ein Reasoner verknüpft werden, wobei es möglich ist,
jeden Reasoner mit einem eigenen Regelsatz zu versehen. Auch kann man mit Hilfe
eines Reasoners ein Modell von einem anderen Modell ableiten und somit mehrere
Modelle und Reasoner übereinander schichten.
Mit der Jena Ontology API ist es möglich, Anfragen an Modelle beziehungsweise
Ontologien zu stellen. Jena unterstützt aber auch SPARQL. Die SPARQL Query
Engine erlaubt es, SPARQL-Queries auszuwerten und Anfragen an Ontologien zu
stellen.
Jena bietet also sehr gute Unterstützung bei der Entwicklung von Anwendungen,
die OWL-Ontologien verwenden. Sowohl die Schnittstellen für OWL-Ontologien
als auch die Möglichkeiten, die Jenas Reasoner bieten, sind entscheidende Gründe
für die Wahl von Jena als Framework für die Einbindung von Ontologien in den
Fahrerassistenten. Auch die Unterstützung von SPARQL ist von Vorteil, ebenso
die ausführliche Dokumentation.
2.4.6 Java
Die Programmiersprache, in der der Fahrerassistent geschrieben wird, ist Java.
Gründe hierfür sind die vorhandene Unterstützung für Ontologiemanagement, also
das Framework Jena. Ebenso ist der Verkehrssimulator VIS SIM in Java geschrieben. Es bietet sich also an den Fahrerassistenten ebenfalls in Java zu programmieren, da Kommunikation zwischen Programmen, die zum Beispiel in C und in
Java geschrieben sind, zwar möglich ist, im Fall von Java und C zum Beispiel mit
JNI10 , aber nicht immer problemlos funktioniert. Des Weiteren ist Java plattformunabhängig, und somit auch der Fahrerassistent.
2.4.7 Erwartungen an die ontologische Kontextmodellierung
Nachdem die verwendeten Sprachen, der OWL-Editor und das Framework beschrieben wurden, werden in diesem Abschnitt die Erwartungen an die Ontologie
erläutert.
Abgrenzung zu anderen Möglichkeiten der Modellierung
Zuerst wird die ontologische Kontextmodellierung von anderen Arten der Kontextmodellierung abgegrenzt. Nach [SL04] gibt es folgende Klassen von Modellen,
die sich zur Formalisierung von kontextbezogenen Informationen eignen:
1. Bei Key-value Modellen wird die Information bezüglich des Kontexts einer
Variable als Wert zugewiesen. Es ist nicht möglich, Restriktionen anzugeben
und somit ist auch eine Validierung nicht durchzuführen. Key-value Modelle
10
http://java.sun.com/j2se/1.4.2/docs/guide/jni/
32
können aber durchaus zur Beschreibung von Kontextinformationen in mobilen Umgebungen eingesetzt werden [SAW94].
2. Markup Scheme Modelle besitzen eine hierarchische Datenstruktur, die
einzelnen Elemente haben Attribute und Werte. XML und RDF Schema sind
Sprachen zur Beschreibung von Markup Scheme Modellen. Beispiele für in
RDF und RDF Schema verfasste Modelle finden sich unter anderem in [Av04].
Schwachpunkte dieses Ansatzes sind die Tatsache, dass Definitionen oft in
externen Dateien stehen (DTD) und somit die Vereinigung von zwei Modellen
erschweren und dass eine Validierung des Modells nur partiell möglich ist
[SL04].
3. Graphische Modelle erlauben es, zum Beispiel Entity-Relationship-Modelle von relationalen Datenbanken darzustellen. Die unterschiedlichen Konzepte
(Entities) werden durch verschiedene Beziehungen (Relationships) miteinander verbunden. Eine hierfür geeignete Sprache ist zum Beispiel UML. Von
Nachteil ist, dass graphische Modelle meist nur eingeschränkt maschinenlesbar sind. Ein Beispiel für einen grafischen Ansatz zur Kontextmodellierung findet sich mit einer Erweiterung für Object-Role Modeling (ORM) in
[HIR03].
4. Bei objektorientierten Modellen wird Kontext durch Objekte modelliert,
die die Kontextinformationen enthalten. Vorteile sind die Wiederverwendbarkeit und die Abkapselung von Informationen in Objekten, die nur über
spezielle Schnittstellen ansprechbar sind. Auch hier ist Validierung nur partiell möglich. In [CMD99] wird ein elektronischer Reiseführer vorgestellt, der
Besucher einer Stadt mit Informationen versorgt, und sich hierzu eines objektorientierten Kontextmodells bedient.
5. Logik basierte Modelle formalisieren die Kontextinformationen in mathematisch abstrakter Art und Weise mit Hilfe von Fakten, logischen Ausdrücken und Regeln. Beispiele hierfür sind die Prädikatenlogik erster Stufe
und Beschreibungslogiken [Baa03]. Bei Beschreibungslogiken wird zwischen
der Formalisierung der Konzepte und der Formalisierung der Instanzen unterschieden. Logik basierte Modelle haben ihren Ursprung im Forschungsbereich
der künstlichen Intelligenz. Von Vorteil ist die sehr formale Beschreibung des
Modells.
6. Ontologie basierte Modelle definieren wichtige Aspekte des Kontexts als
Konzepte, welche bestimmte Eigenschaften haben. Ebenso können Beziehungen zwischen den einzelnen Konzepten und Eigenschaften beschrieben
werden, die über eine Konzept- und Eigenschaftshierarchie hinausgehen. Es
ist möglich, mehrere ontologische Kontextmodelle zu einem Modell zu verknüpfen. Ebenso ist die formale Beschreibung von Konzepten und Beziehun-
33
gen von Vorteil und macht Ontologien maschinenlesbar. Eine Sprache zur
ontologischen Kontextmodellierung ist zum Beispiel OWL [Mv04].
Der Ansatz der ontologischen Kontextmodellierung hat entscheidende Vorteile gegenüber den anderen Ansätzen. Von den meisten anderen Modellen unterscheiden
sich die ontologischen Modelle durch ihren hohen Grad an Formalität und damit
auch Maschinenlesbarkeit. Dies ermöglicht auch den Einsatz von Reasonern. Trotzdem sind Ontologien mächtiger als Beschreibungslogiken. Während bei den allermeisten Beschreibungslogiken strikt zwischen Definitionen (TBox) und Instanzen
(ABox) unterschieden wird [Baa03], ist es zum Beispiel in OWL Full, einer Sprache
zur Modellierung von Ontologien, möglich, dass Instanzen zugleich auch Klassen
sind [SWM04]. Allerdings wird dieser Vorteil bei OWL Full mit Unentscheidbarkeit erkauft [Av04]. Unentscheidbarkeit bedeutet hier, dass das Reasoning eventuell
nicht terminiert. Kompromisse bei der Mächtigkeit ermöglichen es, dass Ontologien auf Beschreibungslogiken abgebildet werden, und somit alle Vorteile von diesen
auch auf die entsprechenden Ontologien, zum Beispiel OWL DL, zutreffen. Im
Gegensatz zu Beschreibungslogiken sind Ontologien aber oft relativ leicht für den
Menschen zu verstehen, ein nicht zu unterschätzender Vorteil.
Erwartungen an die Ontologie
Aus diesen Vorteilen, die der Ansatz der ontologischen Kontextmodellierung mit
sich bringt, leiten sich auch die meisten Erwartungen an den Einsatz einer Ontologie im Fahrerassistenten ab.
Als erstes lässt sich erwarten, dass es dank der Mächtigkeit von Ontologien
möglich ist, ein gutes Modell des Kontextes aufzustellen, also alle Tatsachen, die
beschrieben werden müssen, auch beschreiben zu können. Die Verwendung von
OWL als Sprache zur Modellierung von Ontologien erlaubt es, je nach Anforderungen an das Modell, eine geeignete, hinreichend mächtige Version der Sprache
einzusetzen.
Dieses Modell muss maschinenlesbar sein, es darf also kein zusätzliches externes
Wissen nötig sein, um es richtig zu instanziieren und interpretieren. Zweideutigkeiten im Modell sollten also nicht vorkommen. Dies ist beim Einsatz von Ontologien
ebenfalls gegeben, dass es sich bei ihnen um eine “formal, explicit specification of
a shared conceptualization” handelt [SBF98].
Es sollte möglich sein, aus relativ einfachen Daten mit Hilfe von Reasonern und
Regeln, die das Wissen um die Zusammenhänge formalisieren, komplexere Informationen herzuleiten. Vor allem der Einsatz von Reasonern erlaubt es, auf das
Wissen, das in Ontologien implizit durch Konzepte, Beziehungen und Eigenschaften modelliert ist, zurückzugreifen.
Je nach Mächtigkeit der Ontologie ist zu hoffen, dass das Ableiten von Zusammenhängen oder die Beantwortung von Anfragen in einem vernünftigen Zeitrahmen machbar ist. OWL sollte es ermöglichen, durch die Beschränkung auf OWL
DL oder gar OWL Lite diese Erwartung zu erfüllen. Vor allem der Einsatz von Rea-
34
sonern, die für Beschreibungslogiken entwickelt wurden, verspricht in den meisten,
in der Praxis auftretenden Fällen, relativ kurze, also nicht exponentielle Laufzeiten
[SS04].
Die Querysprache SPARQL erlaubt die Formulierung relativ komplexer Anfragen (siehe Abschnitt 2.4.4). In Kombination mit einem Reasoner sollten diese Anfragen an die Ontologie Ergebnisse von hoher Qualität liefern, da der Reasoner
auch den Zugriff auf implizites Wissen ermöglicht.
Ein wichtiges Argument für die Verwendung von Ontologien ist die Erweiterbarkeit und Wiederverwendbarkeit. Ontologien sollen leicht mit neuen Konzepten
zu erweitern sein, man kann also eine schon existierende Ontologie verwenden und
die gewünschten Konzepte hinzufügen. Somit könnten Ontologien für neue Anwendungen wiederverwendet werden, entweder ganz ohne oder mit eventuell nötigen
Erweiterungen. Dies kann den Aufwand bei der Erstellung neuer Anwendungen
wesentlich reduzieren.
In diesem Zusammenhang ist auch der Import anderer Ontologien zu erwähnen.
Somit sollte es machbar sein, zum Beispiel Ontologien verschiedener Hersteller zu
importieren, in denen ihre Fahrzeuge genauer spezifiziert werden und auf diese
Daten auch zurückzugreifen.
Ontologien erleichtern auch den Datenaustausch, da man Synonyme definieren
kann. Wenn eine Ontologie in Englisch verfasst ist und die andere deutsche Begriffe
verwendet, können diese als gleichbedeutend gesetzt werden. Somit kann sowohl
auf Daten über Geschwindigkeit als auch über Speed zugegriffen werden. Der
Zugriff auf externe Ontologien ist durch die Definition von Abbildungsregeln für
Konzepte der unterschiedlichen Ontologien möglich.
Der Einsatz von Ontologien sollte ebenso ein hohes Abstraktionslevel bei Anwendungen möglich machen. Wenn Anwendungen ihre Daten über eine Ontologie
beziehen, sind sie unabhängig vom eigentlichen Datenformat, sie greifen nur auf
das ontologische Modell zu.
In Abschnitt 6.1 und Abschnitt 6.2 wird untersucht, ob diese Erwartungen auch
erfüllt werden, beziehungsweise inwieweit sich eine Ontologie überhaupt zur Kontextmodellierung im Zusammenhang mit Kollisionsvermeidung bei Fahrzeugen eignet.
2.5 Alternativen
In diesem Abschnitt werden ein paar der möglichen Alternativen zu den in Abschnitt 2.4 erläuterten Entscheidungen bezüglich der gewählten Sprachen und des
Verkehrssimulators beschrieben.
35
2.5.1 Andere Verkehrssimulatoren
Zuerst werden zwei alternative Verkehrssimulatoren vorgestellt. Für beide steht
der Quellcode im Internet zur Verfügung, da es sich um Open Source Projekte
handelt.
2.5.1.1 SUMO
SUMO ist ein frei verfügbarer Verkehrssimulator. Er wird von Mitarbeitern des
Zentrums für angewandte Informatik der Universität Köln und dem Institut für
Verkehrsführung und Fahrzeugsteuerung am Deutschen Zentrum für Luft- und
Raumfahrt entwickelt. Informationen finden sich auf der Homepage11 , ebenso wie
die neueste Version des Simulators. Hier gibt es auch eine Dokumentation [KR07],
an der allerdings zum Zeitpunkt dieser Arbeit noch geschrieben wird.
Die Programmiersprache, in der SUMO geschrieben ist, ist C++. Dies ist der
entscheidende Nachteil des Simulators gegnüber VIS SIM, da es recht aufwändig
ist den in Java programmierten Fahrerassistenten mit einem in C++ geschriebenen
Verkehrssimulator kommunizieren zu lassen. Es ist zwar möglich, sprengt aber den
Rahmen dieser Arbeit.
Genau wie VIS SIM ist SUMO ein mikroskopischer Verkehrssimulator, das heißt
das Fahrerverhalten und die Fahrzeugeigenschaften sind die Grundlage der Simulation. Ebenso bedient sich SUMO eines kollisionsfreien Modells zur Verkehrssimulation, Unfälle müssen also erzwungen werden. Laut Dokumentation ist dies
mit dynamischen Anpassungen der Geschwindigkeitsvorschriften oder mit Stopbefehlen für einzelne Fahrzeuge, die für den öffentlichen Nahverkehr gedacht sind,
theoretisch möglich.
Ein Nachteil von SUMO gegenüber VIS SIM ist es, dass in SUMO die Positionsberechnungen der einzelnen Fahrzeuge nur jede Sekunde vorgenommen werden.
Dies ist ein recht grobes Zeitraster, da Kontrollbefehle des Fahrerassistenten somit
nur jede Sekunde beachtet werden können. Ebenso kommt es zu der unrealistischen
Situation, dass alle Fahrzeuge gleichzeitig auf die Berechnungen ihrer Fahrerassistenten reagieren.
Des Weiteren ist es im unmodifizierten SUMO nicht möglich, die Fahrzeuge
einzeln extern anzusprechen oder die Simulation schrittweise ablaufen zu lassen.
Hierzu muss der Quellcode von SUMO geändert werden.
Zur Erstellung von Straßennetzen müssen XML-Dateien geschrieben werden, was
nicht so komfortabel ist wie der graphische Editor von VIS SIM, aber genauere
Angaben ermöglicht. Außerdem können wesentlich umfangreichere Straßennetze
beschrieben werden, ebenso ist es möglich, die Netze anderer Verkehrssimulatoren
oder Datenbanken zu importieren.
Ein weiterer Vorteil von SUMO ist die Möglichkeit, einzelnen Fahrzeugen feste
Routen zuzuweisen. Somit können bekannte Gefahrensituationen besser getestet
11
http://sumo.sourceforge.net
36
oder reproduziert werden. Dies ist in VIS SIM nicht möglich. Ein graphisches Interface zur Visualisierung der Simulation ist ebenso vorhanden.
Das Entwicklerteam und die höhere Professionalität von SUMO lassen bessere
Ergebnisse als die des Simulators VIS SIM erwarten. Auch das größere Straßennetz und die anzunehmende geringere Anzahl an Fehlern in der Simulation sind
gute Argumente für SUMO. Gegen Sumo spricht die geringe Anzahl der Positionsberechnungen. Der eigentliche Grund, warum VIS SIM und nicht SUMO als
Verkehrssimulator gewählt wurde, ist aber die Tatsache, dass SUMO in C++ und
nicht in Java geschrieben ist.
2.5.1.2 SWANS++
Eine weitere interessante Alternative zu VIS SIM ist SWANS++. Es ist eine Open
Source Weiterentwicklung des Frameworks JIST/SWANS. Hauptverantwortlicher
ist David Choffnes von der Northwestern University. Informationen zu SWANS++
und Links zur Dokumentation von JIST/SWANS finden sich auf der Homepage12 . JIST ist eine Simulationsumgebung für Javaprogramme und SWANS ein auf
JIST basierender Netzwerksimulator. Beide wurden an der Cornell University entwickelt13 .
SWANS++ erweitert den Netzwerksimulator JIST/SWANS um einen Verkehrssimulator. Auch dieser Verkehrssimulator ist mikroskopisch. Ebenso wie die beiden
anderen Alternativen bedient sich SWANS++ eines kollisionsfreien Modells.
Die Kombination von Verkehrs- und Netzwerksimulator eröffnet interessante
Möglichkeiten, da auch das Netzwerk, über das die einzelnen Fahrzeuge miteinander kommunizieren, simuliert werden kann. Weder SUMO noch VIS SIM bieten
diese Möglichkeit.
Ein Problem bei der Verwendung von SWANS++ ist die nichttriviale Erzeugung
von Straßennetzen. Es existiert nur die Möglichkeit TIGER-Karten zu importieren. Tiger ist ein Kartenformat des United States Census Bureau14 , in dem unter
anderem Informationen zu Straßen, Gebäuden und Gewässer enthalten sind. Dies
ermöglicht einerseits den Import von realistischen Daten, andererseits erschwert es
das Erstellen von einfachen Testnetzwerken erheblich.
Ein Schwachpunkt von SWANS++ ist die graphische Ausgabe, die sehr einfach
gehalten ist. Straßen werden zum Beispiel nur als einfache Striche dargestellt, somit
sind Unfälle nur schwer zu analysieren.
Gegenüber von SUMO hat SWANS++ den großen Vorteil, dass es in Java geschrieben ist, beziehungsweise eine Simulationsumgebung für Javaprogramme ist.
Allerdings hat sich gezeigt, dass SWANS++ nicht mit Jena kompatibel zu sein
scheint. JIST verwendet einen Class-Rewriter, um die kompilierten Javaklassen
für die Simulation vorzubereiten. Versucht der Rewriter aber die Klassen von Jena
12
http://www.aqualab.cs.northwestern.edu/projects/swans++/
http://jist.ece.cornell.edu
14
http://www.census.gov/geo/www/tiger/
13
37
umzuschreiben, tritt ein java.lang.NoClassDefFoundError auf. Dies liegt nicht
an ungültigen Pfadangaben oder veralteten Programmbibliotheken, wie ein direkter Programmaufruf ohne den Einsatz von JIST zeigt, und es scheint unmöglich,
den Fehler in einem vernünftigen Zeitrahmen zu finden und zu beheben. Die unvollständig umgeschriebenen Programme lassen sich mit JIST nicht mehr korrekt
ausführen und somit kann auch SWANS++ nicht eingesetzt werden, da es auf
JIST aufbaut.
Somit ist es zumindest nicht ohne größeren Aufwand möglich, den Fahrerassistenten, wenn er sich des Frameworks Jena bedienen soll, mit dem Verkehrssimulator SWANS++ zu verknüpfen. Dies ist ein entscheidender Nachteil gegenüber
dem Simulator VIS SIM, bei dem die Integration von Assistenten und Verkehrssimulator keine Probleme bereitet.
Bei der Entscheidung gegen SWANS++ war die erwähnte Inkompatibilität mit
Jena ausschlaggebend. Die graphische Ausgabe und die Schwierigkeiten bei der
Erstellung von Teststraßennetzen sind weitere Nachteile, die aber durch die Vorteile eines kombinierten Netzwerk- und Verkehrssimulators aufgewogen werden.
Die Tatsache, dass es sich nicht um die Arbeit eines Studenten handelt, ist zwar
positiv, andererseits gibt es von SWANS++ nur eine Alphaversion, eine niedrige
Fehlerrate ist also nicht garantiert.
2.5.2 OWL-QL
OWL-QL ist eine Querysprache, die speziell für OWL aus der DAML Query Language entwickelt wurde. OWL-QL spezifiziert auch ein Protokoll für Client und
Server zur Beantwortung einer Anfrage. Somit erscheint es eine gute Alternative
zu SPARQL zu sein, da letzteres nicht speziell auf OWL zugeschnitten ist, sondern auf RDF. OWL-QL wird an der Stanford University entwickelt. Außer auf
der Homepage15 finden sich in [FHH04] weitere Informationen zu OWL-QL. Die
Sprache ist abstrakt gehalten, so dass der Einsatz mit Ontologien, die nicht in
OWL formalisiert sind, denkbar ist.
Die Syntax von OWL-QL ist ähnlich der Syntax von SPARQL. Auch hier besteht
der Query aus Tripeln der Form (type ?c Fahrzeug), allerdings ist die Form
abstrakter. Zusätzlich kann angegeben werden welche Variablen gebunden werden
müssen und wie das Antwortschema aussehen soll. OWL-QL ist speziell für den
Einsatz im Semantic Web ausgelegt und unterstützt den Einsatz von Reasonern.
Gegen die Anwendung von OWL-QL als Querysprache sprechen mehrere Fakten.
Erstens ist es relativ schlecht dokumentiert, es findet sich außer dem Material unter
besagter Internetadresse und dem dort vorhandenen Artikel [FHH04] quasi nichts.
Außerdem erscheint die Zielsetzung einer abstrakten Sprache, die auf den Einsatz
im Internet mit der Möglichkeit, viele unterschiedliche Server, mit in unterschiedlichen Sprachen formalisierten Wissensdatenbanken, gleichzeitig zu befragen, nicht
15
http://www-ksl.stanford.edu/projects/owl-ql/
38
mit den Anforderungen an die Architektur des Fahrerassistenten, nämlich eine
möglichst schnelle Antwort zu erhalten, übereinzustimmen.
Des Weiteren ist das Projekt anscheinend noch in der Entwicklungsphase und
somit, wenn man die Fehlermeldungen des Beispielservers betrachtet, wohl noch
nicht ganz ausgereift, zumindest was die zur Verfügung gestellten Server und Client
Library und das Servlet betrifft.
Vor allem die mangelnde Dokumentation, in Kombination mit den auftretenden Fehlermeldungen, machen OWL-QL und die dazugehörige Library weniger
attraktiv als SPARQL und Jena.
2.5.3 RDF und RDF Schema
Alternativ zu OWL könnte man einfache Ontologien auch mit RDF oder RDF
Schema beschreiben.
Jena unterstützt sowohl RDF als auch RDF Schema, es wäre also möglich, dasselbe Framework wie für OWL zu verwenden. Auch der Einsatz von Reasonern für
RDF/RDFS ist mit Jena möglich. SPARQL ist sogar speziell für RDF geschrieben. Mit Protégé steht ein Editor zur Verfügung, mit dessen Hilfe man Ontologien in RDF Schema entwickeln kann. Somit wäre es machbar, anstelle von OWL
RDF/RDFS zu verwenden, ohne die restlichen Komponenten der Architektur auszutauschen.
Allerdings hat RDF/RDFS ein paar entscheidende Nachteile. Mit RDF/RDFS
kann man hauptsächlich Klassenhierarchien beschreiben. Dies ist aber zu wenig,
um den Kontext für eine Anwendung zur Kollisionsvermeidung zu modellieren.
So ist es zum Beispiel in RDF/RDFS unmöglich disjunkte Klassen zu definieren.
Somit ist es nicht möglich im Modell strikt zwischen dem eigenen und anderen
Fahrzeugen zu unterscheiden, oder zwischen Straßen und Kreuzungen. Auch die
Definition neuer Klassen mit Hilfe boolscher Ausdrücke kann in RDF/RDFS nicht
realisiert werden.
Die sehr hilfreichen Beschränkungen von Properties existieren in RDF/RDFS
ebensowenig. Hier sind sowohl die Transitivität, die Symmetrie oder das Inverse
ebenso wie Kardinalitätsbeschränkungen zu nennen. Es wäre also denkbar, dass
ein Fahrzeug zwei Geschwindigkeiten hat, ohne dass der Reasoner hier einen Fehler
entdecken könnte.
Somit ist es durchaus möglich, RDF und RDF Schema zur Formalisierung des
Kontextes zu verwenden, aber beide Sprachen bieten nicht dieselben Möglichkeiten
wie OWL. Wenn die Kontextmodellierung dagegen auf Klassenhierarchien beschränkt ist, dann ist RDF/RDFS eine denkbare Alternative.
2.5.4 Weitere Alternativen
Neben den oben genauer beschriebenen Sprachen existieren noch weitere Alternativen für die Verwaltung und Erstellung von Ontologien. Einige dieser Alternativen
39
werden hier kurz genannt. Die Aufzählung erhebt natürlich keinen Anspruch auf
Vollständigkeit.
Als erstes wäre KAON216 als Alternative zu Jena zu erwähnen. KAON2 ist ein
Framework für das Management von Ontologien. Wie Jena ist es in Java geschrieben. Es ist der Nachfolger von KAON17 und unterstützt sowohl OWL als auch
SPARQL aber auch Frame Logiken zur Beschreibung von Ontologien. Ontologien werden im KAON Server abgespeichert. Die Anbindung externer Reasoner ist
ebenso möglich, es hat aber auch eigene Reasoner.
KAON bietet grundsätzlich ähnliche Möglichkeiten wie KAON2, kann aber keine
in OWL modellierten Ontologien verarbeiten sondern hat eine eigenes, auf RDF
Schema basierendes Format zur Beschreibung von Ontologien.
Neben Jena, KAON und KAON2 existiert noch Sesame18 , ein weiteres Framework für die Verwaltung von Ontologien. Sesame kann RDF und RDF Schema
Informationen speichern. Auf diese kann sowohl mit der Sesame eigenen Querysprache RQL, als auch über eine Exportfunktion, die es erlaubt Daten von Schemata zu trennen, zugegriffen werden.
Auch bei den Ontologieeditoren gibt es Alternativen zu Protégé, zum Beispiel
OntoEdit. OntoEdit wird von der Firma Ontoprise19 vertrieben. OntoEdit bietet
wie Protégé die Möglichkeit Plug-Ins zu installieren, unterstützt es aber auch, wenn
mehrere Entwickler an derselben Ontologie arbeiten.
Ein weiterer Editor ist OILed20 . Mit ihm können Ontologien in der Vorgängersprache von OWL, DAML+OIL, formalisiert werden. Die Entwicklung von OILed
wurde eingestellt.
16
http://kaon2.semanticweb.org
http://kaon.semanticweb.org
18
http://www.openrdf.org
19
http://www.ontoprise.de
20
http://oiled.man.ac.uk
17
40
3 Erste Variante des Assistenten
Nachdem der logische Aufbau der Architektur und die verwendeten Sprachen, das
Framework und der Verkehrssimulator beschrieben wurden, wird in diesem Kapitel
die erste Variante des Fahrerassistenten genauer erläutert.
Am Anfang dieses Kapitels wird das Szenario nochmals kurz beschrieben, dann
werden die für dieses Szenario speziellen Anforderungen an die Ontologie und
die restliche Architektur aufgeführt. Im nächsten Abschnitt wird das ontologische
Modell, in den darauf folgenden die eigentliche Kollisionsberechnung und die Implementierung erklärt. Am Schluss des Kapitels werden die Ergebnisse dargelegt.
3.1 Beschreibung des Szenarios
In dieser Version des Fahrerassistenten fließt nur relativ wenig Kontext in die
Kollisionsberechnungen ein. Grundsätzlich wird angenommen, dass alle Fahrzeuge
miteinander vernetzt sind und regelmäßig an alle anderen Fahrzeuge ihre Daten
schicken. Die kommunizierten Daten sind eine Fahrzeug-ID, die Position, die Geschwindigkeit, die Richtung, die Beschleunigung und der Fahrzeugtyp. Aus dem
Fahrzeugtypen können, wenn er bekannt ist, die Länge und die Breite des Fahrzeugs berechnet werden, ansonsten werden die Maße eines Standard-PKWs genommen.
Weitere Informationen stehen nicht zur Verfügung. Vor allem das Straßennetz
und sämtliche Verkehrsregeln werden völlig ignoriert, die Umgebung wird sozusagen als weite, leere Ebene modelliert, über die sich Fahrzeuge, zumindest was das
Modell betrifft, in beliebigen Richtungen völlig frei bewegen können.
Ziel dieses Szenarios ist es herauszufinden, welche Qualität die Kollisionsvorhersagen, die im Wesentlichen mit Positions-, Richtungs- und Geschwindigkeitsdaten
berechnet werden, haben. Durch eine Analyse der Mängel kann dann bestimmt
werden, welche weiteren Kontextinformationen die Qualität der Berechnungen verbessern sollten.
3.2 Anforderungen an Ontologie und Architektur
Nachdem die allgemeinen Anforderungen an die Architektur und den Fahrerassistenten in Abschnitt 2.2 erläutert wurden, wird hier auf die speziellen Anforderungen dieses Szenarios, auch an die Ontologie, eingegangen.
41
Wichtigste Voraussetzung für sinnvolle Berechnungen sind korrekte Daten. Es
müssen also ständig neue Daten zu Position, Geschwindigkeit, Beschleunigung und
Richtung aller Fahrzeuge zur Verfügung stehen. Je öfter die Fahrzeuge ihre eigenen
Daten messen, die der anderen empfangen, und aus beiden Datensätzen die Kollisionsmöglichkeiten berechnen, desto höher die Qualität der Vorhersagen. Daraus
ergibt sich die Anforderung an den Simulator, dass er diese Daten in Zeitintervallen, die klein genug sind, zur Verfügung stellt. Der Fahrerassistent andererseits
muss in der Lage sein die Daten sehr oft auszuwerten. Dazu muss der Assistent
zwei Vorausetzungen erfüllen:
1. Die Ontologie muss schnell neue Instanzen aus den aktuellen Daten kreieren,
alte löschen und auf Anfragen schnell antworten können.
2. Die Berechnung der Kollisionsgefahr muss für eine große Anzahl von Fahrzeugen schnell erfolgen.
Um die erste Voraussetzung zu erfüllen, darf die Ontologie nicht zu komplex sein.
Generell lässt sich sagen, dass komplexere Ontologien aufwendigere Verfahren beim
Reasoning erfordern, auch exponentielle Laufzeiten sind möglich. Dies muss, zumindest bei größeren Ontologien, auf jeden Fall verhindert werden, wenn Anfragen
in angemessener Zeit bearbeitet werden sollen. Zur Erfüllung der zweiten Voraussetzung benötigt man ein schnelles Verfahren zur Kollisionsberechnung, das effizient implementiert werden kann.
Damit es möglich ist aus dem Fahrzeugtyp auf die Maße eines Fahrzeuges, also
die Länge und Breite, zu schließen, muss der Fahrzeugtyp bekannt sein. Enweder ist
es also erforderlich alle Fahrzeugtypen direkt in der Ontologie zu erfassen, oder es
muss möglich sein andere Ontologien zu importieren, in denen weitere Fahrzeugtypen beschrieben werden. Die zweite Variante ist der ersten bei weitem vorzuziehen,
da somit die Daten von Herstellern, so sie als Ontologien vorliegen, ohne großen
Aufwand verwendet werden können. Somit ist eine weitere Anforderung an den
Fahrerassistenten, dass er den Import externer Ontologien ermöglicht.
Zusammenfassend lässt sich also feststellen, dass dieses Szenario präzise und
ständig aktuelle Fahrzeugdaten benötigt, die dem Fahrerassistenten die Berechnung der Kollisionsgefahr ermöglichen. Diese Berechnungen müssen sehr häufig,
und damit auch sehr schnell erfolgen. Somit muss auch die Ontologie in der Lage
sein schnell auf Anfragen zu antworten und Aktualisierungen ihrer Daten, also
Instanzen, durchzuführen. Zu hohe Komplexität in der Kontextmodellierung ist
hier kontraproduktiv. Um die richtigen Fahrzeugmaße zu kennen, müssen externe
Ontologien importiert werden können.
42
3.3 Ontologie und Regelsatz
In diesem Abschnitt wird die Ontologie, die dem Fahrerassistenten in diesem Szenario zur Beschreibung der Kontextinformationen dient, und der dazugehörige Satz
von Regeln erläutert.
3.3.1 Grundsätzliches und Aufbau
Die Ontologie dieses Szenarios ist relativ einfach gehalten. Sie soll sich auf das
Wesentliche beschränken. Grund für diese Entscheidung ist die Tatsache, dass
einfache Ontologien schneller zu verarbeiten sind.
In dieser Ontologie werden nur Fahrzeuge modelliert. Als Modellierungssprache
dient OWL, genauer die Sprache OWL DL. Somit stehen relativ schnelle Reasoner zur Verfügung, bei Bedarf können auch externe Reasoner verwendet werden.
OWL Full wäre zwar mächtiger, aber eben auch langsamer bei der Verarbeitung,
es könnten sogar unentscheidbare Probleme beim Reasoning auftreten. Somit ist es
sinnvoll sich auf OWL DL zu beschränken, da es für diese Modellierung mächtig
genug ist. OWL Lite auf der anderen Seite hätte zwar noch schnellere Reasoner, ist aber nicht mächtig genug. Problematisch ist, dass die Verwendung des
owl:disjointWith - Konstruktors in OWL Lite nicht erlaubt ist. Somit ist es
zum Beispiel unmöglich festzulegen, dass ein Motorrad nicht gleichzeitig auch ein
LKW, oder das eigene Fahrzeug kein anderer Verkehrsteilnehmer sein kann.
Die Ontologie enthält eine Unterscheidung der Verkehrsteilnehmer in das eigene Fahrzeug und andere Fahrzeuge. Bei Fahrzeugen werden mehrere Fahrzeugtypen unterschieden. Verbunden sind diese beiden Konzepte durch die Festlegung, dass sowohl das eigene als auch die anderen Fahrzeuge vom Typ Fahrzeug
sind. Die wichtigsten Eigenschaften von Fahrzeugen, also zum Beispiel Positions-,
Richtungs- und Geschwindigkeitswerte werden als Properties des Typs Fahrzeug
modelliert. Die Möglichkeit des Imports von Herstellerdaten wird durch den Import
einer einfachen Beispielontologie gezeigt. Zu der in OWL beschriebenen Ontologie
gehört auch noch ein Satz von Regeln, der sowohl den in der Ontologie definierten
Standardfahrzeugtypen Werte zuordnet, als auch die Abbildung der importierten
Beispielontologie auf die Fahrzeugontologie beschreibt.
3.3.2 Fahrzeugontologie
In diesem Abschnitt wird die Fahrzeugontologie genauer beschrieben. Zur besseren
Übersichtlichkeit wird sie in drei Bestandteile zerlegt:
1. Die Klasse Fahrzeug mit den dazugehörigen Properties/Eigenschaften
2. Die Definition der einzelnen Fahrzeugtypen
3. Die Klasse Verkehrsteilnehmer
43
Die komplette Ontologie als OWL-Datei findet sich auf der beiliegenden CD. Zuerst
wird die Klasse Fahrzeug und die ihr zugeordneten Eigenschaften betrachtet. Dann
wird auf die Definition der einzelnen Fahrzeugtypen kurz eingegangen. Zum Schluss
wird die Definition der Verkehrsteilnehmer beschrieben.
Fahrzeug mit Eigenschaften
Die Eigenschaften eines Fahrzeuges, die in die Kollisionsberechnungen einfließen,
werden in der Klasse Fahrzeug als Properties modelliert. Alle diese Eigenschaften
sind Datatype Properties, sie bilden also die Klasse Fahrzeug auf Datentypen ab.
Bis auf die ID, welche ganzzahlig ist, werden alle anderen Properties durch Gleitkommazahlen beschrieben. Abbildung 3.1 stellt die Klasse Fahrzeug und alle ihr
zugehörigen Eigenschaften dar.
Abbildung 3.1: Die Properties des Klasse Fahrzeug
44
Die einzelnen Properties sind:
1. Eine eindeutige Fahrzeug ID. Sie wird zur Identifikation der Fahrzeuge benötigt.
2. Die Länge und Breite des Fahrzeugs in Metern.
3. Die Zeit in Sekunden. Es wird der Zeitpunkt, an dem die Fahrzeugdaten
gemessen wurden, angegeben.
4. Die maximale Beschleunigung, Geschwindigkeit und Bremsbeschleunigung
in ms beziehungsweise sm2 . Aus der maximalen Beschleunigung lässt sich zum
Beispiel berechnen, ob ein stehendes Auto gefahrlos beschleunigen kann.
5. Die aktuellen Positionsdaten als x- und y-Werte eines kartesischen Koordinatensystems, ebenfalls in der Einheit Meter. Der Grund für die Wahl von kartesischen Koordinaten liegt in der Kollisionsberechnung. Für letztere sind kartesischen Koordinaten notwendig, es macht also Sinn die Position so zu modellieren. Bei einer tatsächlichen Anwendung des Fahrerassistenten würden
die Positionswerte zwar als GPS-Daten vorliegen, müssten aber spätestens
für die Kollisionsvorhersage in x- und y-Werte umgerechnet werden. Da der
Verkehrssimulator ebenfalls kartesische Koordinaten liefert, macht es Sinn
die Position auch so zu modellieren. Ansonsten müssten die kartesischen Koordinaten des Simulators in GPS-Daten für das Modell umgerechnet werden
und dann für die Kollisionsberechnungen wieder in kartesische Koordinaten
zurück transformiert werden.
6. Die Richtung wird als der Winkel zwischen y-Achse und dem Fahrzeug angegeben. Ein sich auf der y-Achse in positiver Richtung bewegendes Fahrzeug
hat also den Richtungswinkel 0◦ , ein sich in Richtung der negativen x-Achse
bewegendes den Richtungswinkel 270◦ .
7. Die aktuelle Geschwindigkeit in ms . Das Fahrzeug bewegt sich zum angegebenen Zeitpunkt mit dieser Geschwindigkeit in die gegebene Richtung. Seitliche
Bewegungen sind nicht möglich, Rückwärtsbewegung kann durch negative
Geschwindigkeit dargestellt werden.
8. Die aktuelle Beschleunigung in sm2 . Hier ist der Beschleunigungswert, der sich
sowohl aus dem Beschleunigen des Autos durch das Betätigen des Gaspedals,
als auch durch Abbremsen ergibt, gemeint. Durch die Einbeziehung der aktuellen Beschleunigung lässt sich die Qualität der Unfallvorhersage gegenüber
einer auf der reinen Geschwindigkeit basierenden Vorhersage wesentlich verbessern. Die Richtung der Beschleunigung ist dieselbe wie die Richtung der
Geschwindigkeit. Positive Werte beschleunigen ein vorwärts fahrendes Auto,
negative hingegen bremsen es ab.
45
Alle diese Properties sind sowohl vom Typ owl:DatatypeProperty, als auch vom
Typ owl:FunctionalProperty. Der Typ owl:DatatypeProperty bedeutet, dass
die Wertemenge der Properties vordefinierte Datentypen und keine Objekte sind,
owl:FunctionalProperty dass jeder Instanz der Definitionsmenge maximal ein
Wert der Wertemenge zugeordnet wird. Die Kardinalität der Properties ist also
entweder null oder eins. Somit kann ein Fahrzeug zum Beispiel entweder keine
Geschwindigkeit haben, was als unbekannte Geschwindigkeit interpretiert wird,
oder genau eine, nicht aber zwei oder drei.
Fahrzeugtypen
Zur Beschreibung von Fahrzeugen, genauer gesagt Kraftfahrzeugen, wird ein einfaches Modell der Fahrzeugtypen erstellt. Abbildung 3.2 zeigt die Klassenhierarchie
dieser Fahrzeugtypen.
Abbildung 3.2: Die Klassenhierarchie der Fahrzeugtypen
Die Klasse Fahrzeug wird in vier Unterklassen eingeteilt. Dies sind die Klassen
PKW, LKW, Bus und Motorrad. Natürlich wären noch weitere Fahrzeugtypen denkbar. Als Beispiele seien hier Kleintransporter oder Wohnmobile genannt. Weitere
oder detailliertere Fahrzeugtypen ändern aber nichts am prinzipiellen Aufbau oder
der Funktionsweise des Fahrerassistenten. Aus diesem Grund beschränkt sich das
Modell auf diese vier Klassen, es wird also schlicht und damit auch übersichtlich
gehalten.
46
Des Weiteren wird definiert, dass die Klasse Fahrzeug sich aus ihren Unterklassen
zusammensetzt. Somit muss jedes Fahrzeug entweder ein PKW, ein LKW, ein Bus
oder ein Motorrad sein.
Zwischen den vier Unterklassen werden keine Überschneidungen zugelassen, Motorräder können also keine Busse sein und umgekehrt. Fahrzeuge müssen folglich
genau einen der vier möglichen Typen haben.
Bei jeder der vier Unterklassen ist ein Standardvertreter definiert. Die Standardfahrzeuge haben eine vorgegebene Länge, Breite, Maximalgeschwindigkeit, maximale Bremsbeschleunigung und eine Maximalbeschleunigung. Diese Werte werden
allerdings nicht in der OWL-Datei festgelegt, sonder in dem dazugehörigen externen Regelsatz, der in Abschnitt 3.3.4 genauer beschrieben wird. Ebenso gibt
es den Simulator_Car, der bei der Verwendung des Verkehrssimulators VIS SIM
zum Einsatz kommt.
An dieser Stelle der Ontologie ist es möglich weitere Fahrzeuge zu definieren, also
zum Beispiel die unterschiedlichen PKWs der einzelnen Hersteller und ihnen über
den Regelsatz die korrekten Werte zuzuordnen, wie es mit den Standardfahrzeugen
und dem Simulator_Car gemacht wird.
Die Modellierung der Fahrzeugtypen ist einfach gehalten, kann aber sehr leicht
erweitert werden und so den Bedürfnissen nach detaillierten Angaben zu einzelnen
Fahrzeugen angepasst werden. Zu beachten ist, dass die konkreten Fahrzeugwerte
in einem externen Regelsatz festgelegt sind. Dieser muss bei einer Erweiterung
ebenfalls angepasst und mit den zusätzlichen Daten versehen werden.
Verkehrsteilnehmer
Im Fahrzeugmodell wird zwischen Fahrzeugen und Verkehrsteilnehmern unterschieden. Somit ist es möglich andere Verkehrsteilnehmer später ohne größere
Schwierigkeiten in das Modell zu integrieren. Das Modell definiert zwei Arten von
Verkehrsteilnehmern, wie aus Abbildung 3.3, die die Modellierung der Verkehrsteilnehmer zeigt, ersichtlich ist:
1. Das eigene Fahrzeug
2. Andere Fahrzeuge
Beide Arten von Verkehrsteilnehmern sind als Unterklassen der allgemeinen Klasse
Verkehrsteilnehmer definiert. Anders als im Falle der Fahrzeugtypen sind hier
auch weitere Arten von Verkehrsteilnehmern erlaubt, die Klasse ist also nicht als
Vereinigung der beiden Unterklassen definiert.
Die Klassen Eigenes_Fahrzeug und Andere_Fahrzeuge sind disjunkt, es wird
strikt zwischen dem eigenen und allen anderen Fahrzeugen unterschieden. Diese
Unterscheidung erleichtert die Anfragen des Fahrerassistenten an die Fahrzeugontologie, da bei den Kollisionsberechnungen nur die möglichen Unfälle des eigenen Fahrzeuges von Interesse sind und nicht die der anderen Fahrzeuge. Mögliche
Unfälle zwischen den anderen Verkehrsteilnehmern können zwar auch dem eigenen
47
Abbildung 3.3: Die Modellierung der Verkehrsteilnehmer
Fahrzeug gefährlich werden, allerdings steigt der Rechenaufwand bei der Beachtung aller möglichen Unfälle quadratisch zur Anzahl der Fahrzeuge. Dieser potentiell sehr hohe Aufwand macht eine Beschränkung auf das eigene Fahrzeug sinnvoll.
Sowohl die Klasse Eigenes_Fahrzeug als auch die Klasse Andere_Fahrzeuge
sind als Unterklassen von Fahrzeug definiert. Somit erben sie die in der Klasse
Fahrzeug festgelegten Eigenschaften. Die Klasse Eigenes_Fahrzeug besitzt außerdem noch zwei weitere Properties, kollisions_partner und kollisions_zeit.
Diese stellen das Ergebnis der Kollisionsberechnungen dar.
kollisions_partner ist eine owl:Objectproperty, das heißt sie bildet die Instanzen einer Klasse auf die einer anderen Klasse ab. In diesem Fall verknüpft sie
das eigene Fahrzeug mit einem Fahrzeug vom Typ Andere_Fahrzeuge. Die Property kollisions_partner ist funktional, kann also, wenn keine Gefahr besteht,
auch auf kein Fahrzeug verweisen, ansonsten liefert sie nur das Fahrzeug, mit dem
es zuerst zum Unfall kommt.
Die kollisions_zeit gibt an in wieviel Sekunden es zum Unfall mit dem
kollisions_partner kommt. Somit ist sie als funktionale owl:Datatypeproperty
definiert, die Sekunden werden als Gleitkommazahl geschrieben, da eine Angabe
in ganzen Zahlen zu unpräzise wäre.
48
Die Modellierung weiterer Verkehrsteilnehmer ist leicht möglich, sie können
ähnlich wie die Klasse Andere_Fahrzeuge dargestellt werden, also als eigene Unterklasse der Verkehrsteilnehmer. Außerdem können Fußgänger, Fahrradfahrer,
Rollerblader, etc in einer eigenen Klassenhierarchie neben der Klasse Fahrzeug
formalisiert werden, von welcher die neuen Verkehrsteilnehmer ihre Eigenschaften
erben. Diese Möglichkeiten zum Ausbau der Ontologie werden in Abschnitt 3.6.3
genauer untersucht.
3.3.3 Importbeispiel
Spezielle Fahrzeugtypen können nicht nur in der Fahrzeughierarchie hinzugefügt
werden, es ist auch möglich externe Ontologien zu importieren. Somit können
schon vorhandene externe Informationen, die im richtigen Format vorliegen, in die
Fahrzeugontologie integriert werden. Zur Demonstration des Prinzips dient die in
import-beispiel.owl beschriebene und in Abbildung 3.4 dargestellte Ontologie.
Hier wird ein sehr einfaches Fahrzeugmodell formalisiert. Die Klasse Vehicle
hat verschiedene Properties und die beiden Unterklassen Car und Truck. Die Properties sind im einzelnen die Länge length, die Breite width, die Maximalgeschwindigkeit topspeed, die Bremsbeschleunigung breakforce, die Maximalbeschleunigung acceleration und die Anzahl an Türen doors. Somit stehen die
unveränderlichen Fahrzeugeigenschaften, die in der Fahrzeugontologie beschrieben sind, auch hier zur Verfügung. Zusätzlich wird noch eine weitere Information
modelliert, die bei der Kollisionsberechnung aber keine Rolle spielt, nämlich die
Anzahl der Türen.
Im Unterschied zur Fahrzeugontologie gibt es in dieser Ontologie auch zwei Instanzen der Fahrzeugklassen, den Simulator-Car und den Simulator-Truck. Beide sind mit konkreten Werten instanziiert, es ist also zum Beispiel möglich aus der
Importbeispiel - Ontologie die Länge des Simulator-Car herauszulesen.
Damit diese in der importierten Ontologie vorhandenen Informationen auch ausgewertet werden können, benötigt man Abbildungsvorschriften, die festlegen, welche Klassen oder Properties in den einzelnen Ontologien einander entsprechen. In
diesem Fall also dass unter anderem die length eines Vehicle in der importierten
Ontologie der laenge eines Fahrzeugs in der importierenden Ontologie entspricht.
Dies kann entweder in der Ontologie selbst oder in einem externen Regelsatz geschehen. In dieser Arbeit wird der zweite Ansatz gewählt, um die eigentliche Fahrzeugontologie so einfach wie möglich zu halten. Der externe Regelsatz wird in
Abschnitt 3.3.4 genauer erläutert. Hier finden sich auch Beispielregeln.
Externe Ontologien können also in die Fahrzeugontologie eingebunden werden
und weitere Informationen zu einzelnen Fahrzeugen liefern. Hierzu müssen nur
die benötigten Konzepte und Eigenschaften aufeinander abgebildet werden, überflüssige Informationen kann man ignorieren. Diese Abbildung kann unter anderem
mittels eines externen Regelsatzes geschehen, wie er im nächsten Abschnitt beschrieben wird. Hier finden sich auch die erwähnten Abbildungsvorschriften.
49
Abbildung 3.4: Die Importbeispiel - Ontologie
3.3.4 Regelsatz
Jedem ontologischen Modell wird im Framework Jena ein Reasoner zugeordnet.
Mit Hilfe dieses Reasoners kann zum Beispiel die transitive Hülle der Klassenhierarchie gebildet werden, oder auch das Modell auf Inkonsistenzen überprüft werden.
In Jena stehen sowohl Reasoner für die einzelnen OWL-Dialekte, RDF Schema
usw, als auch ein generischer, regelbasierter Reasoner zur Verfügung. Dieser kann
zum Beispiel mit den vorgegebenen Regelsätzen für OWL versehen werden, oder
auch zusätzlich mit eigenen, benutzerdefinierten Regeln. Diese werden entweder
direkt im Programm formalisiert, oder in einer externen Datei abgespeichert. In
dieser Arbeit wird der zweite Weg gewählt. Es wird also aus dem in OWL beschriebenen Modell mit Hilfe des generischen Reasoners, der um in einer externen
Datei definierte Regeln erweitert wird, ein neues Modell abgeleitet. Mit Hilfe die-
50
ser benutzerdefinierten Regeln können weitere Zusammenhänge, die nicht in der
OWL-Ontologie erfasst wurden, modelliert werden.
In diesem Abschnitt wird nur der verwendete Regelsatz erläutert. Die Implementierung der Ontologie und ihre Verknüpfung mit einem Reasoner wird in Abschnitt
3.5 dargelegt. Der Regelsatz ist in der Datei car_no_streets.rules gespeichert.
Sie findet sich auf der beiliegenden CD. Mit ihrer Hilfe wird die Importbeispiel Ontologie auf die Fahrzeugontologie abgebildet und es werden den Standard- und
Simulatorfahrzeugen der Fahrzeugontologie feste Werte bezüglich ihrer Eigenschaften zugeordnet.
Es wäre auch möglich, die Zusammenhänge zwischen der Fahrzeugontologie
und der zu importierenden Ontologie in der Fahrzeugontologie selbst zu definieren. Ein externer Regelsatz hat aber den Vorteil, dass die Fahrzeugontologie
selbst nicht geändert werden muss. Die Ontologien und ihre Abbildungsregeln
sind also strikt getrennt. Vor allem beim Import vieler externer Ontologien dient
dies der Übersichtlichkeit. Der Grund für die Implementierung der Zuordnung fester Werte für die einzelnen Fahrzeugtypen in externen Regeln ist auch hier die
Übersichtlichkeit. Die Zuordnung könnte aber genauso gut in der Ontologie selbst
passieren. Die Regeln zur Zuordnung der Werte haben folgende Form:
@prefix kontext: <http://stud.tejp.de/georg/onto/fahrzeug.owl#>.
# Simulator_PKW
[rule1:
( ?c owl:sameAs ?o ) ( ?o rdf:type kontext:Simulator_PKW )
->
( ?c kontext:laenge 4.0 ),
( ?c kontext:breite 1.3 ),
( ?c kontext:beschleunigung_maximal 4.0 ),
( ?c kontext:geschwindigkeit_maximal 16.0 ),
( ?c kontext:bremsbeschleunigung_maximal 10.0 )
]
Diese Regel erlaubt es Fahrzeuge vom Typ Simulator_PKW mit ihren konstanten
Eigenschaften versehen, also Länge, Breite, maximale Beschleunigung, Geschwindigkeit und Bremsbeschleunigung. Es handelt sich hier um eine Vorwärtsregel.
Wann immer die Voraussetzung erfüllt wird, führt der Reasoner den zweiten Teil
der Regel aus. Die Voraussetzung besteht aus zwei Bedingungen:
1. ( ?c owl:sameAs ?o )
Es existiert ein ?c, das im Modell mit Hilfe des Konstruktors owl:sameAs
als gleich mit einem ?o gesetzt wird.
2. ( ?o rdf:type kontext:Simulator_PKW )
Dieses ?o ist vom Typ Simulator_PKW, der in der Ontologie mit der URI
kontext definiert ist, also der Fahrzeugontologie.
51
Damit die Regel angewendet wird, muss also das Fahrzeug mit Hilfe des Konstruktors owl:sameAs als gleich mit einem anderen Fahrzeug vom Typ Simulator_PKW
in der Ontologie beschrieben werden. Wenn diese beiden Bedingungen erfüllt sind,
dann kommen die folgenden fünf Regeln zum Einsatz:
1. ( ?c kontext:laenge 4.0 )
Die Länge des Fahrzeuges wird auf vier Meter gesetzt.
2. ( ?c kontext:breite 1.3 )
Die Breite des Fahrzeuges beträgt 1,3 Meter.
3. ( ?c kontext:beschleunigung_maximal 4.0 )
Das Fahrzeug bekommt eine Maximalbeschleunigung von 4 sm2 zugewiesen.
4. ( ?c kontext:geschwindigkeit_maximal 16.0 )
Das Fahrzeug erhält die Maximalgeschwindigkeit von 16 ms .
5. ( ?c kontext:bremsbeschleunigung_maximal 10.0 )
Die maximale Bremsbeschleunigung beträgt 10 sm2 .
Diese Werte werden dem Objekt ?c zugeordnet, nicht dem Simulator_PKW oder
dem Objekt ?o vom Typ Simulator_PKW. Sinnvollerweise sollte es sich bei ?c um
eine Instanz des Typs Fahrzeug handeln. Ähnliche Regeln gibt es für die Standardfahrzeugtypen, also den Standard_PKW, den Standard_LKW, den Standard_Bus
und das Standard_Motorrad. Soll die Ontologie um weitere Fahrzeugtypen erweitert werden, dann müssen natürlich auch die entsprechenden Regeln zu den
car_no_streets.rules hinzugefügt werden. Im Regelsatz werden aber nicht nur
den Fahrzeugtypen konkrete Werte zugeordnet, sondern es wird auch die Verbindung mit der importierten Beispielontologie hergestellt. Dies geschieht wieder mit
jeweils einer Regel pro Fahrzeugtyp. Hier die Regel für den Simulator-Car:
@prefix ex: <http://stud.tejp.de/georg/onto/import-beispiel.owl#>.
# Simulator-Car
[rule6:
( ?c owl:sameAs ?o ) equal( ?o, ex:Simulator-Car )
( ?o ex:length ?l ) ( ?o ex:width ?w )
( ?o ex:acceleration ?a ) ( ?o ex:topspeed ?s )
( ?o ex:breakforce ?b )
->
( ?c kontext:laenge ?l ),
( ?c kontext:breite ?w ),
( ?c kontext:beschleunigung_maximal ?a ),
( ?c kontext:geschwindigkeit_maximal ?s ),
( ?c kontext:bremsbeschleunigung_maximal ?b )
]
52
Diese Regel unterscheidet sich leicht von der ersten, da der Simulator-Car in der
Beispielontologie als Instanz mit allen benötigten Werten schon vorliegt, während
das beim Simulator_PKW nicht der Fall ist. Hier handelt es sich um eine Klasse,
keine Instanz. Grund für diese unterschiedlichen Ansätze ist es zu zeigen, dass
beide möglich sind und dasselbe Ergebnis liefern, nämlich eine Fahrzeuginstanz
mit den richtigen Werten auszustatten.
In den Vorausetzungen wird wieder mit ( ?c owl:sameAs ?o ) die Gleichheit von ?c und ?o gefordert. Diesmal muss ?o allerdings identisch mit dem
Simulator-Car sein, durch den Konstruktor owl:sameAs definierte Gleichheit
genügt nicht (equal( ?o, ex:Simulator-Car )). Die restlichen Voraussetzungen, wie zum Beispiel ( ?o ex:length ?l ) liefern die Werte der Properties der
Instanz Simulator-Car, hier also die Länge ?l.
Im zweiten Teil der Regel werden dann die Werte der Instanz Simulator-Car
auf die Werte von ?c abgebildet. ( ?c kontext:laenge ?l ) weist der Property
laenge der Instanz ?c den Wert ?l zu, welcher in den Vorausetzungen als length
des Simulator-Car festgelegt wurde.
Wenn also ein Fahrzeug im Modell mit dem Simulator-Car gleichgesetzt wird,
dann weist diese Regel dem Fahrzeug die Werte des Simulator-Car zu. Somit kann
auf die in der importierten Ontologie enthaltenen Informationen zu verschiedenen
Arten von Fahrzeugen zugegriffen werden.
Zu beachten ist, dass nicht für alle Eigenschaften Abbildungen benötigt werden.
Die property doors wird einfach ignoriert, da es in der Fahrzeugontologie keine
Entsprechung gibt. Somit wird nur der Teil der Beispielontologie verwendet, der
von Interesse ist. Dies ermöglicht effektiven Import von komplexen Ontologien, die
eventuell viele nicht benötigte Details enthalten.
Abschließend muss noch erwähnt werden, dass dieser Regelsatz mit den Instanzen der Fahrzeugontologie arbeitet. Er muss also nach jeder Änderung der Instanzmenge wieder auf die Ontologie angewendet werden.
3.4 Kollisionsberechnung
In diesem Abschnitt wird der mathematische Ansatz zur eigentlichen Kollisionsberechnung erläutert. Ziel der Kollisionsberechnung ist es herauszufinden ob zwei
Fahrzeuge kollidieren, und wenn ja, wann. Die zur Verfügung stehenden Daten
sind die Länge und Breite beider Fahrzeuge, ihre Positionen, Geschwindigkeiten,
die Beschleunigungswerte und die Richtung, in die sie sich bewegen. Das Ergebnis
ist die Anzahl der Sekunden, in der es zur Kollision kommt, beziehungsweise ein
negativer Wert, wenn das nicht der Fall ist.
Die Vorschriften zur Kollisionsberechnung werden nicht in der Ontologie selbst
modelliert, auch wenn das erstrebenswert erscheint. Um vernünftig und präzise
abschätzen zu können, ob es zu einer Kollision zwischen zwei Fahrzeugen kommt,
müssen entweder die Positionen, der Abstand oder die Geschwindigkeiten der Fahr-
53
zeuge in irgendeiner Weise miteinander verglichen werden. Zum Vergleichen von
Abständen muss es zumindest möglich sein, einen Ausdruck der Form Abstand
< Minimalabstand zu modellieren. Für Geschwindigkeiten und Positionen gilt
Ähnliches. Des Weiteren ist es nötig, dass Abstände (bzw Geschwindigkeiten oder
Positionen) mit konkreten Werten modelliert werden, also als konkrete Datentypen, zum Beispiel Zahlen oder Zeichenketten, da es sonst unmöglich ist, quantitative Vergleiche vorzunehmen. Will man aber Prädikate, die mehr als eine Stelle
haben, also zum Beispiel <, auf konkrete Datentypen anwenden, dann kann dies
bei Beschreibungslogiken oder OWL zu Unentscheidbarkeit führen [SS04].
Vorschriften zur Kollisionsberechnung, die mit konkreten Zahlenwerten oder Zeichenketten arbeiten und sich Vergleichen oder anderer mehrstelliger Prädikate bedienen, können also nicht in OWL modelliert werden, ohne dass dies zu potentiell
unentscheidbaren Problemen führt. Wenn aber die Kollisionsberechnung ein potentiell unentscheidbares Problem ist, dann sind Fehler in der Vorhersage nicht zu
vermeiden. Somit ist die Modellierung der Vorschriften in der OWL-Ontologie ein
ungeeignetes Verfahren zur Kollisionsberechnung.
3.4.1 Fahrzeuge als sich bewegende Rechtecke
Mit den gegebenen Daten der beiden Fahrzeuge können sie als sich in der Ebene bewegende Rechtecke modelliert werden. Wenn es zu einem Zeitpunkt zu einer Überschneidung der beiden Flächen kommt, dann kollidieren sie. Die Ausdehnung der Flächen entspricht der Fahrzeugfläche zuzüglich eines gegebenenfalls
erwünschten Sicherheitsabstandes. Dieser kann natürlich nach vorne und hinten
einerseits und zu den Seiten andererseits unterschiedlich gewählt werden.
Punktförmige Objekte
Will man den Zeitpunkt der Überschneidung sich bewegender Flächen berechnen, ist es sinnvoll erst einmal den einfacheren Fall der punktförmigen Objekte
zu betrachten. Bewegt sich ein Objekt mit Geschwindigkeit v und wird mit a beschleunigt, dann kann aus der Zeit t die zurückgelegte Strecke berechnet werden:
a
s = t · v + t2 ·
2
Mit Hilfe dieser Formel lässt sich die Bahn eines punktförmigen Objekts in einer mehrdimensionalen Ebene beschreiben. Geschwindigkeit und Beschleunigung
werden als Vektoren erfasst, wobei die beiden Vektoren entweder die gleiche oder
die entgegengesetzte Richtung haben (~a = n ∗ ~v ). Der Ortsvektor bei t = 0 ist
~y . Somit ergibt sich für den Bahnvektor ~s(t) in Abhängigkeit der Zeit folgende
Geradengleichung:
1
~s (t) = ~y + t · ~v + t2 · ~a
(3.1)
2
Will man wissen, ob sich zwei Objekte treffen, dann berechnet man den Schnittpunkt der beiden Bahnen und überprüft, ob sich die Objekte zur gleichen Zeit
54
im Schnittpunkt befinden (t1 = t2 ). Hierbei sind Sonderfälle wie parallele, oder
im mehr als zweidimensionalen Raum auch windschiefe Geraden, und identische
Bahnen zu beachten.
Ruhende Rechtecke
Die Fläche eines Rechtecks wird mit einem Ungleichungssystem beschrieben. Wenn
|~l| die Länge und |~b| die Breite des Rechtecks ist, dann ergibt sich bei einem
Mittelpunkt ~y folgende Gleichung:
~ = ~y + m · ~l + n · ~b
A
(3.2)
Wenn ~l auf die Länge und ~b auf die Breite des Rechtecks genormt sind, müssen für
m und n folgende Ungleichungen gelten:
−0.5 ≤ m ≤ 0.5
−0.5 ≤ n ≤ 0.5
(3.3)
(3.4)
Die Bedingungen für m und n und die Gleichung (3.2) beschreiben also als Ungleichungssystem die Fläche eines ruhenden Rechtecks.
Sich bewegende Rechtecke
Sich bewegende Rechtecke können als ruhende Rechtecke, deren Mittelpunkte sich
bewegen, formalisiert werden. Aus den Gleichungen (3.1) und (3.2) lässt sich also
eine Gleichung zur Beschreibung der Bahn eines Rechtecks in Abhängigkeit der
Zeit ableiten:
1
~s (t) = ~y + t · ~v + t2 · ~a + m · ~l + n · ~b
(3.5)
2
Natürlich müssen auch hier die Ungleichungen (3.3) und (3.4) erfüllt sein. Aus
der Gleichung (3.5) und den beiden Ungleichungen ergibt sich wieder ein Ungleichungssystem, das die Fläche des Rechtecks in Abhängigkeit der Zeit beschreibt.
Schnitt sich bewegender Rechtecke
Eine Kollision zweier Rechtecke findet genau dann statt, wenn sich ihre Flächen
überschneiden. Mindestens ein Punkt muss also zur gleichen Zeit in beiden Rechtecken liegen. Die Rechtecksgleichungen sind nach (3.5):
1
s~1 (t) = y~1 + t · v~1 + t2 · a~1 + m1 · l~1 + n1 · b~1
2
1
s~2 (t) = y~2 + t · v~2 + t2 · a~2 + m2 · l~2 + n2 · b~2
2
Das Gleichsetzen beziehungsweise die Subtraktion der beiden Gleichungen zur Bestimmung identischer Punkte liefert dann:
~0 = y~1 − y~2 + t · (v~1 − v~2 ) + t2 · 1 (a~1 − a~2 ) + m1 · l~1 + n1 · b~1 − m2 · l~2 − n2 · b~2 (3.6)
2
55
Spaltet man diese Gleichung in die zwei entsprechenden Ungleichungen ≤ 0 und
≥ 0 auf, dann lässt sich mit den Ungleichungen (3.3) und (3.4) ein Ungleichungssystem für den zweidimensionalen Raum aufstellen. Das Problem ist, dass in diesem
Ungleichungssystem fünf Unbekannte vorkommen, nämlich m1 , m2 , n1 , n2 und t,
und eine davon, die Zeit t, nicht linear ist. Nichtlineare Ungleichungssysteme sind
aber wesentlich schwieriger zu lösen als lineare. Das Ziel ist es, die anderen vier
Unbekannten zu eliminieren und dann das vereinfachte System, in dem nur noch
die Zeit unbekannt ist, zu lösen. Die allgemeine Form der n-ten Ungleichung, des
Systems, das sich aus (3.3), (3.4) und (3.6) ergibt, ist:
yn + vn t + an t2 + m1 l1n + n1 b1n + m2 l2n + n2 b2n ≤ cn
(3.7)
Wobei yn sich aus den Ortsvektoren ergibt, vn aus der Geschwindigkeit, usw.
Natürlich können diese Faktoren auch den Wert Null annehmen. Ersetzt man die
zu eliminierenden Unbekannten m1 , m2 , n1 und n2 durch die Variablen x4 bis x7
und erweitert die ersten drei Summanden mit den Variablen x1 bis x3 , welche den
Wert Eins haben, dann ergibt sich:
yn x1 + vn tx2 + an t2 x3 + l1n x4 + b1n x5 + l2n x6 + b2n x7 ≤ cn
(3.8)
Wird nun die Zeit t als Konstante betrachtet, erhält man somit ein System linearer
Ungleichungen, in dem vier Variablen unbekannt, der Rest aber bekannt ist, da
x1 , x2 , x3 = 1 gilt. Bevor das resultierende lineare Ungleichungssystem formuliert
wird werden zur vereinfachten Darstellung folgende Konstanten definiert:
• yxd und yyd beschreiben die x- und die y-Komponente der Differenz der Mittelpunktsvektoren y~1 und y~2 .
• vxd und vyd sind die x- und die y-Komponente der Differenz der Geschwindigkeitssvektoren v~1 und v~2 multipliziert mit der Zeit t.
• axd und ayd sind die beiden Komponenten, die sich durch Subtraktion der Beschleunigungssvektoren a~21 und a~22 und einer Multiplikation mit dem Quadrat
der Zeit t2 ergeben.
• l1x , l2x , l1y , l2y , b1x , b2x , b1y und b2y beschreiben die x- und y-Komponenten
der Flächenvektoren l~1 , l~2 , b~1 und b~2 .
Wie schon erwähnt ist der Vorteil dieser Definitionen, dass das resultierende Ungleichungssystem für den Schnitt zweier sich in der zweidimensionalen Ebene bewegenden Flächen linear ist. Die quadratische unbekannte Variable t2 ist in den
Konstanten axd und ayd verborgen. Es ergibt sich also folgendes lineares Ungleichungssystem, wobei die letzten vier Spalten der Matritze, beziehungsweise die
Variablen x4 bis x7 , den Unbekannten m1 , m2 , n1 und n2 aus der Gleichung (3.6)
und den Ungleichungen (3.3) und (3.4) entsprechen:
56
























0
0
0
1
0
0
0
0
0
0
−1
0
0
0
0
0
0
0
1
0
0
0
0
0
0
−1
0
0
0
0
0
0
0
1
0
0
0
0
0
0
−1
0
0
0
0
0
0
0
1
0
0
0
0
0
0
−1
yxd
vxd
axd
l1x
b1x
l2x
b2x
−yxd −vxd −axd −l1x −b1x −l2x −b2x
yyd
vyd
ayd
l1y
b1y
l2y
b2y
−yyd −vyd −ayd −l1y −b1y −l2y −b2y



 


 
 
 
 
 
 
·
 
 
 
 
 













x1


x2  







.. 

≤
.  







x6  


x7




0.5
0.5
0.5
0.5
0.5
0.5
0.5
0.5
0
0
0
0
























(3.9)
Zusamenfassend lässt sich somit feststellen, dass es genau dann zur Kollision
zweier Flächen zum Zeitpunkt t kommt, wenn das lineare Ungleichungssystem
(3.9) für diesen Zeitpunkt t erfüllbar ist. Will man also wissen, ob zwei Flächen
miteinander kollidieren, dann muss man berechnen, ob es ein t gibt, das dieses
Ungleichungssystem erfüllt. Hierzu müssen die Unbekannten m1 , m2 , n1 und n2 ,
also x4 bis x7 , eliminiert werden. Das Ergebnis ist ein neues System quadratischer
Ungleichungen, in denen nur die Variable t unbekannt ist. Dieses System kann dann
auf Erfüllbarkeit getestet werden. Im nächsten Abschnitt wird die Elimination der
Unbekannten beschrieben, im darauf folgenden der Test auf die Erfüllbarkeit des
neuen Ungleichungssystems bezüglich t.
3.4.2 Die Fourier-Motzkin-Elimination
Die Elimination der Variablen x4 bis x7 im linearen Ungleichungssystem (3.9) wird
mit der sogenannten Fourier-Motzkin-Elimination, wie sie in [Gro04] beschrieben
ist, durchgeführt. Die Fourier-Motzkin-Elimination ermöglicht es, ein lineares Ungleichungssystem auf Erfüllbarkeit zu testen, beziehungsweise einzelne Variablen
zu eliminieren.
Der Algorithmus der Fourier-Motzkin-Elimination hat als Eingabeparameter das
Ungleichungssystem A~x ≤ ~b. Das Ungleichungssystem wird also durch eine (m, n)Matrix A, die Variablen ~x und den Vektor ~b beschrieben. In jedem Schritt wird eine
Spalte j der Matrix A eliminiert und das daraus resultierende Ungleichungssystem
D~x ≤ d~ aufgestellt. D ist die neue (r, n)-Matrix, d~ der Vektor. Der folgende Algorithmus zur Elimination der Spalte j der Matrix A ist im Wesentlichen [Gro04]
entnommen:
1. Schritt: Die Menge der Zeilenindizes M der Matrix A wird je nach Vorzeichen der Matrixelemente aij in drei Mengen eingeteilt:
Z := {i ∈ M | aij = 0}
57
N := {i ∈ M | aij ≤ 0}
P := {i ∈ M | aij ≥ 0}
2. Schritt: Die neue Indexmenge R der Matrix D wird bestimmt. Ihre Kardinalität r beträgt | Z ∪ (N × P ) |. Somit gilt R := {1, ..., r}. Die Bijektion P bildet
die Indexmenge R auf die Elemente der Zeilenindexmenge Z ∪ (N × P ) ab.
~
3. Schritt: Berechnung der neuen Matrix D und des Vektors d.
Für alle i = 1, 2, ... , r wird eine Fallunterscheidung durchgeführt:
1. Wenn p(i) ∈ Z, dann wird sowohl diese Zeile in die neue Matrix unverändert
übernommen, als auch das entsprechende Element des Vektors ~b. Di. steht
hier für die i-te Zeile der Matrix D.
Di. := Ap(i).
di := bp(i)
2. Wenn p(i) = (s, t), wobei (s, t) ∈ (N ∪ P ), dann erfolgt die Elimination durch
Subtraktion der Vielfachen der beiden Zeilen.
Di. := atj As. − asj At.
di := atj bs − asj bt
Da natürlich atj · asj − asj · atj = 0 gilt, ist auch das neue Element dij = 0.
Somit wurde die Spalte j gleich Null gesetzt, und damit auch die Variable xj
eliminiert.
Der Algorithmus der Fourier-Motzkin-Elimination eliminiert also eine Variable aus
einem linearen Ungleichungssystem. Die Erfüllbarkeit des Ungleichungssystems
wird dadurch nicht beeinflusst. Die Elimination geschieht durch Subtraktion aller mit den negativen Elementen multiplizierten Zeilen mit positivem Element in
der zu eliminierenden Spalte von allen mit den positiven Elementen multiplizierten Zeilen mit negativem Element in der zu eliminierenden Spalte. Zeilen, deren
Element schon Null ist, werden direkt übernommen. Somit kann die Zahl der neuen Ungleichungen stark anwachsen, besonders da auch redundante Gleichungen
produziert werden.
Hat das Ungleichungssystem m Ungleichungen und n zu eliminierenden Variablen, dann ergibt sich für die Fourier-Motzkin-Elimination eine Worst-Case Komn
plexität von O(m2 ). Sind alle Koeffizienten der zu eliminierenden Spalte ungleich
Null, wobei jeweils die Hälfte positiv und die Hälfte negativ ist, gilt für die Anzahl
der neu ermittelten Ungleichungen nach der Elimination einer Variable:
mneu
malt
=
2
58
2
Wenn malt hinreichend groß ist, ist folgende Näherung gültig:
mneu ≈ m2alt
Sollen n Variablen eliminiert werden, gilt mit dieser Näherung:
(21 )
n = 1 ⇒ m1 ≈ m20 = m0
(22 )
n = 2 ⇒ m2 ≈ m21 = m40 = m0
(23 )
n = 3 ⇒ m3 ≈ m22 = m80 = m0
Aus diesen Gleichungen kann man den allgemeinen Zusammenhang zwischen der
maximalen Zahl der produzierten Ungleichungen mn und der Zahl der zu eliminierenden Variablen n für ein Ungleichungssystem mit m0 Ungleichungen ableiten:
(2n )
mn ≈ m0
Somit ist die Worst-Case Komplexität der Fourier-Motzkin-Elimination O(m(2 ) ).
Betrachtet man das hier zu lösende Ungleichungssystem (3.9), das die Bedingungen für die Kollision zweier Fahrzeuge beschreibt, dann sieht man, dass es zwölf
Ungleichungen enthält. Vier seiner Variablen sollen eliminiert werden. Somit er4
geben sich im schlimmsten Fall geschätzte 12(2 ) = 1, 84... · 1017 Ungleichungen
nach der Elimination der vier Unbekannten aus (3.9), die für jeden potentiellen
Kollisionspartner zu lösen sind.
Empirische Werte liegen aber bei ungefähr 100 Ungleichungen. Dies lässt sich
darauf zurückführen, dass viele Elemente der Matrix des Ungleichungssystems
(3.9) den Wert Null haben und sich in jedem Schritt auch einige redundante Ungleichungen ergeben, die aus dem System entfernt werden können. Somit steigt
die Anzahl der Ungleichungen nicht so stark an, wie es die obige Worst-Case
Abschätzung befürchten lässt. Die Fourier-Motzkin-Elimination erweist sich unter diesen Umständen als praktikabel für den Einsatz in der Kollisionsberechnung.
n
3.4.3 Erfüllbarkeit und Lösung
Nachdem die unbekannten Variablen m1 , m2 , n1 und n2 beziehungsweise x4 bis
x7 mit Hilfe der Fourier-Motzkin-Elimination aus dem Ungleichungssystem (3.9)
entfernt wurden, ergibt sich ein neues Ungleichungssystem, das nur noch drei Variablen, dafür aber wesentlich mehr Ungleichungen hat1 . Dieses System muss zuerst
so umgeformt werden, dass die Zeit die einzige Unbekannte in ihm darstellt.
Umformung des Ungleichungssystems
Die einzelnen Ungleichungen des mit der Fourier-Motzkin-Elimination errechneten
Systems haben folgende Gestalt:
ax1 + bx2 + cx3 ≤ d
1
Tests ergeben Werte die in der Größenordnung von bis zu über 100 Ungleichungen liegen
59
(3.10)
• a ist aus Multiplikationen und Subtraktionen in der ersten Spalte von 3.9
entstanden und somit aus Vielfachen der Komponenten der Ortsvektoren y~1
und y~2 der Mittelpunkte der Rechtecke. Es ist nicht von der Zeit abhängig.
Da y~1 und y~2 in Gleichung (3.6) mit keiner Unbekannten multipliziert werden,
wurde bei der Formulierung von (3.9) x1 = 1 definiert.
• b ist das Ergebnis von Umformungen der Geschwindigkeitsvektoren. Es ist
ein Vielfaches der Zeit. Dank der Festlegung von x2 = 1 für (3.9) und mit
der Definition von b′ = bt gilt bx2 = b′ t.
• c ist aus den Beschleunigungsvektoren hervorgegangen. Es ist ein Vielfaches
des Quadrats der Zeit. Auch hier gilt x3 = 1, und somit folgt aus der Definition c′ = tc2 dass cx3 = c′ t2 .
• d ist eine einfache Zahl ohne Variable.
Somit lässt sich (3.10) auch als quadratische Ungleichung mit der Zeit als Variable
schreiben:
0 ≤ d − a − b′ t − c′ t2
(3.11)
Mit Hilfe der Fourier-Motzkin-Elimination kann also aus dem Ungleichungssystem
(3.9) ein neues System von Ungleichungen der Form (3.11) produziert werden, das
als einzige Unbekannte die Zeit enthält. Die Koeffizienten a, b′ , c′ und d enthalten
nur bekannte Werte wie die Geschwindigkeitsvektoren, die Beschleunigungsvektoren, die Positionen oder die Maße der beiden Fahrzeuge/Rechtecke.
Um den Zeitpunkt der Kollision zweier Rechtecke zu berechnen, muss das neue
System quadratischer Ungleichungen auf Erfüllbarkeit getestet, und dann das
kleinst mögliche t ≥ 0 bestimmt werden.
Test auf Erfüllbarkeit und Berechnung des Kollisionszeitpunkts
Damit es zu einer Kollision der Rechtecke kommt, müssen alle Ungleichungen des
Systems mindestens ein t ≥ 0 als Lösung haben. t < 0 bedeutet, dass es zu einer
Kollision in negativer Zeit kommt, ist also gleichbedeutend mit keiner Kollision.
Betrachtet man die Ungleichung (3.11), so sieht man, dass es, abhängig von den
Koeffizienten, für t unterschiedliche Lösungen geben kann.
1. Die Ungleichung ist für alle t unerfüllbar. Dies tritt zum Beispiel auf, wenn
d ≤ 0 und a, b′ , c′ = 0 gilt.
2. Die Ungleichung ist für alle t erfüllt. Ein Beispiel für diesen Fall ist durch die
Koeffizienten d ≥ 0 und a, b′ , c′ = 0 gegeben.
3. Es gibt genau eine Lösung t = x. Dies ist beispielsweise bei der Gleichung
0 ≤ −x2 + 2xt − t2 der Fall.
4. Die Lösungsmenge ist t ≥ x, also durch eine Konstante nach unten beschränkt. Dies gilt für 0 ≤ −x + t.
60
5. Als Lösungsmenge ergibt sich t ≤ x. Sie ist also durch eine obere Schranke
festgelegt und die Lösung der Ungleichung 0 ≤ x − t.
6. Die Lösungsmenge ist t ≤ x1 ∨ t ≥ x2 , liegt also jenseits einer unteren und
einer oberen Schranke. Ein Beispiel hierfür ist die Ungleichung
0 ≤ x1 x2 − t(x1 + x2 ) + t2 , wobei x1 ≤ x2 gilt.
7. Es ergibt sich die Lösungsmenge t ≥ x1 ∧ t ≤ x2 , die durch eine untere und
eine obere Schranke festgelegt wird. Dies ist zum Beispiel das Ergebnis der
Ungleichung 0 ≤ −x1 x2 + t(x1 + x2 ) − t2 , unter der Bedingung das x1 ≤ x2
gilt.
Die Lösung einer Ungleichung liefert also entweder, dass die Ungleichung für alle
t erfüllbar oder unerfüllbar ist, eine Bedingung der Form t ≤ x, t ≥ x oder t = x,
oder die konjunktive beziehungsweise disjunktive Verknüpfung von Bedingungen,
also zum Beispiel t ≤ x1 ∨ t ≥ x2 . Die Lösung ist also eine logische Aussage. Sie
kann sehr einfach aus der Ungleichung berechnet werden. Als Lösung eines Systems
mit n Ungleichungen ergibt sich also eine Formel, bei der die einzelnen Aussagen
durch logische Unds miteinander verknüpft sind:
FA = A1 ∧ A2 ∧ ... ∧ An
(3.12)
Es müssen alle Aussagen Ai erfüllbar sein, damit die Formel FA erfüllbar ist. Für
welche t’s die Formel wahr ist, lässt sich aber nicht so einfach aus der Formel
ablesen. Um dies zu ermöglichen, wird die Formel in eine disjunktive Normalform
umgewandelt, das heißt in eine Form, in der Literale in Konjunktion Monome
bilden, welche wiederum disjunktiv miteinander verknüpft werden. Hierbei gilt:
1. Literale haben die Form T rue wenn sie für alle t erfüllbar sind, F alse wenn
sie für alle t unerfüllbar sind, t ≤ x, t ≥ x oder t = x.
2. Monome entstehen aus der konjunktive Verknüpfung von Literalen, also
M = L1 ∧ L2 ∧ ... ∧ Lm .
3. Die Formel ergibt sich aus der disjunktiven Verknüpfung aller Monome. Sie
hat die Form
FDN F = M1 ∨ M2 ∨ ... ∨ Mf
(3.13)
Zur Umwandlung von FA in FDN F wurde folgender Algorithmus entworfen und
implementiert:
Algorithmus zur Umwandlung von FA in FDN F :
1. Schritt: Erzeuge FDN F mit FDN F = T rue.
2. Schritt: Für i = 1 bis i = n:
61
1. Entferne alle unerfüllbaren Monome in FDN F bis auf das letzte.
2. Füge die Aussage Ai der Formel FA zur Formel FDN F hinzu.
a) Wenn Ai aus einem Literal L besteht, dann wird dieses Literal zu allen
Monomen von FDN F hinzugefügt (FDN F ∧ L).
b) Wenn Ai = L1 ∧L2 , dann wird zuerst L1 und dann L2 mit den Monomen
verknüpft (FDN F ∧ L1 ∧ L2 ).
c) Im Falle von Ai = L1 ∨ L2 gilt
FDN F neu = (FDN F alt ∧ L1 ) ∨ (FDN F alt ∧ L2 )
Der Algorithmus berechnet also aus der Formel FA die Formel FDN F in disjunktiver Normalform. Das Entfernen der unerfüllbaren Monome im zweiten Schritt
ist legitim, da ein unerfüllbares Monom nie durch eine Und-Verknüpfung erfüllbar
werden kann. Außerdem führt es dazu, dass die Formel FDN F nicht durch Aussagen der Form Ai = L1 ∨ L2 exponentiell aufgebläht wird. Dazu ist es aber auch
nötig das Verknüpfen von Literalen mit Monomen effizient zu gestalten. In der
Tat bestehen Monome nie aus mehr als zwei Literalen. Dies ist in der Struktur der
Literale begründet. Ein Monom M der Form M = L1 ∧ L2 ist nur dann erfüllbar,
wenn L1 = t ≥ x1 , L2 = t ≤ x2 und x1 ≤ x2 2 . Man kann sich leicht überlegen, dass
die anderen, nicht redundanten Fälle nicht erfüllbar sind. Wenn man das Monom
M nun mit dem Literal La konjunktiv verknüpft, treten folgende Fälle auf:
1. La = F alse: Damit ist auch M = F alse, da M ∧ F alse = F alse.
2. La = T rue: M bleibt unverändert, da M ∧ T rue = M .
3. La = t ≤ xa :
a) xa < x1 : M ist unerfüllbar, also M = F alse.
b) xa ≥ x2 : M bleibt unverändert.
c) x1 ≤ xa < x2 : L2 wird durch La ersetzt.
4. La = t ≥ xa :
a) xa > x2 : M ist unerfüllbar, also M = F alse.
b) xa ≤ x1 : M bleibt unverändert.
c) x1 < xa ≤ x2 : L1 wird durch La ersetzt.
Es ist also möglich unter Beachtung dieser Fälle ein Literal und ein Monom so
miteinander zu verknüpfen, dass das daraus resultierende Monom maximal zwei
Literale enthält. Ebenso wie es möglich ist ein Monom mit zwei Literalen bei
der Verknüpfung mit einem Literal gegebenenfalls als unerfüllbar zu erkennen und
2
Natürlich ist auch L1 = t ≤ x1 , L2 = t ≥ x2 und x1 ≥ x2 möglich. Dieser Fall ist aber redundant.
Fälle, in denen Literale der Form L = t = x1 , L = F alse und L = T rue auftreten oder in denen
x1 = x2 gilt, sind auch durch ein Literal darstellbar und werden somit ignoriert
62
somit später zu löschen, ist dies auch bei der Verknüpfung eines Literals mit einem
Monom, das aus nur einem Literal besteht, möglich. Die sich bei einer solchen
Verknüpfung ergebenden Fälle sind zwar zahlreich, aber leicht zu überlegen und
werden deshalb hier nicht aufgeführt.
Wenn der oben beschriebene Algorithmus zur Umwandlung von FA in FDN F die
möglichen Kombinationen von Literalen und Monomen beachtet, bleibt die Anzahl
der Monome in der resultierenden Formel FDN F gering, da die meisten Monome
schnell als unerfüllbar erkannt werden.
Somit werden also aus dem linearen Ungleichungssystem (3.9) mittels der FourierMotzkin-Elimination die unbekannten Variablen entfernt und das resultierende System in ein nichtlineares System von Ungleichungen der Form (3.11), das die Zeit
als Variable enthält, umgewandelt. Die einzelnen Ungleichungen werden gelöst und
produzieren jeweils eine Aussage. Die Aussagen werden nach (3.12) miteinander
verknüpft und die so produzierte Formel mittels des oben beschriebenen Algorithmus in die disjunkive Normalform (3.13) umgeformt. Aus der nun vorhandenen
Formel FDN F kann leicht ermittelt werden, ob sie erfüllbar ist, und wann es gegebenenfalls zum Unfall kommt.
Damit FDN F keine Ergebnisse über mögliche Unfälle in negativer Zeit liefert,
wird sie zuerst mit dem Literal t ≥ 0 verknüpft. Erfüllbar ist FDN F genau dann,
wenn mindestens ein Monom erfüllbar ist, also nicht nicht für alle Monome Mi =
F alse gilt. Den nächstmöglichen Zeitpunkt einer Kollision erhält man, indem für
jedes erfüllbare Monom das kleinste erlaubte t ≥ 0 bestimmt wird. Das kleinste
dieser t’s ist der gesuchte Kollisionszeitpunkt.
3.4.4 Zusammenfassung
Mit Hilfe der in diesem Abschnitt beschriebenen Methoden kann also berechnet
werden, ob zwei Fahrzeuge, deren Länge und Breite bekannt sind, bei gegebener Anfangsgeschwindigkeit, konstanter Beschleunigung gleichbleibender Richtung
kollidieren. Wenn sie kollidieren, dann kann auch der Zeitpunkt der Kollision bestimmt werden.
Die Modellierung der Fahrzeuge als Rechtecke erlaubt es sowohl ihre Maße exakt zu bestimmen, als auch den gewünschten Sicherheitsabstand für Vorder- und
Rückseite einerseits und die beiden Seiten andererseits getrennt zu bestimmen.
Dies ist eine interessante Option, da die Abstände zwischen den Fahrzeugen seitlich im Straßenverkehr wesentlich geringer sind als nach vorne und hinten.
Durch Gleichsetzten der Bahnen zweier Fahrzeuge ergibt sich ein Ungleichungssystem, das vier Unbekannte enthält, die sich aus der Beschreibung der Rechtecke
ergeben. Die nichtlineare Unbekannte Zeit wird in den Koeffizienten verborgen,
dafür werden drei weitere Variablen eingeführt, deren Wert Eins beträgt.3
3
Alternativ könnte man auch sagen, dass die Werte 1, t und t2 betragen. Somit ist die Zeit nicht mehr
in den Koeffizienten, sondern in den neuen Variablen enthalten, was aber zum selben Ergebnis führt.
63
Die Fourier-Motzkin-Elimination ermöglicht es, die vier Unbekannten zu eliminieren, ohne die Erfüllbarkeit des Systems zu beeinträchtigen. Die Elimination
führt zu relativ vielen Ungleichungen, von denen aber einige redundant sind und
aus dem System entfernt werden können.
Das aus der Elimination resultierende Ungleichungssystem wird in ein System
von nichtlinearen Ungleichungen umgewandelt, die als einzige Unbekannte die Zeit
enthalten. Dies geschieht durch Gleichsetzen der vorher eingeführten Unbekannten
mit dem Wert Eins. Betrachtet man die Zeit nun wieder als Unbekannte und nicht
als Teil der Koeffizienten, dann erhält man die genannten nichtlinearen Ungleichungen. Da die Koeffizienten, die die Zeit als einfachen Faktor enthalten, die, die
sie nicht enthalten und die, die sie als quadratischen Faktor enthalten, durch die
drei vor der Elimination eingeführten zusätzlichen Variablen sozusagen voneinander getrennt gehalten wurden, können diese Umformungen durchgeführt werden,
ohne das Ergebnis zu verfälschen.
Im nächsten Schritt werden die Lösungsmengen der einzelnen Ungleichungen
für die Zeit bestimmt. Diese haben die Form von logischen Aussagen. Aus den
Aussagen wird mittels des logischen Und eine Formel erzeugt, die genau dann
erfüllbar ist, wenn es zu einem Unfall kommt.
Da diese Formel aber nicht so einfach direkt auf Erfüllbarkeit getestet werden
kann, wird sie mittels eines speziellen Algorithmus in die disjunktive Normalform
umgewandelt. Der Algorithmus beachtet die Besonderheiten der hier auftretenden
Aussagen und kann somit überflüssige, unerfüllbare Monome aus der Formel entfernen. Hierdurch wird die Umformung wesentlich vereinfacht und beschleunigt,
da die Formel sonst durch Aussagen, die ein logisches Oder enthalten, exponentiell
aufgebläht wird.
Diese Formel in disjunktiver Normalform kann sehr einfach auf Erfüllbarkeit getestet werden, da es genügt, wenn ein Monom erfüllbar ist und die unerfüllbaren
Monome bis auf das letzte gegebenenfalls schon aus der Formel entfernt wurden.
Auch der Kollisionszeitpunkt lässt sich, wenn die Formel erfüllbar ist, einfach anhand des frühest möglichen Zeitpunkts bestimmen, der in den in den Monomen
festgelegten Lösungsmengen enthalten ist.
3.5 Implementierung des Fahrerassistenten
Nachdem in den beiden vorhergehenden Abschnitten das ontologische Kontextmodell und der dazugehörende Satz von externen Regeln ebenso erläutert wurde wie
die Methode der Kollisionsberechnung, wird in diesem Abschnitt die eigentliche
Implementierung des Fahrerassistenten beschrieben.
Abbildung 3.5 zeigt die wichtigsten Klassen und ihre Zugehörigkeit zu den logischen Programmkomponenten. Die logischen Komponenten, wie sie in Abbildung
2.1 dargestellt werden, sind hier durch die äußeren Rechtecke abgebildet, die die
dazugehörigen Javaklassen umfassen. Eine strikte Trennung zwischen Simulator
64
und Kontrolleinheit ist nicht möglich. Auf den logische Aufbau beziehungsweise
die logischen Komponenten und die sich daraus ergebende Architektur, sowie die
verwendeten Werkzeuge wie Sprachen und Framework wurde schon im Kapitel 2
genauer eingegangen.
Abbildung 3.5: Die logischen Komponenten und die wichtigsten Javaklassen
In diesem Abschnitt wird die Implementierung der einzelnen Komponenten des
Fahrerassistenten erläutert. Dies geschieht durch eine Beschreibung der wichtigsten
Java-Klassen, die in dieser Arbeit erstellt wurden, und ihrer Funktion. Quellcode
wird nicht angegeben, der interessierte Leser findet ihn auf der beiliegenden CD.
Die nötigen Anpassungen des Verkehrssimulators VIS SIM werden am Ende des
Abschnitts aufgeführt.
3.5.1 Die Klasse OntoCar.java
Die Klasse OntoCar ist die Schnittstelle, über die der Fahrerassistent in den Verkehrssimulator eingebunden ist und mit ihm kommuniziert. Sie ist auf den Simulator zugeschnitten und versteckt die Details der Implementierung des Simulators
vor dem eigentlichen Fahrerassistenten. Will man also einen anderen Verkehrssimulator verwenden, muss eine neue Klasse OntoCar geschrieben werden. Abbildung
3.6 zeigt die Einbindung der Klasse OntoCar in die Programmstruktur.
Im Verkehrssimulator VIS SIM sind Fahrzeuge als Objekte der Klasse Car modelliert. Diese Fahrzeugobjekte werden um je ein OntoCar-Objekt erweitert. Das
OntoCar-Objekt wird regelmäßig nach einer festgelegten Anzahl von Simulationsschritten für einen Simulationsschritt aktiv. Nun werden von seinem Car drei Methoden des OntoCars der Reihen nach aufgerufen. Die Aufspaltung in drei getrennte Aufrufe erlaubt eine bessere Synchronisation zwischen den einzelnen Fahrzeu-
65
Abbildung 3.6: Die Einbindung der Klasse OntoCar
gen, vor allem garantiert sie, dass alle Fahrzeuge mit aktuellen Daten arbeiten.
Die Unterteilung eines Aufrufs in mehrere Aufrufe zu Synchronisationszwecken ist
durch die Struktur des Simulators begründet, da hier diese Technik zum Einsatz
kommt und somit leicht auf den OntoCar zu übertragen ist.
Mit den ersten zwei aufgerufenen Methoden setOntoCar() und updateOntoCar()
liest der OntoCar die Fahrzeugdaten aus. Dies geschieht beim eigenen Fahrzeug direkt aus dem Car, bei den restlichen Fahrzeugen über den Simulator. Es werden
nur die Daten der Fahrzeuge eingelesen, die einen gewissen Abstand zum eigenen
nicht überschreiten. Somit wird die beschränkte Reichweite der Sender in den einzelnen Fahrzeugen simuliert. Die Methode updateOntoCar() gibt die Daten dann
an das InputOutput-Objekt des OntoCar weiter.
Die dritte Methode startOntoCar() startet ihrerseits nun den OntoAssistant.
Die vom OntoAssistant produzierten Kontrollsignale werden ausgewertet und an
den Car weitergeleitet, das heißt die entsprechenden Variablen, mit denen das Fahrzeugverhalten kontrolliert wird, werden gesetzt. Eine Outputmessage mit den zu
verschickenden, eigenen Fahrzeugdaten wird ebenso produziert und ausgedruckt.
Zum Schluss werden noch die eigenen Daten aktualisiert.
Die Klasse OntoCar übernimmt also die komplette Kommunikation zwischen
dem Simulator und dem eigentlichen Fahrerassistenten. Sie ist in den Simulator
eingebunden und liest alle nötigen Daten aus dem Simulator aus. Der Fahrerassistent greift auf den OntoCar nicht zu, die Kommunikation läuft hier über die
Schnittstelle InputOutput, der OntoCar hingegen muss den Fahrerassistenten explizit aufrufen.
In der Klasse OntoCar sind teilweise auch die Funktionen der in Abschnitt
2.3 beschriebenen Kontrolleinheit implementiert, da sie die Steuerungssignale aus
66
InputOutput ausliest und die entsprechenden Variablen zur Fahrzeugkontrolle in
Car setzt.
3.5.2 Die Klasse InputOutput.java
Über die Klasse InputOutput findet die Kommunikation des eigentlichen Fahrerassistenten mit dem Rest des Systems statt, also dem Simulator beziehungsweise dem
OntoCar. Somit ist der Fahrerassistent vom eigentlichen Simulator unabhängig. Sie
entspricht der logischen Komponente Ein- und Ausgabe aus dem Abschnitt 2.3.
InputOutput besteht aus mehreren Komponenten. Die in diesem Szenario wichtigen sind:
• sensorData: Die Sensordaten des eigenen Fahrzeugs, also Position, Geschwindigkeit, usw.
• incoming: Die Sensordaten aller anderer Fahrzeuge, jeweils in Form einer
hier definierten InputMessage.
• outputMessage: Die Fahrzeugdaten, die an die anderen Fahrzeuge verschickt
werden sollen.
• controlOutput: Die vom Fahrerassistenten erzeugten Kontrollsignale zur
Steuerung des Fahrzeuges.
Für alle diese Komponenten stehen Methoden zur Verfügung, die sie entweder mit
neuen Daten versehen, oder es ermöglichen auf die Daten zuzugreifen.
3.5.3 Die Klasse OntoAssistant.java
Diese Klasse implementiert den in Abschnitt 2.3 beschriebenen Assistenten. Für
jedes Fahrzeug existiert ein eigener OntoAssistant. Die benötigten Daten erhält
er über den InputOutput, über den er auch seine Ausgabe, also die zu sendenden Fahrzeugdaten und vor allem die Kontrollsignale, weitergibt. Der Aufruf des
OntoAssistant erfolgt vom OntoCar, er ist also nicht als selbstständiges Programm mit einer eigenen main-Methode implementiert, sondern als normale JavaKlasse.
Der OntoAssistant liest bei jedem Aufruf die aktuellen Daten aus dem Objekt
InputOutput aus und veranlasst die ExtOntology ihr(e) Modell(e) mit diesen Daten neu zu instanziieren. Im nächsten Schritt wird über die Inquiry-Klasse eine
Anfrage an die ExtOntology gestartet. Das Ergebnis dieser Anfrage sind alle bekannten Fahrzeuge mit ihren Daten, sowie die Daten des eigenen Fahrzeugs. Die
Fahrzeuge werden als Objekte des Typs Vehicle in einem Ergebnisobjekt der Klasse Result gespeichert. Dieses dient als Grundlage zweier Kollisionsberechnungen.
Beide werden von der Evaluation-Klasse unter Verwendung der FMElim-Klasse
durchgeführt. Die erste Berechnung überprüft, ob es zu einem Unfall mit einem
67
anderen Fahrzeug kommt, wenn alle Parameter so bleiben wie sie sind. Die zweite
wird nur durchgeführt, wenn das eigene Fahrzeug steht oder sich nur sehr langsam
bewegt. Sie überprüft was passiert, wenn man beschleunigt. Beide Berechnungen schreiben ihr Ergebnis, also, ob es zum Unfall kommen wird, die erwartete
Zeit bis zur Kollision und den Kollisionspartner, in das Result-Objekt. Anschließend wertet die Evaluation-Klasse das Ergebnis aus, das heißt sie berechnet ein
Gefahrenlevel aus der Zeit bis zur nächsten Kollision und generiert hieraus den
ControlOutput im InputOutput. Auch werden die Zeit bis zur nächsten Kollision
und die ID des Kollisionspartners in der Fahrzeugontologie abgespeichert. Zum
Schluss wird noch die OutputMessage in den InputOutput geschrieben.
3.5.4 Die Klasse ExtOntology.java
Hier wird die Fahrzeugontologie und die Umweltontologie verwaltet. Auf die Umweltontologie wird im Kapitel 4 genauer eingegangen, es gilt aber im Prinzip dasselbe wie für die Fahrzeugontologie. Diese Klasse ist die Implementierung der logischen Komponente Ontologie und Reasoner aus dem Abschnitt 2.3.
Bei der Initialisierung der Ontologie wird die Adresse der OWL-Datei übergeben,
in der die Fahrzeugontologie formalisiert ist. Aus dieser Datei wird ein OntModel,
die Jena-Implementierung einer OWL-Ontologie, erzeugt. Die zu importierende
Beispielontologie mit weiteren Fahrzeugtypen wird von Jena automatisch geladen.
Das OntModel ist mit Jenas OWL DL Reasoner verknüpft. Daten werden in dieses
Modell geschrieben und aus ihm gelöscht, es enthält also auch alle Fahrzeuginstanzen.
Da ein Teil des Fahrzeugmodells, unter anderem die Abbildungsvorschriften
für das importierte Modell, in einem externen Regelsatz gespeichert ist, wird
vom OntModel ein Jena InfModel abgeleitet. Dies geschieht mit Hilfe des speziell hierfür konfigurierten GenericRuleReasoner. Er wird sowohl mit dem in der
Datei car_no_streets.rules formalisierten externen Regelsatz erweitert als auch
den Regeln für OWL. Anfragen werden also an das InfModel gestellt, da die durch
die externen car_no_streets.rules beschriebenen Zusammenhänge im OntModel
nicht enthalten sind.
ExtOntology stellt Methoden zur Instanziierung der Fahrzeugontologie bereit.
Bei jeder Instanziierung werden die alten Daten eines Fahrzeugs genau dann gelöscht, wenn neue Daten zur Verfügung stehen. Nach der erfolgten Instanziierung
des OntModels wird das alte InfModel gelöscht und neu abgeleitet. Der mit ihm
verknüpfte Reasoner bleibt aber erhalten, somit müssen die Regeln in der Datei
car_no_streets.rules nicht erneut geladen werden.
3.5.5 Die Klasse Inquiry.java
Anfragen an die Ontologie führt der Fahrerassistent über die Klasse Inquiry durch.
Diese bedient sich Jenas SPARQL Query Engine. Somit kann sie als Teil der logi-
68
schen Komponente Anwendung betrachtet werden.
Inquiry produziert aus einem String einen SPARQL-Query. In diesem Szenario sind dies ein Query, der alle Fahrzeuginstanzen vom Typ Andere_Fahrzeuge
liefert, und ein Query, der ein Eigenes_Fahrzeug ergibt.
Mit diesen Queries wird dann je eine Anfrage direkt an das InfModel der
ExtOntology gestellt. Die erhaltenen Fahrzeuge werden als Objekte vom Typ
Vehicle in einem Result abgespeichert.
Die Methode startCollisionInquiry() führt beide Anfragen komplett durch
und liefert als Rückgabewert eben jenes Result. Sie wird vom OntoAssistant
aufgerufen. Es existiert auch noch eine Methode startEnvInquiry(), die eine
Anfrage an die Umweltontologie durchführt und das Ergebnis ebenfalls als Result
zurückgibt.
3.5.6 Die Klasse Evaluation.java
Die Evaluation ist ebenfalls ein Teil der Anwendung. Sie bedient sich der Klasse
FMElim um aus dem von Inquiry erzeugten Result eine Kollisionsvorhersage zu
machen und ein Gefahrenlevel daraus abzuleiten.
Die Methode checkCrash(Result r) berechnet den frühest möglichen Zeitpunkt einer Kollision des eigenen Fahrzeugs mit einem anderen Fahrzeug. Sowohl
die Zeit bis zum Unfall als auch der Kollisionspartner werden gegebenenfalls im
Result abgespeichert.
Die zweite Kollisionsberechnung, also ob es möglich ist für ein langsames Fahrzeug gefahrlos zu beschleunigen, wird von einer eigenen Methode durchgeführt,
der checkAcceleration(Result r). Intern greifen beide Methoden auf die private Methode testCrash zurück, da die Berechnungen exakt die gleichen sind.
Einziger Unterschied ist es, dass im zweiten Fall erst die eigene Beschleunigung
auf das Maximum gesetzt wird.
Zu beachten ist, dass die in Abschnitt 3.4 beschriebene Methode zur Kollisionsberechnung nicht die Tatsache berücksichtigt, dass bremsende Fahrzeuge nur bis
zum Stillstand abbremsen und nicht unmittelbar mit der Bremsbeschleunigung
weiter im Rückwärtsgang beschleunigen. Damit es hier nicht zu falschen Ergebnissen kommt, wird gegebenenfalls die Zeit bis zum Stillstand der Fahrzeuge berechnet
und überprüft, ob die Kollision vorher oder nachher eintritt, beziehungsweise ob
ein stehendes Fahrzeug getroffen wird.
Ebenso werden Fahrzeuge, die von hinten kommen, ignoriert, da die einzige Reaktion zur Kollisionsvermeidung Abbremsen ist, und dies hier kontraproduktiv
ist. Die relative Position hinten bedeutet, dass der Winkel zwischen eigener Fahrzeugrichtung und dem Mittelpunkt des anderen Fahrzeuges zwischen 135◦ und
225◦ beträgt, also sich das Fahrzeug sozusagen im Quadranten hinter dem eigenen
befindet.
Mit der Methode collReaction(OntoAssistant a, Result r) wird die Reaktion auf die berechneten Ergebnisse festgelegt und die Zeit bis zur Kollision sowie
69
der Kollisionspartner im OntModel abgespeichert. Das InfModel übernimmt diese
Werte automatisch vom OntModel, ohne dass dies explizit angegeben werden muss.
Um die Reaktion zur Kollisionsvermeidung zu steuern, wird ein Gefahrenlevel
berechnet. Dieses leitet sich aus der Zeit bis zum Crash und einer Konstanten
level_const ab. Ist die Zeit kleiner als die Konstante, dann ist das Gefahrenlevel
maximal, liegt sie zwischen der Konstante und der doppelten Konstante, dann ist
das Level um eins niedriger, usw. Ob es gefahrlos ist zu beschleunigen, wenn das
eigene Fahrzeug sehr langsam ist, wird ebenfalls mittels eines Schwellenwertes bestimmt. Die Konstante zur Berechnung des Gefahrenlevels wird im OntoAssistant
festgelegt und beträgt 0.9 Sekunden. Dies ist ein empirischer Wert, der zwar einerseits nicht alle Kollisionen vermeidet, aber andererseits den Verkehrsfluss nicht
zu stark beeinflusst. Der Schwellenwert bei der Beschleunigungswarnung liegt bei
der eineinhalbfachen Konstanten, also 1.35 Sekunden.
Mit Hilfe des hier bestimmten Gefahrenlevels und dem Ergebnis der Beschleunigungswarnung generiert collReaction(OntoAssistant a, Result r) schließlich noch den ControlOutput im InputOutput.
3.5.7 Die Klasse FMElim.java
Die Klasse FMElim implementiert die Fourier-Motzkin-Elimination und wesentliche
Teile der in Abschnitt 3.4 erläuterten Kollisionsberechnung. Sie ermöglicht es mit
Hilfe der Klasse CollisionLogic den Kollisionszeitpunkt zweier Fahrzeuge zu
bestimmen. Somit ist sie ein zentraler Teil der Komponente Anwendung, wie sie
im Abschnitt 2.3 beschrieben ist.
Die Methode carElim(Vehicle ve1, Vehicle ve2) berechnet die Zeit bis zur
Kollision der beiden Fahrzeuge ve1 und ve2. Die Zeit bis zur Kollision wird als
float zurückgegeben. Kommt es zu keiner Kollision, ist der Rückgabewert -1.
Die Berechnung erfolgt nach der in Abschnitt 3.4 beschriebenen Vorgehensweise.
Das Aufstellen des Ungleichungssystems und die Elimination der vier Unbekannten, die sich durch die Modellierung der Fahrzeuge als Rechtecke ergeben, wird in
Methoden der Klasse FMElim implementiert. Das Lösen der quadratischen Ungleichungen und die Umwandlung der resultierenden Formel in eine disjunktive Normalform ist ebenso wie der Test auf Erfüllbarkeit und die Suche nach dem frühesten
möglichen Kollisionszeitpunkt in der Klasse CollisionLogic implementiert. Die
entsprechenden Methoden werden von FMElim aus aufgerufen.
3.5.8 Die Klasse CollisionLogic.java
Die Klasse CollisionLogic implementiert die nicht in FMElim enthaltenen Teile
der Kollisionsberechnung aus Abschnitt 3.4. Somit ist sie ebenfalls Teil der Anwendung. Sie enthält folgende Klassendefinitionen:
• Literal: Ein Literal der Form T rue, F alse, t ≤ x, t ≥ x oder t = x.
70
• Aussage: Eine Aussage, die entweder aus einem Literal oder der Verknüpfung zweier Literale besteht (L1 ∨ L2 oder L1 ∧ L2 ).
• Monom: Ein Monom, das sich aus einem oder zwei Literalen durch eine konjunktive Verknüpfung zusammensetzt (L1 ∧ L2 ).
• Formel: Eine Formel in disjunktiver Normalform (M1 ∨ ... ∨ Mn ).
• Inequation: Implementiert die Lösung von quadratischen Ungleichungen.
Die Methode quadInEquation(float a, float b, float c) errechnet die Lösung der Ungleichung ax2 + bx + c ≥ 0 und gibt sie als Aussage zurück. Mit Hilfe
von createFormula(Aussage[] au) kann ein Array von Aussagen, die durch logische Unds verbunden sind, in eine Formel in disjunktiver Normalform umgewandelt werden. Hierzu wird der in Abschnitt 3.4 erläuterte Algorithmus implementiert. Durch die Berücksichtigung der speziellen Form der Aussagen, Literale
und Monome wird ein starkes Anwachsen der Formel vermieden. Die Methode
testCrash(Formel f) liefert schließlich die Zeit bis zum nächsten Crash, beziehungsweise den Wert -1 wenn die Formel unerfüllbar ist.
3.5.9 Weitere Klassen
Es sind noch weitere Klassen implementiert, die hier aber nur kurz erwähnt werden.
Vehicle ist die Klasse, in der intern die Daten eines einzelnen Fahrzeugs gespeichert werden. Sie stellt ein paar Hilfsmethoden zur Verfügung und übernimmt zum
Beispiel die Umwandlung von Richtungswerten und Geschwindigkeit in Vektoren.
Ebenso kann die relative Position, also vorne, hinten, links oder rechts eines anderen Fahrzeugs mit Hilfe einer hier implementierten Methode bestimmt werden.
Result dient einerseits zur Speicherung der Ergebnisse von Anfragen an die Ontologie, also Listen von Fahrzeugen, andererseits auch der Speicherung der daraus
berechneten Kollisionszeiten und der ID der Kollisionspartner.
Location implementiert einen Punkt in der zweidimensionalen Ebene und stellt
Hilfsmethoden wie die Abstandsberechnung zweier Locations zur Verfügung.
Helper implementiert ein paar Hilfsfunktionen für Rechenoperationen mit Ungleichungen.
3.5.10 Änderungen am Verkehrssimulator
Zum Schluss dieses Abschnitts noch ein paar Bemerkungen zu den am Verkehrssimulator vorgenommenen Änderungen.
Änderungen an Car.java
Um den Fahrerassistenten in den Verkehrssimulator einzubinden, wird jedes Fahrzeug des Simulators, beschrieben durch die Klasse Car, um einen OntoCar erweitert. Somit hat jedes Fahrzeug seinen eigenen Fahrerassistenten mit eigener Ontologie, etc. Die Initialisierung des OntoCar wird von der Klasse Car durchgeführt.
71
Auch die regelmäßigen Aufrufe erfolgen von hier. Somit muss Car mit einem Zähler
und einer Variablen zur Bestimmung der Häufigkeit des Aufrufs versehen werden.
Dadurch, dass die Zähler der einzelnen Fahrzeuge voneinander unabhängig sind,
erfolgen auch die Kollisionsberechnung meist zu unterschiedlichen Zeitpunkten.
Synchronisation bei der Kollisionsberechnung ist nicht nur unrealistisch, sondern
führt auch zu schlechteren Ergebnissen. Als Beispiel hierfür betrachte man zwei
Fahrzeuge, die beide stehen, aber deren Bahnen sich kreuzen. Wenn sie beide
gleichzeitig berechnen, ob es in Ordnung ist zu beschleunigen, dann kommen sie
zu dem Ergebnis, dass keine Gefahr besteht, da ja das andere Fahrzeug steht. Somit fahren beide los und es kommt zum Unfall, wenn sie sich so nahe beieinander
befinden, dass der Fahrerassistent keine zweite Berechnung vornimmt. Erfolgt die
Kollisionsberechnung aber zu unterschiedlichen Zeitpunkten, dann fährt das erste
Fahrzeug los und das zweite kann die drohende Gefahr erkennen, da es das erste
nicht mehr als stehend betrachtet.
Damit das Fahrzeug überhaupt auf die vom Fahrerassistenten erzeugten Kontrollsignale reagieren kann, muss die Klasse Car ebenfalls erweitert werde. Zuerst
werden weitere Variablen benötigt, über die der OntoCar das Fahrzeugverhalten
steuern kann. Dies sind im wesentlichen Variablen, mit denen das Fahrzeug vor
einem drohenden Unfall gewarnt, die Beschleunigung verhindert oder eine Notbremsung eingeleitet werden kann. Damit das Fahrzeug auch auf diese Variablen
reagiert, muss die Methode implement_Basic_Car_Following_Model() des Simulators, mit der das Fahrzeugverhalten gesteuert wird, durch eine erweiterte
Variante, die Methode test_Car_Model(), ersetzt werden. Diese überprüft die
neu eingeführten Kontrollvariablen und bremst das Fahrzeug gegebenenfalls ab.
Wenn das Signal zur Notbremsung gesetzt ist, dann erfolgt eine Vollbremsung
über mehrere Simulatorschritte. Dies hat den Grund, dass der Simulator in seiner
ursprünglichen Implementierung, wann immer möglich, Fahrzeuge maximal beschleunigt. Ein Abbremsen in einem Schritt würde also vom Simulator im nächsten
Schritt sofort wieder mit einer maximalen Beschleunigung beantwortet werden, was
die Erfolgsquote bei Notbremsungen reduziert.
Diese Erweiterung übernimmt also zusammen mit dem OntoCar die Funktion der
Kontrolleinheit aus Abschnitt 2.3. Da der Simulator VIS SIM keine Funktionen zur
externen Fahrzeugkontrolle zur Verfügung stellt, wurde die Kontrolleinheit in den
Simulator integriert und ist dadurch vom restlichen Fahrerassistenten getrennt,
kann also bei der Anbindung eines anderen Simulators nicht wiederverwendet werden. Da ihre Funktionsweise aber sehr einfach gehalten ist, ist dies als kein großer
Nachteil.
Weitere Änderungen
Um die benötigten Fahrzeugdaten, und in der erweiterten Version auch die Informationen über das Verkehrsnetz, aus dem Simulator auslesen zu können, wurde
er mit mehreren Hilfsfunktionen und Variablen ausgestattet, die aber nicht weiter
erwähnenswert sind.
72
Da die Fahrzeuge in der ursprünglichen Implementierung sehr hohe Beschleunigungswerte aufwiesen, wurden diese etwas reduziert, um realistischeres Fahrverhalten zu simulieren.
In der Orginalversion von VIS SIM haben die Fahrzeuge eine Farbe, die sich an
ihrer Geschwindigkeit orientiert. In der angepassten Version ergibt sich die Farbe
aus dem Gefahrenlevel beziehungsweise den Kontrollsignalen, die für ein Fahrzeug
ermittelt wurden. Die einzelnen Farben sind:
• Blau: Kein Warnsignal vom Fahrerassistenten.
• Grün: Die Notbremsung ist wieder aufgehoben:
• Gelb: Geringste Warnstufe.
• Orange: Nächste Warnstufe. Fahrzeug beschleunigt nicht weiter.
• Rot: Höchste Warnstufe. Notbremsung erfolgt.
• Magenta: Beschleunigungswarnung. Fahrzeug wird abgebremst.
Eine weitere Änderung ist die Erweiterung der einzelnen Simulationsschritte von
zwei auf drei Phasen. Hierdurch wird die Synchronisation der Fahrzeugdaten erleichtert.
Auch die Hauptklasse des Verkehrssimulators wurde erweitert. Aufrufe müssen
jetzt mit einem der vier folgenden Parameter erfolgen:
• --nostreets: Das hier beschriebene Szenario, erweitert um die Umweltontologie des zweiten Szenarios, wird aufgerufen. Als Fahrzeugklasse wird der
Simulator_PKW der Fahrzeugontologie verwendet.
• --importnostreets: Ebenso, nur ist die Fahrzeugklasse der in der importierten Beispielontologie enthaltene Simulator-Car.
• --streets: Die Straßenontologie des zweiten Szenarios wird importiert. Als
Fahrzeugklasse wird der Simulator_PKW der Fahrzeugontologie verwendet.
• --importandstreets: Der importierte Simulator-Car und die Straßenontologie kommen zum Einsatz.
Diese Aufzählung der am Verkehrssimulator vorgenommenen Veränderungen ist
nicht vollständig, die hier genannten sind aber die wichtigsten.
73
3.6 Ergebnisse, Schwachpunkte und Erweiterungsmöglichkeiten
In diesem Abschnitt wird die in diesem Kapitel beschriebene erste Version des
Fahrerassistenten analysiert. Zuerst werden die erzielten Ergebnisse beschrieben,
dann wird auf die Schwachstellen dieser Version und mögliche Lösungen eingegangen, und zum Schluss werden mögliche Erweiterungen genannt. Zwei dieser
Erweiterungen, eine Umwelt- und eine Straßenontologie sind in der zweiten Version des Fahrerassistenten implementiert, die in Kapitel 4 genau erläutert wird.
Eine detaillierte Bewertung des Fahrerassistenten wird in Kapitel 5 vorgenommen.
3.6.1 Ergebnisse
Der Fahrerassistent in dieser ersten Version hat nur relativ wenige Daten zur
Verfügung. Seine Informationen beschränken sich auf die Fahrzeugdaten, also im
Wesentlichen Positions-, Geschwindigkeits- und Beschleunigungswerte, sowie die
Maße der einzelnen Fahrzeuge. Mit diesen Daten führt jedes Fahrzeug ein oder
zwei Berechnungen durch. Zuerst wird bei jedem Aufruf ermittelt, ob es zu einem
Unfall kommt wenn alle Fahrzeugdaten gleich bleiben. Ist das eigene Fahrzeug sehr
langsam oder steht es, dann überprüft der Assistent mit der zweiten Berechnung,
ob beim Beschleunigen die Gefahr einer Kollision besteht. Es zeigt sich, dass die
mit diesen Berechnungen erzielten Ergebnisse schon recht gut sind.
t[s]
50
t
u
mit Assistent
40
t
u
30
20
10
t
trs u
u
t
tu
t u
t
tu
rs u
rs u
0
0
10
20
t
u u
t t
u
sr
30
t
u
40
t
t u
u
t
u
t
u
rs
rs
50
60
t
u
t
u
t
u
t
t u
t u
u
t
u
t
u
t
uu
t
t
u
t
u
ohne Assistent
rs
rs
70
rs
80
rs
90
rs
100
n
Abbildung 3.7: Geschwindigkeit des Simulators mit und ohne Fahrerassistenten
Abbildung 3.7 zeigt einen Vergleich der Geschwindigkeiten des Simulators mit
und ohne Fahrerassistent. Zu beachten ist, dass der Einsatz des Fahrerassistenten
anhand einer großen Kreuzung getestet wurde, an der es sehr schnell zu einem Stau
kam. Somit konnte einerseits eine große Menge an Fahrzeugen simuliert werden,
74
andererseits führen alle Fahrzeuge, die stehen, zusätzlich noch Berechnungen für
Beschleunigungswarnungen durch, also genau doppelt so viele wie schnelle Fahrzeuge.
Auf der x-Achse von 3.7 ist die Zahl der simulierten Fahrzeuge aufgetragen, auf
der y-Achse die Zeit, die ein Simulationsschritt, in dem jedes Fahrzeug seinen Fahrerassistenten genau einmal aufruft, benötigt. Die Zeit wird in Sekunden gemessen.
Die waagrechte Kurve stellt die Geschwindigkeit ohne den Fahrerassistenten dar,
die andere die Geschwindigkeit mit Fahrerassistent. Alle Simulationen wurden auf
einem AMD Athlon 64 3500+ mit 1024 MB Arbeitsspeicher durchgeführt.
Zuerst kann man feststellen, dass die Geschwindigkeit des Simulators alleine
nicht merklich von der Anzahl der Fahrzeuge abhängt. Ein Simulationsschritt dauert rund 0,75 Sekunden. Der Einsatz des Fahrerassistenten dagegen verlangsamt die
Simulation umso stärker je mehr Fahrzeuge im Einsatz sind. Der Grund hierfür ist,
dass der Rechenaufwand für den Rechner quadratisch mit der Anzahl der Fahrzeuge steigt. Ein einzelner Fahrerassistent berechnet für alle Fahrzeuge, ob eine
Kollisionsgefahr zwischen diesem und dem eigenen Fahrzeug besteht. Hier ist der
Rechenaufwand also linear. Der Rechner, der die Simulation durchführt, muss aber
die Berechnungen aller Fahrerassistenten vornehmen. Somit erfordern n Fahrzeuge
n · (n − 1) Kollisionsberechnungen, die Komplexität der Simulation bezüglich der
Kollisionsberechnungen und der Anzahl der Fahrzeuge ist also O(n2 ).
t[ms]
500
rs
400
rs
300
200
100
rs rs sr sr rs
rs
rs
rs
rs
rs
rs
rs
rs
rs
rs
rs
rs
rs rs
rs
rs rs
sr rs
rs sr
0
0
10
20
30
40
50
60
70
80
90
100
n
Abbildung 3.8: Geschwindigkeit eines einzelnen Fahrerassistenten
Abbildung 3.8 zeigt die Zeit, die ein einzelner Aufruf des Fahrerassistenten in
einer Simulation mit n Fahrzeugen dauert. Sie berechnet sich aus der Gesamtzeit
eines Simulationsschrittes minus der Zeit, die der Simulator ohne den Fahrerassistenten benötigt. Das Ergebnis wird durch die Zahl der Fahrzeuge geteilt, da jedes
Fahrzeug genau einen Assistenten hat und diesen genau einmal aufruft.
75
Es zeigt sich, dass der Fahrerassistent für eine geringe Anzahl von Fahrzeugen sehr schnell ist. Bei 10 Fahrzeugen benötigt jedes Fahrzeug 36 ms extra für
den Einsatz seines Fahrerassistenten. Dieser Wert steigt linear mit der Zahl der
Fahrzeuge. Bei 51 Fahrzeugen steigt die Zeit zum Beispiel auf 116 ms, bei 81 Fahrzeugen auf 192 ms. Ab ungefähr gut 100 Fahrzeugen, die gleichzeitig simuliert
werden müssen, nimmt die Simulationszeit aber sehr stark zu. Bei 105 Fahrzeugen
dauert der Aufruf zum Beispiel 436 ms. Dies liegt am mangelnden Arbeitsspeicher
des Simulationsrechners, so dass Simulationen mit mehr als 100 Fahrzeugen hier
keinen Wert für die Bestimmung der Komplexität des Fahrerassistenten haben.
Zumindest für den getesteten Bereich, für den der Simulationsrechner genügend
Arbeitsspeicher hat, verhält sich die Rechenzeit des Fahrerassistenten somit linear
zur Zahl der erfassten Verkehrsteilnehmer. Seine Komplexität ist in diesem Bereich
also O(n).
Wie sich aber die Anfragezeit oder die Instanziierung der Ontologie zu der Anzahl der in ihr gespeicherten Fahrzeuginstanzen genau verhält, ist nicht klar ersichtlich. Dies hängt von der Jena-Implementierung und der genauen Form der
Anfrage ab. Da die Anfragen aber eine sehr einfache Struktur haben, sie liefern
nur alle Vertreter eines Typs, sollten diese Operationen eigentlich keine zu hohe Komplexität aufweisen. Ebenso ist anzunehmen, dass eine wirklich große Anzahl von Fahrzeuginstanzen unter normalen Umständen nicht auftritt. Der Grund
hierfür ist, dass der Bereich, aus dem die Daten der anderen Fahrzeuge überhaupt
empfangen werden können, beschränkt ist.4
Die relativ hohe Geschwindigkeit, mit der der Fahrerassistent Kontrollsignale
produzieren kann, zeigt, dass der Einsatz von Ontologien zur Kontextmodellierung
hier prinzipiell machbar ist. Anfragen und andere Operationen auf dem ontologischen Modell sind, zumindest bei dieser recht einfachen Fahrzeugontologie, schnell
genug, um Daten für Kollisionsberechnungen in Echtzeit zur Verfügung zu stellen. Die Methode der Kollisionsberechnung an sich, also die Modellierung als sich
bewegende Rechtecke, erweist sich ebenfalls als hinreichend schnell und liefert die
gewünschten Ergebnisse.
Insgesamt reduziert der Einsatz des Fahrerassistenten die Anzahl der Kollisionen erheblich. Es zeigt sich, dass wenn der Fahrerassistent öfter aufgerufen wird,
die Zahl der Kollisionen gegenüber einem weniger häufigen Aufrufen abnimmt.
Dies lässt sich leicht dadurch erklären, dass Voraussagen mit aktuelleren Daten
natürlich auch bessere Ergebnisse liefern. In der Simulation werden die Daten alle
halbe Sekunde aktualisiert und auch die Kollisionsmöglichkeiten berechnet. Eine
4
Nach [wik07b] beträgt die Reichweite von externen Rundstrahlantennen für WLAN-Hardware bis zu
300 Meter. Bei einer Fahrzeugabmessung von 5 Meter Länge und 2 Meter Breite passen maximal rund
28000 Fahrzeuge in einen Kreis mit einem Radius von 300 Meter, wenn die gesamte Kreisfläche mit
Fahrzeugen bedeckt ist. Es ist nicht anzunehmen, dass die Reichweite der in die Fahrzeuge integrierten
Sender größer als 300 Meter ist. Betrachtet man nun statt der Fläche eines Kreises eine Straße mit
vier Spuren in jede Richtung, so ergibt sich, dass diese Platz für maximal 960 Fahrzeuge mit den
genannten Maßen bietet.
76
noch höhere Frequenz des Einsatzes erscheint unnötig, da die Ergebnisse erstens
schon bei dieser Frequenz gut sind, beziehungsweise die Schwachpunkte nicht an
der mangelnden Aktualität der Berechnungen liegen, zweitens die Berechnungen
an sich auch Zeit benötigen, und drittens die Annahme, dass in einer sehr hohen
Frequenz die aktuellen, präzisen Daten aller Verkehrsteilnehmer zur Verfügung
stehen, nicht sehr realistisch ist.
Während der Entwicklung des Assistenten zeigte sich eine Schwachstelle der einfachen Kollisionsberechnung mit der Annahme, dass alle Fahrzeugwerte konstant
bleiben. Dies ist das in Abschnitt 3.5.10 beschriebene Szenario, dass zwei stehende Fahrzeuge, deren Bahnen sich kreuzen, fälschlicherweise annehmen, dass keine
Gefahr besteht, wenn sie beschleunigen. Zur Lösung dieses Problems werden die
Aufrufe der Fahrerassistenten der einzelnen Fahrzeuge voneinander unabhängig
durchgeführt, wie in besagtem Abschnitt erwähnt. Außerdem wurde der Assistent
um die Beschleunigungswarnung erweitert. Diese beiden Erweiterungen verbessern
die Qualität der Kollisionsvorhersage ganz erheblich und reduzieren somit die Anzahl der auftretenden Unfälle. Hier zeigt sich, dass Fehleinschätzungen vor allem
dann auftreten, wenn sich die Fahrzeugparameter ändern, hier also Beschleunigung
und Geschwindigkeit. Um dieses Problem zu lösen stehen zwei Möglichkeiten zur
Auswahl. Entweder man führt die Berechnungen sehr oft durch und kann dadurch
ständig auf die sich verändernden Bedingungen reagieren, oder man versucht die
Änderungen vorherzusagen und die Berechnungen entsprechend anzupassen. Die
erste Option kann nur bis zu einem gewissen Ausmaß durchgeführt werden, da die
Verfügbarkeit aktueller Daten nicht beliebig hoch ist. Die zweite Option ist wesentlich schwieriger, da das Fahrerverhalten keinen festen Regeln folgt und somit
nur schwer vorauszusagen ist. Im Falle von langsamen oder stehenden Fahrzeugen ist eine Vorhersage aber nicht so schwierig, der Fahrer hat eigentlich nur zwei
Möglichkeiten. Er kann entweder stehenbleiben, oder das Fahrzeug beschleunigen.
Richtungsänderungen sind bei stehenden Fahrzeugen unmöglich und bei langsamen ändern sie die Bahn, in der sich das Fahrzeug bewegt, im relevanten Zeitraum
nur geringfügig. Es ist hier also möglich zu berechnen, was passiert wenn der Fahrer
die offensichtliche Option wählt, nämlich zu beschleunigen. Unfälle, die sich durch
die zweite Möglichkeit, also stehenzubleiben oder langsam weiterzufahren, ergeben, werden schon von der normalen Kollisionsvorhersage berechnet. Bei diesem
Szenario kann also die Veränderung der Fahrzeugparameter im Voraus bestimmt
werden. Dies ermöglicht es bessere Ergebnisse bei der Kollisionsvorhersage zu erzielen, da mehr potentielle Gefahrenquellen erkannt werden.
Die Testdurchläufe haben außerdem gezeigt, dass die erzielten Ergebnisse auf
geraden Strecken besser sind als auf kurvigen Strecken. Dies liegt in der Art der
Kollisionsberechnung begründet. Hier wird die Annahme gemacht, dass sich Fahrzeuge auf Bahngeraden bewegen. Wenn diese Annahme erfüllt ist, dann funktioniert auch die Kollisionsberechnung. Die besten Ergebnisse können an Kreuzungen
zweier gerader Straßen erzielt werden.
77
Die Erfolgsquote beträgt in diesem Fall zwar nicht hundert Prozent, allerdings
kommt es fast ausschließlich bei sehr niedrigen Geschwindigkeiten zu Kollisionen.
Die Erfolgsquote ließe sich durch eine größere räumliche Ausdehnung der Fahrzeuge
oder ein früheres Abbremsen weiter verbessern. Vor allem die Unfälle bei höheren
Geschwindigkeiten sind meist sehr knapp, hier würde eine größere Breite der Fahrzeuge Abhilfe schaffen. Zusätzlich muss ein beobachteter, sehr knapper Unfall nicht
wirklich ein Unfall sein, da die Fläche der Rechtecke im Simulator nicht unbedingt
mit den Fahrzeugdaten übereinstimmt. Grund hierfür ist die vermutete fehlerhafte
Umrechnung von Pixeln in Meter, die zu einer gewissen Unschärfe führt. Die richtige Balance zwischen Fehlerquote und unnötigem Eingreifen zu finden ist schwierig
und hängt auch vom individuellen Fahrerverhalten ab. Die Probleme, die sich hier
ergeben, werden in Abschnitt 2.3.7 genauer erläutert. Da die meisten Unfälle aber
nur bei geringen Geschwindigkeiten auftreten, kann dies durchaus als Funktionieren des Fahrerassistenten gewertet werden, weil es gelingt die Anzahl der schweren
Unfälle zu reduzieren. Eine weitere Ursache für auftretende Kollisionen ist, dass ein
Unfall, sobald er passiert ist, vom Fahrerassistenten ignoriert wird. Somit bleibt die
Simulation am Laufen, beziehungsweise es wäre den Fahrern möglich ihre Fahrzeuge vom Unfallort wegzufahren. Dies führt in der Simulation dazu, dass Fahrzeuge
manchmal, wenn sie sehr nahe beieinander stehen, übereinander fahren.
Exakte Zahlen über die Erfolgsquote des Fahrerassistenten können nicht angegeben werden, da der Verkehrssimulator seinen Berechnungen ein unrealistisches
Fahrerverhalten zugrundelegt, nämlich wann immer es möglich ist zu beschleunigen und nie die Spur zu wechseln.
3.6.2 Schwachpunkte und mögliche Lösungen
Die erwähnten Probleme durch sich ändernde Fahrzeugdaten sind einer der Schwachpunkte des Fahrerassistenten. Um sie zu beheben, müssten bessere Vorhersagen
des Fahrer- und Fahrzeugverhaltens getroffen werden, was aber aus den reinen
Positions- und Geschwindigkeitsdaten der Fahrzeuge nur sehr schwer möglich ist.
Es bietet sich also an, mehr Informationen in die Kollisionsberechnungen einfließen
zu lassen. Mögliche Erweiterungen des Kontextmodells und der Kollisionsberechnungen werden im nächsten Abschnitt beschrieben.
Ein weiterer Schwachpunkt liegt in der Berechnung der Fahrzeugbahn als Gerade. Dies führt vor allem bei Straßen mit Kurven zu schlechten Ergebnissen, aber
auch wenn ein Fahrzeug an einer Kreuzung abbiegt. Hier sind drei Möglichkeiten
denkbar, die schon mit geringen zusätzlichen Informationen bessere Vorhersagen
ermöglichen sollten. Die einfachste wäre es, je nach Lenkradeinschlag die Vorhersagen einfach einzuschränken, also je höher der Lenkradeinschlag, desto näher muss
der Kollisionszeitpunkt liegen, damit er beachtet wird. In einer starken Kurve
würden also weiter entfernte Kollisionspunkte ignoriert, da hier die Bahnabweichung von der berechneten Geraden zu hoch ist. Diese Variante kann aber nur die
Zahl der Fehlalarme verringern und keine neuen Unfälle vorhersagen. Die zwei-
78
te Möglichkeit ist es keine Gerade, sondern eine Kurve zu berechnen, wenn das
Lenkrad eingeschlagen ist. Aus dem Lenkradwinkel und weiteren Fahrzeugdaten
lässt sich der Kreis ermitteln, auf dem sich das Fahrzeug bewegt. Aber auch diese Methode liefert nur für relativ nahe Objekte die richtigen Ergebnisse, da die
tatsächliche Bahn wohl kein Kreis ist, sondern nur ein Kreisabschnitt auf den wieder eine Gerade folgt. Außerdem muss die Berechnungsformel angepasst werden, da
hier Rechtecke beschrieben werden müssen, die sich auf Kreisbahnen bewegen und
somit ständig ihre Richtung ändern. Als letzte Möglichkeit könnte die Frequenz
der Berechnungen in Kurven erhöht werden. Hiermit würde man der Tatsache sich
häufig ändernder Parameter gerecht werden. Da die Parameter, die sich ändern,
in diesem Falle die des eigenen Fahrzeugs sind, sollten zumindest die meisten von
ihnen ständig aktuell sein. Diese Möglichkeit könnte auch mit den beiden zuerst
genannten kombiniert werden.
Von Nachteil ist auch, dass der Fahrerassistent sämtliche Fakten, die sich aus dem
Streckenverlauf ergeben, ignoriert. So kann es sein, dass zwei Fahrzeuge überhaupt
nicht kollidieren können, da sie auf getrennten Straßen sind, sich aber aus den Fahrzeugdaten trotzdem eine Kollision ergibt. Im ungünstigsten Fall werden dann beide
Fahrzeuge abgebremst, obwohl ein Unfall durch den Streckenverlauf unmöglich gemacht wird. Hier ist es nötig weitere Informationen zum Straßennetz zu beachten,
um solche Fehleinschätzungen zu vermeiden.
Vorfahrtsregeln werden ebenfalls nicht beachtet, mit ihrer Hilfe würde sich die
Zahl der unnötigen Bremsaktionen ebenfalls verringern und das Verhalten der
Fahrer besser vorhersagen lassen. Allerdings passieren viele Unfälle gerade weil die
Vorfahrtsregeln missachtet werden, so dass Voraussagen anhand der Vorfahrtsregeln bei einer Anwendung zur Kollisionsvermeidung nicht immer das gewünschte
Ergebnis liefern. Ebenso könnte es sein, dass das eigene Fahrzeug zwar Vorfahrt
hat, das andere aber einen Defekt und somit ein leicht zu vermeidender Unfall
durch die Berücksichtigung der Vorfahrtsregeln nicht verhindert wird. Während
von der Berücksichtigung des Straßenverlaufs also hauptsächlich Vorteile zu erwarten sind, können bei den Vorfahrtsregeln durchaus auch Probleme auftreten.
Ein weiterer Schwachpunkt ist auch, dass die Reaktion auf eine erkannte Gefahr
nicht immer dieselbe sein sollte. Vielmehr ist es besser, sie von weiteren Faktoren,
wie zum Beispiel den Wetterverhältnissen, abhängig zu machen. So ist die Sicht bei
starkem Nebel viel schlechter als bei klarem Wetter, was dazu führen kann, dass
der Fahrer Fahrzeuge leichter übersieht. Wenn das Wetter also bekannt ist, dann
kann der Fahrerassistent dem Fahrer besser assistieren, indem er ihn zum Beispiel bei Nebel schon früher auf mögliche Gefahrensituationen hinweist, in dieser
Implementierung also das Gefahrenlevel anhebt.
Ein Problem ganz anderer Art ist es, dass der Fahrerassistent bei einer zu hohen
Anzahl von Instanzen zu langsam wird. Hier könnte eventuell eine effizientere
Implementierung Abhilfe schaffen, oder eine intelligentere Datenbeschaffung. Ein
Filter, der bei einer zu hohen Anzahl von Fahrzeugen nur die mit dem geringsten
79
Abstand zum eigenen Fahrzeug an die Ontologie durchlässt, kann eine Überladung
der Ontologie verhindern. Ebenso könnten alle Daten, die nicht mehr aktuell sind,
regelmäßig gelöscht werden.
Als letzter Schwachpunkt sei noch die Tatsache genannt, dass die Berechnungen nur bei exakten und aktuellen Daten funktionieren. Ungenauigkeiten in der
Positionsbestimmung und veraltete Daten führen zu unbrauchbaren Ergebnissen.
3.6.3 Erweiterungsmöglichkeiten
Aus den im letzten Abschnitt aufgezählten Problemen und den denkbaren Lösungen ergeben sich allerlei mögliche Erweiterungen des Fahrerassistenten. Sowohl das
Kontextmodell als auch die Kollisionsberechnungen und das Ableiten eines Gefahrenlevels oder die Erzeugung sinnvoller Kontrollsignale können erweitert oder
verfeinert werden.
Die Erweiterung des Kontextmodells um Informationen zum Straßenverlauf und
die allgemeinen Umweltbedingungen wird im nächsten Kapitel beschrieben. Sie
erlauben es Situationen besser einzuschätzen und dadurch besser auf sie zu reagieren.
In diesem Abschnitt wird die Möglichkeit, die verwendete Fahrzeugontologie um
neue Arten von Verkehrsteilnehmern zu erweitern, untersucht. Des Weiteren wird
gezeigt, wie die Kollisionsberechnung an die neuen Verkehrsteilnehmer angepasst
werden kann.
Fahrzeuge mit Anhänger oder Gelenk
Ein erstes Problem tritt durch die Annahme, dass alle Fahrzeuge sich als ein einziges Rechteck darstellen lassen, auf. Dies ist nämlich bei Fahrzeugen mit Anhängern
oder Gelenkfahrzeugen, wie zum Beispiel manchen Bussen, nicht der Fall. Es macht
also Sinn, die Fahrzeugontologie so zu erweitern, dass sie auch solche Fahrzeuge
beschreiben kann.
Fahrzeuge mit Anhänger könnten einfach als das modelliert werden, was sie in
gewisser Weise auch sind, nämlich zwei einzelne Fahrzeuge. Eine Klasse Anhänger
wird als Unterklasse des Konzepts Fahrzeug eingeführt. Eine Relation, modelliert als ObjectProperty, kann die Verbindung zwischen den beiden herstellen.
Wenn der aktuelle Winkel zwischen beiden und der konstante Abstand ihrer Mittelpunkte zum Gelenk bekannt ist, dann lassen sich die aktuellen Informationen
über den Anhänger einfach aus den Daten des Fahrzeugs ableiten. Die Position
des Anhängers ergibt sich aus dem Winkel und dem Mittelpunktsabstand und
seine Richtung aus der Fahrzeugrichtung und dem Winkel. Geschwindigkeit und
Beschleunigung sind bei Fahrzeug und Anhänger konstant. Die eigentliche Kollisionsberechnung wird für beide getrennt durchgeführt. Hat das eigene Fahrzeug
einen Anhänger, dann müssen alle Berechnungen ebenso für den Anhänger gemacht werden.
Gelenkfahrzeuge lassen sich auf die gleiche Weise modellieren. Eine neue Klasse
80
Gelenkfahrzeug wird als Fahrzeug definiert, das immer einen Anhänger besitzt.
Alternativ kann der hintere Fahrzeugteil auch als eigene Fahrzeugklasse definiert
werden, um der Tatsache gerecht zu werden, dass zum Beispiel ein Bus sein hinteres
Fahrzeugteil nicht abhängen oder verlieren kann, was bei einem Anhänger aber
durchaus der Fall ist.
Die Erweiterung auf mehrere Anhänger oder Gelenke nach dem selben Prinzip
ist ebenso sehr leicht machbar, wird hier aber nicht weiter ausgeführt.
Fußgänger
Will man alle Verkehrsteilnehmer erfassen, darf man sich nicht auf die unterschiedlichsten Fahrzeugtypen beschränken. Es ist nötig das Modell auch um Fußgänger
zu erweitern.
Die Modellierung von Fußgängern als Unterklasse der Fahrzeuge verbietet sich
aus verschiedenen Gründen. Erstens haben Fußgänger keine Sender, können also
ihre Daten nicht so einfach an das Fahrzeug senden. Zweitens haben Fußgänger
auch gar keine Sensoren, mit denen sie ihre Geschwindigkeits- und Positionswerte
messen können. Drittens bedarf es im Umgang mit Fußgängern besonderer Vorsicht. Während ein leichter Unfall mit einem anderen Fahrzeug nur Sachschaden
verursacht, führt ein Zusammenstoß mit Fußgängern sehr schnell zu schweren Verletzungen. Und schließlich ist das Verhalten von Fußgängern anders als das von
Fahrzeugen. Sie sind einerseits langsamer, andererseits aber wesentlich unberechenbarer in ihren Bewegungen.
Da die Fußgänger ihre Daten nicht selber übertragen, müssen sie vom eigenen
Fahrzeug ermittelt werden. So ist es zum Beispiel möglich den Positionswert aus
Abstandsradar und Bildwerten zu berechnen. Ein Fußgänger hätte also wie ein
Fahrzeug eine Position. Wenn über die Zeit mehrere Positionen ermittelt werden,
dann kann man daraus auch Richtung und Geschwindigkeit ermitteln. Die Beschleunigung ist ebenfalls denkbar, aber nicht sehr sinnvoll, da Fußgänger, auch
wenn sie zum Laufen anfangen, nicht über einen längeren Zeitraum konstant beschleunigen.
Um die nötige Vorsicht im Umgang mit Fußgängern und ihr unvorhersehbares
Verhalten korrekt zu modellieren, könnte man Fußgänger als kreisförmige Objekte betrachten. Der Radius des Kreises ist ein Maß für den Grad der Unschärfe
in der Positions-, Richtungs- und Geschwindigkeitsbestimmung. Auch die eigene
Geschwindigkeit könnte man in gewissem Maße mit einfließen lassen, da es bei
höherer Geschwindigkeit zu schwereren Verletzungen bei einem Unfall kommen
kann.
Da Fußgänger sich aber nicht sehr schnell bewegen können5 , bietet es sich an
sie nicht als sich bewegende Objekte zu modellieren, sondern als ruhende Kreise.
Ergibt sich aus den alten Positionswerten eine hohe Geschwindigkiet, dann kann
5
Der Weltrekord im 100-Meter Lauf für Männer aus dem Jahr 2005 liegt bei 9,77 Sekunden. Dies
entspricht einer Durchschnittsgeschwindigkeit von 10, 23 m
. Somit ist ein Positionswechsel eines
s
Fußgängers von mehr als 5 Metern, wenn alle 500ms gemessen wird, sehr unwahrscheinlich.
81
entweder der Kreisradius erhöht, oder der Kreis zu einer Ellipse in Laufrichtung
verformt werden.
Falls Bilderkennung eingesetzt wird, wäre auch eine Unterscheidung verschiedener Fußgängertypen möglich. Da Kinder sich zum Beispiel im Straßenverkehr
oft sehr unachtsam verhalten, könnten sie mit einem größerem Sicherheitskreis
versehen werden als Erwachsene.
Die Klasse Fußgänger hat also auf jeden Fall eine Position. Wenn einzelne
Fußgänger unterscheidbar sind, dann kann man ihnen noch eine alte Position zuordnen und daraus Geschwindigkeit und Richtung ableiten. Aus diesen lässt sich
auch die zweite notwendige Eigenschaft berechnen, nämlich der Kreisradius oder
die Ellipsenhalbachsen. Alternativ ist es auch möglich diese mit einem konstanten Wert zu besetzen, falls keine Geschwindigkeitswerte zur Verfügung stehen. Die
Kollisionsberechnung erfolgt jetzt anstelle mit einem sich bewegenden Rechteck
mit einem ruhenden Kreis, erfordert also eine Anpassung des Verfahrens.
Fahrradfahrer
Schwieriger ist die Modellierung von Fahrradfahrern. Die hier beschriebenen Probleme gelten aber größtenteils auch für andere, relativ schnelle Verkehrsteilnehmer
wie zum Beispiel Rollerblader.
Fahrradfahrer sammeln und senden wie die Fußgänger keine Daten, Kollisionen
mit ihnen müssen aber ebenfalls auf jeden Fall vermieden werden. Ihr Bewegungsmuster ist dagegen nicht so chaotisch wie das der Fußgänger, ihre Geschwindigkeit
aber wesentlich größer. Die Modellierung als Fußgänger oder Fahrzeug ist somit
nicht besonders sinnvoll. Um eine sinnvolle Berechnung zu gewährleisten, genügt
es nicht sie als ruhende Kreise oder Ellipsen zu beschreiben. Andererseits sind
präzise Berechnungen wie bei Fahrzeugen nicht möglich, da nicht alle benötigten
Daten zur Verfügung stehen.
Dieses Dilemma kann eigentlich nur durch eine verbesserte Datenbeschaffung
gelöst werden. Positionsbestimmungen können mit denselben Techniken wie bei
Fußgängern vorgenommen werden, allerdings ist es wichtig, dass einzelne Fahrradfahrer voneinander unterschieden werden können. Dies könnte entweder durch
Bilderkennungsverfahren geschehen, die hier mehr Unterscheidungskriterien als bei
Fußgängern haben, oder durch in die Fahrräder eingebaute Sender, die als einzige
Information eine ID enthalten.
Sobald eine Unterscheidung, und somit eine Zuordnung alter Positionswerte
möglich ist, kann aus diesen die Geschwindigkeit und die Richtung des Fahrradfahrers bestimmt werden. Beschleunigungswerte machen wohl wenig Sinn, da sie
nicht sehr hoch sind und auch die Geschwindigkeit nur ein Näherungswert ist, die
Berechnungen also nicht sehr präzise sind.
Somit hat ein Fahrradfahrer eine ID, eine aktuelle und eine alte Position. Aus
diesen Werten werden weitere Eigenschaften abgeleitet, die Geschwindigkeit und
die Richtung. Ebenso hat der Fahrradfahrer eine Länge und eine Breite. Diese sind
so groß gewählt, dass die Sicherheit des Fahrradfahrers gewährleistet ist, trotz
82
relativ ungenauer Daten. Die Maße sind entweder konstant, oder abhängig von
seiner Geschwindigkeit oder auch der eigenen Fahrzeuggeschwindigkeit.
Die Berechnungen an sich erfolgen wie bei Fahrzeugen, da der Fahrradfahrer
mit diesen Informationen als sich bewegendes Rechteck dargestellt wird. Der Unterschied zu einem Fahrzeug besteht darin, dass er keine Beschleunigungswerte hat
und die Größe des Rechtecks hauptsächlich von Sicherheitsüberlegungen abhängt
und nicht von der wirklichen Größe des Fahrrads.
3.6.4 Zusammenfassung
Zusammenfassend lässt sich sagen, dass die Ergebnisse des Fahrerassistenten, auch
wenn die im Modell erfassten Daten nicht sehr umfangreich sind, zu brauchbaren Ergebnissen führen. Die gewählte Methode zur Kollisionsberechnung funktioniert am besten auf geraden Strecken und bei konstantem Fahrzeugverhalten, Kurven bereiten Probleme. Diese können durch die Berücksichtigung weiteren Kontexts verringert werden, die Lösungsvorschläge wurden aber nicht implementiert.
Die Implementierung einer Beschleunigungswarnung wurde dagegen verwirklicht
und verhindert in den meisten Fällen eine ansonsten häufig auftretende Fehleinschätzung des Fahrerassistenten.
Die Kollisionsvorhersagen können zügig berechnet werden, und auch die Zugriffe
auf das ontologische Modell erfolgen, wenn es nicht zu viele Fahrzeuginstanzen
enthält, in kurzer Zeit. Dies sind wichtige Voraussetzungen für den Einsatz dieser
Techniken, da alle Berechnungen in Echtzeit erfolgen müssen.
Die Möglichkeit zum Import anderer Ontologien und somit zur Nutzung externer Daten ist ein großer Vorteil der ontologischen Kontextmodellierung. Auch die
leichte Erweiterbarkeit um neue Konzepte spricht für den Einsatz einer Ontologie
als grundlegendes Modell zur Erfassung aller Verkehrsteilnehmer.
Die Mängel des Fahrerassistenten lassen sich vor allem auf fehlende Informationen über seine Umwelt und das Unvermögen, das Verhalten des Fahrers vorherzusehen, zurückführen. Zur Lösung dieser Probleme bietet es sich an weitere
Konzepte, die für einen Verkehrsteilnehmer wichtig sind, zu modellieren und in
die Kollisionsberechnungen mit einfließen zu lassen. Dies wird im nächsten Kapitel mit einem einfachen Modell der allgemeinen Umweltbedingungen und einem
Modell des Straßennetzes realisiert.
83
4 Zweite Variante des Assistenten
Die Ergebnisse, die sich mit dem Fahrerassistenten erzielen lassen, wenn nur Daten
über das eigene und andere Fahrzeuge vorliegen, sind in einigen Situationen sehr
gut, in anderen dagegen weniger hilfreich. In diesem Kapitel wird eine erweiterte
Version des Fahrerassistenten vorgestellt, die durch mehr Kontextinformationen
bessere Ergebnisse erzielen soll.
4.1 Beschreibung des Szenarios
In diesem Szenario stehen dem Fahrerassistenten sowohl die Fahrzeugdaten, als
auch weitere Sensordaten und Informationen zum Straßennetz zur Verfügung. Das
Kontextmodell wird also um zusätzliche Informationen erweitert. Dies soll mit
möglichst wenig Änderungen an der Fahrzeugontologie und der restlichen Implementierung, also der Architektur und vor allem der Kollisionsberechnung, geschehen. Für fast alle Sensordaten, um die das Kontextmodell erweitert wird, gibt
es schon die entsprechenden Sensoren in modernen Fahrzeugen. Auch der einzige
Sensor, der nicht unbedingt in jedem Fahrzeuge vorhanden ist, der Nebelsensor,
könnte jederzeit in ein Fahrzeug eingebaut werden. Die Daten zum Straßennetz,
die in diesem Szenario zum Einsatz kommen, können von externen, elektronischen
Straßenkarten, wie sie zum Beispiel für Navigationssysteme existieren, eingelesen
werden.
Somit bleibt der logische Aufbau derselbe, und auch die Implementierung der
einzelnen Komponenten wird nur leicht angepasst. Die wirkliche Neuerung sind
zwei neue Kontextmodelle, die dem Fahrerassistenten zur Verfügung stehen. Das
erste ist ein Modell zur Beschreibung der Wetter- und Sichtverhältnisse. Es erlaubt
es dem Fahrerassistenten auf unterschiedliche Umweltbedingungen angemessen zu
reagieren. Das zweite Modell beschreibt das Straßennetz. Ziel ist es herauszufinden,
ob zwei Fahrzeuge auf zusammenhängenden Straßenabschnitten fahren und eine
Kollision somit überhaupt möglich ist. Mit der Einführung neuer Ontologien wird
hier auch der Nachweis zur Machbarkeit von Ontologieimporten erbracht.
84
4.2 Unterschiede und Gemeinsamkeiten bei Ansprüchen an
Ontologie, Regeln und Architektur im Vergleich zum
ersten Szenario
Generell sind die Ansprüche an die Architektur bei beiden Szenarien nahezu identisch. Da beide eine Kollisionsberechnung zum Ziel haben und das zweite Szenario
hauptsächlich eine Erweiterung des ersten um zusätzliche Kontextinformationen
darstellt, muss die Architektur auch dieselben Ansprüche erfüllen.
Die Daten bezüglich der Fahrzeuge müssen stets aktuell und präzise sein, da
sonst die Kollisionsberechnung unzuverlässige Ergebnisse liefert. Zugriffe auf die
Fahrzeugontologie müssen schnell erfolgen können, eine Erweiterung um Informationen zum Straßennetz sollte die Fahrzeugontologie nicht wesentlich verlangsamen. Und natürlich muss die Kollisionsberechnung in Echtzeit erfolgen können.
Diese Forderungen wurden schon an die erste Version des Fahrerassistenten gestellt und gelten natürlich weiterhin.
Bei den neuen Ontologien gelten dagegen teilweise andere Voraussetzungen. Die
Daten beider Modelle müssen nicht so aktuell sein, wie die der Fahrzeuge. Grund
hierfür ist, dass sich der Straßenverlauf nur sehr langsam und selten ändert, und
auch die Umweltbedingungen nicht so plötzlichen, drastischen Änderungen unterworfen sind wie die Fahrzeugdaten. Der Umweltontologie stehen alle Daten als
Sensorwerte des eigenen Fahrzeugs zur Verfügung, so dass die vorliegenden Daten
immer aktuell sind, aber nicht in so hoher Frequenz an die Ontologie übergeben
werden müssen. Die Daten zur Straßenontologie dagegen müssen extern beschafft
werden. Eine regelmäßige Instanziierung mit neuen Werten ist, wenn man sich auf
die Eigenschaft des Zusammenhangs von Straßenabschnitten beschränkt, nur extrem selten notwendig. Hier ist es nur wichtig, dass Zugriffe schnell erfolgen können,
da jeder Zugriff auf ein Fahrzeug auch mit einem Zugriff auf die Straßenontologie
verbunden ist.
4.3 Die neuen Ontologien und die Erweiterung der
Fahrzeugontologie
In diesem Abschnitt werden die beiden neuen Kontextmodelle, also die Umweltontologie und die Straßenontologie, erläutert. Ebenso wird auf die notwendigen Änderungen an der Fahrzeugontologie eingegangen und die zu den Ontologien gehörenden Regelsätze.
4.3.1 Umweltontologie
Die Umweltontologie modelliert eine Auswahl der zur Verfügung stehenden Sensoren und daraus abzuleitende Bedingungen wie Sichtverhältnisse oder Glatteisgefahr. Die Ontologie ist in der separaten Datei umwelt.owl beschrieben, die sich
85
auf der beiliegenden CD befindet. Die Ableitungsregeln sind in der externen Datei
sensor.rules formalisiert.
Die Umweltontologie besteht aus zwei Hauptkonzepten, den Sensordaten und
den Bedingungen. Um die Übersichtlichkeit zu wahren, werden diese Konzepte
getrennt erläutert, auch wenn sie in derselben Datei formalisiert sind.
Die Sensordaten
Wie in Abbildung 4.1 dargestellt, werden im Modell vier Sensoren erfasst. Alle
vier leiten sich von der Klasse Sensor ab. Jeder der vier Sensoren hat genau
eine DatatypeProperty. Dies ist der Wert des Sensors, in allen vier Fällen eine
Gleitkommazahl.
Abbildung 4.1: Die Sensoren der Umweltontologie
Die vier Sensoren sind ein Nebelsensor, ein Helligkeitssensor, ein Niederschlagssensor und ein Temperatursensor. Diese liefern folgende Werte:
• Der NebelSensor gibt die Sichtweite in Meter an.
• Der HelligkeitsSensor misst die Leuchtdichte in Candela pro Quadratmeter. Bei Sonnenschein ergeben sich Werte von ungefähr 8000 mcd2 , in der Nacht
von 0, 001 mcd2 .
• Der NiederschlagsSensor zeigt die Stärke des Niederschlags an, wobei ein
Wert von Eins die maximale Niederschlagsmenge ist und ein Wert von Null
bedeutet, dass kein Niederschlag gemessen wird.
86
• Die Außentemperatur wird vom TemperaturSensor in Grad Celsius gemessen.
Die Einheiten der Sensordaten, wie Candela pro Quadratmeter oder Grad Celsius, sind in der Ontologie selbst nicht modelliert. Hier könnte man jedem Sensor
eine Property Einheit zuordnen, die die Einheit als String angibt. Besser wären
konkrete Datentypen, aber solche stehen in OWL nicht zur Verfügung.
Es existieren natürlich weitere Sensoren, die aber dem Modell leicht hinzugefügt
werden können. Beispiele hierfür wären ein Höhenmesser, die Innentemperatur,
oder das Gefälle der Straße. Wie schon bei der Fahrzeugontologie gilt aber auch bei
der Umweltontologie das Interesse mehr der prinzipiellen Funktionsweise und den
Möglichkeiten als der Vollständigkeit des Modells, die theoretisch weder erreichbar,
noch erwünscht ist (siehe Abschnitt 1.3).
Die vier gewählten Sensoren erlauben es Aussagen über Sichtverhältnisse und
Witterungsbedingungen zu treffen. Diese werden durch die Klasse Umwelt modelliert.
Die Umweltbedingungen
Mit Umweltbedingungen werden die aus den Sensordaten abgeleiteten Informationen über die Umwelt bezeichnet. Diese finden sich in Abbildung 4.2. Die Informationen werden als DatatypeProperty der Klasse Umwelt modelliert. Alle diese
Eigenschaften sind funktional, das heißt sie haben maximal eine Kardinalität von
Eins.
Die Eigenschaften lassen sich in drei Typen unterscheiden. Der erste Typ sind
Bedingungen, die entweder gelten oder nicht gelten:
• Mit der Property naesse wird angegeben, ob die Fahrbahn offensichtlich nass
ist, oder ob die Wahrscheinlichkeit dafür gering ist.
• Die Property glatteisgefahr ist wahr, wenn die Bildung von Glatteis möglich ist.
Der zweite Typ beschreibt die Sichtverhältnisse. Die Beschreibung erfolgt nicht
durch Zahlen, sondern abstrakt durch Worte. Die Wertemenge der Eigenschaften
ist auf jeweils vier Worte beschränkt.
• Die helligkeit wird in vier Stufen eingeteilt, hell, duester, halbdunkel
und dunkel
• Die nebeldichte ist entweder stark, normal oder gering. Ebenso besteht
die Möglichkeit, dass es keinen Nebel gibt.
• Die aus helligkeit und nebeldichte abgeleiteten sichtverhaeltnisse
können gut, unguenstig, schlecht oder kritisch sein.
87
Abbildung 4.2: Die abgeleiteten Werte der Umweltontologie
88
Die restlichen drei Eigenschaften der Klasse Umwelt werden im Fahrerassistenten
nicht direkt verwendet. Sie dienen den sensor.rules zur Bestimmung der Sichtverhältnisse aus den Sensorwerten. Die ersten zwei liefern Werte zwischen Null und
Eins, die dritte gegebenenfalls auch höhere.
• Die sicht_zahl ist das aus dem HelligkeitsSensor abgeleitete Helligkeitslevel. Ein Wert von Eins entspricht der maximalen Dunkelheit.
• Die nebel_zahl leitet sich aus dem NebelSensor ab. Je höher die Zahl, desto
höher die Nebeldichte.
• der Wert sichtplusnebel ergibt sich durch Addition der nebel_zahl und
der sicht_zahl. Ein Wert von Null entspricht guten sichtverhaeltnissen,
ein Wert von Eins kritischen.
Mit Hilfe der Umweltontologie können also die Sensoren und die aus ihnen abgeleiteten Umweltfaktoren modelliert werden. Die Umweltfaktoren kann der Fahrerassistent dann aus der Ontologie ablesen und die Reaktionen auf eine mögliche
Kollision an sie anpassen.
Es besteht keine Verbindung zwischen Umweltontologie und Fahrzeugontologie.
Letztere muss also nicht angepasst werden, damit der Fahrerassistent auf Informationen über die Umwelt zurückgreifen kann.
Regelsatz
Der genaue Zusammenhang zwischen Sensordaten und Umweltfaktoren wird in den
sensor.rules formalisiert. Die komplette Datei findet sich auf der beiliegenden
CD, hier werden nur Teile aus dem Regelsatz erläutert.
Die Umweltfaktoren glatteisgefahr und naesse können direkt aus den Sensordaten abgeleitet werden. Ihre Funktionsweise wird am Beispiel folgender Regel
erläutert:
# Glatteisgefahr
[rule1:
(?s kontext:temperatur_sensor ?t) le(?t,4)
(?u rdf:type kontext:Umwelt)
->
(?u kontext:glatteisgefahr ’true’^^bool:)
]
Die Voraussetzungen dieser Regel sind, dass es eine Property temperatur_sensor
gibt, deren Wert geringer als Vier ist, und eine Instanz vom Typ Umwelt. Ist dies
der Fall, dann erhält die Umwelt-Instanz die Eigenschaft glatteisgefahr, deren
Wahrheitswert true ist. Diese Regel besagt also, dass wenn die Temperatur weniger als 4◦ C beträgt, Glatteisgefahr besteht. Ebenso gibt es eine Regel, die bei
Temperaturen über 4◦ C die Glatteisgefahr mit false angibt. Die beiden Regeln
89
für naesse sind ähnlich aufgebaut, nur dass der überprüfte Sensor der Niederschlagssensor ist. Die Regeln für die sicht_zahl und die nebel_zahl benötigen
ebenfalls nur den Wert eines Sensors.
# Nebel als Zahl
[rule10:
(?s kontext:nebel_sensor ?x)
le(?x,150) greaterThan(?x,100)
->
(?u kontext:nebel_zahl ’0.3’^^float:)
]
Die Voraussetzungen sind hier ähnlich zu denen der glatteisgefahr und der
naesse. Einziger Unterschied ist es, dass der Wert des Sensors in einem oben und
unten beschränkten Bereich liegen muss. Diese Regel legt also fest, dass bei einer
Sichtweite zwischen 100 und 150 Metern die nebel_zahl den Wert 0,3 hat. Für
jede der beiden Eigenschaften gibt es vier solcher Regeln, eine höhere Genauigkeit würde entsprechend mehr Regeln erfordern. Mit Hilfe der sicht_zahl und
der nebel_zahl kann nun auch der Wert der Eigenschaft sichtplusnebel mit
folgender Regel berechnet werden:
# Sicht plus Nebel
[rule21:
(?u kontext:sicht_zahl ?x) (?u kontext:nebel_zahl ?y)
(?u rdf:type kontext:Umwelt) sum(?x,?y,?z)
->
(?u kontext:sichtplusnebel ?z)
]
Diese Regel addiert die sicht_zahl mit der nebel_zahl, vorausgesetzt dass beide als Eigenschaft derselben Umwelt-Instanz existieren, und fügt den berechneten Wert als sichtplusnebel zur Umwelt-Instanz dazu. Wenn zum Beispiel die
Sichtbehinderung durch Nebel 30% beträgt (entspricht einem Wert von 0,3) und
mangelnde Helligkeit die Sicht um 40% behindert, dann berechnet diese Regel eine
Sichtbehinderung von 70%.
Man beachte, dass die Reihenfolge, in der die Regeln angewendet werden, nicht
festgelegt werden kann. Der Reasoner überprüft aber nach jeder erfolgreichen Regelanwendung den Regelsatz erneut, so dass die Addition erst dann erfolgt, wenn
sicht_zahl und nebel_zahl schon abgeleitet wurden.
Mit Hilfe der sicht_zahl, der nebel_zahl und von sichtplusnebel können
nun die letzten drei Eigenschaften der Umwelt bestimmt werden:
90
# Sichtverhaeltnisse, abstrakt
[rule25:
(?u kontext:sichtplusnebel ?z) greaterThan(?z,0.75)
->
(?u kontext:sichtverhaeltnisse ’kritisch’^^string:)
]
Diese Regel legt fest, dass ein Wert von sichtplusnebel, der echt größer als 0,75
ist, mit kritischen Sichtverhältnissen gleichzusetzen ist. Für die Bereiche von
z ≤ 0.25, 0.25 < z ≤ 0.50 und 0.50 < z ≤ 0.75 existieren ähnliche Regeln.
Der Regelsatz leitet also Glatteisgefahr und die Möglichkeit einer nassen Fahrbahn direkt aus den Sensorwerten ab. Die Helligkeit und die Nebeldichte werden
über den Umweg einer Zahl festgelegt. Natürlich wäre es auch möglich sie direkt
zu bestimmen, aber für die Sichtverhältnisse ist der indirekte Weg über die Zahlen
wesentlich praktischer als ein Regelsatz, der alle möglichen Kombinationen von
Nebelwerten und Lichtstärken berücksichtigt.
Die Definition der Sichtverhältnisse ist mit diesen Werten natürlich nicht unbedingt sinnvoll, was aber auch nicht das Ziel der Arbeit ist. Vielmehr soll gezeigt
werden, wie es prinzipiell möglich ist, aus reinen Sensordaten abstraktere Informationen über die Umwelt zu erhalten.
4.3.2 Straßenontologie
Die Straßenontologie modelliert das Straßennetz. Nicht alle hier beschriebenen
Konzepte werden auch vom Fahrerassistenten, so wie er implementiert ist, genutzt. Neue Anwendungen, die auch Konzepte wie Verkehrsschilder oder Straßenzustand berücksichtigen, sind aber natürlich ebenso denkbar. Ein paar dieser
Einsatzmöglichkeiten werden in Kapitel 5 erläutert.
Die Straßenontologie enthält, im Vergleich zu den bisher beschriebenen Ontologien, relativ viele Konzepte, die durch Properties miteinander verbunden sind.
Das komplette Modell ist aus Gründen der Übersichtlichkeit auf die beiden Abbildungen 4.3 und 4.4 aufgespalten.
Das Straßennetz
Das Straßennetz wird als Graph modelliert. Die Kreuzungen sind die Knoten des
Graphen, die Straßen die Kanten. Eine Modellierung als Graph bietet den Vorteil,
dass viele Problemstellungen, die Graphen betreffen, Gegenstand der Forschung
waren oder sind und deshalb auch häufig effiziente Algorithmen zur Lösung derselben bekannt sind. Ein Beispiel für Probleme, die mit Hilfe der Graphentheorie
gelöst werden könnten, ist der kürzeste Weg zwischen zwei Knoten, der entweder für einen Routenplaner, der sich des Fahrzeugmodells bedient, interessant sein
könnte, oder auch für die Frage, wann zwei Fahrzeuge frühestens miteinander kollidieren können. Die Frage, ob es überhaupt zur Kollision kommen kann, könnte
91
Abbildung 4.3: Straßen und Kreuzungen
92
durch die Zerlegung des Straßengraphen in seine Zusammenhangskomponenten
und einen Test, in welcher sich die einzelnen Fahrzeuge überhaupt befinden, beantwortet werden. Mit Zusammenhangskomponenten werden die maximalen Teilgraphen bezeichnet, in denen alle Knoten über Kanten miteinander verbunden
sind. Die Modellierung des Straßennetzes als Graph, also als Netz von Knoten und
Verbindungen zwischen diesen, kommt auch dem menschlichen Verständnis recht
nahe, wie sich im Begriff Straßennetz zeigt.
Die einzelnen Konzepte dieses Teils der Straßenontologie, wie er in Abbildung
4.3 gezeigt wird, werden in folgender Aufzählung genauer beschrieben:
• Das Strassennetz enthält allen Knoten und Kanten des Graphen, also alle
Abschnitte. Diese erfolgt über die Property abschnitte. Eine Unterscheidung in eine Knoten- und Kantenmenge ist nicht nötig1 , kann aber bei Bedarf
leicht definiert werden.
• Die Abschnitte eines Straßennetzes, also die Kreuzungen und die Straßen,
werden durch vier Eigenschaften genauer gekennzeichnet. Ihre ganzzahlige
id dient der eindeutigen Identifikation. Ihr zustand kann entweder gut oder
schlecht sein. Der belag eines Abschnitts besteht entweder aus Schotter,
Beton oder Asphalt. Die transitive Property erreichbar kann im Gegensatz zu den anderen drei Properties auch auf mehrere Werte verweisen. Dies
sind weitere Abschnitte, mit denen eine direkte oder indirekte Verbindung
besteht.
• Die Klasse Kreuzung ist eine Unterklasse von Abschnitt und disjunkt mit
der Klasse Strasse. Die boolesche Property ampel gibt an, ob es eine solche
an der Kreuzung gibt. Die zufahrten sind die in die Kreuzung einmündenden
Strassen. Es gibt drei Arten von Kreuzungen. Die Unechte_Kreuzung verbindet genau zwei Strassen miteinander, ist also ein Hilfskonstrukt zur Zerlegung einer langen Strasse in mehrere Abschnitte, die zum Beispiel einen
unterschiedlichen Belag haben. Ein Endpunkt hat nur eine zufahrt und ist
ein Ergebnis der Festlegung, dass eine Strasse immer zwei Kreuzungen miteinander verbindet. Eine Echte_Kreuzung hingegen ist jede Kreuzung, die
mehr als drei zufahrten hat, also das, was man normalerweise als Kreuzung
oder Einfahrt bezeichnet.
• Die Klasse Strasse ist ebenfalls eine Unterklasse von Abschnitt. Ihre eigenen drei disjunkten Unterklassen sind Autobahn, Landstrasse und InStadt.
Jede Strasse ist über die Properties kreuzung_1 und kreuzung_2 mit den
beiden inzidenten Kreuzungen verbunden. Ob sie als Vorfahrtsstraße in die
jeweiligen Kreuzungen mündet, geben die beiden Properties vorfahrt_1 und
vorfahrt_2 an. Des Weiteren hat jede Strasse einen namen, eine zulässige
1
SPARQL-Anfragen der Form SELECT ?x WHERE (?x rdf:type Kreuzung . ?z abschnitte ?x) liefern
zum Beispiel das gewünschte Ergebnis
93
hoechstgeschwindigkeit und eine laenge, ebenso wie kurven und mindestens eine spur.
Erweiterungen für Straßen
Wie bei der Beschreibung der Klasse Strasse durch die Properties kurven und
spuren schon angedeutet, existieren noch weitere Konzepte zur Modellierung des
Straßennetzes, die eine genauere Beschreibung der einzelnen Straßen ermöglichen.
Es folgt eine Aufzählung dieser Konzepte, die in Abbildung 4.4 gezeigt werden:
• Eine Strasse hat mindestens eine Spur. Spuren haben wie Strassen eine id. Die Klasse Spur ist disjunkt mit der Klasse Abschnitt und Kurve.
Bei der erlaubten Fahrtrichtung der Spur sind drei Fälle möglich. Entweder ist sie in Beide Richtungen befahrbar, oder nur von Fahrzeugen die von
kreuzung_1 der dazugehörigen Strasse kommen (Von1), beziehungsweise
von kreuzung_2 (Von2). Die in einer Spur gültigen Verkehrsschilder werden über die Property schilder erfasst.
• Die Klasse Kurve beschreibt die in einer Strasse vorhandenen Kurven. Sie
ist disjunkt mit den Klassen Abschnitt und Spur. Es gibt drei Arten von
Kurven. Eine Einfache_Kurve ist nur in eine Richtung gekrümmt. Eine
S_Kurve dagegen besteht aus einer Krümmung in die eine und einer darauf
folgenden Krümmung in die entgegengesetzte Richtung. Der dritte Kurventyp
ist eine Serpentine, die eine Kurve mit einer Krümmung von nahezu 180◦
beschreibt. Des Weiteren werden Kurven durch drei Eigenschaften charakterisiert. Die erste ist ihre position. Diese ist durch Messung des Abstands
des Kurvenbeginns von kreuzung_1 in Metern gegeben. Die zweite Property
ist die laenge der Kurve, die dritte ihre kruemmung, gemessen in Grad.
• Die Funktionen von Verkehrsschildern werden hier nicht modelliert, die unterschiedlichen Schilder müssten als separate Unterklassen definiert werden.
Die beiden Properties position und laenge legen den Geltungsbereich eines
Verkehrsschilds fest. Wie bei einer Kurve ist die position der Beginn des
Geltungsbereichs, der sich über die gegebene laenge erstreckt.
Das hier erläuterte Modell des Straßennetzes bietet alle nötigen Konzepte, um das
von VIS SIM generierte Straßennetz zu beschreiben. Andere Konzepte kommen
in VIS SIM gar nicht vor, wie zum Beispiel der Zustand einer Straße oder der
Straßenbelag.
Der Fahrerassistent verwendet die Straßenontologie nur um herauszufinden, ob
zwei Fahrzeuge sich auf Straßenabschnitten befinden, die direkt oder indirekt miteinander verbunden sind. Für ihn ist also nur die Property erreichbar von Interesse. Das Modell wurde aber detaillierter ausgestaltet, um zeigen zu können,
welche zusätzlichen Anwendungsmöglichkeiten sich für eine Straßenontologie ergeben (siehe Kapitel 5).
94
Abbildung 4.4: Spuren, Kurven und Verkehrsschilder
95
4.3.3 Erweiterung der Fahrzeugontologie
Um die Verbindung zwischen Fahrzeugen und Straßen herzustellen, wird die Fahrzeugontologie erweitert. Die einzige notwendige Erweiterung besteht darin, dass
jedes Fahrzeug einen strassen_Abschnitt zugeordnet bekommt. Dies ist der
Abschnitt des Straßennetzes, auf dem es sich gerade befindet. Hierzu muss die
Straßenontologie in die Fahrzeugontologie importiert werden. Anders als bei der
Umweltontologie sind die beiden Modelle also nicht voneinander getrennt, die Fahrzeugontologie bedient sich des Modells des Straßennetzes um die Position des Fahrzeuges in selbigem zu beschreiben.
Die korrekte Instanziierung der Fahrzeuge setzt somit voraus, dass aus der absoluten Position des Fahrzeuges der dazugehörige Straßenabschnitt bestimmt werden
kann. In VIS SIM sind den Fahrzeugen ihre Straßenabschnitte bekannt, bei einem
Einsatz in einem richtigen Fahrzeug wäre es ebenfalls möglich diese Informationen
zu berechnen, wenn genügend Daten über das Straßennetz vorliegen.
Der externe Regelsatz der Fahrzeugontologie wird ebenfalls um eine Regel erweitert. Die verwendeten Jena-Reasoner scheinen die transitive Hülle der Property
erreichbar nicht abzuleiten, weshalb immer nur direkt verbundene Kreuzungen
und Straßenabschnitte als erreichbar betrachtet werden. Es wird also eine neue
Regel eingeführt, die das Problem behebt und den Reasoner die transitive Hülle
ableiten lässt:
# Erreichbarkeit
[rule0:
(?a street:erreichbar ?b) (?b street:erreichbar ?c)
->
(?a street:erreichbar ?c)
]
Problematisch an diesem Ansatz ist, dass diese Regel bei jeder Instanziierung der
Fahrzeuge erneut zum Einsatz kommt und die Simulation zumindest bei einer
größeren Anzahl von Straßenabschnitten erheblich verlangsamt. Dies ist aber nur
ein Problem der Implementierung, nicht des Straßenmodells oder der veränderten
Fahrzeugontologie, wie sich bei Testläufen ohne diese Regel zeigt.
4.4 Änderungen an der restlichen Implementierung
Die Erweiterung des Fahrerassistenten um Umwelt- und Straßenontologie erfordert
ein paar Anpassungen in der Implementierung. Beide Ontologien benötigen Daten,
mit denen sie instanziiert werden können. Die Sensordaten für die Umweltontologie
werden einfach in OntoCar von der Methode produceSensorData() auf konstante
Werte gesetzt, da der Simulator diese nicht erzeugen kann. Das Straßennetz wird
dagegen zu Beginn einmal vom OntoCar direkt aus dem Simulator ausgelesen und
96
in eine eigene Struktur übersetzt, die neue Klasse StreetNet. Diese enthält Daten
zu Kreuzungen, Straßen und Spuren, beschränkt sich aber auf Informationen über
Identität und Struktur, also welche Straße mit welcher Kreuzung verbunden ist,
beziehungsweise welche Spur zu welcher Straße gehört. Diese Informationen sind
für die erweiterte Funktionsweise des Fahrerassistenten ausreichend. Der OntoCar
übergibt das StreetNet an InputOutput, von wo es dann der OntoAssistant
ausliest. Dieser überreicht die Daten schließlich an die ExtOntology, die damit die
erweiterte Fahrzeug- beziehungsweise Straßenontologie instanziiert.
Zur Informationsbeschaffung werden die benötigten Informationen zu Straßenund Sichtverhältnissen aus der Umweltontologie ausgelesen. Da es sich nur um
einfache Sensorwerte handelt, zwischen denen keinerlei Zusammenhang besteht,
werden für die Anfrage in Inquiry einfache Jena-Methoden verwendet und kein
SPARQL-Query. Die Anfrage an die Fahrzeugontologie hingegen ist komplexer und
wird deshalb mit einem SPARQL-Query formuliert.
SELECT ?x
WHERE
{
?x rdf:type kontext:Andere_Fahrzeuge .
?y rdf:type kontext:Eigenes_Fahrzeug .
?x kontext:strassen_Abschnitt ?a .
?y kontext:strassen_Abschnitt ?b .
?a street:erreichbar ?b
}
Diese Anfrage liefert alle Anderen_Fahrzeuge, die sich auf einem Straßenabschnitt
befinden, der vom Abschnitt des Eigenen_Fahrzeugs aus erreichbar ist. Die Anfrage macht für das in VIS SIM simulierte kleine Straßennetz Sinn, um die Anzahl der
möglichen Kollisionspartner einzuschränken, bei einem größeren Straßennetz aber
wären Anfragen, die zusätzlich auch die Distanz zwischen Fahrzeugen oder Straßenabschnitten berücksichtigen, sinnvoller. Hierzu könnte man zum Beispiel die
Properties distance und value, die den Abstand zweier Fahrzeuge berechnen, für
die Fahrzeugontologie definieren und den obigen Query um folgende Ausdrücke für
die WHERE-Klausel erweitern. Die etwas umständliche Beschreibung des Abstandes
?d der beiden Fahrzeuge ?x und ?y ist bedingt durch die Tripelstruktur von RDF.
?x distance ?z .
?y distance ?z .
?z value ?d .
FILTER (?d <= 200)
Diese Erweiterung würde die Rückgabe auf die Anderen_Fahrzeuge beschränken,
die einen Abstand von weniger als 200 Meter zum Eigenen_Fahrzeug haben.
97
Die eigentlichen Kollisionsberechnungen müssen nicht verändert werden, da die
verbesserte Auswahl der Fahrzeuge durch den Query erfolgt. Um auf die gewonnenen Informationen zur Umwelt reagieren zu können, wird in der Klasse Car eine
Anpassung des Gefahrenlevels vorgenommen. Je schlechter die Bedingungen, desto
früher erfolgen Warnungen und Notbremsungen.
4.5 Ergebnisse
Zuerst lässt sich feststellen, dass die Geschwindigkeit des Fahrerassistenten durch
die Einführung der Umweltontologie nicht merklich beeinflusst wird. Wie in Abbildung 4.5 zu sehen ist, verlangsamt die Straßenontologie dagegen den Fahrerassistenten merklich, wobei die eigentlich unnötige Erreichbarkeitsregel hier bei weitem
den größten Einfluss hat. Die in 4.5 dargestellte Simulation verwendet ein Straßennetz, das aus 33 Straßenabschnitten besteht, die alle miteinander verbunden sind.
Führt man einen Test mit einem ähnlich großen Straßennetz durch, bei dem aber
keine Verbindungen zwischen den Straßen bestehen, und somit die Erreichbarkeitsregel nie zum Einsatz kommt, ist die mit dem Straßennetz erweiterte Version des
Fahrerassistenten sogar schneller (siehe Abbildung 5.1).
t[s]
50
rs rs
40
mit Straßennetz
rs
rs
rs
t
u
rs
ohne Sraßennetz
t
u
rs rs
30
rs
20
rs
10
sr rs
rs
rs
rs
t
tu
u
tu
t u
tu
tu
0
0
10
rs
rs
t
u
t
t u
u
20
30
t
u
t
u
40
t
u
t
t u
u
50
t
u
60
t
u
t
u
70
t
t u
t u
u
80
t
u
t
u
t
u
90
t
tu
u
t
u
t
u
100
n
Abbildung 4.5: Vergleich der Geschwindigkeit mit und ohne Straßennetz
Wie aus 4.5 ersichtlich, steigt der Rechenaufwand auch für die mit dem Straßennetz erweiterte Variante des Fahrerassistenten linear zur Anzahl der Fahrzeuge
im hier getesteten Bereich. Die Komplexität beträgt also O(n). Aussagen über
den Einfluss der Anzahl der Straßenabschnitte sind schwieriger zu treffen, da es
hier stark auf die Anzahl der Verbindungen zwischen den Abschnitten ankommt
(Erreichbarkeitsregel). Außerdem kommen ständig neue Fahrzeuge zur Simulation
98
hinzu, die erst einmal die aufwändige Initialisierung vornehmen müssen und somit
die Messwerte verfälschen. Wird die Erreichbarkeitsregel aber nur einmal bei der
Initialisierung angewendet, werden bei jedem Straßenabschnitt in der Ontologie
alle erreichbaren Straßenabschnitte direkt abgespeichert. Somit ist die Anfrage an
“alle Fahrzeuge auf einem erreichbaren Abschnitt” höchstens linear von der Anzahl
m der Straßenabschnitte abhängig, da maximal m Abschnitte überprüft werden
müssen. Also ist in diesem Falle auch die Laufzeit des Assistenten linear im Bezug
auf den Umfang des Straßennetzes, die Komplexität beträgt O(m).
Die Initialisierung des Straßennetzes, die ebenfalls zur Verlangsamung beiträgt,
erfolgt nur einmal pro Fahrzeug. Es zeigt sich also, dass Ableitungen mit externen
Regeln oder sonstige rechenintensive Operationen auf der Ontologie, bei einem
etwas umfangreicheren Straßennetz möglichst selten durchgeführt werden sollten,
weil sie die Geschwindigkeit des Fahrerassistenten reduzieren können. Da aber
Änderungen im Straßennetz an sich nur selten auftreten, ist dies prinzipiell auch
möglich.
Mit Hilfe der Umweltontologie können aus einfachen Sensordaten Informationen
über die allgemeinen Umweltfaktoren abgeleitet werden. Diese können der Kontrolleinheit zur Verfügung gestellt werden, um die Reaktion auf eine Gefahrensituation an diese Faktoren anzupassen. Hier wird nur eine Erhöhung des Gefahrenlevels implementiert, es wäre aber zum Beispiel auch ein anderes Bremsverhalten
bei Glatteis oder Nässe, Einschalten der Nebelscheinwerfer oder eine Warnung bei
Glatteis und Fahren mit Sommerreifen denkbar.
Eine unabhängige Umweltontologie ermöglicht es unter anderem auch, die Häufigkeit der Instanziierung von Umwelt- und Fahrzeugontologie anzupassen, beziehungsweise die Häufigkeit, mit der der Reasoner den externen Regelsatz anwendet.
Dies ist bei der Straßenontologie nicht möglich, was bei dieser Implementierung
zu unnötigem zusätzlichen Rechenaufwand durch die ständige Anwendung der Erreichbarkeitsregel führt. Die Integration von Umwelt- und Straßenontologie bereitet keine Probleme, vor allem der Import der Straßenontologie zeigt, wie leicht ein
bereits vorhandenes Modell um völlig neue Konzepte erweitert werden kann.
Die zusätzliche Information, ob sich Fahrzeuge auf miteinander verbundenen
Straßenabschnitten befinden, erlaubt eine verbesserte Kollisionsprognose. Es ist
sozusagen möglich, das Fahrzeugverhalten in gewisser Weise vorauszusagen, da
man weiß, dass Fahrzeuge nur auf Straßenabschnitte gelangen können, die von
ihrer Position aus erreichbar sind. Also können sich auch nur Fahrzeuge, die sich
auf zusammenhängenden Abschnitten befinden, treffen. Somit ist es möglich die
Fahrzeugauswahl einzuschränken und unmögliche Unfälle auszuschließen. Je nach
Struktur des Straßennetzes wird die Fehlerquote mehr oder weniger stark verringert.
Ein Vorteil dieser Auswahlbeschränkung ist es auch, dass sie nur unmögliche
Unfälle ausschließt, aber keine potentiellen Kollisionspartner aus der Auswahl entfernt. Die Wahrscheinlichkeit, dass ein Unfall übersehen wird, steigt also nicht an,
99
dagegen sinkt die Wahrscheinlichkeit, dass ein harmloses Fahrzeug als gefährlich
angesehen wird. Dies setzt natürlich voraus, dass die Informationen über das Straßennetz korrekt und vollständig sind. Ist dies der Fall, dann führt die Erweiterung
des Kontexts um das Straßennetz bei dieser Anwendung nur zu besseren Ergebnissen, eine Verschlechterung ist nicht möglich. Allerdings kann die Erhöhung der
Rechenzeit bei größeren Straßennetzen kritische Ausmaße annehmen.
100
5 Vergleich und Schlussfolgerungen
In diesem Kapitel werden zuerst die beiden Versionen des Fahrerassistenten, wie
sie in Kapitel 3 und 4 beschrieben werden, miteinander verglichen. Dann wird
untersucht, inwieweit sich die entwickelten Ontologien und der Fahrerassistent für
weitere Anwendungen im Bereich der Kollisionsvermeidung erweitern lassen, und
welche Verallgemeinerungen der Ontologie denkbar sind. Zum Schluss wird noch
auf die Anpassungsfähigkeit der Ontologien und ihre Grenzen eingegangen.
5.1 Vergleich der beiden Szenarien
Die beiden Versionen des Fahrerassistenten werden anhand von drei unterschiedlichen Kriterien verglichen. Dies sind die erstens die Anforderungen, die sie an die
Datenbeschaffung stellen, zweitens die Geschwindigkeit, mit der die notwendigen
Operationen durchgeführt werden können und drittens die Qualität der erzielten
Ergebnisse.
Anforderungen
Im ersten Szenario beschränkt sich der Datensatz auf die Fahrzeugdaten. Jedes
Fahrzeug muss in der Lage sein seine Position, Richtung, Geschwindigkeit und
Beschleunigung eindeutig zu bestimmen. Außerdem benötigen die Fahrzeuge Sender und Empfänger, mit denen sie diese Daten an andere Fahrzeuge, die sich in
der Reichweite ihrer Sender befinden, verschicken. Dies muss regelmäßig und sehr
häufig passieren, da aktuelle, präzise Daten die Voraussetzung für eine korrekte Kollisionsvorhersage sind. Außerdem sollte noch der Fahrzeugtyp bekannt sein
und den anderen Fahrzeugen ebenfalls mitgeteilt werden. Ist dies nicht der Fall,
dann kann auch mit vordefinierten Standardfahrzeugen gearbeitet werden, was
aber natürlich zu schlechteren Ergebnissen führt, da die richtigen Maße und Fahrzeugdaten, wie die maximale Beschleunigung, der Fahrzeuge nicht bekannt sind.
Das zweite Szenario baut auf dem ersten auf. Deshalb benötigt es auch alle Daten, die im ersten Voraussetzung für ein Funktionieren des Fahrerassistenten sind.
Somit sind die Anforderungen an die Datenbeschaffung mindestens so hoch wie
bei der ersten Version des Fahrerassistenten. Da sich die Erfassung des Kontextes
nicht mehr nur auf die Fahrzeugdaten beschränkt, sind weitere Informationsquellen nötig. Die Umweltontologie setzt das Vorhandensein mehrerer Sensoren im
Fahrzeug voraus. Dies sind ein Regensensor, ein Helligkeitssensor, ein Nebelsensor und ein Temperatursensor. Bis auf den Nebelsensor sind diese Sensoren in
den meisten Fahrzeugen vorhanden, eine Erweiterung um Kontextinformationen
101
bezüglich dieser Umweltdaten ist also unproblematisch und stellt keine hohen Anforderungen an die Technik des Fahrzeugs. Die Straßenontologie dagegen benötigt
zusätzliche externe Informationsquellen. Um sie sinnvoll einsetzten zu können,
muss eine exakte Karte des Straßennetzes in einem Format vorliegen, das zur
Instanziierung des Straßenmodells genügend Informationen enthält. Ebenso wird
ein Übersetzungsprogramm benötigt, das aus schon vorhandenen, elektronischen
Karten das Straßenmodell instanziiert. Elektronische Straßenkarten existieren bereits für die unterschiedlichsten Routenplaner und Navigationssysteme, es wäre
also denkbar diese als Informationsquelle zu nutzen. Des Weiteren muss es möglich
sein, aus der Position des Fahrzeugs den dazugehörigen Straßenabschnitt zu bestimmen. Diese Zuordnung muss sehr schnell erfolgen, da sie bei jeder Änderung
der Positionsdaten nötig ist. Das Einlesen der Straßenkarte dagegen kann auch
länger dauern, da es nur einmal zu Beginn der Fahrt erfolgt. Es ist zu beachten,
dass das Straßenmodell vollständig bezüglich der Straßenabschnitte und ihrer Verbindungen sein muss, da es sonst passieren kann, dass Gefahrensituationen nicht
als solche erkannt werden.
Ein Vergleich bezüglich der Anforderungen der beiden Versionen an die Datenbeschaffung ergibt also, dass die erweiterte Version sowohl alle Daten der ersten Version benötigt, als auch die Existenz zusätzlicher Informationsquellen voraussetzt. Dies sind Sensordaten des eigenen Fahrzeugs und externe elektronische
Straßenkarten. Im Simulator VIS SIM ist nur letzteres vorhanden, in der Realität
existiert schon eine Vielzahl von Sensoren in den Fahrzeugen, die die benötigten
Daten zur Verfügung stellen. Straßenkarten gibt es ebenfalls, hier wird nur ein
Parser benötigt, der die gewünschten Daten aus der Karte ausliest. Ein Problem
könnte sich durch die Forderung nach Vollständigkeit ergeben. Wenn die Karte des
Straßennetzes nicht vollständig ist, dann kann es sein, dass Kollisionen übersehen
werden, da sie vom Assistenten als unmöglich angesehen werden, weil ihm die
entscheidende Straßenverbindung nicht bekannt ist. Ansonsten stehen die für die
zweite Version zusätzlich benötigten Daten theoretisch alle zur Verfügung
Sind die Anforderungen der ersten Version, also genaue Positionsbestimmung
und Ausstattung aller Fahrzeuge mit Sendern und Empfängern zur Datenübertragung, erfüllt, dann steht einer Erweiterung mit zusätzlichen Kontextinformationen zu Straßennetz und Umweltfaktoren nichts im Weg.
Geschwindigkeit
Das zweite Vergleichskriterium ist die Geschwindigkeit. Bei der einfachen Version
des Fahrerassistenten ist sie hauptsächlich von der Anzahl der Fahrzeuge abhängig.
Bei einer geringen Anzahl von Fahrzeugen läuft die Simulation problemlos, steigt
die Zahl der Verkehrsteilnehmer aber an, dann verlangsamt sich die Simulation
merklich. Dies kann zwei Ursachen haben. Erstens wird die Verwaltung der Ontologie aufwendiger, wenn eine große Anzahl von Instanzen in ihr gespeichert wird.
Zweitens nimmt natürlich auch der Rechenaufwand bei einer steigenden Zahl von
zu simulierenden Fahrzeugen im Quadrat zur Anzahl zu, da erstens die Berechnun-
102
gen pro Fahrzeug steigen und zweitens diese Berechnungen auch für jedes Fahrzeug
einzeln durchgeführt werden. Das erste Problem kann durch eine Beschränkung
der Instanzenzahl durch Filter und eine effiziente Implementierung der Ontologieverwaltung angegangen werden (siehe Abschnitt 3.6.1). Das zweite Problem, die
quadratische Zunahme des Rechenaufwandes, ist nur in der Simulation gegeben,
da hier ein Rechner die Aufgabe aller Rechner in den Fahrzeugen übernimmt.
Der Rechenaufwand pro Fahrzeug steigt für einen einzelnen Fahrerassistenten nur
linear an, da für das eigene Fahrzeug die Kollisionsgefahr mit jedem anderen Verkehrsteilnehmer berechnet wird.
Die erweiterte Version des Fahrerassistenten benötigt für die eigentliche Kollisionsberechnung pro Fahrzeug zwar die gleiche Zeit, dafür muss sie die Berechnungen
für weniger Fahrzeuge durchführen, wenn das Straßennetz aus verschiedenen Zusammenhangskomponenten besteht. Andererseits ist aber die Anfrage an die Fahrzeugontologie komplexer. Inwieweit dies die Geschwindigkeit des Fahrerassistenten
beeinflusst, hängt von der genauen Formulierung der Anfrage und der Implementierung der Programmierschnittstelle ab. Das Einlesen und die Instanziierung des
Straßennetzes hingegen verlangsamt den Fahrerassistenten merklich. In der Simulation macht es sich zwar nur kurz bemerkbar, hier liegt aber auch nur ein sehr
kleines Straßennetz vor. Insgesamt ergeben Tests mit beiden Versionen, dass die
erweiterte Version durch das Straßennetz merklich abgebremst wird. Je größer das
Netz, desto langsamer die Simulation. Dies liegt unter anderem auch an der eigentlich überflüssigen Erreichbarkeitsregel, die bei jedem Aufruf des Fahrerassistenten
die Erreichbarkeit für das komplette Straßennetz ableitet.
Eine wesentliche Geschwindigkeitsreduktion durch die Umweltontologie kann
nicht festgestellt werden. Dafür ist sie zu einfach gehalten und vor allem ist ihre
Instanzmenge sehr klein.
Somit lässt sich also feststellen, dass die erweiterte Version des Fahrerassistenten
tendenziell langsamer ist als die einfache. Dies liegt vor allem an der Straßenontologie, die Umweltontologie hat nur einen sehr geringen Einfluss auf die Geschwindigkeit. Je komplexer das Straßennetz, desto langsamer wird auch der Fahrerassistent.
Der einzige Fall, in dem das System mit Straßennetz schneller sein könnte als das
ohne, wäre, wenn es eine sehr große Anzahl von Fahrzeugen gibt, diese sich auf sehr
viele Zusammenhangskomponenten verteilen und somit bei einer Berücksichtigung
des Straßennetztes wesentlich weniger Kollisionsberechnungen durchzuführen sind.
Das Diagramm 5.1 zeigt einen Vergleich der beiden Varianten des Fahrerassistenten und des Simulators ohne den Assistenten. Wie zu erkennen ist, ist der
mit dem Straßennetz erweiterte Fahrerassistent einen Bruchteil schneller als die
einfache Variante des Assistenten. Das größte verwendete Straßennetz besteht aus
41 nicht verbundenen, parallelen Straßenabschnitten. Die Unterschiede in den Geschwindigkeiten, die sich bei einem Vergleich mit Diagramm 3.7 zeigen, nämlich
dass hier die Zeiten wesentlich niedriger sind, sind darauf zurückzuführen, dass es
bei diesen Straßennetzen zu keinerlei Bremsmanövern kommt und alle Fahrzeuge
103
sich mit konstanter, relativ hoher Geschwindigkeit bewegen. Der Fahrerassistent
führt also keine Berechnungen für zusätzliche Beschleunigungswarnungen durch.
Des Weiteren sind die Bahngeraden der Fahrzeuge lineare Gleichungen vom Typ
~s(t) = ~x + t · ~v , da die Beschleunigungskomponente wegfällt. Somit liefert die
Fourier-Motzkin-Elimination weniger Ungleichungen, die zudem alle linear und
nicht quadratisch sind. Damit ist auch der Fahrerassistent in 5.1 schneller als in
3.7 oder 4.5.
t[s]
5
t
pqu
ohne Straßennetz
4
u
t
qp
3
2
t
pqu
1
rs
mit Straßennetz
ohne Assistent
rs
rs
0
30
40
50
60
n
Abbildung 5.1: Vergleich der Simulationszeiten
Die Erweiterung des Modells um das Straßennetz bedarf also sorgfältiger Überlegungen, wie groß der jeweils instanziierte Abschnitt des Straßennetzes sein sollte.
Je größer, desto langsamer sind die Zugriffe auf die Ontologie, dafür muss das
Straßennetz seltener instanziiert werden. Vor allem aber sollte der Reasoner so
selten wie möglich auf das Straßennetz angesetzt werden, da dies zu erheblichen
Geschwindigkeitseinbußen führen kann, wie sich bei der Erreichbarkeitsregel zeigt
(siehe Abbildung 4.5).
Qualität
Zum Schluss soll noch die Qualität der Ergebnisse beider Versionen verglichen werden. Die erste Version liefert die besten Ergebnisse, wenn sich die Fahrzeugdaten
kaum ändern und vor allem wenn die Fahrbahnen gerade verlaufen und keine Kurven haben. Die Beschleunigungswarnung führt zu verbesserten Ergebnissen, wenn
es sich um stehende Fahrzeuge oder Fahrzeuge mit einer sehr geringen Geschwindigkeit handelt. Hier ist es möglich das Fahrerverhalten vorauszusagen, wodurch
die Änderung der Fahrzeugparameter abgeschätzt werden kann. Ansonsten stehen
mit den reinen Fahrzeugdaten nicht genügend Informationen zur Verfügung um
Voraussagen zum Fahrerverhalten zu treffen und so zum Beispiel mögliche Wege
104
eines Fahrzeugs zu bestimmen. Auch kann die Reaktion des Fahrerassistenten nicht
an die Umweltbedingungen angepasst werden, was zum Beispiel zu gefährlichen
Bremsmanövern bei Glatteis führen kann. Trotzdem liefert der Fahrerassistent vor
allem bei geradem Streckenverlauf brauchbare Ergebnisse und ermöglicht eine erhebliche Reduktion der Anzahl von Unfällen.
Die zweite Version des Fahrerassistenten soll ein paar dieser Mängel durch zusätzliche Kontextinformationen beheben, was auch gelingt. Die Einführung der
Umweltontologie erlaubt es je nach Situation unterschiedlich auf die erkannte Gefahr zu reagieren. So kann zum Beispiel je nach Sichtverhältnissen eine Warnung
früher oder später erfolgen, oder bei Glatteis das Bremsverhalten des Fahrzeugs angepasst werden. Die genaue Reaktion wird hier nicht implementiert, da der Simulator keine diesbezüglichen Tests ermöglicht. Die nötigen Informationen werden aber
zumindest teilweise bereitgestellt. Eine Erweiterung um zusätzliche gewünschte
Sensordaten und daraus abgeleitete Umweltfaktoren ist leicht durchführbar. Die
Straßenontologie bietet zahlreiche interessante Informationen zum Kontext eines
Fahrzeuges, hier wird aber nur eine genutzt. Weitere Möglichkeiten zum Einsatz
der Straßenontologie zur Kollisionsvermeidung werden im nächsten Abschnitt beschrieben. Die hier berücksichtigte Tatsache der Erreichbarkeit erlaubt es das Fahrerverhalten sehr grob abzuschätzen. Ein Fahrer kann sein Fahrzeug nämlich nur
auf einen Straßenabschnitt steuern, den er von seiner Position aus auch erreichen
kann. Diese Information erlaubt es die Anzahl der potentiellen Kollisionspartner zu
reduzieren. Das erzielte Ergebnis kann also, immer vorausgesetzt die Informationen
zum Straßenverlauf sind korrekt und vollständig, nicht schlechter sein als das mit
der ersten Version des Fahrerassistenten erzielten. Es ist zwar nicht möglich potentielle Kollisionen zu erkennen, die vorher übersehen wurden, aber dafür sinkt die
Anzahl der Fehlalarme. Da eine fälschlicherweise durchgeführte Notbremsung auch
eine Gefährdung der anderen Verkehrsteilnehmer darstellt, ist dies eine wichtige
Verbesserung für die Qualität der erzielten Ergebnisse.
Ein Vergleich der beiden Versionen zeigt also, dass die in der zweiten Version
vorgenommenen Erweiterungen auch die Qualität der Ergebnisse verbessern. Mit
Hilfe von zusätzlichen Kontextinformationen ist es also möglich Situationen besser
einzuschätzen und somit sowohl besser auf die einzelne Situation zu reagieren, als
auch die Fehlerquote des Fahrerassistenten zu verringern.
Zusammenfassung
Vergleicht man die beiden Versionen des Fahrerassistenten bezüglich Anforderungen, Geschwindigkeit und Qualität, stellt man fest, dass beide Vorteile und
Nachteile haben. Die einfachere Version stellt geringere Anforderungen an die Beschaffung von Daten und erweist sich auch als schneller. Die erweiterte Version
liefert dagegen bessere Ergebnisse. Es zeigt sich aber auch, dass die benötigten
zusätzlichen Daten relativ leicht zur Verfügung gestellt werden können. Das Problem der geringeren Geschwindigkeit lässt sich ebenfalls lösen, wenn Implementierung, Anfragen und Instanziierung der Straßenontologie optimiert werden. Somit
105
führt die Berücksichtigung der zusätzlichen Kontextinformationen zu einer besseren Version des Fahrerassistenten. Die besonderen Vorteile, die der Einsatz von
Ontologien hier mit sich bringt, wird in Kapitel 6 genauer erläutert. Weitere Einsatzmöglichkeiten der Kontextmodelle werden im nächsten Abschnitt aufgezählt.
5.2 Weitere Einsatzmöglichkeiten
Die Beschleunigungswarnung ist ein gutes Beispiel, wie mit Hilfe der vorhandenen Ontologien eine neue Anwendung entwickelt werden kann, die sich in diesem
Fall der Fahrzeugontologie bedient und keiner weiteren Modifikationen am Kontextmodell oder der Struktur der Architektur bedarf. Die Straßenontologie zeigt,
dass durch die Erweiterung des Kontextmodells eine Verbesserung der Kollisionsvorhersagen möglich ist. Diese Erweiterung erfordert nur wenige Anpassungen des
Fahrerassistenten, wenn man von der Entwicklung der Straßenontologie absieht.
Auch die Integration der Umweltontologie erfolgt ohne Schwierigkeiten. Man kann
also weiteren Kontext relativ einfach in die Berechnungen des Fahrerassistenten
einfließen lassen. Auch die Entwicklung und Integration neuer Anwendungen für
die vorhandenen oder erweiterten Ontologien ist möglich. In diesem Abschnitt werden neue Einsatzmöglichkeiten für die in dieser Arbeit entwickelten Ontologien
beschrieben, also denkbare Anwendungen und die sich daraus ergebenden Erweiterungen der Ontologien. Alle diese Anwendungen und Erweiterungen sollten mit
relativ geringem Aufwand zu verwirklichen sein.
Warnung bei Überholvorgängen
Eine interessante Anwendung wäre eine Unterstützung des Fahrers bei Überholvorgängen. Vor allem schlecht einzusehenden Kurven oder Fehleinschätzungen und
Unaufmerksamkeit der Fahrer können hier zu Gefahrensituationen führen. Eine
solche Anwendung könnte zum Beispiel vor entgegenkommenden Fahrzeugen warnen oder von Fahrzeugen, die sich dem eigenen schnell von hinten auf der Nebenspur nähern. Zwei denkbare Varianten einer derartigen Überholwarnung werden
hier erläutert.
Die erste berechnet mögliche Gefahren erst dann, wenn die Spur gewechselt wird.
Von hinten kommende Fahrzeuge werden hier eventuell zu spät, oder aber von der
Kollisionswarnung erkannt. Um die Gefahr, die von entgegenkommenden Fahrzeugen ausgeht, zu berechnen, muss deren Position auf der Straße und die eigene
bekannt sein. Aus dem Abstand lässt sich nun einfach der Kollisionszeitpunkt berechnen. Der Unterschied zur bisherigen Kollisionsberechnung besteht darin, dass
keine Richtungen oder Fahrzeuggrößen beachtet werden, sondern einfach aus der
Länge des Streckenabschnitts und den Geschwindigkeiten und Beschleunigungswerten der Fahrzeuge die Zeit bis zur Kollision ermittelt wird. Sobald dieser Zeitpunkt zu nahe kommt, erfolgt die Warnung. Dieses System ist relativ simpel und
erfordert nur die Kenntnis der relativen Position der Fahrzeuge auf ihrem Stra-
106
ßenabschnitt. Dieser kann Anhand einer externen elektronischen Karte ermittelt
werden und in der Fahrzeugontologie, die hierzu um eine Property erweitert werden muss, abgespeichert werden. Eine solche Überholwarnung würde immer aktiv
sein und gegebenenfalls auch vor Gegenverkehr auf der eigenen Spur warnen, da
die Situation des Überholvorgangs nicht erkannt wird.
Eine zweite Variante könnte versuchen, die Situation des Überholvorgangs zu
erkennen. Um zu überholen, muss die Spur gewechselt werden. Will der Fahrer die
Spur wechseln, dann setzt er den Blinker, so er sich korrekt verhält. Eine zweite
Möglichkeit wäre, dass er abbiegen will. Wenn also der Fahrer den Blinker setzt
und es keine Möglichkeit zum Abbiegen gibt, dann will er die Spur wechseln. Wird
der Blinker nach links gesetzt, und vor dem eigenen Fahrzeug befindet sich ein
anderes, dann handelt es sich wohl um ein Überholmanöver. Eine strengere Bedingung wäre, dass die linke Spur für den Gegenverkehr bestimmt ist, allerdings ist
dies zum Beispiel auf Autobahnen nicht der Fall. Mit diesen Informationen lässt
sich also die Absicht des Fahrers zu überholen erkennen. Der Assistent kann nun
überprüfen, was passieren würde, wenn das Fahrzeug sich auf der linken Spur befindet. Aus den Streckenpositionen der anderen Fahrzeuge auf dieser Spur und ihren
Geschwindigkeiten und Beschleunigungswerten kann nun die Unfallgefahr abgeleitet werden. Außerdem kann noch ermittelt werden, wie lange der Überholvorgang
wohl dauert, wenn der Fahrer das Fahrzeug voll beschleunigt und sich ungefähr an
die erlaubte Höchstgeschwindigkeit hält. Kommt es in dieser Zeit zu keiner Kollision mit dem Gegenverkehr, dann ist ein Überholvorgang möglich, ansonsten wird
der Fahrer vor dem Unfallrisiko gewarnt. Ebenso wäre es möglich den Fahrer zum
Beschleunigen aufzufordern, falls er den Überholvorgang zu langsam angeht. Im
Unterschied zur ersten denkbaren Variante erkennt diese die Absicht des Fahrers
und kann somit schon im Voraus berechnen, was passiert, wenn der Fahrer seine
Absicht in die Tat umsetzt. Die hierzu benötigten Informationen sind einfach modellierbar. Die Positionen der Fahrzeuge im Straßennetz müssen auch in der ersten
Variante bekannt sein. Die Information, ob der Blinker gesetzt ist, kann leicht von
entsprechenden Sensoren erhalten werden. Die relative Position, also dass sich ein
Fahrzeug vor dem eigenen befindet, ist aus der Position im Straßennetz ableitbar
und kann als Property ins Modell aufgenommen werden. In der Straßenontologie
muss noch die relative Lage der Spuren einer Straße zueinander definiert werden,
da der Fahrerassistent nur an den Fahrzeugen interessiert ist, die sich auf der Spur
links neben der eigenen befinden. Zu beachten ist die beschränkte Reichweite der
Sender. Es ist durchaus möglich, dass Gegenverkehr nicht erkannt wird, da noch
keine Daten von ihm empfangen werden. Hier könnte das eigene Fahrzeug bei anderen Fahrzeugen aktiv nachfragen, ob sie Daten über weitere Verkehrsteilnehmer
besitzen, die sich außerhalb der eigenen Reichweite befinden.
Fahrzeug- und Straßenontologie können also auch in einer Anwendung eingesetzt
werden, die den Fahrer bei Überholvorgängen unterstützt. Sie müssen nur mit sehr
wenigen zusätzlichen Konzepten erweitert werden, in der ersten Variante nur um
107
die Position der Fahrzeuge auf der Straße, in der zweiten zusätzlich um die beiden
Blinker und die relativ Lage der Spuren einer Straße. Diese Erweiterungen beeinflussen aber nicht die Funktionsweise der bisher implementierten Kollisionsweise,
außerdem sind keine echten Modifikationen an den Ontologien vorzunehmen, es
werden nur wenige zusätzliche Properties benötigt.
Erweiterung um Vorfahrtsregeln
Eine denkbare Erweiterung des Fahrerassistenten ist auch die Berücksichtigung
von Vorfahrtsregeln. Diese würden es ermöglichen, auf erkannte Gefahren differenzierter zu reagieren. Wenn das eigene Fahrzeug Vorfahrt hat, dann ist anzunehmen,
dass das andere abbremsen wird. Natürlich ist das nicht garantiert, deshalb sollte
die Gefahr nur geringer eingeschätzt werden, also zum Beispiel keine frühzeitige
Warnung gegeben und das Fahrzeug nur, wenn es absolut notwendig erscheint,
abgebremst werden.
Die Straßenontologie enthält schon eine einfache Modellierung der Vorfahrt, sie
gibt aber nur an, ob eine Straße in eine Kreuzung als Vorfahrtsstraße mündet. Hier
wäre eine detailliertere Modellierung wünschenswert. Vorfahrtsregeln sollten sich
immer auf zwei Straßenabschnitte beziehen, also wer vor wem Vorfahrt hat, da
es zum Beispiel auch abbiegende Vorfahrtsstraßen gibt. Wenn an einer Kreuzung
bekannt ist, wie die Vorfahrtstraße verläuft, dann lassen sich die Vorfahrtsregeln
für die einzelnen Abschnitte ableiten. Dies erfordert zusätzliche Properties und
einen entsprechenden Regelsatz.
Ein Problem könnten sich ändernde Vorfahrtsregeln darstellen. Ampeln müssten
mit Sendern ausgestattet werden, die es den Fahrzeugen erlauben die verschiedenen Phasen zu erkennen, oder die Fahrzeuge benötigen Kameras und eine gutes
Bilderkennungsprogramm. Außerdem muss die Straßenontologie nun regelmäßig
mit neuen Daten instanziiert werden, was zu Problemen mit der Geschwindigkeit
führen kann. Auch temporäre Änderungen der Vorfahrtsregeln durch neue Schilder, zum Beispiel an einer Baustelle, müssen beachtet werden. Hier bietet sich
wieder eine Kamera und ein entsprechendes Bilderkennungsprogramm an, oder
die Verkehrsschilder müssen mit Sendern versehen werden.
Wenn die Instanziierung der Straßenontologie mit neuen Daten effizient durchgeführt wird und das Regelsystem zur Ableitung der Vorfahrtsregeln so formalisiert
wird, dass diese Ableitung auch in angemessener Zeit durchgeführt werden kann,
ist eine Erweiterung der Straßenontologie mit Vorfahrtsregeln ohne Änderungen
an der Struktur der Ontologie durchführbar. Aus den Angaben, welche Straßen
als Vorfahrtsstraßen in eine Kreuzung münden, lassen sich die Vorfahrtsregeln für
alle Straßenabschnitte untereinander ableiten. Ampeln oder temporäre Verkehrsschilder ändern nichts an diesem Prinzip, sie überschreiben nur die bisher gültigen
Regeln.
Die Straßenontologie muss also sowohl um neue Konzepte, als auch um einen Regelsatz erweitert werden, Änderungen an der Struktur sind aber nicht notwendig.
Die notwendigen Erweiterungen sind umfangreicher als die, die bei der Implemen-
108
tierung einer Unterstützung von Überholvorgängen vorzunehmen sind. Bei den
notwendigen Erweiterungen sollte es keine Schwierigkeiten geben, problematischer
ist dagegen die Datenbeschaffung, da entweder das Fahrzeug mit neuer Technik
ausgestattet werden muss, oder alle Ampeln und Verkehrsschilder.
Die Beachtung der Verkehrsregeln bietet einerseits die Möglichkeit auf erkannte
Gefahren besser zu reagieren, andererseits besteht aber auch die Gefahr, dass Kollisionen zwar vorhergesehen werden, aber wegen Beachtung der Vorfahrtsregeln
nicht oder zu spät auf sie reagiert wird. Wenn zum Beispiel das eigene Fahrzeug
Vorfahrt hat, also nicht abbremst, das andere aber einen defekten Fahrerassistenten besitzt und somit die Gefahr nicht erkennt, kann es zu einem Unfall kommen,
der eigentlich hätte vermieden werden können.
Die Modellierung der Vorfahrtsregeln kann aber natürlich auch für andere Gebiete als die Kollisionsvermeidung von Nutzen sein. So ist es denkbar, dass ein
Autopilot sich dieser Informationen bedient, um zu entscheiden, ob er weiterfahren kann oder abbremsen muss, wenn er an einer Kreuzung auf ein anderes
Fahrzeug trifft. In einem solchen Szenario würde dieselbe Straßenontologie zwei
unterschiedlichen Anwendungen als Kontextmodell dienen, einem Programm zur
Kollisionsvermeidung und einem Autopiloten, da beide ähnlichen Informationen
über ihre Umwelt benötigen. Dies ist eine interessante Möglichkeit, die Ontologien bieten, da die Wiederverwendung und der Ausbau schon vorhandener Modelle
den Entwicklungsaufwand für neue Anwendungen reduziert und, wenn mehrere
Anwendungen gleichzeitig auf dieselbe Ontologie zugreifen, auch den Aufwand zur
Datenbeschaffung und Verwaltung.
So kann der nötige Ausbau der vorhandenen Straßenontologie zum Beispiel durch
Ontologieimporte verwirklicht werden. Versionsinformationen sind in OWL ebenfalls möglich, falls die eigentliche Ontologie geändert und erweitert wird. Hier kann
Kompatibilität bzw Inkompatibilität mit alten Versionen einer OWL-Datei angegeben werden. Ein weiterer Vorteil von Ontologien ist es, dass sie den Einsatz von
Reasonern erlauben, um die Widerspruchsfreiheit von Definitionen und Instanzen
zu überprüfen [Av04]. Vor allem beim Ausbau und der Entwicklung großer Ontologien, wie zum Beispiel einer sehr detaillierten Straßenontologie, kann dies von
großem Nutzen sein.
Empfohlene Höchstgeschwindigkeit
Eine weitere Einsatzmöglichkeit für die vorhandenen Ontologien ist die Ermittlung einer empfohlenen Höchstgeschwindigkeit. Hier können sowohl die in der Umweltontologie als auch die in Fahrzeug- und Straßenontologie enthaltenen Informationen von Nutzen sein. Eine empfohlene Höchstgeschwindigkeit könnte entweder
von einem Autopiloten eingehalten werden, oder der Fahrer wird gewarnt, wenn
er diese überschreitet.
Laut Statistischem Bundesamt ist nicht angepasste Geschwindigkeit die häufigs-
109
te Unfallursache1 , was das Fehlverhalten der Fahrer betrifft [sta07a]. Bei den sonstigen Faktoren spielen Glatteis und Nässe die größte Rolle, aber auch die Sichtbehinderung durch Nebel ist ein nicht zu vernachlässigender Faktor2 [sta07b]. Eine
Warnung des Fahrers bei zu hoher Geschwindigkeit würde also durchaus Sinn machen, die Berücksichtigung von Glatteis, regennasser Fahrbahn und Nebel ebenso.
Die Straßenontologie enthält bereits Informationen zu erlaubter Höchstgeschwindigkeit, dem Zustand der Straße, dem Straßenbelag und dem Neigungswinkel der
Kurven. Alle diese Faktoren sollten bei der empfohlenen Höchstgeschwindigkeit
berücksichtigt werden.
Aus der Umweltontologie lassen sich sowohl Informationen über Glatteisgefahr,
als auch über die Gefahr einer nassen Fahrbahn, die Dichte des Nebels, die Helligkeit und die Sichtverhältnisse entnehmen. Glatteis, Nässe und Nebel sind laut
[sta07b] die wichtigsten Umweltfaktoren was die Unfallursachen betrifft, es empfiehlt sich also diese auch in die Ermittlung der empfohlenen Höchstgeschwindigkeit
einfließen zu lassen. Die Umweltontologie bietet also sowohl diese drei wichtigen Faktoren, als auch noch Informationen zu Helligkeit und Sichtverhältnissen.
Somit stehen die benötigten Daten zur Ermittlung der Geschwindigkeit alle zur
Verfügung, die Umweltontologie muss nicht erweitert werden.
Die Fahrzeugontologie dagegen liefert, so wie sie ist, keine brauchbaren Informationen, wenn man von der maximalen Geschwindigkeit des Fahrzeugtyps absieht.
Man könnte sie aber zum Beispiel mit Daten zur Art der Reifen versehen, die
ebenfalls berücksichtigt werden sollten.
Es zeigt sich also, dass Umwelt-, Fahrzeug- und Straßenontologie leicht zur Ermittlung einer empfohlenen Höchstgeschwindigkeit eingesetzt werden, da sie die
meisten dazu notwendigen Informationen zum Großteil schon enthalten, oder aber
leicht um entsprechende Konzepte erweitert werden können. Da überhöhte Geschwindigkeit, Glatteis und Nässe die wichtigsten Unfallursachen sind, könnte die
Ermittlung einer empfohlenen Höchstgeschwindigkeit, die die wichtigsten Umweltfaktoren berücksichtigt, viele Unfälle vermeiden helfen.
5.3 Mögliche Verallgemeinerungen
Die im letzten Abschnitt untersuchten Einsatzmöglichkeiten und Erweiterungen
der Umwelt-, Straßen- und Fahrzeugontologie sind alle auf Bereiche beschränkt, die
mehr oder weniger mit ihrem ursprünglichen Zweck verwandt sind, der Kollisionsvermeidung. In diesem Abschnitt werden mögliche Verallgemeinerungen der entwickelten Ontologien untersucht. Dies sind einerseits Verallgemeinerungen bezüglich des Einsatzes der Ontologien und andererseits Verallgemeinerungen bezüglich
1
Im Jahr 2006 wurden von 403.886 Unfällen mit Personenschäden 64.742 durch nicht angepasste Geschwindigkeit verursacht.
2
Im Jahr 2006 beträgt die Anzahl der allgemeinen Ursachen 35.675, davon entfallen 9.754 auf Glatteis
und Schnee, 7.837 auf Glätte durch Regen und 518 auf Sichtbehinderung durch Nebel.
110
des mit ihnen modellierten Kontexts.
Die Umweltontologie könnte zum Beispiel zu einer Art Wetterontologie erweitert werden. Hier können weitere Informationen zum Wetter modelliert werden, die
unter anderem für die Routenplanung interessant sein können. Dazu müssen die
vorhandenen Informationen bestimmten Bereichen, zum Beispiel in der Straßenontologie, zugeordnet werden. Somit kann man in der Ontologie beschreiben, dass auf
einer Landstraße dichter Nebel ist, während die höher gelegene Autobahn nebelfrei
ist. Die Informationen hierfür können entweder von anderen Fahrzeugen kommen,
die diese Bereiche mit ihren Sensoren erfasst haben, oder von Wetterdiensten. Es
wäre also denkbar, dass die Fahrzeuge mit solchen Diensten kommunizieren, um
Daten zu erhalten, oder auch Daten an diese weiterleiten. Der Einsatz einer zur
Wetterontologie erweiterten Umweltontologie ermöglicht es hier, Konzepte und
ihren Zusammenhang für alle Teilnehmer zu definieren, beziehungsweise Abbildungen der einzelnen Modelle aufeinander festzulegen. Es können also nicht nur
die Daten, sondern auch ihre Bedeutung eindeutig beschrieben werden. Auch wenn
Wetterdienst und Fahrzeuge unterschiedliche Ontologien einsetzen, können sie die
Informationen dank der Abbildungsregeln richtig interpretieren. Somit wird den
Fahrzeugen ermöglicht, auf die Daten des Wetterdienstes zuzugreifen und die hier
beschriebenen Informationen maschinell zu verarbeiten, oder auch ihre Daten an
den Wetterdienst übermitteln.
Ähnliches ist für die Straßenontologie denkbar. Sie könnte als Grundlage für
den Informationsaustausch zwischen den Fahrzeugen und verschiedenen externen
Informationsquellen oder Anwendungsprogrammen dienen. Ein Beispiel hierfür ist
die Routenplanung. Bedient sich ein Navigationssystem der Straßenontologie, dann
ist es vom genauen Format der elektronischen Straßenkarte unabhängig. Außerdem kann es noch auf weitere Informationen zugreifen, wie zum Beispiel der oben
genannten Wetterontologie. Ebenso ist es möglich, dass aktuelle Verkehrsinformationen in Ontologien gespeichert werden. Diese können dann ebenfalls in die
Routenplanung einfließen. Eventuell könnten auch hier Fahrzeuge den Verkehrsdienst mit Informationen zur Verkehrsdichte, Staus und Unfällen versorgen. Wie
schon bei der Wetterontologie ermöglicht natürlich auch hier der Einsatz von Ontologien eine präzise Definition von Konzepten und Zusammenhängen, die maschinell ausgewertet werden können. Eine allgemeine Straßenontologie könnte also
als Grundlage für Kollisionswarnsysteme, Verkehrsdienste und Naviagtionssysteme
dienen. Sie ermöglicht es, dass alle diese unterschiedlichen Anwendungen miteinander kommunizieren können, also Daten, ihre Bedeutung und den Kontext, in dem
sie stehen, austauschen, da ihnen ein gemeinsames Verständnis von Konzepten
zugrunde liegt.
Zum Schluss wird noch auf die mögliche Erweiterung des Modells um fahrerbezogene Konzepte eingegangen. Da die Fähigkeiten und Eigenschaften der einzelnen
Fahrer sehr unterschiedlich sind, ist eine Berücksichtigung der speziellen Eigenheiten des Fahrers auch bei der Kollisionsvermeidung interessant. So ermöglichen
111
Daten über die Reaktionszeit des Fahrers eine verbesserte Reaktion auf eine erkannte Gefahr. Ist der Fahrer langsam, muss eventuell schon abgebremst werden,
ist er schnell, kann eine Warnung ausreichend sein. Auch die Erfassung weiterer
Daten liefert wertvolle Informationen. So reagiert der Fahrer wahrscheinlich bei
einer langen Fahrt oder in der Nacht langsamer und neigt dazu, mehr Fehler zu
machen. Auch das Sehvermögen, das Alter oder die Tatsache, dass der Fahrer
ein Brillenträger ist, können bei der Reaktion des Fahrerassistenten berücksichtigt
werden.
Sind Informationen zum Fahrer vorhanden, dann ergeben sich weitere Einsatzmöglichkeiten einer solchen Fahrerontologie. Ist zum Beispiel bekannt, dass der
Fahrer schon lange bei Nacht unterwegs ist, und er sein Ziel nicht mehr erreichen
kann, da das Wetter sehr schlecht ist, könnte der Fahrerassistent automatisch
nach dem nächsten Hotel suchen, das in der richtigen Preisklasse liegt, und den
Fahrer, so er daran interessiert ist, dorthin leiten. Eine derartige Anwendung würde
sich sowohl der Fahrer-, als auch der Wetter- und Straßenontologie bedienen und
außerdem noch mit einem Hotelservice im Internet kommunizieren.
Es ist also möglich, die in dieser Arbeit formalisierten Ontologien weiterzuentwickeln oder so zu verallgemeinern und auszubauen, dass sie auch in ganz neuen
Bereichen eingesetzt werden und somit die Grundlage des Informationsaustauschs
und der Zusammenarbeit unterschiedlichster Dienste und Anwendungen bilden.
5.4 Anpassungsfähigkeit und Grenzen
Zum Schluss dieses Kapitels wird noch auf Anpassungsfähigkeit der Ontologien
und ihre Grenzen eingegangen. Wie in den vorigen Abschnitten gezeigt wurde,
sind die Ontologien leicht erweiterbar. Sie können sowohl nur um einzelne Konzepte erweitert werden, als auch um komplette Modelle. Dies geschieht durch den
Import anderer Ontologien. Als Beispiel seien hier die Beipielontologie mit externen Fahrzeugdaten und die Straßenontologie genannt. Beide können ohne Schwierigkeiten in die Fahrzeugontologie integriert werden. Nötig ist nur die Definition
von Abbildungsregeln, die die Konzepte der unterschiedlichen Ontologien in Bezug zueinander setzt. In der Beispielontologie geschieht dies durch einen externen
Regelsatz (siehe Abschnitt 3.3.4).
Da die Ontologien leicht zu erweitern sind, können sie auch leicht an neue Anforderungen angepasst werden. Der Ausbau der Ontologien hat aber nicht nur
Vorteile, sondern kann auch zu Problemen führen.
Eine erweiterte Ontologie ist in der Regel auch langsamer, das heißt sie kann
unter anderem Anfragen nicht mehr so schnell bearbeiten. Bei einer Anwendung
wie der Kollisionsvermeidung ist dies aber ein kritischer Punkt, eine zu langsame
Ontologie ist hier nutzlos. Es muss also ein Kompromiss zwischen der Genauigkeit
des Modells und der Geschwindigkeit gefunden werden, die Ontologie ist nicht
beliebig erweiterbar ohne dass die Geschwindigkeit darunter leidet. Existiert ein
112
allgemeines Kontextmodell, das sehr viele Konzepte enthält, dann ist es unter
Umständen empfehlenswert, wenn sich die einzelnen Anwendungen auf die von
ihnen wirklich benötigen Ausschnitte beschränken und nicht das ganze Modell
verwenden.
Wird eine große Anzahl von Ontologien eingebunden, dann führt dies zu einem
weiteren Problem. Für jede Ontologie müssen gegebenenfalls Abbildungsregeln
aufgestellt werden, die den Zusammenhang ihrer Konzepte definieren. Eine hohe
Anzahl solcher Regeln macht das ganze System komplexer und somit auch langsamer. Somit sind auch der Erweiterung der Modelle durch den Import externer
Ontologien Grenzen gesetzt.
Allgemein lässt sich sagen, dass jedem Modell theoretische Grenzen gesetzt sind,
was seine Genauigkeit und die Menge der modellierten Konzepte betrifft. Nach
[Sta73] ist ein Modell immer nur ein Abbild der Wirklichkeit, es verkürzt und es
ist nach pragmatischen Gesichtspunkten erstellt.
Somit erfasst ein Modell nur einen Ausschnitt der Wirklichkeit, den es abstrahierend darstellt. Es soll auch nur die Aspekte erfassen, die dem Erschaffer des
Modells wichtig erscheinen, da es für einen Verwendungszweck geschaffen wird.
Enthält es zu viele Informationen, verliert es an Wert. Ein Modell, das alle Aspekte
der Wirklichkeit abbildet, ist sinnlos. Somit sind natürlich auch einem ontologischen Kontextmodell Grenzen gesetzt.
113
6 Diskussion
In diesem Kapitel werden zuerst die Erwartungen an ein ontologisches Kontextmodell und die tatsächlich erzielten Ergebnisse verglichen. Im nächsten Abschnitt wird
die Eignung des Ansatzes, Ontologien zur Kontextmodellierung einzusetzen, diskutiert. Am Ende des Kapitels steht ein Ausblick auf weitere Einsatzmöglickeiten
von ontologischen Kontextmodellen.
6.1 Erwartungen und Ergebnisse
Im Abschnitt 2.4.7 werden die Erwartungen an eine ontologische Kontextmodellierung formuliert. Hier wird überprüft, inwieweit diese Erwartungen erfüllt wurden.
Die erste Erwartung, dass die Ausdrucksstärke von Ontologien mächtig genug
ist, um den gewünschten Kontext zu modellieren, bestätigt sich für die in dieser
Arbeit entworfenen Kontextmodelle. Keines der Modelle erweist sich als mangelhaft aufgrund der Beschränkungen der Modellierungssprache OWL. Es ist nicht
einmal nötig den mächtigsten OWL-Dialekt, OWL Full, zu verwenden, sondern es
genügt sich auf OWL DL zu beschränken.
Die Maschinenlesbarkeit ist grundsätzlich ebenfalls gegeben. Problematisch könnte aber die richtige Interpretation von Zahlenwerten sein, wenn die physikalischen
Einheiten wie Meter oder Meile nicht in der Ontologie angegeben werden. Hier
existieren, außer für die Zeit, keine vordefinierten Datentypen in OWL, eine Erweiterung der OWL-Datentypen um Länge, Zeit, Temperatur, usw wäre hier sehr
hilfreich. Ansonsten wäre auch eine Festlegung in der Ontologie durch zusätzliche
Properties oder Kommentare möglich. Diese Lösungen erfordern aber wieder den
Eingriff eines Menschen, der die Properties oder Kommentare richtig interpretiert.
Die Möglichkeit zur Ableitung komplexer Informationen wird in dieser Arbeit
nur bedingt genutzt, einfachere Zusammenhänge wie Helligkeit, Nebel und Sichtverhältnisse, oder der Schluss vom Fahrzeugtyp auf seine Maße sind aber sehr
hilfreich. Die Frage, ob komplexere Anfragen beantwortet werden können, kann
mit Hilfe des Beispiels der Anfrage nach allen Fahrzeugen, die sich auf derselben
Zusammenhangskomponente des Straßennetzes wie das eigene Fahrzeug befinden,
bejaht werden.
Die Hoffnung auf schnelles Ableiten der Zusammenhänge dagegen wird nur bedingt erfüllt. Ist das Modell zu umfangreich, wird es auch langsamer. Zumindest
für eine relativ geringe Anzahl von Fahrzeugen und ein beschränktes Straßennetz
arbeitet der Fahrerassistent, und somit auch die ontologischen Modelle, aber mit
114
einer den Ansprüchen einer Echtzeitanwendung genügenden Geschwindigkeit.
Im Hinblick auf die Wiederverwertbarkeit der Modelle und die Möglichkeit zum
Einbinden externer Ontologien werden die Erwartungen erfüllt. Die Wiederverwertbarkeit und Ausbaufähigkeit einer Ontologie zeigt sich am Beispiel der Fahrzeugontologie. In der zweiten Version des Fahrerassistenten ist es leicht möglich, die
alte Fahrzeugontologie mit einer neuen Property zu erweitern, und ansonsten komplett zu übernehmen. Der Import externer Modelle ist ebenfalls leicht machbar,
wie man am Beispiel der Straßenontologie und der Beispielontologie zum Import
externer Fahrzeugdaten sieht.
Die meisten Erwartungen, die an den Einsatz von Ontologien zur Kontextmodellierung gestellt wurden, werden also erfüllt. Im nächsten Abschnitt wird auf die
Vorteile und Nachteile dieses Ansatzes eingegangen.
6.2 Eignung des Ansatzes der ontologischen
Kontextmodellierung
Ontologien ermöglichen es, formal die Aspekte der Wirklichkeit zu beschreiben, die
für den Verfasser der Ontologie von Interesse sind. Das ontologische Modell beschreibt Konzepte, ordnet ihnen Eigenschaften zu und legt Beziehungen zwischen
ihnen fest. Die Semantik des Modells ist eindeutig und die Ontologie besitzt eine
formale Syntax. Dadurch wird das Modell maschinenlesbar und interpretierbar.
Ein ontologisches Kontextmodell hat diese Eigenschaften natürlich auch. Somit
kann es als Grundlage für verschiedenste Anwendungen dienen, die alle Informationen über ähnlich Aspekte der Umwelt benötigen. Im Falle des Fahrerassistenten
ist es somit möglich, ein einmal erstelltes Modell für unterschiedliche Dienste zu
verwenden. Dies spart Zeit bei der Entwicklung von Anwendungen und erlaubt es,
die Anwendungen auf einem relativ abstrakten Level zu schreiben, da sie nur auf
die wohl formalisierten Daten, die die Ontologie enthält, zugreifen müssen.
In einem ontologischen Kontextmodell können die Zusammenhänge zwischen
Sensordaten und abstrakten Konzepten definiert werden. Dies muss nur einmal
implementiert werden, die Anwendungen können sich dann der Konzepte bedienen,
ohne zu wissen, woher die Informationen kommen.
Wenn Anwendungen das Verständnis über die Umwelt teilen, wie es bei der Verwendung gleicher oder (teilweise) aufeinander abbildbarer ontologischer Modelle
der Fall ist, dann erleichtert dies die Zusammenarbeit der Anwendungen erheblich.
Es ist möglich Informationen auszutauschen, die von beiden Partnern in gleicher
Weise interpretiert werden, wenn sie das Verständnis über die enthaltenen Konzepte und ihre Beziehungen zueinander teilen. Dieser Informationsaustausch wird
auch durch die Tatsache begünstigt, dass es möglich ist, Ontologien aufeinander
abzubilden, beziehungsweise die in ihnen formalisierten Konzepte.
Ontologische Kontextmodellierung ist also vor allem dann sinnvoll, wenn das
erzeugte Modell, oder eines, das darauf abbildbar ist, in mehreren Anwendungen
115
eingesetzt wird. Dies spart sowohl Zeit bei der Entwicklung, ermöglicht aber auch
eine verbesserte Kommunikation zwischen den Anwendungen.
Ein weiterer Vorteil des Einsatzes von Ontologien ist ihre Erweiterbarkeit durch
die Einbindung externer Ontologien. Existieren unterschiedliche ontologische Modelle der einzelnen Aspekte des zu modellierenden Kontexts, also zum Beispiel eine
Wetterontologie, eine Straßenontologie und eine Personenontologie als Teilaspekte
des Fahrzeugkontexts, können diese in die eigene Kontextontologie eingebunden
werden. Da je nach Problemstellung die unterschiedlichsten Aspekte des Kontexts
eine Rolle spielen, ist dies eine interessante Möglichkeit. Der Ersteller des Kontextmodells kann also auf die Arbeit anderer zurückgreifen und sich genau der Teile
bedienen, die für ihn von Interesse sind. Bei einer möglichen Erweiterung des Fahrerassistenten könnten dies die Fahrzeugontologien verschiedener Hersteller sein,
oder auch Ontologien, die Informationen zu Wetter und Verkehr enthalten.
Die Tatsache, dass es mit Hilfe von Reasonern möglich ist, aus den modellierten
Daten weitere Rückschlüsse zu ziehen, ist ebenfalls sehr hilfreich. Die Überprüfung
der Ontologie auf Widersprüche durch einen Reasoner ist bei der Entwicklung
größerer Kontextmodelle nützlich, die Überprüfung der Instanzmenge beim Einsatz des Modells.
Ein weiterer Vorteil des Einsatzes von Ontologien zur Kontextmodellierung ist
es, dass sie eine relativ “natürliche” Modellierung erlauben. Die Beschreibung der
Wirklichkeit durch Konzepte, ihren Eigenschaften und Beziehungen zueinander ist
verständlicher als zum Beispiel eine Modellierung durch reine Beschreibungslogiken. In geeigneter Darstellungsform sind zumindest kleinere Ontologien für den
menschlichen Betrachter relativ leicht zu verstehen. Dies ist vor allem bei der
Verwertung externer Ontologien wichtig, aber natürlich auch bei der Entwicklung
eigener Modelle.
Die ontologische Kontextmodellierung hat aber nicht nur Vorteile. Zuerst einmal
ist der Einsatz einer Ontologie relativ aufwändig. Unter anderem wird zur Entwicklung ein spezieller Editor benötigt, die Modellierungssprache muss eventuell
erst erlernt werden, die Einbettung in eine Anwendung erfordert ein Framework
und Zugriffe auf die Ontologie geschehen meist über spezielle Querysprachen und
Reasoner. Die Vorteile des Einsatzes einer Ontologie müssen so groß sein, dass sie
diesen Aufwand rechtfertigen, was zum Beispiel beim hier implementierten Fahrerassistenten der Fall ist.
Ein weiterer Nachteil ist, dass vor allem bei Ontologien mit einer Vielzahl von
Konzepten und Instanzen, die in komplexen Beziehungen zueinander stehen, die
auf ihnen durchgeführten Operationen sehr langsam werden können. Dasselbe gilt
für zu komplexe Anfragen, die vom Reasoner nicht in der gewünschten Zeit beantwortet werden können.
Spielt die Geschwindigkeit also eine große Rolle, dann dürfen Ontologie und Anfragen nicht zu komplex sein. Einfache Ontologien führen unter solchen Umständen
zu besseren Ergebnissen. Können aber die interessanten Eigenschaften eines on-
116
tologischen Kontextmodells nicht genutzt werden, da diese die Anforderungen an
die Geschwindigkeit des Systems nicht erfüllen würden, ist der Aufwand einer Modellierung mittels einer Ontologie eventuell nicht mehr angebracht. Hier mag der
Einsatz anderer Arten von Modellen, die sowohl einfacher in der Erstellung und
im Einsatz als auch schneller bei der Anwendung sind, sinnvoller sein.
Vor allem die Vorteile bezüglich des Imports externer Modelle, des Einsatzes
als Grundlage mehrerer Programme und des wesentlich erleichterten Informationsaustauschs zwischen unterschiedlichen Anwendungen überwiegen die Nachteile
des Ansatzes einer ontologischen Kontextmodellierung. Bei einem Einsatz eines
ontologischen Kontextmodells in Fahrzeugen können sich die unterschiedlichsten
Programme dieses Modells bedienen und auch die Kommunikation mit externen
Diensten wird erleichtert. Die Möglichkeit zur Abstraktion ist bei der großen Anzahl von Sensoren in modernen Fahrzeugen von entscheidender Bedeutung. Da sie
die konkreten Werte und Typen der Sensoren verbirgt, erlaubt sie es Anwendungen zu entwickeln, die in den Fahrzeugen unterschiedlicher Hersteller eingesetzt
werden können.
6.3 Ausblick
Der Einsatz ontologischer Modelle in Fahrzeugen bietet viele Möglichkeiten. Wie
in dieser Arbeit gezeigt wurde, lassen sich die Ergebnisse, die mit Programmen
zur Kollisionsvermeidung bei Fahrzeugen erreicht werden, wesentlich verbessern,
wenn der Kontext, in dem sich die Fahrzeuge befinden, beachtet wird.
Der Einsatz ontologischer Kontextmodelle ist aber nicht nur bei der Kollisionsvermeidung von Fahrzeugen sinnvoll. Die in dieser Arbeit entwickelten Modelle
lassen sich leicht erweitern und in anderen Gebieten einsetzen. Als Beispiel seien hier die Kommunikation des Fahrzeugs mit Routenplanern und Verkehrsdiensten genannt. Eine Erweiterung der Straßenontologie um Vorfahrtsregeln würde es
ermöglichen zu entscheiden, welches von zwei Fahrzeugen, die sich an einer Kreuzung treffen, fahren darf, und welches bremsen muss. In Kombination mit einem
Routenplaner könnte ein ontologisches Kontextmodell hier eventuell den Einsatz
eines Autopiloten unterstützen.
Nach [Rei96] bestehen autonome mobile Systeme aus vier Komponenten. Dies
sind das Sensorsystem zur Informationserfassung, das Aktorsystem zur Fortbewegung, das Kontrollsystem zur Informationsauswertung, und eine Kommunikationsstruktur sowohl für die Verbindung der restlichen drei Komponenten untereinander, als auch zur Kommunikation mit der Außenwelt.
Das Kontrollsystem könnte sich einer Ontologie zur Modellierung des vom Sensorsystem ermittelten Datensatzes, und der Ableitung abstrakter Informationen
aus diesen einfachen Daten bedienen. Auch die Funktionen und Parameter des
Aktorsystems lassen sich in einer Ontologie erfassen, die Kommunikation mit der
Außenwelt wird durch den Einsatz eines ontologischen Kontextmodells ebenso er-
117
leichtert. Navigationsdienste ermöglichen eine Streckenplanung, Verkehrsdienste
die Anpassung an die aktuellen Verkehrsverhältnisse. Entscheidungen zur Fahrzeugsteuerung könnten mit Hilfe eines detaillierten Kontextmodells, das sich auf
die nähere Umgebung des Fahrzeugs beschränkt, vom Kontrollsystem ebenso getroffen werden wie es ihm möglich ist, plötzlich auftretende Gefahren zu erkennen.
Hierzu könnte sich das Kontrollsystem des Autopiloten wiederum einer erweiterten
Version des Fahrerassistenten bedienen.
118
Abbildungsverzeichnis
2.1
2.2
2.3
Die logischen Programmkomponenten . . . . . . . . . . . . . . . . . 18
Einfache Klassenhierarchie und Properties . . . . . . . . . . . . . . 26
Einfache Propertyhierarchie . . . . . . . . . . . . . . . . . . . . . . 28
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
Die Properties des Klasse Fahrzeug . . . . . . . . . . . . . . . .
Die Klassenhierarchie der Fahrzeugtypen . . . . . . . . . . . . .
Die Modellierung der Verkehrsteilnehmer . . . . . . . . . . . . .
Die Importbeispiel - Ontologie . . . . . . . . . . . . . . . . . . .
Die logischen Komponenten und die wichtigsten Javaklassen . .
Die Einbindung der Klasse OntoCar . . . . . . . . . . . . . . . .
Geschwindigkeit des Simulators mit und ohne Fahrerassistenten
Geschwindigkeit eines einzelnen Fahrerassistenten . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
46
48
50
65
66
74
75
4.1
4.2
4.3
4.4
4.5
Die Sensoren der Umweltontologie . . . . . . . . . . . . .
Die abgeleiteten Werte der Umweltontologie . . . . . . .
Straßen und Kreuzungen . . . . . . . . . . . . . . . . .
Spuren, Kurven und Verkehrsschilder . . . . . . . . . . .
Vergleich der Geschwindigkeit mit und ohne Straßennetz
.
.
.
.
.
.
.
.
.
.
86
88
92
95
98
5.1
Vergleich der Simulationszeiten . . . . . . . . . . . . . . . . . . . . 104
119
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Literaturverzeichnis
[AD99]
Abowd, Gregory D. und Dey, Anind K.: Towards a Better Understanding of Context and Context-Awareness. In: HUC ’99: Proceedings of the 1st international symposium on Handheld and Ubiquitous
Computing, Seiten 304–307. Springer-Verlag, 1999.
[Av04]
Antoniou, Grigoris und van Harmelen, Frank: A Semantic
Web Primer. The MIT Press, Cambridge, Massachusetts, 2004.
[Baa03]
Baader, Franz: The Description Logic Handbook : Theory, Implementation and Applications. Cambridge University Press, Cambridge,
2003.
[BK01]
Borgelt, Christian und Kruse, Rudolf: Unsicherheit und Vagheit: Begriffe, Methoden, Forschungsthemen. KI, 15(3):5–8, 2001.
[CMD99]
Cheverst, Keith, Mitchell, Keith und Davies, Nigel: Design
of an object model for a context sensitive tourist GUIDE. Computers
and Graphics, 23(6):883–891, 1999.
[DFv03]
Davies, John, Fensel, Dieter und van Harmelen, Frank: Towards the Semantic Web: Ontology-Driven Knowledge Management.
John Wiley & Sons, 2003.
[DSK05]
Doetzer, Florian, Strassberger, Markus und Kosch, Timo:
Classification for traffic related inter-vehicle messaging. In: 5th International Conference on ITS Telecommunications (ITS-T), 2005.
[FHH04]
Fikes, Richard, Hayes, Patrick und Horrocks, Ian: OWL-QL–
a language for deductive query answering on the Semantic Web. Technischer Bericht, Stanford University, 2004.
[Fot02]
Fotherby, Tom: Visual Traffic Simulation.
University of
London, Student Project, http://mysite.wanadoo-members.co.uk/
tomfotherby/Contents/Uni/Project/index.html, 2002.
[GMF+ 03] Gennari, John H., Musen, Mark A., Fergerson, Ray W.,
Grosso, William E., Crubézy, Monica, Eriksson, Henrik,
Fridman Noy, Natalya und Tu, Samson W.: The evolution of
Protégé: an environment for knowledge-based systems development. Int.
J. Hum.-Comput. Stud., 58(1):89–123, 2003.
120
[Gro04]
Groetschel, Martin: Skript zur Vorlesung Lineare Optimierung. Technische Universität Berlin, http://www.math.tu-berlin.
de/Vorlesungen/WS03/LinOpt/, 2004.
[Gru93]
Gruber, Thomas R.: A translation approach to portable ontology
specifications. Knowledge Acquisition, 5(2):199–220, 1993.
[HIR03]
Henricksen, Karen, Indulska, Jadwiga und Rakotonirainy,
Andry: Generating Context Management Infrastructure from Context
Models. In: 4th International Conference on Mobile Data Management
(MDM), Industrial Track Proceedings, Seiten 1–6, Melbourne, January
2003.
[HM01]
Haarslev, Volker und Möller, Ralf: RACER System Description. In: International Joint Conference on Automated Reasoning, IJCAR’2001, June 18-23, Siena, Italy, Seiten 701–705. Springer-Verlag,
2001.
[Ian98]
Ian Horrocks: The FaCT System. In: Proc. of the 2nd Int. Conf.
on Analytic Tableaux and Related Methods (TABLEAUX’98), Band
1397 der Reihe Lecture Notes in Artificial Intelligence, Seiten 307–312.
Springer, 1998.
[KFFM04] Knublauch, Holger, Fergerson, Ray W., Fridman Noy, Natalya und Musen, Mark A.: The Protégé OWL Plugin: An Open
Development Environment for Semantic Web Applications. In: International Semantic Web Conference, Seiten 229–243, 2004.
[KR07]
Krajzewicz, Daniel und Roessel, Christian: SUMO - Simulation of Urban MObility - User Documentation. http://sumo.
sourceforge.net/docs/gen/user_index.shtml, 2007.
[mey07a]
Meyers Lexikon online. http://lexikon.meyers.de/meyers/Modell,
July 2007.
[mey07b]
Meyers Lexikon online.
Ontologie, July 2007.
[MH69]
McCarthy, John und Hayes, Patrick J.: Some philosophical problems from the standpoint of Artificial Intelligence. In: Machine Intelligence, vol. 4, Seiten 463–502. Edinburgh University Press, 1969.
[MH02]
Miller, Ronald und Huang, Qingfeng: An Adaptive Peer-to-Peer
Collision Warning System. In: Proceedings of IEEE Vehicle Technology
Conference (Spring), (Birmingham, Alabama)., May 2002.
http://lexikon.meyers.de/meyers/
121
[Mv04]
McGuinness, Deborah L. und van Harmelen, Frank:
OWL Web Ontology Language Overview. http://www.w3.org/TR/
owl-features/, 2004.
[Rei96]
Reichardt, Dirk: Kontinuierliche Verhaltenssteuerung eines autonomen Fahrzeugs in dynamischer Umgebung. Doktorarbeit, Universität Kaiserslautern, 1996.
[SAW94]
Schilit, Bill, Adams, Norman und Want, Roy: Context-Aware
Computing Applications. In: IEEE Workshop on Mobile Computing
Systems and Applications, Santa Cruz, CA, US, 1994.
[SBF98]
Studer, Rudi, Benjamins, Richard und Fensel, Dieter: Knowledge Engineering: Principles and Methods. Data & Knowledge Engineering, 25(1-2):161–198, March 1998.
[SL04]
Strang, Thomas und Linnhoff-Popien, Claudia: A Context Modeling Survey. In: First International Workshop on Advanced Context
Modelling, Reasoning And Management at UbiComp 2004, Nottingham, England, 2004.
[SS04]
Staab, Steffen und Studer, Rudi: Handbook on Ontologies. International Handbooks on Information Systems. Springer, 2004.
[SSH98]
Seiler, Peter, Song, Bongsob und Hedrick, J. Karl: Development of a Collision Avoidance System. University of CaliforniaBerkeley, http://vehicle.me.berkeley.edu/Publications/AVC/
pseil_sae98.pdf, 1998.
[Sta73]
Stachowiak, Herbert: Allgemeine Modelltheorie. Springer, Wien,
1973.
[sta07a]
Unfallursachen - Fehlverhalten der Fahrzeugführer bei Unfällen mit
Personenschaden. Statistisches Bundesamt Deutschland, http://www.
destatis.de/, 2007.
[sta07b]
Unfallursachen - Ursachen von Unfällen mit Personenschaden. Statistisches Bundesamt Deutschland, http://www.destatis.de/, 2007.
[SWM04] Smith, Michael K, Welty, Chris und McGuinness, Deborah
L.: OWL Web Ontology Language Guide. http://www.w3.org/TR/
owl-guide/, 2004.
[wik07a]
Wikipedia.
Online-Lexikon,
Wireless_LAN, July 2007.
[wik07b]
Wikipedia. Online-Lexikon, http://de.wikipedia.org/wiki/VANET,
July 2007.
122
http://de.wikipedia.org/wiki/

Kollisionsvermeidung für Fahrzeuge als Beispielanwendung für ein

Transcription

Similar documents

Steigerung der Anwendungseffizienz in mobilen Netzen

Puls-Akkumulation-Laufzeitmessung

DEUTSCH español

Car Connectivity Award 2015 vergeben

V4 @ Lineare Optimierung Übersicht

Honda Pressespiegel 12-2015

Ganz oben Gehör gefunden - Bundesvereinigung der

GFZ_Geohazard_Web2.0undSocialMedia