Deliverable D41.1 Versuchsplan 1€¦ · Daniel Handke – Stadt Frankfurt am Main (FFM) Dominik Mühlbacher –Interdisziplinäres Zentrum für Verkehrswissenschaften an der Univer-sität

Deliverable D41.1

Versuchsplan 1.0

Version 3.0

Verbreitung Öffentlich

Projektkoordination Daimler AG

Versionsdatum 28.06.2010

simTD wird gefördert und unterstützt durch

Bundesministerium für Wirtschaft und Technologie Bundesministerium für Bildung und Forschung Bundesministerium für Verkehr, Bau und Stadtentwicklung

Sichere Intelligente Mobilität Testfeld Deutschland

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite ii

Dieses Dokument wurde erstellt vom Interdisziplinären Zentrum für Verkehrswissenschaften (IZVW) an der Universität Würzburg

Beiträge wurden verfasst von

Ingo Totzke – Universität Würzburg – Interdisziplinäres Zentrum für Verkehrswissenschaften (IZVW; Redaktion und Rahmenkapitel)

Benjamin Kentsch – Hessisches Landesamt für Straßen- und Verkehrswesen (HLSV)

Christian Schlotter – Hessisches Landesamt für Straßen- und Verkehrswesen (HLSV)

Daniel Handke – Stadt Frankfurt am Main (FFM)

Dominik Mühlbacher –Interdisziplinäres Zentrum für Verkehrswissenschaften an der Univer-sität Würzburg (IZVW)

Dorothee Allekotte – Stadt Frankfurt am Main (FFM)

Florian Fischer –Interdisziplinäres Zentrum für Verkehrswissenschaften an der Universität Würzburg (IZVW)

Florian Schimandl – Technische Universität München – Verkehrstechnik (TUM-VT)

Horst Rechner – FhG-Fokus

Jens Zech – TU Berlin

Julia Müller – Technische Universität München – Verkehrstechnik (TUM-VT)

Jürgen Großmann – FhG-Fokus

Marco Petrick – Adam Opel GmbH

Martin Goralczyk – TU Berlin

Mathias Baur – Technische Universität München – Verkehrstechnik (TUM-VT)

Michael Stein – Stadt Frankfurt am Main (FFM)

Nadja Lich – Stadt Frankfurt am Main (FFM)

Rita Jakoby – Albert Speer & Partner GmbH (AS&P)

Robert Braun – Technische Universität München – Verkehrstechnik (TUM-VT)

Sandra Kleinau – Volkswagen AG

Silja Hoffmann – Technische Universität München – Verkehrstechnik (TUM-VT)

Susanne Buld – Interdisziplinäres Zentrum für Verkehrswissenschaften an der Universität Würzburg (IZVW)

Thomas Hecker – TU Berlin

Turhan Batur – Adam Opel GmbH

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite iii

Projektkoordination

Dr. Christian Weiß

Daimler AG

HPC 050 – G021

71059 Sindelfingen

Germany

Telefon +49 7031 4389 550

Fax +49 7031 4389 210

E-mail [email protected]

Das simTD Konsortium übernimmt keinerlei Haftung in Bezug auf die veröffentlichten Deliverables. Änderungen sind ohne Ankündigung möglich. © Copyright 2010 simTD Konsortium

The simTD consortium will not be liable for any use of the published deliverables. Contents are subject to change without notice. © Copyright 2010 simTD consortium

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite iv

Inhaltsverzeichnis Zusammenfassung ................................................................................................................... 1

English summary ...................................................................................................................... 2

1 Einleitung .......................................................................................................................... 3

1.1 Zielsetzung des Deliverable D41.1 ......................................................................... 3

1.2 Überblick über dieses Dokument ........................................................................... 4

1.3 Einbettung von D41.1 in das Projekt simTD ............................................................ 4

1.3.1 TP-übergreifende Einbettung .............................................................................. 4

1.3.2 TP-interne Einbettung ......................................................................................... 5

2 Prüfkonzept 1.0 ................................................................................................................ 6

2.1 Ausgangspunkt Deliverable D13.2 ......................................................................... 6

2.1.1 Nicht-technische Test- und Versuchsfälle .......................................................... 6

2.1.2 Technische Test- und Versuchsfälle ................................................................. 17

2.2 Möglichkeiten und Grenzen der Versuchsumgebungen ...................................... 23

2.2.1 Feldversuch: Versuchsgebiet und Testgelände ................................................ 23

2.2.2 Fahrsimulation .................................................................................................. 25

2.2.3 Verkehrssimulation ........................................................................................... 25

2.3 Durchführbarkeit von Versuchsfällen bei Eingriff in den Straßenverkehr ............. 26

2.3.1 Allgemeine Zusammenstellung der zu erzeugenden Sondersituationen .......... 26

2.3.2 Rückmeldung der zuständigen Straßenverkehrsbehörde hinsichtlich der Durchführbarkeit ............................................................................................................. 27

2.4 Konzept für die Integration technischer und nicht-technischer Versuchsspezifikationen in den Drehbüchern .................................................................... 30

2.5 Priorisierung technischer und nicht-technischer Versuchsfälle ............................ 31

2.5.1 Priorisierung technische Versuche ................................................................... 31

2.5.2 Priorisierung nicht-technischer Versuche ......................................................... 32

2.5.3 Priorisierung technischer und nicht-technischer Versuchsfälle aus TP5-Sicht . 35

2.6 Methodologische Betrachtung: Versuchsmethodik .............................................. 36

2.6.1 Versuchsmethodik ............................................................................................ 37

2.6.2 Methodische Hinweise zur Versuchsplanung ................................................... 38

2.6.3 Methodische Hinweise zur Ergebnisinterpretation ............................................ 43

2.6.4 Beispielrechnungen für optimale Stichprobengröße ......................................... 46

2.6.5 Zwischenfazit .................................................................................................... 51

2.7 Verkehrslageermittlung in Abhängigkeit der Fahrzeugzahl .................................. 52

2.7.1 Verbesserte Verkehrslageermittlung für das städtische Versuchsgebiet ......... 52

2.7.2 Verbesserte Verkehrslageermittlung für das Versuchsgebiet des Landes Hessen in Abhängigkeit der Fahrzeugzahl ..................................................................... 54

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite v

3 Versuchsgebiet ............................................................................................................... 56

3.1 Planung ITS Roadside Station-Standorte ............................................................ 56

3.1.1 Planung ITS Roadside Stations (IRS) – Standorte für das regionale Versuchsgebiet ............................................................................................................... 56

3.1.2 Planung ITS Roadside Stations (IRS) - Standorte für das städtische Versuchsgebiet ............................................................................................................... 58

3.2 Konzeption Erhebung von Detailinformationen über das Versuchsgebiet ........... 59

3.2.1 Städtisches Versuchsgebiet ............................................................................. 59

3.2.2 Regionaler Bereich ........................................................................................... 61

3.2.3 Beschilderung ................................................................................................... 64

3.3 Videobefahrung des Versuchsgebiets und Bereitstellungstool für die erhobenen Videos 65

3.4 Konzeption Verortung der Versuchsfälle: Auswählen der Versuchsteilgebiete .... 67

4 Testgelände .................................................................................................................... 69

4.1 Allgemeine Anforderungen an das Testgelände .................................................. 69

4.2 Beschreibung des ausgewählten Testgeländes ................................................... 71

5 Konzeption Simulationslabor .......................................................................................... 75

5.1 Beschreibung Fahrsimulation ............................................................................... 75

5.1.1 Fahrsimulator mit Bewegungssystem ............................................................... 76

5.1.2 Statischer Fahrsimulator ................................................................................... 77

5.1.3 Pulksimulation ................................................................................................... 77

5.1.4 Fahrsimulationssoftware SILAB ........................................................................ 78

5.1.5 Anwendungsfälle, die in der Fahrsimulation umgesetzt werden ....................... 80

5.2 Beschreibung Verkehrssimulation ........................................................................ 82

5.2.1 Allgemein .......................................................................................................... 82

5.2.2 Simulationsnetz und Verkehrsnachfrage .......................................................... 83

5.2.3 Verkehrstechnische Infrastruktur ...................................................................... 84

5.2.4 Integration der simTD-Anwendungsfälle ............................................................ 84

5.2.5 Herstellen der Untersuchungssituationen ......................................................... 85

5.2.6 Fahrerverhalten ................................................................................................ 85

5.2.7 Kommunikationsmodellierung ........................................................................... 85

5.2.8 Anwendungsfälle, die in der Verkehrssimulation umgesetzt werden ................ 86

5.3 Zusammenspiel der Simulationsumgebungen im Simulationslabor ..................... 88

6 Versuchsflotten: Übersicht .............................................................................................. 92

6.1 OEM-Testflotte ..................................................................................................... 92

6.2 Interne Flotte ........................................................................................................ 93

6.3 Externe Flotte ....................................................................................................... 94

6.4 Verfügbarkeit der Flotten im Versuchsbetrieb ...................................................... 94

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite vi

7 Interne Flotte .................................................................................................................. 97

7.1 Zielsetzung der internen Flotte ............................................................................. 97

7.1.1 Fahrzeugflotte ................................................................................................... 97

7.1.2 Fahrerkonzepte ................................................................................................. 97

7.2 Umsetzung von Anwendungs- und Versuchsfällen ............................................ 101

7.2.1 Nicht-technische Versuchsfälle in der internen Flotte ..................................... 101

7.2.2 Technische Versuchsfälle in der internen Flotte ............................................. 102

7.2.3 Rechtlich-regulatorische Rahmenbedingungen in Bezug auf die interne Flotte 105

7.3 Anforderungen an interne Flotte ......................................................................... 106

7.3.1 Spezielles Fahrverhalten ................................................................................ 106

7.3.2 Technische Ausstattung der Fahrzeuge ......................................................... 107

7.4 Anforderungen der Datenauswertung ................................................................ 108

8 Externe Flotte ............................................................................................................... 109

8.1 Zielsetzung der externen Flotte .......................................................................... 109

8.2 Umsetzung von Anwendungs- und Versuchsfällen ............................................ 109

8.2.1 Nicht-technische Versuchsfälle in der externen Flotte .................................... 109

8.2.2 Technische Versuchsfälle in der externen Flotte ............................................ 112

8.2.3 Rechtlich-regulatorische Rahmenbedingungen in Bezug auf die externe Flotte 119

8.3 Anforderungen an die externe Flotte .................................................................. 119

8.3.1 Spezielles Fahrverhalten ................................................................................ 119

8.3.2 Auswahl und technische Ausstattung der Fahrzeuge ..................................... 120

8.3.3 Eignung der Fahrer für die externe Flotte ....................................................... 120

8.3.4 Eignung potenzieller lokaler Partner ............................................................... 121

8.3.5 Ideensammlung zur Incentivierung der möglichen Betreiber der externen simTD Flotte 124

8.4 Anforderungen an Datenauswertung ................................................................. 128

9 Betreuung der Versuchsfahrer ..................................................................................... 130

9.1 Anforderungen an den Trainingsbedarf der Fahrer ............................................ 130

9.1.1 Pragmatische Überlegungen zur Fahrereinweisung ....................................... 130

9.1.2 Empfehlung zur Fahrereinweisung ................................................................. 130

9.2 Anforderung an den Operator Mensch ............................................................... 131

9.2.1 Beispiele ......................................................................................................... 132

9.2.2 Fazit ................................................................................................................ 133

10 Zusammenspiel simTD-Versuchszentrale und Versuchsflottenstützpunkt .................... 135

10.1 Abgrenzung simTD-Versuchszentrale und Versuchsflottenstützpunkt ................ 135

10.2 Personal und Organigramm ............................................................................... 135

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite vii

10.3 Aufgabenverteilung ............................................................................................ 137

10.4 Anforderungen an den Versuchsflottenstützpunkt ............................................. 139

10.4.1 Räumliche Ausmaße des Versuchsflottenstützpunktes .................................. 139

10.4.2 Ausstattung des Versuchsflottenstützpunktes ................................................ 140

10.4.3 Anforderungen an den Parkplatz .................................................................... 141

10.4.4 Geeignete Flächen ......................................................................................... 141

10.4.5 Bauliche Varianten für den Versuchsflottenstützpunkt ................................... 142

10.4.6 Weiteres Vorgehen für Auswahl des Versuchsflottenstützpunkts .................. 143

11 Versuchsdatenaufzeichnung und -übertragung ............................................................ 144

11.1 Versuchsdatenaufzeichnung .............................................................................. 144

11.2 Versuchsdatenübertragung ................................................................................ 144

11.3 Logprofile ............................................................................................................ 145

11.4 Nachlaufzeit ........................................................................................................ 145

11.5 Monitoring ........................................................................................................... 146

12 Werkzeuge zur Versuchsdurchführung ........................................................................ 148

12.1 Überblick über die zur Verfügung gestellten Werkzeuge ................................... 148

12.2 Arbeiten im Vorfeld der Versuchsdurchführungen ............................................. 149

12.2.1 Erfassen der Mitarbeiterstammdaten .............................................................. 149

12.2.2 Erfassen der Fahrzeugstammdaten ............................................................... 151

12.2.3 Anlegen und prüfen der Drehbücher .............................................................. 151

12.2.4 Drehbücher verfeinern .................................................................................... 152

12.2.5 Planen der Durchführungen ............................................................................ 156

12.3 Tagesgeschäft – Versuchsdurchführungen ........................................................ 156

12.3.1 Vorbereiten der Versuchsdurchführung .......................................................... 157

12.3.2 Versuchsdurchführung .................................................................................... 159

12.3.3 Sofortprüfung .................................................................................................. 161

12.3.4 Vorbereitungen und Nacharbeiten .................................................................. 162

12.3.5 Defektmanagement ........................................................................................ 163

13 Konzeption Pilotversuche und Vorversuche ................................................................. 164

13.1 Teilprojekte TP3/TP4 und deren Phasen ........................................................... 164

13.2 Pilotversuchsphase ............................................................................................ 165

13.2.1 Voraussetzung für die Durchführung von Pilotversuchen ............................... 165

13.2.2 Aufgaben in der Pilotversuchsphase .............................................................. 166

13.2.3 Ergebnisse der Pilotversuchsphase ............................................................... 166

13.3 Vorversuchsphase .............................................................................................. 167

13.3.1 Voraussetzung für die Durchführung von Vorversuchen ................................ 167

13.3.2 Aufgaben in der Vorversuchsphase ................................................................ 168

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite viii

13.3.3 Ergebnisse in der Vorversuchsphase ............................................................. 168

14 Konzeption Erstellung Drehbücher ............................................................................... 169

14.1 Einleitung ............................................................................................................ 169

14.2 Begriffsbestimmung ............................................................................................ 169

14.2.1 Versuchsszenario (Arbeitsdefinition) .............................................................. 169

14.2.2 Drehbuch und Drehbuchauszug (Arbeitsdefinition) ........................................ 171

14.2.3 Übersicht der Arbeitsdefinitionen .................................................................... 172

14.3 Konzeption Drehbuch (Arbeitsstand: März 2010) .............................................. 172

14.3.1 Einführung ...................................................................................................... 172

14.3.2 Arbeitsstand Drehbücher für interne Flotte ..................................................... 175

14.3.3 Externe Flotte ................................................................................................. 176

14.3.4 Fahrsimulation ................................................................................................ 177

14.3.5 Verkehrssimulation ......................................................................................... 178

15 Fazit .............................................................................................................................. 181

15.1 Rückblick ............................................................................................................ 181

15.2 Schlussfolgerungen ............................................................................................ 181

15.2.1 Vorarbeiten zur Erstellung eines Prüfkonzepts ............................................... 181

15.2.2 Übersichten über Versuchsgebiet, Testgelände, Versuchsflotten und Simulationslabor ........................................................................................................... 182

15.2.3 Anmerkungen zu empirischen Versuchen mit der internen bzw. externen Flotte 182

15.2.4 Darstellung der organisatorischen und technischen Rahmenbedingungen ... 183

15.2.5 Aktueller Diskussionsstand bei der Erstellung der Drehbücher für die Versuchsdurchführung in TP4 ...................................................................................... 183

15.3 Ausblick .............................................................................................................. 184

Anhang ................................................................................................................................. 185

Anhang 1: Durchführbarkeit von Versuchsfällen bei Eingriff in den Straßenverkehr ........ 185

Anhang 2: Befahrung des Versuchsgebiets durch IZVW ................................................. 196

Anhang 3: Anforderungen an Testgelände (abgeleitet aus Test- und Versuchsfällen, AP13) ............................................................................................................................... 198

Literaturverzeichnis .............................................................................................................. 205

Abkürzungen ........................................................................................................................ 207

Glossar ................................................................................................................................. 208

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite ix

Abbildungen Abbildung 1: Erläuterung des Unterschieds zwischen Fahr- und Verkehrseffizienz bzw. Fahr- und Verkehrssicherheit an einem fiktiven Beispiel (die Zahlen könnten beispielsweise die jeweilige mittlere Reisezeit oder die jeweilige maximale Geschwindigkeit sein). ..................... 8

Abbildung 2: Inner- und außerstädtische Straßen des simTD-Versuchsgebiets. ...................... 9

Abbildung 3: Spezialistenteams für die technischen Versuche. ............................................. 22

Abbildung 4: Konzept für das Erreichen abgestimmter Prioritäten für die nicht-technischen Versuchsfallvarianten. ............................................................................................................ 34

Abbildung 5: Stufenmodell der Versuchsphasen (Quelle: Sarris, 1990, S. 112). ................... 37

Abbildung 6: Vorher-Nachher-Messung an einer einzigen Versuchsgruppe. ........................ 39

Abbildung 7: Vorher-Nachher-Messung an einer einzigen Versuchsgruppe mit Post-Phase. ............................................................................................................................................... 40

Abbildung 8: Zweistichprobenversuchsplan mit Zufallsgruppenbildung. ................................ 40

Abbildung 9: Cross-Over Design. ........................................................................................... 41

Abbildung 10: Versuchsplan der externen Flotte laut simTD-Vorhabensbeschreibung: „Schrotschuss-Design“. .......................................................................................................... 41

Abbildung 11: Wechselseitige Beziehungen im Signifikanztest (Quelle: Bortz & Döring, 2006, S. 627). ................................................................................................................................... 45

Abbildung 12: Optimale Stichprobengröße (Ordinate) in Abhängigkeit von verschiedenen Teststärken („Power“, Abszisse) für ein Kontrollgruppen-Design, keine Messwiederholung, kleine Effektgröße. ................................................................................................................. 47

Abbildung 13: Optimale Stichprobengröße (Ordinate) in Abhängigkeit von verschiedenen Teststärken („Power“, Abszisse) für ein Kontrollgruppen-Design, keine Messwiederholung, große Effektgröße. ................................................................................................................. 48

Abbildung 14: Optimale Stichprobengröße (Ordinate) in Abhängigkeit von verschiedenen Teststärken („Power“, Abszisse) für ein Kontrollgruppen-Design mit technischen Rahmenbedingungen, kleine Effektgröße, teilweise abhängige Messung. ............................ 48

Abbildung 15: Optimale Stichprobengröße (Ordinate) in Abhängigkeit von verschiedenen Teststärken („Power“, Abszisse) für ein Kontrollgruppen-Design mit technischen Rahmenbedingungen, große Effektgröße, teilweise abhängige Messung. ............................ 51

Abbildung 16: Versuchsgebiet Niederrad und VISUM Umlegungsergebnis (Quelle: Stadt Frankfurt). ............................................................................................................................... 53

Abbildung 17: IRS-Standorte regionaler Bereich (Quelle: HLSV). ......................................... 57

Abbildung 18: Ausschnitt aus dem simTD Versuchsgebiet. ..................................................... 58

Abbildung 19: IRS-Standorte städtischer Bereich. ................................................................. 59

Abbildung 20: Wechselverkehrszeichenbrücke. ..................................................................... 62

Abbildung 21: Wechselwegweiser. ......................................................................................... 62

Abbildung 22: Dynamische Wechselwegweiser mit integrierter Stauinformation – dWiSta. .. 63

Abbildung 23: Dynamische Informationstafeln zur Reisezeitanzeige – dIRA. ........................ 63

Abbildung 24: Temporäre Seitenstreifenfreigabe. .................................................................. 64

Abbildung 25: Hauptfenster von SILABVideoAnalysis (Quelle: WIVW GmbH). ..................... 66

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite x

Abbildung 26: Lage des Testgeländes im Versuchsgebiet. ................................................... 71

Abbildung 27: Übersicht der ehemaligen US-Kaserne Friedberg (Quelle: Bundesanstalt für Immobilienaufgaben). ............................................................................................................. 72

Abbildung 28: Freifläche im Nordosten. ................................................................................. 72

Abbildung 29: West-Ost-Gerade. ........................................................................................... 73

Abbildung 30: Betonierte Freifläche im Süden. ...................................................................... 73

Abbildung 31: Nutzbare Gebäude. ......................................................................................... 74

Abbildung 32: Fahrsimulator mit Bewegungssystem der WIVW GmbH. ................................ 76

Abbildung 33: Statischer Fahrsimulator der WIVW GmbH. .................................................... 77

Abbildung 34: Pulksimulation der WIVW GmbH. ................................................................... 78

Abbildung 35: Screenshots aus der Fahrsimulationssoftware SILAB der WIVW GmbH. Hier beispielhaft Stadtszenario, Landstraße und Nachtfahrt. ........................................................ 79

Abbildung 36: Mitschau der Daten in der Fahrsimulationssoftware SILAB der WIVW GmbH. ............................................................................................................................................... 80

Abbildung 37: 2D- und 3D-Darstellungen von Streckenausschnitten in VISSIM (Quelle: PTV Planung Transport Verkehr AG, 2009). .................................................................................. 83

Abbildung 38: Generiertes Abbild des simTD – Versuchsgebietes als Netzmodell (Quelle: TUM-VT). ................................................................................................................................ 84

Abbildung 39: Wahrscheinlichkeit eines erfolgreichen Nachrichtenempfangs in Abhängigkeit von der Ausstattungsdichte und von der Entfernung zwischen Sender und Empfänger (Quelle: Assenmacher, Killat, Schmidt-Eisenlohr & Vortisch, 2008). ..................................... 86

Abbildung 40: Zusammenspiel zwischen Versuchsszenario, Prüfung der technischen Funktionalität und Wirkungsermittlung und der Einfluss unterschiedlicher Randbedingungen. ............................................................................................................................................... 88

Abbildung 41: Zusammenspiel der Versuchsumgebungen. ................................................... 89

Abbildung 42: Datenfluss im Rahmen einer Verkehrssimulations-Studie. ............................. 91

Abbildung 43: Übersicht über Versuchsflotten in simTD. ......................................................... 92

Abbildung 44. Zuordnung der simTD Flotten zu verschiedenen Phasen (Zeitplanung: Stand März 2010). ............................................................................................................................ 95

Abbildung 45: simTD-Versuchsfahrer der internen Flotte (Quelle: simTD-Vorhabensbeschreibung, 2009). ............................................................................................ 98

Abbildung 46: Verteilung der simTD-Versuchsflotte (Quelle: Vorhabensbeschreibung, 2009). ............................................................................................................................................... 99

Abbildung 47. Personal und Organigramm für Versuchsflottenstützpunkt und simTD-Versuchszentrale. ................................................................................................................. 136

Abbildung 48: Komponenten der Versuchsunterstützung. ................................................... 148

Abbildung 49: Unterschiedliche Einsatzorte der Versuchsunterstützung. ............................ 149

Abbildung 50: Personalstammdaten Eingabe im FMS (Sauer OS, 2009). ........................... 150

Abbildung 51: Personalverfügbarkeit im FMS (Sauer OS, 2009). ........................................ 150

Abbildung 52: Eingabe der Fahrzeugdaten im FMS (Sauer OS, 2009). .............................. 151

Abbildung 53: Testablaufplanung – Drehbücherauflistung. .................................................. 152

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite xi

Abbildung 54: Beispielhafte Darstellung der Formularansicht für Versuchsfälle. ................. 152

Abbildung 55: Szenario-Editor - Allgemeine Informationen. ................................................. 153

Abbildung 56: Szenario Editor - Anlegen von Routen. ......................................................... 154

Abbildung 57: Szenario Editor - Ereignisse und Aktionen. ................................................... 155

Abbildung 58: Szenario Editor - Anlegen von Gruppen. ....................................................... 156

Abbildung 59: Einplanen einer Versuchsdurchführung. ....................................................... 157

Abbildung 60: Buchen von Fahrern und Fahrzeugen. .......................................................... 158

Abbildung 61: Versuchsdurchführung. ................................................................................. 160

Abbildung 62: Beispiel für die HMI Präsentationen (Entwurfsdesign, Stand: März 2010). ... 160

Abbildung 63: Fahrerbefragung – Situationsbewertung (Entwurfsdesign, Stand: März 2010). ............................................................................................................................................. 161

Abbildung 64: Entwurfsbeispiele für Fahrerbefragung – Bewertung (Entwurfsdesign, Stand: März 2010). .......................................................................................................................... 161

Abbildung 65: Sofortprüfung der Versuchsdurchführung. .................................................... 162

Abbildung 66: Defektverwaltung mit dem FMS (Sauer OS, 2009). ...................................... 163

Abbildung 67: Zeitliche Einordnung und Reihenfolge der Phasen. ...................................... 164

Abbildung 68: Priorisierung in den Phasen und deren Teilprojekte. .................................... 164

Abbildung 69: Gliederung der simTD-Begriffe –Versuchsszenario als Konkretisierung eines Versuchsfalls bzw. einer Versuchsfallvariante. .................................................................... 170

Abbildung 70: simTD-Begriffe – Erweiterung um Begriffe „Drehbuch“ bzw. „Drehbuch-Auszug“. ............................................................................................................................... 171

Abbildung 71: Screenshot einer beispielhaften Fahrsituation „Liegengebliebenes Fahrzeug“ der Fahrsimulation der WIVW GmbH. .................................................................................. 178

Abbildung 72: Erste Befahrungsrunde des städtischen Versuchsgebiets durch das IZVW: Baseler Straße – Stresemannallee – Mörfelder Landstraße – Alt-Niederrad – Bürostadt Niederrad – Alt-Niederrad – Kennedyallee. .......................................................................... 196

Abbildung 73: Zweite Befahrungsrunde des städtischen Versuchsgebiets durch das IZVW: Theodor-Stern-Kai – Alt-Niederrad – A5 AS Frankfurt-Niederrad – Frankfurter Kreuz – A3 AS Frankfurt Süd – Mörfelder Landstraße – Kennedyallee. ...................................................... 196

Abbildung 74: Dritte Befahrungsrunde des städtischen Versuchsgebiets durch das IZVW: Theodor-Stern-Kai – Niederräder Ufer – A5 AS Frankfurt-Niederrad – Westkreuz Frankfurt – A648 (Theodor-Heuss-Allee) – Friedrich-Ebert-Anlage. ...................................................... 197

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite xii

Tabellen Tabelle 1: Erweiterte Versuchsmatrix mit den Dimensionen „Nicht-technische Fragestellungen in simTD“ und „Versuchsumgebungen für nicht-technische Ziele“. Im Feld „R“ (Realisierung im Rahmen der nicht-technischen Versuche geplant) wird für jede der Kombinationen das Zutreffen der Kriterien angegeben. Zusätzlich ist jeweils ein Feld für Kommentare vorhanden. ........................................................................................................ 11

Tabelle 2: Auflistung der in simTD geplanten Anwendungsfälle (veranschaulicht durch ein „X“) in Abhängigkeit der nicht-technischen Fragestellung und Versuchsumgebung. (In der Erweiterten Versuchsmatrix: Realisierung im Rahmen der nicht-technischen Versuche geplant - Abkürzungen: „N“ Nutzerakzeptanz, „FE“ Fahreffizienz, „VE“ Verkehrseffizienz, „FS“ Fahrsicherheit und „VS“ Verkehrssicherheit). ................................................................ 12

Tabelle 3: Übersicht über an einem Versuchsfall mögliche beteiligte Fahrer- bzw. Fahrzeuggruppen. .................................................................................................................. 15

Tabelle 4: Übersicht über die Anzahl an Versuchsfallvariationen pro Versuchsumgebung (Stand: März 2010). ................................................................................................................ 16

Tabelle 5: Anzahl von Validierungszielen in Bezug zu Funktionen, Kommunikationssystem, IT-Sicherheit, Ausstattung. ..................................................................................................... 18

Tabelle 6: Technisches Test- und Versuchsfalltemplate. ....................................................... 19

Tabelle 7: Anzahl der Test und Versuchsfallspezifikationen in Relation zu den Validierungszielen. ................................................................................................................. 20

Tabelle 8: Zusammenfassung der technischen Versuchsfälle für das TP4 (Diskussionsstand: März 2010). ............................................................................................................................ 21

Tabelle 9: Stellungnahme der Straßenverkehrsbehörden. ..................................................... 28

Tabelle 10: Nicht-technische Versuchsfallvarianten der internen Flotte im Versuchsgebiet für den Anwendungsfall "Warnung vor Stauende". ..................................................................... 32

Tabelle 11: Vergleich der verschiedenen Versuchsdesigns. .................................................. 42

Tabelle 12: Vorgehen bei Schätzung der optimalen Stichprobengröße für Kontrollgruppen-Design, keine Messwiederholung und kleinem Effekt. ........................................................... 46

Tabelle 13: Vorgehen bei Schätzung der optimalen Stichprobengröße für Kontrollgruppen-Design, keine Messwiederholung und großem Effekt. ........................................................... 47

Tabelle 14: Vorgehen bei Schätzung der optimalen Stichprobengröße für Kontrollgruppen-Design mit verkehrlichen Rahmenbedingungen, teilweise abhängige Messung und kleinem Effekt. ..................................................................................................................................... 49

Tabelle 15: Vorgehen bei Schätzung der optimalen Stichprobengröße für Kontrollgruppen-Design, keine Messwiederholung und großem Effekt. ........................................................... 50

Tabelle 16: Beschreibung der Attribute und Details der POIs im Versuchsgebiet. ................ 60

Tabelle 17: Zuordnung der Attribute zu den POIs im Versuchsgebiet. .................................. 61

Tabelle 18: Bewertung Kriterien geschlossenes Testgelände (aus Sicht von TP4). .............. 70

Tabelle 19: Auflistung der in simTD in der Fahrsimulation geplanten Anwendungsfälle in Abhängigkeit der nicht-technischen Fragestellung. ................................................................ 81

Tabelle 20: Auflistung der in simTD in der Verkehrssimulation geplanten Anwendungsfälle in Abhängigkeit der nicht-technischen Fragestellung. ................................................................ 86

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite xiii

Tabelle 21: Auflistung der in simTD mit der internen Flotte geplanten Anwendungsfälle (veranschaulicht durch ein „X“) in Abhängigkeit der nicht-technischen Fragestellung und Versuchsumgebung. Abkürzungen: „N“ Nutzerakzeptanz, „FE“ Fahreffizienz, „VE“ Verkehrseffizienz, „FS“ Fahrsicherheit und „VS“ Verkehrssicherheit. .................................. 101

Tabelle 22: Funktionsversuche für die interne Flotte. .......................................................... 103

Tabelle 23: Kommunikations-, Sicherheits- und Ausstattungsversuche für die interne Flotte. ............................................................................................................................................. 106

Tabelle 24: Auflistung der in simTD mit der externen Flotte geplanten Anwendungsfälle in Abhängigkeit der nicht-technischen Fragestellung. .............................................................. 110

Tabelle 25: Zusammenfassung der Ausstattungs-, Kommunikation- und IT-Sicherheitsversuche für die externe Flotte. .......................................................................... 117

Tabelle 26: Zusammenfassung der Test- und Versuchsspezifikation für Funktionsversuche für die externe Flotte. ........................................................................................................... 117

Tabelle 27: Bewertung potenzieller Kandidaten für die externe Flotte („-“ negativ zu bewerten bzw. trifft nicht zu, „O“ neutral zu bewerten, „+“ positiv zu bewerten bzw. trifft zu). ............. 122

Tabelle 28: Zuordnung der Aufgaben zum Personal (Stand: März 2010). ........................... 138

Tabelle 29: Übersicht über räumliche Ausmaße des Versuchsflottenstützpunktes. ............ 140

Tabelle 30: Technische Büroausstattung Versuchsflottenstützpunkt (Stand: März 2010). .. 141

Tabelle 31: Mobiliar Versuchsflottenstützpunkt (Stand: März 2010). ................................... 142

Tabelle 32: Konkretisierung einer Versuchsfallvariante zu einem Simulationsszenario. ..... 179

Tabelle 33: Versuchsfälle für A_2.1.1.5 Hindernisse auf der Fahrbahn. .............................. 185

Tabelle 34: Versuchsfälle für A_2.1.1.2 Warnung vor liegengebliebenem Fahrzeug. ......... 186

Tabelle 35: Versuchsfälle für A_2.1.1.4 Baustellenwarnung. ............................................... 187

Tabelle 36: Versuchsfälle für A_1.3.2.1 Optimierung des LSA-gesteuerten Verkehrsflusses. ............................................................................................................................................. 188

Tabelle 37: Versuchsfälle für A_1.3.1.1 Umleitungsempfehlung. ......................................... 190

Tabelle 38: Versuchsfälle für A_2.1.4.1 Warnung vor sich näherndem Einsatzfahrzeug. ... 191

Tabelle 39: Versuchsfälle für A_3.1.2.4 Parksituation. ......................................................... 194

Tabelle 40: Versuchsfälle für A_2.2.4.1 Querverkehrsassistent. ......................................... 195

Tabelle 41: Anforderungen an das Testgelände. ................................................................. 198

Tabelle 42: Abkürzungsverzeichnis. ..................................................................................... 207

Tabelle 43: Einträge der Versuchsmethodik für das simTD-Glossar (Quelle: Bortz & Döring, 2006). ................................................................................................................................... 208

Deliverable D41.1 Version 3.0 | 28.06.2010 | Seite 1

Zusammenfassung Laut simTD-Vorhabensbeschreibung (Version 4.1, 2009, S. 187) hat AP41 „die Aufgabe, ein Versuchsdesign zu entwerfen, mit dem sich die zu den genannten Kategorien definierten Versuche effizient durchführen und auswerten lassen. Dazu gehört

• die Ausarbeitung von Versuchsszenarien

• die Auswahl entsprechender Versuchsgebiete […]

• die Planung der Auswertung

• die Planung des Probandenbedarfs.“

Nach Abschluss von AP41 steht somit ein Versuchsplan zur Verfügung, der verschiedenarti-ge technische und nicht-technische Versuchsfälle im Rahmen von simTD abdeckt. Zu diesem Versuchsplan sind die notwendigen Werkzeuge und Methoden sowie die Messtechnik spezi-fiziert. Der Versuchsplan stellt sicher, dass sich aus den im Versuch erhobenen Daten valide Aussagen ableiten lassen. Das vorliegende Deliverable D41.1 „Versuchsplan 1.0“ stellt ein Zwischenergebnis der Arbei-ten im Rahmen von AP41 Versuchsdesign dar und umfasst folgende Themenschwerpunkte:

• Schnittstellen zu weiteren Teilprojekten und Arbeitspaketen in simTD (Kap. 1)

• Vorarbeiten zur Erstellung eines Prüfkonzepts (Kap. 2)

• Übersichten über Versuchsgebiet, Testgelände, Versuchsflotten und Simulationslabor (Kap. 3 bis Kap. 6)

• Anmerkungen zu Versuchen mit der internen bzw. externen Flotte (Kap. 7 und 8)

• Darstellung der organisatorischen und technischen Rahmenbedingungen (Versuchs-fahrer, Zusammenspiel Versuchszentrale und Versuchsflottenstützpunkt, Versuchs-datenaufzeichnung und -übertragung, Werkzeuge zur Versuchsdurchführung, Kon-zeption Pilotversuche und Vorversuche; Kap. 9 bis 13)

• Diskussionsstand der Erstellung der Drehbücher für die Versuchsdurchführung in TP4 (Kap. 14)

Die Darstellung dieser Themenschwerpunkte erfolgt auf Basis des Arbeitsstandes im März 2010. Sie bilden eine gemeinsame Grundlage für die weiteren Arbeiten in AP41, die im Deli-verable D41.2 „Versuchsplan 2.0“ dargelegt werden.


English summary D41.1 Experimental Design 1.0 According to the simTD project description (version 4.1, 2009, p. 187) the working package AP41 is assigned “to develop a test design, which is fit to exercise and evaluate the prede-fined tests according to its categories efficiently. This includes:

• the development of test scenarios

• the selection of adequate test areas […]

• planning and evaluation

• ascertaining the demand of subjects (test persons).

After the completion of AP41 a test design will be available that encompasses different tech-nical and non-technical experiments during the course of simTD. Necessary tools and meth-ods for the test design will have been specified. This will ensure that valid statements can be derived from all extracted data.

The present Deliverable D41.1 “Test Design 1.0” constitutes an interim result of the work within the scope of AP41 test design. It focuses on the following topics:

• interfaces to other subprojects and work packages of simTD (chapter 1)

• preparation of a concept for regular checks (chapter 2)

• overview of test area, testing grounds, test fleet and simulation-laboratory (chapter 3 to chapter 6)

• remarks concerning tests with intern and extern fleets (chapter 7 and chapter 8)

• description of organisational und technical conditions (test drivers, interaction of cen-tral office and fleet base, plotting and transmission of test data, tools for executing the tests, conception of pilot tests and preliminary tests (chapter 9 to chapter13)

• state of discussion for creating scripts of test procedures for TP4 (chapter 14)

The illustration of those topics is based on the work which was completed by March 2010. It constitutes the common basis for further tasks in AP41 which will be presented in Deliverable D41.2 “Test Design 2.0”.


1 Einleitung

1.1 Zielsetzung des Deliverable D41.1

Das vorliegende Deliverable D41.1 „Versuchsplan 1.0“ stellt ein Zwischenergebnis der Arbei-ten im Rahmen von Teilprojekt TP4 Versuchsdurchführung, speziell: Arbeitspaket AP41 Ver-suchsdesign, dar. Laut simTD-Vorhabensbeschreibung (Version 4.1, 2009, S. 187) sind die drei wesentlichen Ziele dieses Teilprojekts:

• „Großversuch aufbauen und betreiben

• C2X – Wirksamkeits-Nachweis erbringen

• Basis für eine umfassende Bewertung erarbeiten

Im TP4 wird zunächst ein Versuchsdesign entwickelt (AP41), mit dem die in TP1 spezifizier-ten Tests an den technischen Lösungen, die in den Teilprojekten TP2 und TP3 erarbeitet wurden, durchgeführt (AP42 mit Hilfe von AP44) und ausgewertet (AP43) werden“.

Die Untersuchung der Wirkung von C2X-Kommunikationsanwendungen, die in simTD getes-tet werden, lässt sich in vier Kategorien einteilen:

1. Technische Aspekte

2. Nutzerakzeptanz

3. Fahr- und Verkehrssicherheit

4. Fahr- und Verkehrseffizienz

Laut simTD-Vorhabensbeschreibung (Version 4.1, 2009, S. 187) hat AP41 „die Aufgabe, ein Versuchsdesign zu entwerfen, mit dem sich die zu den genannten Kategorien definierten Versuche effizient durchführen und auswerten lassen. Dazu gehört

• die Ausarbeitung von Versuchsszenarien

• die Auswahl entsprechender Versuchsgebiete […]

• die Planung der Auswertung

• die Planung des Probandenbedarfs.“

Nach Abschluss von AP41 steht somit ein Versuchsplan zur Verfügung, der verschiedenarti-ge technische und nicht-technische Versuchsfälle im Rahmen von simTD abdeckt. Zu diesem Versuchsplan sind die notwendigen Werkzeuge und Methoden sowie die Messtechnik spezi-fiziert und der Versuchsplan stellt sicher, dass sich aus den im Versuch erhobenen Daten valide Aussagen ableiten lassen.

Das vorliegende Deliverable D41.1 „Versuchsplan 1.0“ ist somit mit folgenden Zielsetzungen erstellt worden:

• Dokumentation des aktuellen Diskussionsstands in AP41 Versuchsdesign zu ver-suchsrelevanten Fragestellungen

• Identifikation von Schnittstellen zu den weiteren Teilprojekten im Rahmen von simTD

• Herstellung einer gemeinsamen Grundlage für weitere Arbeiten in AP41 mit dem Ziel der Erstellung des Deliverable D41.2 „Versuchsplan 2.0“

Das vorliegende Deliverable D41.1 stellt den Arbeitsstand März 2010 dar.


1.2 Überblick über dieses Dokument

Das vorliegende Deliverable D41.1 wurde von Autoren mehrerer simTD-Konsortialpartner erstellt, so dass unterschiedliche Themenblöcke adressiert und Präsentationsformen ermög-licht werden. Die folgenden Darstellungen lassen sich vereinfacht zu nachstehenden The-menblöcken gruppieren:

• Vorarbeiten zur Erstellung eines Prüfkonzepts

o Kap. 2: Prüfkonzept 1.0

• Übersichten über Versuchsgebiet, Testgelände, Versuchsflotten und Simulationslabor

o Kap. 3: Versuchsgebiet

o Kap. 4: Testgelände

o Kap. 5: Konzeption Simulationslabor

o Kap. 6: Versuchsflotten: Übersicht

• Anmerkungen zu empirischen Versuchen mit der internen bzw. externen Flotte

o Kap. 7: Interne Flotte

o Kap. 8: Externe Flotte

• Darstellung der organisatorischen und technischen Rahmenbedingungen

o Kap. 9: Versuchsfahrer

o Kap. 10: Zusammenspiel simTD-Versuchszentrale und Versuchsflottenstütz-punkt

o Kap. 11: Versuchsdatenaufzeichnung und -übertragung

o Kap. 12: Werkzeuge zur Versuchsdurchführung

o Kap. 13: Konzeption Pilotversuche und Vorversuche

• Aktueller Diskussionsstand bei der Erstellung der Drehbücher für die Versuchsdurch-führung in TP4

o Kap. 14: Konzeption Erstellung Drehbücher

Die meisten der o.g. Kapitel sind eine Gesamtleistung verschiedener Autoren. Die Autoren werden an entsprechender Stelle genannt.

1.3 Einbettung von D41.1 in das Projekt simTD

1.3.1 TP-übergreifende Einbettung

Ziel von AP41 Versuchsdesign ist es, aus den Anforderungen und Vorgaben der technischen und nicht-technischen Versuchsfälle aus Teilprojekt TP1 (speziell: AP13 Abgeleitete Tests) Versuche abzuleiten, diese Versuche zu planen und geeignete Versuchsorte zur Durchfüh-rung zu bestimmen (inklusive Planung der Positionierung der IRS). Dementsprechend ba-siert das Versuchsdesign in AP41 wesentlich auf den Funktionsspezifikationen (AP11), auf den definierten Validierungszielen, -methoden und -metriken (AP12) und den abgeleiteten Versuchen (AP13).

Ebenso hat der von Teilprojekt TP2 geleistete Systementwurf einen wesentlichen Einfluss auf die Arbeiten in AP41: Die Ausgestaltung der technischen und nicht-technischen Versu-


che in TP4 hängt von verschiedenartigen technischen Rahmenbedingungen ab. Zu nennen sind hierbei die Gesamtarchitektur (AP21), die fahrzeug- bzw. infrastrukturseitigen Subsys-teme (AP22 bzw. AP23) und das Testsystem (AP24).

AP41 mit Deliverable D41.1 ist demgegenüber weitgehend unabhängig von Teilprojekt TP3, in dem eine Systemintegration erfolgt. Von Bedeutung ist hier v.a. die Auswahl und Ausge-staltung des Testgeländes (AP32 Infrastrukturaufbau und -integration). Die eher konzeptio-nellen Arbeiten in AP41 sind von den entsprechenden Arbeiten in TP3 nur in begrenzten Ausschnitten betroffen.

Zugleich erarbeitet AP41 die Grundlagen für die Auswertung der Versuche im Versuchsge-biet, auf dem Testgelände sowie in der Fahr- und Verkehrssimulation. Im Rahmen von TP4 findet jedoch keine Interpretation oder Bewertung der Ergebnisse statt. Diese Aufgabe wird von Teilprojekt TP5 unter Hinzuziehung von versuchsexternen Informationen übernommen. Dabei werden Aussagen unter ökonomischen und (volks-)wirtschaftlichen Aspekten getrof-fen. Aus diesem Grund ist eine Abstimmung von AP41 mit TP5 notwendig.

1.3.2 TP-interne Einbettung

AP41 Versuchsdesign mit den Deliverables D41.1 „Versuchsplan 1.0“ und D41.2 „Versuchs-plan 2.0“ ist Voraussetzung für weitere Arbeiten in TP4:

• In AP41 wird das Versuchsgebiet geplant, welches in AP44 (Aufbau und Betrieb Inf-rastruktur und Versuchszentrale) aufgebaut werden wird. Weiterhin werden die detail-lierten IRS Positionen festgelegt.

• Drehbücher für die Durchführung von technischen und nicht-technischen Versuchen müssen hinreichend konkret ausformuliert sein, damit in AP42 (Flottenverwaltung, Versuchsdurchführung und Integration) und AP44 (Aufbau und Betrieb Infrastruktur und Versuchszentrale) die Versuche durchgeführt werden können.

• Planungen zu Datenauswertungen werden an AP43 (Auswertung und Analyse) über-geben, das diese Planungen während und nach der Versuchsdurchführung gegebe-nenfalls adaptiert und konkret umsetzt.

Generell besteht eine enge Zusammenarbeit zwischen den einzelnen Arbeitspaketen des TP4, so dass generell eine enge Verzahnung der einzelnen Prozesse angestrebt wird. Zu-sätzlich ermöglichen die AP-übergreifenden Teams in TP4 („Systemvalidierung“, „Simulati-onslabor“, „Fahrzeugseitige Systeme/Flotte“ und „Infrastruktur/Versuchszentrale“) eine kon-sistente Betrachtungsweise einzelner Themen über die Arbeitspakete hinweg.


2 Prüfkonzept 1.0

2.1 Ausgangspunkt Deliverable D13.2

Im Rahmen des Forschungsprojekts simTD werden 21 C2X-Funktionen mit insgesamt 36 Anwendungsfällen entwickelt, die hinsichtlich ihrer Auswirkungen auf den Fahrer und die verkehrliche Umwelt zu untersuchen sind. Für die Versuchsdurchführung von technischen und nicht-technischen Versuchen wurden in AP13 wesentliche Vorarbeiten geleistet, die im Deliverable D13.2 festgehalten sind. Im Folgenden werden diese näher erläutert.

2.1.1 Nicht-technische Test- und Versuchsfälle

Es wurden im Rahmen von simTD zur Untersuchung der Auswirkungen der Anwendungsfälle auf den Fahrer und die verkehrliche Umwelt fünf übergeordnete nicht-technische Fragestel-lungen definiert: Nutzerakzeptanz, Fahr- und Verkehrseffizienz sowie Fahr- und Verkehrssi-cherheit (siehe Kap. 2.1.1.1).

Bei den fünf simTD-Funktionen der Hauptfunktion HF1.1 mit insgesamt acht Anwendungsfäl-len werden keine nicht-technischen Fragestellungen adressiert. Die entsprechenden Funkti-onen (sog. Basisfunktionen) sind Grundlage für andere simTD-Funktionen und werden durch die technischen Tests und technischen Versuche geprüft. Es finden für diese simTD-Funktionen keine direkten Interaktionen mit dem Fahrer statt. Durch die Überprüfung der Validität der darauf aufbauenden simTD-Funktionen wird die Qualität der Basisfunktionen indi-rekt mit geprüft (z.B. bei der Wetterwarnung F_2.1.3 wird die Qualität der Basisfunktion „Er-mittlung der Verkehrswetterlage“ F_1.1.3 geprüft). Daher ist eine Berücksichtigung dieser Funktionen bei der Betrachtung der nicht-technischen Fragestellungen nicht sinnvoll.

Zur Realisierung der notwendigen Untersuchungen stehen fünf Versuchsumgebungen zur Verfügung (in Klammern sind die nachfolgend verwendeten Abkürzungen dargestellt):

• Feldversuch im Versuchsgebiet mit interner Flotte (IF)

• Feldversuch im Versuchsgebiet mit externer Flotte (EF)

• Testgelände (interne Flotte) (TG)

• Fahrsimulation (FS)

• Verkehrssimulation (VS)

2.1.1.1 Nicht-technische Fragestellungen in simTD Folgende nicht-technische Fragestellungen werden als zentral für die Bewertung der ausge-wählten simTD-Anwendungsfälle in den von TP4 durchzuführenden Versuchen definiert:

• Auswirkungen der simTD-Anwendungsfälle auf Nutzerakzeptanz Die Nutzerakzeptanz betrachtet die Akzeptanz des simTD-Anwendungsfalls durch den Fahrer. Es ist folgende Unterscheidung zu treffen: Subjektive Ebene:

Beurteilung des simTD-Anwendungsfalls durch den Fahrer (z.B. „System hat mich rechtzeitig informiert“, „System hat die Fahrsicherheit erhöht“, „System hat den Fahrkomfort erhöht“)


Objektive Ebene: Nutzungs-/Reaktionsverhalten der Fahrer auf simTD-Anwendungsfall (z.B. Befol-gungsraten und -geschwindigkeit auf simTD-Meldung/Information)

• Auswirkungen der simTD-Anwendungsfälle auf Fahr- und Verkehrseffizienz Fahr- und Verkehrseffizienz adressieren mögliche Wirkungen eines simTD-Anwendungsfalls auf die Effizienz eines einzelnen Fahrers (Fahreffizienz) bzw. eines Verkehrssystems (Verkehrseffizienz). Mögliche Kenngrößen sind beispielsweise Rei-sezeit, Geschwindigkeit, Kraftstoffverbrauch und/oder Streckenlänge. Fahr- und Verkehrseffizienz werden jeweils in Abhängigkeit von IVS-Ausstattungsrate, Verkehrszustand, Straßenkategorie etc. ermittelt Fahreffizienz:

Für die Validierung der Fahreffizienz im Projekt simTD werden die relevanten Kenn-größen für die Fahrzeuge mit Fahrer-Information/Warnung mit den Kenngrößen der Fahrzeuge ohne Fahrer-Information/Warnung verglichen. Um vergleichen zu können, wird auch bei Fahrzeugen ohne Fahrer-Information/ Warnung aufgezeichnet, wann der Fahrer welche Information/Warnung erhalten hät-te. Für Anwendungsfälle, bei denen der Fahrer keine Information/Warnung erhält (z.B. A_1.3.3.3 Reduzierung von (LSA-bedingten) Wartezeiten des Individualverkehrs), bezieht sich die Fahreffizienz auf den Vergleich der relevanten Kenngrößen für die Fahrzeuge, die Fahrzeugdaten (z.B. FCD) für den Anwendungsfall liefern (kommu-nizieren) mit den relevanten Kenngrößen für die Fahrzeuge, die keine Fahrzeugda-ten für den Anwendungsfall liefern (kommunizieren).

Verkehrseffizienz: Für die Validierung der Verkehrseffizienz im Projekt simTD werden die relevanten Kenngrößen für alle Fahrzeuge im Wirkungsbereich des Anwendungsfalls ermittelt und ausgewertet.

• Auswirkungen der simTD-Anwendungsfälle auf Fahr- und Verkehrssicherheit Fahr- und Verkehrssicherheit adressieren mögliche Wirkungen eines simTD-Anwendungsfalls auf die Sicherheit eines einzelnen Fahrers (Fahrsicherheit) bzw. ei-nes Verkehrssystems (Verkehrssicherheit). Mögliche Kenngrößen sind beispielsweise: Geschwindigkeitsverhalten, Abstandsverhalten und/oder Reaktionsverhalten auf für die Fahrzeugführung relevante Informationen. Fahr- und Verkehrssicherheit werden jeweils in Abhängigkeit von IVS-Ausstattungsrate, Verkehrszustand, Straßenkategorie etc. ermittelt. Fahrsicherheit:

Für die Validierung der Fahrsicherheit im Projekt simTD werden die relevanten Kenngrößen für die Fahrzeuge mit Fahrer-Information/Warnung mit den Kenngrö-ßen der Fahrzeuge ohne Fahrer-Information/Warnung verglichen. Auch bei Fahrzeugen ohne Fahrer-Information/Warnung wird aufgezeichnet, wann der Fahrer welche Information/Warnung erhalten hätte.

Verkehrssicherheit: Für die Validierung der Verkehrssicherheit im Projekt simTD werden die relevanten Kenngrößen für alle Fahrzeuge im Wirkungsbereich des Anwendungsfalls ermittelt.

Abbildung 1 verdeutlicht den Unterschied zwischen Fahr- und Verkehrseffizienz bzw. Fahr- und Verkehrssicherheit


IVS-Ausstattungsrate

Fahrzeuge0% 25% 50% 75% 100%

Ohne Fahrer-Info/Warnung 58 56 52 49 -

Mit Fahrer-Info/Warnung - 49 44 46 42

Alle Fahrzeuge 58 54 48 47 42

Fahreffizienz / Fahrsicherheit

Verkehrseffizienz / Verkehrssicherheit

Abbildung 1: Erläuterung des Unterschieds zwischen Fahr- und Verkehrseffizienz bzw. Fahr- und Verkehrssi-cherheit an einem fiktiven Beispiel (die Zahlen könnten beispielsweise die jeweilige mittlere Reisezeit oder die jeweilige maximale Geschwindigkeit sein).

Voraussetzung für die Prüfung der Auswirkungen der simTD-Anwendungsfälle ist deren Be-nutzbarkeit. Aus diesem Grund wurde die Benutzbarkeit als weitere eigenständige nicht-technische Fragestellung aufgenommen. Diese wird im Rahmen von nicht-technischen Tests im Teilprojekt TP2 untersucht, bevor nicht-technische Versuche in TP4 durchgeführt werden. Da die Erweiterte Versuchsmatrix (siehe Kap. 2.1.1.3) als Versuchsplanungstool ausschließ-lich für TP4 herangezogen wird, wird die Benutzbarkeit im Folgenden nicht weiter berück-sichtigt. Das DFKI, das für das simTD-HMI zuständig ist, wird diese nicht-technischen Testfäl-le im Rahmen von AP22 „Fahrzeugseitiges Subsystem“ spezifizieren und durchführen.

2.1.1.2 Versuchsumgebungen für nicht-technische Ziele Die simTD-Versuche werden in den folgenden Versuchsumgebungen durchgeführt (für eine Übersicht über Möglichkeiten und Grenzen der einzelnen Versuchsumgebungen siehe 2.2):

• Versuchsgebiet (siehe Abbildung 2): Ein Teil des Verkehrsraums in der Stadt Frankfurt am Main sowie Bundesautobahnen und Bundesstraßen, die mit für die simTD-Technologie notwendiger Infrastruktur ausge-stattet sind. Hier wird die Versuchsflotte eingesetzt, die wiederum aus der internen und der externen Flotte besteht: Interne Flotte:

Angeleitete Fahrer in angemieteten und mit simTD-Technologie ausgestatteten Fahr-zeugen, welche während der Versuchsdurchführung festgelegte Aufgaben gemäß den Drehbüchern (siehe Kap. 14) erhalten und gezielt bestimmte Fahrsituationen aufsuchen bzw. realisieren.

Externe Flotte: Fahrer, die selbstbestimmt im Versuchsgebiet unterwegs sind (z.B. Pendler in priva-ten Fahrzeugen oder Mitarbeiter eines Unternehmens in Dienstfahrzeugen. Die ge-naue Zusammensetzung ist zum Zeitpunkt der Berichtslegung noch nicht festge-legt). Die Fahrzeuge sind mit simTD-Technologie ausgestattet. Da die Fahrer sich frei bewegen, sind auch Fahrten außerhalb des Versuchsgebiets möglich. Diese werden nicht zur Auswertung herangezogen, da keine detaillierte georeferenzierte Netzbasis für den Bereich außerhalb des Versuchsgebiets zur Verfügung steht.

https://svn.simtd.de/trac/sim-td/wiki/Versuchsgebiet�


Abbildung 2: Inner- und außerstädtische Straßen des simTD-Versuchsgebiets.

• Testgelände: Angemietetes und geschlossenes Gelände, das mit für die simTD-Technologie notwen-diger Infrastruktur ausgestattet ist und auf dem u.a. die Fahrer der internen Flotte so-wie die OEM-Testflotte eingesetzt werden. Die Steuerung der verschiedenen Fahr-zeugflotten erfolgt über das Testsystem (siehe Kap. 12). Die Fahrer erhalten Aufgaben gemäß den Drehbüchern. Da das Gelände geschlossen ist, gibt es hier keinen öffentli-chen Verkehr bzw. ausschließlich Verkehr, der durch die Versuchsleitung gesteuert wird. Die Ausstattung des Testgeländes ist zum Zeitpunkt der Berichtslegung noch nicht endgültig definiert.

• Simulationslabor Fahrsimulation:

Simulationsumgebung, in der ein Fahrer durch eine virtuelle Szenerie fährt. Die Ver-suchsbedingungen (z.B. Wetter, umgebender Verkehr, Meldungen von simTD-Anwendungsfällen, Bebauung) sind kontrolliert herstellbar, d.h. durch die Versuchs-leitung gesteuert. Hierdurch können gezielt Variationen von Fahrsituationen unter kontrollierten Rahmenbedingungen hergestellt werden. Es ist der Einsatz verschie-dener Varianten von Fahrsimulationen (von einer einfachen PC-Simulation bis hin zu einer High-Fidelity Simulation mit Bewegungssystem) möglich.

Verkehrssimulation: Simulationsumgebung, in der viele Fahrer-Fahrzeug-Einheiten simuliert werden (mikroskopische Verkehrssimulation), die sich in einem virtuellen Abbild des Ver-suchsgebiets bewegen. Realistische Verkehrszustände werden abgebildet und das durch die simTD-Anwendungsfälle geänderte Verhalten der Fahrer-Fahrzeug-Einhei-ten wird gemäß den Ergebnissen aus Fahrsimulation und Feldversuch modelliert.

2.1.1.3 Erweiterte Versuchsmatrix

Aufgrund der großen Anzahl von theoretisch möglichen nicht-technischen Versuchsfällen und der limitierten geplanten Versuchsdauer im Rahmen von Teilprojekt TP4 Versuchsdurch-führung waren gezielte Überlegungen zur Durchführung der nicht-technischen Versuche notwendig: Es wurde anhand von festgelegten Kriterien untersucht, ob die Überprüfung jeder der potenziellen 700 Kombinationen einen Mehrwert bietet und damit notwendig ist. So hat z.B. nicht jeder Anwendungsfall einen Einfluss auf jede der nicht-technischen Fragestellun-gen und muss daher diesbezüglich nicht untersucht werden.


Für die Überprüfung der Kombinationen wurde die sog. Erweiterte Versuchsmatrix herange-zogen. Sie stellt eine systematische Übersicht pro Anwendungsfall dar,

• welche der nicht-technischen übergeordneten Fragestellungen

• in welcher Versuchsumgebung

im Rahmen von TP4 Versuchsdurchführung geplant ist, zu überprüfen.

Die Arbeiten zur Erweiterten Versuchsmatrix im Rahmen von AP13 erfolgten in mehreren Schritten. Die Konzeption und eine erste Befüllung der Erweiterten Versuchsmatrix pro An-wendungsfall als Diskussionsgrundlage für die Funktionsentwicklungsteams (FETs) erfolgten durch TUM-VT und IZVW. Im zweiten Schritt wurde die erste Befüllung durch die FETs kommentiert und ergänzt. In einer anschließenden gemeinsamen Diskussion mit TUM-VT, IZVW und den FETs wurden die Erweiterten Versuchsmatrizen konsolidiert. Die Ergebnisse werden im Anhang des Deliverables D13.2 (Anhang 3) vorgestellt.

2.1.1.4 Kriterien der Überprüfbarkeit Zur Bestimmung der Überprüfbarkeit von Kombinationen aus Anwendungsfall, nicht-technischer Fragestellung und Versuchsumgebung wurde das Kriterium „Realisierung im Rahmen der nicht-technischen Versuche geplant“ definiert. Voraussetzungen für eine solche Realisierbarkeit sind zum einen verschiedene technische Faktoren (z.B. technische Ausstat-tung der Fahrzeuge und der Versuchsumgebung), Darstellbarkeit (insbesondere im Simulati-onslabor) oder ethische und rechtliche Bedenken. Weiterhin müssen experimentelle Anord-nungen herstellbar sein.

Nach Sarris und Reiß (2005) sind Voraussetzungen für experimentelle Anordnungen (für eine Definition der Begriffe siehe Glossar am Ende des vorliegenden Deliverables):

• Systematische Beobachtung der Abhängigen Variablen (z.B. Messgrößen)

• Manipulation von Unabhängigen Variablen (z.B. (De-)Aktivierung von simTD-Anwendungsfällen und Bildung von Experimental- und Kontrollgruppe)

• Kontrolle von Störvariablen (z.B. Umgebungsverkehr)

Zum anderen waren für die Realisierung Überlegungen hinsichtlich des zusätzlichen Er-kenntnisgewinns einer Untersuchung gegenüber den anderen geplanten Untersuchungen notwendig (z.B. sollte eine Untersuchung im Testgelände nur dann durchgeführt werden, wenn in dieser zusätzliche Erkenntnisse gegenüber den Versuchen in den übrigen Ver-suchsumgebungen zu erwarten sind). Zusammenfassend ergab sich die Erweiterte Versuchsmatrix pro Anwendungsfall (siehe Tabelle 1), in der für jede der Kombinationen aus nicht-technischer Fragestellung und Ver-suchsumgebung die Überprüfbarkeit anhand des Kriteriums „Realisierung im Rahmen der nicht-technischen Versuche geplant“ dargestellt wird:

• In den Zeilen sind die Versuchsumgebungen dargestellt.

• In den Spalten sind die nicht-technischen Fragestellungen dargestellt.

Für jede dieser Kombinationen wurde anhand der Spalte „R“ (für Realisierung im Rahmen der nicht-technischen Versuche geplant) das Zutreffen anhand folgender Kategorien defi-niert:

• „x“ bedeutet zutreffend,

• „o“ bedeutet nicht zutreffend,

Bei Bedarf wurden anhand von Kommentaren Ergänzungen und Erläuterungen gegeben.


Tabelle 1: Erweiterte Versuchsmatrix mit den Dimensionen „Nicht-technische Fragestellungen in simTD“ und „Ver-suchsumgebungen für nicht-technische Ziele“. Im Feld „R“ (Realisierung im Rahmen der nicht-technischen Ver-suche geplant) wird für jede der Kombinationen das Zutreffen der Kriterien angegeben. Zusätzlich ist jeweils ein Feld für Kommentare vorhanden.

R Kommentare R Kommentare R Kommentare R Kommentare R Kommentare

interne Flotte

externe Flotte

Fahrsim.

Verkehrssim.

Fahrsicherheit Verkehrssicherheit

Testgelände

Versuchsumgebung

Feld

Simulation

Akzeptanz Fahreffizienz Verkehrseffizienz

2.1.1.5 Ergebnis der Erweiterten Versuchsmatrizen Im Rahmen von AP13 wurde festgelegt, welche nicht-technischen Fragestellungen des je-weiligen Anwendungsfalles in welcher Versuchsumgebung überprüft werden sollen. Veran-schaulicht durch ein „X“ gibt Tabelle 2 darüber einen Überblick.

Zusammenfassend wird aus Tabelle 2 folgendes deutlich:

• Mit der internen Flotte im Versuchsgebiet und auf dem Testgelände können viele An-wendungsfälle bzgl. unterschiedlicher nicht-technischer Fragestellungen untersucht werden.

• Die externe Flotte dient überwiegend zur Überprüfung der Nutzerakzeptanz der einzel-nen Anwendungsfälle.

• In der Fahrsimulation können nicht-technische Fragestellungen zur Nutzerakzeptanz, Fahreffizienz und Fahrsicherheit überprüft werden.

• In der Verkehrssimulation können die nicht-technischen Fragestellungen zu Fahr- und Verkehrseffizienz sowie zur Verkehrssicherheit adressiert werden.

Die erstellten und ausgefüllten Erweiterten Versuchsmatrizen waren Grundlage für weitere Arbeiten im AP13 bei der Erstellung von Versuchsfällen und wurden an AP41 „Versuchsde-sign“ zur Erstellung eines Prüfkonzepts sowie zur Erstellung der Drehbücher übergeben.


Tabelle 2: Auflistung der in simTD geplanten Anwendungsfälle (veranschaulicht durch ein „X“) in Abhängigkeit der nicht-technischen Fragestellung und Versuchsumgebung. (In der Erweiterten Versuchsmatrix: Realisierung im Rahmen der nicht-technischen Versuche geplant - Abkürzungen: „N“ Nutzerakzeptanz, „FE“ Fahreffizienz, „VE“ Ver-kehrseffizienz, „FS“ Fahrsicherheit und „VS“ Verkehrssicherheit).

Interne Flotte

Versuchsgebiet Interne Flotte Testgelände

Externe Flotte Fahrsimulation Verkehrssimulation

Nicht-technische Fragestellung

Anwendungsfall

N FE VE FS VS N FE VE FS VS N FE VE FS VS N FE VE FS VS N FE VE FS VS

A_1.2.1.2 Streckenbezo-gene Anzeige Durch-schnittsgeschwindigkeit

X X X X X O O O O O X O O O O X X O X O O X X O X

A_1.2.1.3 Ortsbezogene Anzeige von Hindernissen X O O X X O O O O O X O O O O X O O X O O O O O O

A_1.2.1.4 Ortsbezogene Anzeige von Straßenwet-ter

X O O X O O O O O O X O O O O X O O O O O O O O O

A_1.2.2.1 Streckengeo-metrie im Umfeld der Baustelle

X X X X X O O O O O X O O O O X O O X O O O O O O

A_1.2.2.2 Verkehrslage im Umfeld der Baustelle X X X X X O O O O O X O O O O O O O O O O X X O X

A_1.2.3.2 Dynamische Routenplanung X X O O O O O O O O X X O O O O O O O O O X X O O

A_1.3.1.1 Umleitungsemp-fehlung X X O O O O O O O O X X O O O O O O O O O X X O O

A_1.3.2.1 Optimierung des LSA-gesteuerten Ver-kehrsflusses

O X X O O O O O O O O O X O O O O O O O O X X O O

A_1.3.3.1 Priorisierung ÖPNV O O O O O O X O O O O O O O O O O O O O O X X O O

A_1.3.3.2 Priorisierung Einsatzfahrzeug O O O O O O X O O O O O O O O O O O O O O O O O O


Interne Flotte




Anwendungsfall


A_1.3.3.3 Reduzierung von Wartezeiten des Indi-vidualverkehrs

O X X O O O X X O O O O O O O O O O O O O X X O O

A_2.1.1.2 Warnung vor liegengebliebenem Fahr-zeug

X O O X O O O O O O X O O O O X O O X O O X X O X

A_2.1.1.4 Baustellenwar-nung X O O X O O O O O O X O O O O X O O X O O X X O X

A_2.1.1.5 Hindernisse auf der Fahrbahn X O O X O O O O O O X O O O O X O O X O O X X O X

A_2.1.2.1 Warnung vor Stauende X X O X X O O O O O X O O O O X O O X O O X X O X

A_2.1.3.1 Warnung vor Wettergefahren X o O X O O O O O O X O O X O X O O X O O O O O O

A_2.1.4.1 Warnung vor sich näherndem Einsatz-fahrzeug

X O O X O X X O X O X O O O O X O O X O O O O O O

A_2.2.1.1 Verkehrszei-chenanzeige im Fahrzeug X X X X X O O O O O X X O O O X X O X O O X X O X

A_2.2.1.2 Warnung bei Nichtbeachtung von Ver-kehrszeichen

X X X X X O O O O O X X O O O X X O X O O X X O X

A_2.2.2.1 Grüne Welle X X X X X X X X X X X O O O O X X O X O O X X O X

A_2.2.2.2 Restrotanzeige X X X X X X X X X X X O O O O X X O X O O X X O O


Interne Flotte




Anwendungsfall


A_2.2.2.3 Warnung vor Rotlichtverstoß mit Aus-prägungen

X O O X X X O O X O O O O O O X O O X O O O O O O

A_2.2.3.4 Elektronisches Bremslicht O O O O O X O O X O O O O O O X O O X O O O O O X

A_2.2.4.1 Querverkehrs-assistent X O O X O X O O X X X O O X O X O O X O O O O O O

A_3.1.1.7 Internetbasierte Übertragung von Ver-kehrsdaten

X X O O O O O O O O X O O O O O O O O O O O O O O

A_3.1.2.3 Kommunalinformationen X O O O O O O O O O X O O O O O O O O O O O O O O

A_3.1.2.4 Parksituation X X O O O O O O O O X O O O O O O O O O O O O O O


2.1.1.6 Erstellung nicht-technischer Versuchsfälle Ausgehend von den Ergebnissen der Erweiterten Versuchsmatrizen wurden in AP13 nicht-technische Versuchsfälle pro Anwendungsfall konzipiert. Für die Versuchsumgebungen in-terne Flotte, (teilweise und in vereinfachter Form auch für die) externe Flotte, Testgelände sowie Fahr- und Verkehrssimulation wurden pro Anwendungsfall erste nicht-technische Ver-suchsfälle von TUM-VT und IZVW als Diskussionsgrundlage für die FETs erstellt. Diese wurden im zweiten Schritt von den FETs kommentiert und ergänzt. Die Konsolidierung der nicht-technischen Versuchsfälle erfolgte in einer gemeinsamen Diskussion mit TUM-VT, IZVW und den FETs. Die Ergebnisse werden im Anhang des Deliverables D13.2 (Anhang 3) vorgestellt.

Bei simTD-Funktionen der Hauptfunktion 1.1 werden keine nicht-technischen Validierungszie-le adressiert. Die entsprechenden Funktionen (sog. Basisfunktionen) sind Grundlage für an-dere simTD-Funktionen und werden durch die technischen Tests und Versuche geprüft (siehe Tabelle 22 und Tabelle 26). Es findet für diese simTD-Funktionen keine direkte Interaktion mit dem Fahrer statt. Daher wurden für diese keine nicht-technischen Versuche konzipiert.

Tabelle 3 veranschaulicht an einem Versuchsfall mögliche beteiligte Fahrer- bzw. Fahrzeug-gruppen der internen oder externen Flotte.

Tabelle 3: Übersicht über an einem Versuchsfall mögliche beteiligte Fahrer- bzw. Fahrzeuggruppen.

Fahrzeuge

Fahrer-Info/Warnung Kommunikation Logging für

Auswertung

simTD komplett X X X

simTD ohne Fahrer-Information - X X

simTD ohne Fahrer-Information und ohne Kommunikation - - X

Fremdfahrzeuge - - -

Die Gruppe simTD komplett beteiligt sich an der C2X-Kommunikation, um sicherzustellen, dass der Anwendungsfall technisch funktioniert. Dabei werden für die Auswertung relevante Daten geloggt und die Fahrer der Gruppe erhalten gemäß dem Anwendungsfall eine Infor-mation und/ oder Warnung.

Die Gruppe simTD ohne Fahrer-Information beteiligt sich ggf. an der C2X-Kommunikation, um sicherzustellen, dass der Anwendungsfall technisch funktioniert und es werden für die Aus-wertung relevante Daten geloggt. Die Fahrer dieser Gruppe erhalten keine Information und/oder Warnung. Es wird jedoch mitgeloggt, wann die Fahrer eine Information bzw. War-nung erhalten hätten.

Die Gruppe simTD ohne Fahrerinformation und ohne Kommunikation beteiligt sich nicht an der C2X-Kommunikation, es werden aber für die Auswertung relevante Daten geloggt. Die Fahrer der Gruppe erhalten keine Information und/oder Warnung. Diese Gruppe ist ins-besondere relevant für Anwendungsfälle, die ohne Information oder Warnung für den Fahrer ablaufen, wie z.B. A_1.3.3.3 Reduzierung von Wartezeiten des Individualverkehrs.

Zur Gruppe der Fremdfahrzeuge gehören alle nicht-simTD-Fahrzeuge, d.h. sie können sich nicht an der C2X-Kommunikation beteiligen, es können keine Daten geloggt werden und die Fahrer der Gruppe erhalten keine Information und/oder Warnung.


Die konsolidierten Versuchsfälle (siehe Anhang 3 des Deliverables D13.2) wurden für die Erstellung von Versuchsszenarien und Drehbüchern an AP41 „Versuchsdesign“ übergeben. Folgende Informationen sind pro Versuchsfall u.a. enthalten:

• Versuchsobjekt (z.B. F_2.1.2)

• Beziehungen zu anderen Anwendungsfällen/Funktionen

• Beschreibung des Anwendungsfalls

• Autor

• Versuchsumgebung

• Versuchsschritte

• Aktoren (z.B. Initialfahrzeug, Fahrzeuge mit (ohne) Information/Warnung, IRS)

• Verkehrliche Randbedingungen (z.B. Streckenart und Verkehrszustand und deren Priorisierung aus Sicht der FET)

• Technische Randbedingungen (z.B. Ausstattungsrate IVS, Ausstattungsdichte IVS oder Übertragungsmedium und deren Priorisierung aus Sicht der FET)

• Vorbedingungen für den Versuchsfall

• Adressierte Validierungsziele

• Erste Sammlung von Messgrößen Jeder Versuchsfall kann somit mehrere Variationen beinhalten, wodurch eine Vielzahl an Versuchsfallvarianten hervorgehen kann. Die Zusammensetzung der Varianten wird in der ID verdeutlicht. Pro Versuchsfall sind dadurch theoretisch mindestens 432 Versuchsfallvarian-ten möglich, wodurch für die Versuchsdurchführung die Notwenigkeit einer Priorisierung ver-deutlicht wird. Tabelle 4 gibt einen Überblick über die derzeitige Anzahl an Versuchsfallvaria-tionen pro Versuchsumgebung.

Tabelle 4: Übersicht über die Anzahl an Versuchsfallvariationen pro Versuchsumgebung (Stand: März 2010).

Versuchsumgebung Anzahl Versuchsfallvariationen

Interne Flotte 374

Testgelände 62

Fahrsimulation 145

Verkehrssimulation 508

Hinweis: Die externe Flotte ist nicht kontrollierbar, da die Fahrer selbstbestimmt im Versuchsgebiet oder außerhalb unterwegs sind (z.B. Pendler in privaten Fahrzeugen oder Mitarbeiter eines Unternehmens in Dienstfahrzeugen). Der Fokus liegt bei der externen Flot-te auf der Auswertung und nicht auf der Versuchsplanung. Deshalb wurden in AP13 für diese Versuchsfälle keine detaillierten Beschreibungen zu Aktoren, verkehrlichen und technischen Randbedingungen sowie zu den Validierungszielen vorgenommen.

Anhand der großen Anzahl an Versuchsfallvarianten pro Versuchsumgebung ist ersichtlich, dass im Zuge von AP41 eine Überprüfung erfolgen muss, z.B. welche Versuchsfallvariatio-nen für die Wirkungsanalyse und Bewertung in TP5 Bewertung und Rahmenbedingungen

https://svn.simtd.de/trac/sim-td/wiki/Versuchsgebiet�


benötigt werden. Die Versuchsfallvariationen müssen für die Versuchsdurchführung dement-sprechend priorisiert werden (für das weitere Vorgehen siehe Kap. 2.5).

2.1.2 Technische Test- und Versuchsfälle

Die technischen Versuche basieren auf den in AP12 definierten Validierungs-, Charakterisie-rungs- und Optimierungszielen (siehe Glossar) sowie auf die den Validierungszielen zu-geordnete Bewertungsmetriken und Kenngrößen (siehe Deliverable D12.2 „Validierungs- und Optimierungsziele, Metriken und Methoden“). Diese bilden die Grundlage für eine sys-tematische Charakterisierung, Validierung und Optimierung der in simTD entworfenen und entwickelten Komponenten, Systeme und Funktionen.

2.1.2.1 Berücksichtigung der Validierungsziele Die Ableitung der Validierungs- und Optimierungsziele (siehe Glossar) erfolgte entlang der in ISO/IEC 9126-1 (2001) und ISO/IEC TR 9126-2 (2003) definierten Qualitätseigenschaften für Software-intensive Systeme. Sie ist geleitet durch die in der simTD-Vorhabensbeschreibung definierten Projektziele sowie durch die in Deliverable D5.1 „Anforderungskatalog an den Feldtest“ definierten technischen Bewertungskriterien für den Feldversuch. Im Folgenden ist eine gekürzte Fassung eines Fragenkatalogs dokumentiert, der einen Überblick über die aus TP5 adressierten Anforderungen ermöglicht (die vollständige Liste findet sich auf S.22).

• Wie zuverlässig und sicher arbeitet das Gesamtsystem und die einzelnen Komponen-ten für die jeweiligen Funktionen/Anwendungsfälle?

• Ist die ausgewählte Übertragungstechnik für die jeweilige Funktion/den Anwendungs-fall geeignet?

• Wo sind die Grenzen und das Leistungsspektrum der jeweiligen Kommunikations-technologie (802.11p, 802.11 b/g, Mobilfunk)?

• Wie ist die Reaktionszeit des Systems in Abhängigkeit der Ausstattungsrate und der Funktionen / Anwendungsfälle und Funktionsbündel?

• Ist die realisierte IT-Sicherheit/Informationssicherheit für die Funktionen/ Anwen-dungsfälle ausreichend bzw. bei welchen Systemen, Funktionen/Anwendungsfälle traten Probleme auf?

Bei den in simTD entwickelten Systemen handelt es sich um Softwaresysteme, die sich mit gängigen Methoden und Herangehensweisen prüfen und validieren lassen. Durch ihre spe-zielle Einsatzform weisen diese Systeme jedoch Charakteristiken auf, die zusätzlich dazu einer gesonderten Betrachtung unterzogen werden müssen und die technische Optimierung, Charakterisierung und insbesondere die technische Validierung erschweren. Hierzu zählen:

• Die Verteiltheit des Systems

• Die Mobilität der Teilsysteme, insbesondere der Fahrzeuge

• Sicherheitsaspekte durch Eingriff in den Straßenverkehr

• Kommunikation über unsichere Medien (Funkverbindungen)

Insgesamt wurden im Zuge der Arbeiten in AP12 über 200 Validierungsziele (siehe Glossar) für einzelne Funktionen bzw. das Kommunikationssystem, die IT Sicherheit und verschiede-ne Ausstattungsmerkmale definiert. Die technischen Validierungsziele für die Funktionen


bzw. des Kommunikationssystems ließen sich den in der ISO/IEC 9126-1 (2001) definierten Kategorien Funktionalität, Zuverlässigkeit und Effizienz1 zuordnen. Die Validierungsziele der Ausstattung sowie zum Sicherheitssystem wurden separat definiert. Tabelle 5 gibt einen kurzen Überblick über die Anzahl bzw. Verteilung dieser Validierungszie-le auf die verschiedenen Teilsysteme bzw. Aspekte des simTD Systems (drei Hauptfunktionen (HF), das Kommunikationssystem, IT-Sicherheit, Ausstattung). Die in Klammern angegebe-nen Werte beschreiben zusätzliche Validierungsziele, die als funktionsübergreifend formuliert worden sind und von allen Funktionen realisiert werden sollten.

Tabelle 5: Anzahl von Validierungszielen in Bezug zu Funktionen, Kommunikationssystem, IT-Sicherheit, Ausstat-tung.

Funktionalität Zuverlässigkeit Effizienz Sonstige ∑

HF_1.x 31 (+2) 8 (+4) 2 (+6) 0 41 (+12)

HF_2.x 47 (+2) 23 (+4) 5 (+6) 0 75 (+12)

HF_3.x 16 (+2) 14 (+4) 2 (+6) 0 32 (+12)

Kommunikation 20 15 6 0 41

IT-Sicherheit 0 0 0 10 10

Ausstattung 0 0 0 2 2

∑ VZ 114 (+6) 60 (+12) 15 (+18) 12 201 (+36)

Ursprünglich vorgesehen war eine vollständige Abdeckung aller definierten Validierungsziele durch die in AP13 definierten Tests und Versuche. Schnell wurde jedoch deutlich, dass die große Anzahl der dadurch entstehenden Tests und Versuche die Möglichkeiten der Realisie-rung im Projekt sprengen würde. In einem ersten Auswahlverfahren hatten die spezifizieren-den Spezialistenteams (FETs, Kommunikationsteam, Team IT-Sicherheit) die Möglichkeit einzelne Validierungsziele im Rahmen der Test- und Versuchsspezifikation begründet zu-rückzuweisen. Dies hatte zur Folge, dass kein Test bzw. Versuch für dieses Validierungsziel spezifiziert werden musste. Die zurückgewiesenen Validierungsziele und die entsprechen-den Begründungen sind im Deliverable D13.2 dokumentiert.

2.1.2.2 Grundlage Test- und Versuchsspezifikation Im Rahmen von AP13 wurden auf Basis der Validierungsziele (siehe Glossar) Test und Ver-suchsspezifikationen für die 21 C2X-Funktionen sowie zur Validierung der Systemaspekte Ausstattung, Grenzen der Kommunikationstechnologie, IT-Sicherheit und bessere Ortung definiert. Die Spezifikation erfolgte durch Expertenteams (FETs, Kommunikationsteam, IT-Sicherheitsteam) bzw. durch Einzelpersonen. Grundlage für die Spezifikation war ein Test- und Versuchsfalltemplate, welches speziell auf die Gegebenheiten der technischen Tests und Versuche zugeschnitten wurde. Tabelle 6 zeigt eine Übersicht über die einzelnen Felder des Templates, die im Rahmen der Test- und Versuchsspezifikation zu befüllen waren. Eine detaillierte Erläuterung des Templates findet sich in Deliverable D13.2.

1 Die ISO ISO/IEC 9126-1 unterscheidet grundsätzlich zwischen internen, externen und nutzungsori-entierten Qualitätseigenschaften. Die hier aufgeführten Begriffe Funktionalität, Zuverlässigkeit und Effizienz werden im Sinne der internen und externen Qualitätseigenschaften verwendet. Sie ermögli-chen eine technische Beurteilung des Systems und unterscheiden sich dadurch grundsätzlich von der nutzungsorientierten Sicht der nicht technischen Systemvalidierung.


Tabelle 6: Technisches Test- und Versuchsfalltemplate.

ID Eindeutiger Bezeichner des Test-/Versuchsfalls

Testobjekt Eindeutige Bezeichnung des Testobjekts

Kurzbezeichnung Eindeutige Kurzbeschreibung zum schnellen Erfassen des Inhalts.

Beschreibung Informelle Beschreibung des Tests/Versuch

Autor Autor und Firma der Spezifikation

Validierungs-/Optimierungs-/Charakterisierungsziel

Referenz auf das Validierungs- / Optimierungs- /Charakterisierungsziel gemäß Deliverable D12.2

Testfall-Priorität Hoch, Mittel, Gering

Testart Validierung, Optimierung, Charakterisierung

Testort Prüfstand, Simulation, Testgelände, Versuchsgebiet interne Flotte, Versuchsgebiet interne Flotte naive Fahrer, Versuchsgebiet interne Flotte Expertenfahrer

Testdurchführungsmethode Beschreibung der Testdurchführungsmethode (z.B. Anzahl der Versuche)

Referenz auf Funktionsspe-zifikation

Hauptbezug zu Kap. 4 der Funktionsspezifikation.

Systemanforderung vor Testdurchführung

Beschreibung der für die Validierung/ Optimierung/ Charakterisie-rung notwendigen Ausgangssituation und seinen Vorbedingungen.

Testkonfiguration 1 Beschreibung des Umfelds für diesen Test/Versuch

Testschritte Liste der Testschritte.

Variationen Optionales Feld, falls Variation(en) der Validierung/Optimierung/ Charakterisierung durchgeführt werden sollen.

Auswertungskriterium

Spezifikation der für die Auswertung notwendigen Prüfkriterien für die Auswertung des Tests/Versuchs

Testkonfiguration 2…N 1..(N-1) Wiederholungen der Felder Testschritte, Variationen Aus-wertekriterium analog zu Testkonfiguration 1

„Zutatenliste“ Genaue Beschreibung der benötigten Objekte, z.B. Anzahl weite-rer Fahrzeuge. Bezeichnungen wie ca., etwa, … sind zu vermei-den. Min/Max Angaben sind in Ordnung.

Messgrößen, Logginggrößen

Aufzuzeichnende Messgrößen entsprechend Deliverable D12.2 oder der Messgrößendatenbank des AP24

Fahrerbeurteilung Beschreibung der Fragen, die dem Probanden gestellt werden müssen, sofern dies für den Test/Versuch notwendig ist.

Gültigkeitskriterium Optionales Feld, das bestimmt, ob die Testdurchführung gültig war, möglichst Vor-Ort prüfbar.

Anmerkungen Optionales Feld, nicht relevant für Testdurchführung. Anmerkun-gen, welche in keine anderen Felder passen.

Anmerkung: Bei der Spezifikation der technischen Versuchsfälle in AP13 wurde zwischen der internen Flotte mit Expertenfahrern und der internen Flotte mit naiven Fahrern unter-schieden. Dabei wurde davon ausgegangen, dass zum Zeitpunkt der Versuchsdurchführung


20 Expertenfahrer und 80 naive Fahrer zur Verfügung stehen würden. Im Rahmen von Kap. 7.1.2 wird dargestellt, dass dieses Fahrerkonzept nachfolgend zu diskutieren ist.

Insgesamt wurden im Zuge der AP13 Arbeiten 145 technische Test- und Versuchsfälle spe-zifiziert und im Deliverable D13.2 dokumentiert. Die zahlenmäßige Verteilung der Test- und Versuchsfallspezifikationen auf die drei Hauptfunktionen bzw. auf die Aspekte Kommunikati-on, IT-Sicherheit und Ausstattung lässt sich der Tabelle 7 entnehmen. Darüber hinaus zeigt die Tabelle, wie sich die technischen Test- und Versuchsfälle auf die einzelnen Validierungs-zielkategorien Funktionalität, Effizienz und Zuverlässigkeit beziehen. Der Bezug auf nicht-kategorisierte Ziele wird in der Tabelle unter „Sonstiges“ geführt.

Tabelle 7: Anzahl der Test und Versuchsfallspezifikationen in Relation zu den Validierungszielen.

Funktionalität Zuverlässigkeit Effizienz Sonstige ∑ TF

HF_1.x 29 6 8 1 44

HF_2.x 32 7 5 0 44

HF_3.x 4 2 3 0 9

Kommunikation 9 7 3 6 25

IT-Sicherheit 8 7 0 1 16

Ausstattung 0 1 2 3 6

Bessere Ortung 0 0 0 1 1

145

Im Rahmen der Test- und Versuchsspezifikation wurde für jeden technischen Test- bzw. Versuchsfall eine explizite Zuordnung zu den möglichen Ausführungsumgebungen bzw. Flot-ten vorgenommen (siehe Feld „Testort“ in Tabelle 6). Dabei war die Angabe mehrerer Aus-führungsumgebungen bzw. Flotten möglich.

Eine explizite Zuordnung der einzelnen Test- und Versuchsfälle zu den Teilprojekten TP3 und TP4 konnte aus zeitlichen und inhaltlichen Gründen im Rahmen der D13.2-Arbeiten nicht durchgeführt werden. Diese wurde in einem nachträglichen Prozess als Auswertung des Deliverable D13.2 durch Mitglieder des TP3 und des TP4 begonnen. Die vorläufigen Ergebnisse liegen zum Zeitpunkt der Berichtslegung vor, werden aber im Rahmen der TP3 und TP4 Abstimmungen weiter verfeinert. Die im Folgenden aufgeführte Darstellung der für TP4 relevanten Test- und Versuchsfälle beruht auf diesen vorläufigen Ergebnissen.

2.1.2.3 Tests und Versuche für das TP4

Die technischen Versuche im TP4 bestehen grundsätzlich aus

• funktionsbezogenen Versuchen die die Validierungsziele Effizienz, Funktionalität (d.h. Richtigkeit) und Zuverlässigkeit für einzelne Funktionen prüfen werden (sog. Funkti-onsversuche),

• Ausstattungsversuchen, die abhängig von der IRS Dichte bzw. der Durchdringung mit simTD-Fahrzeugen (IVS Ausstattung) die technischen Grenzen für einzelne Funktio-nen sowie das Kommunikationssystem ermitteln,

• Versuchen zur Prüfung der IT-Sicherheit (sog. IT-Sicherheitsversuche) sowie

• Versuchen, die die Grenzen des Kommunikationssystems in Abhängigkeit von der gewählten Kommunikationstechnologie (Mobilfunk, Geocast Server, 802.11p, 802.11 b/g) vermessen (sog. Kommunikationsversuche).


Tabelle 8: Zusammenfassung der technischen Versuchsfälle für das TP4 (Diskussionsstand: März 2010).

Valid

ieru

ng

Opt

imie

rung

Cha

rakt

eris

ieru

ng

Prüf

stan

d

Sim

ulat

ion

Test

gelä

nde

exte

rne

Flot

te

naiv

e Fa

hrer

Expe

rten

fahr

er

Max

. Fah

rzeu

ge

Funk

tiona

lität

Zuve

rläss

igke

it

Effiz

ienz

Funktionsversuche HF1 25 6 6 8 7 5 10 17 8 22 5 6 Fahrzeugseitige Datenerfassung 0 0 5 0 0 0 5 0 0 2 3 0

Ermittlung der Verkehrswetterlage 1 0 0 0 0 0 1 1 1 min 10 1 0 0

Ermittlung der Verkehrslage 2 1 0 0 1 0 1 1 1 bis 100 2 0 0

Straßenvorausschau 2 1 0 2 2 2 0 0 1 min 6 2 0 1

Baustelleninformationssystem 8 1 0 4 0 0 0 9 3 50 (40) 5 1 2

Erweiterte Navigation 3 1 0 1 3 0 0 2 1 2 1 1

Umleitungsmanagement 2 1 0 0 0 0 1 1 1 2 0 0

Lichtsignalanlagen Netzsteuerung 2 1 1 0 0 0 1 3 0 100 4 0 0 Lokale verkehrsabhängige LSA-Steuerung 5 0 0 1 1 3 1 0 0 300 2 0 2

HF2 20 14 0 3 0 19 16 17 24 22 5 6 Hinderniswarnung 2 6 0 3 0 4 2 5 4 100 5 1 2

Stauendewarnung 3 0 0 0 0 0 0 1 2 20-50 2 0 0

Straßenwetterwarnung 3 1 0 0 0 1 1 2 2 5 3 0 0

Einsatzfahrzeugwarnung 3 0 0 0 0 2 0 2 2 91 2 1 0 Verkehrszeichen-Assistent/Warnung 1 0 0 0 0 1 1 1 1 1 1 0 0

Ampel-Phasen-Assistent/Warnung 4 1 0 0 0 3 2 2 5 1 3 2 0

Längsführungsassistent 0 0 0 0 0 0 0 0 0 0 0 0

Kreuzungs-/Querverkehrsassistent 4 6 0 0 0 8 0 4 8 min 2 8 0 0

HF3 8 0 1 1 0 0 3 3 9 4 2 3 Internetbasierte Dienstnutzung 3 0 0 1 0 0 0 0 3 1 1 1 1

Standortinformationsdienste 5 0 1 0 0 0 3 3 6 1 3 1 2

Kommunikationsversuche 3 0 10 0 0 2 8 8 11 50 3 6 3 IT-Sicherheit 2 0 0 0 0 2 2 2 2 2 2 0 Ausstattung 2 2 1 0 0 0 0 3 4 0 0 2 Ausstattung IRS 2 0 1 0 0 0 0 1 3 0 0 0

Ausstattung IVS 0 2 0 0 0 0 0 2 1 0 0 2

SUMME 52 22 17 11 7 28 36 47 49 49 18 17


Tabelle 8 zeigt einen Überblick über alle derzeit dem TP4 zugeordneten technischen Ver-suchsfälle. Die Tabelle benennt jeweils die Anzahl der geplanten Versuche pro Funktion bzw. pro Systemaspekt. Darüber hinaus wird aufgeschlüsselt, wie viele Versuche jeweils welches Validierungsziel adressieren, wie viele Versuche jeweils welchen Testort anvisieren und was die maximale Anzahl der benötigten Fahrzeuge ist. Ist bei der maximal benötigten Fahrzeuganzahl ein Ausdruck in Klammern angegeben, so handelt es sich um die ge-wünschte Anzahl von Expertenfahrern.

Anmerkung: Bei der Spezifikation der technischen Versuchsfälle in AP13 wurde zwischen der internen Flotte mit Expertenfahrern und der internen Flotte mit naiven Fahrern unter-schieden. Dabei wurde davon ausgegangen, dass zum Zeitpunkt der Versuchsdurchführung 20 Expertenfahrer und 80 naive Fahrer zur Verfügung stehen würden. Im Rahmen von Kap. 7.1.2 wird dargestellt, dass dieses Fahrerkonzept nachfolgend zu diskutieren ist.

2.1.2.4 Weiteres Vorgehen im TP4 Im Rahmen der bisherigen Spezifikationsarbeiten haben sich jeweils Spezialistenteams um die Definition der Versuchsfälle gekümmert. Für die Operationalisierung der Spezifikationen (Drehbuchentwicklung), die fachliche Begleitung der Versuchsdurchführung sowie die Aus-wertung werden im TP4 ähnliche Spezialistenteams benötigt.

Abbildung 3 zeigt die vier oben benannten Schwerpunkte (Funktionen, Kommunikation, Aus-stattung und Sicherheit) der technischen Versuche als separate Säulen für die Versuchspla-nung, Durchführung und Auswertung im TP4. Am Fuß der Säule ist jeweils ein TP-übergreifendes Spezialistenteam benannt, das für die inhaltliche Betreuung des gesamten Versuchsprozesses zuständig ist. Während sich die Zusammensetzung der Gruppen und ihre Zuständigkeiten für das TP1 und das TP3 direkt aus der simTD-Vorhabensbeschreibung ableiten lassen, ist dieses für das TP4 nicht möglich. Grundsätzlich ist anzustreben, dass zwischen den Teilprojekten, die sich mit der Spezifikation, Durchführung und Auswertung technischer Tests und Versuche befassen, diese Teams fortbestehen und durchgängig mit denselben Personen besetzt werden. Insbesondere für die Organisation der Funktionsversu-che und der Kommunikationsversuche besteht erhöhter Abstimmungsbedarf zwischen dem TP3 und dem TP4. Inwiefern dieses tatsächlich über TP-übergreifende Teams mit personel-ler Kontinuität realisiert werden kann, befindet sich derzeit in Klärung. Details sind nach Ab-schluss der AP33 Planungsarbeiten möglich.

Abbildung 3: Spezialistenteams für die technischen Versuche.


2.2 Möglichkeiten und Grenzen der Versuchsumgebungen

Jede der in simTD realisierten Versuchsumgebungen bietet bestimmte Möglichkeiten, aber auch Grenzen hinsichtlich der Versuchsdurchführung und -auswertung. Eine detailliertere Charakterisierung der einzelnen Versuchsumgebungen erfolgte im Kap. 2.1.1.2 Möglichkei-ten und Grenzen der jeweiligen Versuchsumgebungen werden im Folgenden kurz skizziert.

2.2.1 Feldversuch: Versuchsgebiet und Testgelände

Als „Realität“ wird in diesem Zusammenhang die Versuchsdurchführung mit realen Fahrzeu-gen und Fahrern auf einem realen Straßennetz bezeichnet und beinhaltet:

• Feldversuch im Versuchsgebiet mit interner Flotte und externer Flotte

• Versuche auf dem Testgelände mit interner Flotte Versuche mit der internen Flotte im Versuchsgebiet und Testgelände und auch die Fahrten der externen Flotte liefern Daten, die unter bestimmten Randbedingungen für die Auswer-tung und Analyse (AP43) sowie Bewertung (TP5) genutzt werden können.

Interne Flotte im Versuchsgebiet: Angeleitete Fahrer in angemieteten und mit simTD-Technologie ausgestatteten Fahrzeugen, welche von der Versuchsleitung Aufgaben gemäß vordefinierter Drehbücher (basierend auf Versuchsfällen aus AP13) erhalten und gezielt bestimmte Fahrsituationen aufsuchen bzw. realisieren.

Möglichkeiten:

• Liefert Fahrverhalten im realen Straßenverkehr in realen Situationen.

• Vergleich von Fahrzeugen „Mit Information/Warnung“ vs. „Ohne Information/ War-nung“ liefert Erkenntnisse über Fahreffizienz und Fahrsicherheit.

• Ermöglicht das gezielte Anfahren definierter und wiederholbarer Situationen zur Prü-fung technischer Eigenschaften unter realistischen Bedingungen.

Grenzen:

• Wirkungsermittlungen hinsichtlich Verkehrseffizienz und Verkehrssicherheit basieren auf detaillierten Einzelfahrzeugdaten aller Fahrzeuge (simTD- und Fremdfahrzeuge), welche in weiten Teilen aufgrund fehlender Datenerfassung nicht verfügbar sind.

• Gezielte Untersuchungen sicherheitskritischer Situationen sind aus ethischen Grün-den möglicherweise nicht vertretbar bzw. organisatorisch oft schwierig oder gar nicht umsetzbar. Beispiel: Das künstliche Erzeugen eines Staus (z.B. durch Fahrzeuge der Straßen-meisterei) ist aus Sicherheitsgründen nicht ohne weiteres möglich. Ebenso ist das künstliche Positionieren von Hindernissen nur möglich, wenn hieraus keine Gefähr-dung des umliegenden Verkehrs resultiert. Beispiel: Plötzliche, harte Stauenden sind nicht planbar und höchst dynamisch. Fahr-zeuge müssten kurzfristig zum richtigen Zeitpunkt am richtigen Ort sein.

Interne Flotte auf Testgelände: Angemietetes und geschlossenes Gelände, das mit für die simTD-Technologie notwendiger Infrastruktur ausgestattet ist und auf dem u.a. die Fahrer der internen Flotte eingesetzt wer-


den. Die Fahrer erhalten von der Versuchsleitung Aufgaben gemäß den Drehbüchern. Da das Gelände geschlossen ist, gibt es ausschließlich Verkehr, der durch die Versuchsleitung gesteuert wird. Die konkrete Ausgestaltung des Testgeländes ist zum Zeitpunkt der Berichts-legung noch nicht definiert.

Möglichkeiten:

• Vergleich von Fahrzeugen „Mit Information/Warnung“ vs. „Ohne Information/ War-nung“ unter vollkommen kontrollierten Bedingungen liefert zusätzliche Erkenntnisse über Fahreffizienz und Fahrsicherheit (auch bzw. gerade für Situationen, die im Feld nicht möglich wären; z.B. Hinderniswarnung).

• Alle Fahrzeuge auf dem Testgelände sind kontrollierbar, kein unbeeinflussbarer um-gebender Verkehr vorhanden.

• Das Funktionsverhalten kann auch für sicherheitskritische Situationen ohne Beteili-gung dritter in einer kontrollierten Umgebung geprüft werden.

• Evtl. Existenz zusätzlicher Messtechnik (z.B. HF-Messtechnik zur Vermessung der Funktechnologie) , die eine genauere Vermessung der Systemeigenschaften zulässt.

Grenzen:

• Gefahr einer Änderung des Fahrverhaltens, da sich Fahrer der Teilnahme an den simTD-Versuchen bewusst ist (sog. Reaktivität). Es werden somit Gewöhnungs- und Trainingsfahrten für die Versuchsfahrer notwendig. Dabei ist zu beachten, dass durch entsprechende Trainings möglicherweise auch die Prüfsituation geübt wird.

• Infrastruktur ist im Testgelände begrenzt (z.B. lediglich ein Knotenpunkt mit LSA vor-handen). Dies führt dazu, dass z.B. eine Netzsteuerung nicht realisierbar ist.

Externe Flotte im Versuchsgebiet: Fahrer, die selbstbestimmt im Versuchsgebiet unterwegs sind (z.B. Pendler in privaten Fahr-zeugen oder Mitarbeiter eines Unternehmens in Dienstfahrzeugen. Die genaue Zusammen-setzung ist zum Zeitpunkt der Berichtslegung noch nicht festgelegt). Die Fahrzeuge sind mit simTD-Technologie ausgestattet. Da die Fahrer sich frei bewegen, sind auch Fahrten außer-halb des Versuchsgebiets möglich, so dass nur für ausgewählte simTD-Funktionen eine C2X-Kommunikation möglich ist.

Möglichkeiten:

• Natürliches, unbeeinflusstes Fahrverhalten der Fahrer mit freier Routenwahl

• Ggf. große Stichproben für bestimmte Anwendungsfälle.

• Liefert Daten für die zentralseitigen Funktionen, die auf eine größerer Menge aktueller Fahrzeugdaten angewiesen sind (Stichwort Fahrzeuge als Sensoren).

Grenzen:

• Wenige Informationen über die aktuelle Situation, in der sich der Fahrer befindet, vor-handen (z.B. ist kein Abstandssensor vorhanden). Reagiert der Fahrer mit Verzöge-rung aufgrund der Warnung oder wg. des Vorderfahrzeugs?

• Keine Kontrollgruppe in der gleichen Situation, mit der die Daten verglichen werden könnten.

• Ggf. große Stichproben, aber welche Daten sind aggregierbar/vergleichbar?

• Ggf. keine Fahrzeuge in Kommunikationsreichweite, so dass keine oder nur selten Fahrzeug-zu-Fahrzeug-Kommunikation stattfindet.


2.2.2 Fahrsimulation

Simulationsumgebung, in der ein Fahrer durch eine virtuelle Szenerie fährt. Die Versuchsbe-dingungen (z.B. Wetter, umgebender Verkehr, Meldungen von simTD-Anwendungsfällen, Bebauung) sind kontrolliert herstellbar, d.h. durch die Versuchsleitung gesteuert.

Möglichkeiten:

• Sicherheitskritische Situationen können in der Fahrsimulation ohne Gefährdung der Versuchsteilnehmer untersucht werden.

• Gezieltes Herstellen und somit Reproduzierbarkeit der gewünschten Situationen. Die Rahmenbedingungen sind im Wesentlichen kontrollierbar. So kann verglichen wer-den, wie sich unterschiedliche Fahrer in identischen Situationen verhalten.

• Detaillierte mikroskopische Kenngrößen über das Fahrverhalten des Einzelnen zur Evaluation von Fahreffizienz und Fahrsicherheit vorhanden.

Grenzen:

• Keine Aussagen über das Fahrzeugkollektiv hinsichtlich Verkehrseffizienz und Ver-kehrssicherheit.

• Routenwahlverhalten bei der Fahrt nur schwer darstellbar, da keine originalgetreuen geografischen Gegebenheiten nachgebildet werden.

• Wetterbedingungen sind nur bedingt abbildbar.

• Die technischen Aspekte der C2X-Kommunikation können nicht originalgetreu nach-gebildet werden. Stattdessen werden die Systemmeldungen zu vordefinierten Zeit-punkten (z.B. 1000m vor Erreichen des Stauendes) eingespielt.

• Beherrschen des Simulatorfahrzeugs und Vermeiden von Simulatorübelkeit setzen voraus, dass die Fahrer im Fahrsimulator trainiert werden.

• Fahrerverhalten in Fahrsimulation kann sich möglicherweise von alltäglichen Fahr-verhalten im alltäglichen Verkehr unterscheiden. Dieser Gefahr wird durch Fahrertrai-nings begegnet.

2.2.3 Verkehrssimulation

Simulationsumgebung, in der sich viele Fahrer-Fahrzeug-Einheiten in einem virtuellen Abbild des Versuchsgebiets bewegen (mikroskopische Verkehrssimulation). Reale Verkehrszustän-de werden abgebildet und das durch die simTD-Anwendungsfälle geänderte Verhalten der Fahrer-Fahrzeug-Einheiten wird gemäß den Ergebnissen aus Fahrsimulation und Feldver-such modelliert.

Möglichkeiten:

• Gezieltes Herstellen der gewünschten Situationen. Die Rahmenbedingungen sind kontrollierbar.

• Die verkehrliche Wirkung eines Anwendungsfalls kann für z.B. unterschiedliche Aus-stattungsraten in sonst identischen Situationen und Verkehrszuständen verglichen werden.

• Detaillierte mikroskopische Kenngrößen über das Fahrverhalten des gesamten Fahr-zeugkollektivs zur Evaluation von Fahr-/Verkehrseffizienz und Verkehrssicherheit vorhanden.


• Situationen bzw. Versuchsvoraussetzungen, die sich aufgrund der beschränkten Pro-jektmittel nicht im Feld umsetzen lassen, können in der Simulation nachgestellt wer-den (Stichwort „hohe Ausstattungsraten“).

Grenzen:

• Nur wenn das geänderte bzw. vorhandene Fahrverhalten bekannt und modellierbar ist, können die Wirkungen mit Hilfe der Verkehrssimulation auf andere Ausstattungs-raten oder Situationen skaliert werden.

• Teilweise ist die Nachbildung bestimmter Anwendungsfälle nicht möglich bzw. wegen zu großen Aufwänden in Relation zu ggf. geringen zusätzlichen Erkenntnissen nicht sinnvoll (z.B. Warnung vor Einsatzfahrzeugen). Eine Übersicht der Anwendungsfälle, die in der Verkehrssimulation umgesetzt werden, findet sich in Kap. 5.2.8.

2.3 Durchführbarkeit von Versuchsfällen bei Eingriff in den Straßen-verkehr

Für den Funktionstest und die Wirkungsermittlung eines Teils der simTD-Funktionen bzw. Anwendungsfälle kann es notwendig sein, gezielt relevante Situationen im Straßenraum zu erzeugen. In simTD soll die Funktionsweise und Wirkung bestimmter Anwendungsfälle getes-tet und ermittelt werden. Eine Gruppe von 100 simTD Fahrzeugen soll gezielt und zum Teil in Pulks in diese Situationen geraten und es soll ermittelt werden, wie sich Fahrzeuge mit erhal-tener Warnung/Information im Vergleich zu Fahrzeugen ohne Warnung/Information verhal-ten. Da nicht verlässlich mit dem Eintreten solcher Situationen zu rechnen ist, müssen sie teilweise gezielt hergestellt werden und erfordern einen Eingriff in den Straßenverkehr.

Im Folgenden werden diesbezüglich relevante Situationen zunächst allgemein beschrieben und später durch die genauen Beschreibungen der geplanten Versuchsfälle präzisiert, wobei bei einigen Versuchsfällen eine Genehmigung der zuständigen Straßenverkehrsbehörde erforderlich sein wird. Um eine endgültige Genehmigung für diese speziellen Versuche zu bekommen, ist die zuständige Straßenverkehrsbehörde zeitgerecht mit der konkreten Situa-tion/Versuch anzufragen.

2.3.1 Allgemeine Zusammenstellung der zu erzeugenden Sondersituationen

Nachfolgend werden einige Sondersituationen für die Durchführung von Anwendungsfällen, wie sie in simTD gefordert bzw. geplant sind, dargestellt. Diese sind:

Künstliches Erzeugen von Hindernissen im Straßenraum

• Hindernis (z.B. Schaumstoffwürfel, verlorene Ladung, Kisten, evtl. mit Pylonen abge-grenzt oder nur Pylonen) auf einem Fahrstreifen einer Autobahn, Bundesstraße, Landstraße oder Stadtstraße

• Hindernis (z.B. Schaumstoffwürfel, verlorene Ladung, Kisten, evtl. mit Pylonen abge-grenzt oder nur Pylonen) auf einem Seitenstreifen einer Autobahn, Bundesstraße oder Landstraße

Künstliches Erzeugen von liegengebliebenen Fahrzeugen im Straßenraum

• „Pannenfahrzeuge“ auf einem Fahrstreifen einer Autobahn, Bundesstraße, Landstra-ße oder Stadtstraße


• „Pannenfahrzeuge“ auf einem Seitenstreifen einer Autobahn, Bundesstraße oder Landstraße

Gezielter Einsatz von Wander- bzw. Tagesbaustellen

• Warnanhänger von Wanderbaustellen auf einem Fahrstreifen einer Autobahn, Bun-desstraße, Landstraße oder Stadtstraße

Infrastrukturseitige Steuerungsverfahren: Lichtsignalsteuerung

• Wechsel zwischen der Art der Signalsteuerung während des Versuchszeitraums (simTD-Anwendungsfall „ein-“ und „ausschalten“; z.B. Dienstag: Lichtsignalsteuerung wie bisher und Mittwoch: Optimierte Lichtsignalsteuerung mit simTD System)

Infrastrukturseitige Steuerungsverfahren: Verkehrsbeeinflussung im übergeordneten Stra-ßennetz

• Informationen gezielt nicht bzw. erst zeitverzögert für das Umleitungsmanagement durch die kollektive Wechselwegweisung (inkl. RDS-TMC und online Services) be-rücksichtigen (z.B. Stau auf Hauptroute, die Umleitungsstrategie wird aber bewusst nicht bzw. erst zeitverzögert geschaltet)

• Informationen gezielt nicht bzw. erst zeitverzögert in den variablen Anzeigen der Streckenbeeinflussungsanlagen berücksichtigen (z.B. Stau auf Streckenabschnitt, die Warnung vor dem Stau wird aber bewusst nicht bzw. erst zeitverzögert geschaltet)

Gezieltes Erzeugen von Stau im Straßenraum

• Erzeugung eines künstlichen Staus (z.B. durch Reduktion eines oder mehrerer Fahr-streifen während Zeiten hoher Verkehrsnachfrage)

Einsatzfahrzeuge mit Sonderwegerecht

• Einsatzfahrten ohne realen Einsatz mit Sonderwegerecht und Blaulicht (z.B. planbare Übungsfahrten für Einsatzfahrzeugfahrer)

Verkleinerung des öffentlichen Parkraums

• Kurzfristige Verkleinerung des öffentlichen Parkraums in Niederrad durch das Sper-ren einzelner Teile

Einschränkung von Sichtweiten im Kreuzungsbereich

• Minimierung bzw. künstliche Verdeckung von Sichtweiten im Kreuzungsbereich (z.B. Parken eines LKW im Kreuzungsbereich)

2.3.2 Rückmeldung der zuständigen Straßenverkehrsbehörde hinsichtlich der Durchführbarkeit

Bezüglich der unter Kap. 2.3.1 genannten Sondersituationen wurde die Straßenverkehrsbe-hörde für Autobahnen und die Straßenverkehrsbehörde für städtische Straßen um eine Stel-lungnahme zu den Vorhaben gebeten. Das Ergebnis ist Tabelle 9 zu entnehmen.

Vorbemerkung: Die in Tabelle 9 vorgenommene Beurteilung der Machbarkeit seitens der Straßenverkehrsbehörde der Stadt Frankfurt am Main gilt nur vorbehaltlich einer Abstim-mung mit dem Verfasser des Rechtsgutachtens in AP53, einer Abstimmung mit dem Polizei-präsidium Frankfurt am Main und einer Abstimmung mit der obersten Straßenverkehrsbe-hörde des Landes Hessen (Hessisches Ministerium für Wirtschaft, Verkehr und Landesent-wicklung). Die Straßenverkehrsbehörde wird die erforderlichen Abstimmungsprozesse einlei-ten und das Ergebnis mitteilen.


Tabelle 9: Stellungnahme der Straßenverkehrsbehörden.

Eingriffsart Mach-barkeit: Ja/Nein

Kommentare, Bedingungen oder Einschränkungen

a) Künstliches Erzeugen von Hindernissen im Straßenraum

Autobahn eventuell

Das Erzeugen von Hindernissen auf einem Fahrstreifen ist nicht möglich – hier ist die dadurch zusätzlich entstehende Unfallgefahr zu hoch. Eine Einzelprüfung im Vorfeld der Versuche durch die zuständige Straßenverkehrsbehörde für ein Hin-dernis auf einem Seitenstreifen kann jedoch positiv ausfallen.

Städtisches Versuchsgebiet Ja

Unter Bezugnahme auf § 32 StVO (Verkehrshindernisse) wird die Straßenver-kehrsbehörde der Stadt Frankfurt am Main (SVB FFM) dem Aufsteller des Ver-kehrshindernisses die entsprechende Ausnahmegenehmigung zum Aufstellen des Hindernisses erteilen.

Eine Absicherung dieses Verkehrshindernisses gemäß § 17 StVO (Beleuchtung) bzw. gemäß der entsprechenden Vorschriften der VwV zur StVO zu den §§ 17 und 32 StVO wird vorausgesetzt.

Das Straßenverkehrsamt der Stadt Frankfurt am Main wird das Aufstellen des Hindernisses beim Baulastträger oder eines entsprechenden Vertreters veranlas-sen und trägt die entstehenden Kosten.

b) Künstliches Erzeugen von liegengebliebenen Fahrzeugen im Straßenraum

Autobahn eventuell

Es ist nicht möglich, ein Pannenfahrzeug auf einem Fahrstreifen von Autobahnen zu simulieren. Die zusätzliche Unfallgefahr ist durch das entstehende Hindernis zu hoch. Eine Einzelprüfung im Vorfeld der Versuche durch die zuständige Straßen-verkehrsbehörde für ein Pannenfahrzeug auf einem Seitenstreifen kann jedoch positiv ausfallen.


Unter Bezugnahme auf § 15 StVO (Liegenbleiben von Fahrzeugen) wird die Stra-ßenverkehrsbehörde der Stadt Frankfurt am Main (SVB FFM) dem Halter des Fahrzeuges, dass das liegengebliebene Fahrzeug darstellen soll, die entspre-chende Ausnahmegenehmigung zum „Liegenbleiben des Fahrzeuges“ erteilen.

Eine Absicherung dieses Verkehrshindernisses gemäß § 17 StVO (Beleuchtung) bzw. gemäß der entsprechenden Vorschriften der VwV zur StVO zu den §§ 17 und 32 StVO wird vorausgesetzt.

Das Straßenverkehrsamt der Stadt Frankfurt am Main wird das Fahrzeug, dass das liegengebliebene Fahrzeug darstellen soll, zur Verfügung stellen bzw. veran-lassen und trägt die entstehenden Kosten.

c) Gezielter Einsatz von Wander-Tagesbaustellen

Autobahn Nein

Ein gezielter Einsatz von Wander- bzw. Tagesbaustellen ist nicht möglich. Es besteht jedoch eine hohe Wahrscheinlichkeit, dass zur Zeit des Feldversuchs Tagesbaustellen auftreten werden. Diese können genutzt werden.

d) Infrastrukturseitige Steuerungsverfahren

Autobahn Nein

Ein Eingriff in das Umleitungsmanagement durch die kollektive Wechselwegwei-sung ist nicht möglich. Hier ist es nicht durchführbar, Umleitungsempfehlungen zeitversetzt oder gar nicht auszusenden.

Ebenfalls ist es nicht möglich, Anzeigen in den Streckenbeeinflussungsanlagen nicht oder zeitverzögert zu schalten.


Das Straßenverkehrsamt der Stadt Frankfurt am Main wird dafür Sorge tragen, dass die Funktion Netzsteuerung wahlweise FCD-Daten verarbeitet oder nicht.

Eine Ausnahmegenehmigung ist nicht erforderlich, da die simTD-Fahrzeuge wie alle anderen Kraftfahrzeuge am öffentlichen Straßenverkehr teilnehmen und somit die Regeln der StVO zu befolgen haben.


Eingriffsart Mach-barkeit: Ja/Nein

Kommentare, Bedingungen oder Einschränkungen

e) Gezieltes Erzeugen von Stau im Straßenraum

Autobahn Nein

Das Erzeugen von Stau durch die Sperrung einer oder mehrerer Fahrstreifen ist auf Grund der dadurch entstehenden Unfallgefahr nicht möglich. Vermutlich wird es aber während des Feldversuches im Versuchsgebiet Verkehrsstauungen ge-ben. Diese können für den Versuch genutzt werden


Das Straßenverkehrsamt der Stadt Frankfurt am Main wird die geforderte Situation entweder durch das Einrichten einer Baustelle oder durch Zeichen und Weisungen von Polizeibeamten (Verkehrskontrollen) herstellen. Dies muss noch mit dem Polizeipräsidium Frankfurt am Main abgestimmt werden.

Unter Bezugnahme auf § 36 StVO (Zeichen und Weisungen der Polizeibeamten) bzw. auf die Richtlinien zur Sicherung von Arbeitsstellen (RAS) wird die Straßen-verkehrsbehörde der Stadt Frankfurt am Main (SVB FFM) die entsprechende Ausnahmegenehmigung erteilen.

Das Straßenverkehrsamt der Stadt Frankfurt am Main wird die erforderlichen Maßnahmen veranlassen und trägt die entstehenden Kosten.

f) Einsatzfahrzeuge mit Sonderwegerecht

Autobahn Nein Ein Einsatz von z.B. Fahrzeugen mit Blaulicht ohne realen Einsatz ist nicht mög-lich, da hierdurch andere Verkehrsteilnehmer Schaden nehmen könnten.

Städtisches Versuchsgebiet

Noch in Prüfung

Gemäß § 38 StVO (Blaues Blinklicht und gelbes Blinklicht) darf blaues Blinklicht nur von den damit ausgestatteten Fahrzeugen und nur zur Warnung an Unfall- oder sonstigen Einsatzstellen verwendet werden.

Es muss mit dem Verfasser des Rechtsgutachtens und dem Polizeipräsidium Frankfurt am Main noch geprüft werden, ob die im simTD-Feldversuch hergestell-ten Situationen dies zulassen, wenn eine entsprechende Ausnahmegenehmigung vorliegt.

Sollte dies nicht möglich sein, muss geklärt werden, ob nicht alleine die entspre-chenden CAM- und DEN-Meldungen ausreichen, ohne dass das blaue Blinklicht und/oder das Einsatzhorn eingeschaltet werden.

g) Verkleinerung des öffentlichen Parkraums

Städtisches Versuchsgebiet Nein

Eine Verkleinerung des öffentlichen Parkraums ist nicht möglich, da es sich um bewirtschaftete Parkhäuser handelt.

Darüber hinaus werden die Daten, die der Anwendungsfall erhält, vom Server des städtischen Parkleitsystems erzeugt. Dieser wird nicht beeinflusst, denn die Daten werden auf den Anzeigeelementen des Parkleitsystems angezeigt, auf dem städti-schen Internetauftritt www.mainziel.de veröffentlicht und an Dienstanbieter wie den ADAC und den Hessischen Rundfunk weitergeleitet.

h) Einschränkung von Sichtweiten im Kreuzungsbereich

Städtisches Versuchsgebiet Nein

Diese Situation ist nur an nicht-lichtsignalgeregelten Knotenpunkten vorstellbar.

Es befinden sich im Versuchsgebiet nur lichtsignalgeregelte Knotenpunkte.

Das komplette Abschalten einer Lichtsignalanlage für die Herstellung dieser Situa-tion wird nicht gestattet.

Detaillierte Informationen über die relevanten angedachten Versuchsfälle finden sich im Anhang 1: Durchführbarkeit von Versuchsfällen bei Eingriff in den Straßenverkehr (Tabelle 33 bis Tabelle 40; entnommen aus Deliverable D13.2).

http://www.mainziel.de/�


2.4 Konzept für die Integration technischer und nicht-technischer Ver-suchsspezifikationen in den Drehbüchern

In simTD wurden Versuche technischer und nicht-technischer Art bisher getrennt betrachtet. Im Zuge der Drehbucherstellung soll die Möglichkeit genutzt werden, dieses getrennte Vor-gehen in ein gemeinsames integriertes Vorgehen zu überführen. Zum einen werden die Softwaretools zur Versuchsunterstützung nicht zwischen technischen und nicht-technischen Versuchen unterschieden. Zum anderen stehen im Versuch nur begrenzte zeitliche und sachliche Ressourcen zur Verfügung, so dass es erforderlich ist, mögliche technische As-pekte in nicht-technischen Versuchsfahrten zu berücksichtigen. Im Folgenden wird ein Kon-zept vorgeschlagen, um eine Integration technischer und nicht-technischer Versuchsfälle zu ermöglichen. Es wird ein 7-stufiges Vorgehen beschrieben.

1. Technische Tests und Versuche nach TP-Zugehörigkeit sortieren Die in Deliverable D13.2 beschriebenen technischen Test- und Versuchsfälle bezie-hen sich auf Funktionen, IT-Sicherheit, Kommunikation und Ausstattungsraten. Bis zu diesem Stand wurde keine finale Zugehörigkeit dieser Versuchsfälle zu TP3 (Test) und TP4 (Versuche) beschlossen, Arbeiten dazu sind allerdings fortgeschritten. Um in AP41 die Integration der technischen Versuchsfälle sinnvoll zu gestalten, ist es als Ausgangsbasis erforderlich, genau zu wissen, welche und wie viele Versuchsfälle vorliegen und integriert werden müssen.

2. Begleitende technische Versuche identifizieren Begleitende technische Versuche sind Versuche ohne explizite Testschritte. Hier steht das zufällige Zustandekommen von bestimmten Situationen im Vordergrund. Typische begleitende Versuche sind Untersuchungen zur Güte der Software oder Bestimmung von Kommunikationsparametern. Diese Versuche müssen identifiziert werden, da sie später nicht in eigenständige Drehbücher überführt werden sollten, sondern in andere bereits bestehende Drehbücher eingebettet werden können. Das Ergebnis der TP3/TP4-Zuordnung sollte daher gesichtet und anhand von noch zu definierenden Kriterien als begleitende technische Versuche identifiziert werden.

3. Versuchsbeschreibungen der technischen und nicht-technischen Versuchsfälle analysieren und gemeinsame Versuchsbeschreibung finden Die Versuchsbeschreibungen von technischen und nicht-technischen Versuchen sind sich in ihrem generellen Aufbau durchaus ähnlich, es gibt allerdings im Detail Unter-schiede. Beispielsweise erlauben technische Versuche in Form von Variationen in-nerhalb eines Versuchsfalls verschiedene Durchführungsabfolgen. Aufgrund dieser konzeptionellen Unterschiede ist es nicht möglich, eine der beiden Seiten ohne An-passungen in die andere zu überführen. Vertreter der technischen und nicht-technischen Seite müssen deshalb ein gemeinsames Modell entwerfen, in das die jeweiligen Versuchsgruppen überführt werden. Ziel sollte es sein, auf Modellebene nicht mehr zwischen technischen und nicht-technischen Versuchsfällen zu unter-scheiden.

4. Nicht-technische Versuchsfälle und technische Versuchsfälle in gemeinsames Format überführen Ist das gemeinsame Datenmodell gefunden, werden technische und nicht-technische Versuchsfälle in dieses überführt. Dazu ist es notwendig, die in Textform vorhande-nen technischen Versuchsfälle aus Deliverable D13.2 in das gemeinsame Daten-bankformat zu wandeln sowie das bereits bestehende Datenbankformat der nicht-technischen Versuchsfälle in das gemeinsame Modell zu überführen. Anschließend


werden die beiden Datenbestände in eine gemeinsame Versuchsfalldatenbank einge-fügt. Alle weiteren Schritte basieren auf dieser gemeinsamen Datenbank.

5. Gemeinsame Drehbücher erstellen Sämtliche technischen und nicht-technischen Versuchsfälle liegen nun in einer ge-meinsamen Datenbank vor. Mit Hilfe von in AP24 bereitgestellten Softwaretools wer-den die einzelnen Versuchsfälle nun zu Drehbüchern weiterentwickelt. Dabei sollte versucht werden, mehrere Versuchsfälle in einem Drehbuch zu integrieren, wenn dies inhaltlich möglich ist und sich die Versuchsfälle nicht gegenseitig beeinflussen kön-nen.

6. Begleitende technische Versuche in die vorhandenen Drehbücher einbetten Technische Versuchsfälle, die den begleitenden Versuchen zugeordnet wurden, soll-ten nicht in ein eigenes Drehbuch überführt werden. Stattdessen sollten sie in Dreh-bücher aus nicht-technischen oder eigenständigen technischen Versuchen integriert werden. Dabei ist darauf zu achten, dass zurückverfolgt werden kann, in welchen Drehbüchern diese Versuche untergebracht wurden. Weiterhin müssen Durchfüh-rungs-Anforderungen der begleitenden Versuchsfälle sichergestellt sein. Soll bei-spielsweise ein begleitender Versuch 3h aktiv sein, muss sichergestellt sein, dass die Drehbücher, in die der Versuchsfall eingebettet wird, in der Summe mindestens 3h Aktivität gewährleisten. Weiterhin ist es möglich, dass begleitende Versuche mit bestimmten anderen Versu-chen kombiniert werden müssen oder nicht kombiniert werden dürfen.

7. Review der Drehbücher Die entstandenen Drehbücher werden innerhalb der Spezialistenteams für technische Versuche (siehe Abbildung 3) verfeinert, gegenseitig in einem Review begutachtet und auf mögliche Schwierigkeiten hingewiesen. Insbesondere ist darauf zu achten, dass Drehbücher, in denen mehrere Versuchsfälle eingearbeitet wurden, diese auch voll abdecken und so in der Summe alle Versuchsfälle abgedeckt sind.

In Kap. 2.5.1 wird eine Priorisierung von technischen und nicht-technischen Versuchsfällen vorgestellt, mit dem Ziel die Gesamtzahl an durchzuführenden Versuchen zu reduzieren. Die Ergebnisse einer Priorisierung sollten am effizientesten unmittelbar vor, nach oder während Schritt 4 berücksichtigt werden.

2.5 Priorisierung technischer und nicht-technischer Versuchsfälle

Dieses Kapitel stellt Konzepte für die Priorisierung technischer und nicht-technischer Ver-suchsfälle vor. Eine Priorisierung ist erforderlich, weil es aufgrund begrenzter Zeit und Res-sourcen nicht möglich ist, alle der in D13.2 erarbeiteten Versuchsfälle bzw. Versuchsfallvari-anten umzusetzen. In Abschnitt 2.5.1 werden Überlegungen zur Priorisierung der techni-schen Versuche, in Abschnitt 2.5.2 zur Priorisierung der nicht-technischen Versuche darge-stellt. In Abschnitt 2.5.3 beschreibt die Einschätzungen zur Priorisierung technischer und nicht-technischer Versuchsfälle aus Sicht von TP5.

2.5.1 Priorisierung technische Versuche

In jedem technischen Versuchsfall ist eine „Testfall-Priorität“ in drei Stufen („gering“, „mittel“, „hoch“) definiert (siehe Deliverable D13.2 Anhang 1 und 2). Diese Priorität gibt an, wie not-wendig der Autor des Versuchsfalls die Durchführung dieses Versuchs erachtet. Wurde Prio-rität „hoch“ gewählt, ist eine zusätzliche Begründung der Wahl dieses Prioritäts-Levels ange-


geben. Wichtigkeit „hoch“ bedeutet, dass die Ergebnisse des Versuchs unmittelbar zum Er-reichen der Projektziele erforderlich sind, und daher der Test durchgeführt werden muss.

Die Priorisierung wurde von den Versuchsfall-Autoren in einer früheren Projektphase durch-geführt. Daher sollte eine Überprüfung der Priorisierung durch die Autoren in Schritt 4 des Integrationsablaufs (siehe Kap. 2.4) durchgeführt werden.

Bei der Versuchsdurchführung müssen zunächst alle Versuchsfälle der Priorität „hoch“ um-gesetzt werden, anschließend Versuchsfälle der Priorität „mittel“. Darüber hinaus besteht die Möglichkeit, Versuchsfälle der Priorität „mittel“ oder „gering“ aus Ressourcengründen nicht umzusetzen.

2.5.2 Priorisierung nicht-technischer Versuche

Für die nicht-technischen Fragestellungen wurden in AP13 von TUM-VT und IZVW Ver-suchsfälle konzipiert, für die wiederum Versuchsfallvarianten beschrieben und mit den FET abgestimmt wurden. Beispiele für nicht-technische Versuchsfallvarianten der internen Flotte im Versuchsgebiet sind in Tabelle 10 am Beispiel des Anwendungsfalls A_2.1.2.1 „Warnung vor Stauende" dargestellt. Sie entstammt dem Deliverable D13.2. Die Priorisierung der verkehrlichen und technischen Randbedingungen reflektiert dabei die Sicht der FET. Tabelle 10: Nicht-technische Versuchsfallvarianten der internen Flotte im Versuchsgebiet für den Anwendungsfall "Warnung vor Stauende".

Variation

Prio

risie

rung

ve

rkeh

rlich

Prio

risie

rung

te

chni

sch Streckenart

(Autobahn,Bundes-/

Landstraße, Innerorts)

Ver-kehrs-

zustand (Frei, Dicht, Stau)

Aus

stat

-tu

ngs-

rate

IV

SA

usst

at-

tung

s-di

chte

IR

SÜ

bert

ra-

gung

s-m

ediu

m

Vorbedingung

Weitere Vorbe-

din-gung

N_A_2.1.2.1_IF01_Ao22P_a Mittel Hoch Autobahn Frei/Stau Mittel Mittel 802.11pnicht-einsehbares Stauende (hinter Kuppe/Kurve)

keine

N_A_2.1.2.1_IF01_Ao22P_b Hoch Hoch Autobahn Frei/Stau Mittel Mittel 802.11p einsehbares Stau-ende keine

N_A_2.1.2.1_IF01_Bo22P_a Null Hoch Bundes-/Landstraße Frei/Stau Mittel Mittel 802.11p

nicht-einsehbares Stauende (hinter Kuppe/Kurve)

keine

N_A_2.1.2.1_IF01_Bo22P_b Null Hoch Bundes-/Landstraße Frei/Stau Mittel Mittel 802.11p einsehbares Stau-

ende keine

Als Ergebnis von AP13 steht für die einzelnen Versuchsumgebungen die in Tabelle 4 geliste-te folgende Anzahl nicht-technischer Versuchsfallvarianten. Nachfolgend soll geschätzt wer-den, mit welchem zeitlichen Umfang diese Versuchsfallvarianten einhergehen dürften.

Interne Flotte im Versuchsgebiet: 374 Versuchsfallvarianten Geht man von einer Versuchsdauer für die interne Flotte von 6 Monaten mit 20 Versuchsta-gen pro Monat und 8 Versuchsstunden pro Tag aus, stehen insgesamt 960 Versuchsstunden zur Verfügung:

6 Monate * 20 Tage/Monat * 8 Std./Tag = 960 Std.

Damit ergeben sich als durchschnittlich zur Verfügung stehende Versuchsdauer pro Ver-suchsfallvariante der internen Flotte (auf dem Testgelände und im Versuchsgebiet) 2.2 Stun-den:

960 Std. / (374 + 62) = 2.2 Std.


Selbst für die einmalige Durchführung eines Versuchs wird diese geringe Versuchszeit bei weitem nicht ausreichen. Um ausreichend große Stichproben zu erhalten, benötigen viele Versuchsfallvarianten mehrere Wiederholungen (Durchführungen). Zudem ist davon auszu-gehen, dass einige Versuche nicht auf Anhieb klappen werden. Diese Abschätzung zeigt, dass die Anzahl der Versuchsfallvarianten insbesondere bei der internen Flotte (im Ver-suchsgebiet und im Testgelände) deutlich reduziert werden muss.

Fahrsimulation: 145 Versuchsfallvarianten Obwohl in der Fahrsimulation eine höhere Fahrszenendichte erreicht werden kann als im Feld, reichen auch hier die geplanten Kapazitäten nicht aus, um die gewünschten Versuchs-fallvarianten abzuarbeiten. Aktuell (Stand: März 2010) sind noch 62 Tage in der Fahrsimula-tion verfügbar:

• Vorbereitung: 4 Tage

• Vorversuche: 5 Tage

• Hauptversuche: 47 Tage

Für die Hauptversuche bleiben somit 47 Tage:

• 47 Tage * 8 Stunden = 376 Stunden gesamt

• 376 Stunden / 145 Versuchsfälle = 2.6 Stunden pro Versuchsfall

• 2.6 Stunden pro Versuchsfall / 30 Pbn pro Versuchswelle = ca. 5 Minuten pro Ver-suchsfall und Proband

Für eine verlässliche Messung ist es erforderlich, die Fahrszenen zweimal darzubieten. Da-durch blieben lediglich 2.5 Minuten pro Versuchsfall und Proband. Eine Fahrszene in so ge-ringer Zeit aufzubauen, ist selbst in der Fahrsimulation in den wenigsten Anwendungsfällen möglich.

Verkehrssimulation: 508 Versuchsfallvarianten Auch die Anzahl der Versuchsfallvarianten in der Verkehrssimulation ist aus heutiger Sicht zu hoch. Eine grobe Abschätzung des Aufwandes für Aufbau von Simulationsszenarien und der Durchführung der Verkehrssimulationen ergibt folgendes Bild:

• Zeitbedarf für Vor- und Nachbereitung eines Verkehrssimulations-Szenarios einer Versuchsfallvariante: ca. 1 Stunde

• Durchschnittliche Dauer eines Simulationsdurchlaufes: ca. 0.5 Stunden

• Durchschnittliche Anzahl von Durchläufen pro Simulationsszenario: mindestens 10

Das ergibt für 508 Varianten bei täglich 10 Stunden Simulationszeit eine benötigte Zeit von

508 * (1 + 10 * 0.5) Stunden = 3048 Stunden = 304.8 Tagen

Zur Verfügung stehen für die Hauptversuche in der Verkehrssimulation maximal 120 Tage, was nach dieser Rechnung maximal (120 * 10) / 6 = 200 Szenarien entspräche. Zu beachten ist zudem, dass pro Versuchsfallvariante mehrere Simulationsszenarien existieren können. Eine Reduktion ist also auch hier unbedingt notwendig.

Wie können solche Reduktionen bezüglich der Versuchsfallvariantenanzahl erreicht werden? In AP13 wurde durch die FET (mit Unterstützung durch TUM-VT und IZVW) eine vorläufige Priorisierung der Versuchsfallvarianten, getrennt nach technischen Randbedingungen (IVS-


Ausstattungsrate, IRS-Dichte, Übertragungsmedium) und verkehrlichen Randbedingungen (Streckenart, Verkehrszustand, weitere Vorbedingungen), vorgenommen. Aufgabe von AP41 ist es, die Versuchsfallvarianten in konkrete Versuchsszenarien samt zugehörigen Drehbü-chern zu überführen. Dabei ist letztendlich zu entscheiden, welche Versuchsfallvarianten bzw. Versuchsszenarien welche Priorität erhalten. Abbildung 4 zeigt, welche Anforderungen bzw. Einschätzungen zur Festlegung abgestimmter Prioritäten führen sollen.

AP13TUM-VT / IZVW

Versuchsfallvariantenmit Priorisierung aus

FET-SichtWünsche der FETs

Einschätzung TP4

• Umsetzbarkeit • Zeitbedarf • Technische Versuche • …

Anforderungen TP5

• Projektziele• Vergleichbarkeit • Wirkfeldanalyse • Kosten/Nutzen-Einschätzung• …

Versuchsfallvariantenmit abgestimmter Priorisierung

TP4/TP5/FET

Abbildung 4: Konzept für das Erreichen abgestimmter Prioritäten für die nicht-technischen Versuchsfallvarianten.

Der Entscheidungsprozess soll dabei möglichst effizient ablaufen und vorrangig die Projekt-ziele von simTD berücksichtigen. Dabei soll trotzdem ein größtmöglicher Konsens zwischen den relevanten Projektpartnern erreicht werden:

• Der erste in Abbildung 4 skizzierte Schritt wurde bereits in AP13 vollzogen, für die Versuchsfallvarianten liegen (zum großen Teil) die Prioritäten aus FET-Sicht vor.

• Im zweiten Schritt wird eine Einschätzung aus Sicht von TP5 hinsichtlich der in D13.2 beschrieben Versuchsfallvarianten erstellt, die insbesondere das Erreichen überge-ordneter Projektziele, die Sicherstellung der Vergleichbarkeit, die Ergebnisse der Wirkfeldanalyse und eine Kosten/Nutzen-Einschätzung berücksichtigt (siehe Kap. 2.5.3).

• Parallel hierzu ist TP4 (AP41) gefordert. Im Zuge der Konkretisierung der Versuchs-fallvarianten zu Versuchsszenarien und der Erstellung der zugehörigen Drehbücher wird die Priorisierung aus TP4-Sicht erstellt, die jeweils mit den relevanten Projekt-partnern abgestimmt wird. Treibende Kraft ist dabei das AP-übergreifende TP4-Team „Systemvalidierung", das sich dabei sowohl mit den FET-Verantwortlichen als auch mit den relevanten Partnern von TP5 abstimmt.

Die folgenden Punkte dienen als erste Ideensammlung, um den Prozess der Priorisierung effizient und zielorientiert zu gestalten:

• Nutzung der Experten-Einschätzung durch TUM-VT, IZVW und andere

• Einbindung des Versuchsdurchführung-Unterauftragnehmers

• Berücksichtigung der in AP11 erarbeiteten Priorisierung der Anwendungsfälle im Rahmen des Funktionsauswahlprozesses

• Berücksichtigung des Zusammenspiels mit technischen Versuchen

• Berücksichtigung der Anforderungen aus der Wirkfeldanalyse

• Berücksichtigung des Schwierigkeitsgrades der Umsetzbarkeit des Versuches

• Berücksichtigung, ob eine Versuchsfallvariante planbar oder nicht planbar ist.


• Abschätzung der Anzahl maximal realisierbarer Versuchsfallvarianten durch je eine exemplarische Abschätzung des Zeitbedarfs für eine Versuchsfallvariante mit „gerin-gem“, „mittlerem“ und „hohem“ Aufwand.

• Abschätzung der Zeitdauer einer einzelnen Durchführung, der Anzahl erforderlicher Wiederholungen, der Wahrscheinlichkeit für das Zustandekommen der erforderlichen Situation (z.B. Stau), des erforderlichen Zeitpuffer etc.

• Versuchsfallvarianten, bei denen eine hohe Wirkung bzgl. der nicht-technischen Fra-gestellungen erwartet wird, sollten höher priorisiert werden.

• Zu jedem Anwendungsfall soll mindestens ein nicht-technischer Versuch durchgeführt werden.

• Berücksichtigung des Konzepts zum Zusammenspiel der Versuchsumgebungen: Es ist zu gewährleisten, dass Abhängigkeiten zwischen den Versuchsumgebungen bei der geplanten Wirkungsermittlung berücksichtigt werden. Beispiel: Ist ein Versuch in der Verkehrssimulation notwendig, kann dieser meist erst erfolgen, nachdem Kenntnisse über das Fahrverhalten aus dem Feld oder der Fahr-simulation vorliegen.

2.5.3 Priorisierung technischer und nicht-technischer Versuchsfälle aus TP5-Sicht

Um die Bewertungsziele des Teilprojektes TP5 und damit des Projekts simTD zu erreichen, müssen Versuchsfälle im Feld und in den Simulationen zur Beantwortung der Fragen aus Deliverable D5.1 „Anforderungskatalog an den Feldtest“ die höchste Priorität haben. Auf Ba-sis dieser Fragen wurden in Deliverable D5.1 Kriterien und Kenngrößen beschrieben, an-hand derer die Beantwortung der unten aufgeführten Fragen erfolgen soll.

Versuchsfälle, welche nicht zur Beantwortung der unten aufgeführten zentralen Fragen die-nen bzw. keine Daten für eine Bewertung liefern, haben aus Sicht von TP5 eine geringe Prio-rität. Diese Versuchsfälle sollen erst nach erfolgreicher Ermittlung der notwendigen Daten für TP5 durchgeführt werden.

Technische Versuchsfälle Bei der Priorisierung der einzelnen technischen Versuchsfälle schlägt TP5 ein mehrstufiges Verfahren vor:

1. Zunächst sollen in TP1 die einzelnen technischen Versuchsfälle den Bewertungskrite-rien aus Deliverable D5.1 zugeordnet werden sowie eine Zuordnung der Test- und Versuchsfälle zu TP3 bzw. TP4 erfolgen. Sollten technische Versuchsfälle ermittelt werden, welche nicht zur Beantwortung der Fragen aus Deliverable D5.1 beitragen, haben diese aus Sicht von TP5 eine geringe Priorität. Auch unabhängig von den Funktionen und den Anwendungsfällen durchgeführte Versuche (wie z.B. Kommunikationsversuche) sollen von TP1 dahingehend geprüft werden, ob sie Beiträge zur Beantwortung der Fragen aus Deliverable D5.1 und Da-ten zur Bewertung liefern.

2. Anschließend sollte ein Team aus TP4 und TP5 die technische Priorisierung gemein-sam durchführen. Dabei soll TP4 die technischen Versuchsfälle erläutern, so dass die Bewertung zusammen erfolgen kann. Die Priorisierung orientiert sich an den Bewer-tungskriterien sowie an den übergeordneten Fragen im Bereich Technik aus Delive-rable D5.1.


Nicht-technische Versuchsfälle Da sich die nicht-technischen Versuchsfälle – im Gegensatz zu den technischen Versuchs-fällen – auf Anwendungsfälle beziehen, werden in diesem Rahmen neben den nicht-technischen Versuchsfällen auch Anwendungsfälle priorisiert. Bei der Priorisierung der An-wendungsfälle sowie der jeweiligen nicht-technischen Versuchsfälle aus Sicht von TP5 wird das folgende Verfahren vorgeschlagen:

1. Zunächst erfolgt in TP5 eine Priorisierung der Anwendungsfälle nach erwartetem Nutzen (aufgrund von Verkehrseffizienz- und Verkehrssicherheitswirkungen) des ein-zelnen Anwendungsfalls. Dies geschieht beispielsweise für die Verkehrssicherheit anhand der vorliegenden Aussagen aus der Wirkfeldanalyse. Dabei sind – in Abhän-gigkeit des jeweiligen Anwendungsfalls – auch Annahmen über die Nutzerakzeptanz (v.a. über das objektive Bedienverhalten, z.B. Befolgungsraten) zu berücksichtigen.

2. Beginnend mit den in Schritt 1 hoch priorisierten Anwendungsfällen erfolgt in einem zweiten Schritt eine Priorisierung der Versuchsfälle für diese Anwendungsfälle. Dabei sind solche Versuchsfälle als „hoch“ zu priorisieren, bei denen in Abhängigkeit der Differenzierungsmerkmale (z.B. IVS-Ausstattungsraten, Verkehrszustände oder Übertragungsmedium) starke (Effizienz- und Sicherheits-)Wirkungen erwartet wer-den. Die Priorisierung der Versuchsfälle durch TP5 erfolgt aufbauend auf die bereits in Deliverable D13.2 erfolgten Priorisierungen der Versuchsfälle bzw. Versuchsfallva-rianten durch die FETs. Anwendungsfälle, für die die Berücksichtigung von zwei Übertragungsmedien vorgesehen ist, werden hoch priorisiert.

3. Die Priorisierungen durch TP5 werden in einem abschließenden Schritt mit dem TP4-Team abgestimmt.

Die Kosten zur Realisierung von Anwendungsfällen werden bei der Priorisierung nur am Rande berücksichtigt, da sie in hohem Maße von der Ausgestaltung des technischen Sys-tems und somit von den Ergebnissen der technischen Versuchsfälle abhängen.

TP5 ist während der Versuchsdurchführung über Änderungen der Priorisierung rechtzeitig zu informieren. Hierzu sollte von TP4 ein Tool z.B. in Form einer Datenbank zur Verfügung ge-stellt oder ein Vorgehen zwischen TP4 und TP5 abgesprochen werden. TP5 ist rechtzeitig z.B. über das Change Management Board zu informieren, wenn durch geplante Softwareup-dates das gewählte Set der Versuchsfälle für Versuch und Simulation geändert werden muss bzw. bisherige Versuchsergebnisse nicht mehr in die Bewertung einfließen können und in größerem Umfang Versuche und Simulationen zu wiederholen sind.

2.6 Methodologische Betrachtung: Versuchsmethodik

Im Rahmen von AP41 Versuchsdesign sind u.a. Aussagen zu treffen, wie oft ein Versuch mit der internen Flotte durchzuführen ist bzw. wie viele Ereignisse in der externen Flotte not-wendig sind, so dass zuverlässige Ergebnisse erzielt werden. Die aus einer solchen Diskus-sion resultierenden Erkenntnisse haben z.B. zur Folge:

• Interne Flotte: Schätzungen zur Häufigkeit der Durchführung von Drehbüchern bei ei-ner gegebenen Zahl von Fahrzeugen (100 PKW, 3 Motorräder)

• Externe Flotte: Schätzungen zur optimalen Anzahl an Fahrzeugen (aktuell: 300 PKW) sowie Anforderungen an die Auswahl potenzieller Partner (z.B. Taxis oder Pendler)

Die entsprechenden Arbeiten werden vom IZVW in Zusammenarbeit mit den FETs geleistet und im Rahmen der Drehbucherstellung für das Deliverable D41.2 „Versuchsplan 2.0“ do-kumentiert. In diesem Zusammenhang werden auch die unter Kap. 2.5 genannten Ergebnis-se zur Priorisierung von technischen und nicht-technischen Versuchsfällen berücksichtigt.


2.6.1 Versuchsmethodik

Eine umfassende Betrachtung, inwiefern Wirkungen der simTD-Anwendungsfälle nachweis-bar sind, muss methodologische Aspekte der Planung, Durchführung und Auswertung der Versuche berücksichtigen. So setzt die Wirkungsbewertung der simTD-Anwendungsfälle auf die Validierungsziele (siehe Glossar) voraus, dass vordefinierte Arbeitsschritte bei der Ver-suchsplanung, -durchführung sowie -auswertung im vornhinein beschrieben und nachfolgend (so weit wie möglich) eingehalten werden. Zusammenfassend sind die in Abbildung 5 darge-stellten Schritte bei der Versuchsdurchführung zu berücksichtigen.

Abbildung 5: Stufenmodell der Versuchsphasen (Quelle: Sarris, 1990, S. 112).

Jeder der in Abbildung 5 skizzierten Schritte bei der Versuchsdurchführung geht mit spezifi-schen methodischen Anforderungen an den Untersucher einher, wie z.B. die Folgenden:

• Hypothesen: Es sind a priori Hypothesen bezüglich der kausalen Wirkungsrichtung bzw. des Zu-sammenhangs zwischen zwei oder mehreren Variablen zu definieren. Die sog. Null-hypothese (siehe Glossar) geht dabei regelhaft davon aus, dass keine kausale Wir-kungsrichtung bzw. kein Zusammenhang zwischen den Variablen vorliegt (verkürzt: „kein Effekt“). Die sog. Alternativhypothese (siehe Glossar) besagt zumeist, dass ein solcher Effekt vorliegt bzw. sagt evtl. sogar die Größe des Effekts voraus. Diese Hy-pothesen sollten sowohl in sprachlicher Form (sog. inhaltliche Hypothesen) als auch in statistisch prüfbarer Form (sog. statistische Hypothesen) vorliegen. Es sind somit bereits an dieser Stelle die später auszuwertenden bzw. zu interpretierenden statisti-schen Prüfgrößen zu bestimmen.

• Versuchsplanung: Es sind Versuchsanordnungen zu konzipieren, welche die (möglichst) eindeutige In-terpretation der Ergebnisse zulassen und alternative Erklärungen (weitgehend) un-wahrscheinlich machen. Diese Anordnungen beinhalten z.B. bei experimentellen Versuchsanordnungen Informationen über die systematische Manipulation relevanter Variablen unter kontrollierten Rahmenbedingungen (d.h. Störvariablen wirken in ver-schiedenen Versuchssituationen in vergleichbarer Art und Weise).

• Versuchsdurchführung: Es sind bei der Durchführung von Versuchen kontrollierte Rahmenbedingungen auf Seiten der Versuchsperson, der Versuchsdurchführung sowie der Versuchssituation herzustellen, so dass die verschiedenen Versuchssitzungen sich vor allem durch die explizit angestrebte Manipulation ausgewählter Variablen unterscheiden.


• Versuchsauswertung: Es ist a priori die Auswertungsstrategie festzulegen. Diese Strategie umfasst Anga-ben, welche deskriptiven, graphischen und inferenzstatistischen Methoden zum Ein-satz kommen sollen.

• Ergebnisinterpretation: Es ist a priori zu definieren, anhand welcher Prüfkriterien Entscheidungen über die zuvor formulierten Hypothesen getroffen werden sollen (siehe oben unter „Hypothe-sen“) und wie diese Ergebnisse zu interpretieren sind. Eine Interpretation kann sich dabei sowohl auf Signifikanz des Testergebnisses beziehen (d.h. inwiefern das empi-rische Ereignis unter Annahme der Nullhypothese (siehe Glossar), die regelhaft von einem Nicht-Effekt ausgeht, wahrscheinlich ist) als auch auf die Größe des gefunde-nen Effekts beziehen (d.h. inwiefern das empirische Ereignis eine bestimmte Größe eines Effekts nahelegt).

Für die vorliegende Diskussion zur methodischen Betrachtung der internen und externen Flotte in simTD sind v.a. Argumente bezüglich der Versuchsplanung und Ergebnisinterpretati-on von Bedeutung. Aus diesem Grund sollen diese Aspekte nachfolgend vertiefend betrach-tet werden.

2.6.2 Methodische Hinweise zur Versuchsplanung

2.6.2.1 Anforderungen an experimentelle Versuchspläne Eine experimentelle Untersuchung ist die „methodisch beste Möglichkeit, um Kausalhypo-thesen zu prüfen“ (Bortz & Döring, 2006, S. 726). Laut Sarris (1990) müssen für streng expe-rimentelle Versuchsdesigns die folgenden Kriterien erfüllt sein:

• Systematische Beobachtung von Messgrößen Beispiel: Einsatz von reliablen, validen und objektiven Messverfahren

• Planmäßige Manipulation bzw. Variation von Bedingungen Beispiel: Variation mit vs. ohne simTD-Anwendungsfall, Variation von UMTS vs. W-LAN, Variation von dichtem Verkehr vs. freiem Verkehr

• Ausschaltung bzw. Kontrolle von Störvariablen Beispiel: Einsatz vergleichbarer Fahrzeuge (z.B. ausschließlich Mittelklassefahrzeu-ge), um zu verhindern, dass unterschiedliche Größen und Motorisierungen die Er-gebnisse systematisch beeinflussen.

Um die Wirkung von simTD-Anwendungsfällen nachzuweisen, ist somit als „Planmäßige Vari-ation von Bedingungen“ ein Vergleich der Fahrten mit simTD-Technologie (z.B. mit Stauen-dewarnung) mit Fahrten ohne simTD- Technologie (bzw. mit deaktivierter simTD-Technologie, also z.B. ohne Stauendewarnung) unerlässlich. Andernfalls sind keine Rückschlüsse auf den Nutzen von simTD möglich, da es keine Vergleichsbedingung gibt. Vergleiche zwischen Be-dingungen können auf zwei Arten durchgeführt werden:

1. „Unabhängiger Vergleich“ Ein Teil der Fahrer erhält simTD-Funktionalität und der andere Teil nicht.

2. „Abhängiger Vergleich“ Fahrer absolvieren sowohl Fahrten mit als auch Fahrten ohne simTD-Funktionalität. Für jeden Fahrer werden somit wiederholte Messungen vorgenommen.

Ein Vorteil abhängiger Vergleiche gegenüber unabhängigen Verfahren ist die geringere Da-tenstreuung (durch die Kontrolle der interindividuellen Verhaltensvariabilität) mit der Konse-quenz, dass die experimentellen Effekte klarer nachweisbar sind (Sarris, 1992) und geringe-


re Stichproben nötig sind (siehe Kap. 2.6.4). Weiterhin erlauben abhängige Verfahren durch die Messwiederholung Testungen von verhältnismäßig wenigen Probanden. Nachteilig ist dagegen, dass Gefahren von sog. Übertragungseffekten (Effekte bei längerer Versuchsteil-nahme, wie z.B. Müdigkeit oder Erfahrung) nicht ausgeschlossen werden können.

2.6.2.2 Mögliche Versuchsdesigns für nicht-technische Versuche Im Folgenden werden vier grundsätzliche Versuchsdesigns vorgestellt, die für die nicht-technischen Versuche in simTD denkbar sind. Diese Designs können bei Bedarf auch mitei-nander kombiniert werden.

Vorher-Nachher-Messung an einer einzigen Versuchsgruppe In diesem Versuchsdesign gibt es zu Beginn der Laufzeit eine sog. Baseline-Phase ohne simTD-Funktionalität (siehe Abbildung 6). Allerdings werden die Zeitpunkte aufgezeichnet, in denen der Fahrer simTD-Meldungen erhalten hätte. In der anschließenden Experimentalpha-se erhalten alle Fahrer simTD-Meldungen. Somit ist ein abhängiger Vergleich möglich, um die Wirkung von simTD-Anwendungsfällen abzuschätzen.

Abbildung 6: Vorher-Nachher-Messung an einer einzigen Versuchsgruppe.

Voraussetzung für diesen abhängigen Versuchsplan ist die Notwendigkeit der Identifizierung der Probanden (z.B. mittels Fahrtenbuch). Nachteilig ist, dass die Anzahl alternativer Erklä-rungen für die Untersuchungsbefunde sehr hoch sein kann. Bezogen auf simTD bedeutet dies, dass zum Beispiel Zeiteffekte die Eindeutigkeit der Ergebnisse einschränken können.

Fiktives Beispiel: Da die Baseline-Phase in den Winter fällt, zeigen die Fahrer hier ein vor-sichtigeres Fahrverhalten und es ereignen sich mehr sicherheitskritische Situationen als während der Experimentalphase. Dieser Unterschied ist allerdings nicht auf simTD zurückzu-führen, sondern auf die Jahreszeit: Möglich ist auch, dass die Fahrer sich zu Beginn der Un-tersuchung stärker beobachtet fühlen und dadurch ihr Verhalten kontrollieren (Die Proban-den fahren vorsichtig und beachten stärker als normalerweise die StVO). Nach einiger Zeit nehmen diese sog. reaktiven Effekte durch Gewöhnung an die Untersuchungssituation ab und die Fahrer zeigen natürliches Verhalten.

Vorher-Nachher-Messung an einer einzigen Versuchsgruppe mit Post-Phase Dieses Versuchsdesign entspricht der o.g. Vorher-Nachher-Messung an einer einzigen Ver-suchsgruppe, enthält jedoch zusätzlich eine abschließende Phase ohne simTD-Funktionalität (siehe Abbildung 7). Hierdurch können Langzeiteffekte der Systeme bestimmt werden (Bei-spiel: Durch die Frage „Fehlt Ihnen der Grüne-Welle-Assistent?“).


Abbildung 7: Vorher-Nachher-Messung an einer einzigen Versuchsgruppe mit Post-Phase.

Zweistichprobenversuchsplan mit Zufallsgruppenbildung In diesem Versuchsdesign erhält ein Teil der Fahrer (sog. Experimentalgruppe) während der gesamten Versuchslaufzeit simTD-Meldungen, der andere Teil (sog. Kontrollgruppe) dagegen nicht (siehe Abbildung 8). In der Kontrollgruppe werden Ereignisse aufgezeichnet, in denen simTD-Anwendungsfälle eingegriffen hätten. Somit ist ein unabhängiger Vergleich möglich, um die Wirkung von simTD-Anwendungsfällen abzuschätzen.

Abbildung 8: Zweistichprobenversuchsplan mit Zufallsgruppenbildung.

Effiziente abhängige statistische Verfahren können dagegen nicht angewendet werden. Zu-dem ist die Größe der Experimentalgruppe verringert. Weiterhin müssen die Gruppen hin-sichtlich verschiedener relevanter Aspekte vergleichbar sein (z.B. Firmen, Fahrzeuge, Fah-rer), um alternative Erklärungen der Befunde durch eine fehlerhafte Stichprobenzusammen-setzung zu verhindern.

Fiktives Beispiel: In der externen Flotte befinden sich die Taxen (falls diese verwendet wer-den) ausschließlich in der Experimentalgruppe, während alle Pendlerfahrzeuge der Kontroll-gruppe zugewiesen werden. Die gefundenen Unterschiede können nicht auf die simTD-Anwendungsfälle zurückgeführt werden, da alternative Erklärungen aufgrund der unter-schiedlichen Stichproben (unterschiedliche Fahrweise, unterschiedliche Fahrtstrecken, un-terschiedliche soziodemographische Faktoren, wie z.B. Schulabschluss) nicht ausgeschlos-sen werden können.

Cross-Over Design Dieses Versuchsdesign ist die Kombination abhängiger und unabhängiger Designs: Zwei Gruppen erhalten Phasen mit und ohne Meldungen, jedoch zu unterschiedlichen Zeitpunkten (um Zeiteffekte auszugleichen; siehe Abbildung 9). In den Phasen ohne simTD-Meldungen werden Ereignisse aufgezeichnet, in denen simTD-Anwendungsfälle eingegriffen hätten. Bei diesem Design sind sowohl unabhängige als auch abhängige Vergleiche möglich, um die Wirkung von simTD-Anwendungsfällen abzuschätzen.


Abbildung 9: Cross-Over Design.

Voraussetzungen für diesen Versuchsplan sind zum einen die Identifizierung der Probanden (z.B. mittels Fahrtenbuch) und zum anderen die Vergleichbarkeit der Gruppen hinsichtlich verschiedener Aspekte (z.B. Firmen, Fahrzeuge, Fahrer).

2.6.2.3 Exkurs: Versuchsdesign der externen Flotte laut Vorhabensbeschreibung In der simTD-Vorhabensbeschreibung ist für die externe Flotte lediglich eine Versuchsbedin-gung vorgesehen, d.h. alle Fahrer erhalten die simTD-Meldungen über die gesamte Laufzeit des Versuchs (siehe Abbildung 10).

Abbildung 10: Versuchsplan der externen Flotte laut simTD-Vorhabensbeschreibung: „Schrotschuss-Design“.

Sarris (1992) bezeichnet dieses Versuchsdesign als sog. Schrotschuss-Design. Laut Sarris (1992, S.31) „findet man in der heutigen Fachliteratur keine ernstzunehmende Arbeit, die auf einem Schrotschuss-Design beruht“. Nachteile dieses Designs sind die fehlende experimen-telle Kontrolle sowie das Fehlen einer Vergleichsmöglichkeit zu anderen Untersuchungsbe-dingungen. Aus diesen Gründen sollte dieses Versuchsdesign höchstens im Rahmen von Pilotstudien eingesetzt werden.

Fiktives Beispiel: Die Ergebnisse zeigen, dass die Fahrer der externen Flotte mit Unterstüt-zung des simTD-Anwendungsfalls „Verkehrszeichenanzeige“ auf 20% der Fahrtstrecken mit Geschwindigkeitsbeschränkungen schneller fahren als die zulässige Geschwindigkeit. Der zusätzliche Nutzen der Verkehrszeichenanzeige hinsichtlich Fahr- und Verkehrssicherheit sowie Fahr- und Verkehrseffizienz kann hier nicht bestimmt werden, da das Fahrverhalten ohne diesen simTD-Anwendungsfall unbekannt ist („Auf welchem Anteil der Fahrtstrecken wird ohne Verkehrszeichenanzeige schneller als die zulässige Geschwindigkeit gefahren?“).

2.6.2.4 Vergleich der Versuchsdesigns In Tabelle 11 sollen die in Kap. 2.6.2.2 und 0 beschriebenen Versuchsdesigns anhand ver-schiedener Aspekte bezüglich folgender Aspekte verglichen werden:

Aspekte der Versuchsdurchführung ( Anforderungen an AP42)

• Vergleichbare Gruppen nötig? Müssen mehrere Gruppen gebildet werden, die hinsichtlich der Zusammensetzung (z.B. Fahrzeugklassen, Fahrtzweck, soziodemographische Daten) vergleichbar sind?


• Identifikation der Fahrer notwendig? Müssen die Fahrer einer Fahrt eindeutig identifiziert werden?

• Mindestanzahl Fahrerkontakte Wie häufig müssen die Fahrer kontaktiert werden, um neue Instruktionen zu geben?

Aspekte der Versuchsauswertung ( Möglichkeiten von AP43)

• Abhängige Verfahren anwendbar? Sind abhängige statistische Verfahren anwendbar?

• Unabhängige Verfahren anwendbar? Sind unabhängige statistische Verfahren anwendbar?

Aspekte der Ergebnisinterpretation ( Rahmenbedingungen von TP5)

• Zusätzlicher Nutzen von simTD bestimmbar? Gibt es eine Bedingung, mit der die Untersuchungsbefunde verglichen werden kön-nen, um den Nutzen der simTD-Anwendungsfälle identifizieren zu können?

• Einfluss von „Faktor Zeit“ Ist der Einfluss zeitlicher Faktoren (z.B. Erfahrung der Fahrer, Witterung) in den Ver-gleichsbedingungen gleich stark?

• Langzeiteffekte identifizierbar? Sind Effekte der längeren Nutzung durch eine abschließende Phase ohne System-nutzung identifizierbar?

Tabelle 11: Vergleich der verschiedenen Versuchsdesigns.

Schrot-schuss

Vorher-Nachher

Vorher-Nachher mit Post-Phase

Zweistich-probenver-suchsplan

Cross-Over Design

Versuchsdurchführung Vergleichbare Gruppen nötig? Nein Nein Nein Ja Ja

Identifikation der Fahrer notwendig? Nein Ja Ja Nein Ja

Mindestanzahl Fahrerkontakte 1 2 3 1 2

Versuchsauswertung

Abhängige Verfahren anwendbar?

Unabhängige Verfahren anwendbar?

Ergebnisinterpretation Zusätzlicher Nutzen von simTD bestimmbar?

Einfluss von „Faktor Zeit“

Langzeiteffekte identifizierbar?


Der Vergleich der verschiedenen Versuchsdesigns in Tabelle 11 zeigt, dass ein klarer Zu-sammenhang zwischen Aufwand für den Untersucher auf der einen Seite und Möglichkeiten für Auswertung und Interpretation auf der anderen Seite besteht: Je eindeutiger und valider die Ergebnisse der simTD-Versuche sein sollen, desto mehr Aufwand und Kosten müssen in die Versuchsplanung investiert werden.

Das in der simTD-Vorhabensbeschreibung für die externe Flotte vorgeschlagene „Schrot-schuss-Design“ ist aufgrund seiner beschränkten Möglichkeiten bezüglich Auswertung und Interpretation der Ergebnisse abzulehnen. Stattdessen sind die in Kap. 2.6.2.2 diskutierten experimentellen Versuchspläne sowohl für die interne als auch für die externe Flotte anzura-ten.

2.6.3 Methodische Hinweise zur Ergebnisinterpretation

2.6.3.1 Bewertung des üblichen inferenzstatistischen Vorgehens Als Einführung der nachfolgenden Argumentation soll nachfolgend eine Textpassage aus Bortz & Döring (2006, S. 600) zitiert werden:

„Die Konzeption des Signifikanztests gestattet es, die bedingte Wahrscheinlichkeit empiri-scher Ergebnisse bei Gültigkeit der Nullhypothese [siehe Glossar] zu bestimmen. Wir sprechen von einem signifikanten Ergebnis, wenn das gefundene Ergebnis einer Ergeb-nisklasse angehört, die bei Gültigkeit von H0 höchstens mit einer Wahrscheinlichkeit von α=0.05 (α=0.01) auftritt. Diese Unvereinbarkeit von Nullhypothese und empirischem Er-gebnis wird dann üblicherweise zum Anlass genommen, die Alternativhypothese [siehe Glossar], zu der nach unseren bisherigen Ausführungen alle mit der Nullhypothese nicht erfassten Populationsverhältnisse zählen, anzunehmen.

Hierin liegt […] ein Nachteil des Signifikanztests. Behauptet die Nullhypothese [siehe Glossar], es existiere kein Effekt (also z.B. kein Zusammenhang oder kein Unterschied), geben auch die kleinsten Effekte Anlass zur Entscheidung für die Alternativhypothese [siehe Glossar], wenn sie sich als statistisch signifikant erweisen. Da aber nun […] die sta-tistische Signifikanz eines Effekts vom Umfang der untersuchten Stichprobe abhängt, ist die Nullhypothese als theoretische Aussage, die auf die Realität praktisch niemals exakt zutrifft, gewissermaßen chancenlos. Setzte der Untersuchungsaufwand der Wahl des Stichprobenumfanges keine Grenzen, wäre wohl jede H0 zu verwerfen.

Statistische Signifikanz kann deshalb nicht allein als Gradmesser des Aussagegehaltes hypothesenprüfender Untersuchungen angesehen werden. Neben die wichtige Forde-rung, an Stichproben gewonnene Ergebnisse gegen den Zufall abzusichern, tritt eine wei-tere: Diese besagt, dass bedeutsame empirische Ergebnisse für Populationsverhältnisse sprechen müssen, die in einer für die Praxis nicht zu vernachlässigenden Weise von den in der H0 behaupteten Populationsverhältnissen abweichen – oder kurz: signifikante Er-gebnisse müssen auch praktisch bedeutsam sein.“

Ausgehend von diesem Originalzitat von Bortz und Döring (2006) bleibt somit festzuhalten, dass zwei Argumente gegeneinander abzuwägen sind:

• Der Einfluss der Stichprobe beeinflusst die Wahrscheinlichkeit, eine Nullhypothese (siehe Glossar) abzulehnen.

• Signifikante Ergebnisse müssen auch praktisch bedeutsam (d.h. in der Realität nicht zu vernachlässigen und replizierbar) sein.


2.6.3.2 Bedeutsamkeit der Stichprobengröße Das Argument „Der Einfluss der Stichprobe beeinflusst die Wahrscheinlichkeit, eine Nullhy-pothese abzulehnen“ (siehe Kap. 2.6.3.1) legt zunächst nahe, eine möglichst große Stich-probe in den simTD-Versuchen zu rekrutieren: „Je größer die Stichprobe, desto eher wird die Nullhypothese (siehe Glossar) abgelehnt („Das Ergebnis ist signifikant“)“. Dieses Argument birgt jedoch zwei Gefahren:

1. Untersuchung unnötig großer Stichproben

2. Fehlerhafte Interpretation von Signifikanzniveaus

Die Forderung nach möglichst großen Stichproben zum Erzielen von signifikanten Ergebnis-sen stellt daher zunächst eine nicht-zulässige Implikation dar, da eine lineare Erhöhung des Stichprobenumfangs nicht mit einer entsprechenden Verringerung der Irrtumswahrscheinlichkeit bei der Entscheidung über die Nullhypothese (siehe Glossar) ein-hergeht. In Kürze: Zu große Stichproben gehen einher mit einem hohen Zeit- und Kosten-aufwand, leisten jedoch einen nur geringen Mehrwert bei der statistischen Prüfung.

Zudem legt die Forderung nach großen Stichproben zum Erreichen von Signifikanz nahe, dass ein nicht adäquates Verständnis von Signifikanz im statistischen Sinne vorliegt: Ein Signifikanzniveau macht ausschließlich Aussagen über die Wahrscheinlichkeit des Zustan-dekommens eines empirischen Ereignisses unter der Annahme der Nullhypothese (siehe Glossar). Demgegenüber macht das Signifikanzniveau keine Aussage über die Vertrauens-würdigkeit bzw. Replizierbarkeit einer Studie bzw. deren Ergebnisse. Sollen jedoch Aussa-gen über die Vertrauenswürdigkeit bzw. Replizierbarkeit einer Studie gemacht werden, sind andere statistische Parameter, wie z.B. die Teststärke (d.h. die Wahrscheinlichkeit, in einem Hypothesentest eine korrekte Entscheidung zugunsten der Alternativhypothese zu treffen; siehe Glossar), zu berücksichtigen (siehe Kap. 2.6.3.3).

Die Stichprobengröße per se ist daher nicht als Hauptargument für eine methodische Betrachtung der notwendigen Stichprobengröße hinsichtlich der internen und exter-nen Flotte in simTD geeignet, wenn hierdurch ausschließlich das Erreichen von Signifikanzniveaus erzielt werden soll.

2.6.3.3 Bedeutsamkeit der Teststärke und optimale Stichprobengröße Das Argument „Signifikante Ergebnisse müssen auch praktisch bedeutsam (d.h. in der Reali-tät nicht zu vernachlässigen und replizierbar) sein“ (siehe Kap. 2.6.3.1), adressiert demge-genüber den für die Planung empirischer Untersuchungen bedeutsamen Zusammenhang zwischen der Wahl eines angemessenen Stichprobenumfanges und der Teststärke. Unter der sog. Teststärke wird diejenige Wahrscheinlichkeit verstanden, mit der ein Signifikanztest zugunsten der Alternativhypothese (siehe Glossar) entscheidet, wenn die Alternativhypothe-se in der Population gilt. Oder anders: die Wahrscheinlichkeit, eine praktisch bedeutsame Alternativhypothese auch statistisch absichern zu können.

Ziel einer empirischen Studie, die vertrauenswürdige und replizierbare Ergebnisse anstrebt, sollte daher sein, vorher definierte Teststärkekriterien zu erfüllen. Sind diese Kriterien erfüllt, ist davon auszugehen, dass die Ergebnisse tatsächlich praktisch bedeutsam (d.h. vertrau-enswürdig und replizierbar) sind. In Anlehnung an Cohen (1988) soll nachfolgend davon ausgegangen werden, dass eine Teststärke von 80% genügt (sog. Entscheidungssicherheit), d.h. in 80% der Fälle erfolgt eine Entscheidung zugunsten der Alternativhypothese, wenn diese in der Grundgesamtheit gilt.

Die Teststärke einer Messung wird v.a. durch folgende Einflussgrößen beeinflusst:

1. Signifikanzniveau liberale Signifikanzniveaus führen zu höherer Teststärke


2. Effektgröße (siehe Glossar) größere Effekte führen zu höherer Teststärke

3. Stichprobenumfang große Stichproben führen zu höherer Teststärke

4. Richtung der Hypothese einseitige Signifikanztests (mit einer gerichteten Alternativhypothese, die der Rich-tung des empirischen Ereignisses entspricht) haben höhere Teststärke als zweiseiti-ge Signifikanztests (mit einer ungerichteten Alternativhypothese)

Eine eindeutige Entscheidungssituation bezüglich der praktischen Bedeutsamkeit von Er-gebnissen tritt ein, wenn der Stichprobenumfang so festgelegt wird, dass aufgrund eines empirischen Ergebnisses entweder die Null- oder die Alternativhypothese (siehe Glossar) zu verwerfen ist. Eine „eindeutige“ Entscheidung (z.B. mit 95%iger Sicherheit) erfordert aller-dings sehr große Stichprobenumfänge. Daher wird (in Anlehnung an Cohen, 1988) davon ausgegangen, dass eine 80%ige Entscheidungssicherheit genügt. Stichprobenumfänge mit dieser Eigenschaft werden auch als „optimale Stichprobenumfänge“ bezeichnet. Bortz und Döring (2006, S. 605) definieren:

• „Ein optimaler Stichprobenumfang gewährleistet, dass ein Signifikanztest mit einer Wahrscheinlichkeit von 80% zu einem signifikanten Ergebnis führt, wenn die spezifi-sche H1 den Populationsverhältnissen entspricht.

• Das Risiko einer Fehlentscheidung bei Annahme dieser H1 aufgrund eines signifikan-ten Ergebnisses entspricht hierbei dem Signifikanzniveau (5% bzw. 1%)“.

Das Signifikanzniveau (α), die Teststärke (1–β), die Effektgröße eines Signifikanztests sowie der optimale Stichprobenumfang (n) sind wechselseitig funktional verknüpft (siehe Abbildung 11, siehe auch Glossar). Bei Kenntnis von drei der genannten Größen kann demzufolge die vierte Größe geschätzt werden.

Abbildung 11: Wechselseitige Beziehungen im Signifikanztest (Quelle: Bortz & Döring, 2006, S. 627).

• „Das Signifikanzniveau ist in der empirischen Forschung mit α = 0.01 bzw. α = 0.05 per Konvention festgelegt.

• Eine ähnliche Normierung zeichnet sich für die Klassifikation von Effektgrößen ab (klein, mittel, groß…).

• Auch bezogen auf die Teststärke scheint sich die Scientific Community mittlerweile auf 1–β = 0.80 als einem für viele Fragestellungen angemessenen Wert geeinigt zu haben“ (Bortz & Döring, 2006, S. 627).

Demzufolge kann man die optimale Stichprobengröße (siehe Glossar) anhand theoretischer Vorüberlegungen bzw. anhand von empirischen Vorerfahrungen schätzen. Dies ist z.B. mög-lich über entsprechende Tabellen von Cohen (1988) oder über die exakte Prozedur G*POWER von Erdfelder, Faul und Buchner (1996) möglich.

Die Schätzung der optimalen Stichprobengröße ist daher als Hauptargument für eine methodische Betrachtung sowohl der internen Flotte als auch der externen Flotte in simTD geeignet, wenn hierdurch die praktische Bedeutsamkeit (d.h. Vertrauenswürdig-keit und Replizierbarkeit) von Ergebnissen adressiert wird.


2.6.4 Beispielrechnungen für optimale Stichprobengröße

Nachfolgend sollen einige Beispielrechnungen für die optimale Stichprobengröße (siehe Glossar) dargestellt werden. Diese Beispielrechnungen wurden mittels des Statistiktools G*POWER von Erdfelder et al. (1996) durchgeführt.

Vorbemerkung: Wenn nachfolgend von Stichprobe gesprochen wird, ist die Anzahl von Ein-zeldaten (= Ereignissen) gemeint. Diese Schätzung macht keine Aussagen über die Anzahl verschiedener Fahrzeuge oder Fahrer, die notwendig wären. Es werden lediglich Aussagen gemacht, wie viele Einzeldaten bzw. Ereignisse vorliegen sollten, damit das Kriterium der optimalen Stichprobengröße erfüllt ist.

2.6.4.1 Beispiel: Kontrollgruppen-Design, keine Messwiederholung, kleiner Effekt Tabelle 12 zeigt das Vorgehen zur Schätzung der optimalen Stichprobengröße am Beispiel des Kontrollgruppen-Designs ohne Messwiederholung und unter der Annahme eines kleinen Effekts. Gelistet sind die Ausgangssituation, das zu verwendende inferenzstatistische Ver-fahren, die zu prüfende Hypothese, die statistischen Rahmenbedingungen (Irrtumswahrscheinlichkeit sowie angestrebte Teststärke) sowie das Ergebnis dieses Schätzprozesses.

Für das skizzierte Beispiel wird deutlich, dass insgesamt 620 Ereignisse notwendig sind (je 310 Ereignisse in Kontroll- und Experimentalgruppe), um zu einer 80% richtigen Entschei-dung zu kommen (d.h. in 80% aller Fälle sind Entscheidungen zugunsten der Alternativhypo-these (siehe Glossar) anhand des empirischen Ereignisses korrekt). Tabelle 12: Vorgehen bei Schätzung der optimalen Stichprobengröße für Kontrollgruppen-Design, keine Mess-wiederholung und kleinem Effekt.

Ausgangssituation Die simTD-Flotte fährt einen simTD-Anwendungsfall.

Eine Hälfte der Fahrer erhält eine simTD-Meldung („Experimentalgruppe“), die andere Hälfte erhält keine simTD-Meldung („Kontrollgruppe“).

Es wird a priori angenommen, dass die simTD-Meldung nur einen kleinen Effekt bei den Fahrern zur Folge hat.

Inferenzstatistisches Verfahren

t-Test für unabhängige Stichproben (2-Stichproben-Plan)

Angenommene Effektgröße

Kleiner Effekt, d = 0.2

Hypothese Gerichtete Hypothese:

„simTD-Meldung führt zu größeren minimalen TTC“

Irrtumswahrscheinlichkeit

α = 0.05

Teststärke Power (1-β) = 0.8

Ergebnis Kontrollgruppe und Experimentalgruppe: je n = 310 Ereignisse

Gesamtstichprobe: N = 620 Ereignisse

Errechnete Teststärke: 0.8002178

Abbildung 12 veranschaulicht die Änderungen der Teststärke (= Ordinate) in Abhängigkeit der zur Verfügung stehenden Stichprobengröße (= Abszisse). Es wird deutlich, dass eine Erhöhung der Teststärke von 80% (d.h. in 80% aller Fälle sind Entscheidungen zugunsten der Alternativhypothese (siehe Glossar) anhand des empirischen Ereignisses korrekt) auf


95% (d.h. Entscheidung ist in 95% aller Fälle korrekt) mit einer Stichprobenvergrößerung von 620 Ereignisse auf fast 1100 Ereignisse einhergeht.

Abbildung 12: Optimale Stichprobengröße (Ordinate) in Abhängigkeit von verschiedenen Teststärken („Power“, Abszisse) für ein Kontrollgruppen-Design, keine Messwiederholung, kleine Effektgröße.

2.6.4.2 Beispiel: Kontrollgruppen-Design, keine Messwiederholung, großer Effekt Tabelle 13 zeigt das Vorgehen zur Schätzung der optimalen Stichprobengröße am Beispiel des Kontrollgruppen-Designs ohne Messwiederholung und unter der Annahme eines großen Effekts. Für das skizzierte Beispiel wird deutlich, dass insgesamt 42 Ereignisse notwendig sind (je 21 Ereignisse in Kontroll- und Experimentalgruppe), um zu einer 80% richtigen Ent-scheidung zu kommen (d.h. in 80% aller Fälle sind Entscheidungen zugunsten der Alterna-tivhypothese anhand des empirischen Ereignisses korrekt).

Vorbemerkung: Es wird hier eine identische Situation wie in Kap. 2.6.4.1 geschaffen. Dies-mal wird allerdings (im Gegensatz zu oben) von einem großen Effekt ausgegangen. Tabelle 13: Vorgehen bei Schätzung der optimalen Stichprobengröße für Kontrollgruppen-Design, keine Mess-wiederholung und großem Effekt.



Es wird a priori angenommen, dass die simTD-Meldung nur einen großen Effekt bei den Fahrern zur Folge hat.


t-Test für unabhängige Stichproben (2-Stichproben-Plan)


Großer Effekt, d = 0.8

Hypothese Gerichtete Hypothese:

„simTD-Meldung führt zu größeren minimalen TTC“


α = 0.05


Ergebnis Kontrollgruppe und Experimentalgruppe: je n = 21 Ereignisse

Gesamtstichprobe: N = 42 Ereignisse



Abbildung 13 veranschaulicht die Änderungen der Teststärke (= Ordinate) in Abhängigkeit der zur Verfügung stehenden Stichprobengröße (= Abszisse). Es wird deutlich, dass eine Erhöhung der Teststärke von 80% (d.h. in 80% aller Fälle sind Entscheidungen zugunsten der Alternativhypothese (siehe Glossar) anhand des empirischen Ereignisses korrekt) auf 95% (d.h. Entscheidung ist in 95% aller Fälle korrekt) mit einer Stichprobenvergrößerung von 42 Ereignisse auf fast 70 Ereignisse einhergeht.

Abbildung 13: Optimale Stichprobengröße (Ordinate) in Abhängigkeit von verschiedenen Teststärken („Power“, Abszisse) für ein Kontrollgruppen-Design, keine Messwiederholung, große Effektgröße.

2.6.4.3 Beispiel: Kontrollgruppen-Design mit verkehrlichen Rahmenbedingungen, kleiner Effekt, teilweise abhängige Messung

Tabelle 14 zeigt das Vorgehen zur Schätzung der optimalen Stichprobengröße am Beispiel des Kontrollgruppen-Designs mit verkehrlichen Rahmenbedingungen mit teilweise abhängi-ger Messung und unter der Annahme eines kleinen Effekts. Für dieses Beispiel wird deutlich, dass insgesamt 42 Ereignisse notwendig sind (je 21 Ereignisse in Kontroll- und Experimen-talgruppe), um zu einer 80% richtigen Entscheidung zu kommen (d.h. in 80% aller Fälle sind Entscheidungen zugunsten der Alternativhypothese anhand des empirischen Ereignisses korrekt). Hervorzuheben ist, dass von ein und demselben Fahrer Ereignisse unter jeder der verkehrlichen Rahmenbedingungen auftreten müssen. Ist dies nicht der Fall, ist eine größere Menge an Ereignissen zum Erreichen der optimalen Stichprobengröße notwendig.

Abbildung 14 veranschaulicht die Änderungen der Teststärke (= Ordinate) in Abhängigkeit der zur Verfügung stehenden Stichprobengröße (= Abszisse). Es wird deutlich, dass eine Erhöhung der Teststärke von 80% (d.h. in 80% aller Fälle sind Entscheidungen zugunsten der Alternativhypothese (siehe Glossar) anhand des empirischen Ereignisses korrekt) auf 95% (d.h. Entscheidung ist in 95% aller Fälle korrekt) mit einer Stichprobenvergrößerung von 42 Ereignisse auf 66 Ereignisse einhergeht.

Abbildung 14: Optimale Stichprobengröße (Ordinate) in Abhängigkeit von verschiedenen Teststärken („Power“, Abszisse) für ein Kontrollgruppen-Design mit technischen Rahmenbedingungen, kleine Effektgröße, teilweise abhängige Messung.


Tabelle 14: Vorgehen bei Schätzung der optimalen Stichprobengröße für Kontrollgruppen-Design mit verkehrlichen Rahmenbedingungen, teilweise abhängige Messung und kleinem Effekt.



Alle Fahrer fahren in o.g. Bedingung (mit vs. ohne simTD-Meldung) unter drei verschiedenen verkehrlichen Rahmenbedingungen: Zunächst im freien Ver-kehr, dann im dichten Verkehr und abschließend im gestauten Verkehr.

Es wird a priori angenommen, dass die simTD-Meldung nur einen kleinen Effekt bei den Fahrern zur Folge hat. Dieser Effekt ist abhängig von den verkehrlichen Rahmenbedingungen.


Zweifaktorielle Split-Plot Varianzanalyse (2*3-Plan)

Geprüft wird ausschließlich die Wechselwirkung

Wichtig: Verkehrliche Rahmenbedingung sind als Messwiederholung konzi-piert (d.h. jeder Fahrer muss jede verkehrliche Rahmenbedingung durchfah-ren)


Kleiner Effekt, d = 0.2

Hypothese Wechselwirkung: Gerichtete Hypothese

„simTD-Meldung führt mit zunehmendem Verkehr zu größeren minimalen TTC, ohne simTD-Meldung werden mit zunehmendem Verkehr kleinere minimale TTC gefahren“


α = 0.05


Ergebnis Kontrollgruppe und Experimentalgruppe: je n = 21 Ereignisse notwendig, die jede verkehrliche Rahmenbedingung durchfahren

Gesamtstichprobe: N = 42 Ereignisse, die jede verkehrliche Rahmenbedin-gung durchfahren

Wichtig: Es müssen von ein und demselben Fahrer Ereignisse unter jeder der verkehrlichen Rahmenbedingungen auftreten. Ist dies nicht der Fall, ist eine größere Menge an Ereignissen zum Erreichen der optimalen Stichpro-bengröße notwendig.


2.6.4.4 Beispiel: Kontrollgruppen-Design mit technischen Rahmenbedingungen, gro-ßer Effekt, teilweise abhängige Messung

Tabelle 15 zeigt das Vorgehen zur Schätzung der optimalen Stichprobengröße am Beispiel des Kontrollgruppen-Designs mit verkehrlichen Rahmenbedingungen mit teilweise abhängi-ger Messung und unter der Annahme eines großen Effekts. Für das skizzierte Beispiel wird deutlich, dass insgesamt 6 Ereignisse notwendig sind (je 3 Ereignisse in Kontroll- und Expe-rimentalgruppe), um zu einer 80% richtigen Entscheidung zu kommen (d.h. in 80% aller Fälle sind Entscheidungen zugunsten der Alternativhypothese anhand des empirischen Ereignis-ses korrekt). Hervorzuheben ist, dass von ein und demselben Fahrer Ereignisse unter jeder der verkehrlichen Rahmenbedingungen auftreten müssen. Ist dies nicht der Fall, ist eine größere Menge an Ereignissen zum Erreichen der optimalen Stichprobengröße notwendig.


Vorbemerkung: Es wird hier eine identische Situation wie in Kap. 2.6.4.3 geschaffen. Dies-mal wird allerdings (im Gegensatz zu oben) von einem großen Effekt ausgegangen. Tabelle 15: Vorgehen bei Schätzung der optimalen Stichprobengröße für Kontrollgruppen-Design, keine Mess-wiederholung und großem Effekt.



Alle Fahrer fahren in o.g. Bedingung (mit vs. ohne simTD-Meldung) unter drei verschiedenen verkehrlichen Rahmenbedingungen: Zunächst im freien Ver-kehr, dann im dichten Verkehr und abschließend im gestauten Verkehr.

Es wird a priori angenommen, dass die simTD-Meldung nur einen großen Effekt bei den Fahrern zur Folge hat. Dieser Effekt ist abhängig von den verkehrlichen Rahmenbedingungen.


Zweifaktorielle Split-Plot Varianzanalyse (2*3-Plan)

Geprüft wird ausschließlich die Wechselwirkung

Wichtig: Verkehrliche Rahmenbedingung sind als Messwiederholung konzi-piert (d.h. jeder Fahrer muss jede verkehrliche Rahmenbedingung durchfah-ren)


Großer Effekt, d = 0.8

Hypothese Wechselwirkung: Gerichtete Hypothese

„simTD-Meldung führt mit zunehmendem Verkehr zu größeren minimalen TTC, ohne simTD-Meldung werden mit zunehmendem Verkehr kleinere minimale TTC gefahren“


α = 0.05


Ergebnis Kontrollgruppe und Experimentalgruppe: je n = 3 Ereignisse notwendig, die jede verkehrliche Rahmenbedingung durchfahren

Gesamtstichprobe: N = 6 Ereignisse, die jede verkehrliche Rahmenbedin-gung durchfahren

Wichtig: Es müssen von ein und demselben Fahrer Ereignisse unter jeder der verkehrlichen Rahmenbedingungen auftreten. Ist dies nicht der Fall, ist eine größere Menge an Ereignissen zum Erreichen der optimalen Stichpro-bengröße notwendig.


Abbildung 15 veranschaulicht die Änderungen der Teststärke (= Ordinate) in Abhängigkeit der zur Verfügung stehenden Stichprobengröße (= Abszisse). Es wird deutlich, dass eine Erhöhung der Teststärke von 80% (d.h. in 80% aller Fälle sind Entscheidungen zugunsten der Alternativhypothese (siehe Glossar) anhand des empirischen Ereignisses korrekt) auf 95% (d.h. Entscheidung ist in 95% aller Fälle korrekt) mit einer Stichprobenvergrößerung von 5 Ereignisse auf 6 Ereignisse einhergeht.


Abbildung 15: Optimale Stichprobengröße (Ordinate) in Abhängigkeit von verschiedenen Teststärken („Power“, Abszisse) für ein Kontrollgruppen-Design mit technischen Rahmenbedingungen, große Effektgröße, teilweise abhängige Messung.

2.6.5 Zwischenfazit

Für die methodologische Bewertung der internen und externen Flotte in simTD bleibt somit zusammenfassend festzuhalten:

• Die Stichprobengröße per se ist nicht als Hauptargument für eine methodische Be-trachtung der internen bzw. externen Flotte in simTD geeignet, wenn hierdurch aus-schließlich das Erreichen von Signifikanzniveaus erzielt werden soll.

• Die Schätzung der optimalen Stichprobengröße ist als Hauptargument für eine me-thodische Betrachtung der internen bzw. externen Flotte in simTD geeignet, wenn hierdurch die praktische Bedeutsamkeit (d.h. Vertrauenswürdigkeit und Replizierbarkeit) von Ergebnissen adressiert wird.

Es ist somit nicht die Signifikanz (= Wahrscheinlichkeit eines empirischen Ereignisses unter Annahme einer Nullhypothese; siehe Glossar) für die Konzeption der Versuche in simTD in TP4 und den daraus resultierenden Bewertungen der C2X-Technologie in TP5 von entschei-dender Bedeutung. Vielmehr ist die praktische Bedeutsamkeit, erfasst über die Teststärke (= Wahrscheinlichkeit, eine praktisch bedeutsame Alternativhypothese (siehe Glossar) auch statistisch absichern zu können), als Leitkriterium für die empirischen Arbeiten in simTD zu definieren.

Zufriedenstellende Teststärken (80%, nach Cohen, 1988) können über die Nutzung sog. optimaler Stichprobengrößen erreicht werden. Die optimalen Stichprobengrößen (und somit der wahrscheinlich zu erreichende Grad an praktischer Bedeutsamkeit der empirischen Er-gebnisse) können anhand theoretischer Vorüberlegungen bzw. empirischer Vorerfahrungen im vornhinein ermittelt werden (siehe Kap. 2.6.3.3).

Hieraus resultieren als notwendige Handlungsschritte für die methodologische Bewertung sowohl der internen Flotte als auch der externen Flotte in simTD unter dem Gesichtspunkt der „optimalen Stichprobengröße“:

1. Definition von Hypothesen zur Wirkung des jeweiligen simTD-Anwendungsfalls (ge-richtete vs. ungerichtete Hypothese)

2. Diskussion möglicher Versuchsdesigns

3. Schätzung der angenommen Effektgröße des jeweiligen simTD-Anwendungsfalls

4. Vorauswahl von inferenzstatistischen Prüfverfahren

Die Darstellungen zur Berechnung der optimalen Stichprobengrößen in Kap. 2.6.4 haben z.B. nachfolgende Argumente veranschaulicht:


• Bei kleinen erwarteten Effekten sind große optimale Stichprobenumfänge notwendig, bei großen erwarteten Effekten genügen kleine Stichprobenumfänge.

• Abhängige Messungen (d.h. dieselben Fahrer durchfahren einen Anwendungsfall un-ter verschiedenen Bedingungen) benötigen geringere optimale Stichprobenumfänge.

Daher ist für die methodologische Bewertung der internen und externen Flotte zunächst für jeden der simTD-Anwendungsfälle zu prüfen,

• mit welchen Effektgrößen der jeweilige Anwendungsfall in den nicht-technischen Va-lidierungszielen (Akzeptanz, Sicherheit, Effizienz) einhergeht.

• mit welchen Ausgangshäufigkeiten des jeweiligen Anwendungsfalls beim alltäglichen Fahren (z.B. Pendler, Kuriere, Taxen, Dienstfahrten) zu rechnen ist.

2.7 Verkehrslageermittlung in Abhängigkeit der Fahrzeugzahl

2.7.1 Verbesserte Verkehrslageermittlung für das städtische Versuchsgebiet

Die städtische simTD-Verkehrslage wird „durch Fusion der an stationären Detektoren erfass-ten Verkehrskenngrößen und der fahrzeugseitig erfassten Daten (FCD)“ (Deliverable D11.1. V2.0, S. 22) ermittelt. Fahrzeugdaten werden von simTD Fahrzeugen an die infrastrukturge-bundenen IRS übermittelt und von dort an die Integrierte Gesamtverkehrsleitzentrale (IGLZ) der Stadt Frankfurt am Main weitergeleitet. Die simTD-Fahrzeuge können in zwei Gruppen aufgeteilt werden: Eine interne (gelenkte) und eine externe (ungelenkte) Flotte.

Der Einfluss der internen Flotte auf die Verkehrslageermittlung gilt als unstrittig. Durch die Möglichkeit der Lenkung der Fahrzeuge kann in einem definierten Gebiet mit der vorgesehe-nen Fahrzeuganzahl auf jeden Fall eine ausreichende Penetrationsrate erreicht werden (sie-he simTD-Vorhabensbeschreibung, Version 4.1, 2009).

Daher konzentriert sich dieser Abschnitt nur auf den Einfluss der externen Flotte auf die Ver-kehrslageermittlung. Dazu wird in diesem Kapitel abgeschätzt, welchen Anteil die externe Flotte am Gesamtverkehrsaufkommen (bezogen auf die Verkehrsleistung) im städtischen Versuchsgebiet Niederrad haben kann. Dies erlaubt Rückschlüsse auf den Einfluss auf die Verkehrslageermittlung.

2.7.1.1 Verkehrsleistung im Versuchsgebiet Niederrad Die tägliche Verkehrsleistung sowie die durchschnittliche Fahrweite im Versuchsgebiet Nie-derrad wurden mit Hilfe des städtischen VISUM-Verkehrsmodells ermittelt. Das Versuchsge-biet Niederrad sowie die im VISUM-Verkehrsmodell abgebildeten Strecken und Belastungen sind in Abbildung 16 dargestellt.

Die VISUM Auswertung ergab eine tägliche Verkehrsleistung von 338600 [Fahrzeug*km/ Tag]. Die durchschnittliche Fahrweite wurde mit 2.0 km ermittelt. Die Daten des Verkehrs-modells sind auf einen durchschnittlichen Werktag im Jahr 2002 kalibriert und werden als Grundlage für die Abschätzung als hinreichend genau betrachtet.

Das abgebildete Modellnetz hat eine Streckenlänge von 38.3 Kilometern, wobei Nebenstra-ßen im Verkehrsmodell nicht abgebildet sind. Vor dem Hintergrund, dass die Verkehrsleis-tung dort im Vergleich zum abgebildeten Modellnetz deutlich geringer ausfällt und sich eben-so keine simTD Erfassungseinrichtungen dort befinden, wird diese Unschärfe im Rahmen der Aufgabenstellung akzeptiert. Weiterhin bleibt festzuhalten, dass im Verkehrsmodell nicht zwischen einzelnen Fahrzeugtypen unterschieden wird.


Abbildung 16: Versuchsgebiet Niederrad und VISUM Umlegungsergebnis (Quelle: Stadt Frankfurt).

2.7.1.2 Abschätzung der Verkehrsleistung der externen simTD Flotte Für die Abschätzung wird angenommen, dass die externe Flotte im Versuchsgebiet rekrutiert wird. Dies umfasst Fahrzeuge, deren Nutzer in Niederrad wohnen oder arbeiten sowie Fahr-zeuge deren Nutzer regelmäßig Ziele im Versuchsgebiet Niederrad anfahren oder das Ge-biet durchfahren.

Zur Abschätzung der Verkehrsleistung der externen Flotte wird die aus dem Verkehrsmodell ermittelte durchschnittliche Fahrweite von 2.0 km zugrunde gelegt. Mit der Annahme von 2 Wegen pro Tag im Versuchsgebiet Niederrad ergibt sich eine Verkehrsleistung von 4 [Fahr-zeug*km/Tag] je Fahrzeug der externen Flotte.

Die Anzahl der Wege und die zurückgelegte Strecke werden in erheblichem Maße von den ausgewählten Fahrzeugen abhängen. Es wird allerdings nicht davon ausgegangen, dass sich die durchschnittlichen Fahrweiten signifikant von den aus dem Verkehrsmodell ermittel-ten Werten unterscheiden.

In Bezug auf die Annahme der zurückgelegten Wege bleibt festzuhalten, dass aus Auswer-tungen des deutschen Mobilitätspanels eine durchschnittliche Anzahl von 2.08 Wegen pro Tag und pro mobiler Person mit dem MIV (motorisierter Individualverkehr) ermittelt wurden (Zumkeller, Chlond, Ottmann, Kagerbauer & Kuhnimhof, 2007). Dieser Wert ist in Bezug auf die Verkehrsleistung der externen Flotte im Versuchsgebiet zu reduzieren, da sicherlich nicht alle Wege das Versuchsgebiet Niederrad tangieren. Hingegen wirken sich die Faktoren, dass in diesen Durchschnittswerten auch Personen ohne eigenes Fahrzeug und Führerschein berücksichtigt sind sowie eine eventuelle Mehrfachnutzung der Fahrzeuge, erhöhend auf die Wegeanzahl aus. Daher werden 2 Wege pro Tag für Fahrzeuge der externen Flotte im Ver-suchsgebiet Niederrad, ohne weitere Analyse, als realistische Abschätzung angesehen.

2.7.1.3 Anteil der Verkehrsleistung der externen Flotte im Tagesdurchschnitt Bei einer Größe der externen Flotte von 300 Fahrzeugen, die im Versuchsgebiet Niederrad beheimatet sind, erzeugen diese eine Verkehrsleistung nach oben getroffenen Annahmen von 200 [Fahrzeug*km/Tag]. Demgegenüber steht die Gesamtverkehrsleistung im Ver-


suchsgebiet von 338 600 [Fahrzeug*km/Tag]. Damit beträgt der Anteil der externen Flotte im Tagesdurchschnitt 3.5 ‰ am Gesamtverkehrsaufkommen im Versuchsgebiet.

2.7.1.4 Maximalbetrachtung zur Spitzenstunde Betrachtet man die Gruppe der Berufspendler isoliert, so ist anzunehmen, dass diese ihre Wege zeitlich konzentriert in den Berufsverkehrszeiten zurücklegen. Im Folgenden konstru-ierten Beispielfall besteht die externe Flotte ausschließlich aus Berufspendlern, die in der Zeit der Verkehrsspitzenstunde mit ihrem Fahrzeug im Bereich Niederrad einen Weg (2 km) zurücklegen. Dabei ist hervorzuheben, dass es sich hier um eine Maximalabschätzung han-delt. Der berechnete Anteil wird in der Praxis nicht zu erreichen sein.

Im Allgemeinen gilt, dass 10 Prozent der täglichen Verkehrsleistung eine gute Abschätzung der Verkehrsleistung der Spitzenstunde ist.

Verkehrsleistung in der Spitzenstunde: 33 860 [Fahrzeug*km/h]

davon Verkehrsleistung der externen Flotte: 600 [Fahrzeug*km/h]

Maximaler Anteil an der Verkehrsleistung: 1,77 %

2.7.1.5 Ergebnis Auch die geringen Anteile der externen Flotte am Gesamtverkehrsaufkommen im Versuchs-gebiet Niederrad werden zu einer erheblichen Verbesserung der Verkehrslageermittlung, im Vergleich zu einem System das ausschließlich auf stationärer Verkehrsdatenerfassung auf-baut, führen. Nur mit den Daten der simTD-Flotte sind Kenngrößen, wie z.B. der Geschwin-digkeitsverlauf und damit Reisezeiten auf einzelnen Streckenabschnitten, zu ermitteln. Nur mit Hilfe der externen Flotte können Rückschlüsse auf eine (ungelenkte) Routenwahl gezo-gen werden, welche wichtige Grundlagen für eine weitere Prognose bilden.

Der ermittelte Anteil macht es allerdings nicht möglich, teilweise auf eine stationäre Datener-fassung zu verzichten. Es wird vermutet, dass deutlich höhere Penetrationsraten notwendig sind. Im Zusammenspiel mit der internen Flotte können diese im weiteren Projektverlauf er-mittelt werden.

2.7.2 Verbesserte Verkehrslageermittlung für das Versuchsgebiet des Landes Hessen in Abhängigkeit der Fahrzeugzahl

Die Ermittlung der Verkehrslage stellt für die Steuerung und die Optimierung des Verkehrs-ablaufs auf Straßen und Autobahnen eine sehr wichtige Grundlage dar, auf der viele weitere Berechnungen und Maßnahmen aufbauen. Daher ist es wichtig, dass die ermittelte Ver-kehrslage den realen Verkehrszustand korrekt abbildet.

Durch stationäre Detektoren lässt sich an einzelnen Punkten im Straßennetz eine Verkehrs-lage ermitteln. Hier befindet sich zwischen zwei Messquerschnitten ein Streckenabschnitt der Länge x, auf dem die Verkehrslage nicht genau zu ermitteln ist bzw. variieren kann. Dieses Defizit kann durch den Einsatz von fahrenden Sensoren geschlossen werden. Mittels Floa-ting Car Data (FCD) kann die Verkehrslage im gesamten Netz besser erfasst werden.

Hierzu werden in der Versuchszentrale die Daten der stationären Detektoren mit den Daten von den Versuchsfahrzeugen fusioniert. Die Verkehrslage auf Bundesautobahnen und für das nachgeordnete Netz wird somit noch detaillierter dargestellt. In Zukunft ist somit die Möglichkeit gegeben, auf Streckenabschnitten ohne stationäre Detektoren eine Verkehrslage durch Floating Car Data zu ermitteln. Dies ist insbesondere für die Erfassung der Verkehrs-


lage im nachgeordneten Netz von herausragender Bedeutung, da in diesem Bereich in der Regel nur vereinzelte stationäre Detektoren zur Verfügung stehen.

Eine genaue Verkehrslageermittlung mit Hilfe von FCD ist jedoch nur möglich, wenn genü-gend Fahrzeuge FCD übertragen. Die notwendige Ausstattungsrate, bei der die über die stationäre Detektion ermittelte Verkehrslage verbessert wird, ist im Projekt simTD durch die Versuche und die Simulation zu ermitteln. Weiterhin ist von Bedeutung, ab welcher Ausstat-tungsrate an FCD-Fahrzeugen auf die stationäre Detektion reduziert werden kann. Im Hin-blick auf Streckenabschnitte ohne stationäre Detektion im nachgeordneten Netz ist insbe-sondere von Interesse, inwieweit mit den Daten einzelner Fahrzeuge bereits eine aussage-kräftige Verkehrslage ermittelbar ist. Diesbezüglich werden vor allem von den Fahrzeugen der externen Flotte wichtige Erkenntnisse erwartet.


3 Versuchsgebiet

3.1 Planung ITS Roadside Station-Standorte

Das folgende Kapitel beschreibt die Planung der Standorte für die ITS Roadside Station. Die Planung für das regionale Versuchsgebiet wurde vom Hessischen Landesamt für Straßen- und Verkehrswesen durchgeführt. Die Standortplanung für das städtische Versuchsgebiet wurde von der Stadt Frankfurt am Main erbracht.

3.1.1 Planung ITS Roadside Stations (IRS) – Standorte für das regionale Ver-suchsgebiet

Für den Feldversuch im Projekt simTD werden zur Kommunikation mit der ITS Central Station (ICS) so genannte ITS Roadside Station (IRS) durch das Hessische Landesamt für Straßen- und Verkehrswesen (HLSV) an Autobahnen und Bundesstraßen aufgebaut. Die IRS bilden die Schnittstelle zur Datenübertragung zwischen Fahrzeug und ITS Central Station und agg-regieren/vorverarbeiten Daten, die dann in die ITS Central Station (ICS) übertragen werden. Die Schnittstelle von der IRS zum Fahrzeug wird über WLAN realisiert und die Schnittstelle der IRS zur ITS Central Station wird über Lichtwellenleiter (LWL) oder 3G-Mobilfunk reali-siert.

Bei der Auswahl der IRS-Standorte haben folgende Faktoren einen Einfluss:

• Bereitstellung eines Streckenabschnitts, auf dem eine vollständige Versorgung ("Aus-leuchtung") mit WLAN gegeben ist.

• Berücksichtigung von Autobahnanschlussstellen, Autobahnkreuzen und Autobahn-dreiecken sowie lichtsignalgeregelten Knotenpunkten und planfreien Knotenpunkten auf Bundesstraßen

• Vermeidung von Funkabschattungen (Brücken etc. können die Reichweite von WLAN-Funkwellen beeinträchtigen)

• Nutzung vorhandener Standorte an bestehenden Anlagen (Streckenstation, Lichtwel-lenleiter und Strom vorhanden)

• Herstellung eines "Lückenschlusses" zum städtischen Versuchsgebiet

Als Resultat der intensiven Planungen des HLSV für die Standorte der IRS hat sich als Er-gebnis der in Abbildung 17 befindliche schematische Plan mit Angaben zu den Standorten der IRS ergeben. Zusätzlich wurde jeder der Standorte fotografisch aufgenommen.

Die Planung hat ergeben, dass 58 IRS an Autobahnen und 22 IRS an Bundesstraßen instal-liert werden. Hierbei sind 44 IRS per Lichtwellenleiter und 36 IRS über 3G-Mobilfunk an die ITS Central Station angeschlossen.


Abbildung 17: IRS-Standorte regionaler Bereich (Quelle: HLSV).


3.1.2 Planung ITS Roadside Stations (IRS) - Standorte für das städtische Ver-suchsgebiet

Das städtische simTD-Versuchsgebiet befindet sich im Stadtteil Frankfurt-Niederrad (siehe Abbildung 18). Die IRS werden im städtischen Versuchsgebiet über die Steuergeräte der Lichtsignalanlagen angebunden und dort auch räumlich untergebracht. Daher kann die vor-handene Stromverbindung des Steuergeräts mit genutzt werden. Die Stadt Frankfurt am Main verfügt über ein eigenes Kabelnetz, über das die Lichtsignalanlagen im Stadtgebiet mit der Integrierten Gesamtverkehrsleitzentrale (IGLZ) verbunden sind. Diese bereits bestehen-de Kabelverbindung wird im Rahmen des Projektes simTD für die Datenübertragung genutzt. Die Infrastrukturanbindung erfolgt in der Regel über eine Kombination von Kupferdraht- und Lichtwellenleiteranbindung.

Fernbahnhof

Frankfurt am Main

HBF

MesseFrankfurt

VZH

Arena

IGLZ

661

3

3

5

66

66

NordwestkreuzFrankfurt

WestkreuzFrankfurt

FrankfurterKreuz

OffenbacherKreuz

AS Frankfurt-Süd

AS Frankfurt Miquelallee

Miq

uel

all e

e

Theodor-Heuss-Allee Ebert-Ebert-Anlage

F riedens-

brücke

Kenne

dyalle

e

Mör

f el d

er L

ands

t raße

648

648

661

B43B43

5 Frankfurt- Niederrad Bürostadt

Abbildung 18: Ausschnitt aus dem simTD Versuchsgebiet. Die Planung und Positionierung der städtischen IRS erfolgte zum einen durch eine Be-standsaufnahme der Infrastruktur (LSA-Standorte und Platzverfügbarkeit im Schaltschrank der Steuergeräte). Zum anderen über eine Zusammenarbeit und Abstimmung mit dem Lehr-stuhl für Verkehrstechnik der TU München (TUM-VT), der Hochschule für Technik und Wirt-schaft des Saarlandes (HTW), der Firma GEVAS Software (Realisierung der Funktion F_1.3.2 LSA-Netzsteuerung und F_2.2.2 Ampelphasenassistent) und der Verkehrszentrale Hessen (VZH). Für den Entscheidungsprozess wurden Kenntnisse aus Vorläuferprojekten und der zu realisierenden C2I-Funktionen herangezogen.

Da das städtische Versuchsgebiet eine unterschiedlich dichte Bebauung aufweist, werden für die IRS-Reichweitentests einmal 200 Meter und 500 Meter als Abstand zwischen 2 IRS gewählt. So wird durch die unterschiedliche Bebauung im Versuchsgebiet und die variable Reichweite eine Übertragbarkeit der Ergebnisse auf andere deutsche Städte gewährleistet.

Städtischer Bereich

Regionaler Bereich


Die minimale Reichweite von 200 Metern zur Positionierung der IRS wurde im Stadtteil Nie-derrad gewählt (siehe Abbildung 18). Dieser Stadtteil zeichnet sich durch eine vielfältige Be-bauung aus: Zum einen aufgelockerte Strukturen, Grünflächen, aber auch Hochhäuser in der Bürostadt Niederrad. So besteht die Möglichkeit, durch Abschalten einzelner IRS Reichweitentests von 200 Meter und 400 Meter bei unterschiedlichen Örtlichkeiten durchzu-führen. Aufgrund dieser Rahmenbedingungen bzw. Kriterien ist eine Anzahl von 20 IRS für den Stadtteil Niederrad geplant.

Die charakteristische Bebauung, sog. Häuserschluchten, welche sich auf dem Abschnitt von der A648 bis zum Frankfurter Hauptbahnhof (sog. Lückenschluss zwischen dem regionalen und städtischen Versuchsgebiet) befinden, sind vergleichbar mit anderen Großstädten und eignen sich daher ebenfalls für eine Übertragbarkeit auf andere Städte in Deutschland. Es wurde ein Abstand von 500 Metern gewählt. Es ist eine Anzahl von 3 IRS vorgesehen.

Die Abbildung 19 gibt den aktuellen Planungsstand wieder. Geringfügige Anpassungen sind ggf. nötig, falls sich bei dem Ausbau der Infrastruktur Änderungen technischer Art ergeben, die ein Verlegen der IRS erforderlich machen könnten.

Abbildung 19: IRS-Standorte städtischer Bereich.

3.2 Konzeption Erhebung von Detailinformationen über das Versuchs-gebiet

3.2.1 Städtisches Versuchsgebiet

Die Erhebung von Detailinformationen über den städtischen Bereich des Versuchsgebiets dient der Organisation des Versuches und soll den Versuchsleitern die Möglichkeit geben, auf Änderungen im Versuchsablauf kurzfristig zu reagieren, z.B. die Fahrzeuge der internen Flotte auf geeignete Parkplätze zu leiten oder sie auf schnellstem Wege in das bzw. aus dem

Legende: IRS im städtischen Versuchs-gebiet

IRS „Lückenschluss“ zur BAB 648

IRS der VZH


Versuchsgebiet zu leiten. Darüber hinaus sollen den Fahrern der internen Flotte Informatio-nen über Versorgungsstellen und Notfalleinrichtungen mit Parkmöglichkeiten zur Verfügung gestellt werden können.

Aus diesen Anforderungen resultieren bestimmte interessante Ortstypen (sog. Points of Interest, POI), die in enger Zusammenarbeit mit dem IZVW der Universität Würzburg defi-niert wurden. Folgende Points of Interest werden erhoben:

• Parkplätze

• Parkhäuser

• Supermärkte

• Apotheken

• Krankenhäuser, Ambulanzen

• Polizeidienststellen

• Toiletten

• Tankstellen

• Cafés

• Imbiss-Schnellrestaurants

• Geldautomaten / Banken

Zu den POIs werden die in Tabelle 16 gelisteten Attribute und Details festgehalten. Tabelle 16: Beschreibung der Attribute und Details der POIs im Versuchsgebiet.

Attribut Details

Lage / Straße Straßenname und Hausnummer, durchgehende Nummerie-rung der POIs. Nummer wird an Stelle der Zufahrt in Plan eintragen, bei erkennbarem Eigentümer wir dieser vermerkt.

Öffnungszeiten Parkplatz abschließbar? Wenn ja, Öffnungszeiten angegeben (falls bekannt).

Toilette Ja / Nein

Einkaufsmög-lichkeiten

Ja / Nein

Parkplätze Anzahl Anzahl abgeschätzt. (1) 10 - 20 Stellplätze, (2) 20 - 50 Stell-plätze, (3) mehr als 50 Stellplätze, (4) mehr als 100 Stellplätze

Belegung Belegung abgeschätzt (gering (bis ca. 25% Auslastung), mittel (25% bis 75% Auslastung), hoch (mehr als 75% Auslastung). Uhrzeit der Erfassung

Öffentlich / Privat

(1) öffentlich (2) privat

Eigentümer Wenn der Parkplatz zu einem Supermarkt/einer Firma etc. gehört, wird der Name angeben.

Nutzungsein-schränkung

Nur für Kunden, Lieferverkehr etc.

Kosten Höhe der Parkgebühr


Es ist nicht für jeden POI notwendig, alle Attribute zu erheben. Die getroffene Vorauswahl ist in nachfolgender Tabelle 17 angegeben. Tabelle 17: Zuordnung der Attribute zu den POIs im Versuchsgebiet.

Lage

/ Stra

ße

Öffn

ungs

zeite

n

Toile

tte

Eink

aufs

mög

lichk

eit

Parkplätze

Anza

hl

Bel

egun

g

öffe

ntlic

h/pr

ivat

Eig

entü

mer

Nut

zung

sein

schr

än-

kung

Kos

ten

Parkplatz x x x x x x x x

Parkhaus x x x x x x x x

Supermarkt x x x x

Apotheke x x

Krankenhäuser x x

Polizeidienststellen x x

Toilette x x x

Tankstelle x x x x x X

Cafés x x x x

Imbiss x x x x x x x X

Geldautomat x x

Alle erhobenen Informationen werden in einer Excel-Datei festgehalten. Dabei erhalten alle POIs eine Kennung (z.B. „P“ für Parkplatz) und eine Nummerierung. Darüber hinaus wird jeder aufgeführte Ort zusätzlich fotografiert. Die Dateinamen der Fotos werden ebenfalls in der Excel-Datei vermerkt, um eine eindeutige Zuordnung zu ermöglichen. Durch Hyperlinks sind die entsprechenden Zellen mit den Fotos verknüpft. Neben den genannten Informatio-nen werden die Koordinaten der POIs in der Excel-Datei festgehalten.

Neben der tabellarischen Aufstellung werden die Orte auf einer Karte eingetragen. Dies er-möglicht eine übersichtliche Verortung aller POIs. Die Kennung und Nummerierung ent-spricht der der oben erwähnten Tabelle 17.

3.2.2 Regionaler Bereich

Informationen über das Versuchsgebiet im regionalen Bereich werden bei den Planungen und Vorbereitungen für die Versuche, bei der Durchführung der Versuche und bei der Aus-wertung der Versuche unterstützen und notwendige Informationen liefern. Die Angaben sind auch für die Verkehrs- und Fahrsimulation von Bedeutung. Zu den folgend aufgeführten Sys-temen und Anlagen werden Detailinformationen (wie z.B. der Standort und der aktuelle An-zeigestatus) erhoben bzw. aus der Verkehrszentrale Hessen bereitgestellt:


Verkehrsbeeinflussungsanlagen/-systeme

• Streckenbeeinflussungsanlagen: Sie dienen zur Erhöhung der Verkehrssicherheit und zur Homogenisierung des Ver-kehrsflusses durch die Anzeige von Gefahrenwarnungen sowie verkehrsabhängigen Geschwindigkeitsbeschränkungen. Die digitalen Anzeigen auf den Wechselverkehrs-zeichenbrücken sind ein- bzw. abschaltbar (siehe Abbildung 20).

Abbildung 20: Wechselverkehrszeichenbrücke.

• Wechselwegweiser: Bei Verkehrsbehinderungen im Netz leiten die Wechselwegweiser die Verkehrsteil-nehmer auf geeignete Ausweichrouten. Besteht z.B. auf der Hauptroute ein Stau, so kann der Wechselwegweiser den Fahrzeugführer auf eine schnellere Alternativroute leiten (siehe Abbildung 21).

Abbildung 21: Wechselwegweiser.

• Dynamische Wechselwegweiser mit integrierten Stauinformationen – dWiSta: Das Verkehrsleitsystem dWiSta informiert die Verkehrsteilnehmer mittels digitaler An-zeigen über Ursache, Lage und Auswirkung von Verkehrsbehinderungen und leitet sie auf geeignete Ausweichrouten um. Fahrzeuge werden optimal im Autobahnnetz verteilt, Staus und Reisezeiten spürbar reduziert. Die gute Informationslage bei den Verkehrsteilnehmern führt zu einer entspannten Fahrweise und das Unfallrisiko wird dadurch gesenkt (siehe Abbildung 22).


Abbildung 22: Dynamische Wechselwegweiser mit integrierter Stauinformation – dWiSta.

• Dynamische Informationstafeln zur Reisezeitanzeige – dIRA: Die dynamischen Anzeigen am Straßenrand informieren über die verbleibende Fahr-zeit bis zu einem bestimmten Punkt im Autobahnnetz (z.B. Autobahnkreuze). Da-durch können Autofahrer besser planen und entspannter fahren. Im Falle erhöhter Reisezeiten ist mit Verkehrsbehinderungen auf der Strecke zu rechnen. Das Auswei-chen auf eine Alternativroute ist dank dIRA frühzeitig möglich. dIRA ist auch als Onli-ne-Reisezeitenservice unter www.staufreieshessen2015.de verfügbar (siehe Abbildung 23).

Abbildung 23: Dynamische Informationstafeln zur Reisezeitanzeige – dIRA.

• temporäre Seitenstreifenfreigabe: Die temporäre Seitenstreifenfreigabe steigert die Straßenkapazität dreistreifiger Rich-tungsfahrbahnen um etwa 20 bis 25% und reduziert so Staus und Reisezeiten. Stark frequentierte Autobahnabschnitte werden zu Stoßzeiten entlastet, hessenweit auf 65 Autobahnkilometern. Ein Ausbau auf insgesamt 350 Kilometer ist in den kommenden Jahren geplant. Die Verkehrszentrale Hessen (VZH) steuert die Freigabe der Seiten-streifen je nach Verkehrslage und kontrolliert den Seitenstreifen rund um die Uhr auf unerwartete Sicherheitsrisiken (z.B. Pannenfahrzeug) per Videobeobachtung (siehe Abbildung 24).

http://www.staufreieshessen2015.de/�


Abbildung 24: Temporäre Seitenstreifenfreigabe.

• Baustellenmanagementsystem: Im Baustellenmanagementsystem (BMS) sind laufende und geplante Baustellen auf den Autobahnen verzeichnet. Das Baustellenmanagementsystem bewertet geplante Baustellen hinsichtlich ihrer Verkehrsauswirkung vorab und übt so Einfluss auf den Zeitpunkt der geplanten Baumaßnahme aus. Bei Großveranstaltungen oder zum Fe-rienstart wird auf Tagesbaustellen sogar gänzlich verzichtet – zugunsten des Ver-kehrsflusses und der Reisezeit. Die Stauzeiten an Baustellen in Hessen reduzierten sich durch den Einsatz des BMS um mehr als die Hälfte.

• Tagesbaustellen (Dynamische Ortung von Arbeitsstellen - DORA): Das System DORA liefert Informationen über Tagesbaustellen im Netz. Über GPS werden die zur Baustellensicherung eingesetzten Warnanhänger geortet. In der Ver-kehrszentrale Hessen (VZH) laufen alle Daten zusammen. Diese bilden die perfekte Grundlage für effiziente Steuerungsmaßnahmen, die den Verkehr über baustellen-freie Strecken leiten können.

Parkplätze und Raststätten auf Bundesautobahnen und Bundesstraßen

• Für die Versuche mit der internen Flotte ist es unter Umständen notwendig, auch während der Versuche einen Startpunkt, Treffpunkt oder Ruhepunkt zu haben. Dafür sind Parkplätze auf Autobahnen und Bundesstraßen als sinnvoller Treffpunkt zu nut-zen. Hierzu werden der Ort und die ungefähre Anzahl an Parkplätzen erhoben. Zu-dem ist es hier für die Versuchsfahrer möglich eine Toilette aufzusuchen.

Tankstellen im Bereich des Versuchsgebiets

• Für notwendige Betankungen der internen simTD-Flotte werden die Standorte und An-zahl der geeigneten Zapfsäulen erhoben. Hierbei werden auch Tankstellen auf Rast-anlagen vorhanden sein, so dass Tanken und Parken kombiniert werden kann.

3.2.3 Beschilderung

Einige Funktionen, wie z.B. der Verkehrszeichenassistent (F_2.2.1), benötigen Informationen über statische Verkehrszeichen im Versuchsgebiet. Auch für die Auswertung und Interpreta-tion der während des Versuchs fahrzeugseitig erhobenen Daten sind diese Informationen relevant. Dazu wird in der ITS Central Station eine Verkehrszeichendatenbank aufgebaut.


Die Aufnahme der Verkehrszeichen für die Bundesautobahnen und Bundesstraßen wird durch das Hessische Landesamt für Straßen- und Verkehrswesen durchgeführt, für die städ-tischen Straßen durch die Stadt Frankfurt am Main. In die Datenbank werden Vorschrift-, Richt- und Gefahrzeichen aufgenommen. Zusätzlich werden Attribute wie z.B. die Position und die Fahrtrichtung hinterlegt. Jedoch wird nicht jedes im Verkehrszeichenkatalog aufge-führte Verkehrszeichen erfasst – es wird eine Auswahl in Absprache mit der Funktion Ver-kehrszeichenassistent (F_2.2.1) geben und somit eine Beschränkung auf die wichtigsten Verkehrszeichen geben.

3.3 Videobefahrung des Versuchsgebiets und Bereitstellungstool für die erhobenen Videos

Am 28./29. Oktober 2009 wurden von TUM-VT Befahrungen des Versuchsgebietes durchge-führt. Diese hatten das Ziel, einen besseren Eindruck für die Details und die verkehrstechni-sche Zusammensetzung des Raums Frankfurt-Niederrad sowie der Autobahn A5 und der Bundesstraße B3 zu generieren. Die Fahrten wurden mithilfe einer Videokamera und eines GPS-Empfängers aufgezeichnet. Die Befahrungen erfolgten auf den Hauptverkehrsstraßen des innerstädtischen Versuchsgebietes sowie auf der A5 in Richtung Norden und der B3 in Richtung Süden.

Die aufgezeichneten Videos erlauben eine detaillierte Rekonstruktion der verkehrstechni-schen Gegebenheiten für die Auswertung. Um später schnell erste Rückschlüsse auf poten-tielle Einflussfaktoren ziehen zu können, ist es notwendig, die realen Gegebenheiten umge-hend visuell abrufen zu können, ohne jedes Mal vor Ort anwesend sein zu müssen. Als sinn-volles Hilfsmittel wurden KML- (bzw. KMZ-) Dateien gewählt. Die sog. Keyhole Markup Lan-guage (KML) ist ein XML-basiertes Dateiformat und ermöglicht es, Einzelbilder mit Geokoor-dinaten zu verknüpfen und diese auf einer georeferenzierten Karte darzustellen.

Zur Realisierung wurden die verschiedenen Videos – nach Autobahn und innerstädtischem Bereich getrennt – in Einzelbilder zerlegt und manuell verkehrstechnisch relevante Stellen extrahiert. Als verkehrstechnisch relevante Stellen wurden Verkehrsschilder, Kreuzungs- und Einmündungsbereiche, Fahrstreifenreduktionen sowie Brücken definiert. Für jedes der Ein-zelbilder wurde ein entsprechender Zeitstempel aus dem Erstellungszeitpunkt und dem ent-sprechenden Offset innerhalb des Videos berechnet und als Metadatum (Exif) an die Bildda-tei angefügt. Eine Verknüpfung, basierend auf den Zeitstempeln der Bilder und der in den GPS-Informationen enthaltenen Zeit, erlaubt nun eine genaue Zuordnung eines Bildes zu einer Geokoordinate.

Parallel hierzu hat das IZVW am 28. Oktober 2009 eine Befahrung des städtischen Ver-suchsgebiets und der angrenzenden Autobahnen A3 und A5 durchgeführt. Der nördliche Teil des regionalen Versuchsgebiets (z.B. A5 nördlich des Frankfurter Westkreuzes bis Friedberg und B3 Frankfurt ↔ Friedberg) ist darin nicht enthalten.

Die Befahrung fand mit einem Fahrzeug des IZVW mit Unterstützung der Stadt Frankfurt am Main statt. Das Fahrzeug war mit zwei nebeneinander montierten und frontal ausgerichteten Videokameras ausgestattet, welche eine weitwinklige Ansicht der Straße aufzeichneten. Gleichzeitig wurden die Daten eines GPS-Empfängers aufgezeichnet.

Bei der Befahrung wurde darauf geachtet, dass alle städtischen Knotenpunkte mit IRS abge-fahren und aufgezeichnet wurden. An diesen IRS-Knotenpunkten wurden während der Fahrt sog. Marker in das Aufzeichnungstool eingegeben. Die Befahrung des Versuchsgebiets er-folgte in drei Runden (siehe Anhang 2: Befahrung des Versuchsgebiets durch IZVW, Abbildung 72 bis Abbildung 74):


1. Baseler Straße – Stresemannallee – Mörfelder Landstraße – Alt-Niederrad – Büro-stadt Niederrad – Alt-Niederrad – Kennedyallee

2. Theodor-Stern-Kai – Alt-Niederrad – A5 AS Frankfurt-Niederrad – Frankfurter Kreuz – A3 AS Frankfurt Süd – Mörfelder Landstraße – Kennedyallee

3. Theodor-Stern-Kai – Niederräder Ufer – A5 AS Frankfurt-Niederrad – Westkreuz Frankfurt – A648 (Theodor-Heuss-Allee) – Friedrich-Ebert-Anlage

Die aufgezeichneten GPS-Daten wurden mit einem Map-Matching Tool auf die Karte des OpenStreetMap-Projekts (www.openstreetmap.org) georeferenziert. Dieser erweiterte Da-tensatz (der nun z.B. Straßennamen enthält) kann mit dem von der WIVW GmbH entwickel-ten Tool „SILABVideoAnalysis“, das innerhalb des simTD-Projekts kostenfrei zur Verfügung gestellt wird, synchron mit den Videos betrachtet werden.

Abbildung 25: Hauptfenster von SILABVideoAnalysis (Quelle: WIVW GmbH).

SILABVideoAnalysis kann direkt von der den Projektpartnern zur Verfügung gestellten DVD gestartet werden. Die Bedienung des Programms wird anhand des Abbildung 25 enthaltenen Screenshots erläutert:

• Über das Menü oder das „Öffnen“-Icon (1) kann die Datei simTD-Versuchsgebiet.vp geöffnet werden, die alle Informationen über die Befahrung enthält. Das Video wird im Videofenster (2) dargestellt. Die Steuerung erfolgt über die üblichen Start – Pause – Stop Knöpfe (5), über den Positionsregler (5) kann direkt eine bestimmte Position des Videos angesprungen werden.

• Die in der Liste (3) aufgeführten Marker enthalten die Positionen der simTD IRS, die durch einen Doppelklick direkt im Video angesprungen werden können.

• GPS-Koordinaten und Karteninformationen werden im Datenfenster (4) dargestellt. Es wird jeweils der zur aktuellen Videoposition gehörende Wert angezeigt.

• Mit der Suchfunktion (6) können Marker-Namen und Variablenwerte nach bestimm-ten Texten oder Werten durchsucht werden.

1

2

3

4

5

6

http://www.openstreetmap.org/�


3.4 Konzeption Verortung der Versuchsfälle: Auswählen der Versuchs-teilgebiete

Für die Verortung der Versuchsfälle auf das Versuchsgebiet wird eine stufenweise Bearbei-tung vorgeschlagen.

In einem ersten Schritt wurde eine grundsätzliche Unterscheidung der Anwendungsfälle vor-genommen, je nachdem, ob eine Anwendung auf städtischem bzw. regionalem Versuchsge-biet erfolgen soll. Diese Einteilung wurde in Zusammenarbeit von TUM-VT, IZVW und dem jeweiligen Funktionsentwicklungsteams (FET) im Rahmen von AP13 vorgenommen und im Deliverable D13.2 dargestellt. Einige Versuchsfälle sind entweder nur für Bundesautobahnen (z.B. A_2.1.1.4 Baustellenwarnung), für Bundesstraßen oder für das städtische Versuchsge-biet (z.B. A_1.3.2.1 Optimierung des LSA-gesteuerten Verkehrsflusses) relevant. Ein weite-rer Aspekt stellt die Sicherheit aller Verkehrsteilnehmer im Hinblick auf die Durchführbarkeit der Versuche im öffentlichen Straßennetz dar. Ob alle Versuche, die für den öffentlichen Straßenraum vorgesehen sind, auch wirklich dort durchgeführt werden können oder im ab-geschlossen Testgelände, wird in Kap. 2.3 ausführlich beschrieben.

Als zweiter Schritt zur Verortung der Versuchsfälle wurden die schon in anderen Arbeitspa-keten geleisteten Arbeiten herangezogen. Dazu gehört die in Deliverable D13.2 erarbeitete Einteilung der verschiedenen Versuchs- bzw. Testorte (Prüfstand, Fahrsimulation, Verkehrs-simulation, Testgelände und Versuchsgebiet). Aufgrund dieser Einteilung konnte die Anzahl der Varianten der nicht-technischen Versuchsfälle für die jeweilige Versuchsumgebung er-mittelt werden (siehe Kap. 2.1.1.6). Die Einteilung der technischen Versuchsfälle zu den Ver-suchs- bzw. Testorten ist zum Zeitpunkt der Erstellung des Deliverable nicht abgeschlossen und wird daher hier noch nicht aufgeführt.

Um zu einer Auswahl der Versuchsteilgebiete für den jeweiligen Versuchsfall zu gelangen, erfolgt nun der dritte Schritt, das Aufstellen einer „Anforderungs-Checkliste“. Die Anforderun-gen der jeweiligen Versuchsfälle ergeben sich zum einen aus den in Deliverable D13.2 be-schriebenen Versuchsschritten und zum anderen aus zusätzlichen Informationen in den Drehbüchern (z.B. Parkplatz für Zwischenhalte). In Deliverable D13.3 erfolgte bereits eine erste grobe Auflistung der notwendigen verkehrlichen Voraussetzungen für den jeweiligen Versuchsfall (z.B. einstreifige Fahrbahn mit max. zulässiger Geschwindigkeit von 70 km/h). Eine solche Anforderungs-Checkliste, um den Versuchsfall durchführen zu können, sollte daher sowohl verkehrliche als auch organisatorische Kriterien beinhalten. Dies könnten bei-spielsweise folgende Merkmale sein:

Autobahnen:

• Wird ein Abschnitt der Autobahn mit hoher Ausstattungsrate an IRS gefordert, so ist der Versuchsfall dem Abschnitt der A5 von Anschlussstelle Friedberg bis zum Bad Homburger Kreuz zuzuordnen.

• Fordert ein Versuchsfall einen Streckenabschnitt, wo keine kollektiven Verkehrsbe-einflussungsanlagen vorhanden sind, so ist die A661 vom Bad Homburger Kreuz bis zum Offenbacher Kreuz zu wählen.

• Ist ein Autobahnabschnitt mit 4, 3 oder 2 Fahrstreifen pro Fahrtrichtung gefordert, so ist der entsprechende Teilabschnitt auf Autobahnen auszuwählen.

• Ist ein Autobahnabschnitt ohne bzw. mit Geschwindigkeitsbeschränkung, LKW-Überholverbot etc. gefordert, so sind mögliche Abschnitte zu identifizieren und kurz vor dem Versuch auf Aktualität zu prüfen.


Bundesstraßen:

• Wird eine Bundesstraße mit direktem Anschluss an die Autobahn gefordert, so ist dies im regionalen Bereich über die B3, B275 und B455 möglich.

• Ist eine Bundesstraße mit direktem Anschluss an das städtische Versuchsgebiet ge-fordert, so ist die B43 zu wählen.

• Ist eine Bundesstraße mit 2 Fahrstreifen erforderlich, so ist die B3 ab dem Preunges-heimer Dreieck zu wählen.

Stadtstraßen:

• Notwendige Verkehrsinfrastruktur, z.B. Verkehrszeichen, LSA

• Infrastruktur baulicher Art, z.B. Bebauung oder Bepflanzung

• Verkehrsbeziehungen bzw. Fahrbeziehungen, z.B. Linksabbieger

• Streckencharakteristik, z.B. 2-spuriger Straßenquerschnitt, max. zul. Geschwindig-keit, Tempo 30-Zone

• Ziele, z.B. ein Parkhaus

• Ereignisse, z.B. Straßensperrungen oder Baustellen

• Verkehrsaufkommen

• Vorhandene IRS

• Sonstige organisatorische Rahmenbedingungen (z.B. Parkplatz, Tankstelle, Toilette)

Weiterhin ist auch zu beachten, von welchem Startpunkt die interne simTD-Fahrzeugflotte den Versuch startet. Hier sind die Reisezeiten zum ausgewählten Versuchsteilgebiet und die da-durch entstehenden Kosten gering zu halten.

Die Auflistung dieser Kriterien sollte für jeden Versuchsfall erstellt werden und Teil des Dreh-buchs sein. Die Informationen sollten in einer Datenbank vorliegen, um so als Filter für rele-vante Versuchsstrecken genutzt werden zu können. Dies ermöglicht eine schnelle und effek-tive Auswahl der Versuchsteilgebiete. Die beiden Infrastruktur-Partner (Stadt Frankfurt am Main und Hessisches Landesamt für Straßen- und Verkehrswesen) übernehmen dann mit ihrer fachlichen und geographischen lokalen Kompetenz die genaue Verortung der Ver-suchsfälle, die in den Drehbüchern festgeschrieben wird.


4 Testgelände Das simTD Testgelände wird im Projekt nicht nur für Integrationsarbeiten und Tests in Teilpro-jekt TP3 benötigt, sondern auch zur Laufzeit des Feldversuches für technische und nicht-technische Versuche mit Fahrern und Fahrzeugen zur Verfügung stehen.

Bei der Auswahl des simTD-Testgeländes wurden verschiedene Kandidaten für ein Testge-lände berücksichtigt. Als mögliche Testgelände-Alternativen wurden analysiert:

1. Kaserne Friedberg,

2. Waldparkplatz,

3. ein sogenanntes „Misch-Szenario“ aus Kaserne Friedberg und Waldparkplatz sowie

4. eine Aufteilung der Nutzung des Testgeländes in Abhängigkeit von TP3 und TP4 (je-weils unterschiedliche Zeitpunkte und Nutzungsdauer).

Für eine vergleichende Bewertung verschiedener Testgeländekandidaten wurde in Zusam-menarbeit von TP4-Leitungsteam und Partnern in TP3 ein Kriterienkatalog erstellt. Dieser Kriterienkatalog und der damit verbundene Prozess der Testgeländeauswahl werden in Kap. 4.1 exemplarisch dargestellt.

Eine der wichtigsten Rahmenbedingungen für die Auswahl des Testgeländes war die Identi-fikation der Notwendigkeit eines Standortes für die Versuchsfahrzeuge, Versuchsfahrer und Versuchsleiter, also aller für die Versuchsdurchführung in TP4 notwendiger Komponenten, im weiteren Versuchsflottenstützpunkt genannt. Aus Sicht von TP4 ist dieser Versuchsflot-tenstützpunkt möglichst nah an die Innenstadt zu wählen, um eine kurze und reibungslose Anreise der Versuchsfahrer zu gewährleisten und um die täglichen Anfahrt- und Abfahrtzei-ten der Versuchsfahrzeuge während des Feldversuches zu optimieren.

Das ehemalige US-Kasernengelände in Friedberg wurde schließlich offiziell als simTD Test-gelände ausgewählt. In Kap. 4.2 wird das geschlossene simTD-Testgelände in Friedberg be-schrieben. Die Fotos sollen einen Eindruck für die Örtlichkeit und Ausmaße vermitteln.

4.1 Allgemeine Anforderungen an das Testgelände

Die Auswahl eines geeigneten geschlossenen Testgeländes folgte einem Kriterienkatalog, der in Tabelle 18 dargestellt ist. Diese Tabelle ist nach den Kategorien „Lage / Erreichbar-keit“, „Verfügbarkeit“, „Eignung für simTD Installationen“ und „Infrastruktur“ aufgeteilt. Mit die-sen Kategorien wurde versucht, die Diskussion zum geschlossenen Testgelände aus Sicht von TP4 nach wichtigen Punkten für die Phase der Versuchsdurchführung zu bündeln.

• Kategorie „Lage / Erreichbarkeit“: Diese Kategorie ist für den geplanten Versuchsflottenstützpunkt wichtig. TP4 hat ein großes Interesse daran, die Versuche des Feldversuches möglichst effizient durchzu-führen. Ein Faktor hierbei ist die Entfernung, welche die Versuchsfahrer bei der An- und Abfahrt zum Ausgangspunkt der simTD-Versuche zurücklegen müssen.

• Kategorie „Verfügbarkeit“: Diese Kategorie fasst Anforderungen an die Ausstattung des Testgeländes (z.B. An-forderungen an Fahrbahnmarkierungen).

• Kategorie „Eignung für simTD-Installationen“: Es ist geplant, auf dem geschlossenen Testgelände mindestens eine LSA und min-destens zwei Streckenstationen aufzubauen. Die Infrastruktur des Testgeländes soll-te dies ermöglichen, weswegen diese Anforderungen formal erfasst worden sind.


• Kategorie „Infrastruktur“: Diese Kategorie stellt eine Sammlung für verschiedene infrastrukturelle Anforderun-gen dar. Diese Anforderungen stellen eine Vorstufe zu den Überlegungen zum Ver-suchsflottenstützpunkt (siehe Kap. 10) dar.

Tabelle 18: Bewertung Kriterien geschlossenes Testgelände (aus Sicht von TP4).

Anforderungen von TP4 an das geschlossene Testgelände und Versuchsflottenstützpunkt (Sammlung von Kriterien)

Relevanz für Versuchscenter

(Parkplätze für interne Flotte und

Privatfahrzeuge der Fahrer)

Relevanz für Versuche im geschlossenen Testgelände

Lage / ErreichbarkeitEntfernung zur SIM‐TD Strecke (simTD Versuchsgebiet als Ganzes) 1 2Entfernung zur Versuchszentrale (Drive Center) 1 2Erreichbarkeit mit dem Auto 1 1Erreichbarkeit mit öffentlichen Verkehrsmitteln 1 1VerfügbarkeitKreisfahrt f. 100 Fz und 400 CCUs auf Rollwägen > 300 x 75 m (mit Sichtlinie) 4 1

Länge größer 1 km (WLAN Reichweite) 4 2Strecke f. Hochgeschwindigkeitstests (>100 km/h) 4 4Parallel laufende Straßen 1. offenes Gelände 4 4 2. z.T. verdeckte Strecke 4 2Kreuzungen mit ausreichend langen Zufahrten 1. offenes Gelände 4 1 2. verdeckte Einfahrten 4 3 3. komplexe Topologie 4 2Fahrbahnmarkierungen (zumindest f. nichttechn. Versuche) 4 3Asphaltierte Strecken und befestigte Bereiche (z.B. Parkplätze) 4 1Eignung für simTD InstallationenAmpelanlage (mit einer Kreuzung) 4 3mind. 2 Streckenstationen (Steuergerät für Verkehrszeichenbrücke) 4 3lokale LAN‐/Glasfaserverbindung für Streckenstationen 4 3Netzwerkanbindung an VsZ möglich 1 1InfrastrukturUmzäunung 3 3Stromanschluss vorhanden (was ist mit Not‐Stromaggregat?) 1 1DSL‐Anschluss vorhanden (DSL Nutzung möglich?) 1 3UMTS‐Abdeckung vorhanden (Mobilfunk Empfang allgemein) 2 2Wasseranschluss vorhanden (Toiletten, Waschbecken, Dixie) 1 3Abstellflächen für >150 Fz 1 1Schutzgebäude für Mess‐ & Netzwerktechnik 3 3Büros und Besprechungsräume 2 3Mobile Funkabschattung 4 4Tankstelle in der Nähe 2 2Fahrzeugwerkstatt in der Nähe (Was ist in der Nähe? Und eigentlich pro OEM 4 4Hotels und Kantine/Catering für 150 Personen 4 4

LEGENDE(1) = ganz wichtige Voraussetzung

(2) = wichtig

(3) = muss durch Projektteam installierbar sein (muss nachträglich "baubar" sein)

(4) = optional


Als wichtige Ergebnisse ergeben sich aus Tabelle 18:

• Das ehemalige US-Kasernengelände in Friedberg erfüllt am besten die gelisteten An-forderungen.

• Es wird die Notwendigkeit für den Aufbau eines sog. Versuchsflottenstützpunkts ge-sehen, der als Ausgangs- und Endpunkt für die simTD-Versuche im Versuchsgebiet fungieren soll.

Der Versuchsflottenstützpunkt soll zum einen als Parkplatz für die Fahrzeuge der internen Flotte und zum anderen als Versammlungspunkt und Briefing-Ort für die bis zu 100 Ver-suchsfahrer pro Versuchssitzung dienen. Dieser Stützpunkt soll möglichst nah am Versuchs-gebiet und der Frankfurter Innenstadt liegen und gut über öffentliche Verkehrsmittel zu errei-chen sein. Das Land Hessen hat sich bereit erklärt, dem simTD-Konsortium (wie bei der Su-che nach dem geschlossenen Testgelände) bei der Identifikation und Suche eines geeigne-ten Geländes behilflich zu sein.

Sollte kein geeigneter Versuchsflottenstützpunkt nah an der Frankfurter Innenstadt gefunden werden, wird der Versuchsflottenstützpunkt auf dem geschlossenen Testgelände in Fried-berg aufgebaut. Diese Lösung wäre für die Durchführung des Feldversuches nicht optimal, da alle Versuchsfahrer erst nach Friedberg fahren müssten, um Ihre Fahrzeuge entgegenzu-nehmen, um dann die Drehbücher im Versuchsgebiet in und um Frankfurt/Main abzufahren.

Des Weiteren wurden in AP13 aus den Test- und Versuchsfällen Anforderungen an das Testgelände abgeleitet. Diese Ergebnisse und Anforderungen sind komprimiert in Anhang 3: Anforderungen an Testgelände (abgeleitet aus Test- und Versuchsfällen, AP13), Tabelle 41 dargestellt und wurden für die Zwecke dieses Deliverables angepasst.

4.2 Beschreibung des ausgewählten Testgeländes

Das Testgelände befindet sich auf dem Gelände der ehemaligen US-Kaserne Friedberg (Ray Barracks), ca. 20 km nördlich von Frankfurt am Main. Zwei Kilometer vom momentanen Eingang zum Gelände führt die B3 als Teil des simTD-Versuchsgebietes vorbei. Bis zur Bun-desautobahn A5 sind es acht Kilometer (siehe Abbildung 26).

Abbildung 26: Lage des Testgeländes im Versuchsgebiet.


Ob das komplette Gelände oder nur Teile des Geländes für Tests (TP3) bzw. Versuche (TP4) genutzt werden können, wird im Rahmen von TP3 mit dem Verwalter des Geländes, der BIMA (Bundesanstalt für Immobilienaufgaben), noch vertraglich geregelt. Die Fläche beträgt ca. 80 ha, welche aus begrünten oder betonierten Freiflächen und bebauten Flächen besteht (siehe Abbildung 27).

Abbildung 27: Übersicht der ehemaligen US-Kaserne Friedberg (Quelle: Bundesanstalt für Immobilienaufgaben).

Der Grünbereich im Nordosten verfügt über eine Fläche von ca. 500x300 Metern mit einem Rundkurs aus größtenteils Kiesbelag (siehe Abbildung 28). Dieser Bereich ist v.a. für simTD-Versuche ohne Funkabschattung bei langsamen Geschwindigkeiten geeignet.

Abbildung 28: Freifläche im Nordosten.

Alle übrigen Straßen des Testgeländes sind gepflastert, asphaltiert oder betoniert, wodurch das Befahren mit höheren Geschwindigkeiten möglich ist. Die maximal zulässige Höchstge-schwindigkeit für die unterschiedlichen Strecken muss im Rahmen von TP3 noch festgelegt werden. Ein Rundkurs mit Bebauung als Funkabschattung befindet sich im Zentrum der Ka-serne.


Die lange West-Ost-Gerade erstreckt sich über 1.3 km und könnte zum Teil mit bis zu maxi-mal drei Fahrstreifen markiert werden (siehe Abbildung 29). Sie wird durch mehrere Neben-straßen gekreuzt. In diesen Kreuzungsbereichen sind z.B. Fahrversuche zum Querverkehrs-assistenten möglich, die im öffentlichen Straßenverkehr zu sicherheitskritisch sind.

Abbildung 29: West-Ost-Gerade.

Im Süden des Testgeländes befinden sich größere betonierte Flächen, auf denen zum Teil Hallen stehen. Hier kann ein Parcours mit Markierungen erstellt werden, für den die beste-hende Straßentopologie nicht ausreicht (siehe Abbildung 30).

Abbildung 30: Betonierte Freifläche im Süden.

Die im Zentrum befindlichen neueren Gebäude können als Büros, Besprechungs- und Prä-sentationsräume genutzt werden (siehe Abbildung 31). Von hier aus werden die Tests (TP3) und Versuche (TP4) vor Ort überwacht. Die Gebäude werden mit einer Anbindung an das Internet (Bandbreite wird in TP3 noch diskutiert) und somit an die Versuchszentrale ausge-stattet werden. Auf dem gesamten Gelände ist die UMTS-Abdeckung für Mobilfunkversuche fast vollständig gegeben.


Abbildung 31: Nutzbare Gebäude.


5 Konzeption Simulationslabor Zur Ergänzung der gewonnenen Daten im Feld (Versuchsgebiet und Testgelände) wurden in simTD die Fahrsimulation und die Verkehrssimulation eingeführt. Nachfolgend werden diese beiden Simulationsumgebungen und deren Zusammenspiel im Simulationslabor dargestellt.

5.1 Beschreibung Fahrsimulation

In der Fahrsimulation können Probandenversuche in einem gefahrlosen und gleichzeitig me-thodisch höchst kontrollierbaren Umfeld durchgeführt werden. Der Fahrer und seine Bedien-eingaben in einer Fahrzeugkonsole (Mockup) sind real, das verkehrliche Umfeld, in dem er sich bewegt, wird simuliert. Dies ist vor allem wichtig, wenn in simTD das Validierungsziel der Fahrsicherheit adressiert ist. Überlegungen zu Ethik und Sicherheit führen zu der Frage, ob die Fahrer bewusst Gefahren ausgesetzt werden, die ein bestimmtes Unfallrisiko mit sich bringen. Da dieses Risiko im Feld nicht tragbar ist, führt der direkte Weg zur Fahrsimulation.

Auch methodisch ist man in Feldversuchen Einschränkungen unterlegen:

• Auftretenshäufigkeit von Messszenarien Wie geht man mit Fahraufgaben um, die im Feld nur selten auftreten, die für die Prü-fung der Anwendungsfälle aber sehr relevant sind?

• Kontrollierbarkeit von Umgebungsvariablen Kann sicher gestellt werden, dass eine wissenschaftliche Prüfung ausgestattet vs. nicht ausgestattet stattfinden kann?

Ziele der Fahrsimulatoruntersuchungen in simTD sind deswegen:

• Ermitteln von Fahrverhalten in sicherheitskritischen Fahraufgaben bzw. Grenzsituati-onen der Systeme. Schränkt die Nutzung der simTD Systeme die Sicherheit beim Fah-ren ein?

• Ermitteln von Fahrverhalten bei verschiedenen Penetrationsraten. Haben verschie-dene Penetrationsraten Auswirkung auf die Nutzerakzeptanz der Systeme?

• Ermitteln von typischem Fahrverhalten, das als Eingabe in die Verkehrssimulation im Sinne eines Fahrermodells dienen kann.

Obwohl die Fahrsimulation mit den Aspekten Ethik und Sicherheit unumstößliche Vorteile bietet, sind dennoch Grenzen der Darstellbarkeit in der Fahrsimulation zu beachten.

• Die mechanischen Grenzen des Bewegungssystems schließen die realistische Be-wegungsumsetzung von hochdynamischen Fahraufgaben (z.B. Schleudern, Voll-bremsungen) aus.

• Unterschiedliche Wetterbedingungen sind nur eingeschränkt simulierbar. Bei starkem Regenfall fehlt z.B. der Eindruck des Wassers auf der Windschutzscheibe bei gleich-zeitigem Betrieb des Scheibenwischers auf höchster Stufe.

• Insgesamt ist die Gefahrenwahrnehmung nur eingeschränkt vorhanden. Dies wäre aber eine Voraussetzung für eine Routenänderung aufgrund äußerer Einflüsse (z.B. Wetterbedingungen), die in manchen simTD Anwendungsfällen erwartet würde.

• Fahraufgaben, die mit Navigation zu tun haben, setzen eine geographisch konsisten-te bzw. korrekte Szenerie voraus. Eine vollständige Nachbildung einer realen Strecke wäre in der Fahrsimulation aber nur mit unverhältnismäßigem Aufwand umsetzbar.


• Persönliche Ziele beim Fahren fallen in der Laborsituation weg. Dies betrifft zum Bei-spiel Parkplatzsuche unter Termindruck, Umleitung, Kommunalinformation.

Die hier beschriebenen Einschränkungen führen dazu, dass nicht alle simTD Anwendungsfäl-le in der Fahrsimulation umgesetzt werden.

Die Versuche in der Fahrsimulation kann die Universität Würzburg in Zusammenarbeit mit dem Würzburger Institut für Verkehrswissenschaften (WIVW GmbH) durchführen. Am WIVW werden neben verschiedenen Simulatoren ein PC-Arbeitsplatz, zwei Fahrstände, ein Lenk-prüfstand und ein Fahrsimulator mit Bewegungssystem betrieben. Grundlage bildet die am Institut entwickelte Fahrsimulationssoftware SILAB. Die Verbundenheit zum Interdisziplinä-ren Zentrum für Verkehrswissenschaften (IZVW) an der Universität Würzburg stellt inhaltlich eine langjährige Kompetenz in der Bearbeitung verkehrswissenschaftlicher Fragen zur Ver-fügung.

Der Fahrsimulator mit Bewegungssystem sowie ein Fahrstand und die Pulksimulation (meh-rere Fahrstände, die in der Art verbunden sind, dass bis zu fünf Fahrer sich gleichzeitig in einer Fahraufgabe bewegen können) werden anschließend in den Kap. 5.1.1 bis 5.1.3 ge-nauer dargestellt. Diese Aufstellung stellt zum aktuellen Zeitpunkt lediglich die techni-schen Möglichkeiten dar, die vom WIVW zur Verfügung gestellt werden. Welcher An-wendungsfall in welcher Fahrsimulation zur Prüfung kommt und welche technische Ausstattung gewählt wird, steht momentan noch zur Diskussion. In den Fahrsimulationsversuchen wird das simTD-HMI eingesetzt. Dazu wird der ausgewählte Simulator um ein Touchscreen-Display ergänzt, über das das HMI angezeigt und bedient werden kann. Das Display wird in einer vergleichbaren Position wie in den Realfahrzeugen eingebaut. Dadurch kann das HMI der simTD-Funktionen in einer vergleichbaren Weise wie in den Realfahrzeugen dargestellt und bedient werden.

5.1.1 Fahrsimulator mit Bewegungssystem

Das Bewegungssystem der Würzburger Fahrsimulation besteht aus einer Stewart-Plattform mit 6 Freiheitsgraden. Sechs elektrische Aktuatoren erzeugen die Bewegung, während die 3 passiven pneumatischen Aktuatoren die max. Nutzlast von 4t halten (siehe Abbildung 32).

Abbildung 32: Fahrsimulator mit Bewegungssystem der WIVW GmbH.

Auf eine sphärische Leinwand ist ein 180° frontales, horizontales Sichtfeld projiziert. Für das frontale Sichtfeld werden drei Bildkanäle benötigt, jeder mit einer Auflösung von 1400x1050 Punkten. Als Innenspiegel und zwei Außenspiegel findet man LCD Displays vor. Die Update-Rate des Sichtsystems beträgt 60 Hz.


Als Mockup findet man in der Kabine einen voll instrumentierten BMW 520i, erweitert um:

• Lenkkraftsimulation

• Zwei LCD-Displays für Navigation, Nebenaufgaben, HMI-Untersuchungen usw.

• Bedienelemente für Assistenzsysteme, Nebenaufgaben usw.

• Eye-Tracking System

• E-Gas

• Gurtstraffer

• Physiologische Messwertaufnehmer (z.B. EKG, EEG und Lidschluss)

8 Kanäle (incl. Subwoofer und Shaker) über 6 Lautsprecher im Mockup, 2 außerhalb gene-rieren den Sound des Fahrgeräuschs. Das Rechnernetz besteht aus 14 PCs, verbunden über 100 Mbit Ethernet.

5.1.2 Statischer Fahrsimulator

Der statische Fahrsimulator des WIVW (siehe Abbildung 33) hat ein 300° horizontales Sicht-feld. Generiert wird dieses über 5 Bildkanäle, jeder mit einer Auflösung von 1400x1050 Punkten. Auch hier werden LCD Displays für die Darstellung von Innen- und linkem Außen-spiegel herangezogen. Die Update-Rate beträgt 60 Hz.

Als Mockup findet man im Innenraum eine Fahrerzelle, die einem Fahrzeug der Sprinter-Klasse nachempfunden ist. Es ist erweitert um:

• Lenkkraftsimulation

• Zwei LCD-Displays für Navigation, Nebenaufgaben, HMI-Untersuchungen mit je 1024x768 Punkten

• Modulare, auf CAN-Bus basierende Messtechnik

Für die Soundsimulation wird ein 5.1 Soundsystem (bestehend aus fünf Hochton-Kanälen und einem Subwoofer) verwendet. Die Lautsprecher sind im Mockup angebracht. Das Rech-nernetz besteht aus 11 PCs, verbunden über 100 Mbit Ethernet.

Abbildung 33: Statischer Fahrsimulator der WIVW GmbH.

5.1.3 Pulksimulation

Die Pulksimulation des WIVW besteht aus fünf Fahrstationen, an denen Fahrer sich gemein-sam in einer virtuellen Umwelt bewegen können. An jeder Fahrstation kann je ein Proband


sitzen und sein simuliertes Fahrzeug steuern. Da die Fahrzeuge in einer gemeinsamen virtu-ellen Umwelt unterwegs sind, sehen sie sich in der Simulation gegenseitig und die Fahrer können auf das Verhalten der anderen Versuchsteilnehmer reagieren.

Jede Fahrstation verfügt über ein 150° horizontales Sichtfeld, bestehend aus drei LCD-Displays mit jeweils 22“ Bildschirmgröße und einer Auflösung von 1680x1050 Punkten (siehe Abbildung 34). Die Innen- und Außenspiegel werden in die Frontsicht eingeblendet. Die Up-date-Rate beträgt 60 Hz.

Abbildung 34: Pulksimulation der WIVW GmbH.

Als Mockup wird jeweils ein hochwertiges PC-Spielelenkrad mit Pedalerie verwendet. Es ist erweitert um:

• Lenkkraftsimulation (Force Feedback)

• Ein LCD-Display für Nebenaufgaben und HMI-Untersuchungen mit 800x480 Punkten. Es handelt sich um einen Touchscreen, so dass auch Bedieneingaben darüber mög-lich sind.

Für die Soundsimulation und die Kommunikation mit dem Versuchsleiter wird ein Headset verwendet. Das Rechnernetz besteht aus insgesamt 25 PCs, verbunden über Gigabit-Ethernet.

5.1.4 Fahrsimulationssoftware SILAB

Alle Fahrsimulatoren des WIVW werden mit der Fahrsimulationssoftware SILAB betrieben. In die Entwicklung von SILAB ist die langjährige Erfahrung des WIVW im praktischen Einsatz von Fahrsimulation eingeflossen. Durch anwendungsorientierte Weiterentwicklung ist ein effizientes Werkzeug zu Bearbeitung von Fragestellungen aus den Bereichen Forschung, Entwicklung und Training entstanden. Die wichtigsten Merkmale von SILAB werden nachfol-gend dargestellt.


Realismus Die einzelnen Komponenten, aus denen SILAB besteht, vermitteln dem Fahrer einen realisti-schen Fahreindruck:

• Es wird eine aufwändige Simulation der Fahrzeugdynamik durchgeführt.

• SILAB enthält eine moderne Bildgenerierung für Stadt-, Autobahn- und Landstraßen-szenarios. Abbildung 35 enthält einige Beispiel-Screenshots aus der Fahrsimulati-onssoftware.

• Für die Simulation anderer Fahrzeuge und Fußgänger sind zahlreiche Verhaltens-modelle verfügbar.

• Eine mehrkanalige Geräuschsimulation vervollständigt die Simulationsumgebung.

Abbildung 35: Screenshots aus der Fahrsimulationssoftware SILAB der WIVW GmbH. Hier beispielhaft Stadtsze-nario, Landstraße und Nachtfahrt.

Skalierbarkeit SILAB ist PC-basiert und benötigt keine Spezialhardware. Die kleinste Ausbaustufe eines Fahrsimulators unter SILAB besteht aus einem PC mit Monitor und einem für Computerspie-le üblichen Lenkrad. Diese Minimalkonfiguration lässt sich ohne großen softwareseitigen Aufwand schrittweise bis hin zu einer Simulation mit mehreren Bildkanälen und Bewegungs-system erweitern.

Anwendungsorientiertes Szenariodesign Unter SILAB können Szenarien vom Anwender selbst erstellt werden. Dies beinhaltet die Definition der Streckengeometrie, die Beeinflussung der landschaftlichen Ausgestaltung und die Steuerung anderer Verkehrsteilnehmer. Eine Simulatorfahrt besteht aus einer vom An-wender festgelegten Abfolge von Szenarios. Dabei bietet SILAB Mechanismen, mit denen während der Simulation die Reihenfolge, in der die Szenarien auftreten, an das Verhalten des Versuchsfahrers angepasst werden kann. Dadurch wird eine hohe Dichte und Reprodu-zierbarkeit von Szenarien erreicht.


Erweiterbarkeit Die Architektur von SILAB erlaubt die Einbindung externer Hard- und Software über die Kommunikationsschnittstellen CAN, UDP, TCP/IP in die Simulation. Anwendungsspezifische Erweiterungen von SILAB können auch in C++ erstellt werden. Mehrere APIs bieten detail-lierten Zugriff auf die wichtigsten Komponenten, wie z.B. Datenbasis, Verkehrssimulation und Visualisierung. Mit einem SILAB-Target für den RealTime Workshop können unter MATLAB/SIMULINK entworfene Modelle bequem in SILAB eingebunden werden.

Transparenz Alle Parameter der Simulation sowie alle anfallenden Daten können für eine spätere Analyse aufgezeichnet werden. Dazu gehören u.a. Bedieneingaben des Fahrers, fahrdynamische Größen, Kenngrößen der Straßengeometrie, Informationen über andere Verkehrsteilneh-mern und alle Daten/Parameter anwendungsspezifischer Erweiterungen von SILAB. Mit ei-ner komfortablen grafischen Benutzeroberfläche können während der Simulation Parameter verändert und Daten beobachtet werden (siehe Abbildung 36). Zudem lassen sich alle Pa-rameter automatisch in Abhängigkeit der aktuell befahrenen Strecke festlegen.

Abbildung 36: Mitschau der Daten in der Fahrsimulationssoftware SILAB der WIVW GmbH.

5.1.5 Anwendungsfälle, die in der Fahrsimulation umgesetzt werden

Mittels der erweiterten Versuchsmatrizen (siehe Deliverable D13.2, Anhang 3) wurde in AP13 definiert, welche nicht-technischen Fragestellungen des jeweiligen Anwendungsfalles in welcher Versuchsumgebung überprüft werden können. Grundlage waren Überlegungen zu Vor- und Nachteilen der Fahrsimulation, die den jeweiligen Anwendungsfall betreffen. In Tabelle 19 wird durch ein „X“ veranschaulicht, für welche Anwendungsfälle eine Realisierung in der Fahrsimulation geplant ist.


Tabelle 19: Auflistung der in simTD in der Fahrsimulation geplanten Anwendungsfälle in Abhängigkeit der nicht-technischen Fragestellung.

Fahrsimulation Nicht-technische

Fragestellung Anwendungsfall

Nutzer- akzeptanz

Fahr- effizienz

Verkehrs-effizienz

Fahr-sicherheit

Verkehrs-sicherheit

A_1.2.1.2 Streckenbezogene Anzeige Durchschnittsge-schwindigkeit

X X O X O

A_1.2.1.3 Ortsbezogene An-zeige von Hindernissen X O O X O

A_1.2.1.4 Ortsbezogene Anzei-ge von Straßenwetter X O O O O

A_1.2.2.1 Streckengeometrie im Umfeld der Baustelle X O O X O

A_1.2.2.2 Verkehrslage im Umfeld der Baustelle O O O O O

A_1.2.3.2 Dynamische Routen-planung O O O O O

A_1.3.1.1 Umleitungsempfeh-lung O O O O O

A_1.3.2.1 Optimierung des LSA-gesteuerten Verkehrsflus-ses

O O O O O

A_1.3.3.1 Priorisierung ÖPNV O O O O O

A_1.3.3.2 Priorisierung Einsatz-fahrzeug O O O O O

A_1.3.3.3 Reduzierung von Wartezeiten des Individualver-kehrs

O O O O O

A_2.1.1.2 Warnung vor liegen-gebliebenem Fahrzeug X O O X O

A_2.1.1.4 Baustellenwarnung X O O X O

A_2.1.1.5 Hindernisse auf der Fahrbahn X O O X O

A_2.1.2.1 Warnung vor Stau-ende X O O X O

A_2.1.3.1 Warnung vor Wetter-gefahren X O O X O

A_2.1.4.1 Warnung vor sich näherndem Einsatzfahrzeug X O O X O

A_2.2.1.1 Verkehrszeichenan-zeige im Fahrzeug X X O X O

A_2.2.1.2 Warnung bei Nicht-beachtung von Verkehrszei-chen

X X O X O


Fahrsimulation Nicht-technische


Nutzer- akzeptanz

Fahr- effizienz

Verkehrs-effizienz

Fahr-sicherheit

Verkehrs-sicherheit

A_2.2.2.1 Grüne Welle X X O X O

A_2.2.2.2 Restrotanzeige X X O X O

A_2.2.2.3 Warnung vor Rot-lichtverstoß mit Ausprägungen X O O X O

A_2.2.3.4 Elektronisches Bremslicht X O O X O

A_2.2.4.1 Querverkehrsassis-tent X O O X O

A_3.1.1.7 Internetbasierte Übertragung von Verkehrsda-

ten O O O O O

A_3.1.2.3 Kommunalinformationen O O O O O

A_3.1.2.4 Parksituation O O O O O

5.2 Beschreibung Verkehrssimulation

5.2.1 Allgemein

Im simTD-Feldversuch werden Anwendungsfälle unter anderem hinsichtlich ihrer Wirkungen auf Fahreffizienz sowie Verkehrseffizienz und -sicherheit untersucht. Eine wertvolle Ergän-zung des Feldversuchs stellt im Rahmen dieser Untersuchungen die Verkehrssimulation dar. Sie erlaubt es, anders als es im realen Umfeld der Fall ist, vergleichbare Verkehrszustände und -situationen als Rahmenbedingung für die vergleichende Bewertung verschiedener verkehrlicher Untersuchungen herzustellen. Außerdem können in der Verkehrssimulation auch bei hoher Verkehrsdichte noch große Anteile von Fahrzeugen mit simTD-Funktionsausstattung am Gesamtverkehr (IVS-Ausstattungsraten) definiert werden.

Die Verkehrssimulation ist Bestandteil des simTD-Simulationslabors. Das in Feldversuch und Fahrsimulator ermittelte Fahrverhalten einzelner Fahrzeuge bildet dabei die Grundlage für alle in der Verkehrssimulation durchgeführten Untersuchungen. In der Verkehrssimulation werden der Verkehrsfluss sowie das Fahrverhalten einzelner Fahrer auf einem Streckenab-schnitt oder auch in einem ganzen Straßennetz anhand geeigneter Verkehrs-, Netz- und Fahrverhaltensmodelle nachgebildet.

Im simTD-Simulationslabor kommt die mikroskopische Verkehrsflusssimulation VISSIM zum Einsatz (siehe Abbildung 37). VISSIM wurde von der PTV Planung Transport Verkehr AG in Karlsruhe entwickelt. Mikroskopisch bedeutet hierbei, dass sich viele einzelne Fahrer und Fahrzeuge, jeweils zusammengefasst zu so genannten Fahrer-Fahrzeug-Einheiten, in einem realitätsgetreuen virtuellen Abbild des Versuchsgebietes bewegen. Dabei werden auch die real gemessenen Verkehrszustände im Versuchsgebiet anhand gemessener Verkehrsdaten nachgebildet.


Abbildung 37: 2D- und 3D-Darstellungen von Streckenausschnitten in VISSIM (Quelle: PTV Planung Transport Verkehr AG, 2009).

Den Fahrer-Fahrzeug-Einheiten wird das reale, in Fahrsimulator und Feldversuch ermittelte Fahrverhalten zugewiesen. Dabei wird stets dahingehend unterschieden, ob der jeweils un-tersuchte simTD-Anwendungsfall das Verhalten beeinflusst oder nicht. Liegen keine aussage-kräftigen Informationen über ein geändertes Fahrverhalten mit simTD-Anwendungsfall aus Fahrsimulation oder Feldversuch vor, kann auch keine zuverlässige verkehrliche Wirkungs-analyse für diesen Anwendungsfall mittels Verkehrssimulation durchgeführt werden.

Die Verkehrssimulation liefert zum einen Aussagen über Wirkungen auf den Gesamtverkehr. Typische makroskopische Kenngrößen hierfür sind Verkehrsdichte, Verkehrsstärke, mittlere Geschwindigkeiten oder mittlere Reisezeiten. Außerdem bietet die Verkehrssimulation die Möglichkeit, detaillierte mikroskopische Kenngrößen über das Fahrverhalten des gesamten Fahrzeugkollektivs zur Evaluation von Fahr-/Verkehrseffizienz und Verkehrssicherheit zu ermitteln.

So können gezielt und kontrolliert verschiedene IVS-Ausstattungsraten oder auch IRS-Ausstattungsdichten skaliert werden. Zudem ist es möglich, in verschiedenen Untersuchun-gen unter sonst identischen und ebenfalls kontrollierbaren Rahmenbedingungen Unterschie-de in der verkehrlichen Wirkung zu ermitteln.

5.2.2 Simulationsnetz und Verkehrsnachfrage

Aus statischen geographischen Informationen wird das simTD-Versuchsgebiet für die Ver-kehrssimulation detailliert nachgebildet und dort für die simTD-Untersuchungen verwendet. Ein Ausschnitt des Simulationsnetzes im Bereich des Versuchsgebietes ist in Abbildung 38 dargestellt.

Nicht immer kommt bei der Verkehrssimulation das gesamte Netz des Versuchsgebietes zum Einsatz. Bei streckenbasierten Funktionen (z.B. Stauende- oder der Hinderniswarnung) wird ein für die jeweilige Anwendung geeigneter und interessierender Streckenausschnitt herausgelöst.

Auch die Verkehrsnachfrage wird, soweit sinnvoll, realitätsgetreu in das Simulationsmodell eingespeist. Das heißt, reale Detektordaten werden ausgewertet und in einem angemesse-nen Detaillierungsgrad als Verkehrsfluss in die Simulation eingegeben. Ebenso werden aus den Verkehrsdaten realistische Routen definiert, die von den Fahrzeugen befahren werden. Je nach untersuchtem Anwendungsfall wird das Routenwahlverhalten auch gezielt, auf Grundlage von Befolgungsraten aus dem Feldversuch oder Fahrsimulator, beeinflusst.


Abbildung 38: Generiertes Abbild des simTD – Versuchsgebietes als Netzmodell (Quelle: TUM-VT).

5.2.3 Verkehrstechnische Infrastruktur

Zusätzlich zu den geographischen und topologischen Netzinformationen findet eine Versor-gung des Simulationsnetzes mit verkehrstechnischer Infrastruktur statt. Das schließt folgen-de Einrichtungen ein:

• Lichtsignalanlagen im innerstädtischen Bereich, aber auch auf Bundes- und Land-straßen außerorts Dabei wird auch jeweils die in der Realität verwendete Steuerungslogik nachgebildet.

• Verkehrsbeeinflussungsanlagen Die Streckenbeeinflussungsanlagen mit ihrer jeweiligen Algorithmik zur Beeinflus-sung der Geschwindigkeitswahl der Verkehrsteilnehmer im Autobahnbereich werden in der Simulation ebenfalls nachgebildet. Außerdem werden Netzbeeinflussungsanlagen, die infrastrukturseitige Routing- und Umleitungsempfehlungen enthalten, bei der Routenwahl der Fahrzeuge berücksich-tigt. Auch die Steuerung der Seitenstreifenfreigabe wird nachgebildet.

• Detektoren und Messstellen Im Straßennetz befindliche Detektoren zur Erfassung und Zählung von Fahrzeugen sowie Messungen von Reise- und Verlustzeiten finden sich auch in der Verkehrssi-mulation in der dort notwendigen Detaillierung wieder.

5.2.4 Integration der simTD-Anwendungsfälle

Zur Integration der Anwendungsalgorithmen für die simTD-Anwendungsfälle in die Verkehrs-flusssimulation VISSIM existiert eine spezielle C2X-Applikationsschnittstelle, die die Beein-flussung des Fahrverhaltens einzelner Fahrzeuge ebenso ermöglicht wie die Steuerung von Lichtsignal- und Verkehrsbeeinflussungsanlagen. Zudem ist insbesondere auch die Modellie-rung der C2X-Kommunikation berücksichtigt.

Einzelne simTD-Funktionsalgorithmen (z.B. zur Erkennung eines Stauendes), werden direkt in eine für die Verkehrssimulation angepasste Programmierung überführt und dort integriert.


Es wird eine Automatik bereitgestellt, mit der das im Feldversuch und Fahrsimulator ermittel-te Fahrverhalten eingespeist und auf Basis von stochastischen Verteilungen einzelnen Fahr-zeugen zugewiesen wird.

Es werden nicht alle simTD-Anwendungsfälle in die Verkehrssimulation integriert, da teilweise die Nachbildung bestimmter Anwendungsfälle nicht möglich bzw. wegen zu großen Aufwän-den in Relation zu vermutlich geringen zusätzlichen Erkenntnissen nicht sinnvoll ist. Dies ist z.B. bei der simTD-Funktion 2.1.4 „Einsatzfahrzeugwarnung“ der Fall.

5.2.5 Herstellen der Untersuchungssituationen

Die Untersuchungen in der Verkehrssimulation zielen auf die Ermittlung von verkehrlichen Wirkungen einzelner Anwendungen unter fest definierten Randbedingungen ab. Neben Randbedingungen, wie Verkehrszustand, Übertragungsmedium der C2X-Kommunikation oder IRS-Ausstattungsdichte, betrifft dies anwendungsspezifische Situationen, die gezielt hergestellt werden können. Ein Beispiel hierfür ist ein liegengebliebenes Fahrzeug, das zur Ermittlung von Wirkungen des Anwendungsfalls „Hinderniswarnung“ auf einem Fahrstreifen einer Autobahn zum Stillstand kommt und dort das Hindernis darstellt, vor dem bestimmte Fahrzeuge gewarnt werden.

5.2.6 Fahrerverhalten

Das Fahrerverhalten, das in die Verkehrssimulation eingespeist wird, muss zuvor in Form von Ergebnissen aus Fahrsimulation und / oder Feldversuch vorliegen. Dabei sind immer zwei Gruppen von Fahrern zu berücksichtigen und zu unterscheiden: Diejenigen, die eine für den betrachteten Anwendungsfall relevante Warnung bzw. Information erhalten und diejeni-gen, die diese nicht erhalten, etwa weil sie über keine C2X-Ausstattung verfügen oder weil die entsprechende relevante Nachricht nicht beim gewünschten Empfänger angekommen ist.

Für beide Gruppen werden die Fahrverhaltenskenngrößen (wie u.a. Beschleunigung, Ab-stands- oder Fahrstreifenwechselverhalten) zu plausiblen und aussagefähigen stochasti-schen Verteilungen aggregiert. Für diese Verteilungen existiert in der Verkehrssimulation ein entsprechender Verarbeitungsmechanismus.

5.2.7 Kommunikationsmodellierung

Die C2X-Kommunikation zwischen einzelnen oder mehreren Kommunikationseinheiten – also IVS und IRS – wird in der Verkehrssimulation anhand eines Kommunikationsmodells mit der stochastischen Charakteristik der Übertragung nachgebildet. Dabei wird nicht die Nach-richtenübertragung im einzelnen simuliert, sondern die Empfangswahrscheinlichkeit für eine Nachricht in Abhängigkeit von Parametern wie Entfernung zwischen Sender und Empfänger, verwendetes Kommunikationsmedium, topologische Umgebungseigenschaften und Ausstat-tungsdichte in der Umgebung des Senders ermittelt. Dieser Zusammenhang ist in Abbildung 39 ersichtlich.


Abbildung 39: Wahrscheinlichkeit eines erfolgreichen Nachrichtenempfangs in Abhängigkeit von der Ausstat-tungsdichte und von der Entfernung zwischen Sender und Empfänger (Quelle: Assenmacher, Killat, Schmidt-Eisenlohr & Vortisch, 2008).

5.2.8 Anwendungsfälle, die in der Verkehrssimulation umgesetzt werden

Mittels der Erweiterten Versuchsmatrizen (siehe Deliverable D13.2, Anhang 3) wurde in AP13 untersucht, welche nicht-technischen Fragestellungen des jeweiligen Anwendungsfal-les in welcher Versuchsumgebung überprüft werden können. In Tabelle 20 wird durch ein „X“ veranschaulicht, für welche Anwendungsfälle eine Realisierung in der Verkehrssimulation geplant ist.

Tabelle 20: Auflistung der in simTD in der Verkehrssimulation geplanten Anwendungsfälle in Abhängigkeit der nicht-technischen Fragestellung.

Verkehrssimulation Nicht-technische


Nutzer- akzeptanz

Fahr- effizienz

Verkehrs-effizienz

Fahr-sicherheit

Verkehrs-sicherheit


O X X O X

A_1.2.1.3 Ortsbezogene An-zeige von Hindernissen O O O O O

A_1.2.1.4 Ortsbezogene Anzei-ge von Straßenwetter O O O O O

A_1.2.2.1 Streckengeometrie im Umfeld der Baustelle O O O O O

A_1.2.2.2 Verkehrslage im Umfeld der Baustelle O X X O X

A_1.2.3.2 Dynamische Routen-planung O X X O O

A_1.3.1.1 Umleitungsempfeh-lung O X X O O


Verkehrssimulation Nicht-technische


Nutzer- akzeptanz

Fahr- effizienz

Verkehrs-effizienz

Fahr-sicherheit

Verkehrs-sicherheit


O X X O O

A_1.3.3.1 Priorisierung ÖPNV O X X O O



O X X O O

A_2.1.1.2 Warnung vor liegen-gebliebenem Fahrzeug O X X O X

A_2.1.1.4 Baustellenwarnung O X X O X

A_2.1.1.5 Hindernisse auf der Fahrbahn O X X O X

A_2.1.2.1 Warnung vor Stau-ende O X X O X

A_2.1.3.1 Warnung vor Wetter-gefahren O O O O O

A_2.1.4.1 Warnung vor sich näherndem Einsatzfahrzeug O O O O O

A_2.2.1.1 Verkehrszeichenan-zeige im Fahrzeug O X X O X


O X X O X

A_2.2.2.1 Grüne Welle

O X X O X

A_2.2.2.2 Restrotanzeige O X X O O

A_2.2.2.3 Warnung vor Rot-lichtverstoß mit Ausprägungen O O O O O

A_2.2.3.4 Elektronisches Bremslicht O O O O X

A_2.2.4.1 Querverkehrsassis-tent O O O O O


ten O O O O O

A_3.1.2.3 Kommunalinformationen

O O O O O

A_3.1.2.4 Parksituation O O O O O


5.3 Zusammenspiel der Simulationsumgebungen im Simulationslabor

Für den Anwendungsfall A_2.1.2.1 „Warnung vor dem Stauende“ wird im Folgenden das Konzept für das Simulationslabor exemplarisch vorgestellt. Abbildung 40 verdeutlicht das geplante Zusammenspiel zwischen Versuchsszenario, Prüfung der technischen Funktionali-tät und Wirkungsermittlung unter dem Einfluss unterschiedlicher Randbedingungen im Feld-versuch. Die einzelnen Blöcke werden im Folgenden näher beschrieben.

Für das Versuchsszenario der internen Flotte in TP4 ist beispielsweise geplant, dass die Fahrzeuge zweier Gruppen auf ein Stauende zufahren. Ein Teil der Fahrer erhält eine War-nung, der andere Teil der Fahrer erhält keine Warnung. Dies entspricht der zu untersuchen-den und ggf. herzustellenden Situation. Die Wirkung der Warnung vor dem Stauende soll unter unterschiedlichen Randbedingungen (z.B. für unterschiedliche IVS-Ausstattungsraten) untersucht werden.

Die technische Funktionalität des Anwendungsfalls vorausgesetzt, kann ermittelt werden, inwieweit der Nutzer die Warnung akzeptiert und auf diese reagiert.

Versuchsszenario

Technische Funktionalität

Wirkung auf Nutzer

Wirkungenauf:VerkehrseffizienzVerkehrssicherheitFahreffizienzFahrsicherheit

Randbedingungen

In Relation

SituationÄußere Einflüsse:

Verkehr, Fahrer,

Störungen, Wetter,

…

Abbildung 40: Zusammenspiel zwischen Versuchsszenario, Prüfung der technischen Funktionalität und Wir-kungsermittlung und der Einfluss unterschiedlicher Randbedingungen.

Wenn der Anwendungsfall funktioniert und der Nutzer ggf. auf die rechtzeitige Warnung rea-giert, kann anhand der Fahrzeugdaten der simTD-Fahrzeuge ermittelt werden, inwieweit und ob sich dies z.B. ggf. auf die Fahrsicherheit (Abstandsverhalten, Geschwindigkeitsprofil etc.) des gewarnten Fahrers im Vergleich zum nicht gewarnten Fahrer auswirkt. Obwohl die War-nung vor dem Stauende hauptsächlich die Fahr- und Verkehrssicherheit adressiert, könnte zusätzlich ausgewertet werden, inwieweit womöglich z.B. die Fahreffizienz beeinflusst wird (beispielsweise durch geringere Geschwindigkeiten oder größere Abstände).

Die Ergebnisse der Versuche im Feld unterliegen äußeren Einflüssen (z.B. Wetter, Ver-kehrszustände), die meist nicht planbar sind und das Fahrverhalten stark beeinflussen kön-nen. Diese äußeren Einflüsse gilt es, als weitere Rahmenbedingungen zu protokollieren und bei der Wirkungsermittlung zu beachten.

Um dem übergeordneten Ziel einer Ermittlung vergleichbarer Wirkungen der Anwendungsfäl-le Rechnung zu tragen, sollten möglichst

• unterschiedliche Ausstattungsgrade (IVS und IRS),

• unterschiedliche Kommunikationsmedien

• unterschiedliche Verkehrszustände (Verkehrsstärken und -dichten) und

• unterschiedliche Fahrer (z.B. unterschieden nach Alter, Geschlecht, Fahrweise)


in ähnlichen Situationen verglichen werden können. Dies bedeutet, dass zusätzlich zu den realen Ergebnissen aus dem Feldversuch über das Simulationslabor die Möglichkeit beste-hen sollte, vergleichbare Situationen zu schaffen, in denen ceteris paribus (d.h. unter sonst gleichen Bedingungen) einzelne Stellgrößen bzw. Randbedingungen verändert werden kön-nen, um deren Einfluss auf die gewünschten Ausgangsgrößen vergleichen zu können.

Ergänzende Versuche im Simulationslabor (Fahrsimulation und Verkehrssimulation) ermögli-chen die Betrachtung einzelner Stellgrößen in stärker kontrollierten Situationen.

Jede der simTD-Versuchsumgebungen bietet bestimmte Möglichkeiten der Wirkungsermitt-lung, unterliegt aber auch bestimmten Grenzen. Sind diese bekannt, so ist es möglich, durch einen integrierten Ansatz die jeweils interessierenden Informationen aus der am stärksten geeigneten Versuchsumgebung zu erheben. Abbildung 41 verdeutlicht das geplante Zu-sammenspiel der verschiedenen Versuchsumgebungen und welche Aussagen mit welcher Versuchsumgebung getroffen werden können.

Netz, Messwerte für Kalibrierung

Fahrer-verhalten

Fahrer-VerhaltensModell

Fahrer-verhalten

C2X-Com-verhalten

VersucheC2X

FahrsimulationRealität

VersucheC2X

Netz-charakteristik

Verkehrs-daten

Erweiterte Fahrer-Modellierung

Verkehrssimulation

C2X-ComModell

Erweiterte C2X-Com-Modellierung

Gesamtverkehrsablauf

Szenarien(+ variable

Ausstattungs-raten)

Nutzerakzeptanz, Fahreffizienz, -sicherheit

Nutzerakzeptanz, Fahreffizienz, -sicherheit;

Verkehrseffizienz, -sicherheit

Fahreffizienz,Verkehrseffizienz, -sicherheit

VersucheC2X

(Versuchsgebiet und Testgelände)

Abbildung 41: Zusammenspiel der Versuchsumgebungen.

Für den Anwendungsfall A_2.1.2.1 „Warnung vor dem Stauende“ bedeutet dies z.B.:

Im Feldversuch (Versuchsgebiet und/oder Testgelände): Zu Zeiten, an denen aus historischen Beobachtungen mit regelmäßigen Stauenden gerech-net werden kann (z.B. Freitagnachmittag BAB Ax in Fahrtrichtung Nord), befahren die Ver-suchsfahrer der internen Flotte diese Strecke. Sobald ein Stauende durch ein simTD-Fahrzeug erkannt wird, können die umgebenden Fahrzeuge gewarnt werden und die Wir-kungen hinsichtlich Nutzerakzeptanz und Fahrsicherheit (u.U. auch Verkehrssicherheit und -effizienz) sowie Erkenntnisse über das Kommunikationsverhalten unter realen Bedingungen ermittelt werden. Als externe Randbedingungen müssen zusätzliche Werte erfasst und pro-tokolliert werden, z.B. Anzahl vorhandener Fahrstreifen, Verkehrskenngrößen der umgeben-den Fahrzeuge (Fahrzeuganzahl, -dichte etc.), Witterungsbedingungen (Regen, Nebel, tro-ckene oder nasse Fahrbahn etc.), aber auch besondere Gegebenheiten (z.B. Baustellen oder Unfälle). Nur in Relation zu den zusätzlich erfassten Randbedingungen können die ge-messenen Reaktionen und Wirkungen ausgewertet und interpretiert werden.

Neben der unmittelbaren Wirkungsermittlung können aus diesen Fahrzeugdaten im realen Verkehrsumfeld aber auch Erkenntnisse hinsichtlich des Fahrerverhaltens gewonnen wer-den. Diese können bei Signifikanz in entsprechende Fahrermodelle oder Parameter für die


Verkehrssimulation münden und dort eine erweiterte Fahrermodellierung unter Berücksichti-gung der Unterschiede im Fahrverhalten mit/ohne simTD Anwendungsfall ermöglichen.

Zusätzlich ermöglicht die Auswertung des Kommunikationsverhaltens die Kalibrierung der Kommunikationsmodellierung in der Verkehrssimulation gemäß realer Bedingungen.

in der Fahrsimulation: In der Fahrsimulation können gezielt Stauenden an bestimmten Stellen des Parcours unter definierten verkehrlichen (viel oder wenig umgebender Verkehr etc.) und infrastrukturellen Randbedingungen (z.B. Stauende hinter einer Kurve) erzeugt werden. Das Fahrverhalten der unterschiedlichen Versuchsfahrer mit bzw. ohne Information/Warnung kann für exakt die gleiche Situation erhoben und verglichen werden. Es können so Aussagen über die nicht-technische Wirkweise des Anwendungsfalls hinsichtlich Nutzerakzeptanz und Fahrsicherheit bzw. Fahreffizienz getroffen werden.

Neben der Wirkungsermittlung können aus diesen Fahrerdaten der Fahrsimulation aber auch gezielte Erkenntnisse hinsichtlich des Fahrerverhaltens in identischen Situationen (unter gleichen Randbedingungen) gewonnen werden. Diese können bei Signifikanz in entspre-chende Fahrermodelle oder Parameter für die Verkehrssimulation münden und dort eine erweiterte Fahrermodellierung unter Berücksichtigung der Unterschiede im Fahrverhalten mit/ohne simTD Anwendungsfall ermöglichen.

in der Verkehrssimulation: In der Verkehrssimulation können gezielt Stauenden an bestimmten Stellen des Strecken-netzes unter definierten verkehrlichen (viel oder wenig umgebender Verkehr etc.) und infra-strukturellen Randbedingungen (z.B. Stauende hinter einer Kurve) erzeugt werden. Das in der Realität und Fahrsimulation ermittelte Fahrverhalten der Fahrer mit bzw. ohne Informati-on/Warnung wird modelliert, also in Algorithmen, Parameter und Regeln gefasst, die die Ver-kehrssimulation verarbeiten kann. Die unterschiedlichen Fahrermodelle dienen als Ein-gangsgrößen für die Verkehrssimulation. Durch Variation des Kommunikationsmediums, dessen Charakteristika (z.B. Latenzzeiten, Reichweiten) ebenso gemäß Beobachtungen aus der Realität modelliert werden, können Aussagen z.B. über die Wirkungsweise auf den ge-samten Verkehr u.a. in Relation zum Ausstattungsgrad ermittelt werden.

In Abbildung 42 ist der Datenfluss zwischen Fahrsimulation, Feldversuch und Verkehrssimu-lation im Rahmen einer vollständigen iterativen Simulationsstudie veranschaulicht. Damit der dargestellte Ablauf sichergestellt werden kann, müssen entsprechende Datenformate im Zuge der Konzeption von Modellierung und Modellkalibrierung bekannt sein. Die Datenver-sorgung aus der Fahrsimulation muss vor Beginn der Verkehrssimulations-Vorstudien erfolgt sein. Die relevanten Feldversuchs-Ergebnisse werden während der Versuchslaufzeit in das Modell eingespeist.

Um die Funktionen in die verschiedenen Simulationsumgebungen integrieren zu können, müssen außerdem die dafür notwendigen Funktionsalgorithmen und die zu versorgenden Parameter rechtzeitig vor Beginn der Integrationsarbeiten den entsprechenden Simulations-verantwortlichen vorliegen.

Im Anschluss an die Simulationsstudien und in Abstimmung mit den Aus- und Bewertungs-aktivitäten des Feldversuchs werden die Ergebnisse aus der Verkehrssimulation analysiert und aus verkehrlicher Sicht ausgewertet.


Abbildung 42: Datenfluss im Rahmen einer Verkehrssimulations-Studie.


6 Versuchsflotten: Übersicht Im Folgenden wird ein Überblick über die verschiedenen in simTD eingesetzten Flotten gege-ben. Kap. 7 geht schließlich detaillierter auf die interne Flotte ein, Kap. 8 fasst die aktuellen Erkenntnisse zu der geplanten externen Flotte zusammen.

Als kurze Übersicht über die in TP4 eingesetzten Flotten ergibt sich:

• OEM-Testflotte: Versuchsträger der in simTD beteiligten Automobilhersteller

• Interne Flotte: 100 Pkw (angemietet durch gemeinsam finanzierten Unterauftrag in AP42) und 3 Motorräder

• Externe Flotte: 300 freiwillig zur Verfügung gestellte Fahrzeuge von potenziellen Partnern innerhalb oder außerhalb des simTD-Konsortiums

Abbildung 43 verdeutlicht grafisch die Zusammensetzung der verschiedenen Flottentypen.

Abbildung 43: Übersicht über Versuchsflotten in simTD.

6.1 OEM-Testflotte

Die OEM-Testflotte setzt sich aus 28 Fahrzeugen der an simTD beteiligten deutschen Auto-mobilhersteller und zwei Motorrädern zusammen. Bei den Fahrzeugen und Motorrädern handelt es sich um klassische Versuchsträger der Automobilhersteller, in denen zusätzlich die simTD-Hardware verbaut wird. Die OEM-Testflotte berücksichtigt somit nur Fahrzeuge der Marken Opel, Audi, BMW, Ford, Mercedes-Benz und Volkswagen.


6.2 Interne Flotte

Die interne Flotte besteht aus 100 Fahrzeugen (PKW) plus 3 Motorräder der Fahrzeugher-steller, welche auch im Projekt simTD vertreten sind. Hierbei werden die Fahrzeuge vom Kon-sortium extern über ein Mietwagenmodell für die Laufzeit des Feldversuches (7 Monate) an-gemietet und mit der simTD-Hardware ausgestattet. Im Gegensatz zu den Pkw werden die 3 Motorräder durch den Partner BMW AG zur Verfügung gestellt und entsprechend mit der simTD-Hardware ausgestattet. Die spezielle simTD-Hardware wird von AP31 derart in die Fahrzeuge eingebaut, so dass eine vollständige Rückbaufähigkeit ermöglicht wird. In AP42 werden die eingesetzten Versuchsfahrer die Fahrzeuge während des Feldversuches nach vorher in AP41 festgelegten Drehbüchern fahren und Daten sammeln, welche von AP43 ausgewertet und von TP5 bewertet werden.

Es wird angenommen, dass die Fahrzeugklasse entscheidend das Fahrverhalten der Fahrer und somit die Interpretierbarkeit und Generalisierbarkeit der Ergebnisse beeinflussen kann:

• Auf der einen Seite beeinflusst die Fahrzeugauswahl für die interne Flotte die Ver-gleichbarkeit der Ergebnisse untereinander. So ist es denkbar, dass die Reaktionen der Fahrer auf die simTD-Anwendungsfälle von der Fahrzeugklasse abhängen, was eine weitere Variation in den Versuchsfällen darstellen würde. Diese zusätzliche Va-riation hätte zur Folge, dass die verfügbare Anzahl an Fahrzeugen einer Klasse redu-ziert wäre, wodurch die jeweilige Stichprobe kleiner würde. Zusätzlich jedoch beeinflusst die Fahrzeugauswahl auch die Vergleichbarkeit der Er-gebnisse von interner und externer Flotte: Je unterschiedlicher die Fahrzeuge in den Flotten sind, desto unterschiedlicher wird das Fahrverhalten der Fahrer sein. Dies schränkt die Vergleichbarkeit der Ergebnisse ein: So ist beispielsweise ein Vergleich von Kleinwagen mit Fahrzeugen der Oberklasse problematisch, da sich die Fahrzeu-ge in wesentlichen Faktoren unterscheiden (z.B. Beschleunigungsverhalten, Brems-verhalten, Abstandsverhalten):

• Auf der anderen Seite sollten hinsichtlich einer optimalen Generalisierbarkeit der Er-gebnisse die Fahrzeuge aus unterschiedlichen Fahrzeugklassen stammen. Je ähnli-cher die Fahrzeuge sind, desto eingeschränkter ist die Generalisierbarkeit: So ist bei-spielsweise die Verallgemeinerung von Untersuchungsergebnissen einer Studie aus-schließlich mit Mittelklassewagen auf die Gesamtmenge aller Fahrzeugklassen (z.B. Transporter, LKWs, Kleinwagen) zu diskutieren.

Die Konzentration auf wenige Fahrzeugmodelle ist, neben der Vergleichbarkeit, mit weiteren Vorteilen hinsichtlich Aufwand und Kosten verbunden: So ist die Verwaltung der Fahrzeug-flotte vereinfacht. Zudem gibt es bei verringerter Modellvielfalt nur eine begrenzte Anzahl an Einweisungen und Trainings (z.B. zu Fahrzeughandling, manuelle bzw. automatische Gang-schaltung). Weiterhin wäre auch die Versuchsdurchführung, beispielsweise durch die verein-fachte Bereitstellung von Ersatzfahrzeugen, kosteneffizienter organisierbar. Von der techni-schen Seite her ist bei geringer Modellvielfalt ein geringerer Integrationsaufwand zu erwarten (z.B. VAPI, Abstandssensoren).

Zu nennen sind weiterhin psychologische Faktoren, die innerhalb der Gruppe der Versuchs-fahrer aufkommen können: Fahrzeuge unterschiedlicher Fahrzeugklassen könnten unter den Fahrern „sozialen Neid“ aufkommen lassen, was sich auf die Motivation auswirken und die Validität der Ergebnisse gefährden kann.

Aus den o.g. Gründen sollte die interne Flotte daher idealerweise nur aus einer Fahrzeug-klasse mit einem Fahrzeugtyp bzw. Fahrzeugmodell von einem Hersteller bestehen. Dieser Idealfall ist aber aufgrund der Konstellation des simTD-Projektes mit verschiedenen Partner-firmen nicht realisierbar. Trotzdem sollte eine möglichst geringe Anzahl an verschiedenen Fahrzeugmodellen zum Einsatz kommen, um die o.g. Bedingungen zu erfüllen. Der Ver-gleichbarkeit wegen sollten die Fahrzeuge zumindest aus einem Fahrzeugsegment stam-


men. Unter diesen Voraussetzungen kommen nur Fahrzeuge aus der Kompaktklasse oder der Mittelklasse in Frage, da nur in diesen Segmenten alle am Projekt beteiligten Fahrzeug-hersteller vertreten sind. Es wurden folgende Fahrzeugtypen festgelegt:

• Audi A4

• BMW X1

• Ford Mondeo

• Mercedes C-Klasse

• Opel Insignia

• VW Passat

Hinsichtlich des Fahrzeugsegments ist der Einsatz kleinerer Fahrzeuge von Vorteil, um Miet- und Betriebskosten zu sparen. Bezüglich ökologischer Aspekte ist dieses Fahrzeugsegment aufgrund des geringeren CO2-Ausstoßes ebenfalls zu empfehlen.

6.3 Externe Flotte

Bei der externen Flotte handelt es sich der Planung nach um 300 Fahrzeuge, die von Part-nern außerhalb oder innerhalb des simTD-Konsortiums für die Sammlung von Daten zur Ver-fügung gestellt werden. Die entsprechenden Partner erklären sich bereit, ihre Fahrzeuge unentgeltlich für diesen Zweck zur Verfügung zu stellen und akzeptieren die für die Ein- und Ausbauten notwendigen Fehlzeiten ihrer Flotten.

Bis auf die LIDAR-Sensoren wird in die Fahrzeuge der externen Flotte eine identische simTD-Hardware verbaut werden. Hierbei gilt, wie bei der internen Flotte, der oberste Grundsatz der vollständigen Rückbaufähigkeit sämtlicher Einbauten.

Im Gegensatz zu der internen Flotte muss an dieser Stelle jedoch die Tatsache hervorgeho-ben werden, dass die Beeinträchtigung der Fahrer – schließlich sollen diese ungestört ihrer „normalen“ täglichen Arbeit nachgehen – bei der externen Flotte auf ein Minimum zu reduzie-ren ist. Hier gilt es; strengere Maßstäbe hinsichtlich möglicher Beeinträchtigungen der Fahrer anzusetzen als für Fahrer der internen Flotte, da letztere für ihre Teilnahme an den Fahrver-suchen finanziell entschädigt werden.

Zu einer möglichen Zusammensetzung der externen Flotte und zu Fragestellungen, wie man die Partner, welche Fahrzeuge für die externe Flotte zur Verfügung stellen, entlohnen könn-te, gibt Kap. 8 einen ersten Überblick.

6.4 Verfügbarkeit der Flotten im Versuchsbetrieb

Abbildung 44 ordnet die o.g. Flotten in simTD den verschiedenen Versuchsphasen, wie Pilot-tests, Optimieruns-/Pilotversuche, Vorversuche und Feldversuch zu. Die Abbildung verdeut-licht die Zeiträume, die dem Projekt gemäß Zeitplan (Stand: März 2010) für die verschiede-nen Phasen zur Verfügung stehen und listet grafisch die jeweils zur Verfügung stehenden Fahrzeuge auf. Einen detaillierteren Überblick zu den einzelnen Phasen liefert Kap. 13.


Abbildung 44. Zuordnung der simTD Flotten zu verschiedenen Phasen (Zeitplanung: Stand März 2010).

Pilottests

Diese Tests sind dazu gedacht, das Gesamtsystem zu prüfen und die Leistungsfähigkeit der Systeme hinsichtlich des Meilensteines MS6 „Gesamtsystem funktioniert im Testgelände“ (01.05.2011) zu demonstrieren. Für die Phase der Pilottests stehen insgesamt 30 Versuchs-träger der OEM-Testflotte zur Verfügung (28 PKW, 2 Motorräder). Als Fahrer dieser OEM-Fahrzeuge stehen nur spezielle Versuchsfahrer und Mitarbeiter der beteiligten Firmen zur Verfügung.

Optimierungs-/Pilotversuche

Diese Phase erlaubt es den OEM, den Herstellern der IVS (VAU und CCU) sowie den Part-nern in TP3 entweder auf dem geschlossenen Testgelände oder bei den Partnern vor Ort Optimierungen an den Systemen durchzuführen.

Weiterhin hätte TP4 bei Bedarf und bei entsprechender Verfügbarkeit der Fahrzeuge und Fahrer die Möglichkeit, bereits vor den Vorversuchen die „Fahrbarkeit“ und Durchführbarkeit von ausgewählten Szenarien oder Drehbüchern mit Fahrzeugen im Versuchsgebiet zu über-prüfen.

Vorversuche

Diese Phase lässt sich am treffendsten als „Generalprobe“ bezeichnen. An dieser Stelle sei erwähnt, dass für diese Phase zum einen die 30 Versuchsträger der OEM-Testflotte (28 PKW, 2 Motorräder) für die Vorversuche zur Verfügung stehen, zum anderen 20 Fahrzeuge der internen Flotte bereit stehen, um den Versuchsplan intensiver zu testen und evtl. Schwachstellen für den Feldversuch aufzudecken.

Für diese Phase stehen 20 Fahrer sowie 20 voll ausgestattete simTD-Versuchsfahrzeuge zur Verfügung. Mit diesen Fahrzeugen sollen die Fahrer einen Großteil der Drehbücher im Ver-


suchsgebiet und auf dem geschlossenen Testgelände fahren und überprüfen. Parallel erfolgt eine stete Optimierung der Drehbücher und der Versuchsdatenbank, um die Erfahrungen aus den Vorversuchen möglichst optimal für den großen Feldversuch zu nutzen.

Feldversuch

Im Feldversuch steht dann die komplette Anzahl von 100 voll ausgestatteten Versuchsfahr-zeugen der internen Flotte zur Verfügung. Diese Versuchsfahrzeuge werden von Versuchs-fahrern genutzt, die speziell für die Versuchsdurchführung akquiriert werden (siehe Kap. 7.1.2). Die 3 Motorräder der internen Flotte werden im Feldversuch durch speziell geschulte Motorradfahrer bewegt, welche bei der BMW AG in München ein spezielles Fahrertraining absolviert haben.

Zur Laufzeit des Feldversuches werden zusätzlich Fahrzeuge der externen Flotte das Ver-suchsgebiet durchfahren und Daten sammeln. Die Fahrer dieser Fahrzeuge werden darüber hinaus regelmäßig ihre Rückmeldungen (z.B. bezüglich der Nutzerakzeptanz) an das Kon-sortium übermitteln.

Schließlich fahren die 30 Versuchsträger der OEM-Testflotte (28 PKW, 2 Motorräder) zusätz-lich zur internen und externen Flotte auf dem Versuchsgebiet und dem geschlossenen Test-gelände. Dabei ist von der Versuchsleitung sicherzustellen, dass diese Fahrzeuge das regu-läre Versuchsgeschehen nicht stören oder nachteilig beeinflussen. In den Drehbüchern wird z.B. jeweils vermerkt, ob OEM-Fahrzeuge im Umkreis des jeweiligen Versuchs fahren dür-fen, ohne dass die Versuchsdurchführung gestört wird.


7 Interne Flotte In diesem Kapitel werden die Zielsetzung sowie die Anforderungen an die interne Flotte (sie-he Kap. 7.1 bzw. 7.3) beschrieben, die sowohl im Versuchsgebiet als auch auf dem Testge-lände eingesetzt wird. Es wird zudem, basierend auf Deliverable D13.2, in Kap. 7.2 gezeigt, welche Anwendungsfälle mit der internen Flotte auf dem Testgelände oder im Versuchsge-biet in simTD realisiert werden sollen. Abschließend werden in Kap. 7.4 die Anforderungen der Datenauswertung an die interne Flotte dargestellt.

7.1 Zielsetzung der internen Flotte

7.1.1 Fahrzeugflotte

Die interne Flotte wird die Hauptlast der in simTD gefahrenen nicht-technischen Versuche tragen. Im Kontrollgruppenvergleich werden die Fahrszenen, die zur Prüfung der Anwen-dungsfälle führen, angefahren. Über sog. Drehbücher wird, soweit es die realen Gegeben-heiten zulassen, ein Mindestmaß an Kontrollierbarkeit bzw. Vergleichbarkeit der Rahmenbe-dingungen geschaffen. Dort werden u.a. Start- und Zielpunkte für die einzelnen Fahrergrup-pen festgelegt.

Es handelt sich um kontrollierte Versuchsfahrzeuge, die von angestellten Versuchsfahrern bewegt werden. Die Fahrten der internen Flotte werden nicht dem Zufall überlassen, sondern nach einem experimentellen Plan (Drehbuch) durchgeführt. Die interne Flotte wird sowohl im Versuchsgebiet als auch auf dem Testgelände eingesetzt.

7.1.2 Fahrerkonzepte

Für die Rekrutierung der Fahrer sind momentan zwei Konzepte in der Diskussion:

• Das Konzept der festangestellten Fahrer oder

• alternativ ein Versuchsfahrer-Panel-Konzept (Datenbankkonzept).

Im weiteren Projektverlauf werden die Möglichkeiten und Grenzen dieser beiden Kon-zepte diskutiert, um vor Beginn des Feldversuchs sicherzustellen, dass ein stimmiges und effizientes Konzept gewählt wird, das den inzwischen detaillierter vorliegenden Vorstellungen an die Ausgestaltung des Feldversuchs angepasst ist. Im Folgenden werden die beiden Konzepte kurz vorgestellt und diskutiert.

7.1.2.1 Fest angestellte Fahrer Die simTD-Vorhabensbeschreibung legt folgende Überlegungen zugrunde:

Da zur Erzeugung von komplexeren Szenarien vor allem im Stadtbereich eine teilweise se-kundengenaue Konfiguration erzeugt werden muss, ergeben sich sowohl technische wie organisatorische Herausforderungen. Diese können gelöst werden, wenn zentrale und de-zentrale Steuerung miteinander kombiniert werden.

Unter dezentraler Steuerung wird verstanden, dass die Versuchsfahrer in eine Gruppe von Experten aufgeteilt werden, die als „Schauspieler“ lokal und unter Eigenregie zusammenwir-ken, um ein bestimmtes Szenario zu erzeugen. Diese sog. Expertenfahrer sind voll in die Versuchsaufgabe eingeweiht, haben diese trainiert und haben auch die Möglichkeit, unterei-nander zu kommunizieren.


Zur Erzeugung der Verkehrslage und der Grundlasten dient die Steuerung der Versuchsflotte von der Versuchszentrale aus. Dieser Teil der Versuchsfahrer dient als „Chor“, der von we-niger gut ausgebildeten, teilweise nicht einmal speziell instruierten Personen dargestellt wer-den kann. Prinzipiell können diese Fahrer bezogen auf das jeweilige Untersuchungsziel so-gar „naiv“ gelassen werden. Dadurch eröffnet sich die Möglichkeit, das Verhalten dieser Gruppe zur Abschätzung der Effizienz, Sicherheit und Akzeptanz der Systemleistung in den einzelnen Szenarien verwenden zu können.

Der wesentliche Unterschied zu einer völlig zentralen Versuchssteuerung liegt darin, dass die lokale Intelligenz der „Schauspieler“ genutzt wird, um das Szenario zu erzeugen. Es setzt voraus, dass diese Gruppe intensiv trainiert wird, wobei dieses Training dem eigentlichen Versuchsbeginn in TP4 vorgeschaltet werden kann und nicht zwingend eine vollständige Fahrzeugausrüstung benötigt. Da dennoch der stochastische Anteil an einem Szenario sehr hoch ist, muss dafür gesorgt werden, dass diese mehrfach durchfahren werden.

Abbildung 45: simTD-Versuchsfahrer der internen Flotte (Quelle: simTD-Vorhabensbeschreibung, 2009).

Abbildung 45 zeigt die nach ersten Überlegungen in der simTD-Vorhabensbeschreibung be-nötigte Anzahl von 500 kontrollierten Fahrern (sog. Hired Driver). Diese Zahl ergibt sich aus der Anzahl der Expertenfahrer plus die Anzahl der naiven Fahrer mit einer Laufzeit von 6 Monaten. Es wird von 20 Expertenfahrern über die gesamte Projektlaufzeit und 80 naiven Fahrern pro Monat ausgegangen. Letztere werden auf monatlicher Basis ausgetauscht und von den Expertenfahrern für die vorgesehenen Aufgaben trainiert. Die Expertenfahrer blei-ben den gesamten Zeitraum der simTD Versuche in TP4 fest angestellt.

Die kontrollierten Fahrzeuge werden in Pulks zu je 20 Fahrzeugen aufgeteilt. Jeder Pulk von Fahrzeugen wird von einigen Expertenfahrern und zum größten Teil von naiven Fahrern be-wegt. Jeder dieser Gruppen von Fahrzeugen und Fahrern steht jeweils ein Gruppenleiter vor, der an AP42 berichtet und tatkräftig bei der Einteilung und Verwaltung der Fahrer, Zuteilung der Fahraufgaben und Versuche und bei der Problembewältigung hilft.

Abbildung 46 verdeutlicht die Verteilung der verschiedenen Teile der simTD-Versuchsflotte zur Laufzeit der Versuchsdurchführung laut simTD-Vorhabensbeschreibung. Die 20 Fahrzeu-ge für die Expertenfahrer werden die gesamte Dauer von 7 Monaten über benötigt. Für Schulungszwecke der Expertenfahrer ist es notwendig, dass diese 20 Fahrzeuge vor dem Beginn der Versuchsdurchführung entsprechend ausgerüstet sind und zur Verfügung stehen. Die 80 Fahrzeuge der naiven Fahrer werden laut simTD-Vorhabensbeschreibung etwas zeit-verzögert eingesetzt, um so die Erkenntnisse der 20 Fahrzeuge in der vorangegangenen Phase umsetzen zu können. Im 6. Monat ist eine Wartungspause für die Fahrzeuge vorge-sehen. Diese Pause gestattet eine Nachjustierung der Versuche und evtl. eine Neueinteilung der naiven Fahrer.

Kontrollierte FahrerInsgesamt 500

20 480Naive Fahrer („Chor“)z.B. Studenten

ExpertenFahrer(„Schauspieler“)


125 8

Anzahl Fahrzeuge

150

250

200

100

50

300

350

400

450

500

TP3 TP4

Free Flow (300)

Externe Flotte (grün)mit min. 300 Fahrern100 Fzge. FFM200 Fzge. tbd

Interne Flotte (gelb)mit 100 Fahrzeugen & Kontrollierten Fahrern

20 Experten Fahrer

80 „naive“FahrerKontrolliert (80+20)

Abbildung 46: Verteilung der simTD-Versuchsflotte (Quelle: Vorhabensbeschreibung, 2009).

Dieses Konzept birgt methodisch betrachtet jedoch auch einige grundlegende Schwierigkei-ten, die weiterhin zu diskutieren sind:

• Vorversuche des IZVW zum Pulkfahren zeigen, dass bereits das Fahren in einer Gruppe von drei Fahrern als deutlich anstrengender bewertet wird als eine Alleinfahrt. Zudem treten im Kolonnenfahren häufiger sicherheitskritische Ereignisse auf, die da-rauf zurück zuführen sind, dass ein Fahrer z.B. die Kolonne zusammen halten möch-te (Mühlbacher, Messerschmidt, Totzke & Krüger, 2010). Anforderungen an Exper-tenfahrer, wie in der simTD-Vorhabensbeschreibung beschrieben, übersteigen somit stark die üblichen Anforderungen bei der Fahrzeugführung (durch Beobachtung, Kon-trolle und Kommunikation mit den anderen Fahrern im fließenden Verkehr). Aus Sicherheitsgründen ist es daher nicht verantwortbar, dass ein Fahrer einen Pulk von 10 Fahrern „führt“, eine Fahrszene selbst herbei führen soll und/oder zusätzliche mit den anderen Expertenfahrern während der Fahrt kommuniziert. Selbst mit gut trai-niertem Personal muss das sichere Führen des eigenen Fahrzeugs erste Priorität haben. Daher wäre eine solche Rollenaufteilung nicht zu halten.

• Fest anstellbar sind in der Regel Personen, die gerade arbeitssuchend gemeldet sind, Studenten oder Rentner. Andere Personenkreise müssten sich, um an der Stu-die teilzunehmen, für 1-6 Monate oder mehr beurlauben lassen. Gerade mitten im Berufsleben stehende Personen und Vielfahrer – die Zielgruppe der simTD Technolo-gie – wären so nicht erreichbar, da sie wohl kaum so lange aus ihrem Beruf ausstei-gen können. Dies schränkt den infrage kommenden Personenkreis derart ein, dass ein repräsentativer Fahrerquerschnitt nicht mehr erreichbar wäre. Aus den Versuchs-fallvarianten ergibt sich zum momentanen Zeitpunkt die Einteilung der Fahrer in fol-gende Gruppen:

o Berufs- vs. Viel- vs. Wenig-Fahrer

o Ortskundigen vs. ortsunkundigen Fahrern

o Fahrer von klein-, mittel- und höher klassigen Fahrzeugen

• Darüber hinaus sind Verschiebungen im Erhebungszeitraum mit diesem Fahrerkon-zept kaum aufzufangen. Falls es überhaupt möglich ist, Personen zu gewinnen, die über einen derart langen Zeitraum dauerhaft verfügbar sind, ist nur schwer denkbar, dass diese Zeit u.U. kurzfristig verschiebbar oder gar zu verlängern wäre.

• Außerdem müsste geklärt werden, wie mit Nacht- und Wochenendarbeit umgegan-gen wird, da sicher davon auszugehen ist, dass manche Versuche in diesen Zeiträu-men stattfinden.


7.1.2.2 Versuchsfahrer-Panel-Konzept (Datenbankkonzept) Beschränkt man sich auf eine zentrale Versuchssteuerung kommt weiterhin ein Versuchs-fahrer-Panel-Konzept (Datenbankkonzept) in Frage. In einer Datenbank sind Personen na-mentlich hinterlegt, die im Untersuchungszeitraum zumindest zeitweise verfügbar sind und Interesse an einer Versuchsteilnahme haben. Für den Versuchszeitraum müssten Personen angeworben werden, die unterschiedliche Eigenschaften aufweisen. Enthalten sein sollten Fahrer unterschiedlichen Alters und Geschlechts, eine große Bandbreite an Fahrerfahrung, ortskundige vs. ortsunkundige und Fahren von klein-, mittel- und höher klassigen Fahrzeu-gen. In der Beschreibung der Versuchsfallvarianten findet man Hinweise auf mögliche Fah-rergruppierungen, die zur statistischen Auswertung der Ergebnisse relevant werden können.

Fahrer könnten über Anzeigen in den Frankfurter Medien angeworben werden. Über einen demographischen Bogen werden die Probanden in eine Datenbank aufgenommen. Diese Datenbank kann dann auch zur Verwaltung der Fahrer herangezogen werden. Idealerweise ist dieser Datenbank auch die Verfügbarkeit der Personen zu entnehmen. Im Bedarfsfall wird der Fahrer zu einem bestimmten Versuchsfall eingeladen. Er müsste sich allenfalls für einen Tag frei nehmen.

Als Vorteile eines solchen Datenbankkonzepts wären zu nennen:

• Ausfälle aufgrund Krankheit, Urlaub etc. können besser und flexibler ausgeglichen werden. Aber auch Verschiebungen im Erhebungszeitraum bzw. technische Ausfälle hätten keine so große Auswirkung auf die Verfügbarkeit der Fahrer, da die Fahrer nicht für einen bestimmten Zeitraum zur Verfügung stehen müssen, sondern nur bei Bedarf für einzelne Termine eingeladen werden.

• Der notwenige Trainingsaufwand pro Fahrer reduziert sich auf ein Minimum, da er nach einer grundsätzlichen Einführung nur noch auf den jeweiligen Versuchstag vor-bereitet werden muss.

• Da die notwendige Lohnabrechnung sowie Sozialabgaben etc., die bei einer Festan-stellung notwendig sind, entfallen können an dieser Stelle erhebliche Kosten gespart werden, da die Fahrer nur dann eine Aufwandsentschädigung erhalten, wenn sie auch tatsächlich gefahren sind.

• Wie bereits angesprochen, muss in diesem Konzept die Versuchssteuerung zentral erfolgen, da keiner der Fahrer in die Einzelheiten eines Versuchs eingeweiht ist. Die Gefahren einer Überforderung des Fahrers reduzieren sich jedoch auf ein Minimum.

Als Nachteil bleibt festzuhalten:

• Durch dieses Konzept wird eine höhere Anzahl der in die Datenbank aufzunehmen-den Personen sowie ein höherer organisatorischer Aufwand notwendig. Hier sind Zahlen von min. 500 bis max. 1000 Personen zu diskutieren, damit im Bedarfsfall auch tatsächlich 100 Fahrer mit den gewünschten Eigenschaften gleichzeitig anwe-send sein können. Alle Fahrer müssen zu einer allgemeinen organisatorischen und fahrerischen Einweisung zu einem Termin vor Ort sein.

Mit hoher Wahrscheinlichkeit gleichen sich die Einsparungen aus Lohnverwaltung und –kosten mit dem Mehraufwand an Organisation aus. Dies ist noch zu prüfen.


7.2 Umsetzung von Anwendungs- und Versuchsfällen

7.2.1 Nicht-technische Versuchsfälle in der internen Flotte

Im Rahmen von AP13 wurde untersucht, welche nicht-technischen Fragestellungen des je-weiligen Anwendungsfalles in welcher Versuchsumgebung überprüft werden können. Tabelle 21 gibt einen Überblick, für welche Anwendungsfälle die Realisierung gemäß den Erweiter-ten Versuchsmatrizen (siehe Kap. 2.1.1.3 und Deliverable D13.2, Anhang 3) mit der internen Flotte im Versuchsgebiet und auf dem Testgelände geplant ist (dargestellt mit "X"). Zusam-menfassend wird deutlich, dass mit der internen Flotte viele Anwendungsfälle im Versuchs-gebiet und auf dem Testgelände bzgl. unterschiedlicher nicht-technischer Fragestellungen untersucht werden. Für detailliertere Informationen siehe Deliverable D13.2. Tabelle 21: Auflistung der in simTD mit der internen Flotte geplanten Anwendungsfälle (veranschaulicht durch ein „X“) in Abhängigkeit der nicht-technischen Fragestellung und Versuchsumgebung. Abkürzungen: „N“ Nutzerak-zeptanz, „FE“ Fahreffizienz, „VE“ Verkehrseffizienz, „FS“ Fahrsicherheit und „VS“ Verkehrssicherheit.

Interne Flotte



Anwendungsfall

N FE VE FS VS N FE VE FS VS


X X X X X O O O O O

A_1.2.1.3 Ortsbezogene An-zeige von Hindernissen X O O X X O O O O O

A_1.2.1.4 Ortsbezogene Anzei-ge von Straßenwetter X O O X O O O O O O

A_1.2.2.1 Streckengeometrie im Umfeld der Baustelle X X X X X O O O O O

A_1.2.2.2 Verkehrslage im Umfeld der Baustelle X X X X X O O O O O

A_1.2.3.2 Dynamische Routen-planung X X O O O O O O O O

A_1.3.1.1 Umleitungsempfeh-lung X X O O O O O O O O


O X X O O O O O O O

A_1.3.3.1 Priorisierung ÖPNV O O O O O O X O O O

A_1.3.3.2 Priorisierung Einsatz-fahrzeug O O O O O O X O O O


O X X O O O X X O O

A_2.1.1.2 Warnung vor liegen-gebliebenem Fahrzeug X O O X O O O O O O


Interne Flotte



Anwendungsfall

N FE VE FS VS N FE VE FS VS

A_2.1.1.4 Baustellenwarnung X O O X O O O O O O

A_2.1.1.5 Hindernisse auf der Fahrbahn X O O X O O O O O O

A_2.1.2.1 Warnung vor Stau-ende X X O X X O O O O O

A_2.1.3.1 Warnung vor Wetter-gefahren X o O X O O O O O O

A_2.1.4.1 Warnung vor sich näherndem Einsatzfahrzeug X O O X O X X O X O

A_2.2.1.1 Verkehrszeichenan-zeige im Fahrzeug X X X X X O O O O O


X X X X X O O O O O

A_2.2.2.1 Grüne Welle X X X X X X X X X X

A_2.2.2.2 Restrotanzeige X X X X X X X X X X

A_2.2.2.3 Warnung vor Rot-lichtverstoß mit Ausprägungen X O O X X X O O X O

A_2.2.3.4 Elektronisches Bremslicht O O O O O X O O X O

A_2.2.4.1 Querverkehrsassis-tent X O O X O X O O X X


ten X X O O O O O O O O

A_3.1.2.3 Kommunalinformationen X O O O O O O O O O

A_3.1.2.4 Parksituation X X O O O O O O O O

7.2.2 Technische Versuchsfälle in der internen Flotte

Vorbemerkung: Bei der Spezifikation der technischen Versuchsfälle in AP13 wurde zwi-schen der internen Flotte mit Expertenfahrern und der internen Flotte mit naiven Fahrern unterschieden. Dabei wurde davon ausgegangen, dass zum Zeitpunkt der Versuchsdurch-führung 20 Expertenfahrer und 80 naive Fahrer zur Verfügung stehen würden. Im Rahmen von Kap. 7.1.2 wird dargestellt, dass dieses Fahrerkonzept nachfolgend zu diskutieren ist.

Insgesamt wurden 38 technische Funktionsversuche für die Durchführung mit naiven Fah-rern und 42 technische Funktionsversuche für die Durchführung mit Expertenfahrern vorge-


sehen. Im Rahmen der Kommunikations-, Sicherheits- und Ausstattungsversuche sind ins-gesamt 14 technische Versuche zur Durchführung mit naiven Fahrern und 17 Versuche zur Durchführung mit Expertenfahrern vorgesehen. Tabelle 22 und Tabelle 23 geben zusätzlich darüber Auskunft, wie viele Fahrzeuge für die jeweiligen Versuche vorzuhalten sind und auf welche Validierungsziele sich die Versuche beziehen.

Tabelle 22: Funktionsversuche für die interne Flotte.

Valid

ieru

ng

Opt

imie

rung

C

hara

kter

isie

rung

In

tern

e Fl

otte

naiv

e Fa

hrer

Expe

rten

fahr

er

Fahr

zeug

e Fu

nktio

nalit

ät

Zuve

rläss

igke

it Ef

fizie

nz

Testfall-Kurzbezeichnung Fahrzeugseitige Datenerfassung

Ermittlung der Verkehrswetterlage

T_F_1.1.3_01_K0103 x x x x min 10 x

Überprüfung der Zuverlässigkeit der Wetterextra- und -interpolation sowie Wetterfusion – Dauerbetrieb

Ermittlung der Verkehrslage

T_F_1.1.4_01_K01xx_K02xx_K03xx_K04xx x x x x bis 100 x

Prüfung ob die bereitgestellte Verkehrslage und Reisezeit richtig ermittelt wird.

Straßenvorausschau

T_F_1.2.1_04_K0102 x x min 6 x

Rechtzeitige Aktualisierung der Daten bei Änderung der Situation

Baustelleninformationssystem

T_F_1.2.2_01_K0102 x x x Validierung der Relevanz der Anzeige der gemeldeten Streckengeometrieelemente

T_F_1.2.2_02_K0100_K02xx x x 1 x Validierung der Erkennung der Strecken-geometrie (bauliche Trennungen)

T_F_1.2.2_03_K0100_K02xx x x 1 x Validierung der Erkennung der Strecken-geometrie (Verschwenkung)

T_F_1.2.2_04_K0101 x X

(40) X

(10) 50 x Validierung der Berechnung der Verkehrs-lage in der Baustelle

T_F_1.2.2_05_K0101 x X

(40) X

(10 50 x Optimierung der Angemessenheit der Berechnung/Bereitstellung Verkehrslage

T_F_1.2.2_06_K0112 x x 50 x Validierung des Zeitverhaltens der Funkti-on - Aktualisierung Baustellengeometrie

T_F_1.2.2_07_K0112 x X

(10) X

(40) 50 x Validierung des Zeitverhaltens der Funkti-on – Aktualisierung der Verkehrslage

T_F_1.2.2_UE01_Kxxxx x x x

Prüfung ob die Funktion nach Ausfall ohne Datenverlust / Funktionseinschränkung automatisch weiterarbeiten kann.

T_F_1.2.2_UE02_Kxxxx x x Prüfung ob die Funktion stabil arbeitet

Erweiterte Navigation

T_F_1.2.3_01_K0104 x x x x

Vergleich der Routenwahl bei dynamischer Routenführung mit signifikant geänderter Reisezeit.

T_F_1.2.3_04_K0104_K0200 x (x) (x) (x) x

Rechtzeitige Fahrerinformation bei Aktuali-sierung der Verkehrslage

T_F_1.2.3_UE01_K0100 x x 1 x Anzahl der Funktionsausfälle

Umleitungsmanagement

T_F_1.3.1_01_K01xx_K02xx x x x x x Prüfung der Umleitungsempfehlung mit der internen Flotte

T_F_1.3.1_02_K01xx x x x Prüfung der Umleitungsempfehlung mit der externen Flotte

Lichtsignalanlagen Netzsteuerung

T_F_1.3.2_01_K0100_K0200 x x 50 x Überprüfung der Kommunikationstechno-logie IRS <-> IGLZ

T_F_1.3.2_02_K0100_K0200_K0300 x x 50 x

Minimierung der Verlustzeiten und Halte im Versuchsgebiet durch optimierte LSA-Steuerung unter Berücksichtigung der Fahrzeuge mit simTD-Funktion

T_F_1.3.2_03_K0100 x x 50 x Berechnung der Verkehrslage


Valid

ieru

ng

Opt

imie

rung

C

hara

kter

isie

rung

In

tern

e Fl

otte

naiv

e Fa

hrer

Expe

rten

fahr

er

Fahr

zeug

e Fu

nktio

nalit

ät

Zuve

rläss

igke

it Ef

fizie

nz

Testfall-Kurzbezeichnung

T_F_1.3.2_UE01_K0106 x x 100 x Auswirkung der Steuerung auf Verkehrsef-fizienz bei versch. Penetrationsraten

Lokale verkehrsabhängige LSA-Steuerung

T_F_1.3.3_UE01_K0100 x x 20 Prüfung der Ausfallsicherheit (Stabilität) der sim-TD-Funktion 1.3.3

Hinderniswarnung

T_F_2.1.1_02_K0100 x x 100 x Position manuell detektierter Hindernisse muss präzise ermittelt werden

T_F_2.1.1_03_K0102 x x x 1 x

Es soll in empfangenden Fahrzeugen vor für den Fahrer relevanten Hindernissen gewarnt werden.

T_F_2.1.1_04_K0104_K0204 x x x 55 x Die Zahl an falschen Warnungen (false positives) muss gering bleiben.

T_F_2.1.1_06_K0100 x x 11 x Erkannte Hindernisse müssen dem Fahrer zeitnah angezeigt werden.

T_F_2.1.1_08_K0108 x x min 22 x

Optimierung der DEN-Parameter Sende-häufigkeit & ExpiryTime

T_F_2.1.1_10_K0105 x x 2 x Hindernisse müssen aus Fahrmanövern automatisch detektiert werden

T_F_2.1.1_UE01_K0104 x x x x min 3 x Reife- und Wiederherstellbarkeitstests

Stauendewarnung

T_F_2.1.2_01_K0101 x x 15 x Funktionstest - Warnung vor Stauenden auf BAB

T_F_2.1.2_02_K01xx x x x Feldtest - Warnung vor Stauenden auf BAB

T_F_2.1.2_03_K0101 (KLT) x x 20-50

Warnung vor Stauenden auf BAB (Schnell-straßen)

Straßenwetterwarnung

T_F_2.1.3_01_K0103 x x x x 1 x Optimierung und Verifikation der fahrzeug-seitigen Glättedetektion

T_F_2.1.3_02_K0100 x x x 5 x Validierung der fahrzeugseitigen Wetterer-eignisfusion

Einsatzfahrzeugwarnung

T_F_2.1.4_01_K0110 x x x 21 x

Überprüfung der Erkennung und Darstel-lung der Einsatzfahrzeugwarnung im Stadtverkehr.

T_F_2.1.4_02_K0110 x x x 91 x

Überprüfung der Erkennung und Darstel-lung der Einsatzfahrzeugwarnung im Autobahnverkehr.

Verkehrszeichen-Assistent/Warnung

T_F_2.2.1_01_K0106_K0201_K0300 x x x x 1 x Funktions- und Effizienznachweis

Ampel-Phasen-Assistent/Warnung

T_F_2.2.2_03_K0100 x x x x 0 x Kompatibilitätstest für LSAs

T_F_2.2.2_04_K0100 x x x x x Ist Vorhersage der LSA Schaltung mit den zur Verfügung stehenden Daten möglich?

T_F_2.2.2_UE01_K0100 x x 1 x Konformität zur StVO

T_F_2.2.2_UE02_K0101 x x 1 x Versagenshäufigkeitstest

T_F_2.2.2_UE03_K0100 x x 1 x Versagenszeitraumtest

Längsführungsassistent

Kreuzungs-/Querverkehrsassistent

T_F_2.2.4_01_K01xx x x x x min.

2 x Vollständige und angemessene Implemen-tierung, Positivtest

T_F_2.2.4_02_K0100 x x x 1 x Vermeidung von Fehlwarnungen.

T_F_2.2.4_03_K0103 x x 1 x Erkennung der Kreuzung (Positivtest)

T_F_2.2.4_04_K01xx x x 1 x Vermeidung der fälschlichen Erkennung einer Kreuzungsannäherung


Valid

ieru

ng

Opt

imie

rung

C

hara

kter

isie

rung

In

tern

e Fl

otte

naiv

e Fa

hrer

Expe

rten

fahr

er

Fahr

zeug

e Fu

nktio

nalit

ät

Zuve

rläss

igke

it Ef

fizie

nz

Testfall-Kurzbezeichnung T_F_2.2.4_05_K0103 x x 1 x Kreuzungstopologie/Richtigkeit

T_F_2.2.4_06_K01xx x x x 1 x Richtige Vorhersage der beabsichtigten Fahrroute über die Kreuzung

T_F_2.2.4_07_K01xx x x x 1 x Richtige Vorhersage des Anhaltewunsches vor der Kreuzung

T_F_2.2.4_08_K01xx x x x Min.

2 x

Warnung vor Kollisionsrisiken mit Querver-kehrsfahrzeugen zum „richtigen“ Zeitpunkt (Positivtest)

Internetbasierte Dienstnutzung

T_F_3.1.1_01_K0100 x x 1 x Verkehrsinformationen über Internetver-bindung Fahrer zur Verfügung zu stellen.

T_F_3.1.1_02_K0100_K0200_K0301_K0400_K0500 x x 1 x

Testet wie schnell die F_311 Dienste übers Internet verfügbar wird

T_F_3.1.1_UE01_K0100_K0200 x x 1 x Testet die Wiederherstellbarkeit der im-plementierten Funktion

Standortinformationsdienste

T_F_3.1.2_01_K0104 x x 1 x Anzeige von Standortinformationen auf der Karte als POI

T_F_3.1.2_02_K0105 x x 1 x Vergleich Parkrauminformationen mit Realsituation Parkraum

T_F_3.1.2_03_K0110 x x 1 x Vergleich Parkrauminformationen mit Realsituation Parkleitsystem

T_F_3.1.2_04_K0100 x x x x 1 x Charakterisierung des Zeitverhaltens der Abfrage von Standortinformationen

T_F_3.1.2_UE01_K0100 x x x x 1 x Test zur Bestimmung der Versagenshäufigkeit der Funktion

T_F_3.1.2_UE02_K0100 x x x x 1 x Test zur Bestimmung des Funktionsverhal-tens unter Lastbedingungen

SUMME 38 42

7.2.3 Rechtlich-regulatorische Rahmenbedingungen in Bezug auf die interne Flotte

Im Rahmen des Feldversuchs sind innerhalb von simTD die rechtlich-regulatorischen Rah-menbedingungen und Konsequenzen, die sich für die Planung der Versuchsdurchführung für die interne Flotte ergeben, zu prüfen. Es sind in diesem Zusammenhang folgende Themen zu betrachten:

• Straßenverkehrsrecht

• Haftung

• Installation

• Schulung

• Datenschutz


Tabelle 23: Kommunikations-, Sicherheits- und Ausstattungsversuche für die interne Flotte.

Valid

ieru

ng

Opt

imie

rung

Cha

rakt

eris

ieru

ng

inte

rne

Flot

te

naiv

e Fa

hrer

Expe

rten

fahr

er

Fahr

zeug

e Fu

nktio

nalit

ät

Zuve

rläss

igke

it Ef

fizie

nz


Ausstattung mit IRS

T_IRS_01_K0103_K0200 x x x 20-100 Prüfung der IRS-Auslastung

T_IRS_02_K01xx_K02xx x x 1 Ermittlung der IRS-Reichweite

T_IRS_03_K01xx x x 1 Wahl der relevanten IRS für das simTD-Fahrzeug

Ausstattung mit IVS

T_IVS_01_K0103_ K0203_ K0303_ K0403_ K0503_ K0603_K0703_K0803_K0903 x x x x

Messung der Genauigkeit der generierten Verkehrslage in Abhängigkeit von der Ausstattungsrate

T_IVS_02_K0100_K0200 x x x Ausstattungsrate der Fahrzeuge mit simTD-Funktionalität (802.11p) im Straßenverkehr

Kommunikationsversuche

T_KOM_01_K0102 x x x x alle x Dauerprotokollierung der Paketfehlerrate

T_KOM_02_K0102 x x x x alle x Dauerprotokollierung der Kanallast

T_KOM_03_K0102 x x x x alle x Dauerprotokollierung des Datendurchsat-zes

T_KOM_06_K0105 x x x bis

8 x

Lastverhalten der Kommunikationstechno-logie 802.11p für Multi-Hop- GeoBroadcast

T_KOM_07_K0100 x x 13 x

Effektivität und Effizienz der Multi-Hop-GeoBroadcastverfahren Simple-GeoBroadcast und GeoBroadcast mit Contention Based Forwarding (CBF)

T_KOM_08_K0100 x x x 7 x Effektivität der Paketzwischenspeicherung für Simple GeoBroadcasting

T_KOM_10_K0100 x x x x alle x Zeitverhalten/Zeitdauer Latenz

T_KOM_16_K0100 x x x x alle x x x Reichweite/Abdeckung/Verfügbarkeit

T_KOM_17_K0100 x x x x alle x x Fehlerfreiheit/Auslastung und Latenz der Mobilfunksysteme

T_KOM_20_K0100_K0200 x x x x 1-50 Zeitverhalten Mobilfunk-Geocast Fahrzeug-zu-Fahrzeug

T_KOM_21_K0100_K0200 x x x x Zeitverhalten Mobilfunk-Geocast Infrastruk-tur-zu-Fahrzeug

IT-Sicherheit

T_SEC_04_K0100 x x x x x x Validierung der Plausibilitätsprüfung

T_SEC_05_K0100 x x x x x x Auswirkungen der Pseudonymwechselsperre

SUMME 14 17

7.3 Anforderungen an interne Flotte

7.3.1 Spezielles Fahrverhalten

In wissenschaftlichen Studien besteht häufig die Gefahr der Reaktivität (z.B. Hussy, Schreier & Echterhoff, 2010). Dies bedeutet die Veränderung bzw. Verzerrung der erhobenen Daten allein aufgrund der Kenntnis der untersuchten Personen darüber, dass sie Gegenstand einer Untersuchung sind. So ist denkbar, dass Probanden in Untersuchungssituationen versuchen, einen möglichst guten Eindruck zu hinterlassen. Bezogen auf die interne Flotte ist es daher beispielsweise möglich, dass die Probanden sich besonders anstrengen, gemäß der Stra-


ßenverkehrsordnung (StVO) zu fahren, auch wenn sie dies in ihrer natürlichen Umgebung nicht so ausgeprägt zeigen.

Für die interne Flotte sind daher u.a. folgende Maßnahmen zur Verringerung der Reaktivität möglich:

• Anonymität und Vertraulichkeit der Daten zusichern

• Täuschung über Zweck oder Zeitpunkt der Untersuchung

• Eingewöhnungsphase zu Beginn der Untersuchung einführen

Daneben wird das Fahrverhalten durch Art und Inhalt der Instruktion bzw. der Aufgabenstel-lung der Probanden beeinflusst. Diese Instruktionen müssen je nach untersuchter Fragestel-lung (z.B. unter Umständen unterschiedliche Instruktionen für nicht-technische Versuche zu Akzeptanz vs. Sicherheit erforderlich) und Anwendungsfall gewählt werden.

7.3.2 Technische Ausstattung der Fahrzeuge

Hauptziel der Fahrzeugauswahl war es, eine möglichst gute Vergleichbarkeit der Ergebnisse zwischen den einzelnen Fahrzeugen zu gewährleisten sowie Aufwand und Kosten im Allge-meinen möglichst gering zu halten (siehe Kap. 6). Ein wichtiges Kriterium für die Eignung von Fahrzeugen zur Aufnahme in die interne Flotte ist zudem deren technische Ausstattung:

• Für die Aufzeichnung und Analyse der Fahrdaten muss der Zugriff auf den CAN-Bus möglich sein. Daher kann die interne Flotte ausschließlich aus Fahrzeugen der simTD-Partner bestehen.

• Um den zusätzlichen Nutzen der C2X-Technologie bestimmen zu können, ist ein Vergleich von Fahrzeugen mit dieser Technik gegenüber Fahrzeugen ohne diese Technik notwendig. Die in diesen beiden Gruppen verwendeten Fahrzeuge müssen technisch vergleichbar sein und dürfen keine das Fahrverhalten beeinflussenden Fahrerassistenzsysteme (z.B. Tempomat, ACC) besitzen.

Für die Analyse des Nutzens der C2X-Technologie hinsichtlich Nutzerakzeptanz, Fahr- und Verkehrssicherheit sowie Fahr- und Verkehrseffizienz ist es notwendig, viele Informationen über die Fahrzeugumwelt zu erhalten, um eindeutige Erklärungen für das Fahrerverhalten bestimmen zu können. Um dies gewährleisten zu können, sind technische Installationen in den Fahrzeugen der internen Flotte zu empfehlen, welche die Auswertungsmöglichkeiten erweitern und die Validität der Analysen erhöhen würden:

• Zum einen ist zur Ermittlung der Wirkungen der simTD-Anwendungsfälle auf die Fahr-sicherheit eine Ausstattung der Fahrzeuge mit einem Abstandssensor erforderlich, durch den die Abstände zum vorausfahrenden Fahrzeug bestimmt werden können. Um das Verhalten des nachfolgenden Fahrzeugs ebenfalls messen zu können, ist darüber hinaus ein Abstandssensor nach hinten anzuraten. Durch die Abstandsdaten können auch die Ursachen für Verhaltensänderungen (z.B. Abbremsen) aufgrund einer simTD-Meldung eingegrenzt werden: Falls das Vorder-fahrzeug ebenfalls gebremst hat (durch Abstandssensorik identifizierbar), ist das Ab-bremsen nicht eindeutig auf die simTD-Meldung zurückzuführen. Falls dagegen kein Vorderfahrzeug existiert, können Verhaltensänderungen nach simTD-Warnungen rela-tiv sicher auf diese Meldung zurückgeführt werden.

• Ebenso äußerst hilfreich zur eindeutigen Identifikation von Ereignissen während der Fahrten der internen Flotte in simTD wäre eine Erfassung der Fahrt mittels Videoauf-zeichnung. Nach Mollenhauer (2009) hat eine Ausstattung von Fahrzeugen einer Naturalistic Driving Study bzw. eines Field Operational Tests mit Videoausrüstung die folgenden Vorteile:


o Erfassung von Fahrerzuständen (z.B. Ablenkung, Müdigkeit)

o Erfassung von Blickverhalten des Fahrers

o Identifikation des Verkehrsgeschehens

o Objektive Informationen bei Unfällen (z.B. Fahrer können sich evtl. nicht erin-nern, haben verzerrte Erinnerungen, könnten bewusst falsche Angaben ma-chen aus Furcht vor juristischen Folgen, können verletzt/verstorben sein)

7.4 Anforderungen der Datenauswertung

Die Auswertung der Daten der internen Flotte soll parallel zum Feldversuch möglichst zeit-nah zur Durchführung der jeweiligen Versuchsfälle erfolgen. Zum Einen, weil die Zeit zwi-schen Feldversuchs- und Projektende (Stand März 2010: Ende Feldversuch: 31.08.2012, Projektende simTD: 31.01.2013) relativ knapp bemessen ist, zum Anderen weil es sein kann, dass bestimmte Versuche noch während der Feldversuchslaufzeit wiederholt werden müs-sen. Dieser Fall tritt dann auf, wenn Fehler erst durch die detaillierte Analyse des Datenin-halts auffallen und nicht schon vorher im Leitstand oder durch technische Überprüfun-gen/Monitore erkannt wurden.

Zur genauen Rekonstruktion der im Feldversuch entstandenen Abläufe und um Kausalitäten aufdecken zu können, ist eine exakte Zeitsynchronisation zwischen den Komponenten not-wendig. Alle Komponenten und beteiligten Akteure müssen hierfür über einen exakten Zeit-stempel im Hundertstelsekundenbereich verfügen. Die geforderte Genauigkeit erhöht sich entsprechend für die Auswertung der Kenngrößen zur Fahr- und Verkehrssicherheit.

Die Aufzeichnung der generierten Daten soll über die vorhandenen Logging-Mechanismen in der IVS erfolgen.


8 Externe Flotte In diesem Kapitel werden die Zielsetzungen sowie die Anforderungen an die externe Flotte beschrieben (siehe Kap. 8.1 bzw. 8.3). Basierend auf dem Deliverable D13.2 wird in Kap. 8.2 gezeigt, welche Anwendungsfälle in simTD mit der externen Flotte geplant sind. In Kap. 8.4 werden abschließend die Anforderungen der Datenauswertung an die externe Flotte darge-stellt.

8.1 Zielsetzung der externen Flotte

Die externe Flotte soll (u.a. laut simTD-Vorhabensbeschreibung) folgenden Zielen dienen:

1. Überprüfung der Wirksamkeit von C2X-Technologie Die C2X-Technologie wird hinsichtlich der nicht-technischen Fragestellungen unter-sucht. Für diese Wirkungsermittlung soll die externe Flotte einen Beitrag leisten.

2. Untersuchung der technischen Realisierbarkeit von C2X-Technologie Neben den unter 1. genannten nicht-technischen Validierungszielen werden auch technische Validierungsziele in der externen Flotte untersucht (siehe Kap. 2.1.2.1).

3. Untersuchung natürlichen Verhaltens Die externe Flotte bietet gegenüber der internen Flotte den Vorteil, dass die Fahrer in gewohnten Situationen (private bzw. berufliche Fahrten) untersucht werden und die Gefahr der Reaktivität (siehe Kap. 7.3.1) weniger ausgeprägt ist.

4. Vergleich von Ergebnissen der internen Flotte und der externen Flotte

5. Verkehrsdatenerfassung für Verkehrslageermittlung Die externe Flotte leistet einen Beitrag zur verbesserten Verkehrslageermittlung.

8.2 Umsetzung von Anwendungs- und Versuchsfällen

8.2.1 Nicht-technische Versuchsfälle in der externen Flotte

Mittels der Erweiterten Versuchsmatrizen (siehe Deliverable D13.2, Anhang 3) wurde in AP13 untersucht, welche nicht-technischen Fragestellungen des jeweiligen Anwendungsfal-les in welcher Versuchsumgebung überprüft werden können. Tabelle 24 zeigt, veranschau-licht durch ein „X“, für welche Anwendungsfälle eine Realisierung mit der externen Flotte geplant ist.

Zusammenfassend wird deutlich, dass die externe Flotte hauptsächlich zur Überprüfung der Nutzerakzeptanz der einzelnen Anwendungsfälle dient. Für detailliertere Informationen siehe Deliverable D13.2.


Tabelle 24: Auflistung der in simTD mit der externen Flotte geplanten Anwendungsfälle in Abhängigkeit der nicht-technischen Fragestellung.

Externe Flotte Nicht-technische


Nutzer- akzeptanz

Fahr- effizienz

Verkehrs-effizienz

Fahr-sicherheit

Verkehrs-sicherheit


X O O O O

A_1.2.1.3 Ortsbezogene Anzei-ge von Hindernissen X O O O O

A_1.2.1.4 Ortsbezogene Anzei-ge von Straßenwetter X O O O O

A_1.2.2.1 Streckengeometrie im Umfeld der Baustelle X O O O O

A_1.2.2.2 Verkehrslage im Umfeld der Baustelle X O O O O

A_1.2.3.2 Dynamische Routen-planung X X O O O

A_1.3.1.1 Umleitungsempfeh-lung X X O O O


O O X O O

A_1.3.3.1 Priorisierung ÖPNV O O O O O



O O O O O

A_2.1.1.2 Warnung vor liegen-gebliebenem Fahrzeug X O O O O

A_2.1.1.4 Baustellenwarnung X O O O O

A_2.1.1.5 Hindernisse auf der Fahrbahn X O O O O

A_2.1.2.1 Warnung vor Stau-ende X O O O O

A_2.1.3.1 Warnung vor Wetter-gefahren X O O X O

A_2.1.4.1 Warnung vor sich näherndem Einsatzfahrzeug X O O O O

A_2.2.1.1 Verkehrszeichenan-zeige im Fahrzeug X X O O O


X X O O O

A_2.2.2.1 Grüne Welle X O O O O


Externe Flotte Nicht-technische


Nutzer- akzeptanz

Fahr- effizienz

Verkehrs-effizienz

Fahr-sicherheit

Verkehrs-sicherheit

A_2.2.2.2 Restrotanzeige X O O O O

A_2.2.2.3 Warnung vor Rot-lichtverstoß mit Ausprägungen O O O O O

A_2.2.3.4 Elektronisches Bremslicht O O O O O

A_2.2.4.1 Querverkehrsassis-tent X O O X O


ten X O O O O

A_3.1.2.3 Kommunalinformationen X O O O O

A_3.1.2.4 Parksituation X O O O O

Um für die weiteren Fragestellungen, die die Fahr- und Verkehrseffizienz sowie die Fahr- und Verkehrssicherheit betreffen, repräsentative Ergebnisse während des Feldversuchs er-zielen und diese in ihrer Gesamtheit besser einschätzen zu können, müssen aus verkehrs-technischer Sicht noch einige theoretische Betrachtungen angestellt werden.

Interessant sind insbesondere die Ausstattungsraten sowie der durchschnittliche tägliche Verkehr (DTV) und die damit verbundenen zentralen Fragestellungen:

• Inwieweit wird der umgebende Verkehr durch die externe Flotte beeinflusst?

• Ist die Größe der Flotte (Anzahl der Fahrzeuge) aus verkehrstechnischer Sicht geeig-net für eine sinnvolle Verkehrslageermittlung?

Der DTV liegt auf der Bundesautobahn (BAB) A5 innerhalb des Versuchsgebietes bei 144895 Kfz pro 24 Stunden (6037 Kfz/Std; für die die Spitzenstunde wird dieser Wert deut-lich überschritten; Quelle: Hessisches Landesamt für Straßen- und Verkehrswesen, 2005). Würden sich – in einem äußerst unwahrscheinlichen Fall – alle 300 Fahrzeuge der externen Flotte gleichzeitig im untersuchten Abschnitt aufhalten, so wäre im Idealfall eine maximale Ausstattungsrate von ca. 5% möglich. Bei 20 Fahrzeugen im untersuchten Abschnitt – was trotz der deutlichen Reduktion eine immer noch sehr unwahrscheinliche Annahme ist – läge die Ausstattungsrate bei ca. 0.3%. Die Auswahl und Zusammensetzung der externen Flotte hat hierauf natürlich einen starken Einfluss. Durch die lokale Konzentration aufgrund der An-näherung an den Flottenstandort und dadurch beeinflusst eventuell ähnliche Fahrwege kann die Ausstattungsrate mitunter auch größer sein. Das diesbezügliche Maximum liegt jedoch bei 5%.

Betrachtet man das gesamte Versuchsgebiet, so kommt man auf eine Gesamtnetzlänge von 200 km (Innerortsbereich ca. 61 km, Bundesstraße ca. 48 km und BAB ca. 91 km). Für beide Fahrtrichtungen zusammen also auf ca. 400 km. Angenommen, es befinden sich alle 300 Fahrzeuge gleichzeitig im Versuchsgebiet, so würden im Mittel ca. 0.75 Fahrzeuge pro Kilo-meter vorhanden sein – oder anders ausgedrückt – jeweils ein Fahrzeug pro 1.33km (für 200 Fz gilt: 1 Fahrzeug pro 2 km; für 100 Fz gilt:1 Fz pro 4 km).


Aus diesen Betrachtungen heraus lassen sich die o.g. Fragestellungen folgendermaßen be-antworten:

• Für eine signifikante Beeinflussung des umgebenden Verkehrs durch die externe Flotte sind eindeutig zu wenige Fahrzeuge vorhanden.

• Zur Ermittlung der Verkehrslage ist die Anzahl an Fahrzeugen geeignet. Dies ist je-doch nur mit der Einschränkung möglich, dass sehr viele Fahrzeuge (bezogen auf das Gesamtnetz) gleichzeitig und gleichverteilt im Versuchsgebiet unterwegs sein müssen. Davon kann nicht ausgegangen werden.

8.2.2 Technische Versuchsfälle in der externen Flotte

Die Test- und Versuchsspezifikation, die im Rahmen des AP13 erstellt worden ist (siehe De-liverable D13.2), definiert die Test- und Versuchsfälle für den Feldversuch sowie ihre jeweili-gen Rahmenbedingungen. Die Versuchsspezifikationen für die technischen Eigenschaften der simTD-Systeme und -Funktionen orientieren sich in diesem Zusammenhang an den Vali-dierungszielen aus dem AP12.

Insgesamt wurden 136 Test- und Versuchsfallspezifikationen für die Validierungsziele Funk-tionalität, Effizienz und Zuverlässigkeit spezifiziert, von denen 29 zur Durchführung mit der externen Flotte vorgesehen sind. In vielen Fällen ist die Verwendung der externen Flotte ergänzend zu Versuchen mit der internen Flotte geplant, d.h. die Messungen für eine Sys-temeigenschaft werden sowohl in einem kontrollierten Versuch mit der internen Flotte vorge-nommen und zusätzlich über Langzeitmessungen mit der externen Flotte abgesichert.

Eine genauere Darstellung der Nutzung und des Nutzens der externen Flotte findet sich in den folgenden Kapiteln. Die Analyse orientiert sich an der durch das AP13 vorgegebenen Struktur und unterscheidet in Kommunikationsversuche, funktionsspezifische Versuche und funktionsübergreifende Versuche.

8.2.2.1 Die Nutzung der externen Flotte für Kommunikationsversuche, Ausstattung und bessere Ortung

Die externe Flotte wird im Rahmen der Kommunikationsversuche laut Versuchsspezifikation von AP13 für die Umsetzung von insgesamt 8 Versuchsspezifikationen benötigt. Die Versu-che zur besseren Ortung sowie zur Ausstattung bzw. Durchdringung des Versuchsfelds mit kommunizierenden Fahrzeugen und Road Side Stations (Ausstattungsversuche) greifen nicht auf die externe Flotte zurück.

Die betroffenen Kommunikationsversuche sind insbesondere dadurch gekennzeichnet, dass sie über einen längeren Zeitraum maximal viele Messungen des Kommunikationsverhaltens in möglichst unterschiedlichen Situationen zur Verfügung stellen. Die dadurch entstehende hohe Stichprobenanzahl bildet die Grundlage für die vorgesehenen statistischen Auswerte-verfahren zur Leistungsbewertung des Kommunikationssystems. Die externe Flotte dient im Rahmen der Kommunikationsversuche als Datensammler, um eine möglichst große Anzahl an Messungen für die Auswertung zur Verfügung stellen zu können. Alle Versuchsspezifika-tionen, die die Nutzung der externen Flotte vorsehen, werden auch als kontrollierte Versuche mit der internen Flotte vorgenommen (siehe Tabelle 25).

Im Einzelnen ergeben sich folgende technischen Versuchsfälle für die externe Flotte:

WLAN Protokolle 802.11p, 802.11bg

• Die Kommunikationsversuche T_KOM_01_K0102, T_KOM_02_K0102 und T_KOM_03_K0102 sehen eine Protokollierung der Paketfehlerrate („Packet Error Ra-te“, PER), der Kanallast („Channel Load“, CL) und des Datendurchsatzes sowohl für


802.11p (Variante 1) als auch für 802.11bg (Variante 2) Protokoll vor. Die zu ermit-telnden Kenngrößen wie beispielsweise der Signal-Rauschabstandes („Signal-to-Noise Ratio“, SNR), die Rauschleistung („Noise Power“), die Paketfehlerrate („Packet Error Rate“, PER) sowie die Latenz und Übertragungsrate sind durchgängig statisti-sche Größen, deren Aussagekraft durch eine hohe Anzahl von Messungen besser belegbar wird.

• Im Versuch T_KOM_10_K0100 werden kontinuierlich die Latenzzeit der Kommunika-tion über die WLAN Protokolle 802.11p als auch über 802.11bg ermittelt. Diese Daten werden anschließend zu statistischen Aussagen wie Durchschnitt, Minimum und Ma-ximum etc. aggregiert.

Mobilfunksysteme UMTS und GSM

• Die Versuche T_KOM_16_K0100 und T_KOM_17_K0100 sehen ein Dauerlogging der relevanten Messwerte zum statistischen Nachweis der Reichweite, Abdeckung, Fehlerfreiheit, Auslastung, Latenz und Verfügbarkeit der Mobilfunksysteme UMTS und GSM sowie deren Ausprägungen (HSxPA, Edge, GPRS) vor.

Mobilfunksysteme Geocast Server

• Die Versuche T_KOM_20_K0100 und T_KOM_21_K0100 werden das Zeitverhalten der Kommunikation für die Kommunikationsfälle Mobilfunk-Geocast Fahrzeug-zu-Fahrzeug und Mobilfunk-GeocastInfrastruktur-zu-Fahrzeug untersuchen. Die externe Flotte ist für das Dauerlogging vorgesehen. Hierfür werden die von den Funktionen in deren Tests übertragene Geocasts für diese Untersuchung herangezogen.

Im Bereich Kommunikationsversuche, Ausstattung und bessere Ortung wird die externe Flot-te demzufolge dazu verwendet, die Datenbasis für die Kommunikationsversuche zu erhöhen. Die externe Flotte bietet die Möglichkeit, das Kommunikationsverhalten bzw. die Kommuni-kationssysteme im Alltagsgebrauch vermessen und prüfen zu können und anschließend eine entsprechende Bewertung der Systeme vornehmen zu können. Die erwartete hohe Anzahl messbarer Ereignisse führt zu einer besseren Datengrundlage für die anvisierten statistisch fundierten Bewertungen des Kommunikationsverhaltens.

Zu klärende Fragen sind:

• Welche Stichprobengröße (Anzahl der messbaren Kommunikationsereignisse) ist für die einzelnen Versuche minimal notwendig?

• Wie groß ist die Wahrscheinlichkeit, dass sich die gewünschten Kommunikationser-eignisse mit der externen Flotte tatsächlich realisieren lassen? Zu unterscheiden ist hier insbesondere zwischen der Fahrzeug-zu-Fahrzeug-Kommunikation, die ein ex-plizites (und im Falle der externen Flotte nur schwer planbares) aufeinandertreffen zweier Fahrzeuge als Kommunikationsvoraussetzung aufweist und der Kommunikati-on mit zentralenseitigen Systemen, die unabhängig von der konkreten Verteilung der einzelnen Fahrzeuge immer mess- und prüfbar ist.

• Lassen sich die erforderlichen Daten auch im Dauerlogging bei Versuchen mit der in-ternen Flotte erheben? Wenn ja, in welchem Umfang und mit welchen Auswirkungen für die Bewertung der Funktion?

• Neben der Bewertung der durch diesen Ansatz ermittelten Stichprobengröße für die einzelnen Kenngrößen des Kommunikationsverhaltens ist darüber hinaus zu klären, ob bzw. welche der für die Kommunikationsversuche notwendigen Messungen paral-lel zu den anderen technischen bzw. nicht-technischen Versuchen als Dauerlogging durchführbar sind ohne diese zu stören?


8.2.2.2 Die Nutzung der externen Flotte für die Prüfung der Funktionen Die externe Flotte hat bei der Prüfung der funktionsspezifischen Validierungsziele Effizienz, Funktionalität, Angemessenheit und Zuverlässigkeit zwei grundsätzlich verschiedene Aufga-ben. Zum einen dient sie, ähnlich wie bei den Kommunikationsversuchen dazu, die Anzahl der Einzelmessungen zu erhöhen. Darüber hinaus wird die externe Flotte im Rahmen der Funktionen (F_1.1.4 Ermittlung der Verkehrslage sowie F_1.3.1 Umleitungsmanagement, F_2.1.3 Funktion Straßenwetterwarnung) verwendet, um eine größere Menge an funktions-verwertbaren Daten einzusammeln und damit die Datenbasis zu erhöhen, auf deren Grund-lage die Funktion arbeitet (Fahrzeuge als Sensoren).

Im Einzelnen ergeben sich folgende technische Versuchsfälle für die externe Flotte:

Fahrzeugseitige Datenerfassung

• Der Versuchsfall T_F_1.1.2_03_K0100_K0200 (Funktion Fahrzeugseitige Datener-fassung) prüft und protokolliert das Startverhalten des CAM Sendens für die Fahr-zeuge im Versuchsgebiet. Die externe Flotte dient in diesem Versuch dazu, möglichst viele Startsituationen mit den verschiedenen Fahrzeugen und Nutzungssituationen zu erhalten.

• Der Versuchsfall T_F_1.1.2_05_K0100_K0200_K0300_K0400 (Funktion „Fahrzeug-seitige Datenerfassung“) protokolliert die Sendeabstände von CAM Nachrichten eines Fahrzeugs, die von einer IRS empfangen werden. Für den Test sind möglichst viele IVS (<100) bei realistischen Manövern zu beobachten. Die externe Flotte wird ver-wendet, um die Anzahl der Messungen und Verkehrssituationen zu erhöhen, die für die Bewertung der Funktion herangezogen werden können.

• Die Versuche T_F_1.1.2_UE01_K0100_K0200_K0300_K0400, T_F_1.1.2_UE02_ K0100_K0200_K0300_K0400 und T_F_1.1.2_UE03_K0100_K0200 prüfen die Zuver-lässigkeit des CAM Sendens sowie das Startverhalten des CAM Senders. Es wird geprüft, wann das CAM Senden ausfällt sowie wie sich die Ausfälle des CAM Sen-dens verteilen. Die externe Flotte dient dazu, eine größere Anzahl von Messungen für die Auswertung zur Verfügung stellen zu können.


• Der Versuchsfall T_F_1.1.3_01_K0103 (Funktion „Ermittlung der Verkehrswetterla-ge“) testet die Wetterextra- und -interpolation sowie Wetterfusion. Die Daten kommen dabei aus verschiedenen Quellen, unter anderem aus den mit einer IVS ausgestatte-ten Fahrzeugen. Die externe Flotte ist in diesem Zusammenhang als Quelle für ver-teilt ermittelte Wetterdaten vorgesehen.


• Der Versuchsfall T_F_1.1.4_02_K0105K02xx_K03xx (Funktion „Ermittlung der Ver-kehrslage“) überprüft, ob eine auf Basis der Fusion infrastrukturseitig und fahrzeug-seitig erfasster Daten bereitgestellte Verkehrslage und Reisezeit richtig ermittelt wird und somit der Realität entspricht, die durch die Aufzeichnungen der Versuchsfahrer in den Streckenabschnitten ermittelt werden kann. Die externe Flotte dient auch hier als Quelle (ausgestattetes Fahrzeug als Sensor für Verkehrslageermittlung) für die Er-mittlung der Verkehrslage im simTD-Versuchsgebiet.


• Der Versuchsfall T_F_1.2.3_04_K0104_K0200 (Funktion „Erweiterte Navigation“) prüft, ob die Änderung einer Verkehrslage rechtzeitig von der Funktion erkannt wird, so dass noch eine Alternativroute berechnet werden kann. Der Versuch sieht die Nutzung der externen Flotte für die Breitenerprobung der Funktion vor.



• Der Versuchsfall T_F_1.3.1_02_K01xx (Funktion „Umleitungsmanagement“) prüft die Angemessenheit, die Richtigkeit und das Zeitverhalten einer Umleitungsempfehlung, dafür (sind Haupt- und Ausweichrouten mit ausreichend großer Fahrzeugzahl parallel zu befahren). Die Versuche werden sowohl mit der internen Flotte als auch mit der externen Flotte geprüft. Die externe Flotte dient dazu, zusätzlich zu den gesteuerten Versuchen weitere Messungen durchführen zu können.


• Der Versuchsfall T_F_1.3.3_UE01_K0100 prüft die Stabilität der Funktion F_1.3.3, d.h. es wird geprüft, wie ausfallsicher die Funktion ist. Dieser Wert wird aus Gründen der Vergleichbarkeit auf eine Stunde Laufzeit bezogen. Getestet wird in Form eines Langzeittests (mindestens 60 Minuten). Dieser Versuch ist nur für die externe Flotte geplant.

Hinderniswarnung

• Der Versuchsfall T_F_2.1.1_03_K0102 (Funktion „Hinderniswarnung“) prüft, ob die Fahrzeuge vor relevanten Hindernissen gewarnt werden.

• Der Versuchsfall T_F_2.1.1_UE01_K0104 prüft die Reife und Wiederherstellbarkeit. Der Testfall liefert nicht absolut notwendige, allerdings sehr interessante Informatio-nen zur Robustheit der Funktion. Außerdem ist der Aufwand äußerst gering, da nur der Funktionszustand geloggt werden muss. Die externe Flotte ermöglicht die Prü-fung der Validierungsziele im Alltagsgebrauch und bietet die Möglichkeit, eine große Anzahl von Messungen für die Auswertung zur Verfügung stellen zu können.


• Der Versuchsfall T_F_2.1.3_03_K0101 (Funktion „Straßenwetterwarnung“) prüft, ob die Fusion und Detektion von Wetterereignissen (Glätte, Regen, Nebel, Wind) funkti-oniert. Ein besonderer Schwerpunkt des Versuchs liegt dabei bei der Regen- und Nebeldetektion. Die Ereignisse stammen dabei aus der fahrzeugseitigen Detektion (F_2.1.3), von anderen simTD-Fahrzeugen (F_2.1.3) und aus der Straßenwetterzent-rale (F_1.1.3 in der ICS).


• Der Versuchsfall T_F_2.2.2_03_K0100 (Funktion „Ampel-Phasen-Assistent/ War-nung“) prüft die Kompatibilität der verschiedenen LSA im Versuchsgebiet in Bezug auf ein korrektes Zusammenspiel mit der IRS-Komponente der Funktion F_2.2.2 „Ampel-Phasen-Assistent/Warnung“. Die externe Flotte wird eingesetzt, um die An-zahl der Prüfsituationen zu erhöhen (Dauertests).

• Der Versuchsfall T_F_2.2.2_04_K0100 dient zur Optimierung der Algorithmen. An-hand von diversen Szenarien werden die Vorhersagen der Steuerung beurteilt und verbessert. Der Ampelphasenassistent wird in die Lage versetzt, auf die möglichen Schwankungsbereiche der Vorhersage zu reagieren. Die externe Flotte dient dazu, der Funktion fahrzeugseitige Daten zur Verfügung zu stellen.


• Der Versuchsfall T_F_3.1.2_04_K0100 (Funktion „Standortinformationsdienste“) dient zur Bestimmung der Zeitdauer von der Anfrage von Standortinformationen bis zur Anzeige des Ergebnisses. Darüber hinaus wird geprüft, ob die Daten im Fahrzeug verfügbar sind bzw. von der Versuchszentrale abgefragt werden müssen und der Sta-tus der Datenverbindung ins Internet (Mobilfunk) aufgezeichnet. Die externe Flotte


wird in diesem Versuch dazu verwendet eine möglichst hohe Anzahl von Messungen für die Auswertung zur Verfügung stellen zu können.

• Die Versuchsfälle T_F_3.1.2_UE01_K0100 und T_F_3.1.2_UE02_K0100 dienen der Zuverlässigkeitsprüfung der Funktion „Standortinformationsdienste“. Es wird die Versagenshäufigkeit der Funktion gemessen und das Funktionsverhalten unter Last-bedingungen geprüft. Zusätzlich zur kontrollierten Flotte wird die externe Flotte ein-gesetzt, um eine möglichst große Datenbasis für die Auswertung zur Verfügung stel-len zu können.

Von den insgesamt 21 in simTD zu realisierenden Funktionen planen somit aktuell 9 Funktio-nen die Nutzung der externen Flotte für die Durchführung technischer Versuche. Dabei las-sen sich zwei grundsätzlich verschiedene Anwendungsszenarien identifizieren.

1. Ähnlich wie bei den Kommunikationsversuchen wird die externe Flotte dazu verwen-det, eine möglichst große Datenbasis für die Auswertung der technischen Validie-rungsziele Effizienz, Funktionalität, Angemessenheit und Zuverlässigkeit zur Verfü-gung stellen zu können. Als Ergänzung zu den Messungen mit der kontrollierten Flot-te fallen durch zusätzliche Messungen mit der externen Flotte mehr auswertbare Da-ten an. Ähnlich wie bei den Kommunikationsversuchen bleibt zu prüfen, inwiefern diese Hoffnung begründet ist. Eine solche Prüfung ist auf der Ebene der einzelnen Funktionen vorzunehmen.

2. Im Rahmen der Funktionen F_1.1.4 Ermittlung der Verkehrslage, F_1.3.1 Umlei-tungsmanagement sowie F_2.1.3 Funktion Straßenwetterwarnung wird die externe Flotte verwendet, um eine größere Menge an funktionsverwertbaren Daten einzu-sammeln und damit die Datenbasis zu erhöhen, auf deren Grundlage die jeweilige Funktion arbeitet (Fahrzeuge als Sensoren).

Während für das erste Anwendungsszenario ein Ersatz der externen Flotte durch Fahrzeuge der kontrollierten Flotte prinzipiell möglich ist, stellt dieses zweite Szenario insbesondere Anforderungen in Hinblick auf die Verteilung der Fahrzeuge und das Fahrverhalten (Daten-sammlung unter möglichst realistischen Nutzungsvoraussetzungen), die sich mit der kontrol-lierten Flotte nur schwer simulieren lassen. In diesem Zusammenhang stellen sich die fol-genden Fragen:

• Wie muss die externe Flotte gestaltet sein (Fahrerverhalten, Nutzungszeiten, Nut-zungsdauer, Verteilung der Fahrzeuge im Versuchsgebiet), sodass die Fahrzeuge die benötigten Daten auch wirklich liefern?

• Wie viele Fahrzeuge werden als Sensoren benötigt?

8.2.2.3 Übersicht Vorbemerkung: Bei der Spezifikation der technischen Versuchsfälle in AP13 wurde zwi-schen der internen Flotte mit Expertenfahrern und der internen Flotte mit naiven Fahrern unterschieden. Dabei wurde davon ausgegangen, dass zum Zeitpunkt der Versuchsdurch-führung 20 Expertenfahrer und 80 naive Fahrer zur Verfügung stehen würden. Im Rahmen von Kap. 7.1.2 wird dargestellt, dass dieses Fahrerkonzept nachfolgend zu diskutieren ist.

Die im Folgenden aufgeführten Tabelle 25 und Tabelle 26 beschreiben die Versuchsspezifi-kationen aus dem AP13, die eine Verwendung der externen Flotte vorsehen.


Tabelle 25: Zusammenfassung der Ausstattungs-, Kommunikation- und IT-Sicherheitsversuche für die externe Flotte.

Valid

ieru

ng

Opt

imie

rung

C

hara

kter

isie

rung

exte

rne

Flot

te

naiv

e Fa

hrer

Ex

pert

enfa

hrer

Fahr

zeug

e Fu

nktio

nalit

ät

Zuve

rläss

igke

it Ef

fizie

nz


Ausstattung mit IRS

Ausstattung mit IVS

Kommunikationsversuche

T_KOM_01_K0102 x x x x alle x Dauerprotokollierung der Paketfehlerrate

T_KOM_02_K0102 x x x x alle x Dauerprotokollierung der Kanallast

T_KOM_03_K0102 x x x x alle x Dauerprotokollierung des Datendurchsat-zes

T_KOM_10_K0100 x x x x alle x Zeitverhalten/Zeitdauer Latenz

T_KOM_16_K0100 x x x x alle x x x Reichweite/Abdeckung/Verfügbarkeit

T_KOM_17_K0100 x x x x alle x x Fehlerfreiheit/Auslastung und Latenz der Mobilfunksysteme

T_KOM_20_K0100_K0200 x x x x 1-50 Zeitverhalten Mobilfunk-Geocast Fahrzeug-zu-Fahrzeug

T_KOM_21_K0100_K0200 x x x x Zeitverhalten Mobilfunk-Geocast Infrastruk-tur-zu-Fahrzeug

IT-Sicherheit

T_SEC_04_K0100 x x x x x x Validierung der Plausibilitätsprüfung

T_SEC_05_K0100 x x x x x x Auswirkungen der Pseudonymwechselsperre

SUMME 10

Tabelle 26: Zusammenfassung der Test- und Versuchsspezifikation für Funktionsversuche für die externe Flotte.

Valid

ieru

ng

Opt

imie

rung

Cha

rakt

eris

ieru

ng

exte

rne

Flot

te

naiv

e Fa

hrer

Expe

rten

fahr

er

Fahr

zeug

e

Funk

tiona

lität

Zuve

rläss

igke

it

Effiz

ienz


Fahrzeugseitige Datenerfassung

T_F_1.1.2_03_K0100_K0200 x x x IRS empfängt ProbeVehicleData im Versuchsgebiet

T_F_1.1.2_05_K0100_K0200_K0300_K0400 x x x CAM Frequenz im Versuchsgebiet

T_F_1.1.2_UE01_K0100_K0200_K0300_K0400 x x x Ausfälle des CAM Sendens im Versuchsgebiet

T_F_1.1.2_UE02_K0100_K0200_K0300_K0400 x x x Ausfälle des CAM Sendens im Versuchsgebiet

T_F_1.1.2_UE03_K0100_K0200 x x x Startverhalten des CAM Sendens im Versuchsgebiet


T_F_1.1.3_01_K0103 x x x x min 10 x

Überprüfung der Zuverlässigkeit der Wetterextra- und -interpolation sowie Wetterfusion – Dauerbetrieb


T_F_1.1.4_02_K0105_K02xx_K03xx x x x

Prüfung ob die bereitgestellte Verkehrslage und Reisezeit richtig ermittelt wird.


Valid

ieru

ng

Opt

imie

rung

Cha

rakt

eris

ieru

ng

exte

rne

Flot

te

naiv

e Fa

hrer

Expe

rten

fahr

er

Fahr

zeug

e

Funk

tiona

lität

Zuve

rläss

igke

it

Effiz

ienz


Straßenvorausschau

Baustelleninformationssystem


T_F_1.2.3_04_K0104_K0200 x (x) (x) (x) x Rechtzeitige Fahrerinformation bei Aktualisierung der Verkehrslage


T_F_1.3.1_02_K01xx x x x Prüfung der Umleitungsempfehlung mit der externen Flotte

Lichtsignalanlagen Netzsteuerung

T_F_1.3.2_02_K0100_K0200_K0300 x x 50 x

Minimierung der Verlustzeiten/Halte durch optimierte LSA-Steuerung unter Berücksichtigung der Fahr-zeuge mit simTD-Funktion


T_F_1.3.3_UE01_K0100 x x 20 Prüfung der Ausfallsicherheit (Stabi-lität) der simTD-Funktion 1.3.3

Hinderniswarnung

T_F_2.1.1_03_K0102 x x x 1 x

Es soll in empfangenden Fahrzeu-gen vor für den Fahrer relevanten Hindernissen gewarnt werden.

T_F_2.1.1_UE01_K0104 x x x x min 3 x

Reife- und Wiederherstellbarkeitstests

Stauendewarnung


T_F_2.1.3_03_K0101 x X 5 x

Validierung der fahrzeugseitigen Wetterereignisdetektion und -fusion – Dauerbetrieb

Einsatzfahrzeugwarnung

Verkehrszeichen-Assistent/Warnung

T_F_2.2.1_01_K0106_K0201_K0300 x X x x 1 x Funktions- und Effizienznachweis


T_F_2.2.2_03_K0100 x X x x 0 x Kompatibilitätstest für LSAs

T_F_2.2.2_04_K0100 x X x x x

Ist eine Vorhersage der LSA Schal-tung mit den zur Verfügung stehen-den Daten möglich?

Längsführungsassistent

Kreuzungs-/Querverkehrsassistent

Internetbasierte Dienstnutzung


T_F_3.1.2_04_K0100 x X x x 1 x

Charakterisierung des Zeitverhal-tens der Abfrage von Standortinfor-mationen

T_F_3.1.2_UE01_K0100 x X x x 1 x Test zur Bestimmung der Versagenshäufigkeit der Funktion

T_F_3.1.2_UE02_K0100 x X x x 1 x

Test zur Bestimmung des Funkti-onsverhaltens unter Lastbedingun-gen

SUMME 20


8.2.3 Rechtlich-regulatorische Rahmenbedingungen in Bezug auf die externe Flot-te

Im Rahmen des Feldversuchs sind innerhalb von simTD die rechtlich-regulatorischen Rah-menbedingungen und Konsequenzen, die sich für die Planung der Versuchsdurchführung für die externe Flotte ergeben zu prüfen. Es sind in diesem Zusammenhang folgende Themen zu betrachten:

• Straßenverkehrsrecht

• Haftung

• Installation

• Schulung

• Datenschutz

8.3 Anforderungen an die externe Flotte

8.3.1 Spezielles Fahrverhalten

Die Fahrer der externen Flotte in simTD werden voraussichtlich eine heterogene Gruppe bil-den. So wird es möglich sein, dass von den Fahrern neben Fahrten aus privaten Zwecken auch Fahrten aus beruflichen Gründen (z.B. Fahrten von Vertretern, Lieferdiensten, Beförde-rungsunternehmen) getätigt werden, wodurch die Fahrer ein unterschiedliches Fahrverhalten aufweisen werden. Insbesondere bei Fahrten aus beruflichen Gründen zeigt sich häufig ein spezielles Fahrverhalten:

• Taxen auf der Suche nach Fahrgästen fahren langsamer als bei besetzter Fahrt und halten ggf. einige Minuten an, um Fahrgäste aufzunehmen.

• Fahrzeuge von Lieferdiensten halten bei der Auslieferung von Waren mehrmals an, um Pakete zuzustellen.

Allerdings ist in anderen Phasen derselben Fahrten dieses spezielle Fahrverhalten nicht zu beobachten:

• Taxen auf dem Weg zu einem bestimmten Ziel (mit Fahrgast oder um einen Fahrgast abzuholen)

• Fahrzeuge von Lieferdiensten auf dem Weg zum Auslieferungsgebiet

In der Auswertung der Fahrten ist eine Vermengung von Fahrten mit speziellem und nicht-speziellem Fahrverhalten äußerst problematisch, da die Ergebnisse durch äußere Faktoren konfundiert sein können (aus den aufgezeichneten Fahrdaten ist beispielsweise nicht ein-deutig nachzuvollziehen, ob das Taxi aufgrund eines Hindernisses auf der Straße angehal-ten hat oder um einen Fahrgast aufzunehmen). Daher muss in der Auswertung derartiges spezielles Fahrverhalten ausgeschlossen werden. Zur Identifizierung speziellen Fahrverhal-tens ist eine Dokumentation durch den Fahrer notwendig (z.B. durch eine Eingabe am HMI, ob das Taxi gerade auf Fahrgastsuche ist), sodass dies für die Auswertung bekannt ist.

Idealerweise wird die externe Flotte so zusammengestellt, dass spezielles Fahrverhalten möglichst selten auftritt.


8.3.2 Auswahl und technische Ausstattung der Fahrzeuge

Entsprechend der internen Flotte beeinflusst auch bei der externen Flotte die Fahrzeugklas-se der ausgewählten Fahrzeuge entscheidend die Interpretierbarkeit und Generalisierbarkeit der Ergebnisse:

• Auf der einen Seite sollten hinsichtlich einer optimalen Vergleichbarkeit der Fahrzeu-ge untereinander und mit den Ergebnissen der internen Flotte die Fahrzeuge aus denselben bzw. ähnlichen Fahrzeugklassen (z.B. nur Mittelklassefahrzeuge) stam-men. Je unterschiedlicher die Fahrzeuge in den Flotten sind, desto eingeschränkter ist die Vergleichbarkeit der Ergebnisse: So ist z.B. ein Vergleich von Kleinwagen mit Fahrzeugen der Oberklasse problematisch, da sich die Fahrzeuge in wesentlichen Faktoren unterscheiden (z.B. Beschleunigungsverhalten, Bremsverhalten). Das be-einflusst das Fahrverhalten wie auch das Sicherheitsgefühl des Fahrers.

• Auf der anderen Seite sollten hinsichtlich einer optimalen Generalisierbarkeit der Er-gebnisse die Fahrzeuge aus unterschiedlichen Fahrzeugklassen stammen. Je ähnli-cher die Fahrzeuge sind, desto eingeschränkter ist die Generalisierbarkeit: So ist bei-spielsweise die Verallgemeinerung von Untersuchungsergebnissen einer Studie aus-schließlich mit Mittelklassewagen auf die Gesamtmenge aller Fahrzeugklassen (z.B. Transporter, LKW, Kleinwagen) in Frage zu stellen.

Aus diesen beiden divergierenden Anforderungen ist ein geeigneter Konsens zu finden, der sowohl das Kriterium der Vergleichbarkeit als auch der Generalisierbarkeit bestmöglich er-füllt.

Für die Anforderungen an die technische Ausstattung gelten dieselben Aspekte wie für die interne Flotte (siehe Kap. 7.3.2).

8.3.3 Eignung der Fahrer für die externe Flotte

Bei der Auswahl der Fahrer für die externe Flotte ist zu berücksichtigen,

1. welche Strecken

2. wie häufig und

3. zu welchem Zweck

gefahren werden. Diese Faktoren beeinflussen erheblich die Eignung eines Fahrers, in die externe Flotte aufgenommen zu werden:

1. Streckenart Für die Bestimmung des Nutzens der C2X-Technologie ist es notwendig, dass die gefahrenen Strecken der Fahrzeuge der externen Flotte überwiegend im Versuchs-gebiet liegen, da ein Großteil der simTD-Anwendungsfälle nur dort funktioniert. An-sonsten würden die simTD-Anwendungsfälle aus Sicht des Fahrers nicht immer funk-tionieren, was bei der Auswertung der Nutzerakzeptanz berücksichtigt werden müss-te. Weiterhin sollten die Strecken die verschiedenen Teile des Versuchsgebiets (Stadt, Land-/Bundesstraße, Autobahn) gleichermaßen abdecken. Es wird empfohlen, dass die externe Flotte sowohl aus Pendlern (die immer dieselbe Strecke zu ähnlichen Zeiten fahren) als auch aus Vielfahrern (die variable Strecken zu unterschiedlichen Zeiten fahren) besteht.

• Durch den Einsatz von Pendlern ist die Wirkungsermittlung einer längeren Nut-zung auf denselben Strecken möglich, was z.B. für die Anwendungsfälle A_1.2.3.2 „Dynamische Routenplanung“ oder A_1.3.1.1 „Umleitungsempfehlung“ relevant ist. Weiterhin können längerfristige Verhaltensänderungen identifiziert


werden (z.B. bei regelmäßigen Stauenden auf denselben Strecken). Zudem er-leichtert die Nutzung derselben Strecken die Vergleichbarkeit der Daten.

• Durch den Einsatz von Vielfahrern auf variablen Strecken können nicht-planbare Situationen (z.B. Warnung vor Hindernissen) mit einer höheren Wahrscheinlich-keit angetroffen werden.

2. Häufigkeit von Fahrten Es wird angeraten, dass die Fahrzeuge möglichst viel im Einsatz sind, um möglichst umfassende Ergebnisse zu erhalten und den Aufwand der technischen Installationen zu gewährleisten.

3. Zweck der Fahrt Für die Erfassung der Akzeptanz ist es hilfreich, wenn die Fahrer die Fahrzeuge der externen Flotte auch in ihrer Freizeit nutzen könnten. Dadurch könnte festgestellt werden, ob durch C2X häufiger gefahren wird. Würden die Fahrten der externen Flot-te ausschließlich dienstlicher Natur sein, wäre die Veränderung der Nutzungshäufig-keit nicht bestimmbar, da die Häufigkeit dienstlicher Fahrten in der Regel nicht frei wählbar ist.

8.3.4 Eignung potenzieller lokaler Partner

Im nachfolgenden Abschnitt wird die Eignung potenzieller lokaler Unternehmen bzw. Partner für die externe Flotte aus der Stadt Frankfurt am Main und der Region Frankfurt betrachtet.

8.3.4.1 Potenzielle lokale Partner in der Stadt Frankfurt am Main Die Stadt Frankfurt am Main und das Land Hessen haben parallel nach geeigneten lokalen Partnern für die externe Flotte gesucht. Es wurden noch keine Gespräche mit den potenziel-len Partnern geführt. Daher ist die Bereitschaft der nachfolgend genannten Institutionen zu einer Zusammenarbeit noch ungeklärt.

Die Kriterien, an denen die Eignung für die externe Flotte gemessen wird, sind:

• Über wie viele Fahrzeuge verfügt der potenzielle Partner?

• Entsprechen die Fahrzeuge den definierten Kriterien (Mittelklassefahrzeuge der simTD-Partner)?

• Wie viele Fahrten legt jedes Fahrzeug durchschnittlich im Versuchsgebiet zurück? Lohnt sich der aufwendige Fahrzeugeinbau?

• Sind die Fahrten zeitlich über den Tag verteilt oder finden sie immer zu derselben Tageszeit statt?

• Sind die Zeiten der Fahrten planbar/verlässlich/regelmäßig?

• Finden die Fahrten (überwiegend) im Versuchsgebiet statt?

• Sind die Fahrziele planbar/verlässlich/regelmäßig?

Generell kommen für das städtische Versuchsgebiet drei Typen von Kandidaten in Frage:

1. Unternehmen der Personenbeförderung oder des Gütertransportes

2. Pendler von ortsansässigen Großunternehmen

3. Dienstfahrzeuge


Tabelle 27 gibt in einer Übersicht eine erste Bewertung potenzieller Kandidaten für die exter-ne Flotte wider. Demnach erscheinen Taxiunternehmen aber auch Hotel-Shuttles und Ku-rierdienste besonders geeignet, vor allem aufgrund der Häufigkeit ihrer Fahrten. Tabelle 27: Bewertung potenzieller Kandidaten für die externe Flotte („-“ negativ zu bewerten bzw. trifft nicht zu, „O“ neutral zu bewerten, „+“ positiv zu bewerten bzw. trifft zu).

Kandidat Typ Anzahl Fahr-zeuge

Fahr-zeugtyp

Anzahl Fahrten / FZ

Zeitliche Aspekte

Räumliche Aspekte

Fahr

zeite

n pl

anba

r?

Tage

szei

tl. A

bde-

ckun

g de

r Fah

rten?

Fahr

ziel

e pl

anba

r?

Räu

ml.

Abd

ecku

ng

Ver

such

sgeb

iet

Kurier-, Express-, Paketdienste

Logistik + - + - + - O

Taxiunternehmen Personen-beförderung

+ + + - + - O

Hotel Shuttles - - + + + + +

Pendler Pendler + O - O - + O

Städtische Dienst-fahrzeuge

Dienstfahrten + + O - - - O

Pflegedienste / Essen auf Rädern

O - + + O O+ +

Poolfahrzeuge Unternehmen

O O O O O O+ +

Pannenservice Fahrzeughersteller

O + + - O - -

8.3.4.2 Vor- und Nachteile potentieller Kandidaten aus dem städtischen Versuchs-gebiet

Die in Tabelle 27 getroffene Einschätzung zur Eignung potenzieller Kandidaten aus dem städtischen Versuchsgebiet wird nachfolgend näher erläutert.

DHL

+ hat Interesse bekundet

− viele Fahrten, aber Fahrzeiten und Fahrtziele unbekannt und nicht steuerbar

− Fahrzeuge entsprechen wahrscheinlich nicht den Anforderungen (Mittelklassewagen, deutscher Hersteller)

− Fahr- und Halteverhalten ist nicht repräsentativ

Taxiunternehmen

+ viele wichtige Standorte im (städtischen) Versuchsgebiet (Hauptbahnhof, Messe Frankfurt, Flughafen, Sachsenhausen, Niederrad)

− viele Fahrten, aber Fahrzeiten und Fahrziele unbekannt und nicht steuerbar


+ Fahrzeuge entsprechen mit hoher Wahrscheinlichkeit den Anforderungen (Mittelklas-sewagen, deutscher Hersteller)


Hotel-Shuttles (zum Flughafen)

+ Hotels, die im Versuchsgebiet liegen und Flughafen-Shuttle rund um die Uhr anbieten

+ Fahren zu jeder Tageszeit, fahren durch das Versuchsgebiet (A5, A3, B43, tlw. durch Niederrad), Ziel (Route) ist bekannt

- Fahrzeuge entsprechen evtl. nicht den Anforderungen (Mittelklassewagen deutscher Hersteller)

Pendler

• Projektpartner: als potentielle Kandidaten:

T-Systems: mit mehreren Standorten in Frankfurt am Main (einer auch im Versuchsgebiet T-Systems Niederrad);

Conti: Unternehmen hat Interesse bekundet, ca. 50 Fahrzeuge

− Ortung und Datenschutzbestimmungen müssen mit vielen Einzelpersonen geklärt werden.

− Fahrziele der Mitarbeiter unbekannt und nicht steuerbar

− Abgesehen von An- und Abreise zum Bürostandort voraussichtlich wenig Fahrten im Versuchsgebiet / Fahrzeug.

− Fahrzeuge entsprechen nur teilweise den Anforderungen (Mittelklassewagen, deut-scher Hersteller)

+ repräsentatives Fahrverhalten zu erwarten

Städtische Dienstfahrzeuge

+ Bis zu 100 Fahrzeuge

+ Fahrzeuge entsprechen mit hoher Wahrscheinlichkeit den Anforderungen (Mittelklas-sewagen, deutscher Hersteller)

− Fahrziel nicht steuerbar, keine Garantie für Fahrten im Versuchsgebiet, fast aus-schließlich Fahrten im Stadtgebiet.


Pflegedienste und Menüservice

+ sind zu jeder Tageszeit im städt. Versuchsgebiet unterwegs

+ Ziele, Routen weitestgehend bekannt, viele Fahrten je Fahrzeug

− halten und parken eventuell rechtswidrig

− Fahrzeuge entsprechen wahrscheinlich nicht den Anforderungen (Mittelklassewagen, deutscher Hersteller)


Unternehmensfuhrparke

+ Im städtischen Versuchsgebiet gibt es Unternehmen mit eigenen Fuhrparken (z.B. aus der Baulogistikbranche). Diese Firmen unterstützen Bauherren und Generalun-ternehmer bei der operativen Durchführung von Baustellen (Ver- und Entsorgungslo-


gistik bis hin zur Baustellenbewachung). Die Mitarbeiter sind daher oft zu den Bau-stellen unterwegs.

+ Ziele, Routen weitestgehend im städtischen Versuchsgebiet. bzw. in Frankfurt/Main.

− Fahrzeuge entsprechen wahrscheinlich nur teilweise den Anforderungen (Mittelklas-sewagen, deutscher Hersteller)


Pannenservice Fahrzeughersteller aus dem Projekt simTD

+ eventuell über Projektpartner leichter zu realisieren

+ Pannenservice liegt nicht im Versuchsgebiet (meist auf der Hanauer Landstraße)

+ Fahrtziel nicht steuerbar, keine Garantie für Fahrten im Versuchsgebiet

- Fahrthäufigkeit schwer kalkulierbar

8.3.4.3 Potenzielle lokale Partner in der Region Frankfurt RheinMain Aus der Region Frankfurt RheinMain sind weitere Unternehmen für die externe Flotte als potenzielle Partner anzusehen. Es kommen sowohl deren Mitarbeiter als Pendler als auch die firmeneigenen Dienstfahrzeuge für die externe Flotte in Betracht. Gespräche oder sonsti-ger Informationsaustausch hat mit den Unternehmen noch nicht stattgefunden. Daher ist die Bereitschaft der Unternehmen für die Teilnahme an der externen Flotte noch ungeklärt.

Grundvoraussetzung für die Eignung der Partner ist das Durchqueren des simTD-Versuchsgebiets und das so häufig wie möglich.

8.3.5 Ideensammlung zur Incentivierung der möglichen Betreiber der externen simTD Flotte

Bei dem simTD-Feldversuch wird die externe Flotte keine Entlohnung im Sinne von Gehalt oder regelmäßigen monetären Zuwendungen bekommen. Es wird aus diesem Grund wichtig sein, dass simTD den Flottenmitgliedern Anreize für eine Teilnahme an der externen Flotte geben kann. Dieses Kapitel beschäftigt sich mit der Frage, wie die Anreize für Fahrzeugflot-tenbetreiber aussehen und realisiert werden könnten.

8.3.5.1 Begriffserklärung: Incentivierung und Vorüberlegungen Incentivierung oder Anreize sind im allgemeinen Geld- oder Sachprämien, Veranstaltungen oder Reisen, die durchgeführt werden, um Kunden oder Einzelpersonen zu einer Tätigkeit zu bewegen. Im Rahmen von simTD wären u.a. folgende Punkte zu diskutieren:

• Was muss eine externer Fahrer/Flottenbetreiber eigentlich für simTD tun? Welche Aufgaben kommen auf die Fahrer der externen Flotte zu?

• Welche Inhalte müssen vor der Teilnahme geschult bzw. eingewiesen werden?

• Worauf lassen sich Fahrer der externen Flotte ein (z.B. Umbauten am Fahrzeug, Fahrzeug fehlt für mehrere Tage dem Flottenbetreiber)?

• Was genau könnte Teilnehmer/Firmen bei simTD besonders interessieren? Was ist der Mehrwert bzw. was kann der Mehrwert für einen Fahrer/Flottenbetreiber sein?


Diese Faktoren sind wichtig, um herauszufinden, auf welche evtl. Komforteinbußen sich ein Fahrer der externen Flotte einstellen muss und was dem Flottenmitglied als Anreiz angebo-ten werden kann. Diese Faktoren werden daher nachfolgend ausführlicher dargestellt.

8.3.5.2 Komforteinbußen vermeiden Zunächst muss es das erklärte Ziel von simTD sein, den Komfort bei der externen Fahrzeug-flotte so wenig wie möglich einzuschränken. Es ist davon auszugehen, dass das Interesse zur Teilnahme an simTD abnimmt, wenn der Flottenbetreiber oder Flottenfahrer zu sehr in seinem Komfort eingeschränkt wird oder wenn im Rahmen von simTD zu oft Zusatztätigkeiten (z.B. Datenaustausch per USB) abverlangt werden. Je mehr Komforteinbußen, desto stärker sinkt die Bereitschaft bei der externen Flotte mitzumachen.

Der erste Schritt, um eine Interessenten an der externen Flotte für simTD zu gewinnen, wäre demnach Komforteinbußen vermeiden:

• Es ist angedacht, die Fahrer in bestimmten Abständen per HMI zu befragen. Maßnahme zur Incentivierung: Fahrer so wenig wie möglich befragen.

• Der Fahrer soll Daten per USB-Stick/Internet manuell an simTD liefern. Maßnahme zur Incentivierung: Den Fahrer in der Flotte nicht mit unnötigen Aufforderungen zur Datenübermittlung belästigen. Versuchen, den Datenaustausch zu automatisieren.

• Die Dachantenne für das Radio wird abgeklemmt, eine Scheibenantenne soll einge-setzt werden. Maßnahme zur Incentivierung: Fahrzeug so wenig wie möglich zerstören, Schaden vermeiden. Fahrer in seinem eigenen Fahrzeug nicht einschränken.

• Die externe Fahrzeugflotte soll Fahrzeuge für Montage/Demontage der Hardware ta-geweise zur Verfügung stellen. Maßnahme zur Incentivierung: Unnötige Standzeiten sowie unnötig lange Fahrten zur Umbauwerkstatt vermeiden. Es muss evtl. angeboten werden, die Fahrzeuge abzuholen und zurückzubringen.

8.3.5.3 Interesse an simTD wecken bzw. Mehrwert für Partner der externen Flotte hervorheben

Nachfolgend wird über klassische Ansätze zur Incentivierung gesprochen, d.h. ein Anreiz soll geschaffen werden, um Interessenten an der externen Flotte zum Mitmachen zu bewegen. Im Folgenden sollen einige Ideen bzw. Vorschläge präsentiert werden.

Idee/Vorschlag 1: Pressemitteilungen (PR) Firmen, die für die externe Flotte ihre Fahrzeuge zur Verfügung stellen, könnten namentlich in Presse bzw. auf der simTD-Webseite genannt werden.

• Voraussetzung: Einen gesonderten Bereich auf der simTD-Webseite einrichten. Bei Pressemitteilungen immer darauf achten, dass Firmen erwähnt werden.

• Vorteil: Ist relativ preiswert zu realisieren.

• Nachteil: Keiner, da relativ einfach und preiswert zu realisieren.


Idee/Vorschlag 2: Einführung der Fahrer/Flottenbetreiber in die simTD-Technologie Man muss den Fahrer oder Flottenbetreiber darüber informieren, was simTD ist und was es genau kann. Möglicherweise könnte die in simTD eingesetzte Technologie wichtig und nütz-lich für Flottenbetreiber und Fahrer sein könnte.

• Voraussetzung: Man muss vor der Versuchsdurchführung den Fahrer bzw. Flotten-betreiber die Wirk- und Bedienweise aller simTD-Funktionen bzw. Anwendungsfälle durch Schulungen oder Schulungsunterlagen vermitteln. Man müsste pro Flottenbe-treiber identifizieren, welche Funktion jeweils besonders wichtig sein könnte und da-mit an die externen Flottenbetreiber und Fahrer herantreten.

• Vorteil: Zukünftige Nutzer des Systems würden bereits an Bord sein.

• Nachteil: Schulungsaufwand für mind. 300 Fahrer. Bei großen Flottenbetreibern ist es vielleicht ratsam, eine Schulung in der jeweiligen Firma durchzuführen.

Idee/Vorschlag 3: Hardwareabgabe nach simTD-Versuch Die Hardware (CCU/HMI/AU) oder Teile der Hardware könnten nach dem Versuch bei der externen Flotte verbleiben. Vielleicht könnte man bereits im Vorfeld identifizieren, wer solche Hardware im Jahr 2011 verwenden oder gebrauchen könnte (z.B. Car2Go/Carsharing). Po-tenzielle Kunden von morgen gewinnen.

• Voraussetzung: Hardware wird vom simTD-Konsortium oder dem Projektträger nicht mehr benötigt. Es muss rechtlich abgeklärt werden, ob Rückbau der Hardware aus-fallen kann.

• Vorteil: Entsorgungskosten entfallen für simTD, potenzielle User/Kunden wären nach Feldversuch bereits an Bord.

• Nachteil: Relativ teuer, weil Hardware für 300 Fahrzeuge abgegeben wird. Man muss die Teilnehmer darauf aufmerksam machen, wozu die Hardware benutzt werden kann. Schulungsaufwand. Rechercheaufwand beim Identifizieren von möglichen Partnern/Firmen, die diese Hardware für ihre Zwecke einsetzen könnten.

Idee/Vorschlag 4: Communitygedanken stärken Für technikaffine Fahrer besonders interessant, um ein Teil eines großen Ganzen zu wer-den. Sehr gut denkbar wäre an bereits bestehende Communities heranzutreten, wie z.B. Open StreetMap, die Geo-Daten benötigen bzw. erstellen.

• Voraussetzung: Man müsste im Konsortium klären, ob der Gedanke einer freien Community Anklang findet. Man müsste identifizieren, wer als möglicher Flottenbe-treiber oder Communitymitglied im simTD-Technologiefeld Interesse haben könnte.

• Vorteil: Je nach Enthusiasmus des Fahrers, wäre auch eine bedingte Steuerung der Fahrer möglich, z.B. eine E-Mail an alle Community-Mitglieder: „Wer Zeit hat, heute um 12:00 Uhr zu xy…fahren“.

• Nachteil: Man müsste offene Schnittstellen anbieten. Bei Veranstaltungen (z.B. „simTD-Abschlussparty“) müsste man auch die Community einladen.

Idee/Vorschlag 5: Offene Schnittstellen anbieten Um die Akzeptanz bei Firmen und Fahrern zu erhöhen, könnte man offene Schnittstellen anbieten. Man könnte Firmen/Fahrern z.B. anbieten, über eine Webseite und einem eigenen


Zugang die eigene Route zu verfolgen. Statistiken über Geschwindigkeit/Verbrauch o.ä. an-bieten. Communities (z.B. Open StreetMap) könnten die erzeugten (eigenen) Datensätze für ihre Karten verwenden. Taxi-/Carsharingunternehmen/Flottenbetreiber könnten ihre Fahr-zeuge in Echtzeit und bequem verfolgen.

• Voraussetzung: Es muss technologisch möglich sein, über einen eigenen Account nur auf die eigenen Datensätze zuzugreifen, die mit einer strikten Nutzungsbedin-gung abgesichert sind.

• Vorteil: Technisch relativ einfach zu implementieren, die Technologie ist vorhanden.

• Nachteil: Rechtliche Rahmenbedingungen müssen geklärt werden (Datenschutz). Firmen/Fahrer müssen alle zustimmen und müssten aufgeklärt werden.

Idee/Vorschlag 6: Tombola Gewinn o.ä. Um einen Anreiz für eine externe Versuchsflotte zu schaffen, könnte man eine Tombola (nach dem simTD-Feldversuch) veranstalten. Als Gewinn könnte man sich z.B. als Preisgel-der die im Feldversuch benutzten PCs/Laptops/Displays vorstellen.

• Voraussetzung: OEMs und alle anderen simTD-Partner müssten sich bereit erklären, Werbeartikel und/oder Preisgelder zu stellen.

• Vorteil: Hohe Akzeptanz bei freiwilligen Tätigkeiten bzw. falls Gewinnchance sehr hoch. Je nach Preisgeld, relativ günstig zu realisieren.

• Nachteil: Ist mit Kosten verbunden, simTD-Konsortium müsste Hardware abgeben.

Idee/Vorschlag 7: Mietwagenflotten an Wochenenden verleihen Es stehen 100 Fahrzeuge der internen Flotte zur Verfügung, falls an Wochenenden keine Versuche gefahren werden. Als Anreiz könnte man die Fahrzeuge an Wochenenden den Fahrern der externen Flotte zur Verfügung stellen. Nach dem Prinzip: „Gb mir bitte deine Daten, du darfst dafür einen BMW X1 für ein Wochenende fahren“.

• Voraussetzung: Interne Flotte und Testgelände sollten am Wochenende zur Verfü-gung stehen und Versuche dürfen auf gar keinen Fall gefährdet werden.

• Vorteil: Preiswert zu realisieren, da Fahrzeuge inkl. simTD-Technologie vorhanden. Falls Datenaustausch oder Wartung bei der externen Flotte ansteht, könnte man die-se parallel durchführen. Die Mietwagenflotte könnte dann am Wochenende auch als externe Flotte arbeiten und weiterhin Daten liefern.

• Nachteil: Klärung rechtlicher und versicherungstechnischer Bedingungen. Erhöhter Verwaltungsaufwand. Samstag/Sonntag muss Versuchsflottenstützpunkt besetzt sein und auch Abnahme durchführen.

Idee/Vorschlag 8: Testgelände nutzen Das Testgelände steht an Wochenenden zur Verfügung, inklusive 100 interne Flottenfahr-zeuge. Man könnte Fahrsicherheitstrainings oder Workshops mit den Fahrzeugen auf dem Testgelände durchführen, organisiert von OEMs oder dem ADAC.

• Voraussetzung: Interne Flotte und Testgelände sollten am Wochenende zur Verfü-gung stehen und Versuche nicht gefährden.


• Vorteil: Preiswert zu realisieren, da Fahrzeuge inkl. simTD-Technologie vorhanden. Falls Datenaustausch oder Wartung bei der externen Flotte ansteht, könnte man die-se parallel durchführen.

• Nachteil: Erhöhter Verwaltungsaufwand. Samstag/Sonntag muss in Versuchsflotten-stützpunkt besetzt sein und man müsste OEMs oder ADAC gewinnen, um diese Workshops anzubieten.

8.4 Anforderungen an Datenauswertung

Da die externe Flotte gegenüber der internen Flotte einige Besonderheiten aufweist, stellen sich hinsichtlich der Datenauswertung erweiterte Anforderungen. Prinzipiell gelten hier eben-falls die Anforderungen, die an die interne Flotte gestellt wurden (siehe Kap. 7.4).

Die Fahrzeuge der externen Flotte können sich sowohl innerhalb als auch außerhalb des Versuchsgebietes frei bewegen. Da die Daten, die außerhalb des Versuchsgebietes gene-riert werden, für die verkehrstechnische Auswertung nicht weiter relevant sind und um das Datenvolumen einzuschränken, das durch das Logging in der IVS entsteht, soll die Auf-zeichnung nach der Überschreitung des Pufferbereichs nach außen – ein genauer Distanz-wert ist hier noch festzulegen – verworfen werden. Bei häufigen Wechseln zwischen Ver-suchs- und Nicht-Versuchsgebiet muss eine entsprechend sinnvolle Lösung gefunden wer-den, um einerseits die Datenmenge nicht unnötig aufzublähen und andererseits die innerhalb des Versuchsgebietes generierten Daten zu schützen. Eine Festlegung von Schwellenwer-ten – zeitlich auf der Verweildauer oder örtlich auf der Länge der Fahrtstrecke basierend – erfolgt im weiteren Projektverlauf von simTD.

Die Auswertung hinsichtlich der verkehrlichen Kenngrößen eines Anwendungsfalls ist bei der externen Flotte wesentlich aufwändiger als bei der internen Flotte. Für das einzelne Fahr-zeug bedeutet dies im Detail, dass zuerst die interessanten Ereignisse identifiziert, diese auf das digitale Straßennetz abgebildet und den entsprechenden kollektiven Verkehrsdaten (De-tektormesswerten, Reisezeiten o.ä.) zugeordnet werden müssen. Der erste dieser Schritte entfällt für die interne Flotte.

Neben diesen rein automatisiert handhabbaren Aspekten ist häufig eine manuelle Interpreta-tion der jeweiligen Situation notwendig. Beispielsweise ist die Fragestellung zu prüfen, ob der jeweilige Anwendungsfall Einfluss auf das geänderte Fahrverhalten hat. Sollten die Fahrzeu-ge der externen Flotte spezielles Fahrverhalten (z.B. in Abhängigkeit von der Flottenzugehö-rigkeit) zeigen, muss dieses in den Daten speziell gekennzeichnet werden. Taxis zeigen bei-spielsweise deutlich unterschiedliches Fahrverhalten, je nachdem, ob der Fahrer nach Fahr-gästen sucht (langsames Fahren oder Anhalten um Fahrgäste aufzunehmen) oder ob Fahr-gäste befördert werden. Aus diesem Grund sollten bei Verwendung von Taxidaten aus-schließlich Fahrten herangezogen werden, bei denen Fahrgäste bereits an Bord sind. Diese Randbedingungen müssen entweder automatisiert über das jeweilige Dispositionssystem erfasst oder manuell durch den Fahrer dokumentiert werden (z.B. durch HMI-Eingaben).

Das jeweilige Fahrverhalten ist auch bei den simTD-Anwendungsfällen zu berücksichtigen: Die Verkehrslage, die mithilfe von Daten von Taxis oder Fahrzeugen von Lieferdiensten er-mittelt wird, sollte nur dann berechnet werden, wenn die Fahrten auch repräsentativ für den umliegenden Verkehr sind.

Grundsätzlich ist bei der Auswertung von Daten der externen Flotte – und hierbei speziell bei der Festlegung der Methoden zur Berechnung der jeweils adressierten Kenngrößen – zu beachten, dass die Menge der Messgrößen im Einzelfall (oder auch im Gesamten) stark ein-geschränkt sein kann. Dies hängt mit der Verfügbarkeit der Messgrößen aus der VAPI zu-sammen, die vermutlich nicht alle CAN-Profile der Flottenfahrzeuge unterstützen wird.


Der Zeitpunkt der Auswertung soll möglichst nah am Durchführungszeitpunkt eines Anwen-dungsfalles liegen. Hierzu ist es nötig, die Daten, die in den Fahrzeugen der externen Flotte aufgezeichnet werden, zeitnah auf dem Loggingdatenserver einzuspielen. Für kleinere Da-tenmengen ist dies sicherlich mittels UMTS möglich. Für größere Datenmengen muss eine entsprechend angepasste Lösung erarbeitet werden.


9 Betreuung der Versuchsfahrer Die für den Versuch angeworbenen Fahrer müssen über die gesamte Versuchszeit hinweg betreut werden. Personen, die bislang nicht in simTD involviert waren, tragen jetzt durch ihr Verhalten in entscheidender Weise zu Erfolg bzw. Misserfolg der Versuche bei. Aus diesem Grund ist es wichtig, dass die Fahrer in das Projekt zumindest soweit eingeführt werden, dass sie sich mit Projektzielen, Fragestellungen und deren Methoden identifizieren können. Darüber hinaus müssen sie in den Ablauf des Feldversuchs insgesamt und die allgemeinen Versuchsbedingungen eingeführt werden. Sie brauchen Informationen zu den Fahrzeugen, die sie fahren sollen, einschließlich der geprüften Funktionen bzw. Anwendungsfälle. Ganz wichtig ist die Aufklärung zu Gefahren und Risiken, die während des Versuchs auf den Fah-rer zukommen können. Rechtlich-regulatorische Rahmenbedingungen (wie z.B. Haftung) sind im Rahmen von simTD weiterhin zu prüfen und zu berücksichtigen.

Daraus ergibt sich die Notwendigkeit von Personal, das die Versuchsfahrer in unterschiedli-chen Fragen betreut: Neben organisatorischen Fragen zur Terminierung, Entlohnung etc. sind das auch Fragen, die den konkreten Versuchsablauf und das Verhalten vor, während und nach der Versuchsfahrt betreffen. In Kap. 10 des vorliegenden Versuchsplans wird bei diesem Personal vom „Operator Mensch“ gesprochen.

Das vorliegende Kapitel beschäftigt sich dementsprechend mit möglichen Inhalten der Fah-rereinweisung und den Anforderungen, die an die Operatoren Mensch gestellt werden.

9.1 Anforderungen an den Trainingsbedarf der Fahrer

9.1.1 Pragmatische Überlegungen zur Fahrereinweisung

Aus methodischer Sicht muss zu Beginn einer Untersuchungsreihe sichergestellt sein, dass die Fahrer sich voll und ganz auf die ihnen gestellte Aufgabe konzentrieren können. Dies bedeutet, die Fahrer müssen mit folgenden Arbeitsabläufen vertraut sein:

• Rekrutierung und Terminierung: Wer ist für mich zuständig? Wo melde ich mich, wenn ich krank bin oder sich an meinen Daten und Angaben etwas geändert hat? Wo melde ich mich, wenn ich am Versuchsgelände angekommen bin? etc.

• Ablauf eines Versuchstags: Wer instruiert mich? Wo bekomme ich das Fahrzeug bzw. den Schlüssel? Wo melde ich mich, wenn unterwegs etwas schief geht? Wo gebe ich Anmerkungen ab? Wo liefere ich sonstige Daten ab?

• Bedienung des Fahrzeugs und des simTD-Systems

• Umgang mit Ausnahmesituationen: Wie verhalte mich im Falle eines Unfalls?

• Schließlich ist es wichtig, die Fahrer so in das Projekt einzuführen, dass ein Zugehö-rigkeitsgefühl vermittelt wird.

Um zu einem optimalen Einsatz und konstruktiven Verhalten der Fahrer am Versuch zu ge-langen, wird empfohlen, den Fahrern eine Einführung in das Projekt zu geben und so das Zugehörigkeitsgefühl zu simTD zu vermitteln.

9.1.2 Empfehlung zur Fahrereinweisung

Die vorausgegangenen Überlegungen führen dazu, dass eine Fahrereinweisung für die Ver-suche sowohl im Versuchsgebiet als auch auf dem Testgelände unumgänglich ist. Obwohl


Gefahren und Risiken auf die Gesundheit der Probanden in der Fahrsimulation keine Aus-wirkungen haben, sind dort ebenso Fahrereinweisungen notwendig, die den entsprechenden aus den Simulationsversuchen resultierenden Anforderungen gerecht werden.

Mögliche Gefahren sowie Verhaltensrichtlinien müssen allen Fahrern in schriftlicher Form ausgehändigt und empfangsbestätigt werden. Darüber hinaus ist es wichtig, dass jeder Fah-rer im Zeitraum von einer Woche vor der ersten Fahrt eine Fahrereinweisung bekommt bzw. ein Training durchläuft. Der Umfang des Trainings sowie die Notwendigkeit, dieses Training regelmäßig aufzufrischen, sind zu diskutieren. Dieses Training umfasst neben einer Kurzdar-stellung von simTD eine Einführung zu den o.g. organisatorischen Punkten, ausdrückliche Hinweise auf mögliche Gefahren und eine Übungsfahrt mit einem simTD-Versuchsfahrzeug. Die einzelnen simTD-Funktionen bzw. -Anwendungsfälle sollten immer zu Beginn einer Ver-suchsfahrt aufgefrischt werden.

Sämtliche Einweisungen, Belehrungen und Trainings sind schriftlich zu dokumentieren. Hier-zu werden geeignete Formulare zur Verfügung gestellt.

9.2 Anforderung an den Operator Mensch

Während der Versuchsdurchführung entspricht der Operator Mensch (siehe Kap. 10) den im experimentellen Arbeiten eingesetzten Versuchsleitern. Die beiden Begriffe werden nachfol-gend synonym verwendet.

Aus den Arbeiten zum Thema Forschungsmethoden (Bortz & Döring, 2006) ist bekannt, dass ein Versuchsleiter trotz technisch gut ausgestatteter und gut durchdachter Versuchsplanung die letzte Instanz für das Gelingen eines Versuchs darstellt. Effekte, die unter dem Begriff „Versuchsleitereffekte“ in die Literatur eingehen, können einen ganzen Datensatz derart be-einflussen, dass er unbrauchbar wird. Unter Versuchsleitereffekten versteht man die Wirkung des Versuchsleiters über sein Verhalten, seine Motivation oder eigene Einstellung zum Ver-such, seine Methode u. a. auf den Probanden, dessen Verhalten und somit das Versuchser-gebnis. Um solche Effekte zu vermeiden, empfiehlt es sich, Operatoren einzustellen, die über entsprechende soziale Fähigkeiten verfügen und diese Fähigkeiten in einem Training zu vertiefen. Die Eigenschaften eines guten Operators Mensch bzw. Versuchsleiters werden nachfolgend dargestellt:

Er muss sich in die Versuchsfragestellung einarbeiten und wenn irgend möglich den Versuchsablauf selbst erleben.

Er muss allen Versuchsfahrern freundlich entgegen treten und eine sympathische Gesprächsatmosphäre schaffen, damit die Fahrer gerne am Versuch teilnehmen, die Instruktion befolgen und Befragungen ernst nehmen. Der Versuchsleiter muss den Namen des Versuchsfahrers kennen. Der Versuchsleiter sollte sich vorstellen.

Der Versuchsleiter muss sich unbedingt an das vorgegebene Versuchsprotokoll hal-ten, auch wenn er oder Versuchsfahrer oder andere Personen anderer Meinung über bestimmte Details sind. Instruktionen müssen in der vorgegebenen Weise vorgetra-gen werden. Sie dürfen nicht eigenmächtig abgewandelt werden. Entsprechende Versuchsmaterialien müssen unbedingt in der vorgegebenen Art und Weise sowie le-serlich ausgefüllt werden.

Müssen aus irgendwelchen fremdbestimmten Gründen Änderungen im Versuchsab-lauf vorgenommen werden, muss der Versuchsleiter mit einem Verantwortlichen Rücksprache halten. Solche Abweichungen und auch sonstige Besonderheiten sind unbedingt zu protokollieren. Ist es akut nicht möglich, einen Verantwortlichen zu kon-taktieren, muss der Versuchsleiter eine Entscheidung im Sinne der Versuchsfrage-


stellung treffen und möglichst schnell umsetzen. Die Sicherheit der Versuchsfahrer steht dabei immer Vordergrund.

Vor allem in Feldversuchen hat man häufig mit technischen Schwierigkeiten oder wetterlichen, verkehrlichen oder sonstigen Unwägbarkeiten umzugehen. Es ist abzu-wägen, ob der Versuch in geplanter Weise stattfinden kann und ob alle Daten aufge-zeichnet werden können. Da aus diesen Gründen die Ausgangsbedingungen nicht immer optimal sind, muss der Versuchsleiter sehr flexibel und in die entsprechenden Rahmenbedingungen eingearbeitet sein.

9.2.1 Beispiele

Gutes bzw. schlechtes Verhalten eines Versuchsleiters soll nachfolgend anhand einiger Bei-spiele demonstriert werden, die aus dem Versuchsalltag des IZVW der Universität Würzburg gegriffen sind.

Der einbestellte Versuchsfahrer sagt nach der Begrüßung zum Versuchsleiter: „Können wir das Ganze ein bisschen schneller machen und ein paar Übungen weglassen? Ich müsste dringend heute noch woanders hin.“

• Schlechtes Verhalten: „Klar, ich denke, dass es ohnehin nicht so lange dauert. Das kriegen wir schon hin.“

• Gutes Verhalten: „ Wann genau müssen Sie denn weg? – Hmh, es ist sehr wichtig, dass wir genügend Zeit haben, alle Fahrten in Ruhe zu absolvieren und eine Nach-besprechung durchzuführen. Deswegen würde ich unseren Termin dann lieber ver-schieben, damit sie die vereinbarte Zeit auch erübrigen können.“

Versuchsfahrer ist während des gesamten Versuchstags sehr unfreundlich zum Versuchslei-ter und nörgelt nur herum.

• Schlechtes Verhalten: Versuchsleiter spricht wenig oder nörgelt zurück. Ist wortkarger als bei den anderen Versuchsfahrern. Lässt sich nervös machen, wird unsicher.

• Gutes Verhalten: Versuchsleiter bleibt durchgehend freundlich, lässt sich nicht vom geplanten Versuchsablauf abbringen, fragt beim Fahrer nach, ob er unzufrieden ist und wenn ja warum. Inhalt dieses Gesprächs wird protokolliert. Ist der Versuchsfahrer nicht kooperativ, muss der Versuch u.U. in Rücksprache mit dem Verantwortlichen abgebrochen werden.

Testfahrzeug springt nicht an.

• Schlechtes Verhalten: Versuchsleiter schickt den Versuchsfahrer nach Hause.

• Gutes Verhalten: Versuchsleiter schickt den Versuchsfahrer in ein nahegelegenes Cafe und verpflegt ihn dort, bittet ihn zunächst zu warten (Die Rechnung wird vom Versuchsleiter/Projekt übernommen). In Rücksprache mit einem Verantwortlichen muss ein neues Fahrzeug beschafft werden. Ist dieses in absehbarer Zeit nicht mög-lich, wird der Versuchsfahrer über das Geschehene informiert und ein neuer Termin vereinbart.

Versuchsfahrt ist bereits seit 1 Stunde in Gang. Am Bildschirm der Messtechnik sieht man ungewöhnliche Werte.

• Schlechtes Verhalten: Versuchsleiter bemerkt dies gar nicht oder bemerkt es und „übersieht“ es.


• Gutes Verhalten: Versuchsleiter spricht in der nächsten Versuchspause mit einem Verantwortlichen, startet das Testsystem neu, kontrolliert, ob überhaupt Daten aufge-zeichnet werden, protokolliert seine Beobachtungen in jedem Fall.

Auf der Teststrecke. 3 Fahrzeuge erzeugen eine Überholsituation. Der Versuchsfahrer traut sich nicht zu, das Fahrmanöver durchzuführen.

• Schlechtes Verhalten: „Das ist wirklich nicht schwer. Geben Sie einfach mehr Gas.“

• Gutes Verhalten: Versuchsleiter gibt dem Versuchsfahrer mehrere Chancen und un-ter Umständen einige Tipps (nur wenn vom Verantwortlichen erlaubt). Wenn sich der Fahrer aber unsicher fühlt, wird das Manöver abgebrochen.

Fahrer fährt immer 120 km/h, obwohl die Instruktion lautet „Fahren Sie zwischen 100 und 110 km/h.“

• Schlechtes Verhalten: Versuchsleiter denkt sich: „Ach, das wird schon nicht so schlimm sein“ und sagt gar nichts.

• Gutes Verhalten: Versuchsleiter erinnert den Fahrer erneut an die Instruktion und in-formiert den Verantwortlichen. Dieser entscheidet, was zu tun ist.

Versuchsfahrer sagt bei der Befragung: „Das ist aber ‘ne blöde Frage!“ Oder „Der ganze Versuch ist doch voll überflüssig. Im letzten ADAC-Heft steht doch schon längst, dass das alles nichts taugt.“

• Schlechtes Verhalten: „Stimmt eigentlich, wir lassen die Frage einfach weg.“ Oder „Das denk ich mir hier auch jeden Tag. Irgendwie ist das Ganze doch Quatsch, naja. Sie kriegen Geld, ich krieg Geld, wir machen einfach das Beste draus.“

• Gutes Verhalten: „Sie haben Recht, manche Fragen sind wirklich schwierig zu be-antworten. Versuchen Sie es aber bitte trotzdem, damit wir alle Daten vollständig ha-ben. Am Ende möchte ich mir gerne die Fragen, mit denen Sie Schwierigkeiten hat-ten, notieren, damit wir unser Material noch verbessern können.“ Oder „Das ist ja in-teressant, dass Sie über das Thema schon gelesen haben. In dieser Studie geht es tatsächlich darum, dass.... Bislang ist aber nicht bekannt, ob.... Sie helfen aber mit diese Technologie zu bewerten, wenn Sie die Aufgaben alle instruktionsgemäß aus-führen und am Ende auf dem Fragebogen unbedingt Ihre Meinung aufschreiben.“

9.2.2 Fazit

Aus diesen Beispielen ergeben sich folgende Anforderungen an den Operator Mensch bzw. an den Versuchsleiter, die bei der Auswahl bzw. des Trainings des entsprechenden Perso-nals zu beachten sind:

Kontaktfähigkeit und soziales Auftreten

• Zugehen auf bekannte und unbekannte Menschen

• Freundlichkeit und Rücksichtnahme

• Schaffen einer angenehmen Gesprächsatmosphäre

• Angenehmes (äußeres) Auftreten, so dass die Versuchsfahrer gerne mit dem Ver-suchsleiter zusammen arbeiten.


Gewissenhaftigkeit

• Sorgfältiger Arbeitsstil

o Versuchsmaterialien müssen alle in der erlernten Art und Weise geführt, be-schriftet und gesichert sein.

• Hohe Zuverlässigkeit

o Der Versuch muss unbedingt in der vorgegebenen Art und Weise durchge-führt werden.

o Notwendig gewordene Abweichungen vom Versuchsplan müssen unbedingt protokolliert werden.

o Besonderheiten während des Versuchs müssen unbedingt protokolliert wer-den.

o Der Versuchsleiter muss in jedem Fall pünktlich sein und terminliche Schwie-rigkeiten sofort mitteilen.

Flexibilität

• Fähigkeit, sich auf unvorhergesehene Situationen einzustellen.

• Ungewissheit tolerieren Handlungsorientierung

• Im entsprechenden Fall Entscheidungen im Sinne des Versuchs und der Sicherheit der Versuchsfahrer treffen.

• Rasche Umsetzung dieser Entscheidung im Sinne des Versuchs und der Sicherheit der Versuchsfahrer.

Selbstbewusstsein • Unabhängigkeit von den Urteilen anderer

• Selbstvertrauen bezüglich der eigenen Fähigkeiten (vgl. Handlungsorientierung)

Die in diesem Kapitel diskutierten Anforderungen an die Operatoren Mensch müssen dem Gemeinsamen Unterauftragnehmer (GUA) für die Versuchsdurchführung in AP42 vorliegen und dort in die Auswahl des entsprechenden Personals eingehen. Aus diesem Grund wird das D41.1 „Versuchsplan 1.0“ dem GUA zur Verfügung gestellt.


10 Zusammenspiel simTD-Versuchszentrale und Versuchsflot-tenstützpunkt

Für die im Rahmen von TP4 durchgeführten Versuche sind die Örtlichkeiten simTD-Versuchszentrale und Versuchsflottenstützpunkt räumlich voneinander abzugrenzen:

• Neben der simTD-Versuchszentrale, die räumlich auf dem Gelände der Verkehrs-zentrale Hessen angesiedelt ist und in der v.a. die Versuchskoordination stattfindet,

• ist ein Versuchsflottenstützpunkt erforderlich, in dem die Versuchsorganisation lo-kalisiert ist.

Um die Suche nach geeigneten Flächen für einen solchen Versuchsflottenstützpunkt zu un-terstützen, wurden vom TP4 Leitungsteam die entsprechenden Anforderungen näher defi-niert. Die nachfolgenden Ergebnisse dokumentieren den Arbeitsstand von März 2010.

10.1 Abgrenzung simTD-Versuchszentrale und Versuchsflottenstütz-punkt

In der simTD-Versuchszentrale erfolgt die Versuchskoordination, das heißt, hier werden alle Vorüberlegungen und praktischen Begleitungen der Versuche getätigt, um möglichst optima-le Daten für die Versuchsauswertung zu erhalten. Das Personal entscheidet zusammen mit einem dort ansässigen „Projektvertreter simTD“, welche Szenarien gefahren werden und ver-folgt den Versuchsablauf aus technischer und verkehrlicher Perspektive. Hierzu zählen auch die Prüfung der Monitoringdaten während des Versuches und die letztliche Entscheidung über das erfolgreiche Abschließen eines Versuches.

Im Versuchsflottenstützpunkt findet die praktische Organisation der Versuche vor Ort statt. Hier wird die Versuchsplanung in die Versuchsdurchführung umgesetzt. Das heißt, Personal- und Fahrzeugeinsatz wird geplant und organisiert, Fahrzeuge werden gepflegt und auf Ein-satzbereitschaft geprüft, Fahrer werden empfangen und eingewiesen, der Versuchsablauf wird beobachtet, Kontakt zu den Fahrern wird während des Versuches gehalten und nach Beendigung des Versuches werden hier die Messdaten ausgelesen.

simTD-Versuchszentrale und Versuchsflottenstützpunkt stehen in engem Kontakt zueinander. Der Kontakt zum „Projektvertreter simTD“ findet vor allem über die simTD-Versuchszentrale statt, den Kontakt zu den Versuchsfahrern hält ausschließlich der Versuchsflottenstützpunkt.

Die detaillierte Aufgabenverteilung ist Kap. 10.3 zu entnehmen.

10.2 Personal und Organigramm

Die Aufgaben und Abhängigkeiten der Personengruppen im Versuchsflottenstützpunkt und der simTD-Versuchszentrale sind in Abbildung 47 dargestellt.

An übergeordneter Position steht der „Manager Versuchsdurchführung“, der sein Büro vo-raussichtlich in der simTD-Versuchszentrale haben wird. Er hat gesamtplanerische und koor-dinierende Aufgaben und ist das Bindeglied zwischen dem „Projektvertreter simTD“, dem Ver-suchsflottenstützpunkt und der simTD-Versuchszentrale.

Der „Leiter simTD-Versuchszentrale“ hält den direkten Kontakt zum Versuchsflottenstützpunkt und dem „Manager Versuchsdurchführung“, er hat die Verantwortung für die erfolgreiche technische und verkehrliche Abwicklung der Versuche. Ihm arbeiten die „Operatoren Ver-kehr“ zu, die während des Versuches den Status und die Verkehrslage überprüfen und Zwi-


schenfälle bzw. Abweichungen vom Drehbuch protokollieren. Die „Operatoren Verkehr“ hal-ten engen Kontakt zu den Operatoren der VZH (Verkehrszentrale Hessen) bzw. der IGLZ (Integrierte Gesamtverkehrsleitzentrale) der Stadt Frankfurt/Main, die im gleichen Raum bzw. in ihrer ITS Central Station sitzen. Ebenfalls in der simTD-Versuchszentrale anwesend sind die „Projektvertreter simTD“, die die Umsetzung der Drehbücher und die daraus resultieren-den Versuchsdaten hinsichtlich ihrer Verwendbarkeit prüfen und ggfs. Drehbücher wiederho-len lassen.

Abbildung 47. Personal und Organigramm für Versuchsflottenstützpunkt und simTD-Versuchszentrale.

Die Verantwortung für die organisatorische Abwicklung der Versuche hat der „Leiter Ver-suchsflottenstützpunkt“. Er plant die praktische Umsetzung der Versuche und koordiniert den hierfür erforderlichen Personal- und Fahrzeugeinsatz. Er wird von verschiedenen Operatoren unterstützt. Die sog. „Operatoren Planung“ und „Operatoren Mensch“ können physisch die-selben Personen sein, die Unterscheidung wird gemäß ihrer Tätigkeit wie folgt getroffen:

• Die „Operatoren Planung“ setzen die Versuchsplanung um, das heißt sie lesen zu-nächst das Szenario und die Drehbücher, suchen dann geeignetes Fahrerpersonal aus, prüfen die Umstände im Versuchsgebiet zum Versuchszeitpunkt (Verkehrslage, Baustellen, Wetter etc.), organisieren und prüfen die Fahrbereitschaft der erforderli-chen Fahrzeuge und bereiten alles für die Fahrereinweisung vor.

• Sobald der eigentliche Versuch beginnt, haben die „Operatoren Mensch“ die Aufga-be, die Fahrer zu begrüßen und einzuweisen, den Versuch zu starten und mögliche Zwischenfälle zu dokumentieren. Nach Beendigung des Versuches überprüfen sie den erfolgreichen Abschluss und melden diesen dem „Leiter Versuchsflottenstütz-punkt“.

• Der „Operator Technik“ ist für alle technischen Fragestellungen rund um das Fahr-zeug und die Fahrzeugeinbauten zuständig. Er entscheidet, ob technische Probleme vor Ort beseitigt werden können oder ob Fahrzeuge/Komponenten ausgetauscht werden müssen. Ihm arbeitet eine noch nicht festgelegte Anzahl an „technischen Hilfskräften“ zu.

Das Sekretariat ist für alle Arten von Bürotätigkeiten zuständig. Es empfängt die Fahrer, re-gistriert sie und gibt Fahrzeugschlüssel und Papiere aus. Während die Fahrer unterwegs


sind, kann das Sekretariat Fahrerunterlagen ausdrucken, kopieren und auslegen, und die Fahrer für zukünftige Versuche organisieren.

10.3 Aufgabenverteilung

Nachfolgende Tabelle 28 stellt dar, welche Aufgaben im Versuchsflottenstützpunkt und in der simTD-Versuchszentrale welcher Personalgruppe zugeordnet sind. Sie gibt den Arbeitsstand vom März 2010 wider.


Tabelle 28: Zuordnung der Aufgaben zum Personal (Stand: März 2010).

Versuchsflottenstützpunkt simTD Versuchszentrale

Aufgaben

Leiter Flotten

stützpun

kt

Ope

rator Planun

g

Ope

rator Men

sch

Ope

rator Technik

Sekretariat/ Verwaltung

technische

Hilfskräfte

Manager

Versuchsdurchführun

g

Leiter ITS Ce

ntral Staion

Ope

rator Verkehr

VZH

‐& IG

LZ Ope

rtoren

TP 4 Team

Konsolidierungsgrupp

e

Einw

eisungsleiter

Versuchsplanung

Erstellung der Drehbücher und Notfalldrehbücher 1 x (x)Planung der Versuchsumsetzung, Grobplanung x x

Konzeption Fahrereinweisung, Definition von Anforderungen 2 xpraktische Umsetzung Fahrereinweisung (Methodik) x xDurchführung Fahrereinweisung x

Konzeption Versuchsleitertraining 3 x

Durchführung Versuchsleitertraining 3 x

Umsetzung der Versuchsplanung

Wöchentliche Vorplanung, Einteilung der Versuche auf Termine x

Vorauswahl an Versuchsfahrern (Personen), Definition der

Anforderugnen an die Versuchsfahrer 4x (x)

Vorbereitung des Versuchs: Organisation von zu erledigenden Aufgaben (am Tag vorher)

x

Praktische Durchführung der Versuchepraktische / inhaltliche Vorbereitung des Versuches am Tag vorher. Drehbuch lesen, Planung & Planungsänderungen, Prüfung der infrastrukturellen Voraussetzungen

x

Anmeldepunkt für Versuchsfahrer 5 xVerwaltung von Fahrzeugsschlüsseln und ‐unterlagen xPrüfen, ob Unterlagen vorhanden, Vorbereitung abgeschlossen xPrüfen, ob Rahmenbedingungen für Versuch erfüllt sind xPrüfen, ob alle Fahrzeuge betriebsbereit sind x xmorgendliche Lagebesprechung x xBegrüßung/Instruktion der Versuchsfahrer xStart/Abschluss Drehbuch (Startschuss) x

Wechsel zwischen Drehbüchern 6 xStart Versuch (nach Freigabe durch Manager Versuchsdurchführung)

x

Protokollierung von Zwischenfällen, Abweichungen von Drehbuch

x x

verkehrliches Monitoring des Versuchs mit kontinuierlicher Überprüfung des Status

x (x)

Prüfung der Monitoringdaten während des Versuchs 7 x xPrüfung der Loggingdaten nach dem Versuch xPlausibilitätsprüfung der Loggingdaten möglichst zeitnah nach

dem Versuch 8x

Prüfung über erfolgreiches Abschließen eines Drehbuchs (und

Weiterleitung der Information an Verantwortlichen) 9x x x x

Entscheidung: Erfolgreiche Durchführung bzw. Forderung nach Wiederholung eines Drehbuchs

x x x x

Terminabsprache Team Flottenstützpunkt / ITS Central Staion x x


Versuchsflottenstützpunkt simTD Versuchszentrale

Aufgaben

Leiter Flotten

stützpun

kt

Ope

rator Planun

g

Ope

rator Men

sch

Ope

rator Technik

Sekretariat/ Verwaltung

technische

Hilfskräfte

Manager

Versuchsdurchführun

g

Leiter ITS Ce

ntral Staion

Ope

rator Verkehr

VZH

‐& IG

LZ Ope

rtoren

TP 4 Team

Konsolidierungsgrupp

e

Einw

eisungsleiter

Terminabsprache Versuchsfahrer xBei Ausfall von Versuchsfahrern: Suche nach weiteren Versuchsfahrern

x

Absage des Versuchs xUnterstützende Tätigkeiten x xKopieren von Fahrerunterlagen (Kurzinformationen, Fragebögen etc.)

x

Austeilen von Materialien xAuslegen von Material in Versuchsfahrzeuge xPRFührung von Besuchergruppen x x x xBetreuung der Pressebesucher x x x x

Flotte

Tanken xsofortige Durchführung kleinerer Raparaturen xPflege der Fahrzeuge (Waschen, Reifendruck etc.) xStellen von Ersatzfahrzeugen => MietwagenfirmaAuslesen der Daten (falls erforderlich) x

Legende:Hauptverantwortung für Tätigkeit xunterstützend tätig (x)

1 AP 41 mit Unterstützung GUA. Teil des LV für GUA

3 Würzburg4 mind. 1 Woche vorher5 Chipkarte?6 Spontaner Wechsel zwischen Drehbüchern z.B. bei Stau7 Monitoring (Status Fahrzeuge, nicht Daten zur Versuchsauswertung). Unklar ob Funktionenstatus während des Versuches geprüft wird8 Automatisierte Kurzauswertung durch München9 Bestätigung im Testablaufplanungstool

2 Anforderung und Ziel des Fahrertrainings (unter Berücksichtigung des Rechtsgutachtens), HMI Bedienung trainieren, Manöver, Trainingsprozess. Computersimulation oder Training im FZ?

10.4 Anforderungen an den Versuchsflottenstützpunkt

Die simTD-Versuchszentrale wurde auf dem Gelände der Verkehrszentrale Hessen bereits realisiert, für den Versuchsflottenstützpunkt wird noch nach einer geeigneten Fläche ge-sucht. Um die Flächen-Recherche zu konkretisieren, wurden die Anforderungen an Größe und Ausstattung der Freiflächen und Gebäude des Versuchsflottenstützpunktes definiert.

10.4.1 Räumliche Ausmaße des Versuchsflottenstützpunktes

Die in Tabelle 29 gelisteten Größenanforderungen für die Büros sind abgeleitet aus DIN 4543-1 (1994), die Größenanforderungen an den Schulungsraum sind Erfahrungswerte von Architekten bezüglich Versammlungsstätten.


Tabelle 29: Übersicht über räumliche Ausmaße des Versuchsflottenstützpunktes.

Was Größe (ca.)

Büro Leiter Versuchsflottenstützpunkt 8 m²

Sekretariat und Empfang. max. 4 Arbeitsplätze (Counter / Theke) ca. 2 Container 32 m²

Arbeitsplatz Operator Technik: 1 Arbeitsplatz 8 m²

1 Raum mit Arbeitsplätzen für Operatoren Mensch (max. 5 Personen gleichzeitig; angesetzt ist 1 Operator/20 Fahrer)

8m² * 4 Arbeitsplätze (+1 Notarbeitsplatz) = ca. 2 Container

32 m²

1 Raum mit Besprechungstisch für ca. 8 Operatoren Planung (zur Vorbereitung und Besprechung der Versuchsdurchführung) 1 Container

16 m²

1 Aufenthaltsraum für das Personal des Versuchsflottenstützpunktes 16 m²

1 Schulungsraum für Fahrer => 50 Personen mal 1,5 qm = 75 m²

Wenn Schulungshalle, dann könnte diese als Unterstand für Wartung der Fahrzeuge parallel genutzt werden (z.B. 200 m²)

WCs Damen und Herren = 1 Sanitärcontainer 16m²

Zu klären ist, ob die Fahrzeuge der internen Flotte durch Wachpersonal sporadisch oder permanent bewacht werden müssen. Dies ist von der Lage und Ausstattung des Versuchs-flottenstützpunkts abhängig und kann daher noch nicht abschließend geklärt werden. In die-sem Zusammenhang ist auch zu klären, ob das Wachpersonal einen eigenen Aufenthalts-container braucht. Dies ist vor allem vom zeitlichen Umfang der nächtlichen Bewachung ab-hängig. Jedenfalls braucht das Wachpersonal Zutritt zu den Toiletten, ohne die übrigen Be-reiche des Versuchsflottenstützpunkts betreten zu können (dies bedeutet, entweder eine zusätzliche Sicherheitstür im Gang einzubauen oder alle Büros abends abzuschließen).

Zusammenfassend ergibt sich somit:

• Insgesamt sind ca. 112 m² Bürofläche, ca. 16 m² Sanitärfläche und ca. 75 m² Schu-lungsfläche erforderlich.

• Das entspricht 7 Bürocontainern (davon einer mit Küchenzeile/Spüle), 1 Sanitärcon-tainer und 1 Schulungs- (und ggfs. Fahrzeugwartungs-) halle/-zelt/ -container.

10.4.2 Ausstattung des Versuchsflottenstützpunktes

Nachfolgende Tabelle 30 und Tabelle 31 zeigen die erforderlichen Ausstattungsmerkmale sowohl bezüglich des Mobiliars als auch bezüglich der technischen Ausstattung des Ver-suchsflottenstützpunkts. Es ist zu beachten, dass diese Listen den momentanen Planungs-stand darstellen und in Zusammenarbeit mit dem GUA weiter konkretisiert werden müssen.


Tabelle 30: Technische Büroausstattung Versuchsflottenstützpunkt (Stand: März 2010).

Technische Ausstattung Für wen?

1 Laptop/PC Chef Versuchsflottenstützpunkt

4 Laptops/PCs 1 leistungsfähiger Drucker und Kopierer

Empfang/Sekretariat

1 Laptop/PC Operator Technik u.a. zum Datenauslesen

5 Laptops/PCs Operatoren Mensch

1 Laptop Operatoren Planung im Besprechungsraum bzw. zur Einweisung der Versuchsfahrer

1 leistungsfähiger Drucker (bis zu 4000 Aus-drucke/Tag könnten erforderlich sein)

Empfang/Sekretariat

12 Telefone oder Handys Chef Versuchsflottenstützpunkt, Empfang/ Sekretariat, Operatoren

Ca. 4 große Fernseher Zur Anzeige von Versuchsanweisungen (Be-ginn Versuch XY); um Filme laufen zu lassen

1 Beamer und 1 Leinwand (bei Trennung/Unterteilung der Versuchs-räume evtl. auch je 2 erforderlich)

Einweisung Versuchsfahrer

10.4.3 Anforderungen an den Parkplatz

Parkmöglichkeiten für ca. 250 Fahrzeuge (100 Parkplätze für simTD-Fahrzeuge, 140 Park-plätze für Privatfahrzeuge der Versuchsfahrer und Mitarbeiter des Versuchsflottenstützpunk-tes sowie für Besucher)

250 * 25m² Parkfläche, befestigt, markiert & nummeriert, beleuchtet 6250 m² Ggfs. nächtlicher Wachdienst auf dem Gelände

10.4.4 Geeignete Flächen

Die Suche nach geeigneten Flächen ist noch nicht abgeschlossen (Stand: März 2010). Die Eignung richtet sich nach folgenden Kriterien:

• Größe mind. 7000 m²

• In der Nähe des Versuchsgebietes und möglichst nah an der simTD-Versuchszentrale

• Zentral, gute Erreichbarkeit mit öffentlichen Verkehrsmitteln

• Planungssicherheit wünschenswert

• Möglichst geringer Mietpreis, geringe Erschließungskosten

• Möglichst befestigte Fläche, Umzäunung und Beleuchtung wünschenswert


Tabelle 31: Mobiliar Versuchsflottenstützpunkt (Stand: März 2010).

Mobiliar Für wen?

1 Schreibtisch Chef Versuchsflottenstützpunkt

2-4 Schreibtische und Theke Sekretariat

1 Schreibtisch Operator Technik

5 Schreibtische Operatoren Mensch

1 großer Besprechungstisch (für ca. 10 Per-sonen)

Operatoren Planung + 2 Personen von Kon-solidierungsgruppe, Chef Versuchsflotten-stützpunkt o.ä.

1 Tisch (für ca. 8 Personen) Aufenthaltsraum Mitarbeiter Versuchsflotten-stützpunkt

1 Kaffeemaschine Mitarbeiter Versuchsflottenstützpunkt

1 Mikrowelle Mitarbeiter Versuchsflottenstützpunkt

1 Kühlschrank Mitarbeiter Versuchsflottenstützpunkt

1 Warmgetränkeautomat Fahrer

1 Kaltgetränkeautomat Fahrer

1 Süßwarenautomat Fahrer

Bürostühle (1+4+5 = 10) Operatoren, Sekretariat/ Empfang

Sonstige Stühle (10 + 8 + 25) Besprechungstisch, Tisch Aufenthaltsraum Mitarbeiter, Versuchsfahrer

1 Schrank mit abschließbaren Fächern Für Wertsachen Personal

2 abschließbare Schränke 1 für sensible Unterlagen, 1 für Büromaterial

5 Regale 3 für Empfang; 2 für Operatoren Planung

Lampen und Beleuchtung Sämtliche Arbeitsplätze und Empfangsbereich

1 Unterstand ggfs. Werkzeugsatz Technische Hilfskräfte

12 Mülleimer, 1 Aschenbecher für draußen Alle

Schlüsselschrank oder Safe Für Fahrzeugschlüssel

10.4.5 Bauliche Varianten für den Versuchsflottenstützpunkt

Da unklar ist, ob sich ein geeignetes Gelände mit ausreichend großer Parkplatzfläche und voll funktionsfähigen Büroflächen finden lässt, muss zum Planungsstand (Stand: März 2010) davon ausgegangen werden, dass die Gebäude gestellt werden müssen. Für einen Zeitraum von nur 7 Monaten kommen hierfür nur Container bzw. Zelthallen in Frage. Gegebenenfalls könnte aber die Fahrereinweisung (siehe Kap. 9) in reaktivierten Hallen auf dem Gelände stattfinden.

Zwei Varianten werden weiter untersucht:

a. Ausschließlich Container sowohl für die Büroräume als auch für die Fahrerschulung: Vorteil dieser Variante ist, dass der Container-Raum, in dem die Fahrerschulung stattfindet, flexibel genutzt werden kann, wenn z.B. ein betreuungsintensiver Versuch stattfindet und mehr als 5 Operatoren Mensch zur Versuchsbegleitung erforderlich


sind. Auch können sich die Fahrer in diesem (beheizten) Raum aufhalten, falls es zu Verzögerungen des Versuchsbeginns kommt. Nachteil ist, dass die Fahrzeugwartung entweder im Freien stattfinden muss, oder ein weiteres Gebäude hierfür errichtet werden muss.

b. Container für die Büroräume und eine Zelthalle, in der sowohl die Fahrerschulung stattfindet als auch Fahrzeuge gewartet werden können: Die überdachte Wartungsmöglichkeit ist der wesentliche Vorteil dieser Lösung, die Halle wäre jedoch nur bedingt geeignet, um hier temporäre Büroarbeitsplätze für Operatoren einzurichten. Auch als Aufenthaltsbereich für die Fahrer wäre sie wahr-scheinlich weniger attraktiv.

10.4.6 Weiteres Vorgehen für Auswahl des Versuchsflottenstützpunkts

Die Anforderungen an den Versuchsflottenstützpunkt wurden vom TP4-Leitungsteam auf Basis des derzeitigen Projektstandes (Stand: März 2010) definiert. Auch wurde bereits Kon-takt mit Container- und Zeltvermietungsfirmen aufgenommen, um nähere Informationen zu Grenzen und Möglichkeiten der Gebäude zu erfragen (z.B. Heizung, Kühlung, Fundamente, Rolltore für Fahrzeuge, Mieten eingerichteter Container und ähnliche Detailfragen).

Die größte Herausforderung ist jedoch, geeignete Flächen zu finden. Das TP4 Leitungsteam hat bereits eine Liste potenzieller Flächen zusammengestellt. Die Verkehrszentrale Hessen hat sich dazu bereit erklärt, Kontakt mit Eigentümern großer Flächen aufzunehmen und die Konditionen mit den Eigentümern zu verhandeln. In Zusammenarbeit mit dem Gemeinsamen Unterauftragnehmer für die Versuchsdurchführung (AP42) wird die Planung für den Ver-suchsflottenstützpunkt weiter detailliert.


11 Versuchsdatenaufzeichnung und -übertragung

11.1 Versuchsdatenaufzeichnung

Das Logging in simTD sammelt Daten in allen beteiligten Systemen: ICS, IRS und IVS – bei den beiden letzteren auch in beiden Untereinheiten Application Unit und Central Communi-cation Unit. Zentral verantwortlich für die lokale Aufzeichnung ist das OSGI Bundle simTDLogging, das in angepassten Versionen auf dem Application-Server der ICS, auf der IRS-AU und IVS-AU laufen wird. Dort werden auf den Systemen vor Ort die Logdateien er-stellt, die letztendlich auf dem Testdatenserver gespeichert werden müssen. Grundsätzlich basiert der gesamte Logdatenbestand auf Dateien. Vom SimTDLogging werden ASCII-Textdateien erstellt, wobei jede Zeile ein Log enthält und die Informationen jedes Logs kom-masepariert sind. Aufgrund der technischen Gegebenheiten wird auf den CCUs eine Biblio-thek (Logging_stub) verwendet, um von dort Logs an das SimTDLogging Bundle auf den korrespondierenden AUs weiterzuleiten. Diese C-Bibliothek dient nur zur Weiterleitung der Logs an die eigentliche Informationen verarbeitende und speichernde Einheit auf der AU, das SimTDLogging Bundle.

11.2 Versuchsdatenübertragung

Die OSGI-Bundles auf IRS, IVS und ICS speichern ihre gepackten Logdateien lokal in einem Verzeichnis und warten auf einen Befehl, die Daten zum Testdatenserver in der ICS zu über-tragen, der die Logfiles annimmt, verifiziert und geordnet abspeichert. Die Dateien werden zuerst im hochverfügbaren, aber mit wenig Speicherplatz ausgestatteten SAN (Datenspei-cher) gepuffert. Von hier werden sie direkt an die Verantwortlichen für die Auswertung, von denen jeder eine komplette Kopie der gesamten Rohdaten bei sich lokal vorhalten wird, aus-geliefert.

• Der Übertragungsweg für die Logdaten des ICS Application Server ist das lokale Netzwerk.

• Die Logdaten aus der IRS werden über deren Backbone übertragen, je nach Typ ist das Glasfaser oder Mobilfunk, das verwendete Verfahren ist aber für das Logging transparent.

• Auf der IVS gibt es drei theoretische Übertragungswege: USB-Stick, WLAN und Mo-bilfunk. Aktueller Diskussionsstand (Stand: März 2010) ist die wahrscheinliche Ver-wendung von USB-Sticks, da die große erwartete Datenmenge nicht über Funk ab-gezogen werden kann.

Derzeit ist ein Verfahren implementiert, das automatisch an der IVS AU angeschlossene USB-Sticks erkennt. Dafür läuft im simTDLogging Bundle ein Thread, der in konfigurierbaren Abständen das System nach neu gemounteten Laufwerken untersucht. Das bedeutet, dass einerseits Laufwerke vom Betriebssystem automatisch gemountet werden müssen und dass der Fahrer durch Einstecken eines beliebigen Speichermediums an den USB-Port die Logs abziehen kann. Für die Übertragung werden die Logs verschlüsselt, eine Prüfsumme wird erstellt und die Logs und Prüfsummen werden auf den USB-Stick kopiert. Abschließend wird ein Signalton ausgegeben. Ob zusätzlich ein Fortschrittsbalken auf dem HMI angezeigt wird, ist noch nicht abschließend geklärt. Die Tatsache, dass der Kopiervorgang durch Anstecken eines Speichermediums getriggert wird, ist der Tatsache geschuldet, dass möglichst wenig Interaktion und einfaches Handling gefordert war. Wenn gewünscht, könnte man die USB-Sticks zur Datenübertragung dadurch identifizierbar machen, dass sie im Wurzelverzeichnis ein leeres File „.simtd“ enthalten.


Die Logs werden auf der IVS solange vorgehalten, bis eine Meldung empfangen wird, dass sie erfolgreich zum Server übertragen worden sind. Die USB-Sticks müssen also zu einem Netzwerk transportiert werden, in dem der Testdatenserver verfügbar ist. Das könnte mögli-cherweise das Internet sein, viel wahrscheinlicher aber ist es das lokale Netzwerk der ITS Central Station (ICS). Hier sollten dann PCs mit der Versuchsdatenannahme-Software lau-fen. Diese erkennt ebenfalls automatisch eingesteckte USB-Sticks, verifiziert und entschlüs-selt die Logdaten und hinterlegt sie in der definierten Ordnerstruktur auf dem Fileserver. Dann wird ein Löschkommando generiert (serialisiertes Java-Objekt, das alle erfolgreich übertragenen Dateinamen, die eindeutig sind, enthält) und auf dem USB-Stick verschlüsselt hinterlegt. Beim nächsten Anstecken des USB-Sticks an die VAU führt das dort entschlüssel-te Löschkommando zum Löschen der erfolgreich übertragenen Daten und verhindert damit das Überlaufen der Festplatte. Daten, die z.B. aufgrund von Bitfehlern korrupt waren und damit nicht erfolgreich übertragen wurden, werden so nicht gelöscht und können damit er-neut übertragen werden. Das erfordert, dass zu jedem Fahrzeug ein USB-Stick gehört und diese nicht vertauscht werden dürfen, damit die Löschkommandos entsprechend ankommen. Die Verschlüsselung ist Teil des Sicherheitskonzepts und gewährleistet zum Beispiel, dass auch die Fahrer der externen Flotte die Daten abziehen können, ohne sie tatsächlich ausle-sen zu können. Es wird ein symmetrisches Verfahren eingesetzt, was den Aufwand gering hält. Jede Einheit kennt dafür eine Passphrase bzw. der Testdatenserver eine Liste aller Passphrasen.

Die Übertragung der Daten von IRS und ICS kann nicht über einen USB-Stick durchgeführt werden und erfolgt über die vorhandenen Netzwerke. Dies wird keine weitere Interaktion durch die Versuchsleitung erfordern, als in der Versuchsteuerung den aktuellen Status auf „nicht im Versuch“ setzen. Die Netzwerke sollen zur Versuchszeit nicht durch Logdatenüber-tragung belastet werden, also geschieht diese nur in Zeiträumen, in denen keine Versuche stattfinden.

11.3 Logprofile

Das SimTDLogging wird nicht frei konfigurierbar sein, sondern über eine feste Menge von Profilen verfügen. Diese Profile können nur die Subscription-Mechanismen steuern und nicht die Datenaufzeichnung der Applikationen. Zurzeit sind die über ein Profil konfigurierbaren Quellen die VAPI, die Umfeldtabelle, der CommunicationClient und Bundle-Informationen aus dem OSGI-Framework. Diese Profile werden nach der Definition der zu loggenden Messgrößen in den Drehbüchern und aus den Anforderungen der Tests bestimmt.

Ziel ist es, eine handhabbare Menge von Profilen zu haben, die in den meisten Fällen genau das abdecken was gefordert ist, in wenigen Fällen mehr loggen als gefordert ist, aber nie weniger. Ziel ist es auch hier, für die Auswertung eine übersichtliche Menge an Logkonfigu-rationen zu haben. Diese Profile werden von der TU Berlin erstellt, sobald die Drehbücher die geforderten Messgrößen enthalten. Diese Profile werden im Bundle enthalten sein und können mit der Übergabe der Profil-ID gesetzt werden.

11.4 Nachlaufzeit

Die Nachlaufzeit der IVS ist ein wichtiger Parameter im Loggingkonzept, da Daten nicht wäh-rend der Laufzeit der Versuche übertragen werden sollen. Egal ob per USB-Stick oder draht-los, das Fahrzeug wird dann in der Regel stehen und ausgeschaltet sein. Der Systemmana-ger wird die vom Logging präferierte Möglichkeit bieten, die Abschaltung von AU und CCU zu verzögern, bis entweder kein Strom mehr da ist oder die Daten übertragen worden sind.


Diese Variante garantiert nicht, dass die technisch mögliche Nachlaufzeit lang genug ist, um alle aktuellen Logs zu übertragen. Falls der Zustand konstant ist und täglich mehr Logfiles entstehen, als übertragen werden können, wird bei einer kritischen Speicherplatzverfügbar-keit dies über das Monitoring mitgeteilt. Bei aufgebrauchtem Speicherplatz können keine neuen Logfiles erstellt werden, das SimTDLogging würde damit nicht mehr seine Funktion erfüllen.

11.5 Monitoring

Diese Beschreibung des Monitoring bezieht sich nur auf das Monitoring der IVS, das von der TU Berlin entwickelt wird. Die IRS wird von einer Softwarekomponente der HTW überwacht.

Zentraler Bestandteil der Definition des Monitoring sind sog. Messpunkte. Messpunkte sind Objekte, die neben einer Messgröße einen Schwellenwert, einen Vergleichsoperator, einen Reduktionstyp, eine Wichtigkeit und eine Beschreibung enthalten. Angelegt werden diese Objekte ebenfalls in der Messgrößen-DB.

Auf der VAU wird bei einem Datenupdate der betreffenden Messgröße eines Messpunktes zuerst der Vergleich (hier wird der definierte Vergleichsoperator benutzt) des Wertes mit dem Schwellenwert durchgeführt. Falls dieser Vergleich "true" ergibt, wird dieser Wert selbst oder das Ergebnis (also nur die Tatsache, dass der Vergleich positiv war) zu den anderen noch Nicht-Versendeten abgelegt. Dies lässt sich über den Reduktionstyp konfigurieren. Für die Wahl ist zu berücksichtigen, dass das Monitoring eine Standardpaketgröße nicht überschrei-ten wird und dafür die unwichtigsten Daten im Überlaufsfall weglässt. Dieser Fall wird weni-ger wahrscheinlich auftreten, wenn weniger Integer-Messwerte übertragen werden müssen. Es gilt also Integer als Datentyp auszuwählen, wenn der aktuelle Messwert schnell verfügbar sein muss und Boolean, wenn die Tatsache ausreicht, dass eine Messung "true" ergeben hat.

Damit nicht die falschen Werte abgeschnitten werden, enthält jeder Messpunkt einen Priorisierungsparameter. Hier ist definiert, wie wichtig die Messung für die Darstellung im Leitstand ist. Hierbei kann man sich an Folgendem orientieren:

• Wenn es um eine Fehlerüberprüfung geht, die Handlungsbedarf erfordert, dann hat dieser Messpunkt eine hohe Wichtigkeit.

• Wenn es um eine Fehlerüberprüfung geht, die keinen weiteren Handlungsbedarf, aber zumindest eine Kenntnisnahme erfordert, dann hat dieser Messpunkt eine mitt-lere Wichtigkeit.

• Wenn die Messung rein informativ ist, also nur bei direktem Interesse daran am Leit-stand verfügbar sein soll, dann ist die Wichtigkeit gering.

Dies hat Einfluss auf die Darstellung der Einheiten im Leitstand und auf die Reihenfolge der Kodierung innerhalb des Paketes und damit auf die Wahrscheinlichkeit der Übertragung der Information.

In regelmäßigem Abstand (z.Zt. ist 1 Sekunde als Intervall geplant) wird ein Paket mit diesen Informationen kodiert und verschickt. Jedes Paket enthält zusätzlich im Header den aktuellen Aufenthaltsort, die Geschwindigkeit und Fahrtrichtung.

Ein Messpunkt definiert also eine Regel, die auf Messwerte angewendet wird und abhängig vom Ausgang dieser Operation verschickt wird. Messpunkte werden im Regelfall die Aufga-be eines Watchdogs übernehmen (d.h. sie überprüfen, dass ein Wert nicht eine vordefinierte Schranke überschreitet) und gegebenenfalls im Leitstand durch eine Statusänderung darauf aufmerksam machen. Messpunkte selbst erhalten nach der Definition durch die TU-Berlin


eine ID. Über diese ID lassen sich Messpunkte gezielt in der Konfiguration des SimTDLoggings deaktivieren.

Die Monitoringpakete werden regelmäßig vom SimTDLogging per UDP an den Leitstand in der ICS übertragen und dort nach der Dekodierung einmal in einer Datenbank gespeichert und gleichzeitig auf einer Karte dargestellt. Die Darstellung ist „grün“, wenn nichts Kritische-res als Daten mit der niedrigen Priorität („informative“) übertragen werden. Die Darstellung ist „gelb“, wenn nichts Kritischeres als Daten mit der mittleren Priorität („warning“) übertragen werden und „rot“, wenn mindestens ein Datum die hohe Priorität („critical“) hat. Wenn der Leitstand von einer IVS über einen zu definierenden Zeitraum kein Paket und damit keine Position bekommen hat, wird das Fahrzeug grau dargestellt und verbleibt auf der Karte an der letzten bekannten Position.


12 Werkzeuge zur Versuchsdurchführung Der gesamte Prozess der Versuchsdurchführung wird durch eine Reihe von Werkzeugen unterstützt. Diese setzen bereits bei der Erstellung und Planung der einzelnen Drehbücher an und unterstützen dann die Versuchsdurchführung.

Im Folgenden wird ein kurzer Überblick über die einzelnen Werkzeuge gegeben und im An-schluss ausführlicher gezeigt, wie diese Werkzeuge im Arbeitsalltag für die Versuchsdurch-führung unterstützend eingesetzt werden können.

12.1 Überblick über die zur Verfügung gestellten Werkzeuge

Im Wesentlichen lassen sich die Werkzeuge in zwei Bereiche gliedern. Zum einen die Test-ablaufplanung, welche die gesamte Organisation und Planung der einzelnen Drehbücher abdeckt. Zum anderen die Versuchssteuerung, die Werkzeuge zur Durchführung der einzel-nen Versuche bereitstellt. Abbildung 48 zeigt die beiden Funktionen mit allen Teilkomponen-ten, die zu ihnen gehören.

Abbildung 48: Komponenten der Versuchsunterstützung.

Diese Werkzeuge sind auf drei räumlich getrennte Systeme verteilt (siehe Abbildung 49):

• Die serverseitigen Komponenten der Versuchssteuerung in der Versuchszentrale übernehmen die Datenhaltung und Steuerung der Fahrzeuge.

• Die Werkzeuge der Testablaufplanung und der Szenario-Editor sind auf den Arbeits-plätzen im Versuchsflottenstützpunkt eingerichtet.

• Das Flottenmanagement ist auf einem Server in der Versuchszentrale installiert und wird über Client-Arbeitsplätze im Flottenstützpunkt bedient.

• Die Fahrzeugsteuerung läuft auf den Fahrzeugen und übernimmt dort die Kommuni-kation mit dem Fahrer (HMI Anweisung, Navigationsziele etc.).

• Die Fahrerbefragung läuft ebenfalls auf den Fahrzeugen.


Abbildung 49: Unterschiedliche Einsatzorte der Versuchsunterstützung.

Für die einzelnen Werkzeuge wird im Folgenden davon ausgegangen, dass es eine Reihe verschiedener Personengruppen gibt, die mit diesen Werkzeugen arbeiten müssen. Im We-sentlichen sind das:

• Versuchsteam: Planung, Durchführung: Operator Planung, Operator Mensch

• Versuchsfahrer: Fahrer der internen Flotte

• Technisches Team: Operator Technik, technische Hilfskräfte etc.

• Verwaltung: Personalwesen, Buchhaltung

12.2 Arbeiten im Vorfeld der Versuchsdurchführungen

Bevor die ersten Versuche mit der Testablaufplanung und Versuchsunterstützung durchge-führt werden können, müssen eine ganze Reihe an Vorarbeiten geleistet werden. Im We-sentlichen betreffen diese Arbeiten die Personalverwaltung, das technische Team und das Versuchsteam:

• Die Personalverwaltung muss im Vorfeld alle Stammdaten der Mitarbeiter erfassen.

• Das technische Team muss alle Daten über die Fahrzeuge eingeben.

• Das Versuchsteam muss alle Drehbücher definieren und die Versuchsdurchführun-gen einplanen.

12.2.1 Erfassen der Mitarbeiterstammdaten

Für die Verwaltung der Fahrer und Fahrzeuge wird ein externes Flottenmanagementsystem (FMS) eingekauft. Es gibt eine ganze Reihe verschiedener Hersteller von FM-Systemen. Diese wurden bereits validiert und zum aktuellen Stand wurden von verschiedenen Herstel-lern Angebote eingeholt. Ziel ist es, ein bestehendes System zu verwenden, das auf die Be-dürfnisse im Rahmen von simTD vom Hersteller angepasst wird. Im Folgenden wird die mög-liche Verwendung eines FMS anhand der Funktionen der gängigen Systeme beschrieben.

Ein FMS bietet die Möglichkeit, die komplette Fahrzeugflotte zu erfassen und zu verwalten. Darüber hinaus bringt es auch eine Personalverwaltung mit und kann bei Bedarf die Lohnab-rechnung für alle erfassten Personengruppen (Fahrer, Verwaltung, etc.) übernehmen.

Für die Versuchsdurchführung müssen mit dem FMS alle beteiligten Mitarbeiter erfasst wer-den. Dazu werden die Personalstammdaten (z.B. Name, Adresse, Kontaktdaten) eingege-


ben und die künftige Arbeitszeit erfasst. Da eventuell ein Mehrschichtbetrieb und unter-schiedliche Arbeitszeiten vorgesehen sind, wird vom FMS eine tagesaktuelle und mindes-tens stundenweise Arbeitszeiterfassung und Planung gefordert. Mit dem FMS können neben den Fahrern auch alle weiteren Mitarbeiter verwaltet werden. Daher muss eine Zuordnung zu einer Personalgruppe (z.B. Fahrer, Versuchsteam, Verwaltung) erfolgen, damit zum Beispiel gezielt alle Fahrer abgerufen werden können.

Abbildung 50 zeigt exemplarisch eine Eingabemaske eines bestehenden Flottenmanage-mentsystems zur Erfassung der Personaldaten. Das System erfasst darüber hinaus auch die geplanten Arbeitstage und Urlaubstage sowie Krankmeldungen (siehe Abbildung 51).

Abbildung 50: Personalstammdaten Eingabe im FMS (Sauer OS, 2009).

Abbildung 51: Personalverfügbarkeit im FMS (Sauer OS, 2009).


12.2.2 Erfassen der Fahrzeugstammdaten

Neben der Erfassung der Personaldaten dient das FMS vor allem zum Verwalten des kom-pletten Fuhrparks. Im FMS werden für jedes Fahrzeug verschiedene Daten (z.B. Kennzei-chen, Fahrzeugtyp, Farbe, Ausstattung) erfasst und die Fahrzeuge einer Fahrzeuggruppe (interne Flotte, externe Flotte, mobile IRS, Einsatzfahrzeug etc.) zugeordnet. Darüber hinaus werden auch alle in das Fahrzeug gesondert verbauten Geräte (CCU, VAU, HMI etc.) erfasst und jede Änderung an diesen Geräten protokolliert.

Das technische Team muss alle diese Daten im FMS eingeben und kann darüber hinaus geplante Wartungsarbeiten und Defekte erfassen (siehe Abbildung 52).

Abbildung 52: Eingabe der Fahrzeugdaten im FMS (Sauer OS, 2009).

12.2.3 Anlegen und prüfen der Drehbücher

Das Versuchsteam beginnt damit, die im Rahmen von AP41 erstellten Versuchsszenarien und Drehbücher aufzurufen und zu aktualisieren. Anschließend sind vom Versuchsteam die Drehbücher derart miteinander zu verknüpfen, so dass hieraus eine Versuchssitzung mit einer geschlossenen Route für die Versuchsfahrer entsteht.

Die Testablaufplanung (siehe Abbildung 53) hilft dabei, alle in der Datenbank enthaltenen Drehbücher aufzulisten und durchzusuchen. Sollte ein Drehbuch noch nicht existieren, kann es hierbei auch vom Versuchsteam neu angelegt werden. Die Übersichtsseite der Testab-laufplanung lässt sich dafür auf verschiedene Gruppierungen der Daten umstellen. Neben der direkten Darstellung aller existierenden Drehbücher kann auch eine Gruppierung nach Versuchsfällen erfolgen. Dadurch lassen sich auch Versuchsfälle finden, für die noch kein Drehbuch existiert. Soweit die Testfälle aus TP3 ebenfalls mit in der Datenbank eingetragen sind, werden diese in der gleichen Ansicht ebenfalls mit aufgelistet.


Abbildung 53: Testablaufplanung – Drehbücherauflistung.

Aus der Testablaufplanung heraus können die einzelnen Drehbücher im Szenario-Editor geöffnet und bearbeitet werden. Der Szenario-Editor bietet für den Einstieg in die Bearbei-tung des Drehbuchs einen Zugriff auf die Formulare für die Versuchsfälle (siehe Abbildung 54). Mit Hilfe dieser Formulare kann das Versuchsteam einen Überblick darüber bekommen, was von dem Drehbuch alles gefordert wird und alle Anforderungen im Folgenden beim de-taillierten Anlegen des Drehbuches berücksichtigen.

Abbildung 54: Beispielhafte Darstellung der Formularansicht für Versuchsfälle.

12.2.4 Drehbücher verfeinern

Die ersten Entwürfe der Drehbücher, die aus den Test- und Versuchsfällen hervorgegangen sind, sind häufig noch sehr allgemein gehalten. Das Versuchsteam muss diese nun schritt-weise immer detaillierter ausarbeiten. So werden im Rahmen von AP41 bei der Drehbucher-stellung beispielsweise die von den Versuchsfahrern zu befahrenen Strecken grob vorge-plant. Das Versuchsteam muss diese Vorarbeiten zum einen aktualisieren (z.B. Prüfung, ob Verkehrsregelungen noch gelten, Dauerbaustellen eingerichtet wurden), zum anderen (je nach Versuch) die konkreten Strecken ausplanen (inkl. Schätzung der Fahrtdauer). Die Be-


arbeitung der Drehbücher wird dabei in mehreren Schritten und zum Teil auch von verschie-denen Personen und Projektpartnern erfolgen.

Im ersten Schritt wird überprüft, ob die grundlegenden Informationen eingetragen wurden. Eventuell müssen einzelne Begrifflichkeiten (z.B. „Glatteis“, „Bodenglätte“) harmonisiert und vereinheitlicht werden. Darüber hinaus entsteht die Szenario Beschreibung und weitere tex-tuelle Beschreibungen für das Drehbuch.

Abbildung 55: Szenario-Editor - Allgemeine Informationen.

Der Szenario-Editor zeigt die wesentlichen Informationen aus dem Drehbuch direkt in einem gesonderten Bereich an (siehe Abbildung 55). Diese sind z.B.

• Name, Funktion etc.

• Anzahl der notwendigen erfolgreichen Durchläufe

• Gefordertes Logging-Profil

• Verschiedene generelle Anforderungen (z.B. Wetter, Tageszeit, Verkehrsdichte)

Für die vollständige Bearbeitung der Drehbuchtexte steht (wie bereits in Abbildung 54 ge-zeigt) eine Formularansicht zur Verfügung.

12.2.4.1 Erstellen der Routen Anhand der zusammengetragenen Informationen und Anforderungen hat das Versuchsteam einen Überblick über die geforderten Straßenabschnitte erhalten und kann (je nach Versuch) im nächsten Schritt für jedes Fahrzeug, das in diesem Drehbuch geplant ist, eine Route defi-nieren. Es gibt vereinzelte Drehbücher, in denen die zu prüfende Funktion bzw. der zu unter-suchende Anwendungsfall die geplante Route verändern soll. Bei solchen Versuchen ist die vollständige Planung der Route im Vorfeld schwierig. Die Umsetzung sieht hier vor, die Rou-


te so zu planen, dass sie das Ereignis des Assistenten auslöst (z.B. in dem die Route mitten durch einen Stau führt) und den Fahrer per Anweisung im Vorfeld darauf aufmerksam zu machen, das sie dem Assistenten folgen sollen.

Der Szenario Editor bietet dafür die Möglichkeiten, neue Routen anzulegen und für eine Rou-te neben dem Start- und Zielpunkt auch beliebig viele Zwischenpunkte zu definieren. Diese Zwischenpunkte sind für die anschließende Validierung der Versuchsdurchführung wichtig. Für die Validierung findet ein Soll-/Ist-Vergleich zwischen geplanter und gefahrender Strecke statt. Dieser muss zuverlässig und unabhängig von den verschiedenen Routenplanungsalgo-rithmen der Navigationslösungen funktionieren und benötigt daher eine eindeutig definierte Route.

Der Szenario-Editor zeigt neben der Routen- und Wegpunktverwaltung (siehe Abbildung 56 Mitte) auch die linearisierte Ansicht einer Route (siehe Abbildung 56 rechts). Diese zeigt übersichtlich alle Punkte einer Route und kann für einen ausgewählten Punkt weitere Detail-informationen (z.B. die laut StVO geltende Geschwindigkeit auf diesem Teilstück, Straßen-name) einblenden. Darüber hinaus können für jedes Teilstück verschiedene Optionen einge-stellt werden, wie z.B. eine für die Versuchsdurchführung geforderte Geschwindigkeit. Diese Optionen werden während der Versuchsdurchführung und für die anschließende Sofortprü-fung verwendet.

Abbildung 56: Szenario Editor - Anlegen von Routen.

Für jede Route (und damit für jedes Fahrzeug) kann gewählt werden, ob die Navigation zwi-schen Start und Ziel über das im Fahrzeug verbaute Navigationsgerät oder manuell über im Vorfeld geplante Fahreranweisungen erfolgt. Letzteres ist vor allem bei Versuchen notwen-dig, in denen das Navigationssystem Teil des Versuches ist.

Darüber hinaus lassen sich auch die Fragen für die Fahrerbefragung definieren, festlegen welche Funktionen aktiv laufen müssen und verschiedene Anforderungen an Fahrer und Fahrzeug (z.B. Fahrerlevel, Fahrzeugtyp, Motorisierung) definieren.


12.2.4.2 Ereignisse definieren Nachdem das Versuchsteam die Routen entworfen hat, können diese nun durch verschiede-ne Ereignisse erweitert werden. Ereignisse können das Erreichen einer bestimmten Position oder ein bestimmter Zeitpunkt (relativ zum Versuchsstart) während der Versuchsdurchfüh-rung sein. Sobald ein Ereignis während der Versuchsdurchführung ausgelöst wird, werden verschiedene mit dem Ereignis verknüpfte Aktionen ausgelöst.

Folgende Aktionen stehen dabei zur Auswahl:

• Ändern des Logging-Profil

• Navigationsziele für die Navigation programmieren

• Anweisungen auf dem HMI ausgeben (Versuchs- und Routenanweisungen)

Damit lässt sich z.B. zum Zeitpunkt des Versuchsstarts das Logging-Profil von einem einfa-chen Default-Profil auf ein Profil umstellen, das alle für den Versuch relevanten Daten erfasst (Die Profile werden vom Logging definiert und zur Verfügung gestellt). Es kann auch ein Er-eignis definiert werden, das z.B. 200m vor einer Kreuzung eine HMI Präsentation auslöst, die den Fahrer darauf hinweist, dass er an der nächsten Kreuzung abbiegen muss.

Abbildung 57 zeigt exemplarisch das Anlegen von Ereignissen und Aktionen.

Abbildung 57: Szenario Editor - Ereignisse und Aktionen.

In Drehbüchern, bei denen die Navigation nicht verwendet wird, kann das Versuchsteam entlang der Route durch die Ereignisse die entsprechenden Routenanweisungen planen. Dafür wird vor jedem relevanten Kurswechsel (z.B. Abbiegen an einer Kreuzung) ein Ereig-nis eingeplant, das als Aktion eine Routenanweisung im HMI auslöst. Die dort präsentierte Anweisung wird manuell vom Versuchsteam eingegeben.

12.2.4.3 Gruppen definieren Als letzter Schritt für die Definition eines Drehbuchs können die Fahrzeuge einzelnen Grup-pen zugeordnet werden. Diese dienen während der Versuchsdurchführung dazu, dass das Versuchsteam schnell mit einer ganzen Gruppe von Fahrzeugen in Kontakt treten kann. Die Gruppen können dabei individuell vom Versuchsteam angelegt werden und ein Fahrzeug darf in mehreren Gruppen enthalten sein (siehe Abbildung 58).


Abbildung 58: Szenario Editor - Anlegen von Gruppen.

Mit diesen Schritten ist die Bearbeitung der Drehbücher abgeschlossen und es kann an die Umsetzung des Drehbuches gehen.

12.2.5 Planen der Durchführungen

Nachdem die einzelnen Drehbücher definiert wurden, kann das Versuchsteam mit der Ein-planung der Versuchsdurchführungen („Wann wird welches Drehbuch gefahren?“) beginnen. Im Wesentlichen werden dafür die Informationen über die Anzahl der benötigten Fahrer und Fahrzeuge, die Anforderungen (z.B. Fahrzeugtyp, Fahrzeugausstattung, Fahrererfahrung) an diese sowie die geforderte Anzahl der Durchführungen benötigt.

Jedes Drehbuch kann mehr als einmal durchgeführt werden. Dies ist zum einen erforderlich für die Validierung der Daten und zum anderen für Wiederholungen, die notwendig werden, wenn eine Durchführung nicht zu den geforderten Situationen oder Loggingdaten geführt hat.

Für die Einplanung lassen sich die geforderten Fahrzeuge mit den verfügbaren Fahrzeugen abgleichen und so freie Termine finden, an denen genügend Fahrzeuge und Fahrer verfüg-bar sind. Die Testablaufplanung unterstützt das Versuchsteam mit einer Listenansicht über alle geplanten und ungeplanten Drehbücher. Zusätzlich kann eine Kalenderansicht einge-blendet werden, in der passende freie Plätze für eine Durchführung farblich hervorgehoben werden (siehe Abbildung 59). Anhand dieser Ansicht kann das Versuchsteam die Durchfüh-rung für jeden Tag und jede Uhrzeit festlegen. Sollten für einen Tag mehr Fahrzeuge ver-plant werden, als insgesamt für das Projekt zur Verfügung stehen, wird automatisch eine Warnung ausgelöst.

12.3 Tagesgeschäft – Versuchsdurchführungen

Nachdem im vorherigen Kap. 12.2 die einzelnen Vorarbeiten für die Versuchsdurchführung beschrieben sind, geht es in diesem Kapitel um das Tagesgeschäft. Die einzelnen zuvor geplanten Drehbücher müssen nun entsprechend der Planung umgesetzt werden. Wie die Werkzeuge der Versuchssteuerung bei der Umsetzung helfen können, soll im Folgenden gezeigt werden.


Abbildung 59: Einplanen einer Versuchsdurchführung.

12.3.1 Vorbereiten der Versuchsdurchführung

Der Tag startet mit den Arbeiten des Versuchsteams. Dieses bereitet alles Wesentliche für die Versuchsdurchführungen an diesem Tag vor und unterrichtet die Fahrer über den ge-planten Tagesablauf.

12.3.1.1 Prüfen der Tagesplanung Zuerst muss das Versuchsteam die aktuellen Planungen für diesen Tag prüfen. Dafür wer-den in der Testablaufplanung die für diesen Tag eingeplanten Versuchsdurchführungen auf-gerufen und die Vorgaben durch die Drehbücher geprüft. Sollten die Anforderungen nicht zum aktuellen Tag passen (z.B. weil Sonnenschein gefordert ist und aktuell gibt es Schnee-fall und Glätte), kann das Versuchsteam kurzfristig ein anderes Szenario für diesen Tag ein-planen. Die Filterfunktionen in der Testablaufplanung (siehe auch Abbildung 59) helfen da-bei, schnell eine Versuchsdurchführung zu finden, die zu den aktuellen Bedingungen passt.

Zusätzlich zu den Anforderungen des Drehbuchs muss das Versuchsteam prüfen, ob genü-gend Fahrer und Fahrzeuge verfügbar sind. Alle Krankmeldungen des Tages müssen in das FMS eingetragen werden (siehe Abbildung 51). Dasselbe passiert bei festgestellten Ausfäl-len auf Seiten der Fahrzeuge. Das Versuchsteam kann auf diese Ausfälle in unterschiedli-cher Weise reagieren: Ausgefallene Fahrer können durch Ersatzfahrer ersetzt werden. Bei Ausfällen in der Fahrzeugflotte, kann im FMS geprüft werden, welche Fahrzeuge zusätzlich verfügbar sind und eventuelle Wartungsarbeiten verschoben werden. Sollte kein ausreichen-der Ersatz gefunden werden, kann auch hier im Zweifelsfall kurzfristig ein anderes Drehbuch vorgezogen werden.


12.3.1.2 Fahrzeuge und Fahrer buchen Das Versuchsteam prüft am Tag der Versuchsdurchführung die Zuordnung der Fahrer und Fahrzeuge zu geplanten Drehbüchern und darin enthaltenen Routen und aktualisiert diese bei Bedarf. Dies geschieht, kurz bevor die Durchführung startet, damit auf kurzfristige Ände-rungen reagiert werden kann. Aufgrund der Komplexität des Gesamtsystems ist davon aus-zugehen, dass langfristige Planungen häufig nicht mehr umsetzbar sind, da sowohl die Fahr-zeuge als auch die Fahrer nicht wie geplant an dem Tag verfügbar sind. Daher erfolgt die Zuordnung von Fahrern und Fahrzeugen erst wenige Tage vor Versuchsdurchführung und muss tagesaktuell geprüft werden.

Die Buchungskomponente der Testablaufplanung hilft bei der Buchung der Fahrer und Fahr-zeuge. Es werden alle Routen, die zum ausgewählten Drehbuch gehören, aufgelistet und die dazugehörigen Anforderungen dargestellt. Parallel dazu werden die verfügbaren Fahrer und Fahrzeuge aus dem FMS abgerufen und dargestellt. Das Versuchsteam kann nun jeder Strecke einen Fahrer und ein Fahrzeug zuordnen.

Um den Vorgang zu vereinfachen, kann initial eine automatisierte Zuordnung erfolgen. Dabei wird versucht, alle geforderten Bedingungen zu erfüllen und zwischen den Versuchsdurch-führungen keinen Fahrerwechsel zu erzeugen. Abbildung 60 veranschaulicht, wie eine Über-sicht über die geplanten Routen bei der Zuordnung von Fahrzeugen und Fahren unterstüt-zen kann. Die gebuchten Fahrer und Fahrzeuge werden abschließend automatisch ans FMS weitergeben und dort werden die Fahrzeuge entsprechen disponiert.

Abbildung 60: Buchen von Fahrern und Fahrzeugen.


12.3.1.3 Briefing Nachdem alle Planungen erfolgt sind, wird vor der Versuchsdurchführung ein kurzes Briefing für die Versuchsfahrer abgehalten. Der Szenario Editor kann auch hierbei unterstützen, da er die in der Datenbank hinterlegten Daten für die einzelnen Zielgruppen aufbereitet ausdru-cken kann. Dadurch lassen sich die folgenden Dokumente auch nach den Planungsände-rungen kurzfristig und aktuell ausdrucken:

• Szenario-Beschreibung

• Drehbuchauszug für jeden einzelnen Fahrer Dieser Auszug enthält nur Informationen, die auch diesen Fahrer betreffen.

• Drehbuch für den Operator Dieses beschreibt die durchzuführenden Aktionen im Versuchsflottenstützpunkt.

Nach dem Briefing begeben sich die Fahrer zu ihren Fahrzeugen und unterziehen diese ei-nem kurzen Funktionscheck. Sollte das Fahrzeug defekt sein, kann über die weiter oben beschriebenen Mechanismen Ersatz beschafft werden (siehe Kap. 12.3.1.1).

12.3.2 Versuchsdurchführung

Für die Versuchsdurchführung wird das entsprechende Drehbuch im Szenario-Editor geöff-net. Dieser bietet eine Ansicht, die speziell auf die Bedürfnisse der Versuchsdurchführung ausgerichtet ist. Neben den bekannten Ansichten und Funktionen aus dem Szenario-Editor kommen Elemente zum Steuern des Versuches, zur Anzeige und zur Auswahl der Fahrzeu-ge sowie zur Kommunikation mit den Fahrern hinzu.

12.3.2.1 Durchführung im Versuchsflottenstützpunkt Sobald die Fahrzeuge gestartet wurden, melden sich diese über das Monitoring und der Sta-tus wird in der Fahrzeugliste visualisiert (siehe Abbildung 61). Das Versuchsteam kann das Drehbuch initiieren, sobald alle Fahrzeuge bereit sind. Die Initiierung führt dazu, dass das ausgewählte Drehbuch auf die Fahrzeuge kopiert wird und die Fahrer an ihren jeweiligen Startpunkt navigiert werden.

Nachdem alle Fahrzeuge ihren Startpunkt erreicht haben, kann das Versuchsteam die Durchführung manuell starten. Für die einzelnen Routen kann bereits bei der Planung ein verzögerter Startzeitpunkt definiert werden. Die Fahrer erhalten dann unabhängig vom glo-balen Start durch das Versuchsteam ihre Anweisungen unter Berücksichtigung dieser Ver-zögerung. Damit lassen sich die Fahrzeuge in definierten Zeitabständen starten. Ab diesem Augenblick erhalten die Fahrer automatisiert die im Vorfeld geplanten Anweisungen. Dem Versuchsteam wird die Bewegung der Fahrzeuge auf der Karte in Echtzeit angezeigt und zusätzlich kann ein Vergleich zwischen Soll- und Ist-Trajektorie eingeblendet werden.

Die Anzeige der Fahrzeuge kann über die Fahrzeugauswahl eingeschränkt werden. Dabei kann auf die im Vorfeld definierten Gruppen zurückgegriffen werden. Den Fahrern der aus-gewählten Fahrzeuge kann über die „Ad-hoc Nachrichten“-Funktion eine kurze Textnachricht gesendet werden, die auf dem HMI des Fahrzeugs dargestellt wird. Wenn die im Fahrzeuge verwendete Plattform Text-to-Speech (TTS) unterstützt, können die Nachrichten optional auch über TTS ausgegeben werden.

Während der gesamten Versuchsdurchführung steht dem Versuchsteam ein Notizfeld zur Verfügung. In diesem können kurze Notizen eingetragen werden, um die Durchführung zu protokollieren.


Abbildung 61: Versuchsdurchführung.

Der Versuch wird sowohl bei erfolgreicher Durchführung als auch bei Problemen manuell vom Versuchsteam beendet.

12.3.2.2 Durchführung im Fahrzeug Im Fahrzeug wird mit dem Starten der Versuchsdurchführung die automatisierte Abarbeitung des Drehbuches gestartet. Zu den geplanten Zeitpunkten und Positionen werden dem Fahrer dabei verschiedene Präsentationen im HMI angezeigt.

• Versuchsanweisungen geben dem Fahrer kurze Instruktionen, die den Versuch be-treffen (siehe Abbildung 62 rechts).

• Routenanweisungen geben dem Fahrer Anweisungen bzgl. der Routenführung. Das wird vor allem genutzt, wenn auf die Nutzung der Onboard-Navigation verzichtet wird. (siehe Abbildung 62 links)

• Ad-hoc Anweisungen aus dem Versuchsflottenstützpunkt

Abbildung 62: Beispiel für die HMI Präsentationen (Entwurfsdesign, Stand: März 2010).

Darüber hinaus kann die Versuchssteuerung zu geplanten Zeitpunkten das Navigationsgerät programmieren und die im Vorfeld geplante Route wird zusätzlich in der Karte visualisiert.


Des Weiteren wird beim Versuchsstart (für den Fahrer unbemerkt) das ausgewählte Logging-Profil gesetzt, die Konfiguration für die Fahrerbefragung übermittelt und die Konfigu-ration für aktive simTD-Funktionen an den System Manager übergeben.

12.3.2.3 Fahrerbefragung Zusätzlich zu den bereits genannten Aktionen, die den Fahrer betreffen, gibt es noch die Fahrerbefragung. Diese findet in zwei Stufen statt. Neben der Befragung am Ende des Ver-suches (sog. Abschlussbefragung) gibt es während der Versuchsdurchführung die sog. Si-tuationsbewertung. Die Situationsbewertung kann durchgeführt werden, wenn eine beson-ders wichtige zu testende Funktion ausgelöst wurde. Da dies während der Fahrt passiert, ist die Situationsbewertung auf einzelne Ja/Nein- Frage beschränkt (siehe Abbildung 63).

Abbildung 63: Fahrerbefragung – Situationsbewertung (Entwurfsdesign, Stand: März 2010).

Wenn die Versuchsdurchführung beendet wurde, wird eine abschließende Fahrerbefragung durchgeführt, sobald das Fahrzeug anhält. Diese Bewertung ist umfangreicher und beinhaltet verschiedene Ja / Nein- und Multiple Choice-Fragen (siehe Abbildung 64).

Abbildung 64: Entwurfsbeispiele für Fahrerbefragung – Bewertung (Entwurfsdesign, Stand: März 2010).

12.3.3 Sofortprüfung

Zum Abschluss der Versuchsdurchführung muss diese vom Versuchsteam bewertet werden. Dabei geht es im Wesentlichen um die Frage, ob die Versuchsdurchführung die geforderten Versuchsbedingungen herstellen konnte und damit das gewünschte Szenario erfolgreich getestet wurde. Diese Entscheidung kann nur manuell vom Versuchsteam getroffen werden. Die Werkzeuge der Versuchsunterstützung sollen aber bei der Entscheidungsfindung helfen. Dazu finden verschiedene noch zu definierende Analysen statt, z.B.:

• Sind die Logdateien aller beteiligten IVS, IRS und ICS vorhanden?


• Sind die Fahrzeuge entlang der geplanten Routen gefahren?

• Wurden geforderte Geschwindigkeiten eingehalten?

• Tauchen geforderte Logging Einträge überhaupt in der Logdatei auf?

Das Ergebnis dieser Analysen wird dem Versuchsteam zur Verfügung gestellt (siehe Abbildung 65) und fließt dann in die manuelle Entscheidung über den Erfolg der Durchfüh-rung mit ein. Da viele dieser Entscheidungen erst mit einem ersten Blick in die Logdateien möglich sind, kann die endgültige Entscheidung erst erfolgen, wenn die Logdateien vorliegen und hinsichtlich vordefinierter Kriterien geprüft worden sind. Diese sind aber nicht sofort nach dem Versuchsende in der Zentrale abrufbar.

Abbildung 65: Sofortprüfung der Versuchsdurchführung.

Zusammenfassend findet die Sofortprüfung somit in zwei Stufen statt:

• Das Versuchsteam gibt unmittelbar nach der Durchführung sein Sofortfazit ein.

• Die endgültige Sofortprüfung erfolgt dann ein paar Tage später auf Grundlage des Sofortfazits und der Analysen.

12.3.4 Vorbereitungen und Nacharbeiten

Aus den bisher geschilderten Abläufen im Tagesgeschäft ergeben sich einige Tätigkeiten, die jeden Tag erneut vor- und nachbereitet werden müssen.

Um möglichst frühzeitig zu erkennen, dass Änderungen an der Planung notwendig sind, muss das Versuchsteam die Planung der anstehenden Durchführungen ein paar Tage im Voraus überprüfen. Es muss geprüft werden, ob alle eingeplanten Szenarien zu den aktuel-len Bedingungen passen und vor allem ob die Szenarien auch wirklich vollständig definiert worden sind (alle Routen geplant, Gruppen definiert etc.). Sollten an einzelnen Tagen noch freie Zeiten existieren, kann das Team noch nicht geplante Durchführungen suchen, die zu


diesen Tagen passen. Hierbei hilft wieder die Filterfunktion der Testablaufplanung (siehe Kap. 12.2.5). So kann nach verschiedenen Tageszeiten, Wetterbedingungen und auch nach der Anzahl der eingesetzten Fahrzeuge gefiltert werden.

Für die Sofortprüfung führt das Versuchsteam die in Kap. 12.3.3 bereits erläuterten Schritte einige Tage nach der Versuchsdurchführung erneut durch. Als erstes ist zu prüfen, ob mitt-lerweile alle Logdateien vorhanden sind. Sollte dies auch nach mehreren Tagen nicht der Fall sein, muss geprüft werden, welche Logdateien fehlen und ob diese für die Auswertung unbedingt notwendig sind. Wenn alle Logdateien vorhanden sind, können die weiteren Ana-lysen erfolgen. Das Versuchsteam aktualisiert abschließend den Status dieser Durchführung. Sollte die Durchführung nicht erfolgreich sein, muss entschieden werden, ob die Durchfüh-rung wiederholt werden muss und entsprechend eine neue Durchführung eingeplant werden muss. Bei fehlenden Logdateien sollte das Versuchsteam auch prüfen, warum diese Dateien fehlen und wenn nötig weitere Maßnahmen einleiten (z.B. vermerkt im FMS, Überprüfung des Fahrzeugs durch das technische Team).

12.3.5 Defektmanagement

Während der einzelnen Durchführungen kann es immer wieder zu Defekten und Ausfällen kommen. Das kann von Lackkratzern an den Versuchsfahrzeugen über Probleme mit der simTD-Technik bis hin zu Unfallschäden reichen. Das Versuchsteam wird alle technischen Probleme, die im Tagesverlauf auftreten, im FMS eintragen und dort möglichst detailliert er-fassen. Abbildung 66 zeigt ein Beispiel für die Verwaltung von Schadensmeldungen und Werkstattterminen anhand eines bestehenden FMS.

Abbildung 66: Defektverwaltung mit dem FMS (Sauer OS, 2009).

Mit diesen Informationen kann das technische Team die defekten Fahrzeuge im FMS ausle-sen und entsprechend deren Wartung und Reparatur einplanen. Im FMS sind auch alle Bu-chungen der einzelnen Fahrzeuge für eine geplante Versuchsdurchführung hinterlegt. Daher kann das technische Team sofort sehen, wann das Fahrzeug wieder auf dem Gelände des Versuchsflottenstützpunktes verfügbar ist.


13 Konzeption Pilotversuche und Vorversuche Es ist davon auszugehen, dass im simTD-Feldversuch nicht alles auf Anhieb wie vorausbe-rechnet funktioniert. Vor diesem Hintergrund ist es notwendig, vor dem Hauptversuch das Zusammenspiel der technischen sowie organisatorischen Abläufe zu erproben. Aus diesem Grund sind Pilot- und Vorversuche in TP4 vorgesehen, die nachfolgend dargestellt werden. Die konkrete Ausgestaltung dieser Pilot- und Vorversuche hängt dabei maßgeblich davon ab, welche Infrastruktur bzw. Fahrzeuge zu dem jeweiligen Zeitpunkt zur Verfügung stehen (z.B. welche Flotten überhaupt vorhanden sind zu dem jeweiligen Zeitpunkt).

13.1 Teilprojekte TP3/TP4 und deren Phasen

Bevor Pilot- und Vorversuche in TP4 stattfinden können, sind die einzelnen Systeme und Komponenten in TP3 Systemintegration bereits getestet und geprüft worden. Das Gesamt-system ist voll funktionsfähig und von TP3 während deren Pilottests voll integriert. Dies be-trifft alle im Rahmen des Feldversuches eingesetzten Komponenten, Testsysteme und Test-komponenten. Abbildung 67 veranschaulicht die zeitliche Reihenfolge über die Phasen.

Abbildung 67: Zeitliche Einordnung und Reihenfolge der Phasen.

Es gibt bei simTD eine klare Trennung zwischen TP3 Systemintegration und TP4 Versuchs-durchführung und den einzelnen Phasen (siehe Abbildung 68). Es wird ein Ziel sein, zugleich einen sanften Übergang zwischen den Teilprojekten zu realisieren. Damit TP3 die Optimie-rung am Gesamtsystem durchführen kann, wird es zwischen TP3 und TP4 zu Berührungs-punkten kommen. Dabei ist es von Bedeutung, wann und in welchem Umfang der GUA Ver-suchsdurchführung (AP42) in die Pilot- und Vorversuche integriert werden soll und welche Flotten zu welchem Zeitpunkt uneingeschränkt zur Verfügung stehen werden.

Abbildung 68: Priorisierung in den Phasen und deren Teilprojekte.

Anmerkung: in der Pilotversuchsphase stehen TP4 nur die Fahrzeuge und Fahrer der OEMs zur Verfügung. TP3 hat priorisierten Zugriff auf die OEM-Flotte und falls TP4 Fahrten durchführen will, ist dies nur in Absprache mit TP3 und den OEMs möglich.


Nachfolgend werden die Pilotversuche und Vorversuche ausführlicher behandelt. Dabei wird es Berührungspunkte mit der Optimierungsphase (TP3) geben. Idealerweise wird es während der Optimierungs-/Pilotversuchsphase zu einem Übergang zwischen TP3 und TP4 kommen.

Während der Pilot- und Vorversuche werden alle Systeme auf Durchführbarkeit im Gesamt-system überprüft und der laufende Betrieb in einer Art „Generalprobe“ erprobt. Vereinfacht ergibt sich:

• In der Pilotversuchsphase werden sich TP4 und der GUA Versuchsdurchführung (AP42) mit der Infrastruktur und den Werkzeugen, die bei simTD im Gebrauch sind, vertraut machen. Es werden (in Absprache mit TP3 und den OEMs) exemplarisch erste Drehbücher abgefahren. In Kap. 13.2 wird genauer auf Arbeiten und Tätigkeiten während der Pilotversuchsphase eingegangen.

• Die Vorversuchsphase stellt eine Generalprobe für den Feldversuch dar. Hier wird der laufende Betrieb mit einem Teil der Mietwagenflotte (geplant sind 20 Fahrzeuge) durchgeführt. In Kap. 13.3 wird genauer auf das Thema eingegangen.

Inhalt weiterer Arbeiten von TP3 und TP4 ist die Erarbeitung eines gemeinsamen Zeitplans inkl. notwendiger Abstimmungsprozesse für die Durchführung von Pilotversuchen und Vor-versuchen.

13.2 Pilotversuchsphase

In der Pilotversuchsphase sollen TP4 und der GUA Versuchsdurchführung (AP42) erste Er-fahrungen mit der Infrastruktur, den Fahrzeugen den Werkzeugen etc. in simTD sammeln können, um sich mit den simTD-Gegebenheiten vertraut zu machen. Welche Voraussetzun-gen hierbei eine Rolle spielen werden und welche Arbeiten und Tätigkeiten der GUA und TP4 durchführen sollen, wird in diesem Unterkapitel beschrieben.

Der geplante Start- bzw. Endezeitpunkt ist (Stand: März 2010):

• Start: 01.05.2011

• Ende: 31.10.2011

• Dauer: 7 Monate

13.2.1 Voraussetzung für die Durchführung von Pilotversuchen

• Alle Systeme (CCU, AU etc.) sind bereits einzeln und im Gesamtsystem auf Funktio-nalität überprüft und vorhanden.

• Die simTD-Infrastruktur steht komplett zur Verfügung.

• Zuordnung technische Test- und Versuchsfälle zwischen TP3/TP4 ist erstellt worden.

• Drehbücher (z.B. IT-sicherheitsrelevante Drehbücher) stehen exemplarisch für mögli-che Pilotverssuche zur Verfügung.

• Werkzeuge (Software, Hardware etc.) stehen komplett zur Verfügung.

• OEM-Flotte einsatzbereit, aber v.a. für TP3 in der Optimierungsphase verfügbar. Nach Absprache mit OEMs und TP3 steht die OEM-Flotte auch für TP4 zur Verfü-gung.


• Ideal: Der GUA Versuchsdurchführung AP42 hat bereits seine Tätigkeiten aufge-nommen und wird gemeinsam mit TP4 und nach Absprache mit TP3 und den OEMs

o sich mit den Werkzeugen vertraut machen,

o erste Drehbücher mit der OEM-Flotte im Versuchsgebiet abfahren sowie

o sich mit dem Versuchsflottenstützpunkt und der ITS Central Station (ICS) ver-traut machen.

• Falls aus den durchgeführten Erprobungsfahrten verwertbare Daten erzeugt werden, werden diese Daten AP43 zur Auswertung und Analyse zur Verfügung gestellt.

13.2.2 Aufgaben in der Pilotversuchsphase

Zum Zeitpunkt der Pilotversuche/Optimierungsphase liegen die Prioritäten der Tätigkeiten bei TP3. Das Gesamtsystem liegt nach der Optimierungsphase voll integriert, komplett und mehrfach abgeprüft dem simTD und TP4 vor. Da TP3 als Systemintegrator sich über die Funktionalität der einzelnen technologischen Bereiche sicher sein muss, werden die Tätig-keiten von TP4 während der Pilotversuchsphase immer in Absprache mit TP3 und den OEMs stattfinden.

Aufgaben werden für TP4 und den GUA Versuchsdurchführung (AP42) sein:

• Vertraut machen mit der Infrastruktur und Werkzeugen.

• Feedback an TP3/TP4 bei neuen Erkenntnissen (z.B. Softwarebugs, Changes) ge-ben, die notwendige Änderungen am System hervorrufen werden.

• Durchführung erster technischer Versuche (z.B. Kommunikationsversuche) für exemplarisch ausgewählte Drehbücher mit Feedback an TP3/TP4 mit dem Ziel, dies-bezügliche Optimierungsprozesse zu realisieren.

• Durchführung erster sicherheitsrelevanter Versuche (falls möglich) für exemplarisch ausgewählte Drehbücher mit Feedback an TP3/TP4 mit dem Ziel, diesbezügliche Op-timierungsprozesse zu realisieren.

• Definition von Prozessen mit Möglichkeit des Feedbacks an TP3/TP4:

o Zusammenspiel der einzelnen Bereiche im Gesamtsystem (z.B. Versuchsflot-tenstützpunkt <> ITS Central Station (ICS))

o Benutzbarkeit der einzelnen Bereiche (z.B. Infrastruktur, Drehbücher)

o Fehlerfall

o Worst-Case Szenarien

o Eskalationsschritte

13.2.3 Ergebnisse der Pilotversuchsphase

Nach der /Pilotversuchsphase werden folgende Ergebnisse vorliegen:

• Ein umfangreicher Prozesskatalog mit genau definierten Tätigkeitsbeschreibungen und Schnittstellen zwischen den einzelnen Tätigkeiten/Bereichen.

• Erste Ergebnisse und Erkenntnisse über die Durchführbarkeit von Drehbücher


• Analysefähige Daten, die zu diesem Zeitpunkt aus Drehbüchern und Versuchsfahrten gewonnenen wurden (z.B. Kommunikationsversuche, IT-sicherheitsrelevante Versu-che).

• Umfangreiches Wissen über die Infrastruktur und den verwendeten Werkzeugen.

• Eine angepasste Schnittstelle zwischen TP3 und TP4, um im späteren Feldversuch eine reibungslose Wartung der Infrastruktur und Fahrzeuge zu gewährleisten. TP3 ist während der Feldversuchsphase für die Wartung der Infrastruktur/Fahrzeuge verant-wortlich.

13.3 Vorversuchsphase

Während bei der Pilotversuchsphase die Tätigkeiten von TP3 höher priorisiert sind, sind während der Vorversuchsphase die Tätigkeiten und Arbeiten von Teilprojekt TP4 höher prio-risiert. TP3 wird an dieser Stelle bei allen Wartungsarbeiten bezüglich der Infrastruktur und Versuchsflotte unterstützend aktiv werden.

Die Vorversuchsphase ist die sog. Generalprobe, bevor es in den Feldversuch im simTD-Versuchsgebiet geht. Der Ansatz hierbei ist, den laufenden Betrieb des Feldversuches so genau wie möglich abzubilden. Es wird die gesamte Organisationsstruktur auf Schwachstel-len und auf Machbarkeit überprüft. Ab diesem Zeitpunkt ist geplant, dass der GUA Ver-suchsdurchführung (AP42) mindestens 20 Fahrer einsetzt.

Während der Vorversuchsphase ist darauf zu achten, dass jede Tätigkeit in Prozesse abge-bildet werden muss, um daraus Transparenz, Nachverfolgbarkeit und eine Tätigkeitsbe-schreibung für den Feldversuch zu ermöglichen. Die aus den Pilotversuchen und anderen Vorüberlegungen gewonnen Erkenntnisse fließen hierbei mit ein und werden sukzessiv um neue, noch nicht durchdachte Arbeitsschritte erweitert und vervollständigt.

Der geplante Start- bzw. Endezeitpunkt ist (Stand: März 2010):

• Start: 01.11.2011

• Ende: 31.01.2012

• Dauer: 3 Monate

13.3.1 Voraussetzung für die Durchführung von Vorversuchen

• Die Infrastruktur steht komplett zur Verfügung (optimiert während Pilotversuchspha-se).

• Alle Drehbücher stehen für Vorversuche zur Verfügung.

• Einige exemplarisch ausgewählte Drehbücher wurden bereits erfolgreich abgefahren.

• Während Pilotversuchsphase erstellter Prozesskatalog dient als Arbeitsvorlage, um z.B. Drehbücher abfahren zu können.

• Werkzeuge (Software, Hardware etc.) stehen zur Verfügung (optimiert während Pilot-versuchsphase).

• Versuchsflotte mit 20 Fahrzeugen steht voll ausgestattet und einsatzbereit TP4 / GUA Versuchsdurchführung (AP42) zur Verfügung.

• 20 Versuchsfahrer der internen Flotte stehen zur Verfügung,

• Versuchsflottenstützpunkt steht voll betriebsbereit zur Verfügung.


13.3.2 Aufgaben in der Vorversuchsphase

Während der Vorversuchsphase soll der GUA Versuchsdurchführung (AP42) bereits voll integriert und selbständig alle anfallenden Arbeiten ausführen. Die Aufgaben für TP4 und den GUA werden sein:

• Alle Arbeiten in den jeweiligen Bereichen wie im Echtbetrieb aufnehmen.

• Benutzbarkeit der örtlichen Gegebenheiten im größeren Maßstab (mit 20 Versuchs-fahrern Fahrzeuge überprüfen, trainieren etc.).

• Koordination und Steuerung von allen Bereichen im Gesamtsystem (wie z.B. Fahrer), Fahrzeug wird mit den dazugehörigen Werkzeugen trainiert und erprobt.

• Feedback an TP3/TP4 bei neuen Erkenntnissen.

• Durchführen von Versuchen mit interner Flotte (20 Fahrzeuge) und Drehbüchern, mit anschließender Rückmeldung der gewonnen Erkenntnisse an TP3/TP4, um Anpas-sungen und Verbesserungen vornehmen zu können.

• Ausstattungsversuche mit interner Flotte (20 Fahrzeuge) und Drehbüchern durchfüh-ren mit anschließendem Feedback an TP3/TP4 mit dem Ziel, diesbezügliche Optimie-rungsprozesse zu realisieren.

• Definition von Prozessen und Erstellung von Handbüchern:

o Tätigkeiten im Rahmen der Fahrerversuche identifizieren und daraus Prozes-se erstellen (z.B. Schlüsselübergabe an Fahrer, Fahrerbriefing).

o Handbücher erstellen über für den Feldversuch notwendige Tätigkeiten (z.B. Trainingskonzept für Versuchsfahrer).

o Unfall-/Defektszenarien bzw. Wartungsszenarien erproben und optimieren.

o Eskalationsschritte definieren.

13.3.3 Ergebnisse in der Vorversuchsphase

• Ein Prozesskatalog und Handbücher über die verschiedenen anfallenden Tätigkeiten im Rahmen von simTD.

• Erste auswertbare Ergebnisse für technische Versuche (z.B. Kommunikationsversu-che, IT-Sicherheitsversuche)

• Erste auswertbare Ergebnisse für nicht-technische Versuche.

• Transparente und nachvollziehbare Schnittstellen zwischen GUA und simTD-Partnern.

• Drehbücher sind exemplarisch abgefahren worden, so dass abgeschätzt werden kann, ob Drehbücher im Allgemeinen durchführbar sind.

• Alle überprüfbaren Elemente des Gesamtsystems wurden mehrfach im Vorversuch durchlaufen, geprüft, optimiert und verifiziert.


14 Konzeption Erstellung Drehbücher

14.1 Einleitung

Eines der primären Ziele von AP41 Versuchsdesign ist ein detaillierter Versuchsplan, der z.B. festlegt,

• wie viele und welche Fahrer (resp. Fahrzeuge) zu welchem Zeitpunkt welche Aufgabe bekommen,

• wie die Daten von Fahrern und Fahrzeugen mit infrastrukturseitig generierten Daten der Auswertung zugeführt werden können,

• wo die einzelnen Versuche stattfinden werden,

• mit welchen Ausstattungsraten und Verkehrszuständen die Versuche wie häufig wie-derholt werden sowie

• welche Ausstattung für die Infrastruktur notwendig ist.

Die Ausformulierung von Anweisungen für die Versuchsfahrer und die Versuchsdurchfüh-renden soll in Form sog. Drehbücher erfolgen.

Im Rahmen dieses Kapitels werden konzeptionelle Vorarbeiten, die zur Erstellung von Dreh-büchern beitragen, vorgestellt. Die konkreten Ausformulierungen werden im weiteren Verlauf von AP41 vorgenommen und im Rahmen des Deliverables D41.2 „Versuchsplan 2.0“ doku-mentiert.

14.2 Begriffsbestimmung

Für eine Darstellung des aktuellen Arbeitsstandes zur Konzeption einer Drehbuch-Erstellung, wie sie in AP41 zu leisten ist, ist zunächst eine Einordnung der in diesem Zusammenhang zu verwendenden Begrifflichkeiten vorzunehmen. Aus diesem Grund werden nachfolgend Ar-beitsdefinitionen für die im Rahmen von AP41 zu verwendenden Begriffe „Versuchsszena-rio“, „Drehbuch“ und „Drehbuchauszug“ vorgestellt (siehe Kap. 14.2.1 und 14.2.2).

Diese Arbeitsdefinitionen werden im Nachgang dieses Deliverables D41.1 in das simTD-Glossar eingebracht. Hierdurch werden die bisherigen diesbezüglichen Begrifflichkeiten, die von verschiedenen Partnern vorläufig im Rahmen von simTD eingebracht wurden, ersetzt.

14.2.1 Versuchsszenario (Arbeitsdefinition)

Ausgehend von den in AP13 bestimmten Begriffen „Versuchsfall“ und „Versuchsfallvariante“ wird nachfolgend der Begriff des „Versuchsszenarios“ anhand eines nicht-technischen Ver-suchsfalls zum Anwendungsfall A_2.1.2.1 „Warnung vor Stauende“ beispielhaft skizziert (siehe Abbildung 69). Die Ausführungen gelten in ähnlicher Weise für technische Versuchs-fälle.

In einer Versuchsfallspezifikation werden u.a. die notwendigen Schritte bei der Durchführung dieses Versuchsfalls skizziert. Zu diesen Schritten zählen z.B. Angaben darüber,

• wie viele verschiedene Fahrergruppen bei einem Versuchsfall herzustellen sind (im Beispiel in Abbildung 69: zwei Fahrergruppen),


• hinsichtlich welcher Merkmale sich diese Fahrergruppen unterscheiden (im Beispiel in Abbildung 69: eine Hälfte der Fahrzeuge erhält eine simTD-Warnung, die andere Hälf-te erhält diese simTD-Warnung nicht),

• wie im Rahmen der späteren Versuchsauswertung diese Fahrergruppen miteinander verglichen werden sollen (im Beispiel in Abbildung 69: Annäherungsverhalten) und

• welche Aktionen von den Versuchsfahrern zur Versuchsdurchführungszeit zu vollzie-hen sind.

Für diesen Versuchsfall sind zudem verschiedene sog. Versuchsfallvarianten zu berücksich-tigen, die z.B. durch die Variation der Streckenart oder des Verkehrszustands entstehen. Für das dargestellte Beispiel zum Anwendungsfall A_2.1.2.1 „Warnung vor Stauende“ ist dies z.B. die Einsehbarkeit des Stauendes durch die Versuchsfahrer.

Abbildung 69: Gliederung der simTD-Begriffe –Versuchsszenario als Konkretisierung eines Versuchsfalls bzw. einer Versuchsfallvariante.

Die bisher dargestellten Inhalte zu nicht-technischen Versuchsfällen und Versuchsfallvarian-ten sind umfassend im Deliverable D13.2 aufgelistet. In ähnlicher Weise gilt diese beispiel-hafte Darstellung auch für technische Versuchsfälle, wobei in diesem Zusammenhang von Testfällen und von deren Konfigurationen bzw. Variationen die Rede ist.

Im Rahmen von AP41 werden basierend auf den Versuchsfallvarianten in einem weiteren Schritt sog. Versuchsszenarien definiert. Abbildung 69 zeigt einen kurzen beispielhaften Auszug für ein Versuchsszenario für den Anwendungsfall A_2.1.2.1 „Warnung vor Stauen-de“. Ein Versuchsszenario umfasst dabei eine konkrete und anschauliche Beschreibung, wie ein Versuchsfall bzw. dessen Variante umzusetzen ist. Zur leichteren Verständlichkeit und Bearbeitbarkeit der Versuchsszenarien soll eine weitgehend standardisierte Beschreibung gegeben werden, die in Form eines Drehbuchs dokumentiert und detailliert ausgearbeitet wird.

Unter einem „Versuchsszenario“ wird demzufolge als Arbeitsdefinition verstanden:

• Versuchsszenario: Präzisierung bzw. Konkretisierung eines Versuchsfalls bzw. einer Versuchsfallvariante (für nicht-technische Versuche) und/oder eines Testfalls bzw. dessen Konfiguration bzw. Variation (für technische Versuche)

• Beschreibung des Versuchsszenarios erfolgt in standardisierter Form mittels vordefi-nierter Attribute


• Zu jedem Versuchsszenario gehört ein Drehbuch

Die Festlegung, nach welchen Aspekten die Versuchsfälle konkretisiert werden, sowie die Definition der Attribute zur standardisierten Beschreibung werden in den kommenden Ar-beitsschritten des AP41 beschlossen.

Bei der Erstellung von Versuchsszenarien ist zudem zu unterscheiden, inwiefern Versuchs-fälle im Rahmen von TP4 planbar bzw. nicht-planbar sind. Zu den planbaren Versuchsfällen zählen solche, die im vornhinein experimentell herstellbar sind (z.B. Versuchsfälle des An-wendungsfalls A_2.2.2.1 Grüne Welle), zu den nicht-planbaren Versuchsfällen dementspre-chend nicht experimentell herstellbare Versuchsbedingungen (z.B. Versuchsfälle des An-wendungsfalls A_2.1.3.1 Warnung vor Wettergefahren). Ob ein Versuchsfall planbar ist oder nicht, hängt wesentlich von der Versuchsumgebung ab. So können beispielsweise auf dem geschlossenen Testgelände, in der Fahrsimulation und in der Verkehrssimulation Hindernis-se gezielt erzeugt werden, während diese Situation aus Sicherheitsgründen im Versuchsge-biet u.U. nicht gezielt erzeugt werden kann und darf (siehe auch Kap. 2.3.2).

14.2.2 Drehbuch und Drehbuchauszug (Arbeitsdefinition)

Abbildung 70 zeigt, wie die unter 14.2.1 beschriebenen Versuchsszenarien in sog. Drehbü-cher bzw. sog. Drehbuch-Auszüge umgesetzt werden: Aus einem Versuchsszenario wird mindestens ein Drehbuch erstellt. Unter einem Drehbuch versteht man in diesem Zusam-menhang alle Anweisungen, Anforderungen und Bedingungen, die für die Versuchsdurchfüh-rung eines Versuchsszenarios notwendig sind. Diese Anweisungen sind dermaßen konkret und detailliert, so dass die den Versuch durchführende Person weiß, was er/sie wann, wie und mit welchen Hilfsmitteln zu tun hat.

Aus dieser Kurzbeschreibung eines Drehbuchs wird unmittelbar ersichtlich, dass hier eine große Menge an Informationen gesammelt und aufbereitet werden muss. Um diese Informa-tionsmenge nachfolgend nutz- und verwendbar aufzubereiten, werden schließlich sog. Dreh-buchauszüge vorgesehen, die je nach Interessenten- bzw. Adressatengruppe angepasst werden. So erhält die versuchsdurchführende Person einen anderen Drehbuchauszug als die auswertende Person.

Abbildung 70: simTD-Begriffe – Erweiterung um Begriffe „Drehbuch“ bzw. „Drehbuch-Auszug“.

Unter einem „Drehbuch“ wird demzufolge als Arbeitsdefinition verstanden:

• Drehbuch: Genauer Ablaufplan für die Durchführung eines Versuchsszenarios.


• Drehbuch beinhaltet für alle Beteiligten alle Anweisungen für die Operationalisierung eines Versuchsszenarios.

• Drehbuch formuliert alle Anweisungen, Anforderungen und Bedingungen, die für die Durchführung eines Versuchsszenarios notwendig sind.

Unter einem „Drehbuchauszug“ wird demzufolge als Arbeitsdefinition verstanden:

• Drehbuchauszug: Teil eines Drehbuchs für einen bestimmten Adressaten.

• Verschiedene Adressaten (Fahrer, Operatoren, Auswerter etc.) erhalten verschiede-ne Teile bzw. Auszüge eines Drehbuchs

14.2.3 Übersicht der Arbeitsdefinitionen

Als Arbeitsdefinitionen für die neu in AP41 notwendigen Begriffe bleibt somit zusammenfas-send festzuhalten:

• Versuchsszenario: Präzisierung bzw. Konkretisierung eines Versuchsfalls bzw. einer Versuchsfallvariante

• Drehbuch: Genauer Ablaufplan für die Durchführung eines Versuchsszenarios

• Drehbuchauszug: Teil eines Drehbuchs für einen bestimmten Adressaten

Diese Arbeitsdefinitionen werden in das simTD-Glossar eingebracht.

14.3 Konzeption Drehbuch (Arbeitsstand: März 2010)

14.3.1 Einführung

Bereits zu Beginn der Konzeptionierung von Drehbüchern im Rahmen von AP41 Versuchs-design wurde offensichtlich, dass verschiedene Flotten (interne Flotte und externe Flotte) bzw. Versuchsumgebungen (Versuchsgebiet, Testgelände, Fahrsimulation und Verkehrssi-mulation) spezifische Drehbücher benötigen. In diesem Zusammenhang wurde definiert:

• Interne Flotte (Versuchsgebiet und Testgelände): Formulierung von ausführlichen Drehbüchern

• Externe Flotte: Verkehrliche und weitere Rahmenbedingungen sind nicht im Voraus explizit planbar bzw. aktiv herstellbar, daher benötigt v.a. AP43 Informationen in den Drehbüchern für die Datenaufbereitung und -auswertung

• Fahrsimulation: Erstellung von an den Anforderungen der Fahrsimulation angepass-ten Drehbüchern

• Verkehrssimulation: Erstellung von an den Anforderungen der Verkehrssimulation angepassten Drehbüchern

Vor Beginn der Drehbuch-Erstellung sind folgende Punkte zu diskutieren bzw. zu klären:

• Drehbücher sind über ein Datenbank-Konzept zu erstellen bzw. abzulegen.

• Drehbücher können mehrere Validierungsziele bzw. technische und nicht-technische Versuchsfälle gemeinsam abdecken.

• Verschiedene Validierungsziele benötigen z.T. gezielt unterschiedliche Drehbücher.

Diese Punkte werden nachfolgend diskutiert.


14.3.1.1 Datenbank-Konzept für Drehbücher In AP13 wurde für die nicht-technischen Versuchsfälle eine Versuchsfalldatenbank angelegt und befüllt (siehe Deliverable D13.2), die nun im Rahmen von AP41 entsprechend erweitert werden soll. Hierdurch soll die große Menge an Informationen, die in den Drehbüchern ge-sammelt und aufbereitet wird, handhabbar werden. Mit diesem Vorgehen wird angestrebt, eine weitgehende Standardisierung der Befüllung der Drehbücher zu erzielen.

Mit Arbeitsstand März 2010 ist folgendes Vorgehen geplant:

• Grundlage der Datenbank sind die Vorarbeiten im Rahmen von AP13, in dem eine erste Sammlung und Spezifikation von technischen und nicht-technischen Versuchs-fällen erfolgte (siehe Deliverable D13.2).

• In AP41 wird anhand dieser Vorarbeiten ein Konzept für eine gemeinsame Daten-bank von technischen und nicht-technischen Versuchsfällen erarbeitet. In dieser Da-tenbank können die Drehbücher erstellt, überarbeitet bzw. abgelegt werden.

• Die Datenbank wird über standardisierte Eingabemasken bedient. Hierfür ist die Kon-zeption eines einheitlichen Templates für die Erstellung von Drehbüchern (sowohl für die technischen als auch für die nicht-technischen Versuchsfälle) notwendig.

• Die Befüllung der Eingabemasken bei der Erstellung der Drehbücher erfolgt dezent-ral, d.h. in den Eingabemasken sind bestimmte Partner des simTD-Konsortiums für im Vorhinein definierte Felder zuständig (siehe unten).

• Die Steuerung des Befüllungsprozesses bis zur Erstellung des Deliverables D41.2 er-folgt zentral über die AP41-Leitung.

• Zeitnah zum Feldversuch sollen durch den gemeinsamen Unterauftragnehmer zur Versuchsdurchführung (AP42) diese Drehbücher aktualisiert und so kombiniert wer-den, dass im Rahmen von Versuchssitzungen geschlossene Routen entstehen. Ebenfalls ist eine Zuordnung der Drehbücher zu den verschiedenen Versuchsphasen zu diskutieren (z.B. welche Drehbücher bereits in der Vorversuchsphase beispielhaft befahren werden sollen, siehe Kap. 13.3).

• Die Erweiterung der Datenbank bzw. Erstellung der erforderlichen Eingabemasken erfolgt durch die Zusammenarbeit der AP41-Partner FhG-Fokus, TU Berlin, IZVW und TUM-VT.

Die Zuweisung der Konsortialpartner zu den vordefinierten Feldern der Eingabemaske zur Befüllung der Datenbank geschieht nach ihren Kernkompetenzen. Beispielhaft wären zu nennen:

• FFM, HLSV: Streckenplanung, zeitlich-räumliche Verortung der Drehbücher, organi-satorische Rahmenbedingungen sowie die Szenarioerstellung für technische Versu-che zum Thema Ausstattung.

• FETs: technische Randbedingungen (inkl. Logging), Definition der Szenarien (Szenarioerstellung) für die technischen Versuche der jeweils durch die FETs reali-sierten Funktionen (siehe Deliverable D13.2)

• IZVW, TUM-VT: Szenarioerstellung, Monitoring, Abbruchkriterien und Sofortprüfung der Drehbuch-Durchführung

• TUM-VT: verkehrliche Rahmenbedingungen

• IZVW mit FETs: Fahreranweisung und Fahrerbefragung

• Kommunikationsteam: Rahmenbedingungen sowie Kommunikationsversuche

• SIT IT-Sicherheitsversuche


Der im Rahmen von AP42 eingesetzte gemeinsame Unterauftragnehmer für die Versuchs-durchführung soll bei den o.g. Arbeiten einbezogen werden. Hierdurch wird eine reibungslo-se Übergabe zwischen AP41 und AP42 sichergestellt sowie eine hohe Qualität bei der Aktu-alisierung bzw. Durchführung der Drehbücher erreicht.

Um zu erreichen, dass die Drehbücher in vergleichbarer Qualität erstellt werden, wird der Befüllungsprozess der Drehbücher durch IZVW und TUM-VT koordiniert und gesteuert. Nach einer erstmaligen Befüllung der Eingabemasken wird durch horizontale Reviewprozesse (z.B. Vergleich der Inhalte von vordefinierten Feldern der Datenbank über verschiedene Drehbücher hinweg) und vertikale Reviewprozesse (z.B. Vergleich der Inhalte innerhalb ei-nes Drehbuchs) eine hohe Qualität der Drehbücher gewährleistet.

14.3.1.2 Gemeinsame Drehbücher für verschiedene Validierungsziele Aus Gründen der eingeschränkten Zeit- und Budgetressourcen bei der Versuchsdurchfüh-rung im Rahmen von AP42 ist zunächst zu prüfen, inwiefern ein und dasselbe Drehbuch

• simultan mehrere Validierungsziele und/oder

• technische und nicht-technische Versuchsfälle

gemeinsam abdecken kann. Wie in Deliverable D13.2 beschrieben, werden durch eine Ver-suchsfallvariante häufig zugleich mehrere nicht-technische Validierungsziele adressiert, d.h. dass auch die entsprechenden Drehbücher zugleich mehrere nicht-technische Validierungs-ziele adressieren werden (z.B. ein und derselbe Versuchsfall adressiert sowohl Nutzerakzep-tanz als auch die Fahr-/ Verkehrssicherheit und Fahr-/ Verkehrseffizienz).

Zudem ist anzunehmen, dass einige technische Versuchsfälle parallel zur Durchführung nicht-technischer Versuchsfälle laufen können (z.B. Dauerlogging von technischen Funktio-nen während Versuchen zur Fahr- / Verkehrssicherheit).

Es sind folgende Arbeitsschritte vorgesehen:

• Ausgehend von Deliverable D13.2 sind zunächst technische Versuchsfälle zu identifi-zieren, die in TP4 zu adressieren sind (siehe Kap. 2.1).

• Anschließend sind die für TP4 relevanten Versuchsfälle hinsichtlich inhaltlicher As-pekte (z.B. Zielsetzung, Versuchsschritte) zu beschreiben, um Überlappungen zwi-schen technischen und nicht-technischen Versuchsfällen zu identifizieren und die Menge notwendiger Versuchsszenarien und Drehbücher zu benennen.

Dieser Prozess findet parallel zur Erweiterung der Datenbank (siehe Kap. 14.3.1.1) statt.

14.3.1.3 Unterschiedliche Drehbücher für verschiedene Validierungsziele In ähnlicher Weise ist denkbar, dass verschiedene Validierungsziele z.T. gezielt unterschied-liche Drehbücher benötigen. So ist beispielsweise für den Anwendungsfall A_2.2.2.1 Grüne Welle denkbar, dass ein Drehbuch gezielt die Nutzerakzeptanz zum Ziel hat, ein zweites Drehbuch hingegen explizit die Fahr- und Verkehrssicherheit. In erstgenanntem Beispiel würde z.B. in einem Drehbuch definiert, dass eine Gruppe von Fahrern wenige Male durch einen entsprechend ausgestatteten Teil des simTD-Versuchsgebiets (ohne gezielte weitere Instruktion) fährt und anschließend befragt wird. Im zweiten Beispiel wären demgegenüber Drehbücher angezeigt, bei denen größere Fahrzeugmengen mehrfach (d.h. im Sinne eines Rundparcours) die entsprechenden mit LSA ausgestatteten Streckenabschnitte befahren. Wie aus diesem Beispiel ersichtlich wird, ergeben sich hieraus unterschiedliche Anforderun-gen an die inhaltliche Ausgestaltung der Drehbücher.

Die weiteren Schritte zur Identifikation entsprechender Versuchsfälle und Erstellung von Drehbüchern laufen parallel zum unter Kap. 14.3.1.2 skizzierten Vorgehen.


14.3.2 Arbeitsstand Drehbücher für interne Flotte

Eine erste Sammlung der Inhalte eines Drehbuchs für die interne Flotte wird im Folgenden dargestellt.

Wichtige Vorbemerkung: Die nachfolgende Auflistung ist beispielhaft, d.h. weder vollstän-dig noch umfassend. Sie wird im Rahmen der nächsten Arbeitsschritte im Rahmen von AP41 weiter ausgearbeitet, so dass die Inhalte nicht final abgestimmt sind.

1. Drehbuch-ID

2. Rahmenbedingungen aus AP13

a. Beschreibung des Anwendungsfalls

b. IDs der technischen und nicht-technischen Versuchsfallvarianten (aus der Versuchsfall-Datenbank) und der technischen Testkonfiguration

c. Nicht-technische und technische Validierungsziele, die im Drehbuch unter-sucht werden sollen

d. Versuchsschritte (aus der Versuchsfall-Datenbank)

3. Notwendige Vorbedingungen

a. Nicht- oder schlecht planbare Bedingungen, für die das laufende (geplante) Drehbuch abgebrochen werden darf (z.B. Wetterwarnung ist nicht planbar). Daher ist es u.U. sinnvoll, ein ausgeführtes planbares Drehbuch abzubrechen, um die Wetterwarnung zu untersuchen, wenn die äußeren Gegebenheiten dies zulassen).

b. Versuchsfälle, die nicht parallel laufen dürfen: Welche Versuchsfälle dürfen nicht parallel (d.h. während des Drehbuchs in einem anderen, gleichzeitig stattfindenden Drehbuch mit anderen Versuchsfahrern) im Versuchsgebiet durchgeführt werden?

c. Zu deaktivierende simTD-Anwendungsfälle: Welche simTD-Anwendungsfälle führen evtl. zu Interferenzen mit dem jeweils aktuell zu prüfenden simTD-Anwendungsfall und sollen daher in den teilnehmenden Fahrzeugen deakti-viert werden?

d. Verkehrliche Randbedingungen

e. Technische Randbedingungen

f. Welche Fahrzeuge dürfen nicht parallel im Versuchsgebiet unterwegs sein?

g. Wetterbedingungen, die für die Durchführung des Drehbuchs eine Vorausset-zung sind.

4. Vorplanung / Ressourcenplanung

a. Aktoren: Was sind die notwendigen Aktoren (z.B. Initialfahrzeug, Gruppe der Fahrer, die eine Information/Warnung erhält, IRS, ICS, Navigationssystem) des Versuchsfalls (aus der Versuchsfall-Datenbank)?

b. Fahrer: Was sind die Anforderungen an die Stichprobe des Drehbuchs (z.B. Anzahl, Alter, Geschlecht)?

c. Fahrzeuge: Was sind die Anforderungen an die Fahrzeuge des Drehbuchs?

d. Routenplanung: Wo sind Start- und Zielpunkt der Route? Gibt es eine vorher festgelegte Route zwischen diesen beiden Punkten? Wie lautet ggf. diese Route?


e. Termin: Wie lange wird der Versuch geschätzt dauern? Wann (Wochentag, Tageszeit) soll der Versuch stattfinden?

f. Organisatorische Rahmenbedingungen: Welche weiteren Vorkehrungen müs-sen getroffen werden? Welche Informationen müssen bei den beteiligten Per-sonen vorliegen?

5. Eingaben Fahrerein- bzw. Fahreranweisung

a. Testablaufplanung: Angabe der Fahrerein- und Fahreranweisung für die ein-zelnen Fahrer bzw. Fahrergruppen

b. Fahrereinweisung: Wie soll die Einweisung in die entsprechende Aufgabe für die einzelnen Fahrer oder die gesamte Gruppe aussehen?

c. Fahreranweisung: Welche weiteren Anweisungen sollen die Fahrer (z.B. wäh-rend der Fahrt) erhalten?

6. Messgrößen und Logging (aus der Versuchsfall-Datenbank)

7. Fahrerbefragung

a. Befragung z.B. hinsichtlich Situationsbewertung oder Instruktionsbestätigung

8. On-line Protokollierung

a. Bspw. Protokollierung der Versuchskenngrößen, der Messpunkte (Schwellen-werte/Grenzwerte) und Wetterereignisse während des Versuchs

9. Abbruchkriterien für die Drehbuchdurchführung

a. Fahrzeug: Der Fahrer nimmt nicht weiter am entsprechenden Versuch teil, wenn das Fahrzeug defekt ist oder ein Unfall passiert ist, an dem der Fahrer beteiligt war.

b. Fahrer: Erkrankt der Fahrer bspw. während der Fahrt, so kann er den ent-sprechenden Versuch abbrechen.

c. Ausfall HMI: Der Versuch wird abgebrochen, wenn das HMI ausfällt.

d. Ausfall IVS: Der Versuch wird für den entsprechenden Fahrer bzw. das ent-sprechende Fahrzeug abgebrochen.

e. Ausfall Logdaten: Der Versuch wird für den entsprechenden Fahrer bzw. das Fahrzeug abgebrochen.

10. Entscheidung bzgl. der erfolgreichen Durchführung des Drehbuchs z.B. hinsichtlich

a. Technik: Überprüfung, ob die beteiligte Technik richtig funktioniert hat (z.B. IVS, HMI, Testsystem).

b. Logdaten: Überprüfung, ob und in welcher Form die Daten vorliegen.

c. Erreichen notwendiger Stichprobengröße: Die Gesamtsumme notwendiger Datensätze wird im Vorhinein festgelegt.

14.3.3 Externe Flotte

• Die Versuche für die externe Flotte sind in ihrem Ablauf nicht konkret planbar, da sich die externe Flotte frei innerhalb und außerhalb des Versuchsgebiets bewegen wird (siehe Kap. 8). Somit ergeben sich an die Drehbücher für die externe Flotte andere Anforderungen als für die interne Flotte: Die Drehbücher der externen Flotte legen beispielsweise fest, in welcher Form eine Zuteilung der Fahrzeuge zu unterschiedli-


chen Gruppen geschehen soll und welche Daten aufgezeichnet werden sollen (Messgrößen). So kann es sinnvoll sein, dass die eine Gruppe nur den einen Teil der Anwendungsfälle "erlebt", und die andere Gruppe den anderen Teil. Es ist denkbar, die Gruppen nach einer bestimmten Zeit zu tauschen.

• Ein wesentlicher Inhalt der Drehbücher für die externe Flotte wird zudem das Auswer-tungskonzept der Versuche sein, das in enger Zusammenarbeit mit AP43 Auswer-tung und Analyse erarbeitet wird.

Im Deliverable D41.2 „Versuchsplan 2.0“ werden entsprechende Drehbücher für die externe Flotte enthalten sein.

14.3.4 Fahrsimulation

Ausgehend von den in AP13 spezifizierten nicht-technischen Versuchsfällen und Versuchs-fallvarianten werden in AP41 Versuchsszenarien und Drehbücher für die Fahrsimulation ab-geleitet. Die Anforderungen an Versuchsszenarien und Drehbücher in der Fahrsimulation unterscheiden sich jedoch von denen für die interne Flotte: Verkehrliche Rahmenbedingun-gen (z.B. Verkehrsdichten, Verkehrsgeschwindigkeiten) und straßenbauliche Rahmenbedin-gungen (z.B. Anzahl Fahrstreifen, Steigungen/Gefälle, Krümmungen) sowie für die Untersu-chung relevante Ereignisse (z.B. Hindernisse, Baustellen) können in der Fahrsimulation ge-zielt hergestellt werden. Diese werden in ähnlicher Weise zum in Kap. 14.3.2 skizzierten Vorgehen auch für die Fahrsimulation in Form von Drehbüchern dargestellt. Aufgrund des Versuchsaufbaus unter kontrollierten Bedingungen gibt es in der Fahrsimulation keine nicht-planbaren Szenarien.

Für jeden Versuchsfall bzw. jede Versuchsfallvariante in der Fahrsimulation entstehen so konkrete Szenarien, die jeweils in Drehbüchern festgehalten werden. Sie umfassen u.a. fol-gende Informationen:

• Beschreibung des Versuchsfalls bzw. der Versuchsfallvariante

• Beschreibung und Spezifikation des Fahrsimulationsszenarios (inkl. Beschreibung der jeweiligen Prüfsituation)

• Handlungsanweisungen für alle beteiligten Personen (Fahrer, Versuchsleiter)

• Messgrößen, die für die Auswertung der aktuellen Fahrsimulation benötigt werden.

Das Design eines Versuchsszenarios in der Fahrsimulation für den Anwendungsfall A_2.1.1.2 Warnung vor liegengebliebenem Fahrzeug kann so z.B. folgende Informationen umfassen:

• Fahrstreifenbreite: 3.50m (2-streifige Fahrbahn), Landstraße

• Länge des Streckenabschnitts: 1500m Gerade (1000m), Rechtskurve (Länge 250m, r=1800m), Linkskurve (Länge 250m, r=1800m)

• Kein Gegenverkehr

• Richtgeschwindigkeit: 100km/h

• Warndreieck des liegengebliebenen Fahrzeugs steht bei Streckenmeter 400m rechts neben dem Fahrstreifen.

• Liegengebliebenes Fahrzeug (Maße: 3.90m/1.70m) steht bei Streckenmeter 500. Warnblinker ist an.

• Fahrer hat Aufgabe das Hindernis zu umfahren, dabei StVO in vollem Umfang zu be-folgen und weder sich noch andere zu gefährden.


Abbildung 71 zeigt beispielhaft für dieses hier skizzierte Szenario einen Screenshot der Fahrsimulation des Würzburger Instituts für Verkehrswissenschaften (WIVW GmbH), in de-ren Simulation die Fahrversuche stattfinden werden.

Abbildung 71: Screenshot einer beispielhaften Fahrsituation „Liegengebliebenes Fahrzeug“ der Fahrsimulation der WIVW GmbH.

Die Beschreibungen der Drehbücher für die Fahrsimulation sind weniger detailliert als dieje-nigen für die interne Flotte, da nur ein kleiner Personenkreis diese Vorgaben umsetzen wird. Diesem Personenkreis ist der grundsätzliche Umgang mit der Simulationsumgebung sowie den Versuchsfahrern vertraut.

Das Design der Szenarien und Drehbücher erfolgt am IZVW der Universität Würzburg in Ab-stimmung mit den Funktionsentwicklungsteams sowie dem Unfallforscherteam. Zugleich werden Anforderungen von Seiten des Lehrstuhls für Verkehrstechnik der TU München be-rücksichtigt, deren Verhaltensmodellierung der Verkehrssimulation auf den Ergebnissen der Fahrsimulatorstudien aufbaut.

14.3.5 Verkehrssimulation

Auch für die Verkehrssimulation wurden im Rahmen der Arbeiten in AP13 Versuchsfälle zu den in der Verkehrssimulation zu realisierenden Anwendungsfällen definiert. Konkretere Rahmenbedingungen wurden dabei anhand von Versuchsfallvarianten spezifiziert. Aus die-sen Versuchsfallvarianten sind analog zum Feldversuch Versuchsszenarien und Drehbücher abzuleiten.

Die Anforderungen an Versuchsszenarien und Drehbücher für die Verkehrssimulation unter-scheiden sich jedoch von denen für die interne Flotte: Verkehrliche und technische Rahmen-bedingungen sowie für die Untersuchung relevante Ereignisse (wie etwa ein Hindernis oder eine Baustelle) können in der Verkehrssimulation gezielt hergestellt werden. Dies ermöglicht exakte Angaben für die Parameter und Stellgrößen, die als Randbedingungen für eine simulative Untersuchung angenommen werden. Kap. 5.2 beschreibt das Vorgehen im Rah-men einer solchen Verkehrssimulationsstudie.

Aufgrund des Versuchsaufbaus unter kontrollierten Bedingungen gibt es in der Verkehrssi-mulation keine nicht-planbaren Szenarien (vgl. Kap. 14.2.1).

Folgendes Beispiel fasst zunächst eine ausgewählte Versuchsfalldefinition aus AP13 zu-sammen:

Anwendungsfall 2.1.1.2 Liegengebliebenes Fahrzeug


→ Versuchsfall N_A_2.1.1.2_VS01 für die Verkehrssimulation

→ Versuchsfallvariante N_A_2.1.1.2_VS01_Ad12P_b mit folgenden Randbedingungen:

• Streckenart: Autobahn

• Verkehrszustand: Dicht

• Übertragungsmedium: ITS G5A

• Vorbedingung: Hindernis nicht einsehbar (z.B. hinter einer Kurve)

• Ausstattungsrate IVS: Niedrig

• Ausstattungsdichte IRS: Mittel

Die Konkretisierung dieser Versuchsfallvariante zu einem Versuchsszenario, das anschlie-ßend in AP41 erfolgen soll, ergibt sich beispielhaft aus den (fiktiven und unvollständigen) Angaben in Tabelle 32. Tabelle 32: Konkretisierung einer Versuchsfallvariante zu einem Simulationsszenario.

Randbedingung Versuchsfallvariante

Konkretisierung im Verkehrssimulationsszenario

• Streckenart: Autobahn • Nicht einsehbare Kurve • Ausstattungsdichte IRS: Mittel

Netzausschnitt A661, km 308 bis km 314 (Annahme: Simulationsnetz des Versuchsgebietes liegt vollständig vor)

Verkehrszustand: Dicht Auslastungsgrad für den o.g. Streckenabschnitt (Ver-hältnis der Verkehrsstärke am Querschnitt des Stre-ckenbeginns zur Streckenkapazität): 0.9

Übertragungsmedium: ITS G5A Hier keine Konkretisierung notwendig

Vorbedingung: Liegengebliebenes Fahrzeug, Hin-dernis nicht einsehbar

Liegengebliebenes Fahrzeug im Laufe der Simulation mit folgenden Angaben: • Zeitpunkt, zu dem das Fahrzeug liegenbleibt: 7min

nach Verkehrssimulationsbeginn • Strecke, auf dem das Fahrzeug liegenbleibt:

A661 Richtung Bad-Homburger Kreuz • Genaue Position auf der Strecke:

km 30.5 • Nr. des Fahrstreifens auf der Strecke: 1

Ausstattungsrate IVS: Niedrig Anteil von C2X-Fahrzeugen auf der relevanten Stre-cke, die an der Kommunikation beteiligt sind: 5%

Für jeden einzelnen Verkehrssimulations-Versuchsfall entstehen so konkrete Szenarien, die jeweils in Drehbüchern festgehalten werden. Ein Drehbuch in der Verkehrssimulation kann als komplette Anleitung für die Durchführung einer Verkehrssimulationsstudie für ein be-stimmtes Szenario verstanden werden. Es umfasst folgende Informationen:

• Beschreibung des Versuchsfalls

• Beschreibung und Spezifikation des Verkehrssimulationsszenarios

• Hinweise für die Eingabe der relevanten Parameter in das Verkehrssimulationstool


• Messgrößen, die für die Auswertung der aktuellen Verkehrssimulation benötigt wer-den. Dabei ist die weitere Verwendung der Messgrößen nicht näher spezifiziert, da dies Teil eines separaten Auswertungskonzeptes sein wird.

Die Beschreibungen der Drehbücher für die Verkehrssimulation sind dabei weniger detailliert als diejenigen für die interne Flotte, da nur ein kleiner Personenkreis diese Vorgaben umset-zen wird, denen der grundsätzliche Umgang mit der Simulationsumgebung vertraut ist.

Das Design der Szenarien und Drehbücher erfolgt am Lehrstuhl für Verkehrstechnik der TU München in Abstimmung mit den Funktionsentwicklungsteams sowie der Universität Würz-burg, deren Fahrsimulatorstudien eine Grundlage für die Fahrverhaltensmodellierung in der Verkehrssimulation bildet.


15 Fazit

15.1 Rückblick

Als Zielsetzungen von Deliverable D41.1 „Versuchsplan 1.0“ wurden in Kap. 1.1 folgende Aspekte genannt:

• Dokumentation des aktuellen Diskussionsstands in AP41 Versuchsdesign zu ver-suchsrelevanten Fragestellungen

• Identifikation von Schnittstellen zu den weiteren Teilprojekten in simTD

• Herstellung einer gemeinsamen Grundlage für weitere Arbeiten in AP41 mit dem Ziel der Erstellung des Deliverable D41.2 „Versuchsplan 2.0“

Anmerkung: Das vorliegende Deliverable D41.1 stellt den Arbeitsstand März 2010 dar.

Vor diesem Hintergrund wurden von Autoren mehrerer simTD-Konsortialpartner die folgenden Themenblöcke im Rahmen von D41.1 dargestellt:

• Vorarbeiten zur Erstellung eines Prüfkonzepts (siehe Kap. 2)

• Übersichten über Versuchsgebiet, Testgelände, Versuchsflotten und Simulationslabor (siehe Kap. 3 bis 6)

• Anmerkungen zu empirischen Versuchen mit der internen bzw. externen Flotte (siehe Kap. 7 und 8)

• Darstellung der technischen Rahmenbedingungen (siehe Kap. 9 bis 13)

• Aktueller Diskussionsstand bei der Erstellung der Drehbücher für die Versuchsdurch-führung in TP4 (siehe Kap. 14)

Nachfolgend werden in Kap. 15.2 die zentralen Ergebnisse dieser Themenblöcke kurz dar-gestellt.

15.2 Schlussfolgerungen

15.2.1 Vorarbeiten zur Erstellung eines Prüfkonzepts

Im Rahmen von Kap. 2 werden folgende zentrale Argumente erarbeitet:

• Im Rahmen des Forschungsprojekts simTD werden 21 C2X-Funktionen mit insgesamt 36 Anwendungsfällen entwickelt. Für die Durchführung von technischen und nicht-technischen Versuchen wurden in AP13 wesentliche Vorarbeiten geleistet, die in De-liverable D13.2 festgehalten und unter Kap. 2.1 nochmals zusammenfassend darge-stellt sind.

• Die Anzahl an technischen und nicht-technischen Versuchsspezifikationen, wie sie in AP13 ermittelt wurde, sprengt die verfügbaren Ressourcen für die Versuchsdurchfüh-rung im Rahmen von TP4, so dass nicht alle spezifizierten Versuchsfälle empirisch geprüft werden können. Aus diesem Grund wird in Kap. 2.5 ein mehrstufiger Ent-scheidungsprozess vorgeschlagen, um die technischen und nicht-technischen Ver-suchsfälle zu priorisieren.

• Unter Kap. 2.2 werden Möglichkeiten und Grenzen der Versuchsumgebungen hin-sichtlich der Versuchsdurchführung und -auswertung diskutiert. In Kap. 2.3 erfolgt


schließlich durch die beteiligten Straßenverkehrsbehörden eine Einschätzung, inwie-fern experimentelle Manipulationen zur empirischen Überprüfung der simTD-Anwendungsfälle im Versuchsgebiet zulässig sind bzw. weitere Genehmigungen be-nötigt werden.

• In Kap. 2.4 wird ein 7-stufiges Vorgehen beschrieben, um die technischen und nicht-technischen Versuchsfälle in die Drehbücher zu integrieren. Hierdurch soll ein ge-meinsames, integriertes Vorgehen für technische und nicht-technische Versuche im Rahmen von TP4 ermöglicht werden.

• Für eine Abschätzung, wie oft ein Versuch mit der internen Flotte durchzuführen ist bzw. wie viele Ereignisse in der externen Flotte notwendig sind, so dass zuverlässige Ergebnisse erzielt werden, werden in Kap. 2.6 methodologische Argumente zur Ver-suchsplanung und Ergebnisinterpretation dargestellt. Es wird herausgearbeitet, dass die Schätzung der sog. optimalen Stichprobe diesbezüglich als Hauptargument her-anzuziehen ist. Es werden weitere Handlungsschritte für eine umfassende methodo-logische Bewertung sowohl der internen Flotte als auch der externen Flotte in simTD beschrieben.

• In Kap. 2.7 wird schließlich dargestellt, dass sowohl die interne als auch die externe Flotte zu einer erheblichen Verbesserung der Verkehrslageermittlung im Vergleich zu einem System, das ausschließlich auf stationärer Verkehrsdatenerfassung aufbaut, beiträgt.

15.2.2 Übersichten über Versuchsgebiet, Testgelände, Versuchsflotten und Simula-tionslabor

In Kap. 3 bis 6 werden in Überblicksform nachfolgende Informationen gegeben:

• In Kap. 3 wird die Standortplanung für die ITS Roadside Stations (IRS) im Versuchs-gebiet beschrieben. Für das Versuchsgebiet werden zudem Detailinformationen für versuchsrelevante Aspekte festgehalten (sog. Points-of-Interest, POI) und über ein Videotool dem simTD-Konsortium zur Verfügung gestellt.

• Für die Verortung der technischen und nicht-technischen Versuchsfälle im Versuchs-gebiet wird unter Kap. 3.4 ein Konzept für das weitere Vorgehen dargestellt.

• Unter Kap. 4 werden das Testgelände bzw. unter Kap. 5 die Konzeption des Simula-tionslabors aus Sicht der Versuche von TP4 dargestellt. Eine Übersicht über die im Rahmen von TP4 eingesetzten Versuchsflotten liefert Kap. 6.

15.2.3 Anmerkungen zu empirischen Versuchen mit der internen bzw. externen Flotte

In Kap. 7 und 8 werden die Zielsetzungen der internen bzw. externen Flotte sowie die Anfor-derungen an die Flotten beschrieben. Basierend auf Deliverable D13.2 wird gezeigt, welche Anwendungsfälle geplant sind. Abschließend werden die Anforderungen der Datenauswer-tung an die interne Flotte dargestellt. Es werden folgende Argumente hervorgehoben:

• Für die Rekrutierung der Fahrer der internen Flotte werden zwei Konzepte diskutiert (siehe Kap. 7.1.2): Ein Konzept mit festangestellten Versuchsfahrern oder alternativ ein Konzept mit einem Versuchsfahrerpanel (Datenbankkonzept).

• In der internen Flotte wird durch die aktive Steuerung der Fahrer möglicherweise ein spezielles Fahrverhalten realisiert (siehe Kap. 7.3.1), in der externen Flotte hingegen


nicht (siehe Kap. 8.3.1). Hierdurch können Unterschiede zwischen Ergebnissen der internen und der externen Flotte resultieren.

• Die technische Ausstattung der Fahrzeuge ist mitverantwortlich für Umfang und Güte der Ergebnisse der technischen und nicht-technischen Versuche. So ist z.B. für die Erfassung der Fahr- und Verkehrssicherheit eine Abstandssensorik notwendig, die für die externe Flotte nicht vorgesehen ist (siehe Kap. 7.3.2 und 8.3.2).

• Die Auswahl von potenziellen lokalen Partnern, die Teil der externen Flotte sein kön-nen, hat evtl. einen erheblichen Einfluss auf die aus der externen Flotte generierbaren Aussagen zur Wirksamkeit der C2X-Technologie (siehe Kap. 8.3.4). In diesem Zusammenhang sind Möglichkeiten zur Incentivierung zu prüfen, um den po-tenziellen lokalen Partnern einen Anreiz für die Teilnahme an den simTD-Versuchen zu bieten (siehe Kap. 8.3.5).

15.2.4 Darstellung der organisatorischen und technischen Rahmenbedingungen

In den Kap. 9 bis 13 werden Rahmenbedingungen der simTD-Versuche dargestellt, die erheb-lich die Möglichkeiten und den Erfolg der Versuchsdurchführung beeinflussen:

• Anforderungen an Inhalte und Personal der Fahrerbetreuung, die zum Gelingen der Versuche beitragen, werden unter Kap. 9 formuliert.

• In Kap. 10 wird dargestellt, wie die Versuchszentrale, die räumlich auf dem Gelände der Verkehrszentrale Hessen angesiedelt ist und in der vor allem die Versuchskoor-dination stattfindet, und der Versuchsflottenstützpunkt, in dem die Versuchsorganisa-tion stattfindet, voneinander abgegrenzt werden können.

• Kap. 11 skizziert in Kürze die Datenaufzeichnung und -übertragung im Rahmen des simTD-Feldversuchs. Es werden hier v.a. für die versuchsdurchführenden Personen Hinweise gegeben, welche Daten im Rahmen des Monitoring und Logging anfallen werden und wie diese verfügbar sind.

• Der Prozess der Versuchsdurchführung wird schließlich durch eine Reihe von Werk-zeugen unterstützt. Diese setzen bereits bei der Erstellung und Planung der einzel-nen Drehbücher an und unterstützen die Versuchsdurchführung. Kap. 12 gibt einen kurzen Überblick über die Werkzeuge und veranschaulicht, wie diese Werkzeuge im Versuchsalltag in simTD unterstützend eingesetzt werden können.

• Eine Begriffsdefinition und inhaltliche Abgrenzung von Pilotversuchen und Vorversu-chen erfolgt in Kap. 13. In diesem Zusammenhang wird auch die Schnittstelle zu TP3 und den dort durchgeführten Tests in der Optimierungsphase adressiert.

15.2.5 Aktueller Diskussionsstand bei der Erstellung der Drehbücher für die Ver-suchsdurchführung in TP4

In Kap. 14 wird abschließend das Konzept für die Erstellung der Drehbücher skizziert. Die konkreten Ausformulierungen der Drehbücher werden im weiteren Verlauf von AP41 vorge-nommen und im Rahmen des Deliverables D41.2 „Versuchsplan 2.0“ dokumentiert.

Vor Beginn der Drehbuch-Erstellung werden folgende Punkte diskutiert (siehe Kap. 14.3.1):

• Drehbücher sind über ein Datenbank-Konzept zu erstellen bzw. abzulegen.

• Drehbücher können mehrere Validierungsziele bzw. technische und nicht-technische Versuchsfälle gemeinsam abdecken.


• Verschiedene Validierungsziele brauchen z.T. gezielt unterschiedliche Drehbücher.

Es wird unter Kap. 14.3.1.1 ein Vorgehen mit sieben Arbeitsschritten (z.B. Entwicklung von standardisierten Eingabemasken für die Datenbank, Befüllung der Eingabemasken dezentral über vorher definierte Partner des simTD-Konsortiums) vorgeschlagen. Eine erste Sammlung der Inhalte eines Drehbuchs für die interne Flotte wird beispielhaft in Kap. 14.3.2 dargestellt.

15.3 Ausblick

Die im vorliegenden Deliverable D41.1 „Versuchsplan 1.0“ enthaltenen Informationen stellen den aktuellen Diskussionsstand (März 2010) dar und werden im weiteren Verlauf von AP41 Versuchsdesign weiter ausgearbeitet. Die unter Kap. 1.3 kurz skizzierte Einbettung von D41.1 in das Projekt simTD macht deutlich, dass das Deliverable D41.1. Grundlage für zahl-reiche weitere Arbeiten ist:

• Grundlage für weitere Abstimmungen zwischen dem AP41-Team und Ansprechpart-nern von TP2 und TP5

• Grundlage für die Ausplanung des Versuchsgebiets in AP44 (inkl. Festlegung der IRS Positionen)

• Grundlage für die Erstellung der Drehbücher für die Durchführung von technischen und nicht-technischen Versuchen mit Ziel der Erstellung des Deliverable D41.2 bzw. der Ermöglichung der Versuchsdurchführung in AP42 (Flottenverwaltung, Versuchs-durchführung und Integration) und AP44 (Aufbau und Betrieb Infrastruktur und Ver-suchszentrale)

• Grundlage für Planungen zur Datenauswertung für AP43 (Auswertung und Analyse)


Anhang

Anhang 1: Durchführbarkeit von Versuchsfällen bei Eingriff in den Stra-ßenverkehr

Tabelle 33: Versuchsfälle für A_2.1.1.5 Hindernisse auf der Fahrbahn.

A_2.1.1.5 Hindernisse auf der Fahrbahn

Versuchsobjekt Funktion F_2.1.1

Abgeleitet von A_2.1.1.5

Beziehungen zu anderen Funktionen/ Anwendungsfällen

A_1.1.5.2 Identifikation von ungeplanten Verkehrsereignissen A_1.2.1.3 Ortsbezogene Anzeige von Hindernissen A_1.2.2.1 Streckengeometrie im Umfeld der Baustelle A_1.2.2.2 Verkehrslage im Umfeld der Baustelle A_2.2.1.1 Verkehrszeichenanzeige im Fahrzeug

Beschreibung des Anwendungsfalls

Es wird eine Warnmeldung über Hindernisse auf der Fahrbahn gesendet. Auslöser hierfür sind eine automatische Detektion anhand einer Analyse von Ausweichmanövern oder Fahrereingaben über das simTD-HMI (spezi-fisch, d.h. Auswahl aus Liste, z.B. verlorene Ladung, Erdrutsch, Wind-bruch, Personen, Tiere oder Wild). Die Meldung kann auch von Polizei und Rettungsdiensten erzeugt werden. Die Meldung wird an den nachfolgen-den Verkehr weitergeleitet und über eine Warnung dargestellt (Hindernis auf oder neben der eigenen Fahrbahn).

Versuchsumge-bung/-ort

Feld - interne Flotte

Versuchsschritte Rechtlich noch zu klären!! 1. Ein Hindernis liegt auf der Fahrbahn, die Fahrzeuge zweier Gruppen fahren auf das Hindernis zu. 2. Die Fahrer der ersten Gruppe erhalten eine Warnung vor dem Hindernis. Die Fahrer der zweiten Gruppe erhalten keine Warnung 3. Vergleich der beiden Gruppen. Die Fahrzeuge beider Gruppen beteiligen sich an der Kommunikation und es werden für die Auswertung relevante Daten geloggt (auch wann die Fahrer der zweiten Gruppe eine Warnung erhalten hätten).

Aktoren

Initialfahrzeug Ausgestattetes Fahrzeug sendet Meldung: Auslöser hierfür sind z.B. auto-matische Detektion (aufgrund von Ausweichmanövern) oder eine manuelle Meldung durch den Fahrer. Die Meldung kann auch von Polizei und Ret-tungsdiensten erzeugt werden.

Fahrzeuge mit In-formation/Warnung

Das Fahrzeug empfängt die Warnung vor dem Hindernis und sendet die Information an umgebende Fahrzeuge und an die IRS. Die Fahrer nähern sich dem Hindernis und werden vor diesem gewarnt

Fahrzeuge ohne Information/ War-nung

Das Fahrzeug empfängt die Warnung und sendet die Information an um-gebende Fahrzeuge und an die IRS. Die Fahrer nähern sich dem Hindernis und erhalten keine Warnung.


A_2.1.1.5 Hindernisse auf der Fahrbahn

IRS Erhält Hinderniswarnung von der ICS. Leitet von der ICS an die IVS/Fahrer in der Umgebung des Hindernisses weiter.

ICS Gemeldete Hindernisse werden in der ICS gesammelt.

Navigationssystem Dynamische Routenberechnung deaktiviert. (Es werden keine alternativen Routen aufgrund von möglichen Behinde-rungen oder Veränderungen in der Reisezeit berechnet (sonst wird mögli-cher Stau umfahren). Baustellen dürfen nicht angezeigt werden (falls möglich))

Infrastrukturseitige Komponenten

Hier nicht relevant

Sonstige Aktoren Hindernis muss auf Straße gestellt werden

Tabelle 34: Versuchsfälle für A_2.1.1.2 Warnung vor liegengebliebenem Fahrzeug.

A_2.1.1.2 Warnung vor liegengebliebenem Fahrzeug




A_1.1.2.1 Bereitstellung der Reiseziele A_1.1.5.2 Identifikation von ungeplanten Verkehrsereignissen A_1.2.1.3 Ortsbezogene Anzeige von Hindernissen


Das liegengebliebene Fahrzeug (z. B. nach Unfall oder Panne) sendet eine Warnmeldung aus. Auslöser hierfür sind bestimmte Fahrzeugzustände (z. B. Airbag-, eCall-Auslösung, Warnblinklicht), die Meldung kann aber auch manuell durch den Fahrer erfolgen (über simTD-HMI). Zusätzlich werden über kritische Ausweichmanöver des Initialfahrzeugs liegengebliebene Fahrzeuge geschätzt. Die Meldung wird an den nachfolgenden Verkehr weitergeleitet und über eine Warnung dargestellt (Liegengebliebenes Fahrzeug auf oder neben der eigenen Fahrbahn).

Versuchsschritte Rechtlich noch zu klären! 1. Ein liegengebliebenes Fahrzeug ist vorhanden (=Initialfahrzeug), die Fahrzeuge zweier Gruppen fahren auf das liegengebliebene Fahrzeug zu. 2. Die Fahrer der Fahrzeuge der ersten Gruppe erhalten eine Warnung vor liegengebliebenem Fahrzeug. Die Fahrer der zweiten Gruppe erhalten keine Warnung 3. Vergleich der beiden Gruppen. Die Fahrzeuge beider Gruppen beteiligen sich an der Kommunikation und es werden für die Auswertung relevante Daten geloggt (auch wann die Fahrer der zweiten Gruppe eine Warnung erhalten hätten).

Aktoren

Initialfahrzeug Ausgestattetes Fahrzeug gibt sich als liegengebliebenes Fahrzeug aus und sendet Meldung an benachbarte IRS und IVS.


A_2.1.1.2 Warnung vor liegengebliebenem Fahrzeug


Das Fahrzeug empfängt die Warnung vor liegengebliebenem Fahrzeug und sendet die Information an umgebende Fahrzeuge und an die IRS. Die Fahrer nähern sich dem liegengebliebenem Fahrzeug und werden vor diesem gewarnt.


Das Fahrzeug empfängt die Warnung und sendet die Information an um-gebende Fahrzeuge und an die IRS. Die Fahrer nähern sich dem liegengebliebenem Fahrzeug und erhalten keine Warnung.

IRS Die IRS empfängt / sendet die Information, sie hat keinen Funktionsanteil

ICS In der ICS ist die genaue Information über das liegengebliebene Fahrzeug bekannt und wird kontinuierlich mitgepflegt und aktualisiert. Sie hat keinen Funktionsanteil

Navigationssystem Bleibt für diesen Versuchsfall deaktiviert. (Dynamische Routenberechnung deaktiviert: Es werden keine alternativen Routen aufgrund von Hindernissen berechnet Hindernisse dürfen nicht angezeigt werden)


Hier nicht relevant

Sonstige Aktoren Hier nicht relevant

Tabelle 35: Versuchsfälle für A_2.1.1.4 Baustellenwarnung.

A_2.1.1.4 Baustellenwarnung




A_1.1.5.1 Identifikation von geplanten Verkehrsereignissen A_1.2.2.1 Streckengeometrie im Umfeld der Baustelle A_1.2.2.2 Verkehrslage im Umfeld der Baustelle A_2.2.1.1 Verkehrszeichenanzeige im Fahrzeug


Eine Warnbake auf einem Fahrzeug (Wanderbaustelle) meldet sicherheits-relevante Informationen (z.B. Spursperrung, lokale Geschwindigkeitsbe-schränkung, verschmutzte oder glatte Fahrbahn). Eine stationäre Warnbake am Beginn einer Baustelle meldet sicherheitsrelevante Informa-tionen (d.h. Vorhandensein und Position der Baustelle). Die Meldung wird an den nachfolgenden Verkehr weitergeleitet und über eine Warnung (z.B. "Wanderbaustelle in 800m") dargestellt.

Versuchsschritte 1. Die Fahrzeuge zweier Gruppen fahren auf eine Baustelle zu. 2. Die Fahrer der Fahrzeuge der ersten Gruppe erhalten eine Warnung vor der Baustelle, die Fahrer der zweiten Gruppe erhalten die Warnung nicht. 3. Vergleich der beiden Gruppen. Die Fahrzeuge beider Gruppen beteiligen sich an der Kommunikation und es werden für die Auswertung relevante Daten geloggt (auch wann die Fahrer der zweiten Gruppe eine Warnung erhalten hätten).


A_2.1.1.4 Baustellenwarnung

Aktoren

Initialfahrzeug Es gibt keine Initialfahrzeuge, sondern: Wanderbaustelle bzw. stationäre Baustelle mit IRS.


Das Fahrzeug empfängt die Warnung vor der Baustelle und sendet die Information an umgebende Fahrzeuge und an die IRS. Die Fahrer nähern sich der Baustelle und werden vor dieser gewarnt


Das Fahrzeug empfängt die Warnung und sendet die Information an um-gebende Fahrzeuge und an die IRS. Die Fahrer nähern sich der Baustelle und erhalten keine Warnung.

IRS sendet relevante Baustelleninformationen (Position der Baustelle) an sich nähernde Fahrzeuge

ICS In der ICS ist die genaue Information über die Baustelle bekannt (z.B. über das DORA-System) und wird kontinuierlich mitgepflegt und aktualisiert

Navigationssystem Bleibt für diesen Versuchsfall deaktiviert. Dynamische Routenberechnung deaktiviert: Es werden keine alternativen Routen aufgrund von Baustellen berechnet Baustellen dürfen nicht angezeigt werden


Hier nicht relevant


Tabelle 36: Versuchsfälle für A_1.3.2.1 Optimierung des LSA-gesteuerten Verkehrsflusses.

A_1.3.2.1 Optimierung des LSA-gesteuerten Verkehrsflusses




A_2.2.2.1 Grüne Welle A_2.2.2.2 Restrotanzeige A_2.2.2.3 Warnung vor Rotlichtverstoß mit Ausprägungen A_1.3.3.3 Reduzierung von Wartezeiten des Individualverkehrs F_1.1.1 Infrastrukturseitige Datenerfassung F_1.1.2 Fahrzeugseitige Datenerfassung F_1.1.4 Ermittlung der Verkehrslage F_2.2.2 Ampel-Phasen-Assistent/Warnung


Über infrastrukturseitige und fahrzeugseitige Erfassungseinrichtungen in F_1.1.1 und F_1.1.2 (Detektoren und IVS) wird die aktuelle Verkehrslage im Straßenverkehrsnetz der Stadt Frankfurt am Main erfasst und in F_1.3.2 in einem Verkehrsmodell zu einer räumlich-zeitlichen Repräsentation der Verkehrslage fusioniert. Mit Hilfe eines Wirkungsmodells werden die Auswirkungen verschiedener Steuerungsalternativen für jede LSA für die nächsten 5 - 15 Minuten prog-nostiziert und dahingehend optimiert, dass eine minimale Verlustzeit so-wohl für den ÖPNV als auch für den motorisierten Individualverkehr (mIV) und den nicht motorisierten Individualverkehr (nmIV) entsteht. Die hieraus



entstehenden optimalen Rahmensignalpläne werden an die LSA geschickt, die diese unmittelbar umsetzen und dadurch den Verkehrsfluss optimieren. Mit Hilfe der Daten von Fahrzeugen (CAM, DEN, Fahrtziel und ProbeVehicleData), die sich im Netz befinden, kann die LSA-Steuerung adaptiv angepasst und somit der Verkehrsfluss optimiert werden (z.B. Ver-längerung der Freigabezeiten bei größeren Rückstaulängen).

Versuchsschritte 1. Die Fahrzeuge der internen Flotte fahren (mehrfach) vorgegebene Rou-ten im relevanten Versuchsgebiet (Niederrad) 2. Keine, ein Teil bzw. alle Fahrzeuge der internen Flotte liefern Fahrzeug-daten über die IRS an die Zentrale (IGLZ) als FCD für die Netzsteuerung 3. Auswertung der Fahrzeugdaten aller Fahrzeuge.

Aktoren

Initialfahrzeug Hier nicht relevant


Der Fahrer bekommt über das HMI von diesem Anwendungsfall nichts mit. "Fahrzeuge mit Information/Warnung" heißt hier: Fahrzeug liefert FCD, bzw. Anwendungsfall nutzt FCD von diesem Fahrzeug.


Der Fahrer bekommt über das HMI von diesem Anwendungsfall nichts mit. "Fahrzeuge ohne Information/Warnung" heißt hier: Fahrzeug liefert keine FCD, bzw. Anwendungsfall nutzt FCD von diesem Fahrzeug nicht.

IRS Die IRS dient der Kommunikation zwischen Fahrzeug und LSA bzw. zwi-schen Fahrzeug und Verkehrszentrale. Sie stellt das Bindeglied zwischen einem sich bewegenden Objekt (Fahrzeug) und einem stationären Objekt (LSA, Verkehrszentrale) her. Fahrzeugdaten werden zur IRS gesendet, verarbeitet und an die LSA / Verkehrszentrale weitergeleitet.

ICS Daten von der IRS werden im Verkehrsmodell auf Zentralenseite verarbei-tet und in einem räumlich-zeitlichen Zusammenhang gebracht, um die ak-tuelle Verkehrslage zu rekonstruieren. Basierend darauf wird die LSA-Netzsteuerung optimiert.

Navigationssystem Hier nicht relevant


LSA, Detektoren, Netzsteuerung

Sonstige Aktoren 1. Lichtsignalanlage (LSA) mit optimierten Signalzeitenplan Die Lichtsignalanlage bekommt einen auf die Verkehrssituation angepass-ten Rahmensignalplan. 2. Detektoren (i.d.R. Induktionsschleifen) Die Induktionsschleifen liefern die Anzahl an Überfahrten für ein vorgege-benes Zeitintervall (i.d.R. 1 Minute). Diese Daten werden an ein Verkehrs-modell weitergeleitet, das die Daten in einen räumlich-zeitlichen Zusam-menhang bringt und so die Verkehrslage im Gebiet rekonstruiert. 3. Netzsteuerung Die Netzsteuerung arbeitet auf strategischer und taktischer Ebene. Auf strategischer Ebene werden Kriterien festgelegt, an denen sich die Steuerung orientieren soll. Kriterien für die Auswahl der Eingangsgrößen



sind u.a. die Richtlinien, an die die Kommunen durch die Gesetzgebung gebunden sind. Ferner können aber auch verkehrspolitische Zielvorstellun-gen wiedergegeben werden. Die taktische Ebene umfasst das adaptive Netzsteuerungsverfahren (Licht-signalsteuerungsverfahren). Durch ein Verkehrsmodell und die Optimie-rung über eine explizite Zielfunktion, die die vorgegebenen Parameter der strategischen Ebene aufnimmt, werden optimale Rahmensignalpläne er-rechnet und an die einzelnen Lichtsignalanlagen verschickt. 4. Verkehrsfluss Der Verkehrsfluss ist die Gesamtheit aller sich bewegenden Fahrzeuge im Straßennetz

Tabelle 37: Versuchsfälle für A_1.3.1.1 Umleitungsempfehlung.

A_1.3.1.1 Umleitungsempfehlung




A_1.1.4.1 Bereitstellung Gesamtverkehrslage A_1.1.5.1 Identifikation von geplanten Verkehrsereignissen A_1.1.5.2 Identifikation von ungeplanten Verkehrsereignissen A_1.2.3.2 Dynamische Routenplanung F_1.1.4 Ermittlung der Verkehrslage F_1.1.5 Identifikation von Verkehrsereignissen F_1.2.3 Erweiterte Navigation


Im Fall von Störungen werden Umleitungsempfehlungen generiert, die eine Verkürzung der Fahrzeit und/oder eine Entlastung der gestörten Route bewirken können. Die Umleitungsempfehlungen werden für jeden relevan-ten Entscheidungspunkt (Autobahnknotenpunkt oder Anschlussstelle) durch einen Vergleich der Reisezeiten auf der Hauptroute mit den mögli-chen Alternativouten ermittelt und als Textmeldung bereitgestellt.

Versuchsschritte 1. Die Fahrzeuge zweier Gruppen erhalten die Aufgabe ein gemeinsames Ziel anzufahren, das über eine Standardroute erreicht werden kann. Für Teile der Standardroute stehen Alternativrouten zur Verfügung. 2. Die Fahrer der Fahrzeuge der ersten Gruppe erhalten dabei eine Umlei-tungsempfehlung, sobald Teile der Hauptroute eine ungewöhnlich hohe Reisezeit im Vergleich zur Alternativroute aufweisen. Fahrer der zweiten Gruppe erhalten keine Empfehlung. Ggf. erhalten alle Fahrer zusätzlich die gleiche Empfehlung über dWiSta, sofern vorhanden. 3. Vergleich der beiden Gruppen.

Aktoren



Die Fahrer erhalten eine Umleitungsempfehlung.


Die Fahrer erhalten keine Umleitungsempfehlung.


A_1.3.1.1 Umleitungsempfehlung

IRS Weiterleitung der Umleitungsempfehlungen an die Fahrzeuge

ICS Informationen und Strategien zu potenziellen Alternativrouten werden für die relevanten Knotenpunkte entwickelt und in einer Alternativroutenbiblio-thek in der ICS bereitgestellt. Für jede alternative Route werden auf der Grundlage der Verkehrslage (F_1.1.4) die Reisezeit bzw. etwaige Verluste verglichen. Bei Über-/Unterschreiten definierter Schwellenwerte (Hystere-se) wird die Umleitungsempfehlung ausgesendet (an dWiSta und Fahrzeu-ge (virtuelle dWiSta)).

Navigationssystem deaktiviert


ggf. dWiSta

Sonstige Aktoren keine

Tabelle 38: Versuchsfälle für A_2.1.4.1 Warnung vor sich näherndem Einsatzfahrzeug.

A_2.1.4.1 Warnung vor sich näherndem Einsatzfahrzeug




A_2.1.4.2 F_2.1.1 Hinderniswarnung


Das Einsatzfahrzeug sendet seine aktuellen Fahrzeugdaten inkl. Status "Aktiver Noteinsatz" an die umgebenden Fahrzeuge. Die Meldung wird von den empfangenden Fahrzeugen in Fahrtrichtung des Einsatzfahrzeugs weitergereicht, dabei sind auch querende Straßen eingeschlossen. Im empfangenden Fahrzeug wird der Fahrer nach erfolgreicher Relevanzprüfung vor dem Einsatzfahrzeug, das im Wirkbereich von EGO ist, über das HMI gewarnt. Der Wirkbereich soll dadurch charakterisiert sein, dass eine Reaktion von EGO erforderlich ist. Nach erfolgreicher Relevanzprüfung wird über ein Einsatzfahrzeug, das außerhalb des Wirk-bereichs von EGO ist, über das HMI informiert. Eine Richtungsanzeige gibt an, aus welcher Richtung der Fahrer das Einsatzfahrzeug erwarten muss.

Versuchsschritte Kreuzungsvariante Die Fahrzeuge werden in zwei Gruppen aufgeteilt. Gruppe A erhält bei Bedarf eine Warnung, Gruppe B erhält keine Warnung. 1. Auf der Hauptstraße fahren Fahrzeuge beider Gruppen im fließenden Verkehr von beiden Seiten auf eine Kreuzung zu und überqueren diese. Der Abstand der Fahrzeuge beträgt 10 - 50m. 2. Im querenden Verkehr fahren Fahrzeuge beider Gruppen. Der Abstand der Fahrzeuge beträgt 10 - 50m. 3. Im fließenden Verkehr fährt ein Einsatzfahrzeug entlang der Hauptstra-ße. 4. Der Schalter aktiver Noteinsatz wird eingeschaltet. 5. Das EFZ sendet CAM & DEN Nachrichten. 6. Ego-Fahrzeuge empfangen EFZ Nachrichten und werten diese aus.



7. Alle F2.1.4 Fahrzeuge im Relevanzbereich erkennen das EFZ als rele-vant. 8. Alle F2.1.4 Fahrzeuge außerhalb des Relevanzbereiches erkennen das EFZ als nicht relevant 9. Alle F2.1.4 Fahrzeuge im Relevanzbereich, die in Fahrtrichtung des EFZ sind, und die Fahrzeuge, die auf die Kreuzung zufahren, erkennen, dass das EFZ in ihrem Wirkbereich ist. 10. Entsprechend des Wirkbereichs wird eine Warnung / Information bei allen Fahrzeugen der Gruppe A im Relevanzbereich ausgegeben. 11. Bei allen Fahrzeugen der Gruppe A im Relevanzbereich wird das EFZ als POI dargestellt.

Aktoren

Initialfahrzeug Einsatzfahrzeug (Polizei, Rettungsdienst, Feuerwehr, Behörden etc.) sen-det als CAM-Nachricht die aktuellen Fahrzeugdaten. Dazu gehört auch der Status „Aktiver Noteinsatz“. (Kommentar: Es ist vorgesehen, auch reale Einsatzfahrzeuge (ca. 10) aus-zurüsten. Die Details werden mit den zuständigen Behörden geklärt.)


Das Fahrzeug empfängt die CAM- und DEN-Nachrichten des Einsatzfahr-zeugs und leitet die DEN-Nachrichten nach Prüfung des Zielgebietes ggf. an umgebende Fahrzeuge und an die IRS weiter. Im empfangenden Fahrzeug wird der Fahrer nach erfolgreicher Relevanzprüfung vor dem Einsatzfahrzeug, das im Wirkbereich von EGO ist, über das HMI gewarnt. Der Wirkbereich soll dadurch charakterisiert sein, dass eine Reaktion von EGO erforderlich ist. Nach erfolgreicher Relevanzprüfung wird über ein Einsatzfahrzeug, das außerhalb des Wirk-bereichs von EGO ist, über das HMI informiert. Eine Richtungsanzeige gibt an, aus welcher Richtung der Fahrer das Einsatzfahrzeug erwarten muss. Die Analyse, ob das EFZ im Relevanzbereich (Reichweite des EGO Fahr-zeug) ist und ob es sich darüber hinaus auch im Wirkbereich des EGO Fahrzeug befindet, übernimmt die Funktion selbst (aufbauend auf den Da-ten der Umfeldtabelle, Relevanzfilter und Navigationsdaten). Information bzw. Warnung über Einsatzfahrzeug beinhaltet Radardarstellung im simTD-HMI und eine Darstellung des EFZ in der Navigationskarte als POI.

Fahrzeuge ohne Informati-on/Warnung

Das Fahrzeug empfängt die Warnung und sendet die Information an um-gebende Fahrzeuge und an die IRS. Die Fahrer erhalten keine Informati-on/Warnung über ein sich näherndes Einsatzfahrzeug.

IRS Die Funktion hat keinen Anteil auf der IRS. Die IRS können jedoch auf Netzwerkebene Nachrichten weiterleiten.

ICS Die Funktion hat keinen Anteil auf der ICS.

Navigationssystem Die Wirkbereichsprüfung kann jeweils mit und ohne Auswertung der Kar-tendaten erfolgen. Die Variante mit Kartendaten erlaubt durch Nutzung von Straßenattributen eine bessere Situationsbewertung.


Hier nicht relevant



N_A_2.1.4.1_IF02

Versuchsschritte Autobahnvariante Die Fahrzeuge werden in zwei Gruppen aufgeteilt. Gruppe A erhält bei Bedarf eine Warnung, Gruppe B erhält keine Warnung. 1. Auf der Autobahn fahren Fahrzeuge der beiden Gruppen im fließenden Verkehr in eine Richtung. Der Abstand der Fahrzeuge beträgt 100 - 500m. 2. Im Gegenverkehr auf der Autobahn fahren Fahrzeuge mit F2.1.4 (Fahr-zeuge ohne aktivierte F2.1.4 sind erlaubt, aber nicht notwendig). Der Ab-stand der Fahrzeuge beträgt 100 - 1000m. 3. Im fließenden Verkehr fährt ein EFZ (zufällig) auf der Autobahn. 4. Der Schalter aktiver Noteinsatz wird eingeschaltet. 5. Das EFZ sendet CAM & DEN Nachrichten. 6. Ego-Fahrzeuge empfangen EFZ Nachrichten und werten diese aus. 7. Alle F2.1.4 Fahrzeuge im Relevanzbereich erkennen EFZ als relevant. 8. Alle F2.1.4 Fahrzeuge außerhalb des Relevanzbereiches erkennen EFZ als nicht relevant 9. Alle F2.1.4 Fahrzeuge im Relevanzbereich, die in Fahrtrichtung des EFZ sind erkennen, dass das EFZ in ihrem Wirkbereich ist. 10. Die Fahrzeuge auf der querenden Straße erkennen, dass das EFZ NICHT in ihrem Wirkbereich ist 11. Entsprechend des Wirkbereichs wird eine Warnung / Information bei allen Fahrzeugen der Gruppe A im Relevanzbereich ausgegeben. 12. Bei allen Fahrzeugen der Gruppe A im Relevanzbereich wird das EFZ als POI dargestellt.

Aktoren

Initialfahrzeug Einsatzfahrzeug (Polizei, Rettungsdienst, Feuerwehr, Behörden etc.) sen-det als CAM-Nachricht die aktuellen Fahrzeugdaten. Dazu gehört auch der Status „Aktiver Noteinsatz“. (Kommentar: Es ist vorgesehen, auch reale Einsatzfahrzeuge (ca. 10) aus-zurüsten. Die Details werden mit den zuständigen Behörden geklärt.)


Das Fahrzeug empfängt die CAM- und DEN-Nachrichten des Einsatzfahr-zeugs und leitet die DEN-Nachrichten nach Prüfung des Zielgebietes ggf. an umgebende Fahrzeuge und an die IRS weiter. Im empfangenden Fahrzeug wird der Fahrer nach erfolgreicher Relevanzprüfung vor dem Einsatzfahrzeug, das im Wirkbereich von EGO ist, über das HMI gewarnt. Der Wirkbereich soll dadurch charakterisiert sein, dass eine Reaktion von EGO erforderlich ist. Nach erfolgreicher Relevanzprüfung wird über ein Einsatzfahrzeug, das außerhalb des Wirk-bereichs von EGO ist, über das HMI informiert. Eine Richtungsanzeige gibt an, aus welcher Richtung der Fahrer das Einsatzfahrzeug erwarten muss. Die Analyse, ob das EFZ im Relevanzbereich (Reichweite des EGO Fahr-zeug) ist und ob es sich darüber hinaus auch im Wirkbereich des EGO Fahrzeug befindet, übernimmt die Funktion selbst (aufbauend auf den Da-ten der Umfeldtabelle, Relevanzfilter und Navigationsdaten). Information bzw. Warnung über Einsatzfahrzeug beinhaltet Radardarstellung im simTD-HMI und eine Darstellung des EFZ in der Navigationskarte als POI.


Das Fahrzeug empfängt die Warnung und sendet die Information an um-gebende Fahrzeuge und an die IRS. Die Fahrer erhalten keine Informati-on/Warnung über sich näherndes Einsatzfahrzeug.



IRS Die Funktion hat keinen Anteil auf der IRS. Die IRS können jedoch auf Netzwerkebene Nachrichten weiterleiten.

ICS Die Funktion hat keinen Anteil auf der ICS.

Navigationssystem Die Wirkbereichsprüfung kann jeweils mit und ohne Auswertung der Kar-tendaten erfolgen. Die Variante mit Kartendaten erlaubt durch Nutzung von Straßenattributen eine bessere Situationsbewertung.


Hier nicht relevant


Tabelle 39: Versuchsfälle für A_3.1.2.4 Parksituation.

A_3.1.2.4 Parksituation




A_3.1.2.3 Kommunalinformation


Aktuelle Informationen über den Parkraum werden von einem Dienstanbie-ter bereitgestellt, zum Fahrzeug übertragen, dort gespeichert und auf An-frage des Fahrers angezeigt. Die Informationen beinhalten die Verfügbar-keit und die spezifischen Eigenschaften von Parkmöglichkeiten in Parkhäu-sern, Tiefgaragen und auf bewirtschafteten Parkplätzen. Durch die Anbin-dung an die Navigationsfunktion ermöglicht der Anwendungsfall eine kom-fortable Zielführung zu einem verfügbaren geeigneten Parkplatz in der Nähe des Ziels. Funktion im gesamten Stadtgebiet möglich!

Versuchsschritte 1. Die Fahrer der Fahrzeuge zweier Gruppen der internen Flotte erhalten die Aufgabe schnellstmöglich einen Parkplatz möglichst nahe an einem gegebenen Ziel zu finden. 2. Die Fahrer der Fahrzeuge der ersten Gruppe erhalten die Information über die Parksituation. Fahrer der zweiten Gruppe erhalten keine Informa-tion. Dabei sollte die Einteilung so erfolgen, dass sich in beiden Gruppen gleiche Anteile von ortskundigen und nicht ortskundigen Fahrern befinden 3. Vergleich der Gruppen.

Aktoren



Fahrer der ersten Gruppe erhalten die Informationen zur Parksituation.


Fahrer der zweiten Gruppe erhalten die Informationen zur Parksituation nicht.

IRS Nicht relevant


A_3.1.2.4 Parksituation

ICS Aufbereitung der ortsbezogenen Informationen

Navigationssystem Zusammenwirken mit F_3.1.2 ist erforderlich: Parkräume werden auf der Karte als POI angezeigt. Ausgewählter Parkraum wird als neues Ziel für die Zielführung übernommen.


Bewirtschaftete Parkplätze

Sonstige Aktoren Parkraumbetreiber

Tabelle 40: Versuchsfälle für A_2.2.4.1 Querverkehrsassistent.

A_2.2.4.1 Querverkehrsassistent




A_2.2.1.2 Warnung bei Nichtbeachtung von Verkehrszeichen A_2.2.2.1 Grüne Welle A_2.2.2.3 Warnung vor Rotlichtverstoß mit Ausprägungen F_2.2.1 Verkehrszeichen-Assistent/Warnung F_2.2.2 Ampel-Phasen-Assistent/Warnung


Ein wartepflichtiges oder ein vorfahrtsberechtigtes Fahrzeug nähert sich an eine Kreuzung an und erhält im zeitlichen Verlauf bis zum Überqueren der Kreuzung geeignete Informationen und/oder Warnungen, um Kollisionen mit querenden Fahrzeugen auf der Kreuzung zu vermeiden.

Versuchsschritte 1. Die Fahrer werden in vier Gruppen eingeteilt 2. Der Fahrer fährt auf eine Kreuzung zu. 3. Gruppe 1: Fahrer erhält Information über die Verkehrsregelung an der Kreuzung und eine Warnung, wenn die Gefahr einer Kollision besteht. Gruppe 2: Fahrer erhält eine Information über die Verkehrsregelung an der Kreuzung und eine Warnung, wenn die Gefahr einer Kollision besteht. Außerdem erhält er F_2.2.1 Verkehrszeichenassistent/-warnung. Gruppe 3: Fahrer erhält nur F_2.2.1 Verkehrszeichenassistent/-warnung. Gruppe 4: Der Fahrer erhält keine Warnung. 4. Vergleich der Gruppen.

Aktoren



Gruppe 1 erhält eine Information über die Verkehrsregelung an der Kreu-zung und eine Warnung, wenn die Gefahr einer Kollision besteht. Gruppe 2 erhält eine Information über die Verkehrsregelung an der Kreu-zung und eine Warnung, wenn die Gefahr einer Kollision besteht. Außer-dem erhält sie F_2.2.1 Verkehrszeichenassistent/-warnung. Gruppe 3 erhält nur F_2.2.1 Verkehrszeichenassistent/-warnung.

Fzge. ohne Informa-tion/ Warnung

Gruppe 4 fährt auf Kreuzung zu und erhält keine Information/Warnung.


Anhang 2: Befahrung des Versuchsgebiets durch IZVW

Abbildung 72: Erste Befahrungsrunde des städtischen Versuchsgebiets durch das IZVW: Baseler Straße – Stre-semannallee – Mörfelder Landstraße – Alt-Niederrad – Bürostadt Niederrad – Alt-Niederrad – Kennedyallee.

Abbildung 73: Zweite Befahrungsrunde des städtischen Versuchsgebiets durch das IZVW: Theodor-Stern-Kai – Alt-Niederrad – A5 AS Frankfurt-Niederrad – Frankfurter Kreuz – A3 AS Frankfurt Süd – Mörfelder Landstraße – Kennedyallee.


Abbildung 74: Dritte Befahrungsrunde des städtischen Versuchsgebiets durch das IZVW: Theodor-Stern-Kai – Niederräder Ufer – A5 AS Frankfurt-Niederrad – Westkreuz Frankfurt – A648 (Theodor-Heuss-Allee) – Friedrich-Ebert-Anlage.


Anhang 3: Anforderungen an Testgelände (abgeleitet aus Test- und Ver-suchsfällen, AP13)

Tabelle 41: Anforderungen an das Testgelände.

ID KurzbeschreibungArt der Anforderung

Betroffene Testsystem‐Komponenten

Beschreibung

TSysTGelR_001 DSL‐Anbindung im Testgelände

Technisch (Hardware, OS, Screen, etc.) Testgelände Auf dem Testgelände muss es einen Breitband/DSL‐Zugang geben

TSysTGelR_002 Testmodus pWLAN

Technisch (Hardware, OS, Screen, etc.) Testgelände

Testmodus für pWLAN bei dem mit hoher Rate Datenpakete für Kommunikationsversuche versendet werden. Dabei sol l die Sendelei s tung, Datenrate, Paketlänge und der Fehlerschutz al ternierend umgescha ltet werden.

TSysTGelR_003 Testmodus cWLAN


Testmodus für cWLAN bei dem mit hoher Rate Datenpakete für Kommunikationsversuche versendet werden. Dabei sol l die Sendelei s tung, Datenrate, Paketlänge und der Fehlerschutz al ternierend umgescha ltet werden.

TSysTGelR_004

Ausrüstung f. Versuchsdurchführung ‐ Kommunikation

Technisch (Hardware, OS, Screen, etc.) Testgelände Funkgeräte/Mobi l telefone

TSysTGelR_005

Ausrüstung f. Versuchsdurchführung ‐ einfache Messtechnik

Technisch (Hardware, OS, Screen, etc.) Testgelände Stoppuhren, Messbänder, Pylone

TSysTGelR_006

Ausrüstung f. Versuchsdurchführung ‐ Dokumentationsunterlagen

Technisch (Hardware, OS, Screen, etc.) Testgelände Übers ichtsgrafiken Testgelände gesamt bzw. einzelner Abschni tte

TSysTGelR_007Geeigneter Straßenabschni tt mit Mögl ichkei t für Hindernisaufbau


Auf einem Landstraßenabschnitt aus Pylonen errichtetes Hindernis sol l aufgrund des Ausweichmanövers detektiert

TSysTGelR_008

Frei fläche von mehreren hundert Metern um zwei voneinander getrennten Fahrzeugen mit Sichtl inie

Technisch (Hardware, OS, Screen, etc.)

TestgeländeVersuchsgebietExpertenfahrer

Im freien Feld ohne Hindernisse wird die Reichweite zwischen zwei IVS gemessen zur Bestimmung der Referenz einer optimisti schen Reichweite als Kenngröße für die optimis tische Leis tungsfähigkei t eines Kommunikationssystems und für die Ableitung von Parametern für Kommunikationsmodel le.

TSysTGelR_009

Fläche zur kreis förmigen Anordnung von Fahrzeugen um ein Fahrzeug in Kommunikationsreichwei te


Erhöhung der Kana l las t von einer Anzahl von 20 Fahrzeugen um ein Empfängerfahrzeug bis die Paketfehlerrate über einer definierten Schwel le l iegt.

TSysTGelR_010 Keine unbetei l igten Sender

Qual i tät (Performance, Securi ty, etc.)

Testgelände(VersuchsgebietExpertenfahrer)

Es s ind keine an dem Versuch unbetei l igten Sender auf dem

verwendeten Kanal aktiv, weder s imTD‐externe noch s imTD‐interne.

TSysTGelR_011

Referenzmessung zur Richtigkei t/Genauigkei t der Hochfrequenzverkabelung

Qual i tät (Performance, Securi ty, etc.) Testgelände

Anbringen einer Referenzstation zur Überprüfung der Richtigkeit der Verkabelung und damit der abgestrahl ten Sendeleis tung des gesamten Kommunikationssystems.

TSysTGelR_012 WLAN‐Empfangs lei s tung der IVS


Bei Durchführung auf dem Testgelände müssen entsprechende HF‐Messgeräte zur Verfügung s tehen.

TSysTGelR_013 WLAN‐Signa lgenerator oder IVS

Qual i tät (Performance, Securi ty, etc.) Testgelände WLAN‐Signalgenerator oder IVS mit veri fizierter Sendelei stung

TSysTGelR_014Signalgenerator zur Erzeugung von Rauschs ignalen


Signa lgenerator zur Erzeugung eines Rauschs igna ls zur Bestimmung der Rauschlei s tung

TSysTGelR_015Richtigkei t/Genauigkei t der gel ieferten WLAN‐Sendelei stung


Bei Durchführung auf dem Testgelände müssen entsprechende HF‐Messgeräte zur Verfügung s tehen. Am besten geeignet i s t ein WLAN‐Testempfänger. Gegebenfal ls kann auch ein Power‐Meter Messgerät oder Spektrum‐Analyser verwendet werden.

TSysTGelR_016Straßenkreuzung mit einem Gebäude



Diese Untersuchung bestimmt die WLAN‐Kommunikationsqual i tät zwischen einem Sender und einem Empfänger in Abhängigkeit der geographischen Distanz sowie der Pos ition, der Umgebung (Abschattung durch Gebäude) und der Geschwindigkeit der Fahrzeuge. (Testkonfiguration 1)




Beschreibung

TSysTGelR_016 Straßenkreuzung mit einem GebäudeTechnisch (Hardware, OS, Screen, etc.)


Diese Untersuchung bestimmt die WLAN‐Kommunikationsqualität zwischen einem Sender und einem Empfänger in Abhängigkeit der geographischen Distanz sowie der Position, der Umgebung (Abschattung durch Gebäude) und der Geschwindigkeit der Fahrzeuge. (Testkonfi

TSysTGelR_017 Straßenkreuzung mit vier GebäudenTechnisch (Hardware, OS, Screen, etc.)


Diese Untersuchung bestimmt die WLAN‐Kommunikationsqualität zwischen einem Sender und einem Empfänger in Abhängigkeit der geographischen Distanz sowie der Position, der Umgebung (Abschattung durch Gebäude) und der Geschwindigkeit der Fahrzeuge. (Testkonfi

TSysTGelR_018Empfangsleistung Mobilfunkmodul und Überprüfung Hochfrequenzverkabelung

Qualität (Performance, Security, etc.)

TestgeländeVersuchsgebietnaive FahrerExpertenfahrer

Es muss ein kalibrierter Spektrumananalyzer (externes Messgerät) inkl. notwendiger Hochfrequenzadapter, mit Möglichkeit zur Messung der Empfangsleistung des Mobilfunksystems, zur Verfügung stehen. Die Messung der Empfangsleistung ist so durchzuführen, das

TSysTGelR_019 Ort mit optimaler MobilfunkversorgungQualität (Performance, Security, etc.)


Sicherstellen, dass die Empfangsleistung des Mobilfunknetzes während der Messung stabil bleibt. Bedingungen hierfür sind Sichtverbindung zur Basisstation und Geringe Interferenzen durch benachbarte Basisstationen

TSysTGelR_020Referenz‐Mobilfunkgerät für GSM/UMTS

Qualität (Performance, Security, etc.)


Referenzmessung zur Überprüfung des vom Mobilfunkmodul angezeigten Empfangsleistungswertes, sowie Überprüfung der Hochfrequenzverkabelung

TSysTGelR_021 Mobilfunkgerät zum Absetzen von SMSQualität (Performance, Security, etc.)


Mobilfunkgerät zum Absetzen von SMS für die AT‐Befehle oder Möglichkeit zum Anstoßen des Logging

TSysTGelR_022Fahrzeuge im Bereich einer Mobilfunkzelle

Qualität (Performance, Security, etc.) Testgelände

Alle Fahrzeuge der Versuchsflotte müssen sich im Bereich einer Mobilfunkzelle befinden und sich einbuchen können, um feststellen zu können, ob der Geoserver alle Fahrzeuge bedienen kann.

TSysTGelR_023Spezialanwendung zum Senden von DENMs


Innerhalb jedes Teilgebiets sendet ein bestimmter Anteil der dort befindlichen Fahrzeuge DENM Nachrichten. Die DENM Nachrichten werden von einer speziellen Testanwendung generiert.

TSysTGelR_024 Protokoll Trace ToolQualität (Performance, Security, etc.) Testgelände Log aller vom Geoserver und zum Geoserver gesendeten Nachrichten

TSysTGelR_025 Gebiet mit guter FunkversorgungQualität (Performance, Security, etc.)

TestgeländeVersuchsgebietfreie Flottenaive FahrerExpertenfahrer

Ein Gebiet mit guter Funkversorgung zur Bestimmung der Dauer der Übermittlung eines Geocasts von Fahrzeug/Infrastruktur zu Fahrzeug.

TSysTGelR_026 Gebiet mit schlechter FunkversorgungQualität (Performance, Security, etc.)


Ein Gebiet mit schlechter Funkversorgung zur Bestimmung dder Dauer der Übermittlung eines Geocasts von Fahrzeug/Infrastruktur zu Fahrzeug.

TSysTGelR_027 IRSTechnisch (Hardware, OS, Screen, etc.)

PrüfstandTestgelände

Auf einer IRS muss das ServiceAnnouncement „TrafficDataCollector" aktiviert sein

TSysTGelR_028 Testparcour ohne störenden ObjektenQualität (Performance, Security, etc.) Testgelände

Ebenes Gebiet mit guter Himmelssicht ohne störende Objekte (wie Bäume, Gebäude) im Umkreis des Parcours. Eine Gerade mit mind. 200x8m Freifläche und eine freier Kreis mit einem Radius von mind. 60m.

TSysTGelR_029Ausreichender Reibwert der Fahrbahnoberfläche


Der Reibwert der Oberfläche muss mind. 0,4 betragen (Asphalt bei Nässe ist ausreichend) um keinen Schwimmwinkel zu erhalten.

TSysTGelR_030 Überdachte StraßenabschnitteQualität (Performance, Security, etc.) Testgelände

Optional sind Tunnel, Brücken‐Unterfahrten, verdeckte Straßentrassen etc. für eine Verbesserung der GNSS‐Rohdaten

TSysTGelR_031Toolunterstützung zur Visualisierung der Positionsdaten


Toolunterstützung zur Visualisierung der Positionsdaten (GNSS‐Rohdaten und Positionsdaten der Besseren Ortung) und der zugehörigen Gütekenngrößen

TSysTGelR_032 Hochgenaues Referenz‐MesssystemQualität (Performance, Security, etc.) Testgelände

Optional hochgenaues Referenz‐Messsystem (z.B. Inertialsystem), z.B. für die Verifikation der ersten OEM‐Versuchsträger.

TSysTGelR_033Keine weitere Belastung der Kommunkationskanäle


Es gibt keine weitere Belastung der Kommunikationkanäle im Bereich der IRS durch andere Stationen oder Funktionen.

TSysTGelR_034 IRS Technisch (Hardware, OS, Screen, etc.) Testgelände

CCU mit pWLAN Kommunikation incl. CAM‐Sender und gültige Positions‐ und Zeitdaten. IRS meldet Service Announcment zum Empfang von ProbeVehicleData. Empfangene C2X‐Nachrichten sind zugreifbar (Daten die in die Umfeldtabelle geschrieben werden).




Beschreibung

TSysTGelR_035 ControlChannel unbelastetQualität (Performance, Security, etc.) Testgelände

Der ControlChannel ist nicht durch weitere ITS Stations oder Funktionen belastet.

TSysTGelR_036 Freifläche inkl. IRSTechnisch (Hardware, OS, Screen, etc.) Testgelände

Freie Fläche ohne Abschattung und ein angenommener Empfangsradius <150m zur IRS.

TSysTGelR_037 IRSTechnisch (Hardware, OS, Screen, etc.) Testgelände

IRS CCU mit pWLAN Kommunikation und empfangene C2X‐Nachrichten werden in Umfeldtabelle geschrieben.

TSysTGelR_038 pWLAN Traffic GeneratorTechnisch (Hardware, OS, Screen, etc.) Testgelände

Sendeeinheit in Nähe der IRS für pWLAN Kommunikation mit der Möglichkeit eine vorgegebene Kanallast durch Dummy‐Nachrichten zu erzeugen

TSysTGelR_039 Streckenabschnitt (Autobahn)Technisch (Hardware, OS, Screen, etc.)


Streckenabschnitt mit mind. 2000m Länge für eine Geschwindigkeit von bis zu 130 km/h

TSysTGelR_040Streckenabschnitt (Stadtstraße, Landstraße bzw. Autobahn)

Technisch (Hardware, OS, Screen, etc.) Testgelände Streckenabschnitt mit mind. 1500 m Länge zum Test der Straßenvorausschau

TSysTGelR_041Streckenabschnitt (Stadtstraße, Landstraße bzw. Autobahn)

Technisch (Hardware, OS, Screen, etc.) Testgelände Streckenabschnitt mit mind. 1500 m Länge zum Test der Straßenvorausschau

TSysTGelR_042Keine weiteren Sender von Verkehrslagedaten

Qualität (Performance, Security, etc.) Testgelände Andere Sender von Verkehrslagedaten stören den Test nicht

TSysTGelR_043

Prüfung der Situationserkennung / Verkehrsmodell Knotenpunkt auf Richtigkeit mit einem simTD Einsatzfahrzeug



Es wird geprüft, ob das Verkehrsmodell Knotenpunkt Verkehrssituationen richtig erkennt, d.h. ob bestimmte Fahrzeugbewegungen (inkl. Einsatz‐ und ÖPNV‐Fahrzeuge) richtig erkannt werden.

TSysTGelR_044 Kreuzung mit LSA inkl. IRSTechnisch (Hardware, OS, Screen, etc.)

(Prüfstand)Testgelände X‐Kreuzung (zum Teil mehrspurig je Fahrtrichtung) mit LSA inkl. IRS

TSysTGelR_045Prüfung des Zeitverhaltens mit einem simTD Einsatzfahrzeug


Es wird auch mit Einsatzfahrzeugen geprüft, ob die folgenden beiden Zeitpunkte übereinstimmen bzw. nicht zu stark voneinander abweichen: Tatsächlicher Zeitpunkt, zu dem ein SIM‐TD Fahrzeug einen dezidierten Punkt überfahrt und Zeitpunkt, den das Verkehrsm

TSysTGelR_046 Kreuzung mit LSA inkl. IRSTechnisch (Hardware, OS, Screen, etc.) Testgelände

X‐Kreuzung (einspurig je Fahrtrichtung) mit LSA mit ÖPNV‐Signal inkl. IRS und Anfahrtsstrecke >100m

TSysTGelR_047 simTD ÖPNV‐FahrzeugeTechnisch (Hardware, OS, Screen, etc.) Testgelände

Die ÖPNV‐Fahrzeuge simulieren ÖPNV‐Fahrten, in dem Sie ÖPNV‐Signale beachten und Haltestellenaufenthalte simulieren. (bis zu 3 Stück)

TSysTGelR_048 Streckenabschnitt inkl. HindernisTechnisch (Hardware, OS, Screen, etc.)

(Prüfstand)Testgelände(Versuchsgebietnaive FahrerExpertenfahrer)

Streckenabschnitt (Landstraße) mit der Möglichkeit zum Aufbaus eines Hindernisses aus Pylonen oder zum Abstellen eines Fahrzeug



Streckenabschnitt (Landstraße) mit 1000m Länge mit der Möglichkeit zum Aufbaus eines Hindernisses aus Pylonen oder zum Abstellen eines Fahrzeug

TSysTGelR_051 Streckenabschnitt inkl. HindernisTechnisch (Hardware, OS, Screen, etc.) Testgelände

Streckenabschnitt (Landstraße mit v<= 100 km/h) mit der Möglichkeit zum Aufbaus eines Hindernisses aus Pylonen oder zum Abstellen eines Fahrzeug



Gerade oder leicht gekrümmte Landstraße lässt das Abstellen eines Pannenfahrzeugs und eine Geschwindigkeit von 100 km/h zu.



Stark gekrümmte Straße, Landstraße mit Abbiegung oder Autobahnabfahrt. Sicht zu Hindernis optisch und reichweitebezogen eingeschränkt.

TSysTGelR_054 Streckenabschnitt inkl. HindernisTechnisch (Hardware, OS, Screen, etc.) Testgelände

Im Testgelände wird ein Parcours mit Pylonen markiert, der eine Kreuzung und eine scharfe Kurve darstellt (hiermit simuliert das Fahrzeug ein Fahren in der Stadt, sowie auf einer Bergstrasse mit engen Kurven). v=100 km/h

TSysTGelR_055 Schnee‐, Eis‐ und WasserglätteTechnisch (Hardware, OS, Screen, etc.)


Es wird überprüft, ob die Erkennung des Wettereignisses Glätte, in seinen Ausprägungen Schnee-, Eis- und Wasserglätte (Aquaplaning), mittels fahrzeugseitiger Sensoren funktioniert. Dabei werden Parameter in der Funktion variiert, um die zuverlässigste Kon

TSysTGelR_056

Überprüfung der Erkennung und Darstellung der Einsatzfahrzeugwarnung im Stadtverkehr.



Das Einsatzfahrzeug (EFZ) sendet bei einem aktiven Noteinsatz seine Position, Fahrtrichtung, Geschwindigkeit, Längsbeschleunigung sowie den Status „aktiver Noteinsatz“ an die umgebenden Fahrzeuge. Im empfangenden Fahrzeug wird der Fahrer situationsgerecht




Beschreibung

TSysTGelR_057

Überprüfung der Darstellung der Einsatzfahrzeugwarnung bei mehreren EFZ, sowie wie Test der Reaktionszeit der Funktion


Das Einsatzfahrzeug (EFZ) sendet bei einem aktiven Noteinsatz seine Position, Fahrtrichtung, Geschwindigkeit, Längsbeschleunigung sowie den Status „aktiver Noteinsatz“ an die umgebenden Fahrzeuge. Im empfangenden Fahrzeug wird der Fahrer situationsgerecht

TSysTGelR_058 Verkehrs‐ und WechselverkehrszeichenTechnisch (Hardware, OS, Screen, etc.)


Möglichst viele Verkehrszeichen, mindestens ein Verkehrszeichen jeder Kategorie (in Spezifikation aufgeführt: A2.1, A2.2, A2.3.1, A2.3.2, A2.3.3, A2.3.4, A2.4), 6 Wechselverkehrszeichen, zum Test des Verkehrszeichenassistenten

TSysTGelR_059Streckenabschnitt mit Kreuzungen und Beschilderung


TestgeländeVersuchsgebietfreie Flottenaive FahrerExpertenfahrer Eine Strecke (Autobahn, Land‐ oder Stadtstraße) mit mindestens 27 VZ

TSysTGelR_060 Streckenabschnitt mit IRSTechnisch (Hardware, OS, Screen, etc.) Testgelände

Eine Strecke mit mind. 700m Länge und einer IRS. v <= 200 km/h, 5 sec vor Erreichen der IRS müssen die Verkehrsdaten empfangen werden

TSysTGelR_061 Kreuzung mit LSA inkl. IRSTechnisch (Hardware, OS, Screen, etc.) Testgelände

T‐ oder X‐Kreuzung mit LSA inkl. IRS mit Verkehrszeicheninformationen, v<=70 km/h

TSysTGelR_062 Kreuzung mit IRSTechnisch (Hardware, OS, Screen, etc.) Testgelände T‐ oder X‐Kreuzung mit IRS mit bekannter Kreuzungstopologie

TSysTGelR_063 MotorradTechnisch (Hardware, OS, Screen, etc.) Testgelände ein Motorrad ohne simTD‐Ausstattung



T‐ oder X‐Kreuzung mit LSA inkl. IRS mit Verkehrszeicheninformationen, v<=70 km/h


TestgeländeVersuchsgebietExpertenfahrer X‐Kreuzung (einspurig je Fahrtrichtung) mit LSA inkl. IRS, v=70km/h

TSysTGelR_066 StreckenabschnittTechnisch (Hardware, OS, Screen, etc.)


Streckenabschnitt mit einer Länge von mind. 1km für eine Geschwindigkeit von v>12 m/s

TSysTGelR_067 StreckenabschnittTechnisch (Hardware, OS, Screen, etc.)


Streckenabschnitt mit einer Länge von mind. 1km für eine Geschwindigkeit von v=55 m/s

TSysTGelR_068 Keine Funktionen (DEN, HMI) aktivQualität (Performance, Security, etc.)


Keine anderen Funktionen die DENs verschicken oder HMI Aufträge generieren aktiv

TSysTGelR_069 Kreuzung mit IRSTechnisch (Hardware, OS, Screen, etc.)


T‐ oder X‐Kreuzung mit IRS und ggf. Vorfahrtsregelnder Beschilderung

TSysTGelR_070 MotorradTechnisch (Hardware, OS, Screen, etc.)


ein Motorrad mit simTD‐Ausstattung



T‐ oder X‐Kreuzung mit IRS und ggf. Vorfahrtsregelnder Beschilderung ohne oder mit ausgeschalteter LSA, v<= 80 km/h

TSysTGelR_072 Kreuzung ohne IRSTechnisch (Hardware, OS, Screen, etc.)


T‐ oder X‐Kreuzung ohne IRS und ggf. Vorfahrtsregelnder Beschilderung ohne oder mit ausgeschalteter LSA


TestgeländeVersuchsgebietExpertenfahrer T‐ oder X‐Kreuzung mit IRS mit bekannter Kreuzungstopologie




Beschreibung

TSysTGelR_074 MotorradTechnisch (Hardware, OS, Screen, etc.)


ein Motorrad mit simTD‐Ausstattung



T‐ oder X‐Kreuzung mit IRS mit bekannter Kreuzungstopologie



T‐ oder X‐Kreuzung mit IRS mit bekannter Kreuzungstopologie, v= 70km/h

TSysTGelR_077 Kreuzung mit IRSTechnisch (Hardware, OS, Screen, etc.) Testgelände

X‐Kreuzung (einspurig je Fahrtrichtung) mit IRS mit bekannter Kreuzungstopologie, v=60km/h

TSysTGelR_078 Kreuzung mit LSA inkl. IRSTechnisch (Hardware, OS, Screen, etc.) Testgelände Kreuzung mit LSA inkl. IRS

TSysTGelR_079 simTD ÖPNV‐FahrzeugeTechnisch (Hardware, OS, Screen, etc.) Testgelände ein oder mehrere ÖPNV‐Fahrzeuge

TSysTGelR_080 simTD EinsatzfahrzeugeTechnisch (Hardware, OS, Screen, etc.) Testgelände ein oder mehrere Einsatzfahrzeuge

TSysTGelR_081 StreckenabschnittTechnisch (Hardware, OS, Screen, etc.) Testgelände Streckenabschnitt mind. 1‐spurig je Richtung

TSysTGelR_082 Streckenabschnitt mit HindernissTechnisch (Hardware, OS, Screen, etc.) Testgelände Streckenabschnitt mit ein Spure je Richtung mit variablem Hinderniss

TSysTGelR_083 KreuzungTechnisch (Hardware, OS, Screen, etc.) Testgelände X‐Kreuzung einspurig je Richtung

TSysTGelR_084 simTD Einsatzfahrzeug Technisch (Hardware, OS, Screen, etc.) Testgelände ein Einsatzfahrzeug

TSysTGelR_085 Kreuzung mit VerkehrszeichenTechnisch (Hardware, OS, Screen, etc.) Testgelände

X‐Kreuzung einspurig je Richtung mit vorfahrtsregelnden Verkehrszeichen, LSA ausgeschaltet

TSysTGelR_086Knotenpunkt mehrstreifig mit LSA inkl. IRS und Steuergerät (Stromanschluss)


Knotenpunkt: Hauptverkehrsstraße (2‐spurig mit separater Linksabbiegerspur und ÖPNV‐Bucht/‐fahrbahn) ‐ LSA geregelt, Nebenverkehrsstraße (1‐spurig) ‐ LSA geregelt, Vorabrechtsabbieger von der Nebenstraße, ggf. Fußgängerfurten und ‐signalisierung

TSysTGelR_087 DSL‐AnbindungTechnisch (Hardware, OS, Screen, etc.) Testgelände 100 MBit‐Anbindung des Testgeländes an das Internet für IRS‐Management

TSysTGelR_088 mobile FunkabschattungenTechnisch (Hardware, OS, Screen, etc.) Testgelände mobile Funkabschattungen zur Anpassung der Abschattungen an die Testfälle

TSysTGelR_089 WinterdienstTechnisch (Hardware, OS, Screen, etc.) Testgelände

bei Tests und Versuchen im Winter muss ggf. ein Räum‐ und Streudienst organisiert werden

TSysTGelR_090 BüroausstattungTechnisch (Hardware, OS, Screen, etc.) Testgelände

Verlängerungskabel, Mehrfachsteckdosen, Lampen und sonstiges Elektroinventar




Beschreibung

TSysTGelR_091 BüroausstattungTechnisch (Hardware, OS, Screen, etc.) Testgelände Monitore, Rechner, Drucker, Druckerpapier, Kopierer und sonstige IT‐Hardware

TSysTGelR_092 BüroausstattungTechnisch (Hardware, OS, Screen, etc.) Testgelände Mobiliar wie Tische, Stühle, Whiteboard...

TSysTGelR_093 Raum für PrüfstandTechnisch (Hardware, OS, Screen, etc.) Testgelände Aufbaumöglichkeit des Prüfstandes in einem Raum in einem der Gebäude

TSysTGelR_094 SprechanlageTechnisch (Hardware, OS, Screen, etc.) Testgelände Sprechanlage

TSysTGelR_095 TestgeländevorschriftRechtlich (Standards, Versicherung, etc.) Testgelände Erstellung einer Testgeländevorschrift

TSysTGelR_096 AußenbeleuchtungTechnisch (Hardware, OS, Screen, etc.) Testgelände spezielle Straßen‐/Außenbeleuchtung

TSysTGelR_097 HausordnungRechtlich (Standards, Versicherung, etc.) Testgelände Hausordnung inkl. Sicherheitsbeauftragter

TSysTGelR_098 StraßensicherungenTechnisch (Hardware, OS, Screen, etc.) Testgelände Sperrbänder, Pylone, Hinweisschilder

TSysTGelR_099 Stromanschluss SteuergerätTechnisch (Hardware, OS, Screen, etc.) Testgelände 230V/16A mit einer 2,5 mm² Zuleitung, welche maximal 20m sein sollte

TSysTGelR_100herkömmliche Detektion im Testgelände


Eine herkömmliche Detektion (Induktionsschleifen, Infrarot, Radar, Videodetektion, ...?) ist zwingend erforderlich, zum Vergleich zwischen simTD‐System und herkömmlichem Betrieb.Dabei auch Baken anbringen für ÖV‐Anforderung der Busspur!

TSysTGelR_101 KameraüberwachungTechnisch (Hardware, OS, Screen, etc.) Testgelände

Eine Kameraüberwachung zur Unterstützung der Logging‐Auswertung wäre sinnvoll. Anzahl? Art? Überkopf am Knotenpunkt?Wäre bei einem sehr großen, unübersichtlichen Gelände eine Echtzeit‐Anzeige auf Bildschirm(en) im Kommandostand sinnvoll?

TSysTGelR_102 Kennzeichnung der FahrstreifenTechnisch (Hardware, OS, Screen, etc.) Testgelände

Die Fahrstreifen sollten sichtbar mit einer eindeutigen Kennzeichnung versehen werden (Straßenmarkierung, z.B. "A1"), um den Fahren eine genaue Orientierung zu ermöglichen. Vorschlag dazu siehe Lageplan.

TSysTGelR_103 AnzeigetafelTechnisch (Hardware, OS, Screen, etc.) Testgelände

Eine große digitale Anzeigetafel wäre nützlich, die bestimmte Parameter sowohl für die Fahrer als auch die Testbegleiter für alle sichtbar anzeigen könnte (z.B. aktueller Test, aktuelle Funktion, bestimmte Funktionen zu‐/abgeschaltet, herkömmliche Detekti

TSysTGelR_104 SignalisierungTechnisch (Hardware, OS, Screen, etc.) Testgelände

Insb. falls obige Anzeigetafel nicht realisiert wird: Eine einfache, mehrfarbige Signalisierung (ähnlich einer LSA), die den aktuellen Teststatus für alle anzeigt (GO, STOP, Fehler, …)

TSysTGelR_105 Lautsprecher & MikrofonTechnisch (Hardware, OS, Screen, etc.) Testgelände

Aus dem Kommandostand sollte die Möglichkeit bestehen, Lautsprecherdurchsagen auf das Testgelände zu schicken. Anzahl und Standorte der Lautsprecher?

TSysTGelR_106

Projektierung des Knotenpunkts mit der Maßgabe einer möglichst realistischen Abbildung


Bei der Projektierung des Knotenpunkts soll eine möglichst große Realitätsnähe angestrebt werden. Dazu zählen z.B. neben der Fahrstreifenbreite auch deren Belegung. Im Stadtbild typische Elemente sollen hierbei gleichfalls berücksichtigt werden, wie z.B.

TSysTGelR_107

Ausstattung des Knotenpunkts mit allen für die Versuchsdurchführung relevanten Formen und Fahrstreifenbelegungen


Es müssen sämtliche in den Versuchsbeschreibungen vorgesehenen Verkehrsabläufe möglich sein. Deshalb sollen folgende Aspekte berücksichtigt werden: In den Hauptrichtungen jeweils zwei durchgehende Fahrstreifen nach Geradeaus. Eine der Zufahrten hat einen

TSysTGelR_108Ausstattung des Knotenpunkts mit Fuß‐ und Radverkehrsanlagen Anzeige (Look and Feel) Testgelände

Der Knotenpunkt muss realistisch, also mit allen im Stadtbild üblichen Merkmalen des Fuß‐ und Radverkehrs ausgestattet werden: Signalgeber für Fußgänger, Warn‐Blinklichter für abbiegende Pkw, Anforderungstaster, Furtmarkierungen. In den nachgeordneten Kno

TSysTGelR_109Berücksichtigung von Fußverkehr in Signalprogrammierung


Zur realistischen Dimensionierung der Freigabezeiten für die einzelnen Signalgruppen des IV ist die Berücksichtigung der Fußgängerfreigaben unerlässlich (auch wenn im Testgelände nicht mit Fußverkehr zu rechnen ist).

TSysTGelR_110Markierungs‐Infrastruktur für variable dedizierte Testparcours


Für die Verifikation von Systemkomponenten wie besserer Ortung und Funktionen wie F2.2.4 Kreuzungs‐Querverkehrsassistenz müssen auf einer geeigneten Freifläche des Testgeländes bestimmte Testparcours gesteckt werden können z.B. über Bojen und Leitplanken.




Beschreibung

TSysTGelR_111 Car2X MonitorTechnisch (Hardware, OS, Screen, etc.) Testgelände

Die aktuellen Car2X‐Nachrichten auf de Testgelände sollen erfasst und überwacht werden können, z.B. über eine CCU mit Software für Visualisierung und Statistik

TSysTGelR_112 Car2X LastgeneratorTechnisch (Hardware, OS, Screen, etc.) Testgelände

über eine stationäre oder mobile CCU und eine entsprechende Software (vgl. Hr. Hiller FET 1.1.2 Lastgenerator) sollen zusätzliche Nachrichten, insbesondere CAM‐Nachrichten virtueller Fahrzeuge ins Testgelände verfunkt und so Last erzeugt werden können. Di

TSysTGelR_113 Gemeinsame Kartengrundlage Funktional TestgeländeDie Kartengrundlage (z.B. für die Routenberechnungen, Anzeige im Leitstand, Anzeige im HMI) soll in allen simTD‐Komponenten identisch sein.

TSysTGelR_114Server für Testdaten von Prüfstand und Testgelände Funktional


Es scheint sinnvoll alle oder wenigstens wichtige Daten vom Prüfstand und dem Testgelände zentral für TP4 abzulegen, um später bei der Auswertung auf diese zugreifen zu können

TSysTGelR_115Auslösemöglichkeit des Testfalles T_KOM_14_K0101


TestgeländeVersuchsgebiet

Es muss für die Testfahrer eine Möglichkeit bestehen, die Tests im Rahmen des Testfalles T_KOM_14_K0101 am Referenzpunkt manuell auszulösen.

TSysTGelR_116 FahrbahnmarkierungenTechnisch (Hardware, OS, Screen, etc.) Testgelände

Zur Kennzeichnung der Fahrstreifen, sowie zur Anzeige von Abbiegespuren und Baustellenumfahrungen werden temporäre Fahrbahnmarkierungen benötigt, die bei Bedarf ohne größeren Aufwand geändert werden können.


Literaturverzeichnis Assenmacher, S., Killat, M., Schmidt-Eisenlohr, F. & Vortisch, P. (2008). A Simulative Ap-proach for the Identification of Possibilities and Impacts of V2X-Communication. 15th World Congress on ITS, New York City, 16.-20. Nov. 2008.

Bortz, J. & Döring, N. (2006). Forschungsmethoden und Evaluation für Human- und Sozial-wissenschaftler (4., überarb. Aufl.). Berlin: Springer.

Cohen, J. (1988). Statistical power analysis for the behavioral sciences (2nd ed.). Hillsdale, NJ: Erlbaum.

Deliverable D5.1 (2009). Anforderungskatalog an den Feldtest (Version 2.2.). simTD: Konsor-tium-internes Deliverable.

Deliverable D11.1 (2009). Beschreibung der C2X-Funktionen (Version 2.0). simTD: Öffentli-ches Deliverable.

Deliverable D12.2 (2009). Validierungs- und Optimierungsziele, Metriken und Methoden (Version 1.0). simTD: Öffentliches Deliverable.

Deliverable D13.2 (2010). Test- und Versuchsspezifikation (Version 1.0). simTD: Öffentliches Deliverable

Deliverable D13.3 (2010). Anforderungen ans Testsystem (Version 1.0). simTD: Konsortium-internes Deliverable.

DIN 4543-1 (1994). Büroarbeitsplätze – Teil 1: Flächen für Aufstellung und Benutzung von Büromöbeln. Sicherheitstechnische Anforderungen, Prüfung. Berlin: DIN – Deutsches Institut für Normung e.V.

Erdfelder, E., Faul, F. & Buchner, A. (1996). GPOWER: A general power analysis program. Behavior Research Methods, Instruments, & Computers, 28, 1-11.

Hessisches Landesamt für Straßen- und Verkehrswesen (2005). Verkehrsmengenkarte für Hessen, Ausgabe 2005. Frankfurt: Dezernat Verkehrssicherheit, Verkehrstechnik und Stra-ßenausstattung.

Hussy, W., Schreier, M. & Echterhoff, G. (2010). Forschungsmethoden in Psychologie und Sozialwissenschaften - für Bachelor. Berlin: Springer.

ISO/IEC 9126-1 (2001). Software engineering - Product quality - Quality model.

ISO/IEC TR 9126-2 (2003). Software engineering - Product quality - External metrics.

Mollenhauer, M. (2009). Data Management in Naturalistic Driving Studies. Tagungsbeitrag beim Workshop „Naturalistic Driving Studies & Field Operational Tests“ der TU Chemnitz, München. Mühlbacher, D., Messerschmidt, J., Totzke, I. & Krüger, H.-P. (2010). Fahren in einer Kolon-ne - Lieber einzeln oder gemeinsam in den Urlaub?. 52. Tagung experimentell arbeitender Psychologen (TeaP), Saarbrücken, 22.03-24.03.2010.

Neale, V.L., Dingus, T.A., Klauer, S.G., Sudweeks, J. & Goodman, M. (2005). An overview of the 100-car naturalistic study and findings (Paper No. 05-0400). Washington: National High-way Traffic Safety Administration.

PTV Planung Transport Verkehr AG (2009). VISSIM 5.20 Benutzerhandbuch.

Sarris, V. (1990). Methodologische Grundlagen der Experimentalpsychologie 1: Erkenntnis-gewinnung und Methodik. München: Reinhardt.

Sarris, V. (1992). Methodologische Grundlagen der Experimentalpsychologie 2: Versuchs-planung und Stadien des psychologischen Experiments. München: Reinhardt.


Sarris, V. & Reiß, S. (2005). Kurzer Leitfaden der Experimentalpsychologie. München: Pear-son-Studium.

Sauer OS (2009). Anforderungen an ein Flottenmanagementsystem für eine ereignisorien-tierte Einsatzplanung (Präsentation im Rahmen des Forschungsprojekts simTD). Zugriff am 01.04.2010. Verfügbar unter https://service.projectplace.com/pp/pp.cgi/0/369387286.

Vorhabensbeschreibung (2009). Projekt SIM-TD Sichere Intelligente Mobilität – Testfeld Deutschland (Version 4.1, final).

Zumkeller, D., Chlond, B., Ottmann, P., Kagerbauer, M. & Kuhnimhof, T. (2007). Deutsches Mobilitätspanel (MOP) – Wissenschaftliche Begleitung und erste Auswertungen: Zwischen-bericht. Karlsruhe: Institut für Verkehrswesen.


Abkürzungen Tabelle 42: Abkürzungsverzeichnis.

Abkürzung Beschreibung

ACC Adaptive Cruise Control

CAM Cooperative Awareness Message

CAN Controller Area Network

CCU Car Communication Unit

CCU Car Communication Unit

EF Externe Flotte

FCD Floating Car Data

FET Funktionsentwicklungsteam

FMS Flottenmanagementsystem

FS Fahrsimulation

GUA Gemeinsamer Unterauftragnehmer

HMI Human Machine Interface

ICS ITS Central Station

IF Interne Flotte

IGLZ Integrierte Gesamtverkehrsleitzentrale

IRS ITS Roadside Station

IVS ITS Vehicle Station

LIDAR Light Detection and Ranging

LSA Lichtsignalanlage

LWL Lichtwellenleiter

OEM Original-Equipment-Manufacturer

POI Points of Interest

StVO Straßenverkehrsordnung

TG Testgelände

TTS Text-to-Speech

VAPI Vehicle Application Programming Interface

VAU Vehicle Application Unit

VS Verkehrssimulation


Glossar Tabelle 43: Einträge der Versuchsmethodik für das simTD-Glossar (Quelle: Bortz & Döring, 2006).

Begriff Beschreibung

Abhängige Va-riable (AV)

Variable, die zum »Dann«-Teil einer Hypothese gehört und in der sich die Wirkun-gen der Unabhängigen Variablen (Ursachen, Bedingungen) widerspiegeln.

Alternativhypo-these (H1)

Inhaltlich behauptet die Alternativhypothese, dass in der Population ein Effekt vor-liegt bzw. dass sich Populationsparameter unterscheiden. Da man Untersuchungen in der Regel durchführt, um Effekte nachzuweisen, entspricht die Forschungshypo-these üblicherweise der Alternativhypothese. Man unterscheidet

• gerichtete oder ungerichtete Alternativhypothesen, bei denen die Richtung des Parameterunterschiedes entweder vorgegeben (z.B. H1: μ1>μ2, ältere Fahrer fahren im Mittel langsamer als junge Fahrer) oder nicht vorgegeben (z.B. H1: μ1≠μ2, ältere Fahrer wählen eine andere mittlere Fahrgeschwin-digkeit als jüngere Fahrer) wird;

• spezifische oder unspezifische Alternativhypothesen, bei denen die Größe des Parameterunterschiedes entweder vorgegeben (z.B. H1: μ1>μ2+10, jüngere Fahrer fahren mind. 10 km/h schneller als ältere Fahrer) oder nicht vorgegeben (z.B. H1: μ1>μ2) wird.

Charakterisierungsziel

Ein Charakterisierungsziel ist eine informelle oder semi-formale Beschreibung einer oder mehrerer Systemanforderungen oder Systemeigenschaften, die im Kontext einer spezifischen Anwendung bisher nicht bekannt sind und durch Bereitstellung objektivierbarer Methoden zu ermitteln sind.

Beispiel: "Wenn die Elektronisches-Bremslicht-Warnung ausgelöst wird, (a) bremst der Fahrer schnellstmöglich ab, (b) versucht der Fahrer die Spur zu wechseln und auszuweichen oder (c) gerät der Fahrer in Panik und tritt versehentlich aufs Gas, wodurch ein Unfall ausgelöst wird

Effektgröße (Effect Size)

Größe eines Effekts bzw. einer Parameterdifferenz. Um eine spezifische Alternativ-hypothese formulieren zu können, muss man die erwartete Effektgröße im Voraus angeben. Die Festlegung einer Effektgröße ist auch notwendig, um den für die ge-plante Untersuchung optimalen Stichprobenumfang bestimmen bzw. die Teststärke eines Signifikanztests angeben zu können. Da sich bei großen Stichproben auch sehr kleine (für die Praxis unbedeutende) Effekte als statistisch signifikant erweisen können, sollte ergänzend zur statistischen Signifikanz immer auch die Effektgröße betrachtet werden.

Hypothese Annahme über einen realen (empirisch erfassbaren) Sachverhalt in Form eines Konditionalsatzes (Wenn-dann-Satz, Je-desto-Satz). Wissenschaftliche Hypothesen müssen über den Einzelfall hinausgehen (Generalisierbarkeit, Allgemeinheitsgrad) und anhand von Beobachtungsdaten falsifizierbar sein. Man unterscheidet Nullhy-pothese und Alternativhypothese, inhaltliche und statistische Hypothese, Zusam-menhangs-, Unterschieds- und Veränderungshypothese; mono- und multikausale Hypothese.

Nullhypothese (H0)

Inhaltlich negiert die Nullhypothese das Vorliegen eines Effekts und widerspricht damit der Alternativhypothese. Bei ungerichteten Alternativhypothesen sind Nullhy-pothesen spezifisch, d. h. sie enthalten das Gleichheitszeichen, um auszudrücken, dass Parameter sich gleichen (z.B. H0: μ 1= μ 2) oder dass ein Parameter den Wert 0 annimmt (z.B. H0: μ =0). Bei gerichteten Alternativhypothesen sind sie unspezi-fisch (z.B. H0: μ ≤0). Die »klassischen« Signifikanztests sind Nullhypothesentests, d.h. aus der spezifischen H0 wird eine theoretische Stichprobenkennwerteverteilung für den Test konstruiert (sog. Nullverteilung, Nullmodell, z.B. Standardnormalvertei-lung, t-Verteilung, F-Verteilung), anhand deren das empirische Stichproben- bzw. Testergebnis bewertet wird bzw. aus der die bedingte Wahrscheinlichkeit für das

https://svn.simtd.de/trac/sim-td/wiki/Charakterisierungsziel�



https://svn.simtd.de/trac/sim-td/wiki/Methoden�

https://svn.simtd.de/trac/sim-td/wiki/Warnung�


Auftreten des gefundenen (oder eines extremeren) Stichprobenergebnisses als Alphafehlerwahrscheinlichkeit abgeleitet wird.

Optimaler Stichprobenum-fang

Stichprobenumfänge sind optimal, wenn sie einem Signifikanztest genügend Test-stärke geben, um einen getesteten Effekt bei vorgegebener Effektgröße entdecken und auf einem vorgegebenen Signifikanzniveau absichern zu können. Optimale Stichproben sind so berechnet, dass eine ausreichende Teststärke von 80% ge-währleistet ist. Wählt man den Stichprobenumfang zu klein, verliert ein Test an Teststärke, wählt man ihn zu groß, betreibt man unnötigen Aufwand, da nun auch kleinste Effekte signifikant werden können, die praktisch bedeutungslos sind. Mit optimalen Stichprobenumfängen zu arbeiten ist ökonomisch und führt zu eindeuti-gen statistischen Ergebnissen.

Optimierungsziel

Ein Optimierungsziel ist eine informelle oder semi-formale Beschreibung, einer oder mehrerer Systemanforderungen oder Systemeigenschaften, deren Parameter hin-sichtlich einer spezifische beabsichtigte Anwendung durch Bereitstellung objekti-vierbarer Methoden zu optimieren sind. Im Rahmen der Optimierung wird für eine definierte Messgröße ein Zielwert (Zahl oder +/- Unendlich) vorgegeben. Durch Änderung eines definierten Satzes an Eingangsgrößen werden die Eingangsgrößen bestimmt, die das Optimum in Hinblick auf den gegebenen Zielwert darstellen.

Beispiel: "Die Hinderniswarnung soll möglichst selten Fehlwarnungen ausgeben. (Fehlwarnung = Eine Warnung wird ausgelöst, obwohl kein (relevantes) Hindernis in Sicht ist."

Signifikantes Ergebnis

Ein Ergebnis ist statistisch signifikant, wenn es zu einer Ergebnisklasse gehört, deren Wahrscheinlichkeit bei Gültigkeit der Nullhypothese kleiner als ein zuvor fest-gesetztes Signifikanzniveau ist. Per Konvention festgelegte Höchstgrenze der α-Fehler-Wahrscheinlichkeit, α <5% (signifikant, »*«), α <1% (sehr signifikant, »**«) oder α <0.1% (hoch signifikant, »***«). Das 5%-Niveau ist im Forschungsbereich üblich. Da mit wachsendem Stichprobenumfang auch kleine und praktisch unbe-deutende Effekte signifikant werden können, sollte bei Signifikanzaussagen immer die Effektgröße mitbetrachtet werden.

Teststärke (Po-wer)

Wahrscheinlichkeit, mit der eine richtige Alternativhypothese durch einen Signifikanztest entdeckt wird. Sie entspricht der Wahrscheinlichkeit 1–β. Signifikanztests sollten mindestens eine Teststärke von 80% aufweisen. Hypothesenprüfungen mit zu kleiner Teststärke sollten nur in Ausnahmefällen veröf-fentlicht werden, denn sie erschweren kumulative Erkenntnisentwicklung; vgl. Beta-fehlerwahrscheinlichkeit.

Unabhängige Variable (UV)

Variable, die zum »Wenn«-Teil einer Hypothese gehört; vgl. Abhängige Variable.

Validierungsziel Ein Validierungsziel ist eine informelle oder semi-formale Beschreibung, einer oder mehrerer Systemanforderungen oder Systemeigenschaften, deren Eignung für eine spezifische beabsichtigte Anwendung durch Bereitstellung eines objektiven Nach-weises zu belegen sind. In simTD werden Validierungsziele durch Tests oder Ver-suche belegt die eine binäre Aussage ("Ja" oder "Nein") über die Eignung (evtl. unter Zuhilfenahme statistischer Methoden, mit definiertem Sicherheitswert) des Systems für den angegebenen Gebrauch zulassen.

Beispiel: "Durch die Warnung vor einem Stauende werden die Abstände zwischen den Fahrzeugen größer."

https://svn.simtd.de/trac/sim-td/wiki/Optimierungsziel�





https://svn.simtd.de/trac/sim-td/wiki/Sicht�

https://svn.simtd.de/trac/sim-td/wiki/Validierungsziel�

https://svn.simtd.de/trac/sim-td/wiki/Validierungsziel�



Documents

Deliverable D41.1 Versuchsplan 1€¦ · Daniel Handke – Stadt Frankfurt am Main (FFM) Dominik Mühlbacher –Interdisziplinäres Zentrum für Verkehrswissenschaften an der Univer-sität