Hardware-in-the-Loop gestützte Entwicklungs- plattform … · 1.3 Anforderungen an die Simulationsumgebung. . . . . . . . . 6 ... 1.2 Struktur der Simulationsumgebung ... 5.4 Zustandsautomat

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

http://dnb.ddb.de/

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.


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


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])


Stau-assistent


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




PL MFR4300 Board

PL TC1796 BoardFX Connector



PL MFR4300 Board




PL MFR4300 Board




PL MFR4300 Board




PL MFR4300 Board


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


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


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


Stau-assistent


Spurhalte-assistent

FlexRay

Knoten 5

Tür- steuerung

L-FX DECOS Node


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


Node2


partition_HC_HC2()

Node1


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


Δ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


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.


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


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


Δ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


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


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


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


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


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


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


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) +


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) +


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


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


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.


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


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


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


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


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


Spurhalte-assistent

FlexRay

Knoten 5Tür- steuerung

DECOS Cluster

L-FX DECOS Node


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


Spurhalte-assistent

FlexRay


DECOS Cluster

CAN

L-FX DECOS Node


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


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


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


– 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


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


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


Knoten 1 Knoten 2 Knoten 3 Knoten 4Stau-assistent


Spurhalte-assistent

FlexRay


DECOS Cluster

L-FX DECOS Node


L-FX DECOS Node

L-FX DECOS Node

L-FX DECOS Node

L-FX DECOS Node

CARTS HiL

Verkehr

Sensoren


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


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.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


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:


� Geschwindigkeit des Hindernisfahrzeugs vObs = 50 km/h ≈ 13,89 m/s


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


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


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


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


Tabelle 6.2: Ergebnis der Messungen zur Reproduzierbarkeit fur ein Spur-wechselmanover mit K = 0,9


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.2.2 Bremsmanover

Das Kapitel beschreibt Messergebnisse von Bremsmanovern, mit denen einStauassistent untersucht wurde. Folgende Randbedingungen gelten fur alledurchgefuhrten Messungen:


� 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


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:


91


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


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


Tabelle 6.4: Ergebnis der Messungen zur Reproduzierbarkeit fur einBremsmanover mit K = 0,5


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


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


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


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


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


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


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


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


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.


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


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


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


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


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


[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

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:1970L0156:19980414:DE:PDF




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


[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


[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

Documents

Hardware-in-the-Loop gestützte Entwicklungs- plattform … · 1.3 Anforderungen an die Simulationsumgebung. . . . . . . . . 6 ... 1.2 Struktur der Simulationsumgebung ... 5.4 Zustandsautomat