hardware-in-the-loop gestützte entwicklungs- plattform … · 1.3 anforderungen an die...
Post on 18-Sep-2018
212 Views
Preview:
TRANSCRIPT
ISBN 978-3-86129-004-1
Christian Schmidt
Hardware-in-the-Loop gestützte Entwicklungs- plattform für Fahrerassistenzsysteme
Analyse und Generierung kritischer Verkehrsszenarien
Chris
tian
Schm
idt
Har
dwar
e-in
-the-
Loop
ges
tütz
te E
ntw
ickl
ungs
plat
tform
für F
ahre
rass
iste
nzsy
stem
e
Christian Schmidt
Hardware-in-the-Loop gestützte Entwicklungsplattform für Fahrerassistenzsysteme – Analyse und Generierung kritischer Verkehrsszenarien --
kasseluniversity
press
Die vorliegende Arbeit wurde vom Fachbereich Elektrotechnik / Informatik der Universität Kassel als Dissertation zur Erlangung des akademischen Grades eines Doktors der Ingenieurwissenschaften angenommen. Erster Gutachter: Prof. Dr. rer. nat. Ludwig Brabetz Zweiter Gutachter: Dr.-Ing. Mohamed Ayeb Tag der mündlichen Prüfung 27. August 2010 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar Zugl.: Kassel, Univ., Diss. 2010 ISBN print: 978-3-86219-004-1 ISBN online: 978-3-86219-005-8 URN: http://nbn-resolving.de/urn:nbn:de:0002-30055 © 2010, kassel university press GmbH, Kassel www.upress.uni-kassel.de Printed in Germany
Vorwort
Die vorliegende Arbeit entstand wahrend meiner Zeit als wissenschaftlicherMitarbeiter am Fachgebiet Fahrzeugsysteme und Grundlagen der Elektro-technik im Fachbereich Elektrotechnik / Informatik der Universitat Kassel.Die Arbeit war Teil des integrierten Forschungsprojektes DECOS, das vonder Europaischen Union im 6. Rahmenprogramm gefordert wurde.
Nachdem Herr Prof. Dr.-Ing. Jurgen Leohold, bei dem ich meine Arbeit be-gonnen hatte, in die Fahrzeugindustrie zuruckkehrte, ubernahm Herr Prof.Dr.-Ing. Heinz Theuerkauf die kommissarische Leitung des vakanten Fach-gebietes und die Betreuung der laufenden Arbeiten. Ihm danke ich fur vielehilfreiche Anregungen und die Unterstutzung der begonnenen Arbeit.
Herrn Dr.-Ing. Mohamed Ayeb danke ich fur seine kritischen Fragen unddie fruchtbaren Diskussionen, in denen ich von seinem Wissen uber Echt-zeitsimulation, HiL und elektronische Systeme in Kraftfahrzeugen profitie-ren konnte. Außerdem danke ich ihm fur die Ubernahme des Zweitgutach-tens.
Nach der Berufung von Herrn Prof. Dr. rer. nat. Ludwig Brabetz zumneuen Leiter des Fachgebiets Fahrzeugsysteme und Grundlagen der Elek-trotechnik ubernahm er auch die Betreuung der noch nicht abgeschlossenenwissenschaftlichen Arbeiten. Ich danke ihm fur das Interesse, das er meinerArbeit entgegengebracht hat und die Bereitschaft, das Amt des Erstgut-achters zu ubernehmen.
Meinen Kollegen Carsten Schmidt und Dirk Tellmann danke ich fur die au-ßerordentlich gute Zusammenarbeit am gemeinsamen Projekt und die Be-reitschaft, ihr Wissen - nicht nur uber LATEX - mit mir zu teilen. Wesentlichzum Gelingen des Projektes beigetragen hat auch eine Reihe studentischerArbeiten, angefertigt unter anderem von Dominik Holler, Patrick Grabelund Klaus Simon.
i
Vorwort
Ich danke auch meinen Kollegen Frank Diegmuller, Stefan Frohlich, RalfGemmerich, Oliver Haas und Dirk Schneider, die auch - und gerade -wahrend der Zeit der Vakanz immer fur ein positives Klima gesorgt ha-ben.
Herrn Dr. phil. Michael Obenaus danke ich fur die vermutlich ziemlichmuhevolle Durchsicht des Manuskripts.
Besonderer Dank gilt meinen Eltern, die mir mein Studium ermoglicht undmeinen Weg immer mit Wohlwollen begleitet haben. Ebenfalls danke ichmeiner Frau und meinen beiden Sohnen, die - obgleich hier an letzter Stellegenannt - einen ganz besonderen Platz in meinem Leben haben und derenNachsicht und Unterstutzung diese Arbeit uberhaupt erst moglich gemachthat - auch wenn es dann doch wieder langer gedauert hat.
Bohl-Iggelheim, im August 2010 Christian O. Schmidt
ii
Fur Katharina, Ole und Peer
iii
Vorwort
iv
Inhaltsverzeichnis
Vorwort i
1 Einleitung 11.1 DECOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Fahrerassistenzsysteme . . . . . . . . . . . . . . . . . . . . . 41.3 Anforderungen an die Simulationsumgebung . . . . . . . . . 6
2 Konzept 112.1 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Test von Fahrerassistenzsystemen . . . . . . . . . . . 112.1.2 Marktrecherche . . . . . . . . . . . . . . . . . . . . . 12
2.2 Konzept der Eigenentwicklung . . . . . . . . . . . . . . . . 132.2.1 Echtzeitrechner – HiL Simulation . . . . . . . . . . . 182.2.2 PC – SiL Simulation . . . . . . . . . . . . . . . . . . 20
3 Grundlagen 233.1 Unfallstatistik . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1 Unfallstatistik des Statistischen Bundesamtes . . . . 233.1.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Koordinatensysteme . . . . . . . . . . . . . . . . . . . . . . 283.3 Kritische Verkehrsszenarien . . . . . . . . . . . . . . . . . . 30
3.3.1 Kritische Verkehrssituation . . . . . . . . . . . . . . 303.3.2 Kritikalitat . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Verkehrssituationen fur Langsfuhrungssysteme . . . . . . . 333.4.1 Funktionsbeschreibung des Stauassistenten . . . . . 333.4.2 Situationen . . . . . . . . . . . . . . . . . . . . . . . 33
4 Erzeugung kritischer Verkehrssituationen 394.1 Modellannahmen . . . . . . . . . . . . . . . . . . . . . . . . 394.2 Hindernisposition . . . . . . . . . . . . . . . . . . . . . . . . 404.3 Spurwechsel des Hindernisfahrzeugs . . . . . . . . . . . . . . 41
v
Inhaltsverzeichnis
4.3.1 Lange des Spurwechselvorgangs . . . . . . . . . . . . 444.3.2 Start des Spurwechselvorgangs . . . . . . . . . . . . 46
4.4 Bremsen des Hindernisfahrzeugs . . . . . . . . . . . . . . . 504.5 Einbiegen eines Hindernisfahrzeugs . . . . . . . . . . . . . . 52
5 Simulationsmodule 555.1 Ubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2 Modul Verkehr . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.1 Schnittstellen . . . . . . . . . . . . . . . . . . . . . . 575.3 Modul Situationsgenerator . . . . . . . . . . . . . . . . . . . 57
5.3.1 Schnittstellen . . . . . . . . . . . . . . . . . . . . . . 595.3.2 Konfiguration . . . . . . . . . . . . . . . . . . . . . . 595.3.3 Zustandsautomat . . . . . . . . . . . . . . . . . . . . 61
5.4 Modul CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.5 Modul FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . 66
6 Anwendung und Validierung 696.1 Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.1.1 Test eines Assistenzsystems . . . . . . . . . . . . . . 706.1.2 Implementierung der DECOS Applikationen . . . . . 76
6.2 Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.2.1 Einschermanover . . . . . . . . . . . . . . . . . . . . 806.2.2 Bremsmanover . . . . . . . . . . . . . . . . . . . . . 906.2.3 Vorubergehender Ausfall des Sensors . . . . . . . . . 976.2.4 Auslosetoleranz . . . . . . . . . . . . . . . . . . . . . 1006.2.5 Bewertung . . . . . . . . . . . . . . . . . . . . . . . 104
7 Zusammenfassung und Ausblick 105
A Anhang 107A.1 Anforderungskatalog . . . . . . . . . . . . . . . . . . . . . . 107A.2 Fehlerabschatzung zur Linearisierung der Spurwechseltra-
jektorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111A.3 Abkurzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . 113A.4 Verzeichnis der Formelzeichen . . . . . . . . . . . . . . . . . 114A.5 Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115A.6 Parameter Datei . . . . . . . . . . . . . . . . . . . . . . . . 117A.7 Messwerte Spurwechselmanover . . . . . . . . . . . . . . . . 118A.8 Messwerte Bremsmanover . . . . . . . . . . . . . . . . . . . 120
vi
Inhaltsverzeichnis
A.9 CAN-Botschaften . . . . . . . . . . . . . . . . . . . . . . . . 122A.10 Bilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124A.11 simenv-Datei fur STA-Test . . . . . . . . . . . . . . . . . . 128
Literaturverzeichnis 131
vii
Inhaltsverzeichnis
viii
Abbildungsverzeichnis
1.1 Eingriffsintensitat verschiedener Assistenzsysteme . . . . . . 51.2 Struktur der Simulationsumgebung . . . . . . . . . . . . . . 9
2.1 Blockschaltbild der Simulationsumgebung . . . . . . . . . . 142.2 Ein DECOS FlexRay Knoten . . . . . . . . . . . . . . . . . 162.3 Das DECOS FlexRay Cluster und die Applikationen . . . . 162.4 Blockschaltbild des CARTS Hardware-in-the-Loop Simulators 192.5 MPI Block in Simulink (Ausschnitt aus Abbildung A.3) . . 21
3.1 Unfallursachen 2006 . . . . . . . . . . . . . . . . . . . . . . 263.2 Unfalltypen 2006 . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Koordinatensysteme . . . . . . . . . . . . . . . . . . . . . . 283.4 Koordinatensystem nach DIN 70000 . . . . . . . . . . . . . 293.5 Testfahrzeug und Hindernis, Abstande . . . . . . . . . . . . 313.6 Spurwechselsituation . . . . . . . . . . . . . . . . . . . . . . 343.7 Bremsen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.8 Stau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.9 Einbiegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.10 Uberholen, Einscheren, Bremsen . . . . . . . . . . . . . . . 37
4.1 Spurwechseltrajektorie . . . . . . . . . . . . . . . . . . . . . 424.2 Stuckweise Linearisierung . . . . . . . . . . . . . . . . . . . 434.3 Linearisierung der Spurwechseltrajektorie . . . . . . . . . . 474.4 135° Kreuzung . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1 Simulationsmodule in der HiL bzw. SiL Umgebung . . . . . 565.2 Blockschaltbild der Fahrdynamik . . . . . . . . . . . . . . . 575.3 Blockschaltbild der Interaktion des Situationsgenerators mit
der Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . 585.4 Zustandsautomat des Situationsgenerators . . . . . . . . . . 625.5 Anbindung von PRAETORIA an das Testsystem via CAN 65
ix
Abbildungsverzeichnis
5.6 Anbindung von PRAETORIA an das Testsystem via CAPLund FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1 Anwendung der Simulationsumgebung im Entwicklungspro-zess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Konfiguration der Simulationsumgebung in PRAETORIA . 726.3 Konfiguration der Hindernisfahrzeuge in PRAETORIA . . . 736.4 PRAETORIA im SiL Betrieb . . . . . . . . . . . . . . . . . 756.5 Versuchsaufbau des HiL Demonstrators . . . . . . . . . . . 766.6 Domanenspezifischer Editor fur plattformunabhangige Mo-
delle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.7 Kommunikationsplan fur das DECOS-Cluster . . . . . . . . 796.8 Einschermanover mit Kritikalitat K = 0,8 . . . . . . . . . . 816.9 Einschermanover mit Kritikalitat K = 0,8 . . . . . . . . . . 826.10 Messwerte zur Messung 10 aus Tabelle 6.1 . . . . . . . . . . 856.11 Ausschnitt aus Abbildung 6.10 . . . . . . . . . . . . . . . . 856.12 Messwerte zur Messung 14 aus Tabelle 6.1 . . . . . . . . . . 866.13 Ausschnitt aus Abbildung 6.12 . . . . . . . . . . . . . . . . 866.14 Bremsmanover mit Kritikalitat K = 0,8 . . . . . . . . . . . 916.15 Bremsmanover mit K = 0,8 . . . . . . . . . . . . . . . . . . 926.16 Sensorausfall beim Spurwechselmanover mit KSoll = 0,5 . . 976.17 Ausschnitt aus Abbildung 6.16 . . . . . . . . . . . . . . . . 986.18 Sensorausfall beim Spurwechselmanover mit KSoll = 0,9 . . 996.19 Ausschnitt aus Abbildung 6.18 . . . . . . . . . . . . . . . . 100
A.1 Linearisierungsfehler . . . . . . . . . . . . . . . . . . . . . . 112A.2 Laboraufbau beim Projektpartner AEV . . . . . . . . . . . 124A.3 Simulink Blockschaltbild beim Projektpartner AEV . . . . 125A.4 DECOS FlexRay Cluster . . . . . . . . . . . . . . . . . . . 126A.5 HiL Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . 127
x
Tabellenverzeichnis
5.1 Datenbasisvariablen des Situationsgenerators . . . . . . . . 605.2 Konfigurierbare Situationen . . . . . . . . . . . . . . . . . . 61
6.1 Ergebnis der Messungen zur Reproduzierbarkeit fur ein Spur-wechselmanover mit K = 0,5 . . . . . . . . . . . . . . . . . 84
6.2 Ergebnis der Messungen zur Reproduzierbarkeit fur ein Spur-wechselmanover mit K = 0,9 . . . . . . . . . . . . . . . . . 88
6.3 Mittelwerte der Messungen zur Generierbarkeit von Spur-wechselmanovern . . . . . . . . . . . . . . . . . . . . . . . . 89
6.4 Ergebnis der Messungen zur Reproduzierbarkeit fur ein Brems-manover mit K = 0,5 . . . . . . . . . . . . . . . . . . . . . 94
6.5 Ergebnis der Messungen zur Reproduzierbarkeit fur ein Brems-manover mit K = 0,9 . . . . . . . . . . . . . . . . . . . . . 95
6.6 Mittelwerte der Messungen zur Generierbarkeit von Brems-manovern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.7 Ergebnis der Messungen zur Ausloseprazision fur ein Spur-wechselmanover mit K = 0,5 . . . . . . . . . . . . . . . . . 101
6.8 Ergebnis der Messungen zur Ausloseprazision fur ein Spur-wechselmanover mit K = 0,9 . . . . . . . . . . . . . . . . . 101
6.9 Ergebnis der Messungen zur Ausloseprazision fur ein Brems-manover mit K = 0,5 . . . . . . . . . . . . . . . . . . . . . 102
6.10 Ergebnis der Messungen zur Ausloseprazision fur ein Brems-manover mit K = 0,9 . . . . . . . . . . . . . . . . . . . . . 102
6.11 Auslosetoleranzen bei unterschiedlichen Geschwindigkeitenund Reaktionszeiten eines menschlichen Fahrers . . . . . . . 103
A.1 Ergebnis der Messungen zur Generierbarkeit fur alle Spur-wechselmanover . . . . . . . . . . . . . . . . . . . . . . . . . 118
A.2 Ergebnis der Messungen zur Generierbarkeit fur alle Brems-manover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
A.3 Gesendete und empfangene CAN-Botschaften . . . . . . . . 122
xi
1 Einleitung
Moderne Fahrzeuge sind mit einer großen Anzahl von elektronischen Steu-ergeraten ausgerustet1, die eine Vielzahl von Funktionen erfullen. Auch –und gerade – im Komfort- und Sicherheitsbereich sind neue Funktionen oftmit einem proprietaren Steuergerat sowie eigener Sensorik verknupft. Derweitaus großte Teil innovativer Funktionen wird im Bereich elektronischerSysteme erwartet, woraus sich ein weiterer Anstieg bei der Zahl der Steu-ergerate wie auch beim Kommunikationsaufkommen ergibt [Kopetz u. a.,2003].
Funktionale Einheiten, wie zum Beispiel ABS/ESP2, die Motorsteuerungoder ein Stauassistent, wurden – und werden nach wie vor – ublicherweisemit je einem eigenen elektronischen Steuergerat realisiert. Mit steigenderKomplexitat der Einzelsysteme und zunehmender Vernetzung der verschie-denen Systeme untereinander stoßt diese Art der Realisierung (engl. fede-rated architecture) jedoch an ihre Grenzen [Schmidt, 2003]. Die als Losungdes Problems vorgeschlagene integrierte Architektur soll im Projekt DE-COS entwickelt werden [Gruber, 2004].
1.1 DECOS
Im 6. Forschungsrahmenprogramm der Europaischen Union wird das inte-grierte Forschungsprojekt
”Dependable Embedded Components and Sys-
tems3“ (DECOS) gefordert, das sich zum Ziel gesetzt hat, Technologie undMethoden fur eine integrierte Architektur verteilter eingebetteter Systemeauf der Basis zeitgesteuerter Kommunikationssysteme zu entwickeln. Diese
1Beispiel: Der Volkswagen Phaeton ist mit 61 vernetzten Steuergeraten ausgestattet.Vgl. [Brabetz, 2007]
2Antiblockiersystem (engl. Antilock Braking System)3http://www.decos.at/
1
1 Einleitung
Architektur soll als Basis fur die Entwicklung verteilter Steuer- und Re-gelanwendungen im Automobilbau, in der Luftfahrt und in der Industriedienen. Das Konzept erlaubt dabei nicht nur die gemeinsame Ausfuhrungsicherheitskritischer und nicht-sicherheitskritischer Anwendungen auf ei-nem Steuergerat, sondern auch die Verteilung einer Anwendung uber meh-rere Knoten des Steuergerateverbundes. Auch die redundante Ausfuhrungvon Applikationen im Steuergerateverbund wird von der Architektur un-terstutzt.
Das Projekt ist in acht Teilprojekte unterteilt, die sich mit der Entwick-lung der zugrunde liegenden Technologie, der Anwendung dieser Techno-logien sowie der Verwertung und Veroffentlichung der erzielten Ergebnissebeschaftigen.
In den Technologieteilprojekten werden
� die Architektur,
� die Entwicklungsmethoden,
� die Entwicklungswerkzeuge und
� die Hardwareplattform
entwickelt, auf deren Basis und mit deren Hilfe in den Anwendungsteil-projekten Demonstratoren aufgebaut werden, die als Funktionsnachweisdienen.
Die in DECOS entwickelte Architektur basiert auf einer zeitgesteuertenKommunikation, die fur die zeitliche Synchronisation der beteiligten Steu-ergerate sowie den Austausch der zu kommunizierenden Daten sorgt. Jenach Anwendungsgebiet kommen dabei entweder TTP4 – fur Industrieund Luftfahrt – oder FlexRay – fur den Automobilbereich – als Kommu-nikationssystem zum Einsatz. Wesentliches Merkmal der Architektur istaußerdem die Kapselung der verschiedenen Anwendungen, die gemeinsamauf einem Steuergerat ausgefuhrt werden, so dass auftretende Fehler sichnur auf die betroffene Komponente oder Anwendung auswirken konnen(engl. fault containment).
4Time Triggered Protocol [TTTech Computertechnik AG, 2003]
2
1.1 DECOS
DECOS strebt die Durchgangigkeit der angewendeten Methoden und Tech-nologien an. Der Entwicklungsprozess wird daher durch eine an die ent-wickelten Methoden angepasste Werkzeugkette unterstutzt. Von der An-forderungsanalyse und Spezifikation uber den Entwurf und die Implemen-tierung bis zur Verifikation und Validierung wird die Entwicklung vonWerkzeugen begleitet. Ein innerhalb des Projekts entwickeltes Werkzeugunterstutzt die Spezifikation eines plattformunabhangigen Modells5 derAnwendung. Das plattformunabhangige Modell (PIM) beschreibt lediglichdie grobe Struktur, die notwendige Kommunikation mit den erforderlichenSchnittstellen und einzuhaltende Rahmenbedingungen, wie z. B. die maxi-male Ausfuhrungszeit (engl. worst case execution time). Das PIM enthaltkeine Beschreibung des Systemverhaltens, dient aber als Basis fur die Mo-dellierung des Verhaltens mit SCADE6, indem der Import des plattfor-munabhangigen Modells ein zu fullendes Gerust in SCADE erzeugt, dasdie zuvor modellierten Schnittstellen bereits enthalt. Dieses Gerust wirddann in Scade mit einem Verhaltensmodell gefullt. Aus der dann vorliegen-den Beschreibung wird mit Hilfe des integrierten Codegenerators C-Codeerzeugt.
Der von SCADE aus dem Modell generierte Code wird dann mit weiterenProgrammteilen, die z. B. Treiber fur Kommunikationssysteme und das Be-triebssystem enthalten, zusammengefuhrt. Dieser Code wird mit Hilfe vonScripten zur Compilersteuerung ubersetzt und kann dann auf der Zielplatt-form ausgefuhrt werden.
Die Zielplattform, die jeweils einen Knoten eines Rechnerverbundes bil-det, besteht aus einem Infineon TriCore Prozessor, einem FPGA7 fur diezusatzlichen fehlertoleranten Schichten des Kommunikationsprotokolls undeinem an das verwendete Protokoll angepassten Kommunikationscontrol-ler (vgl. Abbildung 2.2). Der FPGA wird benotigt, um die DECOS spe-zifischen fehlertoleranten Schichten zu implementieren, die in den Spezifi-kationen der Protokolle nicht vorgesehen sind. Der TriCore Prozessor un-terstutzt die geforderte Kapselung verschiedener Anwendungsprogrammegegeneinander [Hufeld, 2006].
Neben der Entwicklung der Applikationen soll in den Anwendungsteilpro-
5Platform independent model (PIM) [Pataricza, 2007]6Safety-Critical Application Development Environment, http://www.esterel-
technologies.com/products/scade-suite/7Field Programmable Gate Array
3
1 Einleitung
jekten der Nachweis der Anwendbarkeit der DECOS-Technologie erbrachtwerden. Dazu werden verschiedene Demonstratoren entwickelt, die die DE-COS Technologie einsetzen. Das Teilprojekt
”SP5 application automotive“
wird diesen Nachweis anhand von Fahrerassistenzsystemen erbringen, dieauf der Basis der DECOS Technologie entwickelt wurden.
In diesem Rahmen wird an der Universitat Kassel als Demonstrator eineSimulationsumgebung zum Test von Fahrerassistenzsystemen entwickelt,mit deren Hilfe Fahrerassistenzsysteme gezielt in kritischen Verkehrssitua-tionen getestet werden konnen.
1.2 Fahrerassistenzsysteme
Fahrerassistenzsysteme (FAS) sind komplexe Systeme, die den Fahrer beiseiner Aufgabe – der Fahrzeugfuhrung – unterstutzen sollen, indem sie
� ihm Informationen zur Verfugung stellen, die uber seinen eigenenWahrnehmungsbereich hinausgehen,
� ihn in kritischen Situationen warnen,
� in kritischen Situationen das Fahrzeug so beeinflussen, dass ein Unfallverhindert oder zumindest die Folgen verringert werden.
Das Spektrum der moglichen Assistenzsysteme deckt von rein informati-ven Systemen uber solche mit begrenzten Eingriffsmoglichkeiten hin zum -moglicherweise in Zukunft zu realisierenden - autonomen Ausweichen undFahren ein sehr weites Feld ab. Die Abbildung 1.1 stellt verschiedene Assis-tenzsysteme und die Intensitat ihres Eingriffs in die Fahrzeugdynamik dar.In allen Fallen tragt der Fahrer die letzte Verantwortung fur sein Fahrzeugund seine Eingriffe in Langs- und Querfuhrung des Fahrzeugs haben immerPrioritat uber die Aktionen des Assistenzsystems.
Um die oben beschriebene Unterstutzung bieten zu konnen, sind viele As-sistenzsysteme mit Sensoren ausgerustet, die die Umgebung des Fahrzeugsbeobachten. Anhand der ermittelten Daten konnen die Systeme dann dieSituation bewerten und dem Fahrer Informationen anbieten oder aktiv indie Fahrzeugfuhrung eingreifen. Die Sensorik der Systeme ist an die jeweili-ge Anwendung angepasst: Ein System, das die Fahrbahn beobachtet, wird
4
1.2 Fahrerassistenzsysteme
Nachtsichthilfe ABS
ESP
Stauassistent
Automatische
Abstandsregelung
Adaptive
Lichtsteuerung
Notbrems-
assistent
Ausweich-
assistent
Autonomes
Fahren
Spurhalte-
systeme
Abbildung 1.1: Eingriffsintensitat verschiedener Assistenzsysteme
mit einer Videokamera ausgerustet sein, wahrend ein System, das den Ab-stand und die Relativgeschwindigkeit zu Fremdfahrzeugen bestimmt, einenRadar- oder Lasersensor zur Verfugung hat.
Fahrerassistenzsysteme mussen vor dem Einsatz in Serienfahrzeugen ge-testet werden. Dazu ist jedoch ein sehr großer finanzieller und materiellerAufwand notig, wenn die Systeme im realen Umfeld durch Fahrversuchegetestet werden sollen, da dazu Hindernisse, Straßen und Fremdfahrzeugenotwendig sind, um die Sensoren mit den erforderlichen Eingabedaten zuversorgen. Daruber hinaus ist der Test solcher Systeme im offentlichen Ver-kehrsraum mit nicht unerheblichen Gefahren verbunden, da eine Fehlfunk-tion eines Assistenzsystems zu Situationen fuhren kann, die der menschli-che Fahrer nicht mehr beherrschen kann. Auch fur geubte Testfahrer kannder Ausfall eines Assistenzsystems in einer kritischen Situation also großeRisiken bergen. Gerade diese Situationen mussen daher intensiv getestetwerden, um die sichere Funktion der Systeme unter allen moglichen Be-dingungen zu gewahrleisten.
”Sichere Funktion“ bedeutet in diesem Zu-
5
1 Einleitung
sammenhang nicht unbedingt, dass die Systeme unter allen Umstandenfunktionieren, sondern dass die Fahrsicherheit des Fahrzeugs zu keinemZeitpunkt negativ beeinflusst wird.
Beim Test von Fahrerassistenzsystemen sind jedoch nicht nur Aufwand undGefahr von Untersuchungen im realen Verkehrsumfeld problematisch, auchdie Reproduzierbarkeit kritischer Manover, die von einem menschlichenFahrer gefahren werden, ist nicht gegeben. So haben menschliche Fahrernicht nur Schwierigkeiten, eine Trajektorie mit der geforderten Genauig-keit zu reproduzieren, auch das Auslosen geplanter Vorgange, wie z. B.Einlenken in ein Spurwechselmanover, gelingt nur unzureichend [Schicku. a., 2007].
Der Test von Fahrerassistenzsystemen in kritischen Situationen ist also eineAufgabe, die mit Hilfe von Simulationswerkzeugen insofern besser gelostwerden konnte, als zumindest teilweise auf aufwandige Tests mit realenFahrzeugen verzichtet werden kann. Gleichzeitig ist die Reproduzierbarkeitder Testsituation gewahrleistet und eine Dokumentation der Testfalle undErgebnisse kann mit Hilfe der Simulationsumgebung erzeugt werden.
Das Ziel dieser Arbeit ist die Entwicklung einer Simulationsumgebung,die sowohl den entwicklungsbegleitenden Test als auch den abschließen-den Funktionstest von Fahrerassistenzsystemen in einer simulierten Um-gebung erlaubt. Damit sollen die oben beschriebenen Forderungen nachsicheren und reproduzierbaren Tests in allen Stufen des Entwicklungspro-zesses erfullt werden. Fahrversuche auf Teststrecken und im realen Ver-kehrsumfeld konnen durch die Simulation nicht vollstandig ersetzt wer-den, allerdings lasst sich durch gezielte Vorbereitung in der Simulation dieHaufigkeit solcher Fahrten deutlich verringern.
1.3 Anforderungen an dieSimulationsumgebung
Um das oben formulierte Ziel – den entwicklungsbegleitenden Test – rea-lisieren zu konnen, muss die Simulationsumgebung unterschiedliche An-forderungen erfullen, die zum Teil bereits in [Kant, 2004] und [Ayeb u.Schmidt, 2005] beschrieben sind.
6
1.3 Anforderungen an die Simulationsumgebung
Die wesentlichen Elemente der Simulationsumgebung werden hier kurz vor-gestellt, detailliertere Beschreibungen der einzelnen Elemente und ihrerFunktionen fur den Test von Fahrerassistenzsystemen sind in Abschnitt 2.2sowie in [Schmidt, 2010] und [Tellmann, 2010] zu finden.
Umwelt Das wichtigste Element der Umwelt ist die Straße, auf der dassimulierte Verkehrsgeschehen stattfindet. Zusatzliche Elemente derUmwelt, wie etwa unbewegte Hindernisse, Gebaude und andere Ele-mente der Randbebauung, sind zunachst nur von untergeordneterBedeutung. Die Straße soll mit allen physikalisch relevanten Großenwie Steigung, Neigung, Reibwert und Krummung modelliert werden.
Testfahrzeug Innerhalb einer simulierten Umgebung muss das mit virtu-ellen Sensoren und dem zu testenden Assistenzsystem ausgerusteteTestfahrzeug bewegt werden. Dazu ist die Fahrzeugdynamik des Test-fahrzeugs (vehicle under test, VUT) detailliert zu simulieren. DieFahrdynamiksimulation ist erforderlich, um realistische Eingriffe desAssistenzsystems in die Fahrdynamik nachbilden zu konnen. Die Er-gebnisse werden auch dazu genutzt, die Sensoren im Raum auszurich-ten. Das Testfahrzeug muss also Schnittstellen bereitstellen, die denAssistenzsystemen die Beeinflussung der Fahrdynamik erlauben unddie Abfrage der Position und der Ausrichtung im Raum ermoglichen.
Sensormodelle Die zu testenden Systeme mussen mit Informationen uberdie Umgebung des Testfahrzeugs versorgt werden. Dazu sind Sensor-modelle notig, die die Umgebung erfassen und diese Daten dem As-sistenzsystem in der erforderlichen Form zur Verfugung stellen. Diefur Fahrerassistenzsysteme ublichen Sensortypen, wie etwa Radar-und Lasersensoren, sollen modelliert werden.
Verkehr Fahrerassistenzsysteme reagieren auf das Geschehen rund um dasTestfahrzeug. Um Fahrerassistenzsysteme gezielt und reproduzierbartesten zu konnen, mussen kritische Verkehrssituationen nachgebildetwerden. Dazu werden neben dem Testfahrzeug weitere Verkehrsteil-nehmer simuliert, die entweder normalen Verkehr bilden oder spezi-elle, auf Testfahrzeug und Assistenzsystem abgestimmte, kritische Si-tuationen realisieren. Diese Hindernisfahrzeuge (Obstacle, Obs) wer-den entweder von Fahrermodellen gesteuert oder von einem Situati-onsgenerator so beeinflusst, dass die gewunschte kritische Verkehrs-situation reproduzierbar simuliert wird. Als Maß fur das Gefahren-
7
1 Einleitung
potenzial der erzeugten kritischen Situationen, wird die KritikalitatK definiert (vgl. dazu Abschnitt 3.3.2).
Benutzer-Schnittstelle Ein wesentliches, aber nicht direkt zur Simulati-on notwendiges, Element der Simulationsumgebung ist die Benutzer-schnittstelle, mit der die Simulation konfiguriert und die Ergebnissebeobachtet werden konnen. Alle Teilnehmer des simulierten Verkehrswerden dabei dreidimensional visualisiert, so dass der Beobachter Si-mulationsergebnisse direkt beurteilen kann.
Die Abbildung 1.2 zeigt eine Ubersicht der wahrend der Projektlaufzeit ander Universitat Kassel realisierten Simulationsumgebung.
8
1.3 Anforderungen an die Simulationsumgebung
Visualisierung
Verkehrsszenario
Sensormodelle
Fahrzeugdynamik
Fahrerassistenzsystem
HiL Simulator
yVUT
xVUT
Visualisierungs- und Bedien-PC
Echtteil
Abbildung 1.2: Struktur der Simulationsumgebung
9
1 Einleitung
10
2 Konzept
2.1 Stand der Technik
2.1.1 Test von Fahrerassistenzsystemen
Wie bereits in Abschnitt 1.2 erwahnt, ist der Test von Fahrerassistenzsys-temen bisher mit erheblichem Material- und Personalaufwand verbunden,daher teuer und, bedingt durch den quasi-manuellen Test, nicht determi-nistisch.
Ein Losungsansatz besteht darin, das mit Assistenzsystemen ausgerusteteTestfahrzeug auf einer ausreichend großen Freiflache zu bewegen und dieAssistenzsysteme mit Informationen uber simulierten Fremdverkehr zu ver-sorgen. Bei dem von Bock u. a. [2005] vorgestellten Vorgehen wird derVerkehr mit dem Simulationsprogramm Pelops1
”erzeugt“ und als Aus-
gabe simulierter Sensoren den Systemen des Testfahrzeugs uber CAN2
ubermittelt. Die aktuelle Position und Geschwindigkeit des Testfahrzeugswerden uber CAN an Pelops zuruckgegeben, so dass eine Interaktion dersimulierten Fahrzeuge mit dem Testfahrzeug moglich ist. Die Sensorik desTestfahrzeugs ist deaktiviert, um die Sensorschnittstelle zur Ubermittlungder Daten der simulierten Hindernisse nutzen zu konnen.
Mit dem Konzept VEHiL (Vehicle Hardware-In-the-Loop) verfolgt TNOAutomotive3 einen anderen Ansatz. Dabei ist das mit Assistenzsystemenund Sensoren ausgerustete Testfahrzeug auf einem Rollenprufstand fixiert,der umgebende Verkehr wird durch relativ zum Testfahrzeug bewegte Hin-dernisse nachgebildet. Die Hindernisse sind auf einer Freiflasche rund um
1http://www.pelops.de/2Controller Area Network, [Bosch, 1991]3http://www.automotive.tno.nl/
11
2 Konzept
den Rollenprufstand frei beweglich und werden von Simulationsprogram-men so gesteuert, dass die Sensorik des Testfahrzeugs Bewegungen detek-tiert, wie sie in entsprechenden Manovern im realen Straßenverkehr vor-kommen wurden. Fur Tests von Fahrerassistenzsystemen mit VEHiL sindalso mindestens Fahrzeugprototypen erforderlich, die auf einem Rollen-prufstand betrieben werden konnen (vgl. [Verburg u. a., 2002] und [Giete-link u. a., 2004]).
Die hier vorgestellte Testumgebung kann in allen Phasen des Entwick-lungsprozesses angewendet werden und erlaubt durch die Unterstutzungvon
� Model-in-the-Loop Tests (MiL) die Risikoabschatzung verschiedenerAlgorithmen,
� Software-in-the-Loop Tests (SiL) die funktionale Absicherung der Al-gorithmen,
� Hardware-in-the-Loop Tests (HiL) die Absicherung von Prototypenund den Test von Seriensteuergeraten.
Durch die Unterstutzung entwicklungsbegleitender Tests kann eine iterati-ve Optimierung der zu testenden Systeme erreicht werden.
Uber den entwicklungsbegleitenden Einsatz hinaus kann die Simulations-umgebung auch nach Abschluss der Entwicklung zur Unterstutzung beiFehlersuche und Ursachenforschung dienen, indem im Feld beobachtete Si-tuationen in der Simulation nachgestellt werden konnen.
2.1.2 Marktrecherche
Vor Beginn der Entwicklung der Simulationsumgebung wurde eine umfang-reiche Marktrecherche durchgefuhrt, um die kommerzielle Verfugbarkeitvon Simulationswerkzeugen zu untersuchen, die als Grundlage der Ent-wicklung dienen konnten [Schmidt, 2004]. Anhand eines Anforderungska-talogs, der im Abschnitt A.1 abgedruckt ist, wurden dabei Programme zurSimulation des Verkehrsflusses, Programme zur Simulation der Fahrdyna-mik sowie ein System, das als Fahrsimulator konzipiert ist, untersucht.
12
2.2 Konzept der Eigenentwicklung
Zum Zeitpunkt der Untersuchung erfullte keines dieser Programme alleAnforderungen4.
Die Programme, deren Fokus auf dem Verkehrsfluss liegt, bieten ausge-feilte Moglichkeiten zur Simulation verschiedenster Verkehrsszenarien undStraßennetze, allerdings mit nur sehr eingeschrankten Moglichkeiten zurBeeinflussung des Testfahrzeugs sowie zur Abfrage der benotigten Parame-ter der Umgebung. Fur den Einsatz in Hardware-in-the-Loop Umgebungensind diese Programme nicht geeignet, da fahrzeugdynamische Daten nichtoder nur in sehr geringem Umfang berechnet werden und Schnittstellenzur Ansteuerung von realer Hardware nicht vorgesehen sind.
Simulationswerkzeuge, die auf die Fahrzeugdynamik ausgerichtet sind, bie-ten hingegen sehr umfangreiche Schnittstellen zur Manipulation des Ver-haltens eines einzelnen Fahrzeugs, jedoch sind hier die Moglichkeiten zurSimulation von komplexen Verkehrsszenarien deutlich geringer als bei derzuvor genannten Gruppe von Programmsystemen. Diese Werkzeuge bie-ten allerdings die Moglichkeit des HiL Einsatzes und die erforderlichenSchnittstellen zur Einflussnahme auf Testfahrzeug und Situation.
Die Kombination der Moglichkeiten und der Genauigkeit der Simulationder dynamischen Eigenschaften eines Fahrzeugs, die eine Fahrdynamiksi-mulation bietet, mit den Moglichkeiten der Erzeugung komplexer Szenari-en, wie sie benotigt werden, ist zum Zeitpunkt der Untersuchung am Marktnoch nicht verfugbar.
2.2 Konzept der Eigenentwicklung
Da keines der im Rahmen der Marktrecherche untersuchten und am Marktverfugbaren Programme alle Anforderungen fur die Entwicklung der ge-planten Simulationsumgebung erfullte, wurde die Simulationsumgebungals Eigenentwicklung realisiert. Dazu wurden aus den in Abschnitt 1.3beschriebenen Anforderungen drei Gruppen gebildet, um das Gesamtpro-jekt (vgl. Abbildung 2.1) in ubersichtlichere Module zu unterteilen. Die-se Module wurden dann in einer kooperativen Entwicklung realisiert und
4Die Marktrecherche wurde im Fruhjahr 2004 durchgefuhrt.
13
2 Konzept
Bedienung/Visualisierung
VUT Verkehr
Sensoren
Situations-generator
HiL Simulator
CANinterneSchnittstelle
Ethernet
Objekt-daten
Zustands-größen
Dynamik-eingriff
Zustands-größen
Hindernis-beeinflussung
Position,Orientierung
Zustands-größen
FAS aufDECOS Cluster
Knoten 1 Knoten 2 Knoten 3 Knoten 4
Stau-assistent
AdaptiveLicht- steuerung
Spurhalte-assistent
FlexRay
Knoten 5
Tür- steuerung
DECOS Cluster
CAN
L-FX DECOS Node
FlexRay-CAN- Gateway
L-FX DECOS Node
L-FX DECOS Node
L-FX DECOS Node
L-FX DECOS Node
Legende
Abbildung 2.1: Blockschaltbild der Simulationsumgebung
bilden zusammen eine Testumgebung fur Fahrerassistenzsysteme. Eine ge-naue Spezifikation der Schnittstellen bildet dabei die Grundlage fur dieerreichte Modularitat des Gesamtsystems.
Schmidt [2010] beschreibt die Entwicklung der Simulationsumgebung, dieallen anderen Modulen als Grundlage dient, indem sie Straßen- und Fahr-zeugmodelle fur die Simulation und die PC-seitige Visualisierung der Er-gebnisse zur Verfugung stellt. In [Tellmann, 2010] wird die Entwicklung derSensormodelle zur Erzeugung von Eingabedaten fur das Assistenzsystemund der Fahrermodelle zur Steuerung des Verkehrs beschrieben. Die vorlie-gende Arbeit beschreibt die Entwicklung und Implementierung des Modulszur Erzeugung kritischer Verkehrssituationen zum reproduzierbaren Testder Assistenzsysteme.
Die Basis der Simulationsumgebung bildet die Straße als geschlossenerRundkurs, auf der sich alle beteiligten Fahrzeuge bewegen. Der Verlauf derStraße kann mit Hilfe eines Straßeneditors angelegt und bearbeitet werden.
14
2.2 Konzept der Eigenentwicklung
Die Modellierung des Straßenverlaufs fur die Anwendung in Echtzeitsimu-lationen beschreiben Wang [2000], Holler [2005] und Schmidt [2010]. DerVerlauf der Straße im Raum wird dabei fur gerade Abschnitte durch Gera-densegmente und fur gekrummte Abschnitte durch die Superposition dreierkubischer Polynome beschrieben, die in Bogenlange parametriert sind.
In der Simulationsumgebung enthalten sind ein mit detaillierter Fahrdyna-mik simuliertes Testfahrzeug, das mit dem zu testenden Assistenzsystemund modellierten Sensoren
”ausgerustet“ ist, sowie beliebig5 viele Hin-
dernisfahrzeuge, deren Dynamik mit einfacheren Modellen nachgebildetwird. Die Bewegung des Testfahrzeugs kann von einem Fahrermodell unddem zu testenden Assistenzsystem beeinflusst werden. Das Fahrermodellubernimmt dabei die Querfuhrung entlang des Straßenverlaufs, das Assis-tenzsystem regelt die Langsfuhrung. Fahrereingriffe in die Langsfuhrungsind moglich, allerdings gibt das getestete Assistenzsystem in diesem Falldie Fuhrung ab, so dass diese Eingriffe nicht betrachtet werden mussen.Die Sensoren des Testfahrzeugs erfassen die Objekte im Umfeld des Test-fahrzeugs und liefern Eingangsdaten fur das Assistenzsystem. Wahrend des
”normalen“ Verkehrsflusses, d. h. solange keine kritische Situation erzeugt
werden soll, werden die Hindernisfahrzeuge ebenfalls von Fahrermodellengesteuert. Die Fahrermodelle ubernehmen dabei sowohl Langs- als auchQuerfuhrung und verhalten sich regelkonform. Sie versuchen also nicht,kritische Situationen zu provozieren, sondern halten sich an die Verkehrs-regeln [Tellmann, 2010].
Zur Erzeugung kritischer Situationen ubernimmt der Situationsgeneratordie Langs- und Querfuhrung eines oder mehrerer Hindernisfahrzeuge, sodass das konfigurierte Szenario mit der geplanten Kritikalitat ausgefuhrtwird.
Im Rahmen des Projekts DECOS wurden von den Projektpartnern fol-gende Applikationen als Testsysteme zur Verfugung gestellt, die auf der inDECOS entwickelten Zielhardware aus TriCore Prozessoren implementiertwurden:
� Stauassistent (STA)
� Spurhalteassistent (SHA)
5Die Simulationsprogramme begrenzen die Anzahl der simulierten Fahrzeuge nicht;wieviele Fahrzeuge in Echtzeit simuliert werden konnen, hangt von der Ausstattungdes Echtzeitrechners ab.
15
2 Konzept
Powerlink (PL) Baseboard
Physical Layer BoardPL FPGA Board
L-FX DECOS Node
PL MFR4300 Board
PL TC1796 Board
FX
FX ConnectorCAN
Abbildung 2.2: Ein DECOS FlexRay Knoten (nach [Angelow, 2007])
Knoten 1 Knoten 2 Knoten 3 Knoten 4
Stau-assistent
AdaptiveLicht- steuerung
Spurhalte-assistent
FlexRay
Knoten 5
Tür- steuerung
DECOS Cluster
L-FX DECOS Node L-FX DECOS NodeL-FX DECOS NodeL-FX DECOS Node
CAN
L-FX DECOS Node
FlexRay-CAN- Gateway
Powerlink (PL) Baseboard
Physical Layer BoardPL FPGA Board
PL MFR4300 Board
PL TC1796 BoardFX Connector
Powerlink (PL) Baseboard
Physical Layer BoardPL FPGA Board
PL MFR4300 Board
PL TC1796 BoardFX Connector
Powerlink (PL) Baseboard
Physical Layer BoardPL FPGA Board
PL MFR4300 Board
PL TC1796 BoardFX Connector
Powerlink (PL) Baseboard
Physical Layer BoardPL FPGA Board
PL MFR4300 Board
PL TC1796 BoardFX Connector
Powerlink (PL) Baseboard
Physical Layer BoardPL FPGA Board
PL MFR4300 Board
PL TC1796 BoardFX Connector
Abbildung 2.3: Das DECOS FlexRay Cluster und die Applikationen
� Adaptive Lichtsteuerung (ALS)
� Tursteuerung (Tur)
Der DECOS-Cluster besteht aus funf Knoten (vgl. Abbildung 2.2), die uberFlexRay untereinander und via CAN mit der Außenwelt kommunizierenkonnen (vgl. Abbildung 2.3). Die CAN-Schnittstelle wird dazu genutzt,die Kommunikation zwischen den Modellen der Sensoren, des Testfahr-zeugs und dem Assistenzsystem abzuwickeln. Dazu ist auf Knoten 1 einFlexRay-CAN-Gateway implementiert, das zwischen den Bussen vermit-telt. Auf den Knoten 2 - 5 sind die Applikationen implementiert, fur dieder Funktionsnachweis der DECOS-Technologie erbracht werden soll.
Kritische Verkehrssituationen werden nur zum Test des Stauassistenzsys-
16
2.2 Konzept der Eigenentwicklung
tems erzeugt, da alle anderen Systeme unbeeinflusst vom umgebenden Ver-kehr arbeiten. Die Systeme sind untereinander nicht vernetzt, so dass derSpurhalteassistent und die adaptive Lichtsteuerung von Situationen, diefur den Stauassistenten erzeugt werden, nicht beeinflusst werden.
Der Test von Fahrerassistenzsystemen mittels Simulation kann zu unter-schiedlichen Zwecken dienen. Getestet werden kann unter anderem
� zum Nachweis der Funktion,
� zur Uberprufung der Systemreaktion auf einen Sensorausfall,
� zur Bestimmung der Funktionsgrenzen des Systems,
� zum Nachweis der Robustheit der Algorithmen in Grenzbereichen.
Je nach Testzweck werden unterschiedliche Randbedingungen uberpruft.Die Parameter, die die Situation definieren, mussen vor dem Test festgelegtwerden. Dazu wird die Simulationsumgebung konfiguriert. Hierzu werdenverschiedene Konfigurationsdateien benotigt, die Informationen uber dievirtuelle Umwelt (das Straßennetz), die beteiligten Fahrzeuge (Testfahr-zeug und Hindernisfahrzeuge), die Sensorik des Testfahrzeugs, die Fah-rermodelle der Hindernisfahrzeuge sowie das zu testende Assistenzsystemund die zu erzeugenden Verkehrssituationen enthalten (vgl. dazu [Schmidt,2010], [Tellmann, 2010] und Abschnitt A.6). Diese Gesamtkonfiguration ei-ner Simulation wird
”Simulationsumgebung“ genannt.
Die in Abbildung 2.1 dargestellten”internen Schnittstellen“ zwischen den
einzelnen Simulationsmodulen transportieren die zur Simulation notwendi-gen Daten nicht direkt zwischen den Modulen, sondern uber eine zentraleDatenbasis. Die erzeugenden Module schreiben ihre Ausgabedaten in dieDatenbasis, aus der die konsumierenden Module die Daten im nachstenSimulationsschritt lesen konnen.
Abgesehen von der Visualisierung der Ergebnisse sind alle Simulations-module so entwickelt worden, dass sie sowohl auf dem Echtzeitrechner alsauch auf einem PC ausgefuhrt werden konnen. In den Modulen sind da-zu Callback-Funktionen implementiert, die entweder von der Simulations-steuerung des Echtzeitrechners oder von einem ahnlichen Zustandsauto-maten auf dem PC entsprechend dem aktuellen Zustand aufgerufen wer-den. Der Echtzeitrechner stellt dabei die eigentliche Zielplattform dar. Die
17
2 Konzept
Ausfuhrung auf dem PC erlaubt aufgrund der besser zuganglichen Benut-zerschnittstelle ein einfacheres Testen der Module und schafft daruber hin-aus die Voraussetzungen fur Model-in-the-Loop und Software-in-the-LoopTests.
2.2.1 Echtzeitrechner – HiL Simulation
Der Echtzeitrechner stellt die Schnittstellen zum Anschluss der zu testen-den Echtteile zur Verfugung und ermoglicht so, das Hardware-in-the-Loop(HiL) Konzept des Tests umzusetzen.
Zum Einsatz kommt ein CARTS Hardware-in-the-Loop System, das ausmehreren Rechnereinheiten aufgebaut ist. Dazu gehort ein PowerPC-Kno-ten, der die zentrale Datenbasis verwaltet und die Kommunikation zwi-schen den beteiligten Rechenknoten und dem Bedien-PC abwickelt. Da-ruber hinaus sind ein uber VME6-Bus angebundener PowerPC als Rechen-knoten, zwei externe Rechenknoten auf x86-Basis (ESU17 und ESU2) sowieein I/O-Subsystem in das System integriert. Die externen Rechenknotenverfugen neben CPU und Hauptspeicher auch uber eine Festplatte als per-manenten Datenspeicher. Das I/O-System stellt Ein- und Ausgabeschnitt-stellen fur analoge sowie digitale Signale zur Verfugung und erlaubt dieKommunikation uber CAN- und LIN8-Netzwerke. Die externen Modulewerden uber eine Gigabit Ethernet Verbindung mit der zentralen Datenba-sis synchronisiert. Abbildung 2.4 stellt die Komponenten des HiL Systemsin der Ubersicht dar.
Die Zustande aller beteiligten Simulationsmodule werden in einer zentra-len Datenbasis (DB) gespeichert. Um nun allen Modulen die jeweils ak-tuellen Daten zur Verfugung zu stellen, werden die benotigten Werte ausder zentralen Datenbasis zu Beginn eines jeden Simulationszyklusses andie lokale Datenbasis auf den Rechenknoten ubertragen. Von hier wer-den die benotigten Parameter in den Speicherbereich der Module kopiert,die die Werte benotigen. Nachdem alle auf einem Knoten ausgefuhrtenModule einen Simulationsschritt beendet haben, werden die Ausgabeda-ten wieder mit der lokalen Datenbasis synchronisiert und von dort zurzentralen Datenbasis ubertragen. Zur Wahrung der Echtzeitfahigkeit wird
6Versa Module Eurocard7ESU: External Simulation Unit8Local Interconnect Network, http://www.lin-subbus.org/
18
2.2 Konzept der Eigenentwicklung
VME System
ESU1 ESU2
VUT
Sensor
SG/Obs
Fahrer
I/O System
Gigabit Ethernet
A I/O D I/O
DB
MVME6100 A15
VME
CARTS HiL System
Knoten 1 Knoten 2 Knoten 3 Knoten 4
Stau-assistent
AdaptiveLicht- steuerung
Spurhalte-assistent
FlexRay
Knoten 5
Tür- steuerung
L-FX DECOS Node
FlexRay-CAN- Gateway
L-FX DECOS Node
L-FX DECOS Node
L-FX DECOS Node
L-FX DECOS NodeCAN
Ether
net
Elemente des HiL-SystemsESU1/2 External Simulation Unit
(Rechenknoten, x86)DB zentrale DatenbasisMVME6100 PPC RechnerA15 PPC RechnerPC Versuchsbedienung und
Visualisierung
SimulationsmoduleVUT Fahrdynamik des TestfahrzeugsSensor SensormodellSG/Obs Situationsgenerator und
HindernisfahrzeugeFahrer Fahrermodelle
Legende
PC
DECOS Cluster
Abbildung 2.4: Blockschaltbild des CARTS Hardware-in-the-LoopSimulators
die Synchronisation mit einem Ethernet-Frame abgewickelt. Durch dieseBeschrankung konnen pro Simulationszeitschritt maximal 238 Parameterzwischen der zentralen Datenbasis und der lokalen Datenbasis auf einemRechenknoten ubertragen werden. Sollen mehr als 238 Parameter synchro-nisiert werden, wird die Ubertragung auf mehrere Zeitschritte verteilt.
Alle Komponenten des Echtzeitrechners arbeiten unter dem Echtzeitbe-triebssystem Microware OS-9, so dass die Ausfuhrung der Simulationsmo-dule in Echtzeit gewahrleistet ist. Allerdings gilt die Einschrankung, dassdie Simulationsprogramme nicht nach der zugeteilten Zeit vom Betriebs-system unterbrochen werden, sondern innerhalb eines Simulationszyklus’zuruckkehren mussen, damit die vorgegebene Simulationsschrittweite ein-
19
2 Konzept
gehalten werden kann. Falls ein Simulationsprogramm nicht innerhalb dergeplanten Rechenzeit zuruckkehrt, werden die im zeitlichen Ablauf folgen-den Simulationsprogramme moglicherweise erst im darauffolgenden Zeit-schritt ausgefuhrt.
2.2.2 PC – SiL Simulation
Die Visualisierung der Ergebnisse ist in das Programm”PRAETORIA“ in-
tegriert, das auch die Umgebung fur die Software-in-the-Loop-Simulationauf dem PC bereitstellt (vgl. dazu [Schmidt, 2010]). Fur den SiL-Betriebwerden die Simulationsmodule nicht fur den Echtzeitrechner, sondern zurAusfuhrung auf einem Windows-PC ubersetzt. Die Simulationsprogram-me werden in PRAETORIA von einem vergleichbaren Zustandsautoma-ten gesteuert wie auf dem Echtzeitrechner. In der SiL-Simulation kann dieAusfuhrung der Module in Echtzeit nicht gewahrleistet werden, je nachRechnerauslastung und Zeitplanung des Betriebssystems kann die Zeit zwi-schen den einzelnen Funktionsaufrufen variieren. Dies stellt kein Problemdar, da hier ublicherweise keine Echtteile angeschlossen werden, die aufEchtzeitkommunikation angewiesen sind. Der Betrieb der Simulationsum-gebung auf dem PC erlaubt es auch, bereits die Modelle der zu testendenAssistenzsysteme zu untersuchen (Model-in-the-Loop-Test). Dabei konnendie Modelle der Testsysteme direkt in Matlab/Simulink ausgefuhrt werden,wobei die Kommunikation zwischen der Umweltsimulation in PRAETO-RIA und dem zu testenden System dann uber MPI9 abgewickelt wird (vgl.[Grabel, 2007]). Dazu wird ein zusatzlicher Funktionsblock in das SimulinkModell eingefugt, der die Kommunikationsschnittstelle mit der Datenbasisin PRAETORIA uber MPI zur Verfugung stellt (vgl. Abbildung 2.5).
Die in der Abbildung 2.5 mit Pfeilen zum Block”Simulationsdatenbank“
dargestellten Signale sind Eingange der Datenbasis, die hier ubermitteltenDaten werden von den in Simulink ausgefuhrten Modellen geliefert. Dievom Block
”Simulationsdatenbank“ ausgehenden Pfeile ubertragen Daten
von der Datenbasis zum Modell. Der Ausschnitt stellt nur die Schnittstellezur Simulationsdatenbank aus dem beim Projektpartner AEV eingesetz-ten Simulinkmodell dar. Eine Ubersicht uber das Gesamtmodell ist in inAbbildung A.3 dargestellt.
9Message Passing Interface
20
2.2 Konzept der EigenentwicklungÄnderungen für UNIK Enironment :- HC1: alte Version des GWF- HC2: Limits : 2.0/-2.0- HC2: LowPass : Sampletime -0.08- ACC1: ACC_ZVORH an "kein Vorderfzg" angeschlossen- vTmax als Konstante auf 120
Environment Simulation Simulation of a distributed ACC and HC
Hardware Timing Simulation
Simulation of Communication
Slot5 (empty)
function()
Slot4
function()
In1<Li> Out1
Slot3
function()
In1<Li> Out1
Slot2
function()In1<Li>
In2<Li>
Out1
Out2
Slot1
function()In1<Li>
In2<Li>
Out1
Out2
S-Function
SteeringFcn
Node4
partition_ACC_ACC4()
Node3
partition_ACC_ACC3()
Node2
partition_ACC_ACC2()
partition_HC_HC2()
Node1
partition_ACC_ACC1()
partition_HC_HC1()
Memory 2
MPI Client
Simulationsdatenbank
ACC_MOM_ANF
ACC_VERZ_ANF
ACC_MOTOR
ACC_BREMS
HC_LM
ACC_FAHRPEDACC_BREMSPEDACC_VWUNSCHACC_GRA_AKTACC_GRA_SET
ACC_ALF_ENACC_ALF_AKTACC_MOTORMACC_MOTORVACC_MSOLLIN
ACC_MINMOTMACC_MFWUNSCH
ACC_VERZMINACC_MOMMAXACC_WANDLVACC_UEBERS
ACC_GANGACC_SCHALT_AKT
ACC_VEIGENACC_AEIGENACC_STILLSTACC_ZVORH
ACC_ZDISTACC_ZV
ACC_ZVDIFFACC_ZA
ACC_ZADIFFHC_QABWHC_QGWF
HC_KRMHC_SPBR
HC_GTEHC_V_MPSOBS1_VDES
VUT_DOBS_1_D
HC2
HC2
HC1
HC1
[ENV]
[ACC3]
[ACC2]
[ACC1]
[HC2]
[HC1]
[ACC4]
[HC2]
[HC1]
[ENV]
[ENV]
[ENV]
[ENV]
[ENV]
[ENV]
[ACC4]
[ACC4]
[ACC3]
[ACC3]
[ACC3]
[ACC2]
[ACC2]
[ACC1]
[ACC1]
Convert
boolean
boolean
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
Convert
25
0
0
Cluster Schedule
Slot1
Slot2
Slot3
Slot4
Slot5
ACC4
ACC4
ACC3
ACC3
ACC2
ACC2
ACC1
ACC1
LM_Nm_out
<MMo_soll>
<Motoreingriff >
<Bremseingriff >
<aBA_soll>
<MMo >
<MMo _begr>
<iAS>
<dx_ist>
<vT _ist>
<aT_ist>
<ALF _Abstand_relativ>
<ALF _Abstand_eigen>
<ALF _Geschwindigkeit_eigen>
<dx_ideal>
<vT _ideal>
<aT_ideal>
<rT_ideal>
<RK_hold>
<RK_enable>
F_Reg
Bremseingriff
Motoreingriff
aBA_soll
MMo_soll
<aT_RF _Relativ >
<vT _max>
<Gaspedal>
<aT_RF _Geschw>
<vT _ist>
<aT_RF _Abstand>
ALF _Anfahren _ges teuert
ALF _Bremse_loesen
ALF _Stills tand
ALF _Abstand_relativ
ALF _Abstand_eigen
ALF _Geschwindigkeit_eigen
TG_refresh
TG_enable
RK_enable
<F_Reg>
<vT _max>
<vx _ist>
<TG_enable>
<TG_refresh >
aT_RF _Relativ
aT_RF _Geschw
aT_RF _Abstand
rT_ideal
dx_ideal
aT_ideal
vT _ideal
<aT_ist>
<vT _ist>
<dx_ist>
<vP _ist>
<aP_ist>
<ALF _Geschwindigkeit_eigen>
<ALF _Abstand_eigen>
<ALF _Abstand_relativ>
<ALF _Stills tand>
<ALF _Bremse_loesen>
<ALF _Anfahren _gesteuert>
<Brem spedal>
<aT_ideal>
RK_hold
<MMo _soll>
<Mom_Anf _Fahrer>
<Fahrpedal>
MMo_begrMMo_begr
<Querabweichung_m >
ENV <Gierwinkelfehler>
<Guete _Spurerkennung>
Querabweichung_Voraus_mQuerabweichung_Voraus_m
LM_Nm_out
GaspedalGaspedal
Fahrpedal
Bremspedal
vT _max
Tem pomat
Tem pomat_setzen
ALF_enable
ALF_aktiv
MMo
MMo_VM
MmotBegrGetr
MmotBegrMot
Mom_Anf _Fahrer
aBA_soll_m in
MMo_soll_max
MM_Wandl_VMMM_Wandl_VM
iASiAS
Gang_eingelegt
Schaltung
vT _is t
aT_ist
Stills tand
Zielobjekt_vorhanden
dx_ist
vP _ist
vx _is t
aP_is t
ax_is t
Querabweichung_m
Gierwinkelfehler
Kruemmung_1pm
Spurbreite_m
Guete_Spurerkennung
HC_vT _ist
VUT_D
OBS_1D
<vT _is t>
<Zielobjekt_vorhanden>
Gaspedal
Abbildung 2.5: MPI Block in Simulink (Ausschnitt aus Abbildung A.3)
Fur Software-in-the-Loop-Tests wird der aus den Modellen generierte Pro-grammcode fur die Ausfuhrung als Modul in PRAETORIA ubersetzt. Da-zu wird der eigentliche Funktionscode in eine Hullfunktion10 eingefugt, diean den Zustandsautomaten in PRAETORIA angepasst ist. Die Kommuni-kation zwischen Testsystem und Umweltsimulation geschieht dabei direktdurch die Datenbasis in PRAETORIA.
Ausnahmen vom reinen Software-in-the-Loop-Betrieb bilden die in Ab-schnitt 5.4 und Abschnitt 5.5 vorgestellten Module. Diese Module erlau-ben die Kommunikation mit realer Hardware uber CAN oder FlexRay, eineBeschreibung der Module ist in den jeweiligen Abschnitten enthalten.
Auf einem zum Zeitpunkt des Tests modernen PC11 lauft die SiL-Simula-tion mit funf Hindernisfahrzeugen und zwei konfigurierten Radarsensorenam Testfahrzeug nahezu in Echtzeit. Fur den Betrieb der zuvor genanntenModule zur CAN- bzw. FlexRay-Kommunikation muss die Ausfuhrbarkeitder SiL- oder MiL-Simulation in Echtzeit gewahrleistet werden.
10Engl. wrapper11AMD Athlon 64 3200+, 2GB RAM, Nvidia GeForce 6600 mit 256 MB RAM
21
2 Konzept
22
3 Grundlagen
3.1 Unfallstatistik
Die in verschiedenen Statistiken gesammelten Daten uber Verkehrsunfallekonnen - sofern Informationen zum Unfallhergang und nicht ausschließlichzum Unfallergebnis enthalten sind - fur die Bestimmung von kritischenVerkehrsszenarien und die Bewertung der Kritikalitat hilfreich sein.
Statistische Daten uber Verkehrsunfalle werden einerseits vom Statisti-schen Bundesamt und andererseits auch von verschiedenen Forschungsein-richtungen und Verbanden der Automobilhersteller (z. B. ACEA1) gesam-melt und ausgewertet.
Zur Ermittlung relevanter Situationen fur den Test von Fahrerassistenzsys-temen sollen statistische Informationen ausgewertet und daraus Schlusseuber mogliche haufig auftretende kritische Situationen im Straßenverkehrgezogen werden.
3.1.1 Unfallstatistik des Statistischen Bundesamtes
Die Erhebungen des Statistischen Bundesamtes zum Verkehrsunfallgesche-hen werden veroffentlicht. Altere Auswertungen liegen meist in gedruck-ter Form vor, Daten aus den letzten Jahren sind auch in elektronischerForm erhaltlich. Sie beschreiben detaillierte Auswertungen nach Unfallty-
1Association des Constructeurs Europeens d’Automobiles, http://www.acea.be/
23
3 Grundlagen
pen2, Unfallarten3, Straßenarten und Personenschaden, enthalten jedochnur sehr wenige Aussagen zu den Unfallursachen. Unfalle werden einemder folgenden Unfalltypen zugeordnet:
Fahrunfall wird ausgelost durch den Verlust der Kontrolle uber das Fahr-zeug. In der Folge konnen Kollisionen auftreten.
Abbiege-Unfall wird ausgelost durch den Konflikt zwischen einem Ab-biegenden und einem aus gleicher oder entgegengesetzter Richtungkommenden Verkehrsteilnehmer (auch Fußganger) an Kreuzungen,Einmundungen u.a.
Einbiegen/Kreuzen-Unfall wird ausgelost durch den Konflikt zwischen ei-nem einbiegenden Wartepflichtigen und einem vorfahrtberechtigtenFahrzeug an Kreuzungen, Einmundungen u.a.
Uberschreiten-Unfall wird ausgelost durch den Konflikt zwischen Fahr-zeug und einem Fußganger, der sich quer zur Fahrbahn bewegt.
Unfall durch ruhenden Verkehr wird ausgelost durch den Konflikt zwi-schen einem Fahrzeug des fließenden Verkehrs und einem Fahrzeug,das parkt oder halt, jedoch nicht verkehrsbedingt wartet.
Unfall im Langsverkehr wird ausgelost durch den Konflikt zwischen Ver-kehrsteilnehmern, die sich in gleicher oder entgegengesetzter Rich-tung bewegen.
Sonstiger Unfall ist keinem der anderen Unfalltypen zuzuordnen. [Statis-tisches Bundesamt, 2002]
2
”Der Unfalltyp beschreibt die Konfliktsituation, die zum Unfall fuhrte,
d.h. die Phase des Verkehrsgeschehens, in der ein Fehlverhalten oder einesonstige Ursache den weiteren Ablauf nicht mehr kontrollierbar machte. ImGegensatz zur Unfallart geht es also beim Unfalltyp nicht um die Beschrei-bung der wirklichen Kollision, sondern um die Art der Konfliktauslosungvor diesem eventuellen Zusammenstoß.“ [Statistisches Bundesamt, 2002]
3
”Die Unfallart beschreibt vom gesamten Unfallablauf die Bewegungsrich-
tung der beteiligten Fahrzeuge zueinander beim ersten Zusammenstoß aufder Fahrbahn oder, wenn es nicht zum Zusammenstoß gekommen ist, dieerste mechanische Einwirkung auf einen Verkehrsteilnehmer.“ [Statisti-sches Bundesamt, 2002]
24
3.1 Unfallstatistik
Außerdem wird jeder Unfall durch eine der folgenden Unfallarten beschrie-ben [Statistisches Bundesamt, 2002]:
1. Zusammenstoß mit anderem Fahrzeug, das anfahrt, anhalt oder imruhenden Verkehr steht.
2. Zusammenstoß mit anderem Fahrzeug, das vorausfahrt oder wartet.
3. Zusammenstoß mit anderem Fahrzeug, das seitlich in gleicher Rich-tung fahrt.
4. Zusammenstoß mit anderem Fahrzeug, das entgegenkommt.
5. Zusammenstoß mit anderem Fahrzeug, das einbiegt oder kreuzt.
6. Zusammenstoß zwischen Fahrzeug und Fußganger.
7. Aufprall auf ein Hindernis auf der Fahrbahn.
8. Abkommen von der Fahrbahn nach rechts/links.
9. Unfall anderer Art.
Aus den veroffentlichten Statistiken ist also nicht ableitbar, wie es zu demjeweiligen Verkehrsunfall gekommen ist bzw. wie die Ausgangssituation vordem Unfall war. Daher ist eine Ableitung besonders gefahrlicher bzw. furspezielle Unfallarten typischer Verkehrssituationen aus diesen Statistikennicht direkt moglich. Allerdings kann mit den statistischen Angaben dieRelevanz der vom Situationsgenerator erzeugten Situationen belegt wer-den. Dazu wird im Abschnitt 3.4.2 bei den jeweiligen Situationen auf denkorrespondierenden Unfalltyp sowie die entsprechende Unfallart verwie-sen.
Deutlich wird in der Statistik jedoch, dass rund 12% der Unfalle, die durchFehlverhalten des Fahrzeugfuhrers verursacht wurden, auf Abstandsfehlerzuruckzufuhren sind (vgl. Abbildung 3.1). Obwohl die Anzahl der Unfallemit Personenschaden insgesamt weiterhin rucklaufig ist, hat der Anteil derUnfalle, die durch Abstandsfehler verursacht werden, in den letzten Jahrenleicht zugenommen. Betrachtet man die Unfalle im Langsverkehr insge-samt (siehe Abbildung 3.2), so ist zu erkennen, dass uber 21% aller Unfallediesem Typ der Abstandsfehler zugeordnet werden konnen (vgl. [Statis-tisches Bundesamt, 2006]). Damit liegt jeder funfte Unfall im moglichenEinflussbereich von Assistenzsystemen zur Unterstutzung der Fahrzeug-langsfuhrung.
25
3 Grundlagen
Verkehrstüchtigkeit 6%
Falsche Straßenbenutzung 7%
Nicht angepassteGeschwindigkeit 16%
Abstand 12%
Überholen 4%Vorfahrt, Vorrang 15%
Abbiegen, Wenden,Rückwärtsfahren,Ein- und Anfahren 15%
Falsches Verhaltengegenüber Fußgängern 4%
Andere Fehlerbeim Fahrzeugführer 20%
Ursachen von Straßenverkehrsunfällen 2006
Abbildung 3.1: Unfallursachen 2006 (nach [Statistisches Bundesamt,2006])
3.1.2 Fazit
Statistische Informationen allein sind zur Auswahl relevanter Situationennicht ausreichend. Um Situationen fur den Katalog von Testszenarien aus-zuwahlen, werden daher zusatzlich die Funktionsbeschreibungen der zutestenden Assistenzsysteme sowie Erfahrungen aus dem Straßenverkehr ge-nutzt.
Die Spezifikation von Testfallen fur reale Fahrerassistenzsysteme war nichtThema dieser Arbeit, vielmehr wurde die Infrastruktur geschaffen, die dieSpezifikation von Testfallen sowie das Testen von Assistenzsystemen er-laubt. Die im weiteren Verlauf dargestellten Tests am im Rahmen des For-schungsprojektes DECOS implementierten Fahrerassistenzsystem dienenals Anwendbarkeitsnachweis der Methode und stellen keinen vollstandigenTest dar.
26
3.1 Unfallstatistik
Fahrunfall 22%
Abbiege-Unfall 13%
Einbiegen/Kreuzen-Unfall 25%
Überschreiten-Unfall 5%
Unfall durchruhenden Verkehr 3%
Unfall imLängsverkehr 21%
Sonstiger Unfall 11%
Unfalltypen von Straßenverkehrsunfällen 2006
Abbildung 3.2: Unfalltypen 2006 (nach [Statistisches Bundesamt, 2006])
27
3 Grundlagen
3.2 Koordinatensysteme
Zur Beschreibung der verschiedenen Elemente der Simulationsumgebungwerden unterschiedliche Koordinatensysteme genutzt. Dazu gehoren
� ein Inertialsystem als globales Bezugssystem, in dem die Position inkartesischen Koordinaten (xE, yE, zE) beschrieben wird,
� ein Straßenkoordinatensystem, das den zuruckgelegten Weg D ent-lang der Straßenmittellinie, die Querablage O von dieser Mittelliniesowie die Hohe L uber der Fahrbahnoberflache beschreibt,
� zu jedem Punkt auf dem Mittellinienpolynom ein Fahrbahnkoordi-natensystem, das die Straßenoberflache beschreibt (xr, yr, zr) sowie
� zu jedem Fahrzeug ein fahrzeugfestes Koordinatensystem (xV, yV, zV).
xr
zryr
D
OxV
yV
yE
xE
-1
1
Abbildung 3.3: Koordinatensysteme
Die beschriebenen Koordinatensysteme sind jeweils so gewahlt, dass sieder Definition in [Normenausschuß Kraftfahrzeuge (FAKRA), 1994] ent-sprechen. Abbildung 3.3 zeigt die genannten Koordinatensysteme.
Die globalen Koordinaten werden zur Berechnung der Fahrzeugbewegun-gen im Raum sowie zur Visualisierung verwendet. Zur Beschreibung und
28
3.2 Koordinatensysteme
xV
zV
yV
Gieren
Nicken
Wanken
Abbildung 3.4: Koordinatensystem nach DIN 70000 [NormenausschußKraftfahrzeuge (FAKRA), 1994]
Erzeugung von Verkehrssituationen sind Straßenkoordinaten jedoch bessergeeignet. Aus den Straßenkoordinaten (D,O,L) konnen auf analytischemWeg globale Koordinaten berechnet werden, indem zunachst der die Stra-ßenmittellinie beschreibende Spline an der Stelle der aktuellen BogenlangeD ausgewertet wird. Zu dem so gefundenen Punkt ~p werden yr skaliert mitO und zr skaliert mit L addiert.
Die Bestimmung von Straßenkoordinaten D,O,L aus vorliegenden karte-sischen Koordinaten xE, yE, zE ist ungleich aufwandiger, da dazu zunachstdas zugehorige Geraden- oder Splinesegment gefunden werden muss, umschließlich die Stutzstelle D auf dem Spline numerisch zu bestimmen. Istdie Stutzstelle bekannt, konnen O und L analytisch berechnet werden (vgl.[Schmidt, 2010]). Zur einfachen Zuordnung eines Fahrzeugs zu einer Fahr-spur sind die Fahrspuren symmetrisch zur Mittellinie beginnend mit 1 inRichtung der O-Koordinate nummeriert.
29
3 Grundlagen
Die fahrzeugfesten Koordinatensysteme entsprechen der Abbildung 3.4,dabei zeigt die xV-Achse in Fahrtrichtung nach vorne und liegt in derFahrzeuglangsmittelebene. Die yV-Achse steht senkrecht auf dieser Ebeneund zeigt nach links, die zV-Achse ist nach oben gerichtet. Die Gier-, Nick-und Wankwinkel sind jeweils positiv eingezeichnet.
3.3 Kritische Verkehrsszenarien
Das Ziel der hier beschriebenen Testumgebung ist, kritische Verkehrssitua-tionen definierter Kritikalitat zu erzeugen, so dass Fahrerassistenzsystemereproduzierbar und definiert getestet werden konnen.
Zunachst werden die verwendeten Begriffe definiert.
3.3.1 Kritische Verkehrssituation
Definition 1 (Kritische Situation im Sinne dieser Arbeit):Eine Verkehrssituation ist immer dann kritisch, wenn eine der folgendenBedingungen4 zutrifft:
� Es kommt zu einer Kollision zwischen Fahrzeug und Hindernis oder
� der definierte Mindestabstand dmin zwischen Fahrzeug und Hinderniswird unterschritten, ohne dass es zu einer Kollision kommt.
3.3.2 Kritikalitat
Die Kritikalitat K beschreibt ein Maß fur die Gefahrlichkeit einer Ver-kehrssituation, in der ein Eingriff eines Fahrerassistenzsystems erforder-lich ist. K bezieht sich dabei immer auf die bereits bewaltigte Situation,d.h. der Eingriff des Assistenzsystems ist abgeschlossen. Grundsatzlich gilt:K ∈ [0; 1].
4Selbstverstandlich kommen daruber hinaus im Straßenverkehr auch kritische Situa-tionen vor, die von den genannten Bedingungen nicht abgedeckt werden. Allerdingsspielen diese Situationen in der vorliegenden Arbeit keine Rolle und werden dahernicht betrachtet und auch hier nicht genannt.
30
3.3 Kritische Verkehrsszenarien
Zunachst sind einige Großen zu definieren, die fur die Berechnung undDefinition der Kritikalitat erforderlich sind. Die Abbildung 3.5 stellt dieim Folgenden verwendeten Abstande dar.
VUT Obs
Δdmin
ΔDSoll
ΔD
Abbildung 3.5: Testfahrzeug und Hindernis, Abstande
Der Sollabstand in Langsrichtung ergibt sich dynamisch aus der Geschwin-digkeit des vorausfahrenden Hindernisfahrzeugs zu
dSoll(t) = vObs(t) · tgap. (3.1)
Die einzuhaltende Zeitlucke tgap ist konfigurierbar. Der Standardwert be-tragt tgap = 1,8 s, das entspricht dem geforderten halben Tachowert (vgl.dazu STVO, §4 (Abstand) und [Hentschel u. Konig, 2007]).
Der minimal erforderliche Abstand entspricht der minimalen Detektions-distanz, d.h. der Entfernung zwischen Sensor und Objekt, unterhalb derder Sensor das Objekt nicht mehr detektieren kann. Tellmann [2010] gibtdie minimale Erkennungsdistanz des Sensormodells mit dmin = 2 m an. InAnlehnung an einen realen Sensor wird der Standardwert des Mindestab-standes auf dmin,lon = 3 m festgelegt (vgl. dazu z. B. [Basten u. Braschel,2003]), der Wert ist aber frei konfigurierbar. Wird der Mindestabstandunterschritten, ist eine Situation immer mit der Kritikalitat K = 1 zu be-werten, da das Assistenzsystem bei vermeintlich nicht mehr vorhandenemZielobjekt freie Fahrt annehmen und versuchen konnte, das Fahrzeug aufdie eingestellte Wunschgeschwindigkeit zu beschleunigen. Gleichung (3.2)beschreibt den aktuellen Sollabstand in Langsrichtung:
dSoll,lon(t) = max (dmin,lon; vObs(t) · tgap) (3.2)
Im Stillstand wird der Sollabstand auf dSoll = 2 · dmin festgelegt, um auchunvorhergesehene Annaherungen an das Hindernisfahrzeug tolerieren zu
31
3 Grundlagen
konnen. Eine unvorhergesehene Annaherung konnte beispielsweise durchZuruckrollen des Hindernisfahrzeugs verursacht werden.
Der laterale Sollabstand wird nach Burckhardt [1993] auf
dSoll,lat ≥ dmin,lat = 0,6 m
festgelegt. Auch dieser Wert kann konfiguriert werden.
Die Kritikalitat K wird wie folgt definiert:
Definition 2 (Kritikalitat):Die Kritikalitat bezieht sich auf die Moglichkeiten des zu testenden Assis-tenzsystems, etwa hinsichtlich der aufzubringenden Verzogerung.
K = 0 Es besteht keine unmittelbare Kollisionsgefahr, die Situation birgtlediglich das immer vorhandene latente Gefahrenpotential [Mitschkeu. a., 1982].
K ∈ ]0,1[ Die Kollision kann vom Assistenzsystem verhindert werden, derAbstand zwischen Testfahrzeug und Hindernisobjekt ist nach Ab-schluss des Manovers jedoch kleiner als gewunscht. Der Abstand ∆Dzwischen Testfahrzeug und Hindernis liegt im Intervall ]dmin; dSoll[.
K = 1 Das Assistenzsystem kann die Kollision bzw. das Unterschreiten desMindestabstandes mit eigenen Mitteln (z. B. mit der zur Verfugungstehenden Beschleunigung oder Verzogerung) nicht verhindern, fahr-physikalisch kann die Kollision aber noch verhindert werden.
Die Berechnung der Kritikalitat ist in Gleichung (3.3) beschrieben.
K =
1 fur ∆D < dmin
max(
0; 1− ∆D−dmin
dSoll−dmin
)fur dmin ≤ ∆D ≤ dSoll
0 fur ∆D > dSoll
(3.3)
In Gleichung (3.3) beschreibt ∆D den Abstand zwischen Testfahrzeug undHindernis nach dem Ende des Assistenzsystemeingriffes.
32
3.4 Verkehrssituationen fur Langsfuhrungssysteme
3.4 Verkehrssituationen furLangsfuhrungssysteme
3.4.1 Funktionsbeschreibung des Stauassistenten
Der Stauassistent funktioniert im Normalbetrieb, d.h. auf einer Straßemit fließendem Verkehr wie eine
”normale“ automatische Distanzregelung
(ADR5). Das bedeutet, dass ein damit ausgerustetes Fahrzeug bei freierFahrt mit der vom Fahrer gewunschten Geschwindigkeit vWunsch bewegtwird bzw. bei vorausfahrendem Hindernis im Abstand dWunsch folgt.
Als Erweiterung zur einfachen automatischen Distanzregelung, die erst beiGeschwindigkeiten uber etwa 30 km/h nutzbar ist, kann der Stauassistentdas Fahrzeug auch bis zum Stillstand abbremsen, wenn das Hindernis bei-spielsweise als Stauende erkannt wird. Fahrt das Vorderfahrzeug wiederan, kann der Stauassistent auch das eigene Fahrzeug anfahren und demVorderfahrzeug im gewunschten Abstand folgen oder bei freier Fahrt aufdie Wunschgeschwindigkeit beschleunigen.
Das System ist auf die reine Langsfuhrung des Fahrzeugs (Regelung derGeschwindigkeit durch Beeinflussung von Motormoment und Bremse) be-schrankt, die Querfuhrung bleibt dem Fahrer uberlassen. Sobald der Fahrerdurch Betatigung von Gas- oder Bremspedal in die Langsdynamik eingreift,wird das Assistenzsystem inaktiv.
3.4.2 Situationen
Dieses Kapitel beschreibt Verkehrssituationen, die mit definierter Kritika-litat erzeugt werden konnen.
Fur alle Situationen gilt, dass es unweigerlich zur Kollision kommt, fallsvVUT nicht innerhalb des zur Verfugung stehenden Bremswegs dB auf vObs
verringert werden kann. Zur Verringerung der Geschwindigkeit wird dieZeit tB benotigt:
tB =∆v
aVUT=vObs − vVUT
aVUT(3.4)
5auch Adaptive Cruise Control (ACC)
33
3 Grundlagen
ΔD0
D
O
VUT
Obs
Abbildung 3.6: Spurwechselsituation
Dies gilt unter der Voraussetzung, dass die Bremsbeschleunigung des Test-fahrzeugs konstant uber der Geschwindigkeit ist: aVUT(vVUT) = konstant.Außerdem wird angenommen, dass sofort nach Detektion des Hindernis-fahrzeugs durch den Sensor der maximale Bremsdruck zur Verfugung steht6
und damit die maximal zur Verfugung stehende Verzogerung genutzt wer-den kann.
Einscheren
Ein vorausfahrendes Hindernisfahrzeug Obs schert mit vObs < vVUT vordem Testfahrzeug VUT ein (vgl. Abbildung 3.6). Das Testfahrzeug kanndabei frei fahren oder im geregelten Abstand einem Fuhrungsfahrzeug fol-gen.
Bewegt sich das Hindernisfahrzeug mit konstanter Geschwindigkeit undreicht der Abstand zum Verzogern aus, dann stellt sich der minimale Ab-stand dann ein, wenn die Geschwindigkeit des Testfahrzeugs gleich der Ge-schwindigkeit des Hindernisses ist (vVUT = vObs). Unfalle, die durch diesesSzenario ausgelost werden, haben den Typ 6, Unfall im Langsverkehr unddie Unfallart7 2.
6Diese Voraussetzung kann beispielsweise durch die Vorpositionierung der Bremsba-cken erfullt werden. Dabei werden die Bremsbacken nur soweit aus ihrer Ruhepo-sition in Richtung Bremsscheibe gefahren, dass gerade noch keine Bremswirkungeintritt.
7Zur Erlauterung der Unfallart und des Unfalltyps siehe Abschnitt 3.1.1
34
3.4 Verkehrssituationen fur Langsfuhrungssysteme
ΔD0
VUTObs
D
O
Abbildung 3.7: Bremsen
Vollbremsung des vorausfahrenden Fahrzeugs
Ein vorausfahrendes Hindernisfahrzeug verzogert, wie in Abbildung 3.7dargestellt, bis zum Stillstand (vObs = 0). Abhangig von der gewunschtenKritikalitat und der aktuellen Geschwindigkeit der beiden beteiligten Fahr-zeuge wird die Verzogerung des Hindernisfahrzeugs eingestellt. Dabei wirddas Hindernisfahrzeug nicht zwangslaufig nur im Rahmen der physikali-schen Moglichkeiten verzogert, sondern so, dass die geforderte Kritikalitaterreicht wird, maximal allerdings mit aObs = −15 m/s2. Von dieser Situa-tion provozierte Unfalle gehoren zum Unfalltyp 6 sowie zur Unfallart 2.
Abbremsen des vorausfahrenden Fahrzeugs
Die Situation ahnelt der Vollbremsung, allerdings wird hier nur bis zueiner Geschwindigkeit vObs = vSoll > 0 verzogert und dann mit dieserGeschwindigkeit die Fahrt fortgesetzt. Fur Unfallart und -typ gelten dieAngaben wie zur Vollbremsung.
Abbremsen und Wiederanfahren
Das Hindernisfahrzeug bremst bis zur Geschwindigkeit vObs = vSoll,1, be-schleunigt wieder und setzt danach die Fahrt mit vObs = vSoll,2 fort. DieUnfallart eines evtl. provozierten Unfalles ist 2, der Unfalltyp wieder 6.
35
3 Grundlagen
VUTObs 2
Obs 1
Obs 3
Obs 4
Obs 5
Obs 6
Abbildung 3.8: Stau
Stop-and-Go
Ein Hindernisfahrzeug fuhrt die Situation”Abbremsen und Wiederanfah-
ren“ wiederholt aus.
Stau
Mehrere Hindernisfahrzeuge bilden uber die gesamte Fahrbahnbreite einenStau (Abbildung 3.8), die Fahrzeuge fahren nach einer Wartezeit tw wiederan und setzen dann ihre Fahrt mit Wunschgeschwindigkeit fort.
Einbiegen
Ein Hindernisfahrzeug biegt mit vObs < vVUT vor dem Testfahrzeug aufdie vom Testfahrzeug befahrene Fahrspur ein (vgl. Abbildung 3.9).
Die mit dieser Situation provozierten Unfalle gehoren zum Unfalltyp 3,Einbiegen/Kreuzen-Unfall und haben die Unfallart 5.
36
3.4 Verkehrssituationen fur Langsfuhrungssysteme
VUT
D
O
ΔD0
Obs
Abbildung 3.9: Einbiegen
D
O
vH << vVUTVUT
ObsvH >> vVUT
Abbildung 3.10: Uberholen, Einscheren, Bremsen
Uberholen, Einscheren und Bremsen
Das Hindernisfahrzeug nahert sich dem Testfahrzeug von hinten mit hoherGeschwindigkeit vObs � vVUT, uberholt das Testfahrzeug dann, je nachAusgangslage, rechts oder links. Dann schert das Hindernis vor dem Test-fahrzeug ein und bremst auf vObs � vVUT ab (vgl. Abbildung 3.10). Dievorgegebene Kritikalitat bezieht sich hierbei auf das Bremsmanover.
Auf diese Art provozierte Unfalle haben den Unfalltyp 6 und die Unfall-art 2.
37
3 Grundlagen
38
4 Erzeugung kritischerVerkehrssituationen
4.1 Modellannahmen
Im Folgenden werden sowohl die Bewegung des Testfahrzeugs wie auchdie der Hindernisfahrzeuge mit kinematischen Zusammenhangen beschrie-ben. Die Krafte, die die Bewegung der Fahrzeuge verursachen, mussenfur die Berechnung und Erzeugung kritischer Verkehrssituationen nichtberucksichtigt werden. Dies gilt fur Testfahrzeug und Hindernisfahrzeu-ge gleichermaßen. Die Zustandsgroßen des Testfahrzeugs werden vom Si-tuationsgenerator zwar als Eingangsdaten verarbeitet (vgl. auch Abbil-dung 2.1), welche Krafte diese Zustande verursacht haben, ist dabei abernicht relevant. Fur die Bewegung der Hindernisfahrzeuge werden erforder-liche Beschleunigung und Verzogerung aus den aktuellen Zustandsgroßenvon Hindernis- und Testfahrzeug sowie der gewunschten Kritikalitat be-rechnet und direkt angewandt, um den geplanten Effekt zu erzielen.
In Abschnitt 3.4.2 wurde eine vereinfachende Annahme zur Berechnungder fur die Verzogerung des Testfahrzeugs benotigten Zeit sowie des indieser Zeit zuruckgelegten Weges beschrieben. Die dort beschriebene idea-le Bremse, die ohne Anstiegszeit den vollen Bremsdruck zur Verfugungstellt, wird durch ein Modell mit Schwelldauer ersetzt [Breuer, 2004]. NachJansson [2004] ist die Modellierung der Bremse als PT1-Glied mit einer An-stiegszeit von etwa 0,3 s hinreichend genau, um reale Verzogerungsvorgangenachzubilden1.
a(t) = aVUT(1− e−t/T ) (4.1)
1Gleichung (4.1) muss angepasst werden, falls im Modell die Vorpositionierung derBremsbacken oder ein pradiktiver Bremsdruckaufbau berucksichtigt werden sollen.
39
4 Erzeugung kritischer Verkehrssituationen
Da die fur die Verzogerung erforderliche Zeit daraus analytisch nicht zubestimmen ist, wird die entsprechende Verzogerungszeit numerisch berech-net. Hierzu werden in jedem Simulationsschritt die Gleichungen (4.1), (4.2)und (4.3) ausgewertet, um die erforderliche Verzogerungszeit und den dabeizuruckgelegten Weg zu berechnen.
v(t) = v(t− τ) + a(t)τ (4.2)
D(t) = D(t− τ) + v(t)τ (4.3)
τ beschreibt die Simulationsschrittweite. Aus dem damit bekannten Weg,resp. der bekannten Position auf der Straße (D(t+ tVerz)), kann dann dieSollposition des Hindernisfahrzeugs zur Erzeugung einer Situation definier-ter Kritikalitat K berechnet werden.
4.2 Hindernisposition
Der Weg, den das Testfahrzeug wahrend der Verzogerung noch zurucklegt,ist aus Gleichung (4.3) bekannt. Damit kann fur bekannten AufenthaltsortDObs und Geschwindigkeit vObs die Kritikalitat K der Situation berechnetwerden.
Umgekehrt kann mit den Großen Zielgeschwindigkeit und geforderte Kriti-kalitat auch der anzustrebende Aufenthaltsort des Hindernisfahrzeugs furden Detektionszeitpunkt t1 bestimmt werden. Der Detektionszeitpunkt be-schreibt den Moment, in dem das Hindernisfahrzeug vom Sensor des Test-fahrzeugs erfasst wird, ab diesem Moment kann das Assistenzsystem aufdas Hindernis reagieren. Zu bestimmen ist hierbei, in welchem Abstandvom Testfahrzeug sich das Hindernis zum Zeitpunkt t1 befinden muss, umeine Situation der gewunschten Kritikalitat zu erreichen.
Der Abstand nach Verzogerung des Testfahrzeugs auf die Geschwindigkeitdes Hindernisses wird durch
∆D(t1 + tVerz) = DObs(t1 + tVerz)−DVUT(t1 + tVerz) (4.4)
beschrieben.
40
4.3 Spurwechsel des Hindernisfahrzeugs
Dabei werden DVUT(t1 + tVerz) und tVerz mit den Gleichungen (4.2) und(4.3) bestimmt. Aus der Definition der Kritikalitat (Gleichung (3.3)) folgt
K = 1− ∆D − dmin
dSoll − dmin. (4.5)
Damit ergibt sich fur die Sollposition des Hindernisfahrzeugs DObs(t1 +tVerz)
DObs(t1 + tVerz) = (1−K)(dSoll − dmin) + dmin
+DVUT(t1 + tVerz) (4.6)
Ersetzt man DObs(t1 + tVerz) durch DObs(t1) + dObs(tVerz) und DVUT(t1 +tVerz) durch DVUT(t1) + dVUT(tVerz) so erhalt man fur den zu erzielendenAbstand zum Zeitpunkt der Detektion ∆D(t1)
∆D(t1) = DObs(t1)−DVUT(t1)
= (1−K)(dSoll − dmin) + dmin + dVUT(tVerz)− dObs(tVerz) (4.7)
Dabei reprasentieren DObs(tVerz) und DVUT(tVerz) den von Hindernis bzw.Testfahrzeug wahrend der Verzogerung des Testfahrzeugs noch zuruckge-legten Weg. In Abhangigkeit von der zu erzeugenden Situation kann darausder Auslosezeitpunkt t0 bestimmt werden.
4.3 Spurwechsel des Hindernisfahrzeugs
Fur den geplanten Spurwechsel zur Erzeugung einer kritischen Verkehrs-situation wird das Hindernisfahrzeug entlang einer angepassten Kosinus-Trajektorie bewegt (vgl. Abbildung 4.1). Diese Beschreibung ist aus ei-ner Untersuchung des Fahrerverhaltens beim Spurwechsel abgeleitet, diein [Salvucci u. Liu, 2002] beschrieben ist.
Die Querabweichung des Hindernisfahrzeugs von dem die Straßenmittel-linie beschreibenden Spline wird fur einen Spurwechsel nach links durch
O(D) = O(D0) +w
2
(1− cos
(D −D0
`π
))(4.8)
41
4 Erzeugung kritischer Verkehrssituationen
D - D0
wO D
O
Abbildung 4.1: Spurwechseltrajektorie
und fur einen Spurwechsel nach rechts durch
O(D) = O(D0)− w
2
(1− cos
(D −D0
`π
))(4.9)
beschrieben.
Dabei ist O(D0) die Querabweichung zum Zeitpunkt des Spurwechselbe-ginns, w die Spurwechselbreite und ` die gesamte Lange des Spurwechsel-vorgangs.
Um die Querabweichung O(t) fur den aktuellen Zeitpunkt berechnen zukonnen, ist also die zugehorige Position auf dem Fahrspurspline D(t) er-forderlich. Der vom Fahrzeug bei Bewegung auf der Spurwechseltrajek-torie zuruckgelegte Weg ist durch den Zusammenhang s = vObstSW ge-geben. Die Lange der Spurwechseltrajektorie berechnet sich aus dem Bo-genlangenintegral
Lab =
∫ b
a
√1 + [f ′(x)]2 dx (4.10)
mit f = O(D) wird
f ′ =d
dDO(D) =
wπ
2`sin
(D −D0
`π
)(4.11)
42
4.3 Spurwechsel des Hindernisfahrzeugs
ΔD
α ΔO
Abbildung 4.2: Stuckweise Linearisierung
und damit folgt fur L
Lab =
∫ b
a
√1 +
(wπ
2`sin
(D −D0
`π
))2
dD. (4.12)
Das in Gleichung (4.12) beschriebene Integral ist nicht geschlossen losbar,sondern fuhrt auf ein elliptisches Integral zweiter Art, dessen Auswer-tung in der Echtzeitsimulation nicht sinnvoll ist, zumal zur Berechnungdes zuruckgelegten Weges auch noch die Umkehrfunktion zu bestimmenware.
Die Projektion der Spurwechseltrajektorie auf den Fahrspurspline wird da-her durch abschnittsweise Linearisierung berechnet.
Mit
α = arctan
(∆O
∆DSpline
)(4.13)
und
lim∆DSpline→0
∆O
∆DSpline=
d
dDO(D) (4.14)
wird mit Gleichung (4.11)
α = arctan
(wπ
2`sin
(D −D0
`π
)). (4.15)
43
4 Erzeugung kritischer Verkehrssituationen
Daraus kann dann mit
∆DSpline(t) = cos(α)v(t)∆t (4.16)
und der Annahme, dass der Vorgang bei D0 begann, der in einem Zeit-schritt auf dem Fahrspurspline zuruckgelegte Weg berechnet werden
∆DSpline(t) = cos
(arctan
(wπ
2`sin
(D −D0
`π
)))v(t)∆t . (4.17)
Die aktuelle Position des Fahrzeugs auf dem Fahrspurspline wird danndurch folgenden Zusammenhang beschrieben
DSpline(t) = D0 +t∑
T=t0
∆DSpline(T ) . (4.18)
4.3.1 Lange des Spurwechselvorgangs
Die Lange des Spurwechselvorgangs hangt primar von der vom Fahrer to-lerierten Querbeschleunigung ab.
Die Querbeschleunigung aq berechnet sich aus
aq =v2
r= v2κ . (4.19)
Mit der Krummung κ
κ =f ′′(x)
(1 + f ′2(x))3/2
, (4.20)
f ′ nach Gleichung (4.11) und
f ′′(x) =d
dD2O(D) =
wπ2
2`2cos
(D −D0
`π
)(4.21)
wird
aq = v2
wπ2
2l2cos
(D −D0
`π
)(
1 +
[wπ
2`sin
(D −D0
`π
)]2)3/2
. (4.22)
44
4.3 Spurwechsel des Hindernisfahrzeugs
Damit kann nun die Querbeschleunigung in Abhangigkeit der Geschwin-digkeit sowie der Gesamtlange ` des Spurwechselvorgangs berechnet wer-den. Mit einer vorgegebenen maximal tolerierten Querbeschleunigung dieSoll-Lange zu berechnen, ist analytisch nicht direkt moglich.
Allerdings kann mit den folgenden Vereinfachungen eine Abschatzung ge-troffen werden:
Fur den Nenner N aus Gleichung (4.22) gilt mit der Abkurzung s = D −D0
N =
1 +
wπ2`sin(s`π)
︸ ︷︷ ︸u
2
3/2
.
Mit
w � l⇒ w2 � `2 ⇒ w2
`2� 1
und
0 ≤ sin2(s`π)≤ 1
folgt dann
u� 1
und
N =√
(1 + u2)3 ≈ 1 .
Fur aq gilt damit naherungsweise
aq ≈ v2 wπ2
2`2cos(s`π)
. (4.23)
Die Extrema der Kosinusfunktion liegen bei 0 ± nπ, damit kann als Be-tragsmaximum fur aq
|aq,max| = v2 wπ2
2`2(4.24)
45
4 Erzeugung kritischer Verkehrssituationen
angenommen werden.
Damit kann dann auch ` in Abhangigkeit von aq berechnet werden
`|aq≤aq,max ≥
√v2wπ2
2aq,max= v
√wπ2
2aq,max. (4.25)
Tolerierte Querbeschleunigung
Nach Mitschke u. Wallentowitz [2004] nutzen Durchschnittsfahrer nur et-wa die Halfte der maximal verfugbaren Querbeschleunigung. Als tolerier-te Querbeschleunigung wird hier daher ein Wert von 0,5g angenommen.Mit Gleichung (4.25) kann jetzt fur eine gegebene Geschwindigkeit v desHindernisfahrzeugs die projizierte Lange des Spurwechselvorgangs berech-net werden. Fur die Modellierung von Verkehrsszenarien kann die tolerier-te Querbeschleunigung auch als Parameter des Fahrermodells gespeichertwerden und damit abhangig vom Typ des Fahrers in die Simulation einge-hen.
Die in [Salvucci u. Liu, 2002] beschriebene Studie zum Spurwechselverhal-ten beschreibt eine Spurwechseldauer von 5,14±0,86 s bei einer Geschwin-digkeit v ≈ 30 m/s. Das entspricht einer tolerierten Querbeschleunigungvon aq ≈ 0,2g bei einer angenommen Spurbreite2 von w = 5 m.
4.3.2 Start des Spurwechselvorgangs
Um den Startzeitpunkt t0 bzw. die Startkoordinate D0,Obs = DObs(t0) desSpurwechselvorgangs berechnen zu konnen, ist ein Zusammenhang zwi-schen Querabweichung O und zuruckgelegtem Weg erforderlich. Wie obenbereits beschrieben, kann das Bogenlangenintegral fur die cos-Trajektorienicht analytisch gelost werden. Die numerische Integration bietet keineLosung fur die gesuchte Umkehrfunktion. Die gesuchte Koordinate D0,Obs
wird daher durch eine Naherung bestimmt (vgl. Abbildung 4.3). Hierbeiwird die Spurwechseltrajektorie zunachst durch eine lineare Trajektorieangenahert, fur die der Zusammenhang zwischen zuruckgelegtem Weg underreichter Querabweichung bekannt ist.
2Die Studie beschreibt das Spurwechselverhalten auf Landstraßen in den USA.
46
4.3 Spurwechsel des Hindernisfahrzeugs
VUTΔD(t1)
D
O
OZiel
ΔO
O0
D0,Obs
Abbildung 4.3: Linearisierung der Spurwechseltrajektorie
Der auf der linearen Trajektorie zuruckgelegte Weg wird beschrieben durch∆s = v∆t. Dabei ist ∆t die Dauer des Spurwechselvorganges. Fur dieQuerabweichung auf dieser Trajektorie gilt:
O(D) = O0 +D(t)−D0,Obs
`∆O (4.26)
Gleichung (4.26) gilt fur t0 < t < t0 + ∆t. Fur t < t0 und t > t0 + ∆t wirddas Fahrzeug entlang einer Fahrspur bewegt.
Mit dem entlang des Mittellinien-Splines zuruckgelegten Weg
D(t) = D0,Obs + cos(α)v · (t− t0) (4.27)
und
α = arctan∆O
`(4.28)
erhalt man
O(D) = O0 +cos(α)v · (t− t0)
`∆O. (4.29)
Dabei beschreibt ` nach Gleichung (4.25) die auf die D-Achse projizier-te Lange des gesamten Spurwechselvorgangs entlang der cosinusformigenTrajektorie.
47
4 Erzeugung kritischer Verkehrssituationen
Die beschriebene Linearisierung kann die Lange des zuruckgelegten Wegesnicht exakt abbilden, der Fehler kann jedoch fur die betrachteten Spur-wechselvorgange vernachlassigt werden. Zur Abschatzung des Fehlers sieheAbschnitt A.2.
Fur die Querabweichung gilt dann mit dem linearisierten Verlauf
O(∆s) = O0 +cos(α)∆s
`∆O. (4.30)
Aus der bekannten Soll-Querabweichung OZiel (vgl. dazu Abbildung 4.3)im Moment der ersten Detektion durch den Sensor
OZiel = O0 +cos(α)∆sZiel
`∆O
kann ∆s bestimmt werden
∆sZiel =
(OZiel −O0
∆O
)`
cosα. (4.31)
Mit Gleichung (4.27) ergibt sich daraus fur die Startkoordinate D0,Obs desSpurwechselvorgangs
D0,Obs = DZiel −(OZiel −O0
∆O
)`. (4.32)
Mit ∆D(t1) nach Gleichung (4.7) ist der geforderte Abstand zwischen Test-fahrzeug und Hindernis zum Detektionszeitpunkt bekannt. Berucksichtigtwerden mussen nun noch die Bewegung des Hindernisfahrzeugs bis zu die-sem Abstand und die Bewegung des Testfahrzeugs wahrend dieser Zeit.Fur das Hindernisfahrzeug kann eine gleichformige Bewegung vorausge-setzt werden, fur das Testfahrzeug wird eine gleichmaßig beschleunigteBewegung angenommen.
Das Hindernisfahrzeug legt auf der Spurwechseltrajektorie bis zum Detek-tionspunkt den Weg
∆s =D(OZiel)−D(t0)
cosα(4.33)
48
4.3 Spurwechsel des Hindernisfahrzeugs
zuruck und benotigt dafur die Zeit
∆t =∆s
v=
(OZiel −O0
∆O
)`
cosα
1
vObs. (4.34)
Das Testfahrzeug legt in dieser Zeit den Weg
∆DVUT = vVUT,0 ∆t+a(t0) ∆t2
2
= vVUT,0
(OZiel −O0
∆O
)`
cosα
1
vObs
+a(t0)
2
((OZiel −O0
∆O
)`
cosα
1
vObs
)2
(4.35)
zuruck. Damit erhalt man fur DVUT(t1) die Beschreibung
DVUT(t1) = DVUT(t0) + vVUT,0
(OZiel −O0
∆O
)`
cosα
1
vObs
+a(t0)
2
((OZiel −O0
∆O
)`
cosα
1
vObs
)2
. (4.36)
Fur DZiel erhalt man mit DZiel = DVUT(t1) + ∆D(t1)
DZiel = DVUT(t0) + vVUT,0
(OZiel −O0
∆O
)`
cosα
1
vObs
+a(t0)
2
((OZiel −O0
∆O
)`
cosα
1
vObs
)2
+ (1−K)(dSoll − dmin) + dmin + ∆DVUT(tVerz)
−∆DObs(tVerz). (4.37)
Fur ∆DObs(tVerz) erhalt man mit der oben geforderten gleichformigen Be-wegung
∆DObs(tVerz) = tVerzvObs. (4.38)
49
4 Erzeugung kritischer Verkehrssituationen
Nach Gleichung (4.32) erhalt man als Startposition D0 des Spurwechsel-vorgangs
D0,Obs = DVUT(t1) + ∆D(t1)
= DVUT(t0) + vVUT,0
(OZiel −O0
∆O
)`
cosα
1
vObs
+a(t0)
2
((OZiel −O0
∆O
)`
cosα
1
vObs
)2
+ (1−K)(dSoll − dmin) + dmin + ∆DVUT(tVerz)
− tVerzvObs. (4.39)
Aufgrund der nur numerisch berechenbaren Verzogerungszeit tVerz kannGleichung (4.39) nur wahrend der Simulation ausgewertet werden.
Zur Bestimmung von D0,Obs nach Gleichung (4.39) muss OZiel bekanntsein. Beeinflusst wird OZiel durch die Geometrie des Hindernisfahrzeugssowie durch die Geometrie des Sensors, der dem Assistenzsystem Infor-mationen uber die Objekte in der Umgebung liefert. Die Abbildung 4.3verdeutlicht diesen Zusammenhang.
4.4 Bremsen des Hindernisfahrzeugs
Nahert sich das Testfahrzeug mit der Geschwindigkeit vVUT,0 einem vor-ausfahrenden Hindernisfahrzeug, das mit der Geschwindigkeit vObs,0 fahrt,und lost das Hindernisfahrzeug im Abstand ∆D0 vor dem Testfahrzeug eineBremsung mit der Verzogerung aObs aus, gelten wieder die in den Gleichun-gen (4.1), (4.2) und (4.3) formulierten Zusammenhange fur die Bewegungdes Testfahrzeugs. Das Hindernisfahrzeug legt wahrend der Verzogerungvon vObs,0 auf vObs,1 noch den Weg ∆DObs,Verz zuruck:
∆DObs,Verz =1
aH
(vObs,0(vObs,1 − vObs,0) +
(vObs,1 − vObs,0)2
2
). (4.40)
Der resultierende Abstand zwischen Testfahrzeug und Hindernis wird durchfolgenden Zusammenhang beschrieben:
∆Dres = ∆D0 + ∆DObs,Verz −∆DVUT,Verz . (4.41)
50
4.4 Bremsen des Hindernisfahrzeugs
Ist die Zeit tVUT,Verz, die das Testfahrzeug fur die Verringerung der Ge-schwindigkeit auf vObs,1 benotigt, großer als die Zeit, die wahrend derVerzogerung des Hindernisfahrzeugs vergeht, so ergibt sich der wahrendder Verzogerung des Testfahrzeugs zuruckgelegte Weg des Hindernisfahr-zeugs aus
∆DObs = ∆DObs,Verz + vObs,1(tVUT,Verz − tObs,Verz) . (4.42)
Zur Beeinflussung der Situation eignet sich bei vorgegebener Zielgeschwin-digkeit vObs,1 nur der Parameter aObs, da der Anfangsabstand ∆D0 unddie Geschwindigkeit des Testfahrzeugs vVUT durch die Reaktion des Assis-tenzsystems bestimmt werden. Die Variation der Ausgangsgeschwindigkeitdes Hindernisfahrzeugs ist aufgrund der damit hervorgerufenen Reaktiondes Assistenzsystems ungeeignet, da das Bremsmanover nach Moglichkeitaus einer Situation ohne Bremseingriff ausgelost werden soll.
Die Verzogerung des Hindernisfahrzeugs wird also so vorgegeben, dass sichein resultierender Abstand entsprechend der Definition der Kritikalitat(Gleichung (3.3)) einstellt.
Die Kritikalitat der Situation berechnet sich damit zu
K = 1−∆D0 +
1
aH
(vObs,0(vObs,1 − vObs,0) +
(vObs,1 − vObs,0)2
2
)dSoll − dmin
+vObs,1 ∆tVerz −∆DVUT,Verz − dmin
dSoll − dmin.
(4.43)
Die vom Hindernisfahrzeug aufzubringende Verzogerung aObs ergibt sichmit
∆Dres = (1−K)(dSoll − dmin) + dmin (4.44)
und Gleichung (4.43) zu
aObs =vObs,0(vObs,1 − vObs,0) +
(vObs,1 − vObs,0)2
2∆Dres −∆D0 − vObs,1 ·∆tVerz + ∆DVUT,Verz
. (4.45)
Die Terme vObs,1 · ∆tVerz und ∆DVUT,Verz werden wieder numerisch ausden Gleichungen (4.1), (4.2) und (4.3) bestimmt.
51
4 Erzeugung kritischer Verkehrssituationen
Obs
VUT
Abbildung 4.4: 135° Kreuzung
4.5 Einbiegen eines Hindernisfahrzeugs
Biegt das Hindernisfahrzeug vor dem Testfahrzeug auf die Fahrbahn desTestfahrzeugs ein, muss die Geschwindigkeit des Testfahrzeugs zur Ver-meidung einer Kollision auf die Geschwindigkeit des Hindernisses reduziertwerden. Die Verzogerung des Testfahrzeugs wurde bereits beschrieben, furden Einbiegevorgang ist noch der Weg des Hindernisfahrzeugs zu beschrei-ben.
Zur Beschreibung von Kreuzungen mussen Ubergangssplines definiert wer-den, die die Navigation uber verschiedene Straßensegmente hinweg erlau-ben. Entlang eines solchen Ubergangssplines (Abbildungen 3.9 und 4.4)verlauft dann die Bewegung des Hindernisfahrzeugs wahrend des Einbie-gens.
Aus der bekannten Lange dieses Splines und der ebenfalls bekannten Be-schleunigung und Start- und Zielgeschwindigkeit des Hindernisfahrzeugskonnen dann die Dauer des Einbiegevorgangs und der Auslosezeitpunkt inAbhangigkeit der Kritikalitat berechnet werden.
Fur den zu erzielenden resultierenden Abstand gilt wieder Gleichung (4.44).Der vom Hindernis in Fahrtrichtung des Testfahrzeugs zuruckgelegte Weg
52
4.5 Einbiegen eines Hindernisfahrzeugs
kann aus der Projektion des Einbiegesplines auf den Zielspline berechnetwerden. Mit dem nach Gleichung (4.3) zu berechnenden Weg des Testfahr-zeugs wahrend der Annaherung an das Hindernis ergibt sich dann fur denSollabstand im Moment der Detektion
∆D0 = Dres −∆DObs,Verz −∆DVUT,Verz . (4.46)
Aus dem Erkennungsabstand ∆D0 kann dann die Sollposition des Hin-dernisfahrzeugs auf dem Einbiegespline und damit der Startzeitpunkt desEinbiegevorgangs berechnet werden.
Einbiegesituationen sind derzeit nicht implementiert, da der aktuelle Standdes Straßenmodells keine Kreuzungen erlaubt.
53
4 Erzeugung kritischer Verkehrssituationen
54
5 Simulationsmodule
5.1 Ubersicht
Wie in Kapitel 2 beschrieben, ist die Gesamtsimulation aus mehreren ein-zelnen Modulen aufgebaut, die jeweils die Berechnung von Teilaspektenubernehmen und ihre Ergebnisse anderen Modulen uber eine zentrale Da-tenbasis zur Verfugung stellen.
Der Situationsgenerator ist so konzipiert, dass alle Hindernisfahrzeuge uber-wacht und gesteuert werden konnen. Dazu verfugt der Situationsgenera-tor, der als eigenes Modul innerhalb der Simulation ausgefuhrt wird, uberSchnittstellen, die die Zustandsvariablen jedes Hindernisfahrzeugs sowiedes Testfahrzeugs ubermitteln. Die Modelle der Hindernisfahrzeuge stellenwiederum Schnittstellen zur Verfugung, die die Vorgaben des Situations-generators entgegennehmen. Die Kommunikation zwischen den Modulenwird vollstandig uber die zentrale Datenbasis des Echtzeitrechners bzw.der Softwaresimulationsumgebung (PRAETORIA) abgewickelt.
Die Abbildung 5.1 zeigt die mindestens erforderlichen Module zur Simu-lation von Verkehrssituationen. Das Modul
”Sensoren“ simuliert die am
Testfahrzeug angebrachte Sensorik (vgl. dazu [Tellmann, 2010]). Im Mo-dul
”Verkehr“ sind die Modelle der Fahrzeuge enthalten, die den zur Er-
zeugung von kritischen Situationen notigen Verkehr bilden, wahrend dieDynamik des Testfahrzeugs im Modul
”VUT“ berechnet wird. Das Mo-
dul”Situationsgenerator“ berechnet die Funktionen des Situationsgenera-
tors. Zur Vollstandigkeit ist das auf dem DECOS Cluster implementierteAssistenzsystem mit dargestellt, auch wenn es kein Simulationsmodul imeigentlichen Sinne darstellt.
55
5 Simulationsmodule
FAS auf DECOS Cluster
CANDB
HiL/PRAETORIA
SensorenVUT Verkehr Situations-generator
Abbildung 5.1: Simulationsmodule in der HiL bzw. SiL Umgebung
5.2 Modul Verkehr
Das Modul Verkehr enthalt die Modelle des Testfahrzeugs und der Hinder-nisfahrzeuge sowie die den Fahrzeugen zugeordneten Fahrermodelle. Allediese Elemente konnten zwar auch in jeweils eigenen Modulen simuliertwerden, allerdings steigt mit der Zahl der Module auch die Menge der mitHilfe der Datenbank zu ubertragenden Daten drastisch an, da fur jede Fah-rer/Fahrzeug Kombination die Werte durch die Datenbasis gefuhrt werdenmussten. Fur die hier beschriebene Anwendung, die Erzeugung von Ver-kehrssituationen, ist die Trennung nicht erforderlich, die Simulation allerFahrzeuge mit den jeweiligen Fahrermodellen wird daher in einem Modulzusammengefasst.
Zur Simulation der Langsdynamik des Testfahrzeugs und der Hindernis-fahrzeuge wird ein einfaches Modell mit der in Abbildung 5.2 dargestelltenStruktur verwendet, das zusammen mit dem Modell des Assistenzsystemsim Rahmen des Projekts DECOS zur Verfugung gestellt wurde. Das Modelldas Assistenzsystems ist fur dieses Dynamikmodell parametriert.
Die mit MAnf bezeichnete Schnittstelle ubertragt die Momentanforderungdes Assistenzsystems bzw. des Fahrers zum Motor, die Schnittstelle VerzAnf
ubermittelt die Verzogerungsanforderung. Als Ausgangsgroßen liefert dasModell die Geschwindigkeit v und die Beschleunigung a.
56
5.3 Modul Situationsgenerator
Motor Getriebe Trieb-strang
MAnf
MMotor
MGetriebe
FAntrieb v
Fahr-wider-stände
FW
m
1
aVerzAnf
FRes
Brems-system
Verz
Abbildung 5.2: Blockschaltbild der Fahrdynamik
Zur Nachbildung der Querdynamik dient ein Einspurmodell, das die Bewe-gung des Fahrzeugs zunachst in kartesischen Koordinaten berechnet. Diekartesischen Koordinaten werden dann in Straßenkoordinaten uberfuhrt(vgl. Abschnitt 3.2 und [Schmidt, 2010]) und fur die Situationserzeugunggenutzt.
5.2.1 Schnittstellen
Fur das Testfahrzeug werden Ein- und Ausgabeschnittstellen zum ange-schlossenen Assistenzsystem, zu den Sensoren, zum Situationsgeneratorsowie zur Visualisierung benotigt. Eine Ubersicht uber die Schnittstellenzu den Assistenzsystemen bietet Tabelle A.3. Allerdings sind dort auch dieSchnittstellen zwischen Sensoren und Assistenzsystemen enthalten (Wertemit ’Ziel-’ in den Botschaften 257, 259 und 260). Die Hindernisfahrzeu-ge sind mit Ein-/Ausgabeschnittstellen zum Situationsgenerator und zurVisualisierung ausgestattet.
5.3 Modul Situationsgenerator
Das Modul”Situationsgenerator“ berechnet die zur Erzeugung kritischer
Situationen notwendigen Vorgaben fur Lenkung und Beschleunigung bzw.Verzogerung der Hindernisfahrzeuge. Dazu werden die Zustande aller Fahr-zeuge von einem globalen Beobachter verfolgt und die Situationen entspre-chend der Konfigurationseintrage der einzelnen Hindernisse erzeugt. DerSituationsgenerator sucht in jedem Zeitschritt nach dem Hindernis, das
57
5 Simulationsmodule
VUT
Obs1
Obs2
Situations-generator
Sensoren SUT
Vorgaben
DB
Zustandsgrößen VUT
Zustandsgrößen Obs 1...nZustandsgrößen
VUT, Obs 1...n
Abbildung 5.3: Blockschaltbild der Interaktion des Situationsgeneratorsmit der Umgebung
am besten dazu geeignet ist, eine der anstehenden Situationen zu erzeu-gen. Wird ein Fahrzeug zur Situationserzeugung ausgewahlt, so wird diesesFahrzeug aktiv, die anderen bleiben zunachst passiv.
Abbildung 5.3 zeigt schematisch die Interaktion des Situationsgeneratorsmit den beteiligten Fahrzeugen. Die in orange eingetragenen Schnittstellensind lediglich der Ubersichtlichkeit wegen als direkte Verbindung zwischenzwei Blocken dargestellt, die damit ubertragenen Variablen werden vomSender in die Datenbasis geschrieben und vom Empfanger aus der Daten-basis gelesen.
Je nach aktuell zu erzeugender Situation konnen evtl. mehrere Fahrzeugeaktiv sein, z. B. zur Erzeugung eines Staus. Bei anderen Situationstypendarf nur ein einzelnes Hindernis aktiv sein, die anderen mussen dann passivbleiben.
58
5.3 Modul Situationsgenerator
Der Situationsgenerator stutzt sich auf die Straßenkoordinaten, da sichdamit die Verhaltnisse der Fahrzeuge zueinander ohne zeitaufwandige Ko-ordinatentransformationen beschreiben lassen.
5.3.1 Schnittstellen
Die Schnittstellen des Situationsgenerators sind in Abbildung 5.3 darge-stellt.
Die mit”Zustandsgroßen“ bezeichnete Schnittstelle transportiert die Zu-
standsvariablen des Testfahrzeugs und der Hindernisfahrzeuge, das sind dieWeltkoordinaten x, y, z, die Straßenkoordinaten D,O,L, die Geschwindig-keit ~v und die aktuelle Beschleunigung a.
Die Schnittstelle”Vorgaben“ ubermittelt die Vorgaben des Situationsge-
nerators bzgl. der Langs- und Querfuhrung an das betroffene Hindernis.
In der Datenbasis werden die beschriebenen Schnittstellen auf Variablenabgebildet, die die zu ubertragenden Werte speichern. Eine Ubersicht zeigtTabelle 5.1.
Eine in Abbildung 5.3 nicht dargestellte Schnittstelle stellt dem Situations-generator die relevanten Parameter aus der Umwelt und jene zur genauerenBeschreibung des Assistenzsystems zur Verfugung. Hier werden unter an-derem die in der Simulationsumgebung konfigurierten Daten ubertragen.Dazu gehort neben der Straße und den konfigurierten Sensoren auch dieListe der von den Hindernisfahrzeugen zu erzeugenden Situationen. Die-se Schnittstelle unterscheidet sich insofern von den oben beschriebenen,als die Daten hier nur einmalig zum Simulationsstart aus Dateien gelesenund nicht in jedem Simulationszyklus mit der Datenbasis synchronisiertwerden.
5.3.2 Konfiguration
Fur jedes Hindernis wird eine Liste mit zu erzeugenden Situationen konfi-guriert; diese Liste ist Teil der Konfiguration jedes Hindernisses und in derSimulationsumgebung gespeichert. Hindernisse konnen grundsatzlich mitbeliebig vielen Situationen konfiguriert werden. Die in der Konfigurationfestgelegten Szenarien werden in einer Liste der erzeugenden Situationen
59
5 Simulationsmodule
Tabelle 5.1: Datenbasisvariablen des Situationsgenerators
Prafix Variable Bedeutung
VUT X Weltkoordinate xY Weltkoordinate yZ Weltkoordinate zROTZ Rotation um die HochachseROTY Rotation um die QuerachseROTX Rotation um die LangsachseD Straßenkoordinate DO Straßenkoordinate OL Straßenkoordinate LVX Geschwindigkeit X-KomponenteVY Geschwindigkeit Y-KomponenteVZ Geschwindigkeit Z-KomponenteA Beschleunigung
OBS n X Weltkoordinate xY Weltkoordinate yZ Weltkoordinate zROTZ Rotation um die HochachseROTY Rotation um die QuerachseROTX Rotation um die LangsachseD Straßenkoordinate DO Straßenkoordinate OL Straßenkoordinate LVX Geschwindigkeit X-KomponenteVY Geschwindigkeit Y-KomponenteVZ Geschwindigkeit Z-KomponenteA BeschleunigungSG DELTA Lenkwinkelvorgabe des SituationsgeneratorsSG FORCE Antriebskraftvorgabe des SituationsgeneratorsSG UMODE Umschalten zw. Fahrer und Situationsgenerator
60
5.3 Modul Situationsgenerator
Tabelle 5.2: Konfigurierbare Situationen
Situation Konfigurations-eintrag
Beschreibung
Spurwechsel Lanechange Hindernis wechselt auf die Fahrspur desTestfahrzeugs
Bremsen Brake Hindernis bremst vor dem Testfahrzeugauf definierte Geschwindigkeit
Vollbremsung Brake Hindernis bremst bis zum Stillstand
Bremsen undWiederanfah-ren
BrakeRestart Hindernis bremst vor dem Testfahr-zeug auf definierte Geschwindigkeitund fahrt wieder an
Stop-and-Go StopGo Wiederholtes Abbremsen bis zum Still-stand und Wiederanfahren
Stau Jam Mehrere Fahrzeuge bilden einen Stauuber die ganze Fahrbahnbreite
Spurhalten FLane Hindernis folgt einer Fahrspur, Fah-rermodell ubernimmt Langs- undQuerfuhrung
Uberholen,Einscheren undAusbremsen
Overtake Hindernisfahrzeug uberholt, schert vordem Testfahrzeug ein und bremst
fur jedes Hindernis separat verwaltet. Damit ist es moglich, viele Fahrzeugeals Verkehr an der Simulation zu beteiligen und nur ausgewahlte Hinder-nisfahrzeuge in die Erzeugung kritischer Situationen einzubeziehen.
Tabelle 5.2 enthalt zu jeder konfigurierbaren Situation eine knappe Be-schreibung sowie den im Konfigurationsdialog zu verwendenden Eintrag.
5.3.3 Zustandsautomat
Der Situationsgenerator ist als Zustandsautomat realisiert, der separat furjedes beteiligte Hindernisfahrzeug durchlaufen wird. Abbildung 5.4 zeigt
61
5 Simulationsmodule
einen Uberblick uber den Zustandsautomaten.
<company> diagram_Statemachine_1/Statemachine Thu Nov 15 17:13:50 2007 1
Wait
Prepare
Generate_Situation
Critical_Preparation
Normal
Check_Preparation
Initial
<SG>
1true
1
isCritical = true
2
isCritical = false
1
prepared = true
1
criticalPrepFinished = true
2
prepared = false
1
prepared = true
2
waitRequired = true
1
(situationGenerated = true) and (isCritical = true)
1waitRequired = false
2(situationGenerated = true) and (isCritical = false)
Abbildung 5.4: Zustandsautomat des Situationsgenerators
Der Startzustand der Hindernisfahrzeuge bei Simulationsbeginn heißt Nor-mal. In diesem Zustand wird das Fahrzeug von einem Fahrermodell ge-steuert durch den Verkehr bewegt, ohne kritische Situationen zu provozie-ren. Enthalt die Situationsliste des Fahrzeugs mindestens einen Eintrag,wechselt der Zustandsautomat in einen vorbereitenden Zustand (CheckPreparation). In diesem Zustand wird gepruft, ob die Voraussetzungenzum Erzeugen der geplanten Situation vorliegen.
Zunachst wird uberpruft, ob die grundsatzlichen Voraussetzungen gegebensind, d.h. ob sich das Hindernis auf der richtigen Fahrspur befindet, um diegewunschte Situation zu erzeugen und bei welcher Bogenlange es sich imBezug zum Testfahrzeug auf der Straße befindet. Sind alle Voraussetzun-gen erfullt, wechselt der Zustandsautomat in den Zustand, der die kritische
62
5.3 Modul Situationsgenerator
Situation vorbereitet (Critical Preparation). Wenn die Startbedingun-gen erfullt sind, wird aus diesem Zustand die kritische Situation ausgelost.Wenn die Startvoraussetzungen nicht gegeben sind und auch nicht durcheinfache Manover, wie z. B. einen Spurwechsel, geschaffen werden konnen1,wird der Zustand Wait aktiv, der das Hindernis unter der Kontrolle desFahrermodells lasst und bei passender Gelegenheit wieder in den ZustandCheck Preparation wechselt.
Sind die im Zustand Check Preparation uberpruften Voraussetzungennicht gegeben, wird zunachst versucht, diese Voraussetzungen im ZustandPrepare herzustellen. Nach einem erneuten Wechsel in den Zustand Check
Preparation kann die Situation dann, wie oben beschrieben, ausgelostwerden.
Zustande und Zustandswechsel
Der Zustand Normal wird von jedem Hindernis als Startzustand angenom-men. Ist in der Situationsliste eines Hindernisses mindestens eine Situationgespeichert, deren Soll-Kritikalitat KSoll > 0 ist, wechselt der Zustand zuCheck Preparation. Ist keine Situation in der Liste gespeichert, verweiltdas Fahrzeug im Zustand Normal. In diesem Zustand wird das Fahrzeugvon einem Fahrermodell durch den Verkehr bewegt, ohne den Versuch zuunternehmen, kritische Situationen zu erzeugen. Die Geschwindigkeit, diedas Fahrermodell in diesem Zustand halt, ist in der Konfiguration vorge-geben.
Im Zustand Check Preparation werden die situationsabhangigen Rand-bedingungen gepruft, die erfullt sein mussen, um eine geforderte Situationausfuhren zu konnen. Voraussetzung fur einen Einschervorgang ist bei-spielsweise, dass das Hindernisfahrzeug sich nicht bereits auf der gleichenFahrspur befindet wie das Testfahrzeug. Daruber hinaus darf mit Ausnah-me von Situationen, die mehrere Fahrzeuge erfordern, nur ein Hindernisaktiv eine Situation auslosen.
Sind alle Bedingungen erfullt, kann die kritische Situation im ZustandCritical Preparation vorbereitet werden. Dazu werden die Ergebnisse
1Eine solche Situation kann beispielsweise dann auftreten, wenn das Hindernis einSpurwechselmanover ausfuhren soll, das Testfahrzeug sich aber vor dem Hindernisauf der Straße befindet
63
5 Simulationsmodule
der in jedem Zeitschritt ausgewerteten Gleichungen (4.1), (4.2) und (4.3)bewertet und daraus fur die zu erzeugende Situation Startzeitpunkt und-bogenlange sowie evtl. die benotigte Verzogerung berechnet.
Liegen die berechneten Werte in einem ungultigen Bereich, wird die Vor-bereitung abgebrochen und zunachst in den Zustand Wait umgeschaltet.Dies tritt z. B. dann auf, wenn ein Bremsmanover durchgefuhrt werdensoll, die vom Hindernisfahrzeug aufzubringende Verzogerung aber außer-halb des gultigen Bereiches liegt oder wenn bei einem Spurwechselmanoverdie Auslosebogenlange bereits passiert wurde. Auch wenn das Hindernis-fahrzeug sich hinter dem Testfahrzeug auf der Straße befindet, wird dieVorbereitung abgebrochen und in den Zustand Wait gewechselt. Das Hin-dernis versucht also nicht, das Testfahrzeug zu uberholen, sondern wartet,bis es vom Testfahrzeug uberrundet wurde. Dies gilt mit Ausnahme derSituation
”Uberholen, Einscheren und Bremsen“ (vgl. Tabelle 5.2) fur alle
Situationen.
Sind die wahrend der Vorbereitung berechneten Werte jedoch gultig undsind die Kriterien erfullt (z. B. Startbogenlange erreicht), schaltet der Zu-standsautomat in den Zustand Generate Situation um. Durch den Wech-sel in den Zustand Generate Situation wird dieses Hindernisfahrzeug ak-tiv, alle anderen Zustande lassen das Fahrzeug passiv. Das Umschalten inden aktiven Zustand wird auch bei sonst erfullten Bedingungen nur dannausgefuhrt, wenn die Aktivierung nicht durch ein anderes, bereits aktivesHindernis blockiert wird. Dieser Zustand fuhrt die gewunschte Situationaus und wird nach dem Ende des Manovers wieder verlassen. Falls dieSituationsliste eine weitere zu erzeugende Situation enthalt, wechselt derZustandsautomat in den Zustand Check Preparation, andernfalls in denZustand Normal.
5.4 Modul CAN
Speziell fur den Betrieb ohne Echtzeitrechner wurde ein Modul zur CAN-Kommunikation mit der in DECOS verwendeten Hardware entwickelt, dases erlaubt, die Simulationsmodule auf dem PC unter Verwendung der aufder Zielhardware implementierten Testsysteme zu untersuchen. Bei der
64
5.4 Modul CAN
DBSituationsgeneratorSensoren
VerkehrCANModul
PRAETORIA
PC
XLDriverLibraryDLL
CANCardXL
CAN
Knoten 1 Knoten 2 Knoten 3 Knoten 4Stau-assistent
AdaptiveLicht- steuerung
Spurhalte-assistent
FlexRay
Knoten 5Tür- steuerung
DECOS Cluster
L-FX DECOS Node
FlexRay-CAN- Gateway
L-FX DECOS Node
L-FX DECOS Node
L-FX DECOS Node
L-FX DECOS Node
Abbildung 5.5: Anbindung von PRAETORIA an das Testsystem via CAN
Nutzung dieses Moduls muss immer berucksichtigt werden, dass die Simu-lation auf dem PC nicht die Echtzeitbedingungen des CARTS-Simulatorserfullen kann.
Das Modul ubertragt dabei die im HiL-Betrieb vom Echtzeitrechner gesen-deten Nachrichten direkt vom PC zum DECOS-Cluster und empfangt dievon den Testsystemen gesendeten Nachrichten (vgl. Abbildung 5.5). Diezu ubertragenden Werte werden aus der Datenbasis von PRAETORIAgelesen, die empfangenen Daten werden wieder in die Datenbasis geschrie-ben, um den Modulen
”Verkehr“,
”Sensoren“ und
”Situationsgenerator“
als Eingabedaten zu dienen.
Implementiert wurde das CAN-Modul zur Verwendung einer CANCard Xbzw. CANCard XL von Vector Informatik2 mit der XL Driver Library[Vector Informatik, 2006] des gleichen Herstellers. Das Verhalten und dieKommunikation des Moduls sind im Programmquelltext fest vorgegeben.Nachrichten und Inhalte sind fur die Kommunikation des Testfahrzeugsmit den Applikationen
”Stauassistent“,
”Spurhalteassistent“ und
”Adapti-
ve Lichtsteuerung“ implementiert.
Das Modul ist im aktuellen Stand nicht konfigurierbar, die Kommunikati-on ist fest fur den beschriebenen Anwendungsfall implementiert. Die kom-plette Liste der gesendeten und empfangenen Botschaften ist im Anhangin Tabelle A.3 aufgefuhrt.
2http://www.vector-informatik.de/
65
5 Simulationsmodule
DBSituationsgeneratorSensoren
VerkehrFlexRayModul
PRAETORIA
CAPLDLL
CAPL Code
CANalyzer
VN3600
sharedmemory
PC
USBKnoten 1 Knoten 2 Knoten 3 Knoten 4Stau-assistent
AdaptiveLicht- steuerung
Spurhalte-assistent
FlexRay
Knoten 5Tür- steuerung
DECOS Cluster
CAN
L-FX DECOS Node
FlexRay-CAN- Gateway
L-FX DECOS Node
L-FX DECOS Node
L-FX DECOS Node
L-FX DECOS Node
Abbildung 5.6: Anbindung von PRAETORIA an das Testsystem viaCAPL und FlexRay
5.5 Modul FlexRay
Dieses Modul realisiert die Kommunikation zwischen der Umweltsimulati-on in PRAETORIA und der Implementierung der DECOS-Applikationen,die beim Projektpartner Audi realisiert wurde (vgl. dazu [Frunzke, 2007]).Dabei kommunizieren die einzelnen Applikationen, die auf der DECOS-Hardware ausgefuhrt werden, via FlexRay mit einem VN3600 FlexRay-Knoten. Dieser Knoten ist uber USB an den PC angebunden und wird voneinem CAPL3-Programm angesteuert, das in CANalyzer4 ausgefuhrt wird.Abbildung 5.6 zeigt eine Ubersicht des Versuchsaufbaus, Abbildung A.2zeigt ein Foto des Versuchsaufbaus beim Projektpartner AEV.
Die Kommunikation der Daten zwischen der Umweltsimulation in PRAE-TORIA und dem CAPL-Programm im CANalyzer wird uber eine DLL ab-gewickelt, die einen gemeinsam verwendeten Speicherbereich zur Verfugung
3Communication Access Programming Language4CANalyzer ist ein Analyseprogramm fur Bussysteme der Vector Informatik GmbH.
66
5.5 Modul FlexRay
stellt. Das Modul CAPLcom fur PRAETORIA liest in jedem Simulations-zeitschritt die erforderlichen Werte aus der Datenbasis aus und schreibtsie in diesen Speicherbereich. Von dort werden die Daten vom CAPL-Programm ausgelesen. Nachdem die auf dem DECOS-Cluster ausgefuhrtenApplikationen ihre Ergebnisse via FlexRay ubermittelt haben, schreibt dasCAPL-Programm diese Daten wieder in den gemeinsam verwendeten Spei-cher, so dass die Werte von Modul CAPLcom gelesen und in die Datenbasisubernommen werden konnen. Dort stehen sie dann den anderen Simulati-onsmodulen wieder zur Verfugung.
Das Modul realisiert die Kommunikation fur die Applikationen”Stauas-
sistent“,”Spurhalteassistent“ und
”Adaptive Lichtsteuerung“. Die uber-
tragenen Werte und ihre Zuordnung zu den Parametern in der Datenbasisvon PRAETORIA sind fest implementiert, eine Konfiguration ist nichtmoglich.
Die Module”CAN“ und
”FlexRay“ hatten idealerweise gleichartig im-
plementiert werden sollen. Aufgrund der Einschrankungen der verwende-ten Treiberbibliothek bezuglich der Konfiguration des FlexRay-Knotensmussten zwei unterschiedliche Losungsansatze gewahlt und die Module un-abhangig voneinander implementiert werden.
67
5 Simulationsmodule
68
6 Anwendung und Validierung
6.1 Anwendung
Die aufgebaute Entwicklungsplattform fur Fahrerassistenzsysteme wurdezusammen mit den in DECOS entwickelten und implementierten Appli-kationen als Demonstrator des Teilprojekts 5 in Betrieb genommen undvalidiert.
Anforderungsanalyse&
Systemspezifikation
Systemarchitektur
Softwarearchitektur
Komponenten-spezifikation Komponenten-Test
SoftwareIntegrationstest
Integrationstest
System-Test
MiL
SiL
HiL
CARTS HiL
Verkehr
SensorenSituations-generator
Implementierung
SiL
Abbildung 6.1: Anwendung der Simulationsumgebung im Entwicklungs-prozess (nach [Theuerkauf, 2005] und [Schauffele u. Zuraw-ka, 2006])
69
6 Anwendung und Validierung
Die Simulationsmodule wurden so entwickelt, dass ein Betrieb der Mo-dule auf dem PC und auf dem CARTS Echtzeitrechner moglich ist. Dazuwird der gleiche Programmquelltext einmal fur den Betrieb unter MS Win-dows und einmal fur den Betrieb unter Microware OS-9 ubersetzt. DieseArt der Entwicklung erlaubt einerseits einfaches Testen der Module auf ei-nem Windows PC und andererseits die Anwendung in Model-in-the-Loop-und Software-in-the-Loop-Tests sowie die Ausfuhrung in Echtzeit auf derCARTS Plattform fur die Anwendung in Hardware-in-the-Loop-Tests. Da-mit konnen alle Phasen des Entwicklungsprozesses durch die entstandeneSimulationsumgebung unterstutzt werden (vgl. Abbildung 6.1). Dies er-laubt es, einmal spezifizierte und in der Simulationsumgebung konfigurierteTestfalle durchgangig zu verwenden und die Ergebnisse aus den verschie-denen Entwicklungsphasen miteinander zu vergleichen.
6.1.1 Test eines Assistenzsystems
Fur den Test eines Assistenzsystems, wie z. B. des Stauassistenten, istzunachst die Simulationsumgebung zu konfigurieren. Dazu wird mit Hil-fe von PRAETORIA entweder eine vorhandene Konfiguration bearbeitetoder eine neue Konfiguration angelegt. Einige der zu konfigurierenden Ele-mente enthalten konkrete Werte, die z. B. die Startposition auf der Straßebeschreiben. Andere verweisen auf Dateien, die komplexe Informationenzusammenfassen. Dazu gehoren unter anderem der Kafig1, das Fahrermo-dell und die Sensorkonfiguration. Die Elemente, die durch Verweise aufDateien beschrieben werden, sind in der Ubersicht durch D gekennzeich-net. Konfiguriert werden mussen folgende Elemente:
� Straße
– der geometrische VerlaufD
– das VisualisierungsmodellD
� Testfahrzeug
– das VisualisierungsmodellD
1Der Kafig ist das vereinfachte Geometriemodell der Fahrzeuge, das auf dem Echt-zeitrechner von den Sensormodellen abgetastet wird. Vgl. dazu [Schmidt, 2004] und[Tellmann, 2010]
70
6.1 Anwendung
– der KafigD
– die Startposition
– die SensorikD
– das FahrermodellD
– zusatzliche ParameterD
– die Wunschgeschwindigkeit
– das Variablen-Prafix
� Ein oder mehrere Hindernisfahrzeuge
– das VisualisierungsmodellD
– der KafigD
– die Startposition
– das FahrermodellD
– die Wunschgeschwindigkeit
– die Liste der kritischen Situationen
– das Variablen-Prafix.
Die Abbildung 6.2 zeigt die zu konfigurierenden Elemente sowie das Fens-ter, mit dem die Eigenschaften des Testfahrzeugs verwaltet werden konnen,in Abbildung 6.3 ist der Konfigurationsdialog fur ein Hindernisfahrzeugdargestellt. Der rote Rahmen enthalt die Liste der zu erzeugenden Situa-tionen, im Feld
”Typ“ konnen die in Tabelle 5.2 angegebenen Situationen
eingetragen werden.
Nachdem die Simulationsumgebung vollstandig konfiguriert wurde, kanndie aktuelle Konfiguration gespeichert werden. Das Ergebnis ist eine Dateiim XML Format, die neben Verweisen auf weitere XML Dateien die Datender gerade konfigurierten Simulationsumgebung enthalt. Ein Beispiel fureine vollstandige Konfigurationsdatei ist in Abschnitt A.11 zu finden. Eineeinmal angelegte und gespeicherte Konfiguration kann fur MiL-, SiL- undHiL-Betrieb gleichermaßen verwendet werden. Im MiL- und SiL-Betriebwird die Konfiguration schlicht in PRAETORIA geladen und steht da-mit den ebenfalls in PRAETORIA ausgefuhrten Simulationsmodulen zur
71
6 Anwendung und Validierung
Abbildung 6.2: Konfiguration der Simulationsumgebung in PRAETORIA
72
6.1 Anwendung
Abbildung 6.3: Konfiguration der Hindernisfahrzeuge in PRAETORIA
Verfugung. Zur Verwendung fur den HiL-Betrieb kann die geladene Kon-figuration auf den Echtzeitrechner ubertragen werden. Dabei werden allenotwendigen Dateien auf der Festplatte eines Rechenknotens (ESU) oderim Speicher des VME-Rechners abgelegt, wo sie dann den Simulationsmo-dulen zur Verfugung stehen.
Model-in-the-Loop- und Software-in-the-Loop-Betrieb
In diesen Betriebsarten von PRAETORIA werden alle Simulationsmoduleund zu testenden Systeme auf dem PC ausgefuhrt. Einerseits konnen dieTestsysteme dabei in Form von Modellen in Matlab/Simulink ausgefuhrtwerden, wobei dann die Kommunikation uber die in PRAETORIA inte-grierte MPI-Schnittstelle abgewickelt wird (vgl. [Grabel, 2007]). Bereits
73
6 Anwendung und Validierung
wahrend der Spezifikation eines Systems kann so mit Model-in-the-Loop-Tests die grundsatzliche Funktion validiert werden. Durch die Kommu-nikation uber MPI ist auch die Verteilung der Simulation uber mehrereRechner in einem Netzwerk moglich.
Eine zweite Moglichkeit ist die Uberfuhrung der Modelle der Testsystemein Programmbibliotheken2, die dann ebenfalls in PRAETORIA ausgefuhrtwerden. Dazu wird entweder aus einem Modell mit Hilfe der in Matlab/Simulink integrierten Funktionen Quelltext erzeugt oder die im Modelloder anderweitig spezifizierte Funktionalitat wird manuell implementiert.Die erzeugten Funktionen werden in eine fur den Einsatz in PRAETORIAvorbereitete Programmhulle3 eingefugt und dann vom Zustandsautoma-ten in PRAETORIA aufgerufen. Im Verlauf der Entwicklung konnen al-so mit Software-in-the-Loop-Methoden einzelne Software-Module oder dievollstandige Systemsoftware bezuglich ihrer Funktion und ihres Verhaltensgetestet werden. Die Kommunikation mit den anderen Modulen verlauftvollstandig durch die Datenbasis. Alle Module werden dabei auch mit dergleichen Zykluszeit aufgerufen. Die Simulation lauft dann zwar nicht inEchtzeit, das hat jedoch keine Auswirkungen auf die Simulationsergebnis-se, da als Parameter nicht die tatsachlich vergangene Zeit seit dem letztenAufruf ubergeben wird, sondern der als Zykluszeit in PRAETORIA einge-stellte Wert.
Abbildung 6.4 zeigt PRAETORIA im SiL-Betrieb mit vier geladenen Simu-lationsmodulen. Im linken Teil der Abbildung sind in den farblich hervor-gehobenen Bereichen ein Ausschnitt aus der Datenbank (rot), die Simu-lationsmodule Verkehr, Sensoren, Situationsgenerator und Stauassistent(grun) und die eingestellte Zykluszeit (blau) zu sehen. Der mittlere Teilzeigt die dreidimensionale Visualisierung und der rechte ein zusatzlichesFenster, das die aktuellen Werte von Datenbasisvariablen anzeigt. Erkenn-bar ist, dass das Assistenzsystem eine Verzogerung von 2,643 m/s2 anfor-dert (ACC VERZ ANF), wahrend sich das Testfahrzeug dem Hindernis-fahrzeug mit 2,189 m/s nahert (ACC ZVDIFF).
2DLL - Dynamic Link Library3Engl. wrapper
74
6.1 Anwendung
Abbildung 6.4: PRAETORIA im SiL Betrieb
Hardware-in-the-Loop-Betrieb
Im HiL-Betrieb sind die Module Verkehr, Situationsgenerator und Sensorenauf dem CARTS Hardware-in-the-Loop-Simulator (vgl. Abbildung 2.4) im-plementiert. Auf dem Bedien-PC werden wahrend der Echtzeitsimulationnur die Visualisierung sowie die Versuchsbedienungssoftware fur den Echt-zeitrechner ausgefuhrt. Ein an diesen PC angeschlossenes Lenkrad kanndazu verwendet werden, das Testfahrzeug manuell durch die simulierteUmgebung zu steuern. Auf dem DECOS-Cluster sind die im Rahmen desProjekts fur die Demonstratoren ausgewahlten Applikationen implemen-tiert. Der Versuchsaufbau fur den Echtzeit HiL-Betrieb ist in Abbildung 6.5dargestellt, ein Foto des Aufbaus ist in Abbildung A.5 im Abschnitt A.10zu sehen.
75
6 Anwendung und Validierung
Knoten 1 Knoten 2 Knoten 3 Knoten 4Stau-assistent
AdaptiveLicht- steuerung
Spurhalte-assistent
FlexRay
Knoten 5Tür- steuerung
DECOS Cluster
L-FX DECOS Node
FlexRay-CAN- Gateway
L-FX DECOS Node
L-FX DECOS Node
L-FX DECOS Node
L-FX DECOS Node
CARTS HiL
Verkehr
Sensoren
Situations-generator
CAN 2ALSECU
CAN 1
Verkehr
VUT
Abbildung 6.5: Versuchsaufbau des HiL Demonstrators
Die auf dem Echtzeitrechner ausgefuhrten Simulationsmodule kommuni-zieren mit den Applikationen auf dem DECOS-Cluster uber einen mit500 kBit/s betriebenen Highspeed-CAN-Bus (CAN 1). Dazu ist auf demKnoten 1 des Clusters ein FlexRay-CAN-Gateway implementiert, das zwi-schen den beiden beteiligten Bussen vermittelt (siehe auch Abschnitt 6.1.2).An diesen Bus ist neben dem Echtzeitrechner und dem DECOS-Clusterauch noch ein Prototypensteuergerat angeschlossen, das einen Teil derFunktionalitat der
”Adaptiven Lichtsteuerung“ berechnet. Dieses Steuer-
gerat kommuniziert uber einen weiteren CAN-Bus (CAN 2, 500 kBit/s)mit dem angeschlossenen Scheinwerfer.
Zusatzlich ist CAN 2 auch an den Echtzeitrechner angeschlossen, so dassder berechnete und dem Scheinwerfer ubergebene Schwenkwinkel auch furdie Visualisierung genutzt und entsprechend dargestellt werden kann.
6.1.2 Implementierung der DECOS Applikationen
Die von den Projektpartnern zur Verfugung gestellten Applikationen wur-den entsprechend der DECOS-Methoden mit Hilfe der DECOS-Werkzeug-kette auf der Zielplattform implementiert. Dazu wurde fur jede Applikation
76
6.1 Anwendung
ein plattformunabhangiges Modell (platform independent model, PIM) ent-wickelt, das zusammen mit der ursprunglich in Form von Simulink- bzw.Stateflow-Modellen vorliegenden Verhaltensbeschreibung in ein SCADE4
Modell importiert wurde. Fur den Entwurf der plattformunabhangigen Mo-delle wurde der im Rahmen von DECOS an der Universitat Budapest ent-wickelte domanenspezifische Editor (PIM-DSE) genutzt. Das Programmist als Erweiterung (Plug-In) fur die Entwicklungsumgebung Eclipse rea-lisiert. Abbildung 6.6 zeigt ein Bildschirmfoto des Editors wahrend derBearbeitung des ALS5 Modells.
Abbildung 6.6: Domanenspezifischer Editor fur plattformunabhangigeModelle
Nach dem Import des plattformunabhangigen Modells steht in SCADE
4SCADE Suite enthalt neben der Modellierungsumgebung auch einen zertifiziertenCode-Generator zur Erzeugung von C Quelltext.
5Adaptive Lichtsteuerung
77
6 Anwendung und Validierung
zunachst ein Gerust mit bereits spezifizierten Schnittstellen zur Verfugung,das mit einer Modellierung des Verhaltens gefullt werden muss. Diese In-halte konnen entweder direkt in SCADE modelliert werden, oder wie imFalle der DECOS-Applikationen, durch den Import von Simulink- bzw.Stateflow-Modellen generiert werden. Aus diesen Modellen wird dann derfunktionale Code zur Ausfuhrung auf der DECOS-Hardware generiert.
Zur Definition des Gesamtsystems wurde aus den plattformunabhangigenEinzelmodellen aller Applikationen zusammen mit einer Beschreibung derHardwareplattform ein plattformspezifisches Modell (platform specific mo-del, PSM) des Gesamtsystems gebildet, das Informationen uber die raum-liche6 und zeitliche Verteilung der Einzelapplikationen sowie uber die Kor-respondenz der von den einzelnen Applikationen gesendeten bzw. zu emp-fangenden Nachrichten enthalt. Aus den damit bekannten Zuordnungen derzu kommunizierenden Nachrichten wurde mit Hilfe der Werkzeuge TTX-Plan und TTX-Build ein Kommunikationsplan (vgl. Abbildung 6.7) furdas gesamte Netzwerk sowie ein Zeitplan fur die Ausfuhrung der einzelnenApplikationen fur jeden Knoten generiert. Aus dieser Beschreibung des Ge-samtsystems, dem Kommunikationsplan und dem mit SCADE generiertenCode wurde dann jeweils ein ausfuhrbares Programm fur einen Knotenerzeugt.
Eine ausfuhrlichere Beschreibung der DECOS-Methoden und -Werkzeugeist in [Ayeb u. a., 2007a] und [Ayeb u. a., 2007b] zu finden.
Das FlexRay-CAN-Gateway wurde ebenfalls mit Hilfe der DECOS-Werk-zeugkette entwickelt und implementiert. Dazu wurde zunachst die gesam-te Umweltsimulation als Einheit betrachtet und mit einem PIM beschrie-ben. Dieses Modell wurde im plattformspezifischen Modell des Gesamtsys-tems einem externen CAN-Knoten zugeordnet, der den Echtzeitrechner re-prasentiert. Aus der Kenntnis der korrespondierenden Nachrichten konntedann das Gerust des FlexRay-CAN-Gateways automatisch generiert wer-den. Die zur vollstandigen Implementierung des Gateways notwendigenFunktionen zur Umrechnung sowie zum Ein- und Auspacken der in unter-schiedlichen Formaten ubertragenen Daten wurden manuell programmiert.Diese Funktionen implementieren außerdem die Zuordnung zwischen ei-nem symbolischen Namen und dem entsprechenden CAN-Identifier sowiedie Anordnung der Daten in den CAN-Botschaften.
6Beschreibt die Verteilung von Applikationen uber mehrere Steuergerate. Englisch:spatial partioning
78
6.1 Anwendung
Abbildung 6.7: Kommunikationsplan fur das DECOS-Cluster
79
6 Anwendung und Validierung
6.2 Validierung
Dieses Kapitel beschreibt Ergebnisse von Messungen, die mit dem in Ab-schnitt 6.1.1 beschriebenen Versuchsaufbau durchgefuhrt wurden. Dazuwurden bereits im Rahmen der Arbeit am Deliverable7 D5.3.1 [Ayeb u.Schmidt, 2006] Untersuchungen zur Reproduzierbarkeit der erzeugten Si-tuationen und der erzielten Kritikalitat durchgefuhrt. Diese Messungenwerden durch aktuelle Messungen erganzt. Die Messergebnisse werden indiesem Kapitel vorgestellt und interpretiert.
6.2.1 Einschermanover
Dieser Abschnitt beschreibt die Auswertung der Messergebnisse von Ein-schermanovern, mit denen ein Stauassistent untersucht wurde. Die Situa-tion wurde mit folgenden Parametern konfiguriert:
� Startgeschwindigkeiten von Hindernis und TestfahrzeugvObs,0 = vVUT,0 = 0 m/s
� Testfahrzeug auf der mittleren Fahrspur (−2)
� Hindernis zunachst auf der rechten Fahrspur (−3)
� Wunschgeschwindigkeit des TestfahrzeugsvWunsch,VUT = 100 km/h ≈ 27,8 m/s
� Geschwindigkeit des Hindernisfahrzeugs vObs = 50 km/h ≈ 13,9 m/s
� Maximal mogliche Verzogerung des Assistenzsystems amax = 4 m/s2
Abbildung 6.8 zeigt ein Bildschirmfoto der 3D-Visualisierung. In der dar-gestellten Situation wurde ein Einschermanover des grunen Hindernisfahr-zeugs vor dem roten Testfahrzeug simuliert.
Die Abbildung 6.9 stellt die Geschwindigkeiten vVUT des Testfahrzeugsund vObs des Hindernisses, den vom Sensor gemessenen Abstand ∆D unddie vom Assistenzsystem angeforderte Verzogerung aVUT fur ein Einscher-manover mit der geplanten Kritikalitat K = 0,8 dar. Ebenfalls eingetragen
7Im Rahmen des Pojektes DECOS mussten in regelmaßigen Abstanden Ergebnissegeliefert werden, die meist in Form von Berichten abgegeben wurden. Diese Berichtewurden als ’Deliverable’ bezeichnet.
80
6.2 Validierung
Abbildung 6.8: Einschermanover mit Kritikalitat K = 0,8
81
6 Anwendung und Validierung
0 4.5 9 13.5 18 22.5 27 31.5 36 40.5 45
−4
−3.5
−3
−2.5
−2
−1.5
−1
−0.5
0
t [s]
aVUT
[m/s2]
0
7.5
15
22.5
30
37.5
45
52.5
60
67.5
∆D [m]
0
3
6
9
12
15
18
21
24
27
vVUT
[m/s]
0
3
6
9
12
15
18
21
24
27
vObs
[m/s]
Abbildung 6.9: Einschermanover mit Kritikalitat K = 0,8
ist als gestrichelte Linie der Abstand, der der vorgegebenen Kritikalitat beider aktuellen Geschwindigkeit des Hindernisfahrzeugs entspricht.
Beide Fahrzeuge beschleunigen aus dem Stillstand. Dabei arbeitet das As-sistenzsystem des Testfahrzeugs zunachst als Geschwindigkeitsregler, dakein vorausfahrendes Fahrzeug als relevant erkannt wird. Das Testfahrzeugbefindet sich noch im Beschleunigungsvorgang, hat seine Wunschgeschwin-digkeit jedoch fast erreicht, als das Hindernisfahrzeug bei t ≈ 34 s wahrenddes Spurwechsels vom Sensor detektiert wird und die Verzogerung beginnt.Das Assistenzsystem fordert zunachst die volle verfugbare Verzogerung an,mit abnehmender Geschwindigkeitsdifferenz wird dann auch die Verzoge-rung reduziert, so dass sich ein minimaler Abstand ∆D = 7,48 m ein-stellt. Dieser Abstand entspricht einer Kritikalitat K = 0,792 bei einerHindernisgeschwindigkeit von vObs = 13,9 m/s, der relative Fehler betragtf = −1,03%.
Reproduzierbarkeit
Zum Nachweis der Reproduzierbarkeit der durch das Spurwechselmanoverausgelosten kritischen Situationen wurden jeweils 20 Messungen fur die
82
6.2 Validierung
Kritikalitaten K1 = 0,5 und K2 = 0,9 durchgefuhrt und dabei die resultie-rende Kritikalitat gemessen.
Die Messungen wurden mit folgenden Parametern durchgefuhrt:
� Startgeschwindigkeiten von Hindernis und TestfahrzeugvObs,0 = vVUT,0 = 0 m/s
� Geschwindigkeit des Hindernisfahrzeugs vObs = 50 km/h ≈ 13,89 m/s
� Maximal mogliche Verzogerung des Assistenzsystems amax = 4 m/s2
Der erwartete minimale Abstand zwischen Testfahrzeug und Hindernisnach einer Situation mit K1 = 0,5 liegt fur die genannten Parameter bei∆Dmin = 14 m.
Die Messergebnisse fur K sind in Tabelle 6.1 dargestellt. Die beiden mar-kierten Zeilen kennzeichnen die Messungen mit der jeweils großten positi-ven und negativen Abweichung von der Sollkritikalitat. Die relativen Fehlerder Kritikalitat betragen fK- = −9,52% und fK+ = 16,10%.
Abbildung 6.10 stellt die wahrend der Messung 1 aufgenommenen Mess-werte im Uberblick dar, Abbildung 6.11 zeigt einen Ausschnitt daraus undzusatzlich das Signal
”Zielobjekt vorhanden“, mit dem das Sensormodell
die Existenz eines als relevant erkannten Hindernisobjekts signalisiert. InAbbildung 6.12 sind die Messwerte zur Messung 14 dargestellt, Abbil-dung 6.13 enthalt wieder einen Ausschnitt aus diesen Daten und das Signal
”Zielobjekt vorhanden“.
Der Vergleich der Abbildungen 6.10 und 6.12 zeigt die Unterschiede derbeiden Situationen. In Situation 10 (zu Messung 10, Tabelle 6.1) wird dasHindernisfahrzeug bei t10,0 ≈ 25,6 s als relevant erkannt, bei t10,2 ≈ 35,8 sverlasst es die Fahrspur des Testfahrzeugs nach Abschluss der Situationwieder und wird damit nicht mehr als relevant bewertet. Das Testfahrzeugerreicht dabei zum Zeitpunkt t10,1 ≈ 25,7 s eine Hochstgeschwindigkeitvon vVUT,max = 25,7 m/s ≈ 89 km/h, dann beginnt das Assistenzsystemauf das Hindernis zu reagieren, und das Testfahrzeug wird verzogert.
In Situation 14 (zu Messung 14, Tabelle 6.1) wird das Hindernisfahrzeugbei t14,0 ≈ 28,1 s als relevant erkannt, und bei t14,2 ≈ 37,3 s hat dasHindernis die Fahrspur des Testfahrzeugs wieder verlassen. Die erreich-te Hochstgeschwindigkeit des Testfahrzeugs betragt in dieser Situation
83
6 Anwendung und Validierung
Tabelle 6.1: Ergebnis der Messungen zur Reproduzierbarkeit fur ein Spur-wechselmanover mit K = 0,5
Messung ∆Dmin[m] K ∆K
Soll 14,00 0,5
1 13,90 0,509 0,009
2 14,14 0,498 -0,002
3 14,05 0,489 -0,011
4 13,57 0,516 0,016
5 13,80 0,504 0,004
6 12,76 0,552 0,052
7 12,78 0,540 0,040
8 12,28 0,569 0,069
9 14,47 0,465 -0,035
10 14,75 0,452 -0,048
11 12,96 0,533 0,033
12 14,46 0,464 -0,036
13 13,19 0,538 0,038
14 12,24 0,581 0,081
15 13,97 0,480 -0,020
16 12,95 0,534 0,034
17 13,17 0,536 0,036
18 14,24 0,474 -0,026
19 14,66 0,456 -0,044
20 13,33 0,525 0,025
84
6.2 Validierung
0 4 8 12 16 20 24 28 32 36 40
−4
−3.5
−3
−2.5
−2
−1.5
−1
−0.5
0
t [s]
aVUT
[m/s2]
0
7.5
15
22.5
30
37.5
45
52.5
60
67.5
∆D [m]
0
2.5
5
7.5
10
12.5
15
17.5
20
22.5
vVUT
[m/s]
0
2.5
5
7.5
10
12.5
15
17.5
20
22.5
vObs
[m/s]
Abbildung 6.10: Messwerte zur Messung 10 aus Tabelle 6.1
25 26 27 28 29 30 31 32 33 34 35
−4
−3.5
−3
−2.5
−2
−1.5
−1
−0.5
0
t [s]
aVUT
[m/s2]
0
7.5
15
22.5
30
37.5
45
52.5
60
67.5
∆D [m]
12
13.4
14.8
16.2
17.6
19
20.4
21.8
23.2
24.6
vVUT
[m/s]
12
13.4
14.8
16.2
17.6
19
20.4
21.8
23.2
24.6
vObs
[m/s]
1
0
Zielobjekt vorhanden
Abbildung 6.11: Ausschnitt aus Abbildung 6.10
85
6 Anwendung und Validierung
0 4 8 12 16 20 24 28 32 36 40
−4
−3.5
−3
−2.5
−2
−1.5
−1
−0.5
0
t [s]
aVUT
[m/s2]
0
7.5
15
22.5
30
37.5
45
52.5
60
67.5
∆D [m]
0
3
6
9
12
15
18
21
24
27
vVUT
[m/s]
0
3
6
9
12
15
18
21
24
27
vObs
[m/s]
Abbildung 6.12: Messwerte zur Messung 14 aus Tabelle 6.1
26 27.2 28.4 29.6 30.8 32 33.2 34.4 35.6 36.8 38
−4
−3.5
−3
−2.5
−2
−1.5
−1
−0.5
0
t [s]
aVUT
[m/s2]
0
7.5
15
22.5
30
37.5
45
52.5
60
67.5
∆D [m]
12
13.4
14.8
16.2
17.6
19
20.4
21.8
23.2
24.6
vVUT
[m/s]
12
13.4
14.8
16.2
17.6
19
20.4
21.8
23.2
24.6
vObs
[m/s]
1
0
Zielobjekt vorhanden
Abbildung 6.13: Ausschnitt aus Abbildung 6.12
86
6.2 Validierung
vVUT,max = 25,5 m/s ≈ 92 km/h zum Zeitpunkt t14,1 ≈ 28,2 s, in demdas Assistenzsystem beginnt, das Testfahrzeug zu verzogern.
Die Messungen fur ein Einschermanover mit der Kritikalitat K2 = 0,9mit dem erwarteten Abstand ∆Dmin = 5,20 m sind in Tabelle 6.2 darge-stellt. Auch hier sind wieder die Zeilen mit der jeweils großten positivenund negativen Abweichung hervorgehoben. Die relativen Kritikalitatsfehlerbetragen fur K2 fK- = −7,88% und fK+ = 7,65%.
Generierbarkeit
Zum Nachweis der Erreichbarkeit der vorgegebenen Kritikalitat wurden furEinschermanover mit den Kritikalitaten Kn ∈ [0,1; 0,2; ...; 0,9] Messungendurchgefuhrt, deren Ergebnisse hier vorgestellt werden.
Fur jede vorgegebene Kritikalitat wurden jeweils funf Messungen durch-gefuhrt, die Mittelwerte der Messergebnisse sind in Tabelle 6.3 zusammen-gefasst, die vollstandigen Messergebnisse sind im Abschnitt A.7 in Tabel-le A.1 dargestellt.
Die erzielte Kritikalitat K stimmt im Wesentlichen gut mit der vorge-gebenen Kritikalitat KSoll uberein, der mittlere relative Fehler betragtfK = −0,124%, der großte Einzelfehlerbetrag fK = −8,179%. Dieser Feh-ler tritt bei der sehr kleinen Sollkritikalitat kSoll = 0,1 auf und entspricht∆K = −0,008.
Die in den aktuellen Messungen erzielten Ergebnisse sind deutlich besserals die wahrend der Arbeit am Deliverable D5.3.1 [Ayeb u. Schmidt, 2006]erreichten Werte. Die dabei erzielten großen relativen Fehler fur niedri-ge Kritikalitaten sind auf ein zu stark vereinfachtes Modell der Bremsezuruckzufuhren. In dem zu diesem fruheren Zeitpunkt verwendeten Mo-dell wurde die Bremsanstiegszeit vernachlassigt und mit einer idealisiertenBremse gerechnet, was zur Folge hatte, dass die dem Testfahrzeug fur dienotwendige Verzogerung zur Verfugung stehende Distanz nicht ausreich-te.
87
6 Anwendung und Validierung
Tabelle 6.2: Ergebnis der Messungen zur Reproduzierbarkeit fur ein Spur-wechselmanover mit K = 0,9
Messung ∆Dmin[m] K ∆K
Soll 5,20 0,9
1 5,66 0,876 -0,024
2 4,08 0,950 0,050
3 5,10 0,901 0,001
4 5,13 0,900 -0,000
5 5,64 0,877 -0,023
6 5,35 0,891 -0,009
7 6,05 0,858 -0,042
8 5,12 0,900 -0,000
9 6,07 0,860 -0,040
10 5,08 0,907 0,007
11 4,33 0,939 0,039
12 5,38 0,887 -0,013
13 4,65 0,922 0,022
14 6,46 0,839 -0,061
15 6,04 0,863 -0,037
16 4,96 0,908 0,008
17 5,33 0,892 -0,008
18 3,68 0,969 0,069
19 5,55 0,883 -0,017
20 6,88 0,829 -0,071
88
6.2 Validierung
Tabelle 6.3: Mittelwerte der Messungen zur Generierbarkeit von Spurwech-selmanovern
KSoll K ∆K f[%]
0,10 0,099 -0,001 -1,420
0,20 0,200 0,000 0,000
0,30 0,294 -0,006 -1,913
0,40 0,397 -0,003 -0,855
0,50 0,504 0,004 0,747
0,60 0,607 0,007 1,174
0,70 0,723 0,023 3,335
0,80 0,798 -0,002 -0,293
0,90 0,883 -0,017 -1,889
89
6 Anwendung und Validierung
6.2.2 Bremsmanover
Das Kapitel beschreibt Messergebnisse von Bremsmanovern, mit denen einStauassistent untersucht wurde. Folgende Randbedingungen gelten fur alledurchgefuhrten Messungen:
� Startgeschwindigkeiten von Hindernis und TestfahrzeugvObs,0 = vVUT,0 = 0 m/s
� Wunschgeschwindigkeit des TestfahrzeugsvWunsch,VUT = 100 km/h = 27,8 m/s
� Sollgeschwindigkeit des Hindernisfahrzeugs vor dem ManovervObs,1 = 50 km/h = 13,9 m/s
� Zielgeschwindigkeit nach dem Bremsmanover vObs,2 = 0 m/s
� Maximal mogliche Verzogerung des Assistenzsystems amax = 4 m/s2
Die Abbildung 6.14 zeigt den Verlauf der Geschwindigkeiten vVUT des Test-fahrzeugs und vObs des Hindernisses, des vom Sensor gemessenen Abstan-des ∆D und der vom Assistenzsystem angeforderten Verzogerung aVUT
von Simulationsbeginn bis zum Abschluss der Situation. Außerdem ist derdie vorgegebene Kritikalitat reprasentierende Abstand (dK = 3,6 m beivObs = 0) als gestrichelte Linie in das Diagramm eingetragen.
Erkennbar ist, dass beide Fahrzeuge zunachst beschleunigen. Das Hinder-nis beschleunigt bis zur vorgegebenen Zielgeschwindigkeit, das Testfahr-zeug erreicht seine Wunschgeschwindigkeit nicht, da das Hindernis bereitsvor Erreichen der Wunschgeschwindigkeit detektiert wird und das Assis-tenzsystem die Geschwindigkeit daraufhin an das vorausfahrende Fahrzeuganpasst.
Solange kein Objekt detektiert wurde, liefert das Sensormodell fur denAbstand ∆D = 0 m. Das Signal
”Zielobjekt vorhanden“ zeigt in diesem
Fall an, dass kein Objekt als relevant erkannt wurde und der gelieferteWert fur ∆D ungultig ist. Bei t ≈ 18 s wird das Zielobjekt erkannt und eingultiger Wert fur ∆D geliefert, das Testfahrzeug setzt die Beschleunigungaufgrund des großen Abstands zunachst jedoch fort.
Bei t ≈ 26 s wird die Beschleunigung beendet, und das Testfahrzeug be-ginnt, sich der Geschwindigkeit des vorausfahrenden Hindernisfahrzeugsanzupassen.
90
6.2 Validierung
0 5 10 15 20 25 30 35 40 45 50
−4
−3.5
−3
−2.5
−2
−1.5
−1
−0.5
0
t [s]
aVUT
[m/s2]
0
15
30
45
60
75
90
105
120
135
∆D [m]
0
2.5
5
7.5
10
12.5
15
17.5
20
22.5
vVUT
[m/s]
0
2.5
5
7.5
10
12.5
15
17.5
20
22.5
vObs
[m/s]
Abbildung 6.14: Bremsmanover mit Kritikalitat K = 0,8
Zum Zeitpunkt t ≈ 37 s beginnt das Hindernisfahrzeug mit der abruptenVerzogerung, nachdem das Testfahrzeug den Verzogerungsvorgang beendethat. Das Testfahrzeug reagiert mit maximaler Verzogerungsanforderungund kann einen Abstand (∆Dmin = 3,66 m) knapp uber dem durch dievorgegebene Kritikalitat festgelegten Wert halten.
Die Kritikalitat zum Zeitpunkt des geringsten Abstandes betragt in derdargestellten Situation K0,8 = 0,78, liegt also geringfugig unterhalb dergeforderten Kritikalitat. Der relative Fehler betragt f = −2,5%.
Reproduzierbarkeit
Zum Nachweis der Reproduzierbarkeit der erzeugten Situationen wurdenjeweils 20 Messungen fur Bremsmanover mit den Kritikalitaten K1 = 0,5und K2 = 0,9 durchgefuhrt.
Die Messungen wurden mit folgender Konfiguration durchgefuhrt:
� Startgeschwindigkeiten von Hindernis und TestfahrzeugvObs,0 = vVUT,0 = 0 m/s
91
6 Anwendung und Validierung
Abbildung 6.15: Bremsmanover mit K = 0,8
� Testfahrzeug und Hindernisfahrzeug auf der mittleren Fahrspur (−2)
� Wunschgeschwindigkeit des TestfahrzeugsvWunsch,VUT = 80 km/h = 22,2 m/s
� Sollgeschwindigkeit des Hindernisfahrzeugs vor dem ManovervObs,1 = 50 km/h = 13,9 m/s
92
6.2 Validierung
� Zielgeschwindigkeit nach dem Bremsmanover vObs,2 = 0 m/s
� Maximal mogliche Verzogerung des Assistenzsystems amax = 4 m/s2
Die Ergebnisse fur das Manover mit K1 = 0,5 sind in Tabelle 6.4 darge-stellt, Tabelle 6.5 zeigt die Ergebnisse fur K2 = 0,9.
Hervorgehoben sind wieder die Zeilen, die die jeweils großte positive undnegative Abweichung vom Sollwert zeigen. Da das Hindernisfahrzeug biszum Stillstand abbremst, fuhren kleine Abweichungen von dem die vorge-gebene Kritikalitat reprasentierenden Abstand bereits zu großen relativenFehlern bei der resultierenden Kritikalitat. Die Abweichungen vom Soll-abstand sind jedoch im Rahmen der Messgenauigkeit des Sensors tolerier-bar. Nach Tellmann [2010] liegt die Messgenauigkeit des Sensormodells bei±0,6 m bzw. ±0,5%, die Ergebnisse der erzeugten Situationen liegen alsonoch innerhalb des Toleranzbereichs des Sensormodells.
Die relativen Fehler der Kritikalitat in den markierten Zeilen betragen furK1 = 0,5, fK- = −7,34% und fK+ = 9,34%, die relativen AbstandsfehlerfD- = 2,44% und fD+ = −3,11%, das entspricht absoluten Abstandsfehlernvon FD- = 0,11 m und FD+ = −0,14 m.
Fur K2 = 0,9 betragen die relativen Fehler der Kritikalitat fK- = −5,56%und fK+ = 5,56%, die relativen Abstandsfehler fD- = 4,55% und fD+ =−4,55% bei einem absoluten Abstandsfehler FD- = 0,15 m und FD+ =−0,15 m.
Generierbarkeit
Zum Nachweis der Generierbarkeit von Situationen mit verschiedenen vor-gegebenen Kritikalitaten wurden fur Bremsmanover Messungen mit denKritikalitaten Kn ∈ [0,1; 0,2; ...; 0,9] durchgefuhrt. Die Mittelwerte der er-reichten Kritikalitat sind in Tabelle 6.6 zusammen mit dem relativen Fehlerf dargestellt. Wahrend die erreichte Kritikalitat bei der Auswertung derErgebnisse fur [Ayeb u. Schmidt, 2006] noch deutlich hoher als der spezi-fizierte Wert lag, werden nun im Durchschnitt sehr kleine relative Fehlererzielt. Dies ist, wie bereits oben beschrieben, auf die Erweiterung desBremsmodells um die Anstiegszeit zuruckzufuhren.
93
6 Anwendung und Validierung
Tabelle 6.4: Ergebnis der Messungen zur Reproduzierbarkeit fur einBremsmanover mit K = 0,5
Messung ∆Dmin[m] K ∆K
Soll 4,50 0,5
1 4,61 0,463 -0,037
2 4,49 0,503 0,003
3 4,59 0,470 -0,030
4 4,41 0,530 0,030
5 4,45 0,517 0,017
6 4,55 0,483 -0,017
7 4,59 0,470 -0,030
8 4,50 0,500 0,000
9 4,46 0,513 0,013
10 4,49 0,503 0,003
11 4,54 0,487 -0,013
12 4,48 0,507 0,007
13 4,52 0,493 -0,007
14 4,53 0,490 -0,010
15 4,52 0,493 -0,007
16 4,56 0,480 -0,020
17 4,38 0,540 0,040
18 4,36 0,547 0,047
19 4,37 0,543 0,043
20 4,36 0,547 0,047
94
6.2 Validierung
Tabelle 6.5: Ergebnis der Messungen zur Reproduzierbarkeit fur einBremsmanover mit K = 0,9
Messung ∆Dmin[m] K ∆K
Soll 3,30 0,9
1 3,33 0,890 -0,010
2 3,40 0,867 -0,033
3 3,28 0,907 0,007
4 3,39 0,870 -0,030
5 3,17 0,943 0,043
6 3,20 0,933 0,033
7 3,26 0,913 0,013
8 3,37 0,877 -0,023
9 3,27 0,910 0,010
10 3,39 0,870 -0,030
11 3,27 0,910 0,010
12 3,17 0,943 0,043
13 3,19 0,937 0,037
14 3,41 0,863 -0,037
15 3,45 0,850 -0,050
16 3,35 0,883 -0,017
17 3,30 0,900 0,000
18 3,15 0,950 0,050
19 3,20 0,933 0,033
20 3,29 0,903 0,003
95
6 Anwendung und Validierung
Tabelle 6.6: Mittelwerte der Messungen zur Generierbarkeit von Brems-manovern
KSoll K ∆K f[%]
0,10 0,097 -0,003 -3,000
0,20 0,207 0,007 3,500
0,30 0,303 0,003 1,100
0,40 0,390 -0,010 -2,500
0,50 0,502 0,002 0,330
0,60 0,597 -0,003 -0,550
0,70 0,720 0,020 2,857
0,80 0,830 0,030 3,750
0,90 0,905 0,005 0,556
96
6.2 Validierung
6.2.3 Vorubergehender Ausfall des Sensors
Spurwechselmanover mit K = 0,5
Um die Auswirkungen vorubergehender Sensorausfalle zu untersuchen, wur-den fur die folgenden Messungen die Sensorsignale manipuliert und so diean das Assistenzsystem gelieferten Objektdaten verfalscht.
Die Startbedingungen fur die folgende Messung sind identisch zu der in Ab-schnitt 6.2.1 beschriebenen Situation. Untersucht wurde wieder ein Spurwechsel-manover mit der Sollkritikalitat K1 = 0,5.
Wie in Abbildung 6.16 erkennbar ist, wurde das Hindernis zwar bei t0 =25,46 s erkannt, allerdings wurden zum Zeitpunkt toff = 25,55 s die vomSensor gemessenen Werte fur Abstand und Geschwindigkeit auf Null ge-setzt. Daraufhin setzte das Sensormodell das Signal
”Zielobjekt vorhan-
den“ einen Zeitschritt spater ebenfalls auf Null. Dieses Signal beschreibt,ob ein Hindernis vom Sensor als relevant erkannt wurde oder nicht. DasAssistenzsystem nahm nun an, es sei kein Zielobjekt mehr vorhanden undbegann als Reaktion darauf bei t1 = 25,61 s die Verzogerungsanforderungzuruckzunehmen.
0 4 8 12 16 20 24 28 32 36 40
−4
−3.5
−3
−2.5
−2
−1.5
−1
−0.5
0
t [s]
aVUT
[m/s2]
0
7.5
15
22.5
30
37.5
45
52.5
60
67.5
∆D [m]
0
2.5
5
7.5
10
12.5
15
17.5
20
22.5
vVUT
[m/s]
0
2.5
5
7.5
10
12.5
15
17.5
20
22.5
vObs
[m/s]
Abbildung 6.16: Sensorausfall beim Spurwechselmanover mit KSoll = 0,5
97
6 Anwendung und Validierung
24.5 24.8 25.1 25.4 25.7 26 26.3 26.6 26.9 27.2 27.5
−4
−3.5
−3
−2.5
−2
−1.5
−1
−0.5
0
t [s]
aVUT
[m/s2]
0
7.5
15
22.5
30
37.5
45
52.5
60
67.5
∆D [m]
19
19.6
20.2
20.8
21.4
22
22.6
23.2
23.8
24.4
vVUT
[m/s]
19
19.6
20.2
20.8
21.4
22
22.6
23.2
23.8
24.4
vObs
[m/s]
1
0
Zielojekt vorhanden
Abbildung 6.17: Ausschnitt aus Abbildung 6.16
Zum Zeitpunkt ton = 25,65 s wurden die Messergebnisse des Sensors nichtmehr manipuliert, dem Sensormodell standen also wieder korrekte Wertezur Verfugung. Ab t2 = 25,69 s setzte das Sensormodell das Signal
”Ziel-
objekt vorhanden“ wieder auf eins. In der Folge erhoht das Assistenzsystemab t3 = 25,73 s die Verzogerungsanforderung wieder, und die Geschwindig-keit des Testfahrzeugs wurde deutlich reduziert.
Die Abbildung 6.17 zeigt die Messwerte zu der beschriebenen Messungnoch einmal im Detail.
In Folge des ∆t1 = 100 ms dauernden (simulierten) Sensorausfalls kam eszu einer Unterschreitung des geforderten Abstandes von ∆DSoll0,5 = 14 mum d = 2,52 m, so dass der resultierende Abstand nur noch ∆D = 11,48 mbetrug. Die resultierende Kritikalitat der Situation betrug K = 0,63.
Spurwechselmanover mit K = 0,9
Die Untersuchung wurde fur die gleiche Ausgangssituation, allerdings mitder SollkritikalitatK2 = 0,9 wiederholt. Aufgrund der geringeren Abstande
98
6.2 Validierung
0 4 8 12 16 20 24 28 32 36 40
−4
−3.5
−3
−2.5
−2
−1.5
−1
−0.5
0
t [s]
aVUT
[m/s2]
0
7.5
15
22.5
30
37.5
45
52.5
60
67.5
∆D [m]
0
3
6
9
12
15
18
21
24
27
vVUT
[m/s]
0
3
6
9
12
15
18
21
24
27
vObs
[m/s]
Abbildung 6.18: Sensorausfall beim Spurwechselmanover mit KSoll = 0,9
wurde diesmal das Sensorsignal nur fur ∆t2 = 70 ms manipuliert. Der Sen-sor erkannte das Hindernis bei t0 = 29,86 s, ab toff = 29,9 s wurden dieSensordaten manipuliert, und einen Zeitschritt spater wurde kein relevan-tes Hindernis mehr an das Assistenzsystem ubermittelt. Bei ton = 29,97 smaß der Sensor wieder korrekte Werte. Im nachsten Simulationszyklus wur-de wieder ein relevantes Hindernis gemeldet. Die Folge der Unterbrechungwar wieder die kurzzeitige Rucknahme der Verzogerungsanforderung durchdas Assistenzsystem.
Die Abbildungen 6.18 und 6.19 zeigen wieder die komplette Situation bzw.den relevanten Ausschnitt der Messung.
Der fur die spezifizierte KritikalitatK2 = 0,9 erwartete Abstand ∆DSoll0,9 =5,2 m wurde in der Folge um d = 2,22 m unterschritten, so dass der re-sultierende Abstand ∆D = 2,98 m betrug. Dieser Abstand war jedochkleiner als die minimale Detektionsdistanz des Sensors (dmin = 3 m, vgl.Abschnitt 3.3.2). Die Situation war also mit K = 1 zu bewerten, da dieUnterschreitung des Mindestabstandes dazu hatte fuhren konnen, dass dasHindernisobjekt vom Sensor nicht mehr erkannt worden ware und das Test-fahrzeug daraufhin wieder beschleunigt hatte.
99
6 Anwendung und Validierung
29.5 29.6 29.7 29.8 29.9 30 30.1 30.2 30.3 30.4 30.5
−4
−3.5
−3
−2.5
−2
−1.5
−1
−0.5
0
t [s]
aVUT
[m/s2]
0
7.5
15
22.5
30
37.5
45
52.5
60
67.5
∆D [m]
25
25.14
25.28
25.42
25.56
25.7
25.84
25.98
26.12
26.26
vVUT
[m/s]
25
25.14
25.28
25.42
25.56
25.7
25.84
25.98
26.12
26.26
vObs
[m/s]
1
0
Zielojekt vorhanden
Abbildung 6.19: Ausschnitt aus Abbildung 6.18
Das Hindernis wurde vom Sensormodell noch detektiert, da der Mindestab-stand des Sensormodells noch nicht unterschritten war [Tellmann, 2010].Das Assistenzsystem versuchte daher nicht, auf die Wunschgeschwindigkeitzu beschleunigen, was unweigerlich zu einer Kollision gefuhrt hatte.
6.2.4 Auslosetoleranz
Fur die verschiedenen Manover wurde auch die Auslosetoleranz untersucht.Dazu wurde aus den aufgezeichneten Daten bestimmt, in welcher Ent-fernung zum Testfahrzeug das Hindernisfahrzeug mit dem Erzeugen derVerkehrssituation begann und welche Verzogerung beim Bremsmanoveraufgewandt wurde.
Die Tabellen 6.7, 6.8, 6.9 und 6.10 zeigen die gemessenen Auslosedis-tanzen ∆D0 fur Spurwechsel- und Bremsmanover mit den KritikalitatenK1,3 = 0,5 und K2,4 = 0,9. In den Tabellen 6.7 und 6.8 sind neben derAuslosedistanz auch die Geschwindigkeiten vVUT und vObs dargestellt, dadie erzielte Kritikalitat bei Spurwechselmanovern primar von diesen Pa-rametern abhangt. Fur Bremsmanover (Tabellen 6.9 und 6.10) ist neben∆D0 auch die Verzogerung des Hindernisfahrzeugs aObs angegeben.
100
6.2 Validierung
Tabelle 6.7: Ergebnis der Messungen zur Ausloseprazision fur ein Spur-wechselmanover mit K = 0,5
Messung ∆K ∆D0[m] vVUT[m/s] vObs[m/s]
1 0,01 46,95 24,27 13,89
2 -0,00 47,05 24,34 13,89
3 -0,01 47,02 24,35 13,89
4 0,02 46,97 24,35 13,89
5 0,00 49,08 25,01 13,89
6 0,05 47,08 24,35 13,89
7 0,04 47,03 24,35 13,89
8 0,07 46,97 24,35 13,89
9 -0,03 47,04 24,35 13,89
10 -0,05 47,03 24,35 13,89
Tabelle 6.8: Ergebnis der Messungen zur Ausloseprazision fur ein Spur-wechselmanover mit K = 0,9
Messung ∆K ∆D0[m] vVUT[m/s] vObs[m/s]
1 -0,02 45,26 25,77 13,89
2 0,05 41,97 25,29 13,89
3 0,00 42,02 25,29 13,89
4 -0,00 41,93 25,30 13,89
5 -0,02 42,06 25,42 13,89
6 -0,01 44,71 25,79 13,89
7 -0,04 42,01 25,31 13,89
8 -0,00 41,86 25,30 13,89
9 -0,04 42,04 25,29 13,89
10 0,01 42,07 25,31 13,89
101
6 Anwendung und Validierung
Tabelle 6.9: Ergebnis der Messungen zur Ausloseprazision fur ein Brems-manover mit K = 0,5
Messung ∆K ∆D0[m] aObs[m/s2]
1 0,05 26,41 -3,08
2 -0,01 26,97 -3,16
3 0,08 26,24 -3,05
4 -0,01 26,01 -3,03
5 0,10 24,84 -2,97
6 -0,01 24,16 -2,89
7 0,09 25,80 -2,99
8 -0,02 26,78 -3,13
9 0,04 24,70 -2,94
10 0,05 25,09 -2,96
Tabelle 6.10: Ergebnis der Messungen zur Ausloseprazision fur ein Brems-manover mit K = 0,9
Messung ∆K ∆D0[m] aObs[m/s2]
1 0,02 26,78 -3,30
2 -0,06 25,98 -3,19
3 0,09 25,67 -3,14
4 0,09 27,37 -3,40
5 0,08 26,45 -3,25
6 0,06 26,33 -3,24
7 -0,01 25,78 -3,16
8 0,03 25,58 -3,13
9 0,09 26,79 -3,30
10 -0,12 25,72 -3,15
102
6.2 Validierung
Der Vergleich der Toleranz bei der Auslosung des Fahrmanovers mit derAbweichung der erzielten Kritikalitat zeigt, dass trotz der scheinbar großenAbweichungen die Fehler der Kritikalitat klein sind, solange der Situations-generator beim Spurwechsel die Parameter ∆D0 und vVUT passend wahlt.Fur Bremsmanover sind ∆D0 und aObs die Parameter, die vom Situati-onsgenerator vorgegeben werden mussen.
Bei manueller Durchfuhrung der Tests mit realen Fahrzeugen muss auf-grund der Reaktionszeiten eines menschlichen Fahrers schon bei der Auslo-sung eines Manovers mit Toleranzen im Bereich mehrerer Meter gerechnetwerden. Da man bei der Durchfuhrung der Tests von geubten und auf dasEreignis vorbereiteten Fahrern ausgehen muss, lassen sich die von Huge-mann [2002] neu bewerteten Ergebnisse der Untersuchung von Burckhardt[1985] auf die Situation ubertragen. Man kann also davon ausgehen, dassein Fahrer nach dem Erscheinen eines Signals eine Zeit zwischen 0,36 sund 0,63 s braucht, um das geforderte Fahrmanover einzuleiten. Die Ta-belle 6.11 zeigt, mit welchen Toleranzen aufgrund der Reaktionszeit desMenschen beim Start eines Manovers mindestens zu rechnen ist.
Daruber hinaus besteht in der Literatur Einigkeit daruber, dass nicht nurzwischen verschiedenen Personen Unterschiede in der Reaktionszeit auf-treten, sondern dass auch dieselbe Person bei wiederholten Versuchen imAllgemeinen unterschiedliche Reaktionszeiten aufweisen wird [Hugemann,
Tabelle 6.11: Auslosetoleranzen bei unterschiedlichen Geschwindigkeitenund Reaktionszeiten eines menschlichen Fahrers
tR[s]
v[km/h] v[m/s] 0,3 0,36 0,4 0,5 0,6 0,63 0,7
30 8,3 2,5 3,0 3,3 4,2 5,0 5,3 5,840 11,1 3,3 4,0 4,4 5,6 6,7 7,0 7,850 13,9 4,2 5,0 5,6 6,9 8,3 8,8 9,760 16,7 5,0 6,0 6,7 8,3 10,0 10,5 11,770 19,4 5,8 7,0 7,8 9,7 11,7 12,3 13,680 22,2 6,7 8,0 8,9 11,1 13,3 14,0 15,690 25,0 7,5 9,0 10,0 12,5 15,0 15,8 17,5
100 27,8 8,3 10,0 11,1 13,9 16,7 17,5 19,4
103
6 Anwendung und Validierung
2002], [Zomotor, 1991]. Dies wird dazu fuhren, dass bei dem Versuch, einManover zu reproduzieren, deutliche Unterschiede in der Ausfuhrung auf-treten.
6.2.5 Bewertung
Die gemessenen Toleranzen bei der generierten Kritikalitat sowie der Aus-losedistanz haben ihre Ursachen in der fehlenden zeitlichen Synchronisationder beteiligten Rechner und im nichtdeterministischen Verhalten des Kom-munikationsmediums CAN. Wurden alle Algorithmen synchron zueinan-der ausgefuhrt und konnte jede zeitliche Toleranz zwischen der Ausfuhrungder einzelnen Programme und in der Ubertragung der Nachrichten ausge-schlossen werden, so wurde die Simulation bei wiederholter Ausfuhrungmit gleichen Ausgangsbedingungen die exakt gleichen Ergebnisse liefern.Da jedoch auch in der realen Anwendung von Fahrerassistenzsystemen inKraftfahrzeugen die Kommunikation auf CAN basiert, bildet die Simula-tion die systemeigene Unscharfe zumindest in Teilen mit ab.
Die Messungen der erzeugten Kritikalitaten sowie der Auslosetoleranzenbelegen die Anwendbarkeit der Methode zum reproduzierbaren Test vonFahrerassistenzsystemen. Durch die Simulation lassen sich gefahrlos auchriskante Situationen untersuchen, wie beispielsweise Manover mit hoher zugenerierender Kritikalitat oder die Auswirkungen eines Sensorausfalls.
104
7 Zusammenfassung undAusblick
Das Ziel, ein Simulationswerkzeug zu entwickeln, das den entwicklungsbe-gleitenden Test von Fahrerassistenzsystemen reproduzierbar und risikolosunterstutzt, wurde erreicht. Das entstandene Werkzeug ist im Model-in-the-Loop- und Software-in-the-Loop-Betrieb genauso einsetzbar wie zu-sammen mit realen Komponenten im Hardware-in-the-Loop-Betrieb. DieSimulationsumgebung hat ein stabiles Prototypenstadium erreicht, fur dieproduktive Nutzung kann die Entwicklung auf dieser Basis fortgesetzt wer-den.
Der aktuelle Stand der Simulationsumgebung erlaubt den Test von Fah-rerassistenzsystemen zur Fahrzeuglangsfuhrung. Zum Test anderer Syste-me, wie beispielsweise eines Spurwechselassistenten, muss zunachst die Kri-tikalitat auch fur Situationen definiert werden, die Hindernisfahrzeuge imSeitenbereich des Testfahrzeugs umfassen. Dazu kann aufbauend auf deraktuellen Definition der Kritikalitat mit dem von Burckhardt [1993] be-schriebenen erforderlichen Seitenabstand zwischen Fahrzeugen der Defini-tionsbereich erweitert werden.
In der Folge sollten dann auch zusatzliche Situationen in den Situationska-talog aufgenommen werden, so dass Szenarien fur Testfahrzeuge mit meh-reren Assistenzsystemen moglich werden.
105
7 Zusammenfassung und Ausblick
106
A Anhang
A.1 Anforderungskatalog
107
A Anhang
Anforderungen an Verkehrs- und Umweltsimulation
EinleitungFahrerassistenzsysteme (FAS) sind komplexe Systeme, deren Test aufgrund der erfor-derlichen „Ziele“ für die Sensorik mit einem großen Aufwand hinsichtlich Personal- und Materialeinsatz verbunden ist, wenn die Systeme im realen Verkehrsumfeld getestet werden sollen. Außerdem birgt der Test von FAS in kritischen Situationen Gefahren für die beteiligten Personen, da durch eine Fehlfunktion der Systeme für den Fahrer nicht beherrschbare Situationen auftreten können. Mit Hilfe einer simulierten Umgebung kön-nen Fahrerassistenzsysteme mit geringerem Aufwand getestet werden, da keine realen „Ziele“ erforderlich sind, um die Systeme mit Eingabewerten zu versorgen.
Struktur der SimulationsumgebungDer grundlegende Aufbau einer Simulationsumgebung zum Test von FAS an einer si-mulierten Umgebung ist in folgender Abbildung dargestellt:
Die Umweltsimulation enthält Objekte (Fahrzeuge, Hindernisse) und eine Umwelt, in der sich diese Objekte bewegen. Die Umwelt definiert den Verlauf der Straße und die Position von ortsfesten Hindernissen. Innerhalb der Simulation bewegt sich neben „nor-malen“, von einem Fahrermodell gesteuerten Fahrzeugen auch ein spezielles Fahrzeug ("Vehicle under test" VUT), das neben dem Fahrermodell auch von den Ausgaben der angeschlossenen FAS beeinflusst wird. Die „normalen“ Fahrzeuge müssen ebenfalls be-einflussbar sein, um die Reproduktion von kritischen Situationen zu ermöglichen. In Ab-hängigkeit von der Gesamtsituation müssen sich einzelne Fahrzeuge so beeinflussen las-sen, dass die Kritikalität der Situation gewahrt bleibt und die Funktion des Assistenzsys-tems überprüft werden kann.Die Schnittstelle zwischen der Simulationssoftware und den FAS bildet eine Objektda-tenbank, die Informationen über alle relevanten Objekte enthält. Aufgrund der verschie-denen „Sichtbereiche“ der FA-Sensoren übermittelt die Objektdatenbank nur ausgewähl-te Objekte an die angeschlossenen Systeme. Jedes angeschlossene Assistenzsystem be-rechnet dann die erforderliche Reaktion des Fahrzeuges auf die Situation und gibt diese Informationen an die Simulationssoftware zurück. Mit diesen Daten muss dann das VUT beeinflusst werden.
Christian Schmidt 1Universität Kassel, Fachgebiet Fahrzeugsysteme und Grundlagen der Elektrotechnik 29.03.2004
FAS1
Objektdatenbank&
Schnittstellen
Umwelt-simulation
FahrzeugeHindernisse
Strassen
FAS2
FAS2
108
A.1 Anforderungskatalog
AnforderungskatalogUm Fahrerassistenzsysteme mit Hilfe einer Verkehrssimulationssoftware testen zu kön-nen, muss die Simulationssoftware verschiedene Anforderungen erfüllen.
Anforderungen an die Objekte (Fahrzeuge, Hindernisse) innerhalb der Simulation– Objekte müssen mit Attributen versehen sein, die die Position und die Bewegung be-
schreiben. Benötigt werden folgende Angaben:• aktuelle Position im Raum,• Geschwindigkeit,• Richtung der Bewegung.
– Zur Berechnung der von den Sensoren erkannten Beschreibung der Objekte müssen diese zusätzlich mit Attributen ausgestattet sein, die die physikalischen Eigenschaf-ten der Sensoren berücksichtigen. Dazu gehören:• Richtungsbezogener Reflektionsgrad (Radar, Licht [sichtbar / IR])• Objektabmessungen (3D-Größe, Ausrichtung)
Um reale Assistenzsysteme an einer Simulationsumgebung testen zu können, sind ver-schiedene Schnittstellen zur Simulationssoftware erforderlich.Folgende Schnittstellen müssen vorhanden sein:– Programmierschnittstelle zur Beeinflussung des Verkehrsgeschehens und einzelner
Objekte innerhalb der Simulation. Der Test der FAS soll mit ausgewählten kritischen Situationen erfolgen, diese müssen von außen beeinflussbar sein. Dazu muss es mög-lich sein, das „Verhalten“ der simulierten Objekte zu beeinflussen bzw. die Trajekto-rie der umgebenden Fahrzeuge extern vorzugeben.
– Schnittstelle zum Abfragen der Daten der simulierten Objekte. Die o.g. Informationen der simulierten Objekte müssen an dieser Schnittstelle zur Verfügung stehen.
– Schnittstelle zur Beeinflussung der Dynamik/des Verhaltens des VUT innerhalb der Simulationsumgebung.
Eine weitere Voraussetzung für den Test realer Assistenzsysteme mit Hilfe der Simulati-onsumgebung ist, dass die Simulationssoftware auf Hardware-in-the-Loop (HIL) Um-gebungen eingesetzt werden kann. Die angeschlossenen Assistenzsysteme müssen mit allen Eingabedaten versorgt werden, die auch im realen Fahrzeug zur Verfügung stehen würden.
Die Informationen, die die FAS für die Situationsbewertung erfordern, müssen in Echt-zeit vorliegen, das bedingt natürlich auch die Berechnung der simulierten Umwelt in Echtzeit.
Christian Schmidt 2Universität Kassel, Fachgebiet Fahrzeugsysteme und Grundlagen der Elektrotechnik 29.03.2004
109
A Anhang
Anforderungen an realisierbare VerkehrsszenarienDie zu realisierenden Verkehrsszenarien müssen in verschiedenster Weise beeinflussbar sein. So ist z.B. die Position eines vorausfahrenden Fahrzeuges in der Fahrspur ein ent-scheidender Parameter zur Bestimmung der „Sichtbarkeit“ des Objektes mit unterschied-lichen Sensoren.Wesentliche Eigenschaften der Situation sind:– Position der beteiligten Objekte• absolute Position in „Weltkoordinaten“• relative Position zum VUT, dazu gehören:– Abstand absolut (x,y,z)– relative Position in einer oder mehreren Richtungen (z.B. seitlicher Versatz in
der gleichen Fahrspur)Die verschiedenen Positionsangaben lassen sich selbstverständlich eindeutig ineinander umrechnen, jedoch kann die Vorgabe eines seitlichen Versatzes und des absoluten Ab-standes in einem Szenario von Bedeutung sein, während in einem Anderen lediglich der zeitliche Abstand (die Zeitlücke) zwischen den beteiligten Fahrzeugen relevant ist.– Bewegungen der beteiligten Objekte• absoluter Bewegungsvektor, der die Bewegung des Objekts in Weltkoordinaten be-
schreibt• relativer Bewegungsvektor, der die Bewegung des Objektes bezogen auf das VUT
beschreibt
Christian Schmidt 3Universität Kassel, Fachgebiet Fahrzeugsysteme und Grundlagen der Elektrotechnik 29.03.2004
110
A.2 Fehlerabschatzung zur Linearisierung der Spurwechseltrajektorie
A.2 Fehlerabschatzung zur Linearisierung derSpurwechseltrajektorie
Die Funktion
O(D) = O(D0)− w
2
(1− cos
(D −D0
`π
))wird zur einfacheren Handhabung in der Echtzeitsimulation durch
O(∆s) = O0 +cos(α)∆s
`∆O
genahert.
Der Fehler kann fur den zu erwartenden Wertebereich durch numerischeIntegration der Originalfunktion und Auswertung der Naherungsfunktionabgeschatzt werden. Die Abbildung A.1 zeigt das Ergebnis der Fehlerbe-rechnung fur eine Spurwechselbreite von zwei bis acht Metern, entspre-chend dem Spurwechsel auf einer schmalen zweispurigen Landstraße biszu einem Spurwechsel uber drei Fahrstreifen auf Autobahnen1 bei einerSpurwechsellange von 10− 100 m.
Der großte Fehler tritt bei großen Spurwechselbreiten bei gleichzeitig sehrkleiner Spurwechsellange auf und liegt bei acht Meter Spurwechselbrei-te bei nur zehn Metern Spurwechsellange und betragt dann −3,03 %. Daeine derart große Spurwechselbreite bei sehr geringen Spurwechsellangenjedoch aufgrund der tolerierten Querbeschleunigung nicht zu erwarten ist(vgl. Abschnitt 4.3.1), kann der Linearisierungsfehler fur die wahrend derSimulation zu erzeugenden Situationen vernachlassigt werden.
1In [Forschungsgesellschaft fur Straßen- und Verkehrswesen, 1996] werden verschiedeneStraßenkategorien definiert, fur die je nach durchschnittlicher taglicher Verkehrsbe-lastung unterschiedliche Regelquerschnitte definiert sind.
111
A Anhang
23
45
67
8
0
20
40
60
80
100-3.5
-3
-2.5
-2
-1.5
-1
-0.5
0
Fahrspurbreite [m]
Laenge des Spurwechsels [m]
rela
tiver
Feh
ler [
%]
-3
-2.5
-2
-1.5
-1
-0.5
Abbildung A.1: Linearisierungsfehler
112
A.3 Abkurzungsverzeichnis
A.3 Abkurzungsverzeichnis
ALS Adaptive Lichtsteuerung
CAN Controller Area Network
ESU External Simulation Unit
FAS Fahrerassistenzsystem
FPGA Field Programmable Gate Array
HiL Hardware-in-the-Loop
LIN Local Interconnect Network
MiL Model-in-the-Loop
MPI Message Passing Interface
Obs Obstacle, Hindernisfahrzeug
PIM Platform Independent Model
SCADE Safety-Critical Application Development Environment
SHA Spurhalteassistent
SiL Software-in-the-Loop
STA Stauassistent
TTP Time Triggered Protocol
VME Versa Module Eurocard
VUT Vehicle under test, Testfahrzeug
113
A Anhang
A.4 Verzeichnis der Formelzeichen
a Beschleunigung
d Abstand
g Gravitationskonstante, g = 9,81m/s2
K Kritikalitat
` Lange des gesamten Spurwechselvorganges
v Geschwindigkeit
w Spurbreite (auch Spurwechselbreite)
∆s Zuruckgelegter Weg wahrend der Zeit ∆t
t Zeit [s]
τ Zeitschritt [s]
D,O,L Straßenkoordinaten
D Seit Anfangspunkt der Straße entlang der Straßenmittellinie zuruckgelegterWeg [m]
O Abstand zur Straßenmittellinie in der Straßenebene [m]
L Hohe uber der Straßenoberflache [m]
x, y, z kartesische Koordinaten
ϕ Wankwinkel
θ Nickwinkel
ψ Gierwinkel
114
A.5 Glossar
A.5 Glossar
Fahrermodell Fahrermodelle bilden das Verhalten menschlicher Fahrer imStraßenverkehr nach und steuern die Hindernisfahrzeuge durch dasStraßennetz, solange keine kritische Situation erzeugt werden soll.
FlexRay FlexRay ist ein deterministisches, fehlertolerantes serielles Bus-system, das vom FlexRay Konsortium spezifiziert und bis 2009 be-treut wurde.
Hindernisfahrzeug Hindernisfahrzeuge werden, von Fahrermodellen oderdem Situationsgenerator gesteuert, durch die virtuelle Umwelt be-wegt und bilden die virtuellen Verkehrsteilnehmer. Sie erzeugen un-ter der Kontrolle des Situationsgenerators die geforderten kritischenVerkehrssituationen.
Kritikalitat Die Kritikalitat ist ein Maß fur die Gefahrlichkeit der Situation(siehe auch Abschnitt 3.3.2).
Konfigurationsdateien Konfigurationsdateien enthalten alle fur die Simu-lation relevanten Informationen uber die Simulationsumgebung unddie darin enthaltenen Elemente.
SCADE Esterel SCADE ist eine Entwicklungsumgebung zur grafischenModellierung sicherheitskritischer Systeme nach DO-178B im Luft-fahrtbereich und IEC 61508 im Automobilbau. SCADE enthalt einenC-Codegenerator.
Sensormodell Sensormodelle bilden die Schnittstelle zwischen Fahrerassis-tenzsystem und den Teilnehmern des virtuellen Verkehrs.
Simulationsumgebung Die Simulationsumgebung beschreibt alle zu einerSimulation notwendigen Elemente der virtuellen Umwelt, d.h. Mo-delle fur das Testfahrzeug und die Hindernisfahrzeuge, die Sensor-und Fahrermodelle, den Situationsgenerator und das Straßennetz.
Situationsgenerator Der Situationsgenerator beeinflusst die Hindernisfahr-zeuge so, dass die geforderte kritische Verkehrssituation erzeugt wird.Der Situationsgenerator beobachtet dazu den virtuellen Verkehr, d.h.die Zustandsgroßen aller Verkehrsteilnehmer, um die Hindernisfahr-zeuge entsprechend steuern zu konnen.
115
A Anhang
Startbogenlange Die kritische Situation wird bei Erreichen der Startbo-genlange D0 ausgelost.
Startzeitpunkt Die kritische Situation wird zum Startzeitpunkt t0 aus-gelost.
Straßennetz Das Straßennetz besteht aus einem geschlossenen Rundkurs,dessen Lange und Verlauf im Raum konfigurierbar sind.
Testfahrzeug Das Testfahrzeug (auch Vehicle under Test, VUT) ist dasFahrzeug, das mit virtuellen Sensoren und dem zu testenden Systemals Fahrerassistenzsystem ausgerustet ist. Die Fahrdynamik diesesFahrzeugs ist detailliert nachgebildet, um den Einfluss des Assistenz-systems beurteilen zu konnen. Das Testfahrzeug bildet einen Teilneh-mer des virtuellen Verkehrs.
Verkehrssituation Eine Verkehrssituation stellt jeweils einen Testfall furdas Fahrerassistenzsystem dar.
116
A.6 Parameter Datei
A.6 Parameter Datei
Die zur Simulationsumgebung gehorende Konfigurationsdatei
Dateiname.parameters
beschreibt einige wesentliche Parameter des Testfahrzeugs und des zu tes-tenden Assistenzsystems. Als Parameter des Testfahrzeugs wird das in [EC,1970] definierte Sichtfeld der
� Innenruckspiegel
– Sichtfeldbreite auf Fahrbahnebene
– Beginn des Sichtfeldes auf Fahrbahnebene
– Sichtweite hinter dem Fahrzeug
� Außenruckspiegel auf Fahrer- und Beifahrerseite
– Minimale und maximale Sichtfeldbreite auf Fahrbahnebene
– Beginn des Sichtfeldes auf Fahrbahnebene
– Sichtweite hinter dem Fahrzeug
beschrieben. Daruber hinaus enthalt die Datei Parameter, die das Assis-tenzsystem charakterisieren, derzeit ist jedoch nur die maximal vom As-sistenzsystem aufzubringende Verzogerung decMax gespeichert.
<parameters >
<FieldOfVision >
<IntMirrorDist >60</ IntMirrorDist >
<IntMirrorWidth >20.0 </ IntMirrorWidth >
<ExtMirrorMinDist >4.0</ ExtMirrorMinDist >
<ExtMirrorMaxDist >20.0 </ ExtMirrorMaxDist >
<ExtMirrorMinWidth >1.0</ ExtMirrorMinWidth >
<ExtMirrorMaxWidth >4.0</ ExtMirrorMaxWidth >
<IntMirrorRange >200.0 </ IntMirrorRange >
<ExtMirrorRange >200.0 </ ExtMirrorRange >
<EyeLine >1</EyeLine >
</FieldOfVision >
<DriverAssistanceSystem >
<decMax >-4</decMax >
</DriverAssistanceSystem >
</parameters >
117
A Anhang
A.7 Messwerte Spurwechselmanover
Die vollstandigen Messwerte der Spurwechselmanover zeigt Tabelle A.1.
Tabelle A.1: Ergebnis der Messungen zur Generierbarkeit fur alle Spur-wechselmanover
KSoll Messung ∆Dmin[m] K ∆K f [%]
0.10 1 22.82 0.101 0.001 0.644
0.10 2 22.60 0.102 0.002 1.972
0.10 3 22.70 0.099 -0.001 -1.420
0.10 4 22.69 0.093 -0.007 -6.863
0.10 5 22.73 0.092 -0.008 -8.179
0.20 1 20.59 0.200 0.000 0.000
0.20 2 20.51 0.205 0.005 2.450
0.20 3 20.50 0.206 0.006 3.200
0.20 4 20.68 0.198 -0.002 -1.100
0.20 5 20.69 0.196 -0.004 -1.900
0.30 1 18.44 0.291 -0.009 -2.845
0.30 2 18.36 0.294 -0.006 -1.913
0.30 3 18.61 0.287 -0.013 -4.483
0.30 4 18.06 0.313 0.013 4.442
0.30 5 18.54 0.302 0.002 0.623
0.40 1 16.12 0.397 -0.003 -0.855
0.40 2 15.98 0.411 0.011 2.778
0.40 3 16.23 0.399 -0.001 -0.192
0.40 4 16.42 0.390 -0.010 -2.449
0.40 5 16.43 0.390 -0.010 -2.450
Fortsetzung nachste Seite
118
A.7 Messwerte Spurwechselmanover
KSoll Messung ∆Dmin[m] K ∆K f [%]
0.50 1 13.90 0.509 0.009 1.722
0.50 2 14.14 0.498 -0.002 -0.377
0.50 3 14.05 0.489 -0.011 -2.244
0.50 4 13.57 0.516 0.016 3.293
0.50 5 13.80 0.504 0.004 0.747
0.60 1 11.55 0.608 0.008 1.312
0.60 2 12.04 0.589 -0.011 -1.795
0.60 3 11.57 0.611 0.011 1.780
0.60 4 11.66 0.607 0.007 1.174
0.60 5 11.72 0.604 0.004 0.639
0.70 1 8.97 0.723 0.023 3.335
0.70 2 8.89 0.727 0.027 3.789
0.70 3 9.32 0.706 0.006 0.867
0.70 4 8.95 0.724 0.024 3.371
0.70 5 9.19 0.712 0.012 1.758
0.80 1 7.15 0.808 0.008 0.984
0.80 2 7.69 0.783 -0.017 -2.140
0.80 3 7.37 0.798 -0.002 -0.293
0.80 4 7.16 0.807 0.007 0.890
0.80 5 7.48 0.792 -0.008 -1.025
0.90 1 5.66 0.876 -0.024 -2.681
0.90 2 5.55 0.883 -0.017 -1.889
0.90 3 5.10 0.901 0.001 0.066
0.90 4 5.13 0.900 -0.000 -0.042
0.90 5 5.64 0.877 -0.023 -2.558
119
A Anhang
A.8 Messwerte Bremsmanover
Die vollstandigen Messwerte der Bremsmanover zeigt Tabelle A.2.
Tabelle A.2: Ergebnis der Messungen zur Generierbarkeit fur alle Brems-manover
KSoll Messung ∆Dmin[m] K ∆K f [%]
0.10 1 5.68 0.107 0.007 7.000
0.10 2 5.67 0.110 0.010 10.300
0.10 3 5.71 0.097 -0.003 -3.000
0.10 4 5.72 0.094 -0.006 -6.300
0.10 5 5.74 0.087 -0.013 -13.000
0.20 1 5.38 0.207 0.007 3.500
0.20 2 5.38 0.207 0.007 3.500
0.20 3 5.46 0.180 -0.020 -9.850
0.20 4 5.36 0.214 0.014 6.850
0.20 5 5.45 0.184 -0.016 -8.150
0.30 1 5.16 0.280 -0.020 -6.667
0.30 2 5.09 0.303 0.003 1.100
0.30 3 5.18 0.273 -0.027 -8.900
0.30 4 4.93 0.357 0.057 18.900
0.30 5 5.09 0.303 0.003 1.100
0.40 1 4.84 0.387 -0.013 -3.325
0.40 2 4.86 0.380 -0.020 -5.000
0.40 3 4.83 0.390 -0.010 -2.500
0.40 4 4.77 0.410 0.010 2.500
0.40 5 4.80 0.400 0.000 0.000
Fortsetzung nachste Seite
120
A.8 Messwerte Bremsmanover
KSoll Messung ∆Dmin[m] K ∆K f [%]
0.50 1 4.61 0.463 -0.037 -7.340
0.50 2 4.55 0.483 -0.017 -3.340
0.50 3 4.59 0.470 -0.030 -6.000
0.50 4 4.50 0.500 0.000 0.000
0.50 5 4.46 0.513 0.013 2.660
0.60 1 4.21 0.597 -0.003 -0.550
0.60 2 4.20 0.600 0.000 0.000
0.60 3 4.21 0.597 -0.003 -0.550
0.60 4 4.24 0.587 -0.013 -2.217
0.60 5 4.18 0.607 0.007 1.117
0.70 1 3.77 0.743 0.043 6.186
0.70 2 3.99 0.670 -0.030 -4.286
0.70 3 3.84 0.720 0.020 2.857
0.70 4 3.76 0.747 0.047 6.671
0.70 5 3.88 0.707 0.007 0.957
0.80 1 3.66 0.780 -0.020 -2.500
0.80 2 3.67 0.777 -0.023 -2.913
0.80 3 3.51 0.830 0.030 3.750
0.80 4 3.49 0.837 0.037 4.588
0.80 5 3.42 0.860 0.060 7.500
0.90 1 3.33 0.890 -0.010 -1.111
0.90 2 3.40 0.867 -0.033 -3.700
0.90 3 3.28 0.907 0.007 0.744
0.90 4 3.27 0.910 0.010 1.111
0.90 5 3.30 0.900 0.000 0.000
121
A Anhang
A.9 CAN-Botschaften
Tabelle A.3 zeigt die vollstandige Liste der vom CAN-Modul (vgl. Ab-schnitt 5.4) gesendeten und empfangenen Botschaften.
Tabelle A.3: Gesendete und empfangene CAN-Botschaften
Botschaft Inhalt Empfanger
257 Zielbeschleunigung StauassistentEigenbeschleunigungZieldifferenzbeschleunigungZielabstand
258 Getriebeubersetzung StauassistentFahrerwunschmomentMotormomentInneres Sollmoment
259 Minimales Motormoment StauassistentMotorverlustmomentWandlerverlustmomentZielgeschwindigkeit
260 ALFa aktiv StauassistentALF eingeschaltetBremspedal aktivFahrpedal aktivGang eingelegtSchaltung aktivStillstandTempomat setzenTempomat aktivZielobjekt vorhandenEigengeschwindigkeitZieldifferenzgeschwindigkeitWunschgeschwindigkeit
a Automatische LangsfuhrungFortsetzung nachste Seite
122
A.9 CAN-Botschaften
Botschaft Inhalt Empfanger
262 Querabweichung SpurhalteassistentGierwinkelfehlerKrummungSpurbreite
513 Momentanforderung TestfahrzeugVerzogerungsanforderungMotoreingriffBremseingriff
514 Lenkmoment Testfahrzeug
657 Lenkwinkel Adaptive LichtsteuerungGeschwindigkeitGute Spurerkennung SpurhalteassistentMaximale Verzogerungsanforderung Stauassistent
123
A Anhang
A.10 Bilder
Dieser Abschnitt enthalt Bilder und Fotos zu den verschiedenen – im Textbeschriebenen – Anwendungen.
Abbildung A.2 zeigt den Laboraufbau beim Projektpartner AEV. Sicht-bar sind die Visualisierung der Umweltsimulation auf dem Bildschirm desLaptops, der VN 3600 FlexRay Knoten, ein Lenkrad zur Steuerung desTestfahrzeugs sowie der DECOS FlexRay Cluster.
In Abbildung A.3 ist das Blockschaltbild des Simulink Modells dargestellt,das beim Projektpartner AEV genutzt wurde, um Model-in-the-Loop-Testsmit der Simulationsumgebung in PRAETORIA durchzufuhren.
Die Abbildung A.4 zeigt das DECOS-FlexRay-Cluster bestuckt mit vierFlexRay-Knoten. Zum Betrieb des funften Knotens ist ein zusatzlichesGehause erforderlich, das nicht mit abgebildet ist.
Abbildung A.2: Laboraufbau beim Projektpartner AEV
124
A.10 Bilder
Änd
erun
gen
für U
NIK
Eni
ronm
ent
:- H
C1:
alte
Ver
sion
des
GW
F- H
C2:
Lim
its: 2
.0/-2
.0- H
C2:
Low
Pas
s: S
ampl
etim
e -0
.08
- AC
C1: A
CC
_ZV
OR
H a
n "k
ein
Vor
derfz
g" a
nges
chlo
ssen
- vTm
ax a
ls K
onst
ante
auf
12
0
Envi
ronm
ent S
imul
atio
nSi
mul
atio
n of
a d
istr
ibut
ed A
CC
and
HC
Har
dwar
e Ti
min
g Si
mul
atio
n
Sim
ulat
ion
of C
omm
unic
atio
n
Slot
5 (e
mpt
y)
func
tion(
)
Slot
4
func
tion(
)
In1<
Li>
Out
1
Slot
3
func
tion(
)
In1<
Li>
Out
1
Slot
2
func
tion(
)In
1<Li
>
In2<
Li>
Out
1
Out
2
Slot
1
func
tion(
)In
1<Li
>
In2<
Li>
Out
1
Out
2
S-Fu
nctio
n
Stee
ringF
cn
Nod
e4
parti
tion_
AC
C_A
CC
4()
Nod
e3
parti
tion_
AC
C_A
CC
3()
Nod
e2
parti
tion_
AC
C_A
CC
2()
parti
tion_
HC
_HC
2()
Nod
e1
parti
tion_
AC
C_A
CC
1()
parti
tion_
HC
_HC
1()
Mem
ory
2
MPI
Clie
nt
Sim
ulat
ions
date
nban
k
ACC_
MO
M_A
NF
ACC_
VER
Z_AN
F
ACC_
MO
TOR
ACC_
BREM
S
HC
_LM
ACC
_FAH
RPE
DAC
C_B
REM
SPED
ACC_
VWU
NSC
HAC
C_G
RA_
AKT
ACC_
GR
A_SE
TAC
C_AL
F_EN
ACC_
ALF_
AKT
ACC_
MO
TOR
MAC
C_M
OTO
RV
ACC
_MSO
LLIN
ACC_
MIN
MO
TMAC
C_M
FWU
NSC
HAC
C_VE
RZM
INAC
C_M
OM
MAX
ACC
_WAN
DLV
ACC_
UEB
ERS
ACC
_GAN
GAC
C_S
CH
ALT_
AKT
ACC_
VEIG
ENAC
C_AE
IGEN
ACC_
STIL
LST
ACC_
ZVO
RH
ACC_
ZDIS
TAC
C_ZV
ACC_
ZVD
IFF
ACC_
ZAAC
C_ZA
DIF
FH
C_Q
ABW
HC
_QG
WF
HC
_KR
MH
C_S
PBR
HC
_GTE
HC
_V_M
PSO
BS1_
VDES
VUT_
DO
BS_1
_D
HC
2
HC
2
HC
1
HC
1
[EN
V]
[AC
C3]
[AC
C2]
[AC
C1]
[HC
2]
[HC
1]
[AC
C4]
[HC
2]
[HC
1]
[EN
V]
[EN
V]
[EN
V]
[EN
V]
[EN
V]
[EN
V]
[AC
C4]
[AC
C4]
[AC
C3]
[AC
C3]
[AC
C3]
[AC
C2]
[AC
C2]
[AC
C1]
[AC
C1]
Con
vert
bool
ean
bool
ean
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
Con
vert
25
00
Clu
ster
Sch
edul
e
Slo
t1
Slo
t2
Slo
t3
Slo
t4
Slo
t5
AC
C4
AC
C4
AC
C3
AC
C3
AC
C2
AC
C2
AC
C1
AC
C1
LM_N
m_o
ut
<MM
o_so
ll>
<Mot
orei
ngrif
f>
<Bre
mse
ingr
iff>
<aB
A_so
ll>
<MM
o>
<MM
o_b
egr>
<iAS
>
<dx_
ist>
<vT
_ist
>
<aT_
ist>
<ALF
_Abs
tand
_rel
ativ
>
<ALF
_Abs
tand
_eig
en>
<ALF
_Ges
chw
indi
gkei
t_eig
en>
<dx_
idea
l>
<vT
_ide
al>
<aT_
idea
l>
<rT_
idea
l>
<RK
_hol
d>
<RK
_ena
ble>
F_R
eg
Bre
mse
ingr
iff
Mot
orei
ngrif
f
aBA
_sol
l
MM
o_so
ll
<aT_
RF
_Rel
ativ
>
<vT
_max
>
<Gas
peda
l>
<aT_
RF
_Ges
chw
>
<vT
_ist
>
<aT_
RF
_Abs
tand
>
ALF
_Anf
ahre
n_g
este
uert
ALF
_Bre
mse
_loe
sen
ALF
_Stil
lsta
nd
ALF
_Abs
tand
_rel
ativ
ALF
_Abs
tand
_eig
en
ALF
_Ges
chw
indi
gkei
t_eig
en
TG_r
efre
sh
TG_e
nabl
e
RK
_ena
ble
<F_R
eg>
<vT
_max
>
<vx
_ist
>
<TG
_ena
ble>
<TG
_ref
resh
>
aT_R
F_R
elat
iv
aT_R
F_G
esch
w
aT_R
F_A
bsta
nd
rT_i
deal
dx_i
deal
aT_i
deal
vT_i
deal
<aT_
ist>
<vT
_ist
>
<dx_
ist>
<vP
_ist
>
<aP
_ist
>
<ALF
_Ges
chw
indi
gkei
t_eig
en>
<ALF
_Abs
tand
_eig
en>
<ALF
_Abs
tand
_rel
ativ
>
<ALF
_Stil
lsta
nd>
<ALF
_Bre
mse
_loe
sen>
<ALF
_Anf
ahre
n_g
este
uert>
<Bre
msp
edal
>
<aT_
idea
l>
RK
_hol
d
<MM
o_s
oll>
<Mom
_Anf
_Fah
rer>
<Fah
rped
al>
MM
o_be
grM
Mo_
begr
<Que
rabw
eich
ung_
m>
EN
V<G
ierw
inke
lfehl
er>
<Gue
te_S
pure
rken
nung
>
Que
rabw
eich
ung_
Vora
us_m
Que
rabw
eich
ung_
Vora
us_m
LM_N
m_o
ut
Gas
peda
lG
aspe
dal
Fahr
peda
l
Bre
msp
edal
vT_m
ax
Tem
pom
at
Tem
pom
at_se
tzen
ALF
_ena
ble
ALF
_akt
iv
MM
o
MM
o_VM
Mm
otB
egrG
etr
Mm
otB
egrM
ot
Mom
_Anf
_Fah
rer
aBA_
soll_
min
MM
o_so
ll_m
ax
MM
_Wan
dl_V
MM
M_W
andl
_VM
iAS
iAS
Gan
g_ei
ngel
egt
Sch
altu
ng
vT_i
st
aT_i
st
Stil
lsta
nd
Ziel
obje
kt_v
orha
nden
dx_i
st
vP_i
st
vx_i
st
aP_i
st
ax_i
st
Que
rabw
eich
ung_
m
Gie
rwin
kelfe
hler
Kru
emm
ung_
1pm
Spu
rbre
ite_m
Gue
te_S
pure
rken
nung
HC
_vT
_ist
VUT
_D
OB
S_1D
<vT
_ist
>
<Zie
lobj
ekt_
vorh
ande
n>
Gas
peda
l
Abbildung A.3: Simulink Blockschaltbild beim Projektpartner AEV
125
A Anhang
Abbildung A.4: DECOS FlexRay Cluster
Abbildung A.5 stellt den Versuchsaufbau der HiL-Umgebung dar. Erkenn-bar sind der Bedien-PC, auf dem PRAETORIA und die Versuchsbedie-nung ausgefuhrt werden, das Lenkrad zur Steuerung des Testfahrzeugs,der DECOS-Cluster, der HiL-Rechner (bestehend aus VME-Rechner, zweiESUs, einem I/O-Subsystem und einem Netztteil) im Gehause sowie derFrontscheinwerfer.
126
A.10 Bilder
Abbildung A.5: HiL Versuchsaufbau
127
A Anhang
A.11 simenv-Datei fur STA-Test
<simenv >
<simvisualisation >
<assetsdb >../../ assets/default.assetsdb </assetsdb >
</simvisualisation >
<simroad >
<road >[...]/ rundkurslG.road </road >
<bsptrack texture ="road3 " >[...]/ rundkurslG.bsptrack
</bsptrack >
<terrain texture =""></terrain >
<sky ></sky >
</simroad >
<simvut >
<carts_prefix >VUT </ carts_prefix >
<sensors >../../ sensors/cos.sensors </sensors >
<parameters >../../ parameters/christian.parameters
</parameters >
<cage >../../ cages/touareg.cage </cage >
<driver >../../ drivers/christian.driver </driver >
<asset bodytexture =" t_red_lr"
tiretexture =" t_t_lr">touareg </asset >
<lane0 >-2</lane0 >
<D0 >-100</D0>
<vSet_kmh >100</ vSet_kmh >
</simvut >
<simobjects >
<carts_prefix >OBS </ carts_prefix >
<simobject >
<cage >../../ cages/a8.cage </cage >
<driver >../../ drivers/christian2.driver </driver >
<asset bodytexture =" a8_gn_lr"
tiretexture =" a8_t_lr">a8 </asset >
<lane0 >-2</lane0 >
<D0 >50</D0>
<vSet_kmh >50</ vSet_kmh >
<auto_place >0</auto_place >
<situation >
<type >Brake </type >
<criticality >0.9</ criticality >
</situation >
[...]
128
A.11 simenv-Datei fur STA-Test
</simobject >
</simobjects >
</simenv >
129
Literaturverzeichnis
[Angelow 2007] Angelow, Harald: FPGA Update with FlexRay used asCommunication Protocol - DECOS Deliverable D3.2.6. Wien, 2007. –Forschungsbericht
[Ayeb u. a. 2007a] Ayeb, Mohamed ; Schmidt, Carsten ; Schmidt, Chris-tian: Update of the HiL Simulator - DECOS Deliverable D5.6.1. Kassel,2007. – Forschungsbericht
[Ayeb u. Schmidt 2005] Ayeb, Mohamed ; Schmidt, Christian: SimulatorSpecification - DECOS Deliverable 5.2.1. Kassel, 2005. – Forschungsbe-richt
[Ayeb u. Schmidt 2006] Ayeb, Mohamed ; Schmidt, Christian: Veri-fication results of the scenario generator at the HiL bench - DECOSDeliverable D5.3.1. Kassel, 2006. – Forschungsbericht
[Ayeb u. a. 2007b] Ayeb, Mohamed ; Schmidt, Christian ; Tellmann,Dirk: Report on technology validation - HIL - DECOS DeliverableD5.5.1. Kassel, 2007. – Forschungsbericht
[Basten u. Braschel 2003] Basten, Mark ; Braschel, Volker: TRW Au-tocruise Driver Assistance Systems Presentation
[Bock u. a. 2005] Bock, Th. ; Siedersberger, K.-H. ; Zavrel, M. ; Breu,A. ; Maurer, M.: Simulations- und Testumgebung fur Fahrerassistenz-systeme - Vehicle in the Loop. In: VDI (Hrsg.): Erprobung und Simula-tion in der Fahrzeugentwicklung - Mess- und Versuchstechnik Bd. 1900.Dusseldorf : VDI Verlag, 2005
[Bosch 1991] Bosch: CAN Specification Version 2.0. www.can.bosch.de,1991
[Brabetz 2007] Brabetz, Ludwig: Elektrische und elektronische Systemim Automobil - Vorlesung. Kassel, 2007
131
Literaturverzeichnis
[Breuer 2004] Breuer, Bert: Bremsenhandbuch: Grundlagen, Komponen-ten, Systeme, Fahrdynamik. 2. Auflage. Wiesbaden : Vieweg, 2004. –XXIII, 416 S. – ISBN 3–528–13952–8
[Burckhardt 1985] Burckhardt, Manfred: Reaktionszeiten bei Notbrems-vorgangen. Koln : Verlag TUV Rheinland, 1985. – ISBN 3–88585–267–6
[Burckhardt 1993] Burckhardt, Manfred: Der Uberholvorgang. In: Ver-kehrsunfall und Fahrzeugtechnik (1993), Nr. 11, S. 313–318
[EC 1970] EC: Richtlinie 70/156/EWG des Rates - zur Angleichungvon Rechstvorschriften der Mitgliedsstaaten uber die Betriebser-laubnis fur Kraftfahrzeuge und Kraftfahrzeuganhanger. 1970 http:
//eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:
1970L0156:19980414:DE:PDF
[Forschungsgesellschaft fur Straßen- und Verkehrswesen 1996] For-schungsgesellschaft fur Straßen- und Verkehrswesen: Richt-linien fur die Anlage von Straßen - Querschnitte - RAS-Q. Ausg. Koln: Forschungsges. fur Strassen- und Verkehrswesen, 1996. – 58 S.
[Frunzke 2007] Frunzke, Thorsten: Update of HiL and SiL Demonstrator- DECOS Deliverable 5.6.1. 2007. – Forschungsbericht
[Gietelink u. a. 2004] Gietelink, O. ; Ploeg, J. ; De Schutter, B. ;Verhagen, M.: Testing advanced driver assistance systems for daultmanagement with the VEHIL test facility. In: 7th International Sympo-sium on Advanced Vehicle Control (AVEC 04). Arnhem, 2004, S. 579 –584
[Grabel 2007] Grabel, Patrick: Entwicklung und Implementierung einesCo-Simulationsansatzes fur eine verteilte Software-in-the-Loop Simula-tionsumgebung. Kassel, Universitat Kassel, Diplomarbeit, 2007
[Gruber 2004] Gruber, Manfred: DECOS Project Proposal. Wien, 2004.– Forschungsbericht
[Hentschel u. Konig 2007] Hentschel, Peter ; Konig, Peter:Straßenverkehrsrecht: Straßenverkehrsgesetz, Straßenverkehrs-Ordnung, Fahrerlaubnis-Verordnung, Fahrzeug-Zulassungsverordnung,Straßenverkehrs-Zulassungs-Ordnung, Bußgeldkatalog, Gesetzesmate-rialien, Verwaltungsvorschriften und einschlagige Bestimmungen. 39.
132
Literaturverzeichnis
Munchen : Beck, 2007. – XX, 1655 S. – ISBN 978–3–406–55478–03–406–55478–4
[Holler 2005] Holler, Dominik: Modellierung dreidimensionaler Straßen-verlaufe zum Einsatz in Echtzeitsimulationen. Kassel, Universitat Kas-sel, Diplomarbeit, 2005
[Hufeld 2006] Hufeld, Knut: Conception for components - SP3 SiliconInfrastructure - DECOS Deliverable D3.1.4. Munchen, 2006. – For-schungsbericht
[Hugemann 2002] Hugemann, Wolfgang: Driver Reaction Times in RoadTraffic. In: EVU annual conference. Portoroz, Slovenia, 2002
[Jansson 2004] Jansson, Jonas: Dealing with Uncertainty in Automo-tive Collision Avoidance. In: Valldorf, Jurgen (Hrsg.) ; Gessner,Wolfgang (Hrsg.): Advanced Microsystems for Automotive ApplicationsAMAA 2004, Springer, 2004
[Kant 2004] Kant, Dietmar: Requirement Specification and Descriptionof State of the Art, 1st draft - DECOS Deliverable D5.1.1. Ingolstadt,2004. (DECOS). – Forschungsbericht
[Kopetz u. a. 2003] Kopetz, H. ; Obermaisser, R. ; Peti, P. ; Suri,N.: From a federated to an integrated architecture for dependable real-time embedded systems. Vienna, Austria; Darmstadt, Germany, 2003.– Forschungsbericht
[Mitschke u. a. 1982] Mitschke, M. ; Arand, W. ; Braun, Horst ; Kup-ke, Peter ; Ihme, Joachim ; Maus, Dieter ; Schlichting, Klaus-Dieter:Definition kritischer Situationen im Kraftfahrzeugverkehr - Abschlussbe-richt zum Forschungsprojekt 8014 der Bundesanstalt fur Straßenwesen.1982. – Forschungsbericht
[Mitschke u. Wallentowitz 2004] Mitschke, Manfred ; Wallentowitz,Henning: Dynamik der Kraftfahrzeuge. Springer, 2004. – ISBN 3–540–42011–8
[Normenausschuß Kraftfahrzeuge (FAKRA) 1994] NormenausschußKraftfahrzeuge (FAKRA): DIN 70000 - Straßenfahrzeuge - Fahr-zeugdynamik und Fahrverhalten - Begriffe. Beuth Verlag, 1994
133
Literaturverzeichnis
[Pataricza 2007] Pataricza, Andras: PIM Metamodel (final version) -DECOS Deliverable D1.1.6. Budapest, 2007. – Forschungsbericht
[Salvucci u. Liu 2002] Salvucci, Dario D. ; Liu, Andrew: The time courseof a lane change: Driver control and eye-movement behavior, 2002
[Schick u. a. 2007] Schick, Bernhard ; Buttner, Rolf ; Baltruschat,Klaus ; Meier, Gunther ; Jakob, Heiko: Bewertung der Funktion undGute von Fahrerassistenzsystemen bei aktivem Bremseingriff. In: Auto-mobiltechnische Zeitschrift (2007), Nr. 05/2007, S. 414–425
[Schmidt 2010] Schmidt, Carsten: Hardware-in-the-Loop gestutzte Ent-wicklungsplattform fur Fahrerassistenzsysteme - Modellierung und Vi-sualisierung des Fahrzeugumfeldes. Kassel, Universitat Kassel, Diss.,2010
[Schmidt 2003] Schmidt, Christian: Studie Systemarchitektur Fahreras-sistenzsysteme. Kassel, 2003. – Forschungsbericht
[Schmidt 2004] Schmidt, Christian: Vergleichende Untersuchung zu kom-merziell verfugbaren Simulationswerkzeugen fur die Fahrdynamik- undVerkehrssimulation. Kassel, 2004. – Forschungsbericht
[Schauffele u. Zurawka 2006] Schauffele, Jorg ; Zurawka, Thomas: Au-tomotive Software Engineering - Grundlagen, Prozesse, Methoden undWerkzeuge effizient einsetzen. 3. Auflage. Wiesbaden : Vieweg, 2006(ATZ/MTZ Fachbuch). – ISBN 3–83480051–1
[Statistisches Bundesamt 2002] Statistisches Bundesamt: Fachserie 8,Reihe 7. Bd. 2002: Verkehr - Verkehrsunfalle. 2002
[Statistisches Bundesamt 2006] Statistisches Bundesamt: Fachserie 8,Reihe 7. Bd. 2006: Verkehr - Verkehrsunfalle. 2006
[Tellmann 2010] Tellmann, Dirk: Hardware-in-the-Loop gestutzte Ent-wicklungsplattform fur Fahrerassistenzsysteme - Modelle der Umfeldsen-sorik und angepasste Fahrermodelle. Kassel, Universitat Kassel, Diss.,2010
[Theuerkauf 2005] Theuerkauf, Heinz: Elektronik im Fahrzeug - Prufungund Simulation - Vorlesung
134
Literaturverzeichnis
[TTTech Computertechnik AG 2003] TTTech Computertechnik AG:TTP - Time-Triggered Protocol TTP/C High-Level Specification Docu-ment Protocol Version 1.1
[Vector Informatik 2006] Vector Informatik: User Manual XL DriverLibrary - API Description, Version 5.7. Stuttgart, 2006
[Verburg u. a. 2002] Verburg, Dirk J. ; Knaap, Albert C. M. d. ; Ploeg,Jeroen: VEHIL - Developing and Testing Intelligent Vehicles. In: IEEEIntelligent Vehicle Symposium IV02. Versailles, 2002
[Wang 2000] Wang, Hongling: An analytical solution for free-form Roadsin Driving Simulation. 2000. – Forschungsbericht
[Zomotor 1991] Zomotor, Adam: Fahrwerktechnik: Fahrverhalten. 2.Auflage. 1991. – 392 S. – ISBN 3–8023–0774–7
135
ISBN 978-3-86129-004-1
Christian Schmidt
Hardware-in-the-Loop gestützte Entwicklungs- plattform für Fahrerassistenzsysteme
Analyse und Generierung kritischer Verkehrsszenarien
Chris
tian
Schm
idt
Har
dwar
e-in
-the-
Loop
ges
tütz
te E
ntw
ickl
ungs
plat
tform
für F
ahre
rass
iste
nzsy
stem
e
top related