Vsimrti User Manual 0.13.1

VSimRTI: Vehicle-2-X Simulation
Runtime Infrastructure
User Documentation
Michalis Adamidis
Franz Kage
Tobias Queck
Sebastian Dunkel
Bernard Ladenthin
Stefan Reichel
Erik Schleiff
Jan Henning
Nico Naumann
David Rieck
Bjrn Schnemann
Version 0.13.1
March 25, 2014
Jiajun Hu
Robert Protzmann
Alexander Scheck
Julia Ullrich
Abstract
The Vehicle-2-X Simulation Runtime Infrastructure (VSimRTI) enables the preparation and execution of
Vehicle-2-X (V2X) simulations. It is a flexible system which simulates traffic flow dynamically. VSimRTI
couples different simulators and thus allows the simulation of the various aspects of intelligent transportation systems. The easy integration and exchangeability of simulators enables the utilization of the
most relevant simulators for a realistic presentation of vehicle traffic, emissions, wireless communication
and the execution of V2X applications.
The developer alliance

The developer alliance consists of Fraunhofer-Institut fr Offene Kommunikationssysteme (FOKUS),
Daimler Center for Automotive Information Technology Innovations (DCAITI) and Automotive Services
and Communication Technologies (ASCT).
Contact information
VSimRTI Mailing List (developer team)
vsimrti@fokus.fraunhofer.de
VSimRTI: Smart Mobility Simulation
http://www.dcaiti.tu-berlin.de/research/simulation
Fraunhofer FOKUS: ASCT Competence Center
http://www.fokus.fraunhofer.de/en/asct/index.html
DCAITI
http://www.dcaiti.tu-berlin.de
Contents
1 Introduction
1.1 Overview . . . . . . . . . . . . . . .
1.2 Download and install . . . . . . . .
1.3 License . . . . . . . . . . . . . . . .
1.4 Concept . . . . . . . . . . . . . . . .
1.4.1 Federates and Ambassadors
1.4.2 Root configuration . . . . .
.
.
.
.
.
.
1
1
2
2
3
3
3
2 VSimRTI configuration
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Host configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Simulators
3.1 Kinds of simulators . . . . . . . . . . . . . . . . .
3.1.1 Network simulators . . . . . . . . . . . . .
3.1.2 Traffic simulators . . . . . . . . . . . . . .
3.1.3 Cellular simulators . . . . . . . . . . . . .
3.1.4 Application simulators . . . . . . . . . . .
3.1.5 Environment simulators . . . . . . . . . .
3.1.6 Navigation simulators . . . . . . . . . . .
3.2 JiST/SWANS . . . . . . . . . . . . . . . . . . . . .
3.2.1 swans-ambassador folder structure . . .
3.2.2 Installation . . . . . . . . . . . . . . . . . .
3.2.3 Configuration . . . . . . . . . . . . . . . .
3.3 OMNeT++ . . . . . . . . . . . . . . . . . . . . . .
3.3.1 omnetpp-ambassador folder structure .
3.3.2 Installation . . . . . . . . . . . . . . . . . .
3.3.3 Configuration . . . . . . . . . . . . . . . .
3.4 ns-3 . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 ns3-ambassador folder structure . . . . .
3.4.2 Installation . . . . . . . . . . . . . . . . . .
3.4.3 Configuration . . . . . . . . . . . . . . . .
3.5 SUMO . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 sumo-ambassador folder structure . . .
3.5.2 Installation . . . . . . . . . . . . . . . . . .
3.5.3 Configuration . . . . . . . . . . . . . . . .
3.5.4 Further information . . . . . . . . . . . .
3.6 VISSIM . . . . . . . . . . . . . . . . . . . . . . . .
3.7 VSimRTI Eventserver . . . . . . . . . . . . . . . .
3.7.1 eventserver-ambassador folder structure
3.7.2 Installation . . . . . . . . . . . . . . . . . .
3.7.3 Configuration . . . . . . . . . . . . . . . .
3.8 eWorld . . . . . . . . . . . . . . . . . . . . . . . .
3.8.1 eworld-ambassador folder structure . . .
3.8.2 Installation . . . . . . . . . . . . . . . . . .
3.8.3 Configuration . . . . . . . . . . . . . . . .
3.9 VSimRTI cellular simulator . . . . . . . . . . . .
3.9.1 cell-ambassador folder structure . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
6
6
6
6
7
8
8
8
9
11
11
11
14
15
16
16
18
20
20
20
21
21
22
23
23
23
23
24
24
24
25
26
26
Contents
Contents
3.9.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10 VSimRTI application simulator . . . . . . . . . . . . . . . . . . . . . . .
3.10.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.2 application-ambassador folder structure . . . . . . . . . . . . .
3.10.3 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.5 Development of application . . . . . . . . . . . . . . . . . . . . .
3.10.6 FacilityTimerInterceptors . . . . . . . . . . . . . . . . . . . . . .
3.10.7 Remote debugging of applications . . . . . . . . . . . . . . . . .
3.10.8 Mapping 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11 VSimRTI navigation simulator . . . . . . . . . . . . . . . . . . . . . . .
3.11.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11.2 navigation-ambassador folder structure . . . . . . . . . . . . .
3.11.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.12 Behavior Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.12.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.12.3 Adjusting an application . . . . . . . . . . . . . . . . . . . . . . .
3.12.4 Creating a custom data structure . . . . . . . . . . . . . . . . . .
3.12.5 Matching between a BehaviorDataStruct and normal messages
3.12.6 Creating a new model . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
26
31
31
31
31
31
32
37
42
43
46
46
46
46
47
47
48
48
48
50
50
4 Visualizers
4.1 Kinds of Visualizers . . . . . . . . . . . . .
4.2 eWorld . . . . . . . . . . . . . . . . . . . .
4.2.1 eWorld VSimRTI visualizer plugin
4.3 VsimrtiFileVisualizer . . . . . . . . . . . .
4.3.1 Configuring the File Visualizer . .
4.4 VSimRTI web visualizer (VSim) . . . . . .
4.5 VSimRTI WebSocket visualizer . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
52
53
53
67
67
71
72
5 Create a scenario
5.1 Road network data . . . . . . . . .
5.1.1 Using OpenStreetMap data
5.2 Road network data . . . . . . . . .
5.3 VSimRTI . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73
73
73
74
75
6 Run simulations
6.1 Run a simulation via CLI . . . . .
6.1.1 VSimRTIEmbeddedStarter
6.2 Run a simulation set via CLI . . .
6.3 Results . . . . . . . . . . . . . . .
6.3.1 Logging . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
77
77
78
79
81
81
.
.
.
.
.
7 Scenario Schwanebeck
83
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2 WeatherWarningApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.3 Run a single simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8 Scenario Tiergarten
85
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2 CamExampleApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9 Additional tools
86
9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.2 scenario-convert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure
Contents
Contents
10Additional information
88
10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.2 PATH configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.3 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
11List of Acronyms
91
A VSimRTI deployment
93
A.1 VSimRTI Folder Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
A.2 File listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
B Example scenario Schwanebeck
105
B.1 Folder Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
B.2 File listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
C Example scenario Tiergarten
119
C.1 Folder Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
C.2 File listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
1 Introduction
1.1 Overview
This documentation is part of the current release of VSimRTI and aims at supporting users in their first
steps with the software. We try to explain most of the VSimRTI features and configurations with two
example scenarios named Schwanebeck (see chapter 7) and Tiergarten (see chapter 8).
Having said that we do not aim to give full disclosure for every configuration option here. If you need
more specific information on a configuration have a look at the javadocs provided alongside the current
release which are available for all JavaScript Object Notation (JSON) style configs or the Appendix for
Extensible Markup Language (XML) style configs.
If you have any questions or need further support please feel free to contact our support team via our
mailing list. Please include logfiles and scenario files in your request, if relevant. We also look forward
to get your feedback for improvements of the VSimRTI documentation as well as the installation and
configuration process.
VSimRTI at a glance
VSimRTI was built to support users performing V2X simulations while maintaining the flexibility to choose
which simulators to use. It offers interfaces for the integration of different simulators, e.g. for network,
traffic, and environment simulations to provide flexibility to exchange a simulator without changing the
underlying infrastructure. For the synchronization and the communication among all components the
implemented infrastructure uses common concepts defined in the Institute of Electrical and Electronics
Engineers (IEEE) standard for modelling and simulation (M&S) high-level architecture (HLA). Thus
the runtime infrastructure VSimRTI allows a flexible combination of time-discrete simulators for V2X
simulations. Based on the (possibly differing) requirements of a specific scenario arbitrary simulators
can be added to VSimRTI and are executed together.
VSimRTI is written in the programming language Java and deployed as Java Archive (JAR) files. Therefore
for execution a compatible Java Runtime Environment (JRE) for your operating system needs to be
installed. The following table shows the supported versions
Version
6.0.35 and before
7.0.1 and above
Supported
no
Table 1.1: Supported Java versions
1 Introduction
1.2 Download and install
1.2 Download and install

Download vsimrti-bin.zip from the DCAITI website .
The package
vsimrti-bin.zip
has to be extracted to an arbitrary path. This installation path is referenced as
vsimrti
throughout this document.
1.3 License
The licensing mechanism was introduced for a better release control. It improves the user support
whilst helping the developer team to deactivate outdated releases which cannot be maintained anymore.
Each user needs to be registered at the license server to obtain a license which is a very straightforward
procedure.
1. For registration, the user id and basic system information are stored at the server. After the first
start of VSimRTI without a valid license a warning appears, stating that there was no license file
found and a
vsimrti/systeminfo.txt
text file is generated.
For the initial launch of VSimRTI, without license, any user name can be used. As an example, you
can use -u abc.
2. The created file contains basic information in plain text about the machine on which VSimRTI was
executed and is used to identify the user. The system info needs to be sent to the VSimRTI mailing
list. A member of staff registers the new user at the VSimRTI license server as soon as possible,
usually within one workday. When your license is active, you get an email with your userid.
3. The following information is stored to identify your machine:
central processing unit (CPU) model id
CPU cores
CPU architecture
Media Access Control (MAC) addresses
operating system name
operating system version
random-access memory (RAM) size
sockets
hashed user id
1 Introduction
1.4 Concept
VSimRTI version
4. Directly after confirmation by the VSimRTI team the license is activated. On the next VSimRTI run
with an available Internet connection to the VSimRTI license server a valid license is generated and
a local copy is stored in the VSimRTI folder.
5. The local license files
vsimrti/vsimrti-license.lcs
and
vsimrti/vsimrti.dat
are valid for the next 14 days. In this period no Internet connection is needed for the execution of
VSimRTI. Every time when an Internet connection to the license server can be established the local
license file is renewed for a further 14 days.
Notice: You should not backup the license files. If you have a registered account and a
valid license is present on the license server you will always receive a new license file.
1.4 Concept
In contrast to existing fixed simulator couplings VSimRTI allows the easy integration and exchangeability
of simulators. Thus, the high flexibility of VSimRTI enables the coupling of the most appropriate simulators for a realistic presentation of vehicle traffic, emissions, wireless communication, and the execution of
V2X applications. Depending on the specific requirements of a simulation scenario the most appropriate
simulators can be used.
1.4.1 Federates and Ambassadors

VSimRTI uses the federate-ambassador concept inspired by the concept of the HLA. Using this concept, it
is possible to couple different simulation systems with a remote control interface. Attaching an additional
simulator only requires that the ambassador interface is implemented and the specified commands can
be executed.
1.4.2 Root configuration

This ambassador can be configured with a configuration file. The specific path is
vsimrti/scenarios/<scenarioName>/vsimrti/vsimrti_config.xml
2 VSimRTI configuration
2.1 Overview
VSimRTI can be configured by adapting the files in the /vsimrti/etc directory. A full example of the default
configuration files can be found in A.2.
2.2 Host configuration

This part of software can be configured with a configuration file. The specific path is
vsimrti/etc/hosts.json
Notice: The documentation for the VSimRTI specific component is freely available on
the DCAITI website , explaining all available options.
This file is used for configuring simulation runs using multiple machines. Under normal circumstances it
is not necessary to change this file.
In VSimRTI there are two kinds of hosts: local and remote hosts. All host have to be identified with a
unique string that is valid for the remainder of the configuration to reference a defined host.
For a local host additionally the operating system and a name of a directory that is used to deploy needed
federates is necessary. Values for operating systems are "linux" or "windows".
The syntax for referenced paths has to be chosen according to operating system standards (e.g. /vsimrti/temp for GNU/Linux and C:\vsimrti\temp for Microsoft Windows). Note that also relative paths are
possible.
For remote hosts SSH and SFTP is used to deploy and start federates. Therefore the address of the host as
well as the port, user name, and password for an SSH connection must additionally be given.
3 Simulators
VSimRTI couples different simulators and cant be run alone. Therefore, it requires pre-installed simulators. In this chapter we give an overview of common simulators already supported as well as basic
configuration help. For further information and configuration options please see the javadoc documentation provided on the VSimRTI website . To run other simulators than the provided ones, an additional
component has to be written, which couples the simulator to VSimRTI. If you have any questions or
need further support, please feel free to contact our support team via our mailing list.
3.1 Kinds of simulators

The figure 3.1 gives an overview of the currently available simulators for VSimRTI
vsimrti
network simulators ...................................................... (see 3.1.1)
Java in Simulation Time (JiST)/Scalable Wireless Ad hoc Network Simulator (SWANS) ............................................................. (see 3.2)
OMNeT++ (OMNeT++) ...................................................... (see 3.3)
network simulator 3 (ns-3) ............................................ (see 3.4)
traffic simulators ...................................................... (see 3.1.2)
Simulation of Urban Mobility (SUMO) .................................. (see 3.5)
Verkehr In Stdten - Simulationsmodell (VISSIM) .................... (see 3.6)
cellular simulators ..................................................... (see 3.1.3)
VSimRTI cellular simulator (built in) ............................... (see 3.9)
environment simulators .................................................. (see 3.1.5)
VSimRTI Eventserver .................................................... (see 3.7)
eWorld environment simulator .......................................... (see 3.8)
application simulators .................................................. (see 3.1.4)
VSimRTI application simulator (built in) ........................... (see 3.10)
VSimRTI mapping3 (built in) ..................................... (see 3.10.8)
naviagtion simulators ................................................... (see 3.1.6)
VSimRTI navigation simulator (built in) ............................ (see 3.11)
Figure 3.1: VSimRTI simulator structure
3.1.1 Network simulators

A network simulator is a piece of software modeling the behavior of a network by calculating the interactions between all partaking entities. For VSimRTI and more specifically the communication in a V2X
3 Simulators
environment this refers to simulations of the wireless transmissions taking place between the various
simulated entities.
Notice: To permit parallel usage SWANS and OMNeT++ are connected to VSimRTI on
different ports (which is not mandatory).
3.1.2 Traffic simulators

A traffic simulator is a software modeling the movements of users in a traffic system. Users can mean
cars, pedestrians, trains, ships, planes etc. Traffic simulators can be discriminated by various measures,
of which one is the used scope:
Microscopic models Simulate each car individually and through the interaction of multiple cars
also traffic flows. They are commonly used for situations such as a traffic crossing or an on-ramp
situation.
Macroscopic models Models of a traffic flow without the modelling of individual cars. Instead the
traffic flow is computed using models derived from fluid dynamics or gas-kinetics. By this the
simulation is computationally far less expensive, so more cars and wider areas can be simulated.
An example would be the prediction of traffic jams.
Mesoscopic models Try to bridge the gap between macroscopic and microscopic simulation using
individual vehicles that are being actuated by macroscopic control variables.

Sub-Microscopic models Used to simulate a car in as much detail as possible. The prediction of the
behavior is the most precise of all models, but also computationally the most expensive.
The two currently supported traffic simulator SUMO and VISSIM are both microscopic traffic simulators.
3.1.3 Cellular simulators

Cellular simulators are a special case of network simulators: They simulate the communication taking
place within a cellular network. They can be used as an alternative or addition to a classic network
simulator.
3.1.4 Application simulators

An application simulator is an important component enabling the simulation and creation of V2X
applications. It follows the European Telecommunications Standards Institute (ETSI) standards for
Vehicle-to-Vehicle (V2V) communication. These standards contain message definitions like Decentralized
Environmental Notification Messages (DENM) and Cooperative Awareness Messages (CAM) and also a
general application container design.
3.1.5 Environment simulators

This kind of simulator simulate certain events such as rain, fog, snow, etc..
3 Simulators
3.1.6 Navigation simulators

This is an auxiliary simulator enabling the conversion between different navigational messages used in
the various other simulators.
3 Simulators
3.2 JiST/SWANS
3.2 JiST/SWANS
SWANS is a scalable wireless network simulator built atop the JiST platform.
It was originally released in 2004 by the Cornell University and is free for academic use. Since it was
developed for the simulation of Mobile Ad hoc Network (MANET)s it comes along with the most important models for communication according to IEEE 802.11 on the one hand and exhibits a reasonable
performance in large scale scenarios on the other hand. In the meantime several extensions from other
departments came up with the VANET extension from University Ulm being the most interesting. This
version includes a new Routing Protocol for Geographic Routing, several bugfixes and enhanced mobility
models and is the basis of V2X communication research connected with VSimRTI.
In the release 0.9.9 of VSimRTI, SWANS was extended with a new propagation model Three Log Distance
Path Loss which is currently in experimental state.
Software information
Developer(s)
Cornell Research Foundation, Inc.

University Ulm
Written in
Java
Operating system
Cross-platform
License
open source (Cornell Research Foundation, Inc. License)
Website
http://jist.ece.cornell.edu/
http://vanet.info/jist-swans.html
Supported version(s)
1.1.1
Installation
via released installation script

Table 3.1: Software information: JiST/SWANS
3.2.1 swans-ambassador folder structure

vsimrti/scenarios/<scenarioName>/swans/swans_config.xml
<scenarioName>
swans ............................................................................
swans_config.xml ................................. ambassador configuration file
Figure 3.2: swans-ambassadorfolder structure
3.2.2 Installation
3 Simulators
3.2 JiST/SWANS
Manual installation
To install SWANS, download and extract the contents of the provided swans-patch-0.13.1.zip file in the
vsimrti/bin/fed/swans
folder of your vsimrti installation.
Installation shell script
vsimrti
bin
fed
swans
swans_installer.sh
.......................... Installation script for SWANS
Figure 3.3: SWANS folder structure
The VSimRTI all-in-one package comes with a installation script for the bash-shell, that automates the
task of the SWANS installation.
1. Make the script executable:
chmod 755 swans_installer

2. Now the script is ready to run by typing the following:
./swans_installer
3.2.3 Configuration
The SWANS configuration file contains settings of the used model parameters especially for the radio
channel, the physical layer and the routing protocol on the network layer. It consists of one section for
common parameters and two sections for node specific parameters to support different configurations
for vehicles and RSUs.
Common
Dimensions of the simulated area (NOTE: dimX and dimY must not be smaller than spatial expansions which are configured for the traffic simulator e.g. SUMO)
Configuration of the Random Number Generator (RNG) settings (with 3 supported RNGs Linear
Congruential Generator, MersenneTwister and BlumBlumShub)
Propagation models for path loss and fast fading
Path loss models Free Space, Two Ray Ground and Table do not require further parameters
Three Log Distance Model defines parameters d0, d1, d2 for reference distances and n0, n1,
n2 for path loss exponents (NOTE: this model is still experimental)
Fast fading models None and Rayleigh Fading do not require further parameters
Fast fading model for Rice Fading defines the k-factor for the relation of the dominant LOS
path over the equal distributed NLOS paths
3 Simulators
3.2 JiST/SWANS
Common parameters for physical layer (NOTE: default values of SWANS assume the standard IEEE
802.11b, even if IEEE 802.11p is the reference standard for vehicular communication)
Routing models
None means no routing is applied and V2X messages are sent using singlehop broadcasting
CGGC (Cached Greedy GeoCast) configures the georouting protocol implemented by Ulm
University
Node Specific (Vehicle and RSU)
Specific physical layer parameters for vehicles and RSUs (e.g. different antenna heights, tx power,
rx sensitivity)
10
3 Simulators
3.3 OMNeT++
3.3 OMNeT++
OMNeT++ itself is solely the simulation platform for discrete-event systems. Even though it is primarily
targeted at simulating computer networks and distributed systems, it cannot be used without any
extensions for wireless communication. For this kind of simulations, external model frameworks have
to be included. Currently there are two prominent model frameworks which cover whole model suites
for according focus of wireless research. These are the Mobility Framework and the INET Framework.
A further interesting project is INETMANET which is a development branch of the INET Framework. It
was extended with special focus on MANET simulations, including more sophisticated models for Radio
Channel and PHY Layer as well as further Routing Protocols. Compared to INET master branch the model
capabilities are better suited for V2X communication. Hence INETMANET is used for the integration of
OMNeT++ to the VSimRTI simulation environment.
For an Internet Mobile Ad hoc Network (INETMANET) extension you should look closer on the website
https://github.com/inetmanet.
Developer(s)
OMNeT++ Community and OpenSim Ltd.
Written in
C++
Operating system
Windows (mingw), Linux
License
open source for academic use
Website
http://www.omnetpp.org/
https://github.com/inetmanet
4.1
Installation
via released installation script

Table 3.2: Software information: OMNeT++
3.3.1 omnetpp-ambassador folder structure

The omnetpp.ini file has to be located in the omnetpp folder of the scenario configuration.
<scenarioName>
omnetpp ..........................................................................
omnetpp.ini ....................................... ambassador configuration file
Figure 3.4: omnetpp-ambassador folder structure
3.3.2 Installation
The OMNeT++ binaries are not included in the VSimRTI all-in-one Package. But an additional binary
package was set up and can be downloaded from the VSimRTI release area. It contains:
11
3 Simulators
3.3 OMNeT++
The OMNeT++ federate as executable

The INETMANET model framework as library
An exemplary
vsimrti/scenarios/<scenarioName>/omnetpp/omnetpp.ini
configuration file
The executable was compiled for 64-bit GNU/Linux based operating systems. It was successfully set
up under Ubuntu 10.04.2 LTS and Gentoo-Linux 1.12.14 and depends mainly on the installed shared
libraries. First of all it requires OMNeT++ libraries. That means OMNeT++ needs to be installed prior
to VSimRTI and the omnetpp-federate. The second type of required libraries are general libs which are
shipped with current GNU/Linux distributions or need to be installed manually. These are:
Listing 3.1: OMNeT++ dependencies.
libdl . so .2
libstdc ++. so .6
libm . so .6
libgcc_s . so .1
libc . so .6
libpthread . so .0
libtk8 .5. so
libtcl8 .5. so
libz . so .1
libxml2 . so .2
libmpi_cxx . so .0
libmpi . so .0
libopen - rte . so .0
libopen - pal . so .0
libnsl . so .1
libutil . so .1
libX11 . so .6
libXft . so .2
libxcb . so .1
libfontconfig . so .1
libfreetype . so .6
libXrender . so .1
libXau . so .6
libXdmcp . so .6
libexpat . so .1
Finally the libinet.so is required which is actually the library for the INETMANET model framework.
Set up OMNeT++
Manual installation
To set up OMNeT++ with VSimRTI the following steps are promised to be successful:
1. Install OMNeT++ 4.1 according to the procedure, described on the OMNeT++ website
(www.omnetpp.org).
2. Include the bin folder to the PATH depending on the location OMNeT++ is installed (see listing 3.2).
3. Include the libraries in the LD_LIBRARY_PATH environment variable. This can be checked with
ldd. At least the libinet.so in the inetmanet-folder needs to be added (see listing 3.2).
12
3 Simulators
3.3 OMNeT++
4. Copy the binaries from the OMNeT++ binary package to fed-folder in the VSimRTI all-in-one
package to receive the folder structure as presented in the following Table.
5. Set up an
omnetpp.ini
file in the omnetpp folder of the scenario to be simulated. An example file can be found in
the configuration folder of the OMNeT++ package and the tiergarten scenario is already set up
according to this scheme.
6. For reasonable result logging, the logger-configuration in
vsimrti/etc/logback.xml
has to be adapted to support the OMNeT++ ambassador and federate.
7. At last OMNeT++ has to be activated in the vsimrti_config.xml and the simulation can be started.
Listing 3.2: OMNeT++ environment variables.
# Setting the PATH variable

export PATH = $PATH :/ opt / bin / omnetpp -4.1/ bin
or
export PATH = $PATH :/ usr / local / bin / omnetpp -4.1/ bin
# Setting the L D_ L IB R AR Y_ P AT H variable
export LD_L I BR AR Y _P AT H = $ L D _ L I B R A R Y _ P A T H : inetmanet
Installation shell script
vsimrti
bin
fed
omnetpp
set_env.sh .................. Script to set the required environment variables
omnet_installer.sh ........... Installation script for OMNeT++/INETMANET
Figure 3.5: OMNeT++ folder structure
The VSimRTI all-in-one package comes with an experimental installation script for the bash-shell, that
automates the task of the OMNeT++/INETMANET installation.
1. Make the script executable:
chmod 755 set_env

chmod 755 omnet_installer
2. Run the first script to set the required environment variables for the OMNeT++/INETAMET installation:
./set_env
3. Run the second script to install OMNeT++/INETMANET:
./omnet_installer
13
3 Simulators
3.3 OMNeT++
3.3.3 Configuration
The whole OMNeT++ specific configuration is done via the omnetpp.ini file. It covers static parts for
the simulator coupling as the specific VSimRTI Event Scheduler and the ScenarioManager. Furthermore
logging configurations and the typical parameters for the communication layers (MAC, PHY and Radio
Channel) are addressed. The communication parameters are, similar to the SWANS implementation,
different for vehicles and RSUs. Please refer to the OMNeT++ documentation on the OMNeT++ homepage
for further information about the structure of the omnetpp.ini file.
14
3 Simulators
3.4 ns-3
3.4 ns-3
The network simulator 3 (ns-3) is a discrete-event network simulator, that was started as an opensource project by a team led by Tom Henderson from the University of Washington in July 2006 and
made its first release in June 2008. Ns-3 is targeted primarily towards research and educational use and
thereby, also offers a vital community of developers and maintainers. It was developed as a replacement
for the popular network simulator 2 (ns-2) and mainly focuses upon improving the core architecture,
software integration, models, and educational components for real-world network devices and protocols
(regardless, ns-2 still remains in active use and will continued to be maintained in the near future). It
simulates both unicast and multicast protocols and is used extensively in research on mobile ad-hoc
networks
Like other network simulators, ns-3 has a relatively steep learning curve, especially compared to GUIbased simulators. If you have no prior experience with ns-3, we recommend to familiarize yourself with
the ns-3 simulation environment and the ns-3 simulation basics first. The ns-3 documentation can be
found under:
http://www.nsnam.org/documentation
To take your first steps with ns-3, you might want to download1 the latest version, build a copy of ns-3 (it
uses the Python-based build-system waf) and take a look at the examples, that are shipped within most
of the ns-3 source code repositories and packages. You might also examine the simulation output and try
to adjust it.
Typically, a ns-3 user will work under a Linux environment. For those running under Windows, there
do exist environments which simulate the Linux environment to various degrees. The ns-3 project has
in the past (but not presently) supported the Cygwin environment for these users (see http://www.
cygwin.com for details on downloading). MiniGW is presently not officially supported. According to
the ns-3 installation guide, the officially supported platforms include (please note, that plenty of other
distributions are likely to work with ns-3 regardless):
Fedora 17 (32/64 bit) with g++-4.7.0
Fedora 15 (64 bit) with g++-4.6.3
Ubuntu 12.04 (32/64 bit) with g++-4.6.3
Ubuntu 10.04.4 LTS (64 bit) with g++-4.4.3
OS X Mountain Lion 10.7.4 with g++-4.2.1
OS X Snow Leopard 10.6.8 with g++-4.2.1
FreeBSD 8.2 (32 bit) with g++-4.2.1
Cygwin 1.7.9-1 with g++-4.5.3
1 Please note, that downloading ns-3 via tarball is simpler than the Mercurial process since all of the pieces are pre-packaged for
you.
15
3 Simulators
3.4 ns-3
Important: As stated above, ns-3 is primarily developed on and for GNU/Linux platforms. Since Windows is such a widely used platform and Cygwin is not a perfect emulation
of any Linux, we highly recommended for non-Linux users to consider the installation of a
Linux virtual machine with a virtual machine environment, such as VMware2 or VirtualBox3 .
Developer(s)
Tom Henderson, Mathieu Lacage, George Riley, Mitch Watrous,

Gustavo Carneiro, Tommaso Pecorella and others
Written in
C++ (core) and Python (bindings)
Operating system
GNU/Linux FreeBSD Mac OS X
License
free software: GNU GPLv2
Website
http://www.nsnam.org/
3.15
Deployed in VSimRTI all-in-one
no (and need a patch to link)

Table 3.3: Software information: ns-3
3.4.1 ns3-ambassador folder structure

<scenarioName>
ns3
ns3_config.xml
.................................... ambassador configuration file

Figure 3.6: ns3-ambassador folder structure
Important: Currently, there is no need to configure the ns-3 ambassador with a XMLconfiguration file (i.e. the configuration file is not read by the ambassador).
3.4.2 Installation
VSimRTI offers support for the current stable release of ns-3 (3.15), that was released in August 2012 (older
versions of ns-3 (prior to 3.15) are not supported). The coupling to VSimRTI is designed in a manner of
minimal code changes on the ns-3 simulator itself to keep the update capabilities for future versions.
Prerequisites
For GNU/Linux platforms, the minimal requirements to run basic simulations are a gcc or clang compiler
and a Python interpreter:
Linux x86 and x86_64: gcc versions 4.1 through 4.7 and, 3.4.6, clang versions 3.0 and 3.1.
2 http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_(Windows)
3 http://www.nsnam.org/wiki/index.php/HOWTO_use_VirtualBox_to_run_simulations_on_Windows_machines
16
3 Simulators
3.4 ns-3
FreeBSD x86 and x86_64: gcc version 4.2, clang versions 3.0 and 3.1.
Mac OS X ppc and x86: gcc versions 4.0 and 4.2,
The core of ns-3 requires a gcc/g++ installation of 3.4 or greater and Python 2.4 or greater. As mentioned
in the ns-3 documentation, different options require additional support. At least you need the following
packages to be installed:
Listing 3.3: Ns-3:
Minimum requirements
gcc
g ++
python
python - dev
For a complete list of required packages for different distributions, please refer to the ns-3 installation
guide:
http://www.nsnam.org/wiki/index.php/Installation
Run the installation script
Important: Ns-3 requires several packages to be installed on your computer. You will
need to ensure, that all required libraries are present on your system before proceeding. You
may need superuser permissions to install packages.
To ease the installation of ns-3 for VSimRTI, the installation process has been delegated to an installation
script, that can be found in the associated ns-3 federate folder.
vsimrti
bin
fed
ns3
ns3_installer.sh
............................... Installation script for ns-3
Figure 3.7: ns3-ambassador federate folder structure
The ns-3 installation script accomplishes the following tasks:

1. Download ns-3 tarball from the offical sources
2. Download the ns-3 federate for VSimRTI.
3. Apply a patch to ns-3 in order to make it work with VSimRTI.
4. Add the ns-3 federate to the waf build system.
5. Configure and build the patched ns-3 with the ns-3 federate.
In order to start the simulation, the following steps need to be performed:
1. Set up the confWifi.xml-file in the scenario folder (see section 3.4.3). An example confWifi.xmlfile is shipped with the Tiergarten scenario.
2. For reasonable result logging, the logger-configuration in vsimrti/etc/logback.xml has to be
adapted to support the ns-3 ambassador and federate.
17
3 Simulators
3.4 ns-3
3. At last ns-3 has to be activated in the vsimrti_config.xml and the simulation can be started.
3.4.3 Configuration
The whole ns-3 specific configuration is done via the confWifi.xml and configTechnologies.xml
files.
Listing 3.4: confWifi.xml
<? xml version = " 1.0 " encoding = " UTF -8 " standalone = " no " ? >
< wifi >
<! -- IPv4 address generator -- >
< ipConfig u ra ti o n >
< ip address = " 192.168.0.0 " mask = " 255.255.0.0 " / >
</ ipConf i gu ra t io n >
<! -- Calculate a propagation delay -- >
< propagationDelayModel >
< delay model = " n s 3 : : N o n e P r o p a g a t i o n D e l a y M o d e l " / >
</ p r o p a g a t i o n D e l a y M o d e l >
<! -- Modelize the propagation loss through a transmission medium -- >
< propagationLossModel >
< loss model = " n s 3 : : F r i i s P r o p a g a t i o n L o s s M o d e l " / >
</ p r o p a g a t i o n L o s s M o d e l >
< wif iCo n f i g u r a t i o n >
<! -- Create non QoS - enabled MAC layers -- >
< wifiMac property = " type " value = " n s 3 : : A d h o c W i f i M a c " / >
<! -- Wifi PHY mode -- >
< wifiManager property = " phyMode " value = " O fdmRat e54Mbp s " / >
<! -- Wifi manager -- >
< wifiManager property = " type " value = " n s 3 : : C o n s t a n t R a t e W i f i M a n a g e r " / >
<! -- The energy of a received signal should be higher than this threshold ( dbm ) to allow
the PHY layer to detect the signal -- >
< wifiPhy property = " E n e r g y D e t e c t i o n T h r e s h o l d " value = " -81.0 " / >
<! -- The energy of a received signal should be higher than this threshold ( dbm ) to allow
the PHY layer to declare CCA BUSY state -- >
< wifiPhy property = " C c a M o d e 1 T h r e s h o l d " value = " -99.0 " / >
<! -- Transmission gain ( dB ) -- >
< wifiPhy property = " TxGain " value = " 0.0 " / >
<! -- Reception gain ( dB ) -- >
< wifiPhy property = " RxGain " value = " 0.0 " / >
<! -- Number of transmission power levels available between TxPowerStart and TxPowerEnd
included -- >
< wifiPhy property = " TxPowerLevels " value = " 1 " / >
<! -- Maximum available transmission level ( dbm ) -- >
< wifiPhy property = " TxPowerEnd " value = " 17.0 " / >
<! -- Minimum available transmission level ( dbm ) -- >
< wifiPhy property = " TxPowerStart " value = " 17.0 " / >
<! -- Loss ( dB ) in the Signal - to - Noise - Ratio due to non - idealities in the receiver -- >
< wifiPhy property = " RxNoiseFigure " value = " 0.0 " / >
<! -- Channel center frequency = Channel starting frequency + 5 MHz * ( nch - 1) -- >
< wifiPhy property = " ChannelNumber " value = " 1 " / >
</ wi fiC o n f i g u r a t i o n >
</ wifi >
The IP configuration information includes the network address and network mask. The ns-3 propagation
module defines two generic interfaces, namely PropagationLossModel and PropagationDelayModel,
for the modelling of propagation loss respectively propagation delay.
In the default confWifi.xml, the Wi-Fi device uses the ns-3 standard propagation delay model
ns3::ConstantSpeedPropagationDelayModel and the ns-3 standard propagation loss model
18
3 Simulators
3.4 ns-3
ns3::FriisPropagationLossModel. Radio propagation models in ns-3 can easily be exchanged with

the ns-3 class registration system (see the ns-3 documentation for details). The Wi-Fi configuration
includes additional parameters, like sending power and antenna gain.
Listing 3.5: configTechnologies.xml
< ns3Config u r a t i o n >
< installers >
< installer type = " n s 3 : : W i f i V e h i c l e I n s t a l l e r " name = " WifiVehicle " file = " confWifi . xml "
default = " true " / >
< installer type = " n s 3 : : M o b i l i t y M o d e l I n s t a l l e r " name = " Mobility " default = " true " / >
</ installers >
</ ns3Confi g u r a t i o n >
The configuration manager of the ns-3 federate defines, which installer should be loaded for the Wi-Fi
device (refering to the confWifi.xml) and the mobility model. Usually, you dont need to take any
changes and simply use the default configuration file, that ships with the ns-3 federate.
19
3 Simulators
3.5 SUMO
3.5 SUMO
SUMO is an highly portable, microscopic and continuous road traffic simulation package. It is designed
to handle large road networks faster than real-time. Each vehicle has an own route and is simulated
individually.
Developer(s)
German Aerospace Center
Written in
C++
Operating system
GNU/Linux and Microsoft Windows
License
Website
http://sumo.sourceforge.net/
0.19.0
no
Table 3.4: Software information: SUMO
3.5.1 sumo-ambassador folder structure

vsimrti/scenarios/<scenarioName>/sumo/sumo_config.json
<scenarioName>
sumo .............................................................................
<scenarioName>.edg.xml .............................................. Edge file
<scenarioName>.net.xml ........................................... Network file
<scenarioName>.nod.xml ............................................. Node file
<scenarioName>.rou.xml ............................................. Route file
<scenarioName>.sumo.cfg ............................... sumo configuration file
sumo_config.json ................................. ambassador configuration file
Figure 3.8: sumo-ambassadorfolder structure
3.5.2 Installation
For Microsoft Windows operating systems download and extract
sumo_winbin.zip
from the SUMO website. For GNU/Linux operating systems download and extract the provided
GNU/Linux binaries or build sumo by yourself. Please refer to the SUMO Wiki for further information.
20
3 Simulators
3.5 SUMO
In order to run SUMO with VSimRTI you need to make the SUMO binaries available system wide by
adding the SUMO binary folder to your PATH environment variable (see section 10.2).
3.5.3 Configuration
The SUMO configuration consists of sumo specific config files and the sumo-ambassador configuration
file.
vsimrti/scenarios/<scenarioName>/sumo
. Your main configuration file name must end with the suffix *.cfg . The SUMO Wiki covers more
information and also a tutorial about the different configuration files. Route-, network- and SUMO
configuration files have been generated (using scenario-convert or by yourself). The last step is the
creation of a sumo-ambassadorconfiguration file.
In contrast to standard traffic simulations using SUMO only, VSimRTI handles the SUMO files in a slight
different way , i.e. the route file for a simulation is created at runtime to enable dynamic routing. To get
correct simulation results, we recommend using the scenario-convert tool to create the SUMO files out
of OpenStreetMap data (see section ??).
3.5.4 Further information

VSimRTI specific information
Notice: SUMO broadcasts VehicleMovements in fixed time steps and also sends a
TrafficLightUpdate message, when the tl-state change was initiated in the previous step. For
dynamic change of vehicle behavior during simulation, SUMO subscribes to the messages VehicleTypesInitMessage , VehiclePathsInitMessage , SetMaxSpeed , SlowDown , ChangeRoute ,
ChangeStaticRoute and ChangeTrafficLightsState.
Important:
The difference between ChangeRoute and ChangeStaticRoute is that
ChangeRoute uses the Re-route feature of SUMO where a new route is calculated internally
by SUMO according to a better travel time. ChangeStaticRoute is always used in conjunction
with the NavigationAmbassador which does the route calculation and SUMO takes this route
statically even if it has e.g. a worse travel time. To avoid confusions of routes, ChangeRoute
and ChangeStaticRoute should not be used concurrently.
Known Issues
Traffic light handling in sumo has changed with version 0.13.0, which breaks the support of the
tls.join command of netconvert in VSimRTI > 0.9.12
21
3 Simulators
3.6 VISSIM
3.6 VISSIM
VISSIM is a microscopic multi-modal traffic flow simulation software.
Developer(s)
PTV Planung Transport Verkehr AG
Written in
C++
Operating system
Microsoft Windows
License
Website
http://www.ptv-vision.com/de/produkte/vision-trafficsuite/ptv-vissim/
>5.30
Table 3.5: Software information: VISSIM
To run VISSIM with VSimRTI, additional configuration and modification of VISSIM is necessary. If you
have any questions or need further support, please feel free to contact our support team via our mailing
list.
22
3 Simulators
3.7 VSimRTI Eventserver
3.7 VSimRTI Eventserver

3.7.1 eventserver-ambassador folder structure
vsimrti/scenarios/<scenarioName>/eventserver/eventserver_config.json
<scenarioName>
eventserver .....................................................................
eventserver_config.json .......................... Eventserver configuration file
Figure 3.9: eventserver-ambassador folder structure
3.7.2 Installation
This simulator does not need to be installed. It is delivered as part of the VSimRTI-installation package.
3.7.3 Configuration
The root node of the configuration is a list of environment events. Each event require the type of the
event, a rectangle area, a strength and the time window.
23
3 Simulators
3.8 eWorld
3.8 eWorld
The Hasso-Plattner-Institut fr Softwaresystemtechnik (HPI) in Potsdam founded in year 2009 a combination of enviroment simulator and traffic visualizer aspecially for traffic visualisation and analysis. The
core of the eWorld enviroment simulator is called eWorldEventServer.
It is capable of handling vehicle movement messages and create sensor events according to environmental
data.
The eWorld-eventserver can be used to simulate events (e.g. rain, fog, ice, ...). The eWorld-eventserver
can be considered as an interface between a socket and the eWorld data management (*.ewd and *.json
export file).
Developer(s)
HPI
Written in
Java
Operating system
Cross-platform
License
Website
http://eworld.sourceforge.net/
1.0.1
Table 3.6: Software information: eWorld
3.8.1 eworld-ambassador folder structure

vsimrti/scenarios/<scenarioName>/eworld/eworld_config.json
<scenarioName>
eworld ...........................................................................
<scenarioName>.ewd .......................................... eWorld binary file
eworld_config.json ............................... ambassador configuration file
<scenarioName>Export.json ............................. eWorld JSON export file
Figure 3.10: eworld-ambassador folder structure
3.8.2 Installation
Simply download and use from the website. Be sure to use the latest eWorld release (1.0.1) when using
the latest VsimRTI release.
24
3 Simulators
3.8 eWorld
3.8.3 Configuration
You can configure the eWorldEventServer via Command Line Interface (CLI) with a base64 encoded json
configuration object from class CEworldEventServer .
This class provide different ways to input data.
A database configuration CDatabase database , a ewd file configuration CFile ewdFile , a json
export file CFile jsonFile or a json string String jsonString .
The prefered way is a export from eWorld to a jsonFile. Afterwards just put the exportet file (.json, .js, .txt)
in the configuration directory mentioned above.
To create a eWorld scenario, please refer to the eWorld Website. There you find a detailed user manual.
25
3 Simulators
3.9 VSimRTI cellular simulator

3.9.1 cell-ambassador folder structure
The VSimRTI cellular simulator can be configured via three distinct configuration files, which can be
found within the scenarios folder structure:
<scenarioName>
cell
network.json ......................................... Network configuration file
regions.json .......................................... Regions configuration file
geoserver.json ..................................... Geoserver configuration file
Figure 3.11: cell-ambassador folder structure
3.9.2 Installation
3.9.3 Configuration
The VSimRTI built-in cellular simulator enables the applications to use cellular phone communication.
If you use the cellular simulator you must not use any other network simulator.
The applications have to be altered for the use with the cellular simulator as well as the scenario.
We provide a cellular configuration file in the example scenario Schwanebeck. Please note that in the
default configuration of this scenario the Cellular Simulator is deactivated. To activate the cellular
simulator just add
<! -- Cell federate -- >
< federate id = " cell " active = " true " / >
to the
vsimrti/scenarios/<scenarioName>/cell/network.json
(or, if this line already exist, make sure active is true). With this done you now can deactivate all network
simulators:
<! -- Network simulator federates -- >
< federate id = " swans " active = " false " / >
< federate id = " omnetpp " active = " false " / >
The simulation of cellular communication in VSimRTI consists of two parts: The cellular simulator
itself and the various changes made to the Application Simulator. These changes are done in a generic
way, making the cellular simulator exchangeable. Users interested in a more sophisticated simulation
of cellular communication may use other simulators and develop ambassadors connecting them to
VSimRTI.
26
3 Simulators
The cellular simulator in its current version delivers every message. There is no simulation of a maximum
capacity of the cellular network, no dead zone, no simulation of the individual antennas of the network.
A delay estimation is carried out, deterministic or non deterministic.
The
global
configuration
for
the
cellular
simulator
in
vsimrti/scenar-
ios/<scenarioName>/cell/network.json, including the global region, could look like this:
{
"configuration":{
"randomSeed":-1,
"deterministic":true,
"maxNodeBandwidth":100000000 /* Bit/s */
},
"delay":{
"delayAverage":300,
"minDelay":20,
"delayType":"ConstantDelay",
"pdr":1.0,
"throughput":5000000,
"simpleRandomDelaySteps":3
},
"logging":{
"logPumsWithInfo":true
}
}
Note that all bandwidths are given in bit per second and all delays in milliseconds. Also, every json
configuration goes through a minifier, so comments are allowed in the configuration files. An example
would be the maxNodeBandwidth option.
The Geoserver
The vehicles, also called nodes, send out messages. The process is very analogous to that of normal
V2X-Messages. The content is therefore the same. The messages can be directed to one single node
(Unicast), every node (Broadcast) or all nodes within a specified region (Geocast). Messages directed to
nobody are interpreted as Position Update Messages (PUM)s.
The messages are forwarded through the cellular network to a central instance, here called Geoserver.
The design chosen for this element closely resembles the design chosen within SimTD.
The Geoserver keeps a list of all nodes and updates their position with every new incoming message (be
it a PUM or any other). Based on this stored information the messages are then processed. This means in
particular: A Geocast is commenced based on the latest positional information found stored within the
Geoserver. When a node has not send out a PUM yet it will not receive the message. If the last known
position of the node is outside the targeted area the node will not receive the message even if it moved
into the area in the meantime.
27
3 Simulators
The Geoserver is also able to recast warnings by itself.
If this option is enabled (
warnings.mergeWarnings ) than all Geocasts will be put into a list.
At regular intervals (
warnings.reemitInterval ) the warnings will be reemitted, i.e. send to all nodes within the
original geocast-area. The warnings is only send once to every node (The Geoserver keeps a list of all
nodes it has send the warning too).
Additionally the Geoserver tries to merge similar warnings. If the type is the same and the distance is
close enough (smaller than warnings.mergeDistance ) than the newer warning will be ignored. Also a
warning will be discarded after a certain time ( warnings.keepAliveTime ), given that no other warning
was received which was merged with the original warning.
The configuration of the Geoserver can be adjusted in the geoserver.json file. A working sample
configuration could look like this:
{
"warnings":{
"mergeDistance":100,
"mergeWarnings":true,
"reemitInterval":1000,
"keepAliveTime":600
},
"positionTable":{
"positionGuessInterval":1000
}
}
Delay estimation
The most important feature of the cellular simulator is a estimation of the delay experienced through the
transport over the cellular network. Currently no delay is emulated for the transportation and calculation
done in the backbone of the network. This is mainly due to the expected delay being very small and
constant, thus having little effect on the simulation.
The messages are correctly ordered according to their delay: If message A was to be transmitted t d
seconds before message B but took t a > (t d + t b ) to be transmitted over the network (t b being the delay
experienced by message B) than message A will arrive after message B at the Geoserver. The same is true
for transmissions from the Geoserver to a node.
The cellular simulator offers various modes to estimate the delay of the transmissions. The type of
estimation is specified with by delay.delayType.
delay.delayType = constantDelay, Constant Delay: The message is transmitted with
the lag being exactly equal to network.delay.delayAverageMs.
delay.delayType = simpleRandomDelay, Simple Random Delay: The lag is random, being a multiple of network.delay.delayAverageMs. The number of possible delays can be configured in network.json.
28
3 Simulators
delay.delayType = gammaRandomDelay, Gamma Random Delay: A gamma distribution is

used to estimate the lag, with = 2 and = 2. The minimum delay delay.minDelayMs is added
to the result. The curve is fitted so that the maximum likelihood for the delay is exactly equal to
delay.delayAverageMs.
delay.delayType = gammaSpeedDelay, Gamma Speed Delay: This mode closely resembles the Gamma Random Delay. Additionally a penalty for the velocity with which the node
is moving is calculated. This penalty is then multiplied with the original delay.
Delay regions
Additionally the user has the option to define regions with custom delays. This can be used to simulate
areas with bad reception, crowded areas etc.
The regions should be stored in vsimrti/scenarios/<scenarioName>/cell/regions.json. An example definition for a single region called Ernst-Reuter-Platz could look like this:
{
"regions":[
{ /* First local region */
"area":{
"a":{
"longitude":13.249512,
"latitude":52.871782
},
"b":{
"longitude":13.842773,
"latitude":52.401749
}
},
"name":"Ernst-Reuter-Platz",
"delayType":"SimpleRandomDelay",
"fixedDelay":200, /* This is in milliseconds */
"minDelay":300,
"throughput":35000, /* This is in bit/s */
"simpleRandomDelaySteps":3,
"pdr":1.0,
"pdrType": "DETERMINISTIC",
"regionType":"SQUARE"
}
]
}
Note that a represents the upper-left point of the rectangle and b the lower-right. For further information
about the possible options, please refer to the VSimRTI API documentation.
29
3 Simulators
When no regions are found the delay specified in the network.json-File under delay is treated as a
global fall back estimator: If the node (the vehicle) is not within a specified region the delay is estimated
using the data specified there.
Default values for the configuration
Since VSimRTI version 0.13.0 the cell configuration can be minimal, which means default values are
used for ommited keys. However, default values dont make sense for every key in the cell configuration.
Default values are defined for the following fields:
delayType, defaults to ConstantDelay
pdrType, defaults to Deterministic
fixedDelay, standard is set to 300ms
minDelay, defaults to 150ms
simpleRandomDelaySteps is set to 3 if omitted.
30
3 Simulators
3.10 VSimRTI application simulator

The application simulator implements a multi-layered application container with own application and
facility layer and interfaces to the network layer. It serves as a framework for users to create custom V2X
applications.
3.10.1 Installation
3.10.2 application-ambassador folder structure

vsimrti/scenarios/<scenarioName>/application/applications_config.json
<scenarioName>
application .....................................................................
applications .................................................................
rsu ........................................................................
trafficlight ..............................................................
vehicle ....................................................................
applications_config.json ............... Configuration file for the ambassador.
mapping3 ........................................................................
mapping_config.json ...................... Configuration file for the ambassador.
mapping ..........................................................................
applications.xml ... Enables detailed mapping of applications to simulation objects.
mapping_config.xml Main configuration file, combines all object properties and defines
ratio of vehicle types in the simulation.
rsu_positions.xml ............... Configuration of Road Side Units (RSU) locations.

vehicle_properties.xml ..................... Define special attributes for vehicle.
Figure 3.12: application-ambassador folder structure
3.10.3 Libraries
To develop applications you need to reference to the following libraries.
vsimrti/bin/fed/application/application-federate-x.x.x-shaded.jar
3.10.4 Configuration
31
3 Simulators
Most of the actual configuration of the applications is done by the mapping-simulator. The mappingsimulator is responsible for spawning the entities of the simulation and therefore also decide which
application to map onto which entity.
To deploy an application you have to put it into the appropriate subdirectory for the simulated unit.
In the application configuration file you can specify various settings to manage the message sending and
receiving of applications.
In the msg section, the minimal message length can be set in bytes.
It is also possible to configure the CAM sending behavior. This functionality has been revised in version
0.11.0, leading to probable issues with older scenarios.
To deactivate the CAM-Generation in general just delete the complete section.
Completely analogous to the CAM-Generation is the PUM-Generation. A PUM is the equivalent to a
CAM within cellular communication. Simply rename the cam -section to pum . All options are exactly the
same.
3.10.5 Development of application

Overview
Developing custom applications is rather easy in VSimRTI. If you learn quicker by just looking at source
code yourself: The applications that come with VSimRTI have the Java Source-Files included in their
respective Jar-File. Just open the Jar-File with an archiver of choice and look around.
To develop your own application you have to know three important concepts of the simulator.
One: The interfaces which every application has to implement.
Two: The interfaces you can use to retrieve information, send messages and exert control over the
vehicle.
And three: In case you want to change the content of automatically sent CAMs you need to know about
that as well.
The Application interface

The Application Simulator is the framework for the application and is responsible for basic housekeeping
duties, such as time management, starting and initializing the application. Every application needs to
implement the Application interface, providing methods for the simulator to call in case of certain
events. These methods have to be implemented, even when left empty.
Visual Paradigm for UML Standard
Edition(Technische Universitaet Berlin)
<<Interface>>
Application
+initialize(applicationLayer : ApplicationLayer) : v...
+receiveMessage(msg : TypedV2XMessage) : void
+dispose() : void
<<Interface>>
TimerCall
<<Property>> <+minimalTimerCallInterval : l...
+timerCall(time : long) : void
Figure 3.13: Application class diagram
32
3 Simulators
The Application layer

Every application has access to its own application layer.
Visual Paradigm for UML Standard Edition(Technische Universitaet Berlin)
<<Interface>>
PoolAccess
+poolAccessReference
<<Interface>>
PoolAccessReferen
ce
<<Property>> <+p...
<<Interface>>
ApplicationLaye
r
<<Interface>>
TriggerTimerCallUpdate
+triggerTimerCallUpdate() : void
<<Interface>>
ApplicationToFacility
<<Property>> <+unitType : UnitType
<<Property>> <+logger : Logger
+applicationToFacility
<<Interface>>
VehicleRoutingInformation
<<Property>> <+nodes : HashMap<String, Double>
<<Property>> <+routes : HashMap<String, ArrayList<Strin...
<<Interface>>
ApplicationToFacilityReferen
ce
<<Property>> <+applicationT...
<<Interface>>
UserTaggedValueStorage
<<Property>> <+>userTaggedValue : byte[]
<<Interface>>
CommunicationModuleReference
<<Property>> <+communicationModuleReference : CommunicationMo...
+f() : ApplicationToFacility
+communicationModuleReference
<<Interface>>
FacilityLayer
<<Interface>>
CommunicationMod
ule
+facilityLayer
<<Interface>>
MessageSender
+sendPUM() : void
+sendCAM() : void
<<Interface>>
PoolCommunicationModule
<<Property>> <+>communicationPoolActive : bool...
<<Interface>>
WLANCommunicationModule
<<Property>> <+>wLANCommunicationModuleActive : bool...
SafeTimerLong
-useFirstTimerCall : boolean = true
-lastTimerCall : long
<<Interface>>
ApplicationLayerSendMessage
+sendUdpMessageTopo(msg : TypedV2XMessage) : void
+sendTCPMessageTopo(msg : TypedV2XMessage) : void
<<Interface>>
CellCommunicationModule
<<Property>> <+>cellCommunicationModuleActive : bool...
<<Interface>>
FacilityTimerInterceptor
<<Property>> +>conguration : CFacilityTimerInterce...
<<Property>> <+enabled : boolean
<<Property>> +>facilityLayer : FacilityLayer
+SafeTimerLong(timerCall : TimerC...
+checkTimer(time : long) : boolean
+reset() : void
-timerCall
<<Interface>>
TimerCall
<<Interface>>
Application
+initialize(applicationLayer : ApplicationLayer) : v...
+receiveMessage(msg : TypedV2XMessage) : void
+dispose() : void
Figure 3.14: Application layer class diagram
Provider and Controller interface

Applications can be specific to one of three types of entities: RSUs, traffic lights and of course vehicles.
For each of them a specialized provider and controller is available.
33
3 Simulators
Provider interface
+basicProviderReference
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Interface>>
BasicProvider
+currentTime : long
+longLat : Double
+directPosition : DirectPosition
+longTimeStamp : long
+unitType : UnitType
+unitName : String
+systemState : SystemState
+attribute : SystemState
+getStateOfEnvironmentSensor(type : SensorType)...
<<Interface>>
TracLightProvider
<<Property>> +ctrLanes : Collection<String>
<<Property>> +tracLightGroup : TracLightGr...
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
<<Property>>
+tracLightProviderReference
<<Interface>>
VehicleProvider
+heading : double
+vehicleTau : double
+vehicleSigma : double
+vehicleMaxSpeed : double
+vehicleMaxAcceleration : double
+vehicleMaxDeceleration : double
+vehicleClass : VehicleClass
+currentCurveRadius : double
+vehicleLeftBlinkerOn : boolean
+vehicleRightBlinkerOn : boolean
+vehicleBrakeLightOn : boolean
+vehicleFogLightOn : boolean
+vehicleFrontLightOn : boolean
+vehicleHighBeamLightOn : boolean
+cO2Emissions : double
+currentRoadLength : double
+currentRoadMaxSpeed : double
+road : String
+speed : double
+lane : int
+route : List<String>
+routeId : String
+stopped : boolean
+charging : boolean
+stateOfCharge : oat
+batteryEmpty : boolean
+batteryFull : boolean
<<Interface>>
RSUProvider
+rSUProviderReference
<<Interface>>
PoolProvider
+vehicleProviderReference
<<Interface>>
BasicProviderReference
<<Property>> +basicProviderReference : BasicProvider
<<Interface>>
TracLightProviderReference
<<Property>> +tracLightProviderReference : TracLightProvider
<<Interface>>
VehicleProviderReference
<<Property>> +vehicleProviderReference : VehicleProvider
<<Interface>>
RSUProviderReference
<<Property>> +rSUProviderReference : RSUProvider
<<Interface>>
PoolProviderReference
Figure 3.15: Provider class diagram
Controller interface
+basicControlReference
<<Interface>>
TracLightController
<<Property>> +phaseRemainingDuration ...
<<Property>> +programById : String
+tracLightControlReference
<<Interface>>
BasicControlle
r
<<Interface>>
VehicleController
+setMaximumSpeed(speed : oat, data : BehaviorDataStruct) : void
+slowDown(speed : oat, interval : int, data : BehaviorDataStruct) : void
+changeRoute(longLat : Double, travelTime : long, data : BehaviorDataStruct) : void
+changeRoute(edgeIdList : List<String>, data : BehaviorDataStruct) : void
+changeTarget(longLat : Double, data : BehaviorDataStruct) : void
+changeLane(targetLaneIndex : int, duration : int, data : BehaviorDataStruct) : void
+changeLane(changeLaneMode : ChangeLaneMode, duration : int, data : BehaviorDataStruct) : void
+sendSumoTraciByteArrayMessage(msgId : String, msg : byte [], data : BehaviorDataStruct) : void
+stop(edgeID : String, position : double, laneIndex : byte, duration : int, stopFlag : byte, data : BehaviorDataSt...
+resume(data : BehaviorDataStruct) : void
+requestStartCharging(vehicleID : String, time : long, vehiclePosition : Double) : void
+requestStopCharging(vehicleID : String, time : long, vehiclePosition : Double) : void
<<Interface>>
RSUController
+rSUControlReference
<<Interface>>
VehicleControllerNoBehavior
<<Property>> +maximumSpeed : oat
+slowDown(speed : oat, interval : int) : void
+changeRoute(longLat : Double, travelTime : long) : void
+changeRoute(edgeIdList : List<String>) : void
+changeTarget(longLat : Double) : void
+changeLane(targetLaneIndex : int, duration : int) : void
+changeLane(changeLaneMode : ChangeLaneMode, duration : int) : void
+sendSumoTraciByteArrayMessage(msgId : String, msg : byte []) : void
+stop(edgeID : String, position : double, laneIndex : byte, duration : int, ...
+resume() : void
+vehicleControlReference
<<Interface>>
PoolController
<<Interface>>
BasicControllerReference
<<Property>> +basicControlReference : BasicController
<<Interface>>
TracLightControllerReference
<<Property>> +tracLightControlReference : TracLightContr...
<<Interface>>
VehicleControllerReference
<<Property>> +vehicleControlReference : VehicleController
<<Interface>>
RSUControllerReference
<<Property>> +rSUControlReference : RSUController
<<Interface>>
PoolControllerReference
Figure 3.16: Contro class diagram
CAM content
The following section will show how CAMs are implemented in VSimRTI and how you can alter them.
CAMs consist of four parts:
Header with generic information
MessageBody
ServiceList
TaggedValue list
34
3 Simulators
First of all generic information like protocol version, creation time stamp are transmitted. Normally
this data set follows a network beacon, already containing data like position and speed. Nevertheless
this functionality must be implemented in the network layer, that means in the network simulator. At
the moment this is not supported and is therefore compensated in the next message part, the message
body.
The body can contain either RSU or Vehicle awareness data. In the first case, only the RSU type is
submitted, but this probably changes with a new CAM specification. In the second case, we provide data
like vehicle width, length, position, speed, type and heading. However, the specification is not completely
implemented, especially acceleration data, as well as light and brake status are missing. The third part of
the CAM specification, the service list, is also not implemented. This will probably change, when a list of
services is defined by the ETSI.
Last but not least a message can contain optional data. This is fully implemented and is used for our
traffic light CAM messages, which provide the traffic light status.
The CAM sending interval can be configured, more information can be found in the configuration section
of the application simulator.
User defined tagged values
You can also send an arbitrary byte field. In this way every byte sent via CAM can be controlled,
nevertheless this is often connected with some serious work.
You may also want to safely serialize / deserialize objects.
If the control of every byte is not needed, the DefaultObjectSerialization can be used. This class converts
an object into a byte field and vice versa.
The main advantage of this approach is the easy way to handle the marshalling: it is all already done. So
the developer can focus on the main facts.
After the user defined tagged value was added, it will be sent with the next CAM. For more information
have a closer look at the example applications.
Create a "Hello world" application using eclipse
Create a new project in eclipse (File New Java Project). Name your application HelloWorldApp
and select JavaSE-1.7 as the JRE version. Confirm the creation of the project. Right click on the project
and choose "Properties" to open the project specific configuration options. In the dialog window select
"Java Build Path" and click on the Libraries tab. Choose "Add external JARs" and navigate to your
VSimRTI installation folder. Choose the following JAR and add it to your project:
vsimrti/bin/fed/application/application-federate-x.x.x-shaded.jar
Right click on the "Hello world" Project and choose (New Package). Name the package something
like com.mycompany.vsimrti.applications.HelloWorldApp . Right click on the package and chose
(New Class). Name the class HelloWorldApp, add the interface
35
3 Simulators
com.dcaiti.vsimrti.fed.app.api.interfaces.Application
and confirm.
Figure 3.17: HelloWorldApp
You can now continue and make modifications. To deploy the application you have to export the project
(File Export Java/Jar File) and put the JAR in the folder
vsimrti/scenarios/<scenarioName>/application/applications/vehicle
.
Notice: You can download the example Application "HelloWorldApp" from the website.
36
3 Simulators
Applications that access SUMO TraCI
If SUMO is used as a traffic simulator and a special functionality is required,
the
sendSumoTraciByteArrayMessage function in the VehicleControl can be used.

The function expects a string (a unique identifier which will be assigned to the response) and a byte array
(representing the complete Traffic Control Interface (TraCI) request including the header). The message
identifier can be an empty string, but must be not null.
In many cases the command will trigger a response.
it
implements
the
The application can receive it if
SumoTraciByteArrayMessageApplication interface.
receiveSumoTraciByteArrayMessageResponse()
must be implemented.
The
function
This function will
receive a SumoTraciByteArrayMessageResponse object. This response contains the specified

identifier. The application must handle the identification process of the response itself.
Notice: A response is only delivered to the vehicle which issued the request, but to every
application which implements the SumoTraciByteArrayMessageResponse interface. To
prevent unintentional delivery each application should use an immutable universally unique
identifier (UUID).
Important:
Be careful when using this interface and the TraCI commands. The
commands are delivered to TraCI without any prior checks.
An example use case: Get the speed from a specific vehicle
This is a short introduction to the deployed application TestSumoTraciByteArrayMessageApp. You should

have a look at the source files for a better understanding.
3.10.6 FacilityTimerInterceptors
The application simulator has an interface to intercept the timer call in the facility layer. This interface
allows a customized creation of CAM and PUM messages.
You can instantiate different and multiple interceptors at once and each of them is individually configurable. Place the application configuration in the path
.
Standard interceptors
We provide two standard packages.

com.dcaiti.vsimrti.fed.app.facilitytimerinterceptors.etsi and
com.dcaiti.vsimrti.fed.app.facilitytimerinterceptors.interval .
Both provide
an CAMGeneration ,
37
3 Simulators
an PUMGeneration ,
and an CAMandPUMGeneration class.
They all work the same, but send different messages in condition (only CAM, only PUM or both messages).
Default configuration Without explicit configuration for the ETSI or interval interceptor, a default
configuration is loaded. For the ETSI interceptor have a look at the class CMaxDelta and for the interval
interceptor have a look at the class CInterval .
Notice: For more information about this component, please have a look at the javadoc
(doxygen) documentation.
Configure an interceptor
To instantiate and configure interceptors you must specify the the desired classes in the configuration with
a fully qualified names of the desired classes. Optionally you can deliver a string and a file to configure
each interceptor separate. The delivered configuration is evaluated by the specified interceptor.
Notice: Please do not forget to quote a string with slashes (Escape String). Add backslashes before characters that need to be quoted (double quote ").
Notice: If you are using a configuration file and a string and place both ways identical
parameters with different values, the string should always have a higher priority.
Example configurations for standard interceptors

Do not want to use an interceptor This example illustrates the option to doesnt use an inter-
ceptor.
Hint: You can also delete the file. By default there will be no standard interceptor.
{
" _comment " : " We doesn t need any interceptor . " ,
" f a c i l i t y T i m e r I n t e r c e p t o r s " : null
}
Listing 3.6: applications_config.json
Overwrite the ETSI parameter This example illustrates the option to overwrite the ETSI parame-
ter via file. An additional file (called ETSIParameter.json in this example) is required. If you are using a
relative file reference, place the additional file in the path
vsimrti/scenarios/<scenarioName>/application/applications
.
38
3 Simulators
{
" facilityTimerInterceptors " : {
" interceptors " : [
{
" className " : " com . dcaiti . vsimrti . fed . app . f a c i l i t y t i m e r i n t e r c e p t o r s . etsi .
CAMandPUMGeneration ",
" c o n f i g u r a t i o n F i l e " : " ETSIParameter . json "
}
]
}
}
{
" minInterval " : 100000000 ,
" maxInterval " : 1000000000 ,
" position Chang e " : 5.0 ,
" headingChange " : 4.0 ,
" velocity Chang e " : 1.0
}
Listing 3.8: ETSIParameter.json
This example illustrates the option to overwrite the ETSI parameter via string. No additional file is
required.
{
{
CAMandPUMGeneration ",
" c o n f i g u r a t i o n S t r i n g " : " {\" minInterval \" : 100000000 , \" maxInterval \" :
1000000000 , \" posi tionCh ange \" : 5.0 , \" headingChange \" : 4.0 , \"
vel ocityC hange \" : 1.0} "
}
]
}
}
Overwrite the interval parameter This example illustrates the option to overwrite the interval
parameter via string.

{
{
" className " : " com . dcaiti . vsimrti . fed . app . f a c i l i t y t i m e r i n t e r c e p t o r s . interval .
CAMGeneration " ,
" _comment " : " The interval has the unit ns . " ,
" c o n f i g u r a t i o n S t r i n g " : " {\" interval \" : 100000000} "
}
]
}
}
39
3 Simulators
Overwrite the interval parameter and use different types This example illustrates the
option to use different interceptors for different types.

{
{
CAMGeneration " ,
" _comment " : " This interval is only for the vehicles . The interval has the unit ns
.",
" c o n f i g u r a t i o n S t r i n g " : " {\" interval \" : 1000000000 , \" typesToEnable \" : [ \"
Vehicle \" ] } "
},
{
CAMGeneration " ,
" _comment " : " This interval is only for the traffic lights . The interval has the
unit ns . " ,
" c o n f i g u r a t i o n S t r i n g " : " {\" interval \" : 2000000000 , \" typesToEnable \" : [ \"
TrafficLight \" ] } "
},
{
CAMGeneration " ,
" _comment " : " This interval is only for the road side units . The interval has the
unit ns . " ,
" c o n f i g u r a t i o n S t r i n g " : " {\" interval \" : 4000000000 , \" typesToEnable \" : [ \" Rsu \"
] }"
}
]
}
}
Use ETSI for vehicles and interval for RSUs This example illustrates the option to use an ETSI
interceptor for vehicles and an interval interceptor for RSUs.

{
{
" _comment " : " An ETSI interceptor works only on vehicles . " ,
CAMandPUMGeneration "
},
{
CAMGeneration " ,
" _comment " : " This interval is only for the road side units . The interval has the
unit ns . " ,
" c o n f i g u r a t i o n S t r i n g " : " {\" interval \" : 4000000000 , \" typesToEnable \" : [ \" Rsu \"
] }"
}
]
}
}
40
3 Simulators
Example configurations for self-created interceptors

Different configurations for different interceptors This example illustrates the various op-
tions to configure different interceptors.

{
{
" className " : " com . example . mypackage . Interc eptOnA BC " ,
" c o n f i g u r a t i o n F i l e " : " c o n f i g u r a t i o n A B C . json "
},
{
" className " : " com . example . mypackage . Interc eptOnD EF " ,
" c o n f i g u r a t i o n S t r i n g " : " {\" sendAfterTime \" : 500 ,\" sendOnlyOnce \" : true \" abc \"
: \" def \" ,} " ,
},
{
" className " : " com . example . mypackage . Interc eptOnG HI " ,
" c o n f i g u r a t i o n S t r i n g " : " < config > < value >5 </ value > </ config > " ,
" c o n f i g u r a t i o n F i l e " : " configuration . xml "
}
]
}
}
Different formats This example shows the different ways to use different formats.
{
{
" className " : " com . example . mypackage . MyInterceptor " ,
" c o n f i g u r a t i o n S t r i n g " : " enable . me = true " ,
" c o n f i g u r a t i o n F i l e " : " configuration . properties "
}
]
}
}
Create your own interceptor
To send messages at your own conditions you have the opportunity to develop your own interceptor. An
interceptor class must implement the interface FacilityTimerInterceptor .
Visual Paradigm for UML Standard
Edition(Technische Universitaet Berlin)
<<Interface>>
FacilityTimerInterceptor
<<Property>> +>conguration : CFacilityTimerInterce...
<<Property>> <+enabled : boolean
<<Property>> +>facilityLayer : FacilityLayer
<<Interface>>
TimerCall
Figure 3.18: FacilityTimerInterceptor class diagram
41
3 Simulators
3.10.7 Remote debugging of applications

Remote debugging is a more comfortable way to debug applications in VSimRTI. It offers all common
features of integrated development environment (IDE) debugging modes including single step, variable
inspection etc.
During a simulation run the active applications are loaded to vehicles, RSUs and traffic lights as specified
in the mapping configuration. They are started by the VSimRTI application simulator in a new thread
and have to be synchronized for debugging as shown in the short instruction below. For each applicationsupported vehicle, RSU or traffic light an extra thread appears in the debug view of the IDE.
1) To use a remote debugger use the customFederateArgument in the file
See the documentation for the class
com.dcaiti.vsimrti.fed.app.configuration.CFederate.customFederateArgument .
2) Follow this steps to use the debug view for Eclipse: http://eclipse.dzone.com/articles/
how-debug-remote-java-applicat
Figure 3.19: Remote Debugging Eclipse
42
3 Simulators
3.10.8 Mapping 3
The mapping configuration is used to define how many vehicles of a specific type should drive in a
simulation. You can choose between a deterministic mapping (producing the exact same sequence
of mapped vehicles in every simulation run with regard to the given ratios at each point in time the
simulation) and a stochastic mapping (resulting in a random order of mapped vehicles).
The new mapping ambassador was built to simplify the configuration of complex scenarios. It is not as
tightly linked to the database as its predecessor and relies on JSON rather than XML for configuration.
The configuration for the Mapping3-Federate is located in
vsimrti/scenarios/<scenarioName>/mapping3/mapping_config.json
. In this file an object is described in JSON, which will at runtime be parsed using the MappingFrameworkClass.
To activate the Mapping 3 instead of the classical Mapping go into the
vsimrti_config.xml
and write mapping3! (mapping3!) rather than only mapping! (mapping!).
The Mapping-Framework-Class
The main class for the Mapping3-Configuration is the MappingFramework-Class. It is divided into six
parts: prototypes, rsus, tls, vehicles, matrixMappers and config.
In prototypes you can define models for other objects, which can later be reused in the other
sections. This makes it possible to reuse the definition of certain vehicles or the combination of multiple
applications, reducing redundancies. A new option is the applicationStartOffset: The applications
for this unit will only be started the given amount of seconds after the unit itself has been created.
Also newly added is the option to start a specific application from a jar.
Simply put the
full class name of the class to be loaded behind a colon separating it from the jar file name:
big.jar:com.dcaiti.vsimrti.app.
The rsus-section offers the possibility to define instances of RSUs. To reuse a prototype simply
specify its name in the name-property. The relevant properties, namely the applications and the
applicationStartOffset, will be filled in. You must define a position for every RSU.
In the tls-section traffic lights can be defined. The traffic lights themselves are already specified in the database of the scenario. Here applications can be mapped to them. Two different modes are
offered for that: You can map the entities to individual traffic lights by specifying the name of the traffic
light in the tlName-property. Alternatively you can define weights for the specified traffic lights, which
will then be the base for a random distribution through all traffic lights. The weights do not have to add
up to 100 or 1. Consequently all traffic lights will be mapped using the specified prototypes as soon as
43
3 Simulators
one weight differs from zero. So in case you dont want all traffic lights to have applications running on
them you have to define one traffic light without any applications and add a weight to it.
The vehicles-section is the centerpiece of the configuration. Here the departures, routes and
types of the vehicles are defined. It is divided into VehicleSpawner. These spawners are designed to
produce a traffic stream with the given traffic density (in vehicles/hour). By specifying a maximum
number of vehicles to be created you can also spawn individual vehicles. A VehicleSpawner offers the
possibility to combine multiple vehicle types. By specifying weights for the different vehicle types the
ratios between them can be defined. If no weights are defined they are assumed to be equal. Note: If at
least one vehicle type has a weight defined this does not apply! In that case all types without a defined
weight are ignored. Instead of specifying a route you can also choose two points (given in long/lat). If no
radius for the point is specified the closest point to the given position will be chosen. Otherwise a point
inside the radius will be select randomly.
It is also possible to define and use OD-Matrices. To do so add a ODMatrixMapper to the matrixMapperslist. Each MatrixMapper consists of a list of points, the vehicle-types to be used and the actual flow-values
between each of the points. It is possible to define multiple matrices. This way distinctively different
compositions of the vehicle flows can be achieved. The MatrixMapper will be called before the actual
execution of the simulation and will generate vehicle-spawners for the flow between each of the points.
Thus the MatrixMapper is just a way to save work. If you want to use the extra-option that multiple
vehicleSpawners offer you should use them.
In the config extra options are defined.
Mapping and Identifier

Every traffic object in VSimRTI has a globally unique string identifier. These identifiers are used to identify
a traffic object in VSimRTI as well as in different ambassadors. From users aspect, these identifiers will
be seen in the log files which are generated after a simulation. Therefore, it should be explained, which
identifier belongs to which traffic object.
Traffic Object
VSimRTI Internal ID
Vehicle
veh_[seqNr]
RSU
rsu_[rsuName]
Traffic Light
tl_[groupId]
Table 3.7: Mapping aspects
seqNr is the sequence number of simulated vehicles, which starts from zero.
rsuName is the element name defined by the user for the attribute RsuPosition.
groupId is the group id of the traffic light.
44
3 Simulators
Notice: For more information about this component, please have a look at the javadoc
(doxygen) documentation.
45
3 Simulators
3.11 VSimRTI navigation simulator
3.11 VSimRTI navigation simulator

The navigation ambassador is a new way to decouple traffic simulation and vehicle navigation systems.
This approach makes it possible to retrieve much more information of the current street map than
the traffic simulators SUMO or VISSIM can provide. This is achieved by using a map model based on
OpenStreetMap data, which is transformed before the simulation starts by using scenario-convert.
3.11.1 Installation
3.11.2 navigation-ambassador folder structure

vsimrti/scenarios/<scenarioName>/navigation/navigation_config.json
<scenarioName>
navigation ......................................................................
navigation_config.json ....................................................
<scenarioName>.db ...........................................................
Figure 3.20: navigation-ambassador folder structure
3.11.3 Configuration
As the navigation functionality is already included in the navigation ambassador, no federate component
exists (which otherwise needed to be deploy/started automatically or connected to VSimRTI manually).
Hence the common parameters only consist of a subset of tags.
To configure the navigation ambassador, just locate the database file to
vsimrti/scenarios/<scenarioName>/navigation/<scenarioName>.db
46
3 Simulators
3.12 Behavior Module
Traffic Simulator
DReaM 1
Traffic Simulation
Ambassador
DReaM 2
Behavior
Ambassador
Application 1
Application 2
Application Server Ambassador
VSimRTI
Conventional message for

the Traffic Simulator
New behavioral message
Figure 3.21: An FMC diagram depicting the integration of the Behavior Module into the VSimRTI-Structure

3.12.1 Introduction
The Behavior Module is a standardized way to customize the behavior of the drivers in the simulation. It
allows the scenario creator to easily introduce custom driver behavior models (Driver Reaction Model
(DReaM)) into the simulation. The Behavior Module is set up in a way to allow the DReaMs to easily
manipulate any message from an application directed to the driver and access all relevant information in
the simulation.
To achieve this the scenario has to be changed at several points:
The application has to be changed. The messages that should be intercepted have to be preceded
by a so-called Behavior Message. This message can contain additional information intended for
the driver model, the DReaM.
The configuration-files of the application simulator have be changed to activate the behavior mode.
The Behavior Module has to be activated in the VSimRTI configuration file.
A DReaM, a driver model, has to activated. This can be one of the pre-existing models or a custom
model.
These steps ensure an altered flow of messages that is depicted in diagram 3.21. Bear in mind that
for a traffic message to be processed by the Behavior Module both the Application Simulator and the
application itself have to be properly configured. The exact steps necessary are explained below.
47
3 Simulators
3.12.2 Planning
The application, which generates a warning for the driver, will create a message designated for the Traffic
Simulator. Additional data intended for the model can be bundled with this message. This could be
information such as the distance to the obstacle. More generally it is information that can not be fit into
the traffic message but that the driver model needs anyway.
This data is patched through to every model loaded. So a new model must identify relevant messages and
not be unsettled by others. From there on the model is only invoked in case of a time advance. At these
points new messages, most importantly new traffic messages, can be created. The Behavior Module will
then send them. A model can request time advances, so it will be called after self defined, guaranteed
intervals.
So one has to create or alter an application as well as create or alter a model. One needs to decide on
what data is needed in the model and compose a way to identify the relevant messages. A lot of these
points get easier when a custom data structure is created, which I will demonstrate below (3.12.4).
3.12.3 Adjusting an application

For an application, the general way to exude control over the behavior of the car is through the
VehicleControl interface. This interfaces features methods for changing the speed, changing the
lane or changing the route of a car.
Added to this interface are now a couple of new methods:
public void sendBehaviorMessage(BehaviorDataStruct data) This method sends out
the BehaviorDataStruct inside a newly created BehaviorMessage . Afterwards the message
that should be send to the Behavior Module can be sent out. For an explanation of the matching
between the two see section 3.12.5
public void slowDownBehavior(...) This method first sends out the BehaviorDataStruct
and, immediately afterwards, a slowDown-Message.
public void sendChangeLaneBehavior(...)
This method first sends out the
BehaviorDataStruct and, immediately afterwards, a ChangeLane-Message.

public void sendChangeRouteBehavior(...)
BehaviorDataStruct and, immediately afterwards, a ChangeRoute-Message.

public void sendSetMaxSpeedBehavior(...)
BehaviorDataStruct and, immediately afterwards, a SetMaxSpeed-Message.
3.12.4 Creating a custom data structure

New data structures are required to extend the BehaviorDataStruct -class, that can be seen in listing
3.15.
48
3 Simulators
package com . dcaiti . vsimrti . rti . util ;

public abstract class B e h a v i o r D a t a S t r u c t implements Comparable < BehaviorDataStruct >{
[...]
public abstract void readFr omStre am ( Da t aI n pu tS t re am in ) throws IOException ;
public abstract void writeToStream ( D a t a O u t p u t S t r e a m out ) throws IOException ;
public abstract boolean matches ( Message msg ) ;
}
Listing 3.15: BehaviorDataStruct.java
The methods are needed to transport the content of the data structure across an I/O-Stream. To create
the data object the constructor will be invoked. After that the readFromStream() method of the newly
created object will be called. The matches() method will be discussed below (it is used to match a
Message to a BehaviorDataStruct -object).

The LongDataStruct from listing 3.16 might serve as an example.
package com . dcaiti . vsimrti . rti . util ;
public class LongDa taStru ct implements B e h a v i o r D a t a S t r u c t {
[...]
private long [] data ;
public void re adFrom Stream ( D a ta I np ut S tr ea m in ) throws IOException {
long [] data = new long [ in . readInt () ];
for ( int i = 0; i < data . length ; i ++) {
data [ i ] = in . readLong () ;
}
}
public void writeToStream ( D a t a O u t p u t S t r e a m out ) throws IOException {
out . writeInt ( data . length ) ;
for ( int i = 0; i < data . length ; i ++) {
out . writeLong ( data [ i ]) ;
}
}
public long [] getData () { return data ;}
public void setData ( long [] data ) { this . data = data ;}
public boolean matches ( Message msg ) {
if ( msg instanceof SlowDown )
if ((( SlowDown ) msg ) . getVehicleId () . equals ( this . getUnitName () ) )
return true ;
return false ;
}
}
Listing 3.16: LongDataStruct.java.
The implementation of the matches() -method above only allows the LongDataStruct to be matched
to a SlowDown-Message for the same vehicle.
49
3 Simulators
3.12.5 Matching between a BehaviorDataStruct and normal

messages
Since multiple applications can post both Behavior-Messages and also normal messages and every
application is realized within an own thread the association between the two is not trivial. The BehaviorMessage has to be send first and the message second, but it can never be guaranteed that the associated
message-object is sent out right after the Behavior-Message.
To solve this problem the Application Ambassador stores all incoming Behavior-Messages in a list. When
a normal messages arrives this list is scanned for a matching Behavior-Message, which is determined by
calling the matches() -method of the stored BehaviorDataStruct . Only if this method returns true
the two messages are then put together and send out.
3.12.6 Creating a new model

Developing a custom model, a DReaM, for the Behavior Module is as easy as creating a class inheriting
the abstract class Dream , compiling the new class into a .jar-file, putting this file into the behavior-folder
of the simulation and specifying the class-name in the behavior_config.xml. The Behavior-Module will
automatically search in the files inside of the behavior-folder for the given class-name.
Every new DReaM must inherit the abstract class Dream from listing 3.17.
package com . dcaiti . vsimrti . fed . behavior . dreams ;
public abstract class Dream {
protected BehaveManager manager ;
public abstract void loadConfig ( X M L C o n f i g u r a t i o n xmlConfig , String baseKey ) ;
public abstract boolean p rocess Messag e ( Be ha v io r Me ss a ge msg )
throws I n t e r n a l F e d e r a t e E x c e p t i o n ;
public abstract void advanceTime ( long time )
throws I n t e r n a l F e d e r a t e E x c e p t i o n ;
public void setManager ( BehaveManager manager ) {
this . manager = manager ;
}
public BehaveManager getManager () {
return manager ;
}
}
Listing 3.17: Dream.java
The loadConfig() method gives the DReaMs the possibility to load some configuration data. These
configuration options can be found in the configuration file for the Behavior Module, which is
<scenario>/behavior/behavior_config.xml.
The used class XMLConfiguration is part of the Apache Commons Configuration, which is used by
VSimRTI.
50
3 Simulators
Within the tag configuration/dreams all dream elements represent a DReaM. A valid dream-element
needs a className Element with the correct class name of the dream to be loaded as content (compare
Listing 3.18).
< configuration >
< dreams >
< dream >
< className > com . dcaiti . vsimrti . fed . behavior . dreams . P u r e S l o w d o w n D r e a m </ className >
...
</ dream >
</ dreams >
</ configuration >
Listing 3.18: An exemplary config-file for the Behavior Module
Within this dream-element additional information can be stored.
The baseKey-value of the
loadConfig() method will be the path pointing to the corresponding dream-element. For example the call xmlConfig.getInt(baseKey+example, -1); will return the content of the element
configuration/dreams/dream/example, with the correct dream-element being selected.

Configuration options defined here have the clear advantage that they can be altered by the Simulation
Runner, which is the tool in VSimRTI used for running a series of simulations with the ability to alter
parameters.
After being loaded, the DReaM is kept in the list of active models by the BehaviorManager. For every
BehaviorMessage received it is then called, regardless of the other DReaMs. This bears conflict potential,
since two DReaMs can start interpreting a message and send out potentially conflicting messages. It is up
to the scenario designer to resolve these conflicts. Therefore the order in which the DReaMS are loaded is
not important.
By returning true on a processMessage() -call a DReaM signals that it will take responsibility for the
received message. Therefore, when no DReaM returns true for a given message this message is then
unpacked by the BehaviorManager and the contained traffic message is send back to VSimRTI. Ideally this
should not happen: A designer of a scenario should always select matching applications and DReaMs.
Every DReaM has a handle to the BehaveManager. Here all methods are public. The following methods
are most relevant:
public void requestAdvanceTime(long time) . This requests an time advance to the given
point in time, given in absolute nano seconds. This call is directly forwarded to VSimRTI.
The other important method is public void sendMessage(Message msg) . This method is
used for sending new messages. As with requestAdvanceTime() the call is just forwarded to
VSimRTI.
public long getTime() returns the current simulation time in nano seconds.
Finally the methods suchs as getVissimPaths() and getVehicleTypes() return the information about the current scenario that is stored by the BehaviorManager.
51
4 Visualizers
4.1 Kinds of Visualizers
VSimRTI provides several ways of data evaluation by so called visualizers. To visualize a scenario, different
visualizers can connect to a running simulation. Figure 4.1 gives a overview about the current coupled
visualizers. More than one visualizer of the same type can be defined.
vsimrti
eWorld ...................................................................... (see 4.2)
VSimRTI file visualizer .................................................. (see 4.3)
VSimRTI web visualizer (VSim) ........................................... (see 4.4)
user defined visualizer ..........................................................
Figure 4.1: VSimRTI visualizer structure
The visualization ambassador provides several ways to visualize and/or trace the activities that happen
during the simulation. The here explained visualization federate is responsible for providing data (in
form of subscribed messages) to the visualization component. The kind of visualization is completely
dependent on the component itself.
The VSimRTI file visualizer aims to collect and format data for further processing after simulation.
Furthermore it is possible to visualize the results in eWorld while running a simulation with the eWorld
VSimRTI visualizer plugin. To get an instant impression of a simulation, the WebSocket visualizer shows
vehicle movements on a Google Map.
Currently we are working on the so called ASCT Visualizer, which will be only available in the commercial
version of VSimRTI .
The visualizers are integrated into the simulation with a visualization ambassador.
4 Visualizers
4.2 eWorld
4.2 eWorld
We already gave an overview about the eWorld simulator (see section 3.8).
The eWorld visualizer is configured under the visualization federate.
To enable the eWorld visualizer you need to enable and configure it.
4.2.1 eWorld VSimRTI visualizer plugin
Figure 4.2: VSimRTI Visualizer Plug-in
This section introduces the VSimRTI Visualizer Plug-in (see figure 4.2), that allows on-the-fly visualization of VSimRTI simulations, thus making it a lot easier to trace the vehicle trajectories and network
activities. The plug-in simplifies the creation of scenarios and potential problems can be recognized at an
early stage without the need to run a whole simulation. To achieve this, the visualization ambassador
provides eWorld with real-time data during a simulation run.
eWorld
eWorld is an open source framework, vitally supported by the VSimRTI project team, that allows the
enrichment of mapping data with additional information, such as environmental events like traffic jams
or icy areas, and provides this enhanced data to other applications, e.g. traffic simulators. eWorld can be
downloaded on its SourceForge project website
http://eworld.sourceforge.net
or directly on the VSimRTI release website
https://www.dcaiti.tu-berlin.de/research/simulation/vsimrti
For further information about eWorld, please consider the eWorld User Manual
53
4 Visualizers
4.2 eWorld
http://downloads.sourceforge.net/eworld/eWorld-user-0.9.4.pdf
Quick start guide
1. In order to start a simulation with the VSimRTI Visualizer Plug-in embedded, the visualization
ambassador must be informed to enable the output of eWorld visualization commands. To do this,
open the file ./visualizer/visualizer_config.xml in your scenario folder.
Link here to configuration from 2.9.2 eWorld visualizer.

To activate eWorld visualization, the option enabled must be set to true. eWorld uses port 50500
by default. The default setting for synchronized is true. When sychronization is turned off, it
might occur that simulation steps are left out in the visualization.
If your scenario contains Roadside Units and/or Traffic Lights, the VSimRTI visualization ambassador has to be informed to add support for Roadside Units (line 6-7) and/or Traffic Lights (line
8-9).
2. After you have configured the scenario, start eWorld by using the eWorld.bat in the eWorld home
folder.
3. Import a local map by clicking Import Import from OSM file... in the menu or import an
arbitrary section on the online map by clicking Import Import from OSM online... in the menu.
Important: Before starting the visualization, please verify the map loaded in
eWorld covers the coordinates that will be used in the simulation (vehicle movements).
4. Make sure the plug-in is activated (View VSimRTI Visualizer).
5. At the bottom dock, activate the VSimRTI Control widget by clicking on its tab. Make sure the
port, that eWorld listens for incoming connections, equals the port you have set in your scenario
configuration before (to do this, click the Configure button).
6. Click on the Play button to start listening for incoming connections.
7. Start VSimRTI with -w 0.
VSimRTI Control widget
Figure 4.3: VSimRTI Control widget
The VSimRTI Control widget provides several control buttons, that take effect on the progress of the
visualization. To start a visualization, click the Play button to start listening for incoming connections or
click the Import button to load a visualization from a saved file (.evz). When the Stop button is clicked,
the visualization is stopped and the VSimRTI Control widget is reset. The VSimRTI Control widget has
two operating modes:
54
4 Visualizers
4.2 eWorld
Important: To initially activate the VSimRTI Control widget, a map must be loaded in
eWorld (Import Import from OSM file... or Import Import from OSM online...).
Listener mode The listener mode is activated by clicking the Play button (without importing a visu-
alization before). When in listener mode, eWorld waits for an incoming connection and then starts
the visualization. After a visualization is finished successfully , the buffer mode is automatically
activated (if buffering was activated). A running simulation can be paused by clicking the Pause
button and proceeded by clicking the Play button again. When a simulation is paused, the Step
forward button is activated, that allows to move forward a single step in the simulation (which is
then paused again). In addition, the Delay spinner allows to force the plug-in to pause for the set
time between simulation steps.
Buffer mode The buffer mode is activated after a visualization is finished successfully (if buffering
was activated) or if a visualization is imported from a saved file. The buffer mode expands the
functionality of the listener mode. The timeline is enabled to show the advance in the simulation
and to skip parts of the simulation. In addition, the Step back button is activated (when paused),
that allows to move back a single step in the simulation (which is then paused again).
Important: Depending on the available computing power, it should be considered
to set an adequate delay to slow down the visualization when in buffer mode.
Control element
Description
Timeline
The timeline shows the progress of a simulation by moving a little knob on the
slider. By dragging the knob, certain parts of a simulation can be skipped. The
timeline is only activated in buffer mode. The tick marks for the timeline can
be set in the General tab of the Settings dialog (see section 4.2.1).
Configure
Step back
Opens the Settings dialog (see section 4.2.1).

If paused, the Step back button moves one step back in a paused visualization.
This setting is available in buffer mode only.
Play/Pause
The Play button starts listening for incoming connections. If a visualization

was already imported, the Play button starts reading the visualization from
the buffer. After a visualization is finished, the buffer mode is automatically
activated, enabling a replay by clicking on the Play button again. When a
simulation is running, the Play button becomes a Pause button.
Step forward
The Step forward button moves one step forward in a paused visualization.
Stop
The Stop button shuts down the visualization and removes all models from
the map. If the plug-in is not in buffer-mode, it stops listening for incoming
connections.
Delay
The Delay spinner Sets a delay between the simulation steps in deciseconds
(s 101 ). The delay can be set in the interval from 0 s to 10 s.
Default: 0 s 101
Import
Imports a saved visualization from the file system (filetype: .evz).
55
4 Visualizers
4.2 eWorld
Control element
Description
Export
Saves a visualization to the file system (filetype: .evz). This option is only
available after the simulation is finished.
Table 4.1: VSimRTI Control widget: Control elements
VSimRTI Monitor widget
Figure 4.4: VSimRTI Monitor widget
The VSimRTI Monitor widget provides characteristics and also several options to manipulate the visualization of all models currently in the simulation in tabular form at the bottom panel. The VSimRTI
Monitor is dynamically updated for every single simulation step with each column displaying a certain
type of data and each row allocating the data to a certain model in the simulation. Changes made in
columns, that sets an option for a model in the visualization, wont take effect until the associated model is
updated (i.e. position update, sending/receiving a message) in the simulation. All models in the VSimRTI
Monitor are sorted in descending order of their addition to the simulation.
The options in the VSimRTI Monitor can be set for every model independently, thus the preferences for
the visualization can be determined very accurately.
Important: The global options for all models currently in the simulation can be set via
the General tab in the Settings dialog (see section 4.2.1).
Column
Type
Description
ID
Text
The unique ID of the underlying model as provided by the coupled

simulation environment.
Type
Text
The type of the model (e.g. Classic Vehicle, V2X-equipped Vehicle,

Roadside Unit etc.).
Latitude
Text
The geographic horizontal position (WGS 84 decimal degrees) of the

model.
Longitude
Text
The geographic vertical position (WGS 84 decimal degrees) of the model.
Speed
Text
The speed of the model in kilometers per hour (km/h). Rounded to two
decimal places.
[km/h]
Direction
1
[ ]
Text
The direction of the model in degrees ( ) and the cardinal direction

(e.g. N (North), NE (Northeast), E (East) etc.) parenthesized. Rounded to
two decimal places.
56
4 Visualizers
4.2 eWorld
Column
Type
Description
Distance
Text
The covered distance of the model in kilometers (km). Rounded to two
decimal places.
[km]
#
Sent/Re-
Text
The number of CAM/DENM messages sent/received by the model.
Checkbox
Indicates, whether additional model information is being displayed. The
ceived
Annotation
type of information can be set individually for Vehicles, Roadside Units

and Traffic Lights in the Visualization tab of the Settings dialog (see
section 4.2.1).
Default: On
Radius2
Checkbox
Indicates, whether the circular range (as set in the column Range [m]) of
the model is being displayed.
Default: Off
Range [m]2
Number
Determines the size (radius) of the circular range in meters (m). To
Spinner
count all V2X-equipped models within the set circular range, you can
activate the option Count V2X-equipped models within radius in the
Visualzation tab of the Settings dialog (see section 4.2.1). If a new range
is set, all models adopt the set value. The range can be set between 10 m
and 10,000 m.
Default: 500 m
Destination2
Checkbox
Indicates, whether the position of the geographic destination of a sent

CAM/DENM message will be marked by an arrow on the map (geographic routing only).
Default: Off
V2X-
Checkbox
tracing2
Indicates, whether all receivers of a sender that is marked as V2X-tracing,

will be highlighted. The V2X-tracing setting is mutually exclusive (one
or none models can be selected).
Default: Off
Hide
Checkbox
Indicates, whether the model is being hidden on the map. This setting
can be helpful, when annotative text becomes hard to read, due to an
interference with other models on the map.
Default: Off
Table 4.2: Columns in the VSimRTI Monitor widget
1 Vehicles only.
2 V2X-equipped Vehicles, Roadside Units and Traffic Lights only.
57
4 Visualizers
4.2 eWorld
VSimRTI Statistics widget
Figure 4.5: VSimRTI Statistics widget
The VSimRTI Statistics widget (see figure 4.5) provides a basic statistical report of the current state of the
simulation.
Communication
Sent messages: The total amount of sent V2X messages at this stage in the simulation.
Received messages: The total amount of received V2X messages at this stage in the simulation.
Vehicles
Count (Classic Vehicles): The total amount of Classic Vehicles at this stage in the simulation.
Count (V2X-equipped Vehicles): The total amount of V2X-equipped Vehicles at this stage in
the simulation.
100
Penetration rate: The penetration rate is defined as: p = +
with: = # V2X-equipped Vehicles; = # Classic Vehicles

Roadside Units
Count: The total amount of Roadside Units at this stage in the simulation.
Traffic Lights
Count: The total amount of Traffic Lights at this stage in the simulation.
Settings dialog
To open the Settings dialog, click on the Configure button in the VSimRTI Control widget (see section
4.2.1). To show an explanation for the map icons in the visualization, click on the Legend button at the
bottom-left in the Settings dialog.
58
4 Visualizers
4.2 eWorld
General tab
Figure 4.6: Settings dialog: General tab
Setting
Description
Port
eWorld listens on the set port for incoming connections, after the Play button in
the VSimRTI Control widget is clicked. The status of the port can be retrieved by
clicking on the Test button on the right. The port VSimRTI uses for the connection
can be found in the visualizer_config.xml file of the used scenario.
Default: 50500
Enable buffering
If buffering is enabled, all data received from the VSimRTI visualization ambassador will be stored in physical memory (buffer) and the simulation can be reviewed
or exported to a file after its finished.
Default: On
Annotation1
If activated, annotations will be rendered at the top-right point of all models. The
type of annotation can be chosen for Vehicles, Roadside Units and Traffic Lights
individually in the Visualization tab (see section 4.2.1).
Default: On
Radius1
If activated, a radius will be rendered around all V2X-equipped models. The range
can be set in the Range [m] column of the VSimRTI Monitor widget (see section
4.2.1).
Default: Off
59
4 Visualizers
4.2 eWorld
Setting
Description
Destination1
If activated, the destination of all sent messages will be marked by an arrow on the
map. If no geographic coordinates are received or the destination equals the models
position (depending on the routing algorithms that are simulated), the destination
can not be observed.
Default: Off
Hide1
If activated, all models will be hidden on the map.

Default: Off
Timeline
tick
Sets the tick marks for the timeline in the VSimRTI Control widget, that is activated
when reading a simulation from the buffer or a file. The available settings for tick
marks
marks are either Percentage values or Simulation steps.

Default: Percentage values
Show
simula-
tion steps
If activated, short status notes are displayed in the status bar of the main window at
the bottom-left for all retrieved updates in the simulation. This can be very useful
when tracking down certain simulation steps.
Default: On
Table 4.3: Settings dialog: General tab
60
4 Visualizers
4.2 eWorld
Visualization tab
Figure 4.7: Settings dialog: Visualization tab
Setting
Description
Map icon size
The size of the models map icons can be chosen from the presets Small,
Medium and Large. Due to eWorlds zoom policy, this setting doesnt take
effect when a map is zoomed too close.
Default: Medium
Enable
Anti-
Minimizes graphical artifacts, that might occur when drawing the radius and
annotative boxes.
aliasing
Default: On
Vehicles:
Annota-
tion
Choose an annotation for models of the type Vehicle from the following presets:
ID, Type, Speed, Direction, Distance and # Sent/Received.
Default: ID
Vehicles: Highlight
By activating the Highlight vehicles setting, all Vehicles driving faster/slower
vehicles
the determined threshold will be marked with a speed warning map icon (see
section 4.2.1). Please note, that Vehicles driving 0.0 km/h are excluded from
the speed warning setting.
Default: Off
1 To adopt this setting and to prevent unintentional changes, the Update button on its right must be clicked (instead of the Apply
button). If new models are added to the simulation, they inherit the set value. The settings can also be made in the VSimRTI
Monitor widget (see section 4.2.1 for all models individually.)
61
4 Visualizers
4.2 eWorld
Setting
Description
Roadside Units: An-
Choose an annotation for models of the type Roadside Unit from the following
notation
presets: ID, Type and # Sent/Received.

Default: ID
Traffic Lights: Anno-
Choose an annotation for models of the type Traffic Light from the following
tation
presets: ID, Type and # Sent/Received.

Default: ID
Visibility threshold
The visibility threshold determines the duration (simulation steps), that a
(update count)
sending/receiving model will keep its state. If a new message is send/received

during that period, this message will overwrite the current state of the model
and thus will not be blocked by a message that hasnt reached the set threshold.
Default: 1
V2X-
By activating the setting Count V2X-equipped models within radius, all V2X-
models
equipped models within a defined range will be counted and painted as an
Count
equipped
within radius
annotation at the top-left point of the affected models. The range can be set in
the Range [m] column of the VSimRTI Monitor widget (see section 4.2.1).
Default: Off
Table 4.4: Settings dialog: Visualization tab
62
4 Visualizers
4.2 eWorld
Visualization
(a) Vehicles sending (geographic destination)
(b) Vehicles and Roadside Units counting V2X-equipped models within

radius
Figure 4.8: Example for visualization
The main task of the VSimRTI Visualizer Plug-in is the visualization of a simulation. That includes the
processing of:
Addition of models: Classic Vehicles, V2X-equipped Vehicles, Roadside Units and Traffic Lights
Position updates: Classic Vehicles, V2X-equipped Vehicles
Sending CAM/DENM: V2X-equipped Vehicles, Roadside Units and Traffic Lights
Receiving CAM/DENM: V2X-equipped Vehicles, Roadside Units and Traffic Lights
Removal of models: Classic Vehicles, V2X-equipped Vehicles, Roadside Units and Traffic Lights
Aside from the plain visualization of the simulation data provided by VSimRTI, the plug-in allows to
manipulate the visualization with manifold options, that can be set in the VSimRTI Monitor widget (see
section 4.2.1) and the Settings dialog (see section 4.2.1). Figure 4.8a shows Vehicles, that are sending
a message with a geographic destination. Depending on the simulation scenario, the destination of
a message will automatically be marked on the map. Figure 4.8b shows Vehicles and Roadside Units
counting potential receivers within a user set radius (the number is displayed as an annotation at the
top-left point of the model). This setting can be enabled in the Visualization tab of the Settings dialog
(see section 4.2.1).
63
4 Visualizers
4.2 eWorld
Basic states
(a) V2X-equipped Vehicles and Roadside Units
(b) Classic Vehicles and Traffic Lights
Figure 4.9: Example for basic states
VSimRTI provides three types of models in general: Vehicles (see figure 4.9a and 4.9b), Roadside Units
(see figure 4.9a) and Traffic Lights (see figure 4.9b). The V2X-enabled models (blue color) are not
sending/receiving messages in their basic states. Models that are not V2X-equipped (black color) dont
enter a V2X communication state and V2X-equipped models dont leave their basic state until they are
sending/receiving messages (see section 4.2.1). All models can enter special states (see section 4.2.1)
triggered by the user settings.
Map icon
Type
V2X-enabled
Position updates
Classic Vehicle
V2X-equipped Vehicle
Roadside Unit
Traffic Light
Table 4.5: Map icons: Basic states
64
4 Visualizers
4.2 eWorld
V2X communication states
(a) Vehicles receiving a message from a Roadside Unit
(b) Vehicles sending and receiving messages
Figure 4.10: Example for V2X communication states
V2X-equipped Vehicles, Roadside Units and Traffic Lights indicate ongoing V2X communication by
changing their map icons color. Models sending a message signalize their state with red color (see figure
4.10a and 4.10b), models receiving a message signalize their state with green color (see figure 4.10a and
4.10b),.
Map icon
Type
Sending CAM/DENM
Receiving CAM/DENM
Roadside Unit
Traffic Light
Roadside Unit
Traffic Light
Table 4.6: Map icons: V2X communication states
65
4 Visualizers
4.2 eWorld
Special states
(a) Vehicles speed warning
(b) Vehicles marked as receivers

Figure 4.11: Example for special states
The speed warning setting can be enabled in the Visualization tab of the Settings dialog (see section
4.2.1). Vehicles, that are above/below a certain speed threshold (km/h), will be marked with a general
caution symbol (see figure 4.11a).
To trace the V2X communication of a certain V2X-enabled model, enable the option V2X-tracing in the
VSimRTI Monitor widget (see section 4.2.1). Thus, all models, that are receiving messages, will be marked
on the map, if the sender is currently in V2X-tracing mode (see figure 4.11b).
Map icon
Type
Description
Classic Vehicle
Speed warning
Speed warning
Sending V2X-equipped Vehicle
Speed warning
Receiving V2X-equipped Vehicle
Speed warning
V2X-equipped model (all types)
Marked receiver, if the sender is in V2X-tracing mode
Table 4.7: Map icons: Special states
66
4 Visualizers
4.3 VsimrtiFileVisualizer
The FileVisualizer is a tool which gives you the opportunity to log specific Vsimrti message types.
4.3.1 Configuring the File Visualizer

The main configuration file is located at
vsimrti/scenarios/<scenarioName>/visualizer/visualizer_config.xml
message record
Each message record is derived from a certain message type and composed of several entries, which
are separated by Element separator. A more detailed overview about the visualizable message types
in VSimRTI is given in the next chapter Results. The configuration of the file visualizer is explained
at the example of the VehicleMovements message.
Attribute id indicates the message type, namely the class name of the message.
Message has also an attribute enabled.
The element entries defines the format and content of the finally visualized message record.
The element entries is composed of several sub-elements entry, which correspond to columns of a
message record and the sequence of the columns is the same as that of sub-elements entry.
entry
Basically, there are totally three types of entry: Just look at an example:
<? xml version = " 1.0 " encoding = " UTF -8 " ? >
< message id = " V e h i c l e M o v e m e n t s " >
< entries >
< entry >" MOVE_VEHICLE " </ entry >
< entry > TimeInSec </ entry >
< entry > Updated:Id </ entry >
< entry > U p d a t e d : A p p l i c a t i o n N r </ entry >
< entry > U p d a t e d : P o s i t i o n . Latitude </ entry >
< entry > U p d a t e d : P o s i t i o n . Longitude </ entry >
</ entries >
</ message >
Listing 4.1: Specific Configuration for message.
Constant
Every quoted entry is defined as a constant. The content inside the quotation will be directly visualized
into each corresponding message record.
Listing 4.2: An example for constant type entry.
67
4 Visualizers
Basic Method
The other two types of entry originate from the getXXX() methods of a certain object. For an entry, the
root object for method invoking is the corresponding message class, here VehicleMovements . If a null
object is returned before the last method of cascaded methods is invoked, then null will be written
to the corresponding field. If a null object is returned by iteration method, then all fields involving this
iteration method will be set null.
Iteration
< entry > Updated:Id </ entry >
Listing 4.3: An example for method type entry with iteration.
The first part of this example is Updated , which means to invoke the getUpdated method of class
VehicleMovements . Then a list of VehicleInfo objects is returned. Then ;Id remains. The semicolon is an
operator for iteration, which means for each of the VehicleInfo objects in the returned list invoking getId
method.
Cascading
< entry > Upd a t e d : P o s i t i o n . Latitude </ entry >
Listing 4.4: An example for method type entry with iteration and cascading.
In this example, there is a dot operation. It is a cascade operation. Here getPosition method of VehicleInfo
class is called and a GlobalPosition object is returned. Then we continuously invoke the getLatitude
method of this GlobalPosition object.
Extended Method
All the methods involved above are the basic methods. There are also some functionality, which we cant
extract from these existing methods. So an extended method set is offered to meet these requirements
and also as an extension point in the future.
simple extended method
< entry > TimeInSec </ entry >
Listing 4.5: An example for simple extended method type entry.
With existing methods of VehicleMovements and its super class Message , we cant get the timestamp of a
message in second. (only Message.getTime , which returns a time in ns, is available). Here, getTimeInSec is
a method extension for Message class. The extended method set will be listed later.
assisting extended method
< entry > Updated:Type </ entry >
Listing 4.6: An example for assisting extended method type entry.
68
4 Visualizers
There are also methods both in the simple and extended method set. Taking getType method of VehicleInfo
as an example. If the type of a VehicleInfo object has not been set, this method will return null. But we
can take advantage of AddedVehiclesMapping messages to get its type. Thus, an extended getType will be
invoked if VehicleInfo.getType returns null.
Iteration
Basically, the method type of entry definition supports cascaded iteration as follows:
< entry > Lis t1:Lis t2:Id </ entry >
Listing 4.7: An example for cascaded iteration.
What we havent met yet, is that, if in the definition of entries, several different iterating operations exists,
for example:
< entry > Senders:Id </ entry >
< entry > Receivers:Id </ entry >
Listing 4.8: An example for multi-level iteration.
getSenders() and getReceivers() are two different iterations. In this case, a product of Ids in both list will be
generated. The result may look like this:
sender1 , receiver1
sender1 , receiver2
sender2 , receiver1
sender2 , receiver2
Listing 4.9: Visualising result of the above listing.
Note: the longest matched prefix will be considered as the same iterating operation, which means, they
are in the same level of iteration structure.
Method Sets
Method
Type
Info
Message.getTimeInSec()
long
Message.getTimeInMS()
long
ReceiveV2Xmessage.getType()
String
SendV2Xmessage.getType()
String
VehicleInfo.getApplicationNr()
int
VehicleInfo.getType()
UnitType
@Deprecated
VehicleInfo.getTypeInOrdinal()
int
@Deprecated
Table 4.8: A list of all extended methods
69
4 Visualizers
Method
Type
VehicleMovements.getUpdated()
List<VehicleInfo>
VehicleInfo.getId()
String
VehicleInfo.getPosition()
GlobalPosition
GlobalPosition.getLatitude()
double
Message.getTime()
long
VehicleInfo.getType()
UnitType
Table 4.9: A list of some basic methods
70
4 Visualizers
4.4 VSimRTI web visualizer (VSim)
4.4 VSimRTI web visualizer (VSim)

Most of VSimRTI is directed at making the creation and execution of simulations easy and powerful. But
when an experiment is conducted the setup and the simulation itself are only the first steps.
This is were Visualizing Simulations (VSim) comes into play. VSim is a browser-based software package
directed at making the data collection, analysis and processing as easy as possible. By directly accessing
the relevant data from a database the user does not have to deal with the log-files from the simulation
runs anymore.
By combining the data from a VSimRTI-simulation with the Google-Maps API the user can instantly
visualize the data on a map, zoom in and out and get a good understanding of what actually happened in
a simulation.
When satisfied VSim also offers a variety of different diagrams, making a comparison of different vehicles
or between equipped and unequipped vehicles easy. The available diagrams include average speed,
distance, travel time and speed density, speed distribution, speed over time diagrams and many more.
VSim is available in the commercial version of VSimRTI.
Notice: This visualization method relies heavily on WebSockets. As this is a fairly new
bit of technology in the process of standardisation by the World Wide Web Consortium (W3C),
browsers have varying support for it. If you run into troubles please update your browser to
the most recent version or try out Google Chrome (or Chromium) as it currently seems to
have the best implementation of WebSockets.
71
4 Visualizers
4.5 VSimRTI WebSocket visualizer
4.5 VSimRTI WebSocket visualizer

To get an simple and instant impression of a simulation or to get an idea of how fast it runs or where a
simulation is located, the WebSocket visualizer was created.
It shows a Google Map with markers, indicating the positions of all vehicles, updated as the simulation
progresses.
To start the visualization, simply open the visualizer.html in your browser. The WebSocket Visualizer is
enabled by default.
As soon, as the simulation is running, you can see the vehicle markers moving around.
You can also start the visualization at each simulation run, using the commandline parameter -v.
72
5 Create a scenario
This chapter is intended to act as a checklist for all tasks needed to create a new scenario.
5.1 Road network data

The first step always is to prepare a road network the simulation should take place in. While in general it
is not relevant where the network data is coming from we only provide ready to go import functions for
OpenStreetMap data which is freely available and comprehensive. Also if data in the target area is not
current enough or needs to be adapted to the specific needs this can be done without problems.
In case there are ready to go scenarios for supported traffic simulators like SUMO we also try to support
that. As this heavily depends on the respective tool and their format we only support imports for the
SUMO version currently actively supported by VSimRTI. Nevertheless we cannot guarantee to support all
tool specific functions, so we really recommend using OpenStreetMap data as source.
If you already have data from other sources or want to use another data provider, additional steps might
be necessary. If you have any questions or need further support, please feel free to contact our support
team via our mailing list.
5.1.1 Using OpenStreetMap data

Preparing the data source
For this approach, simply download the *.osm file of the desired region using the openstreetmap.org
website or any other tool that supports *.osm file export (e.g. josm1 or merkaartor2 ) and save it. Be
aware that we currently do not support the binary version *.pbf or any compressed versions.
Make sure that the file only contains complete ways. This means the file should not contain ways which
reference nodes that are outside the target areas bounds. Usually this only has to be checked if the
downloaded data was manually cropped with tools like osmosis3 . Such tools usually also have an option
that will remove such ways (for osmosis this is completeWays=true).
It is best practice to not let the source file contain roads clearly not usable (like bicycle or pedestrian
ways). This is to not clutter the simulation with unnecessary data resulting in a serious slow down for
some aspects of the simulation like routing. There are several ways to filter OpenStreetMap files, the
most convenient way is included in the tool we provide to process the source file, we will get back to that
1 https://josm.openstreetmap.de/
2 http://merkaartor.be/
3 http://wiki.openstreetmap.org/wiki/Osmosis
5 Create a scenario
in a minute. If you need more control over the filter process we recommend to use osmosis or one of the
editors already mentioned.
Processing the data
VSimRTI uses a database for internal storage of map and route data. Therefore it is necessary to convert OpenStreetMap data into the VSimRTI specific database format. While converting we filter out
unnecessary information about the road network and prepare the data in a way, that allows us to provide
routing functionality and create a common base for other components in the simulation like the traffic
simulator.
To be able to do this we provide the tool scenario-convert which can be found in vsimrti/bin/tools. As
already mentioned this tool also provides a basic filtering for OpenStreetMap input. The usual command
to use in this case is:
java - jar scenario - convert - X . X . X . jar -- osm2db -i source . osm -o
In this command -o provides the default filtering which filters out every street below type tertiary.
Executing this will generate you a new file with file ending .db which will be named the same as your
*.osm file. So for the given command it would generate a source.db in the directory source.osm is
found. Additionally a second *.osm file with the suffix _cleaned will be created which is the filtered
source data actually used in the import process. With -d you can provide a custom file name for the
database alongside a path where it should be placed. If you provide a name please do so without the file
extension, the correct one will be added automatically.
Now you should have a brand new database which contains the road network. In the next step you need
to export the data in a format that can be understood by the traffic simulator to be used and still matches
the information in the database. To do so export that data from the database like this:
java - jar scenario - convert - X . X . X . jar -- db2sumo -d database . db -n
Adapt the command to the specific traffic simulator you want to use (see help output of tool on the
command line). The example execution should have created a number of sumo specific network files
(nodes, edges and connections). The addition of -n automatically executes SUMOs netconvert command
after the export to create the needed netfile. This of course expects the SUMO binaries to be in the
systems path, as VSimRTI does in general.
Now you have processed the road network to be in formats usable by VSimRTI and its connected simulators.

VSimRTI contains a navigation component which supports the usage of different routes, vehicles can be
mapped to. As we are currently overhauling the route generation mechanisms you are required to create
routes with the tools supplied by the targeted traffic simulator like duarouter4 which is part of SUMO.
Please make sure to use the network previously exported as a base for these routes.
4 http://sourceforge.net/apps/mediawiki/sumo/index.php?title=DUAROUTER
74
5 Create a scenario
5.3 VSimRTI
For the routes to be usable by VSimRTI you need to import the generated routes using scenario-convert
with a command like this:
java - jar scenario - convert - X . X . X . jar -- sumo2db -r routefile . rou . xml -d target - database
This will read the routes in the route file and save them in the supplied database file. Note that the target
database file has to be the one used to export the network in the last step. If the route file also contained
vehicle definitions these will be tried to converted into a basic mapping3 configuration file. You will need
to adapt this file later on to achieve a meaningful mapping between vehicles and applications to be used.
For more information regarding this please refer to chapter 3.10.8.
5.3 VSimRTI
Now you have everything you need to create a configuration set that VSimRTI will recognize as a scenario.
For this you need the scenario_template package you can find on our website and extract it.
As a first step rename the scenario_template folder to something custom. It is recommended to use
that name as the scenarios name and id in the following steps. Inside that folder you will find a folder
structure, that reflects the different components usually found in a simulation.
Navigation
The generated database file goes into the navigation folder. As long as you only have one database file
in this folder you dont need to do anything more. VSimRTI will recognize the file automatically.
For further info on this simulator have a look at chapter 3.11.
Traffic Simulator
The generated files for the used traffic simulator go into the folder named after that simulator e.g. sumo.
In the folder should be a configuration file that needs to be adapted, to point to the correct simulator
specific network file, e.g. *.sumo.cfg .
For further info on this type of simulators have a look at chapters 3.5 and 3.6.
Applications and mapping
Usually you want the simulated vehicles to be equipped with some kind of applications that influence the vehicles behaviour. To do that you copy the jar files of your applications to the folder
application/applications. To further configure the behaviour of the application simulator have

a look at chapter 3.10.
Having the applications in place you will have to copy your mapping file to the folder mapping3. If
you dont have one by now have a look at the configuration for the default simulations provided with
VSimRTI.
For further information on controlling the mapping see chapter 3.10.8.
75
5 Create a scenario
5.3 VSimRTI
Network simulator
There is an extensive default configuration provided in the simulators folder. Depending on the simulator
you will need to tell the simulator the geographic extend of the simulation area. You can find that
data in the traffic simulators network file, e.g. SUMOs *.net.xml contains this information in the
convBoundary attribute of the location tag. In case of SWANS these have to go into the tags dimX and
dimY. You should round up the values to the next higher thousand.
Important: Larger values for the spatial expansion of the SWANS simulation area are
also possible, but might decrease the performance of SWANS, smaller values lead to wrong
behavior and will crash the simulation.
For further information on the network simulator have a look at chapters 3.2, 3.3 and 3.4.
VSimRTI config
Having done that you are now ready to adapt the vsimrti/vsimrti_config.xml file to your needs. This
usually contains of setting the scenario id (recommended to use the scenarios folder name), adapting the
end time to cover everything you want to analyse.
An important setting is the transformation configuration, as this will control how geographic coordinates
will be converted to cartesians and back. Having a correct setting here is crucial to get correct results
that map to real world coordinates so the simulation results can be visualized in some way. The center
coordinate will be used to determine the correct UTMZone, the cartesianOffset can be determined by
having a look at the traffic simulators network file, e.g. SUMOs *.net.xml contains this information in
the netOffset attribute of the location tag.
Last but not least make sure, that the correct simulators are activated and unused deactivated in the last
section of the configuration.
To simulate a generated scenario copy the now ready scenario into the vsimrti/scenarios folder.
76
6 Run simulations
Notice: Install the required simulators for the specific scenario and have a valid license
(see section 1.3).
6.1 Run a simulation via CLI

To run a single simulation via CLI calling the VSimRTI start script with the following command line
arguments. The VSimRTI start script supports 3 arguments.
-c, - -configuration The primary VSimRTI configuration file which is scenario dependent and located in the according scenario folder. This file transitively includes other necessary configuration
files. Usually you will use the file
.
-u, - -userid The id of the VSimRTI user which was assigned with the authentication for the VSimRTI
release area. For better release control and support of VSimRTI users, a user id is needed to start a
simulation. The user id is connected to a dedicated VSimRTI license.
-w, - -watchdog-interval The interval of the internal alive check (in seconds) which is used by
VSimRTI to detect execution stalls. This parameter is not mandatory and it is also possible to turn
off the watchdog (-w 0) for debug sessions.
-o, - -loggingLevelOverride Override all specified logging-levels. This option is useful for debugging simulations. For example logging every possible event would be done with -o TRACE.
GNU/Linux
./ vsimrti . sh -c ./ scenarios / < scenario name >/ vsimrti / vsimr ti_con fig . xml -u userid
Listing 6.1: VSimRTI GNU/Linux start command.
Microsoft Windows
vsimrti . bat -c .\ scenarios \ < scenario name >\ vsimrti \ vs imrti_ confi g . xml -u userid
Listing 6.2: VSimRTI Microsoft Windows start command.
6 Run simulations
6.1 Run a simulation via CLI
6.1.1 VSimRTIEmbeddedStarter
Since VSimRTI version 0.11.0 we deliver a customizeable java start program. You can also use this program
as template to embed VSimRTI in your java application. The VSimRTIEmbeddedStarter is much more
powerful as the start scripts. E.g. the VSimRTIEmbeddedStarter search in configuration files for the given
scenario id. The embedded starter has a user friendly CLI and many options.
java - jar VsimrtiEmbeddedStarter -1.0.0. jar
usage : java - jar Vs imrtiS tarter . jar
-c , - - configuration < PATH >
Configuration path , or VSimRTI config
file . Default is " . " ( working directory ) .
-- classpaths <arg >
Class paths . Default is " . " ( working
directory ) .
-h , - - help
Print this message .
-n , - - scenario - name < NAME >
The name for searching scenario .
-p , - - process - builder
Start VSimRTI using Pro cessBu ilder .
-- pipe
Use pipe redirect ( only for
-- process - builder ) .
-- print - jar - files
Print the adding jar files .
-- print - parameter
Print the parameter before start .
-s , - - simrun
Use the VSimRTI simulation runner .
-- strict - configuration - path
The starter pass - through the
configuration path as it is .
-u , - - user < USERID >
Your user id .
-v , - - version
Print the version information and
exit .
-- verbose
Print information .
-w , - - watchdog - interval < SECONDS >
Kill VSimRTI process after n seconds .
Default is 30. 0 disables the watchdog .
Listing 6.3: VSimRTI VSimRTIEmbeddedStarter help command.
java - jar VsimrtiEmbeddedStarter -1.0.0. jar -u userid -n scenarioId

Listing 6.4: VSimRTI VSimRTIEmbeddedStarter start command.
While VSimRTI is running, it prints some information on the command line:
[user@gnulinux vsimrti]$ ./vsimrti -u userid -c scenarios/Schwanebeck/vsimrti/vsimrti_config.xml

2012-10-08 11:39:06,442 INFO c - License valid
2012-10-08 11:39:06,449 INFO FederationManagement - Federation with id= Schwanebeck is started
2012-10-08 11:39:06,451 INFO FederationManagement - join federate with id swans
2012-10-08 11:39:06,733 INFO FederationManagement - Start swans local in ./tmp/swans
2012-10-08 11:39:06,939 INFO FederationManagement - join federate with id sumo
2012-10-08 11:39:07,029 INFO FederationManagement - Start sumo local in ./tmp/sumo
2012-10-08 11:39:07,029 INFO FederationManagement - join federate with id application
2012-10-08 11:39:07,252 INFO FederationManagement - Start application local in ./tmp/application
2012-10-08 11:39:07,588 INFO FederationManagement - join federate with id navigation
2012-10-08 11:39:07,589 INFO FederationManagement - join federate with id eworld
2012-10-08 11:39:07,857 INFO FederationManagement - Start eworld local in ./tmp/eworld
eworld
2012-10-08 11:39:11,095 INFO FederationManagement - join federate with id mapping
2012-10-08 11:39:11,096 INFO FederationManagement - join federate with id visualizer
11:39:21.371 - Loading Database: 100%
2012-10-08 11:39:28,613 INFO SequentialTimeManagement - Simulating: 25000000000ns (25.0s)-62.0% (RTF:1,96, ETC:15s)
Figure 6.1: Output of VSimRTI while running
The current simulation progress is shown in the following format.

current wallclock time
78
6 Run simulations
6.2 Run a simulation set via CLI
log level
unit name
current simulation time in [ns] and [s]
progress in %
Real Time Factor (RTF)
Estimated Time to Completion (ETC)
The RTF is the ratio of simulated time to simulation duration in wallclock time, e.g. a real time factor
greater than 1 means, the simulation is running faster than real time. Both RTF and ETC are calculated
based on the performance of the last five seconds of the simulation and should only give a rough overview,
how long a simulation can take. Depending on the simulation setup, the values can differ heavily between
start and end of a simulation.
Gather results
To get results from a simulation, the combined simulators have to be properly configured or a federate
has to be integrated that generates global results. For detailed information and visualization possibilities,
e.g. the FileVisualizer for detailed simulation data or the eWorld VSimRTI Visualizer Plugin for online
visualization.

A common objective when running simulations is to assess the impact of different parameter settings for
a specific scenario on the results of the simulation. To this end, the simulation-runner is a tool to apply
different configurations to a scenario, after which a series of simulations is executed via CLI by calling the
simulation-runner start script. As a result, VSimRTI starts all simulation runs automatically according
to the defined parameters. Thus, the simulation-runner allows in a comfortable way to configure the
execution of multiple simulations, e.g. of simulation series including several simulation runs where only
a few parameters need to be changed in each simulation run. For example, a simulation series could
be defined, where the V2X penetration rate is changed in each simulation run. The simulation-runner
supports the automatic assignment of free ports for all participating federates. This means that all
federates in the
vsimrti/etc/defaults.xml
will get a free port by default. As a result, VSimRTI starts all simulation runs automatically according to
the defined parameters.
Usage
Two types of parameterizations are supported:
Simulation of a fixed set of parameters for actual research.
Adjusting VSimRTI configurations primarily for running concurrent simulations.
79
6 Run simulations
The simulation runner is started as follows:

GNU/Linux
./ simrun . sh -c / scenarios / < scenario name >/ vsimrti / simrun_config . xml -p
numberofparallelsimulations
Listing 6.5: VSimRTI simulation runner start command for GNU/Linux.
GNU/Linux
java - jar VsimrtiEmbeddedStarter -1.0.0. jar -s -u userid -- strict - configuration - path -c
scenarios / < scenario name >/ vsimrti / simrun_config . xml
Listing 6.6: VSimRTI VSimRTIEmbeddedStarter simulation runner start command for GNU/Linux.
Microsoft Windows
simrun . bat -c \ scenarios \ < scenario name >\ vsimrti \ simrun_config . xml -p
numberofparallelsimulations
Listing 6.7: VSimRTI simulation runner start command for Microsoft Windows.
Microsoft Windows
java - jar VsimrtiEmbeddedStarter -1.0.0. jar -u userid -s -- strict - configuration - path -c
scenarios \ < scenario name >\ vsimrti \ simrun_config . xml
Listing 6.8: VSimRTI VSimRTIEmbeddedStarter simulation runner start command for Microsoft Windows.
Configuration file
The configuration file
vsimrti/scenarios/<scenarioName>/vsimrti/simrun_config.xml
contains the parameterization information.
Final notes
Relative paths of the files to be modified will be expanded with the deployment directory of the
current simulation run.
The modified values will be restored at the end of simulation.
The duplication of target values to be modified will be checked between different parameters.
Use the Cleaner.py script to delete temporary created files
The json support in the simulation runner is quite basic right now and only works with primitive
values at the moment.
80
6 Run simulations
6.3 Results
6.3 Results
VSimRTI generates logfiles for each simulation run. Logs are generated for the ambassadors of each
coupled federate respectively simulator and for VSimRTI itself.
The logfiles are stored in the folder
vsimrti/logs/log-<timestamp>
. For each simulation run a new folder is created.
In addition to standard logging output for each federate there is a
Statistics.csv
file which contains detailed information about sent and received VSimRTI messages. This file can be
used to trace a simulation run.
log-<timestamp>
apps ...............................................................................
application-<applicationid>.log ................ Detailed application specific logs
for each application supported vehicle, 000000 is a dummy log id.
Application.log ........................ Information about the application ambassador.

ApplicationDetails.log ...........................................................
Behavior.log ......................................................................
cell.log ...........................................................................
Communication.log ............................... Network simulation ambassador log.
CommunicationDetails.log .............. Detailed output of network simulation federate.
dreamlog.log ......................................................................
Environment.log ............................................... Traffic simulation log.
Mapping.log .............................................. Mapping configuration logs.
Navigation.log ....................................................................
Statistics.csv .................. Simulation overview in comma separated value-format.
Traffic.log .................................................... Traffic simulator logs.
visualizer.csv ....................................................................
VSimRTI.log ............ General VSimRTI information, e.g. startup sequence information.
Figure 6.2: VSimRTI log folder structure
6.3.1 Logging
The main configuration file is
. In this file, each output can be configured in great detail. This file can be adjusted to your needs, e.g.
you can set up a more detailed logging for communication components but set a less verbose output for
VSimRTI internal messages or traffic simulation depending on your simulation focus.
VSimRTI uses logback as logging framework and it is suggested to use logback for the other simulators as well. Logback offers a lot of parameters to adapt the output to your needs. Please refer to
(http://logback.qos.ch/manual/layouts.html#ClassicPatternLayout) for a detailed overview
of parameters you can use in the logback.xml file.
Please note that you can adjust the output to your needs by setting different log levels (ERROR, INFO,
DEBUG etc.) for each component in the file under
81
6 Run simulations
6.3 Results
. This might also influence the simulation performance because of a possibly high amount of data to be
logged.
Federate specific logging

Depending on the simulation purpose, further configuration possibilities for federate specific logging
may be of interest. Especially the opportunities of Application Simulator and SWANS have to be named,
since they are delivered within the VSimRTI AllInOne package.
The Application Simulator also relies on logback and its configuration file logback.xml is located directly
in the
vsimrti/bin/fed/application
folder. The WeatherWarningApp for the default scenario Schwanebeck is quite small with one package
and thus has a short configuration that contains only the root logger. More complex applications with
several packages can be comprehensively configured according to specific needs. Again, please refer to
the logback manual. Generally the pursued strategy in this logger should be to log on a certain stream
(e.g. STDOUT) and the main logger configuration redirects these logs to the dedicated files.
The logging concept of SWANS is based on log4j and the log4j.properties file is located in the
vsimrti/bin/fed/swans
folder. This file already includes a more detailed configuration for different packages i.e. different
communication layers of SWANS. Again the concept assumes logging on the console and redirection of
the stream to the file as configured in the VSimRTI main logger.
82
7.1 Overview
The location is in the area of the motorway junction Autobahndreieck Schwanebeck in the north-east of
Berlin. In the scenario an application ensures the notification of the slippery road and the broadcast of
warning messages to other vehicles. In the context of V2X applications, these event based messages are
widely known as DENM. As a result following vehicles should reduce their speed and vehicles at greater
distance try to reroute to circumnavigate the dangerous location when they receive the warning.
To simulate this V2X communication scenario the well known network simulator SWANS and the traffic
simulator SUMO are applied. For real roadmap data and environment events eWorld is used. Further
modules are included to ensure configuration of applications on specific nodes (mapping) and result
recording via so called visualizers.
Required simulators: SUMO and SWANS.
Figure 7.1: Map of Schwanebeck motorway junction
7.2 WeatherWarningApp
We provide a small example application which provide the expected behavior of the Schwanebeck
scenario which send and receive the warning. The application is simulated in the VSimRTI specific
application simulator.
7.3 Run a single simulation
7.3 Run a single simulation

To give you a first survey of VSimRTI and help to do the first steps with VSimRTI you should run a
Schwanebeck simulation.
First of all install VSimRTI as described (see section 1.2).
You need the SUMO traffic simulator. Install SUMO as as described (see section 3.5). Do not forget
to set the PATH variable as described.
Also you need SWANS. Install SWANS as described (see section 3.2).
You are now ready to run a simulation. Start your CLI, switch to the VSimRTI path and type the command
to run a single simulation (see section 6.1 sequence).
GNU/Linux
./ vsimrti . sh -c ./ scenarios / Schwanebeck / vsimrti / vsimr ti_con fig . xml -u userid
Listing 7.1: VSimRTI Schwanebeck GNU/Linux start command.
Microsoft Windows
vsimrti . bat -c .\ scenarios \ Schwanebeck \ vsimrti \ vs imrti_ config . xml -u userid
Listing 7.2: VSimRTI Schwanebeck Microsoft Windows start command.
VSimRTIEmbeddedStarter
java - jar VsimrtiEmbeddedStarter -1.0.0. jar -u userid -n Schwanebeck
Listing 7.3: VSimRTI Schwanebeck VSimRTIEmbeddedStarter start command.
84
8 Scenario Tiergarten
8.1 Overview
This scenario is located on a straight road Strasse des 17. Juni in Berlin Tiergarten. It implements no
specific V2X use case and should serve more as another basic democase where also RSU and a different
type of messages are included. The information exchange in this scenario is based on periodically sent
CAM.
Required simulators: SUMO and OMNeT++.
Figure 8.1: Map of the road Strasse des 17. Juni in Berlin Tiergarten
8.2 CamExampleApp
We provide a small example application which provide the expected behavior of the Tiergarten scenario
in which CAM messages will be sent and received.
9 Additional tools
9.1 Overview
To speed up some processes, we recommend to use some tools.
9.2 scenario-convert
scenario-convert is a tool used to work with a scenarios database by importing and exporting data from
external sources like OpenStreetMap SUMO etc.
This database is the basis for all map-related tasks, which can be performed by VSimRTI (e.g. navigation,
route calculation...).
Based on a VSimRTI database, scenario-convert can export the data to SUMO or VISSIM input formats,
which then can be used in the simulation. To enable dynamic rerouting of vehicles, scenario-convert
generates, exports and imports route data from and to SUMO. This way, one can choose, whether to use
generated routes (all possible routes between a point A and B), use existing routes and import them via
scenario-convert or build own routes via the route generation tools supplied with the standard SUMO
installation.
Workflow
An example workflow to create a valid map database would be as follows:
get OpenStreetMap file of the desired region
import OpenStreetMap file and export to SUMO using scenario-convert
create routes using existing tools or manually in sumo
import created routes back into database using scenario-convert
start simulation using the database, which now contains all relevant map data and route information
The example scenario-convert call for this workflow would be as follows in listing 1:
osmconvert -- osm2sumo -i < osmFileName > -d < dbFileName > -s < sumoPrefix > -n -- export - traffic -
lights -g -b 50.429997 ,8.6567009 -e 50.429024 ,8.6642044
Listing 9.1: Exemplary call of osmconvert.jar .
9 Additional tools
9.2 scenario-convert
(import OpenStreetMap file to database, generate routes by given coordinates, generate network with
sumo-netconvert and export to SUMO configuration files).
Usage
The following listing 2 provides an overview about the scenario-convert functions.
Usage : osmconvert [ OPTION ]*
Examples :
1. Import an osm file and write data into database
osmconvert -- osm2db -i < OSMFILE > -d < DATABASE >
2. Export db content to sumo - readable files
osmconvert -- db2sumo -d < DATABASE > [ - s < SUMOPREFIX >]
3. Reimport a sumo routefile into a database
osmconvert -- sumo2db -r < ROUTEFILE > -d < DATABASE >
4. Combine steps 1 and 2
osmconvert -- osm2sumo -i < OSMFILE > -d < DATABASE > [ - s < SUMOPREFIX >]
5. Export db content to vissim
osmconvert -- db2vissim -d < DATABASE >
CONFIGURATION OPTIONS :
-i , -- input - file FILE
-d , -- database FILE
-s , -- sumo - prefix SUMOPREFIX
-r , -- route - file FILE
-- node - file FILE
-- edge - file FILE
-- node - import - zone / lon
AUTOMATIC ROUTE GENERATION

-g , -- generate - routes
-- route - begin / end -/ lat / lon
-- route - begin / end - latlon
-- route - start - node - id /
end - node - id
-- number - of - routes INT
-- route - begin - latlon ,
-- route - end - latlon
Loads the given osm file

Saves the parsed results into given SQLite
database
Prefix for the generated sumo files
Sumo *. rou . xml file location
Sumo *. nod . xml file location
Sumo *. edg . xml file location
zone resp . longitude of location for projection
from utm to wsg84 ( mandatory for importing
nod / edg files )
Generate routes based on the given start - and
endpoints ( - - route - begin / end - lat / lon )
use numerical values for each coordinate
Use node ids ( see osm file ) for route

calculations
Optional , limit number of generated routes to
given number ( default : 100)
parses a given string containing coordinates
for each pair of values
Note : If you use the -- generate - routes flag a sumo - route file containing these
routes will be generated , too
ADDITIONAL TOOLS
-n , -- execute - netconvert
Start sumo netconvert to create netfile
automatically ( only in combination with db2sumo )
-- export - traffic - lights
use netconvert to export traffic lights
Listing 9.2: Overview about osmconvert functions.
87
10 Additional information
10.1 Overview
Additional information.
10.2 PATH configuration

PATH is an environment variable on operating systems, specifying a set of directories where executable
programs are located.
GNU/Linux
On GNU/Linux operating system you can edit you local .bash_profile in your home directory with your
favorite CLI editor e.g. Vi IMproved (VIM) or Nanos ANOther editor (NANO).
# . bash_profile
# Get the aliases and functions
if [ -f ~/. bashrc ]; then
. ~/. bashrc
fi
# User specific environment and startup programs
PATH = $PATH : $HOME / bin : $HOME / sumo /
export PATH
Listing 10.1: Add the SUMO location to PATH on GNU/Linux.
On most GNU/Linuxdistibutions you must log out and login to refresh the PATH variable. You can check
your path with the shell command echo $PATH .
10.2 PATH configuration
Microsoft Windows
For Microsoft Windows please follow the instructions below.

1. Select Computer from the start menu. Choose Properties from the context menu.
2. Click Advanced system settings and switch to the Advanced tab in System Properties.
3. Click on Environment Variables.
4. Find Path, and click on it (choose it).
5. Click Edit.
6. Modify Path by adding the absolute location to the value for Path.
(Dont forget a semicolon to seperate).
7. Click OK, click OK, click OK, . . . .
3
2
6
7
5
8
Figure 10.1: Edit PATH variable in Microsoft Windows
89
10.3 Copyright
10.3 Copyright
The figures 7.1 and 8.1 copyed from OpenStreetMap.
OpenStreetMap is open data, licensed under the Open Data Commons Open Database License
(ODbL).
You are free to copy, distribute, transmit and adapt our data, as long as you credit OpenStreetMap and
its contributors. If you alter or build upon our data, you may distribute the result only under the same
licence. The full legal code explains your rights and responsibilities.
The cartography in our map tiles, and our documentation, are licensed under the Creative Commons Attribution-ShareAlike 2.0 license (CC-BY-SA).
90
11 List of Acronyms
ASCT
Automotive Services and Communication Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
CAM
Cooperative Awareness Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
CLI
Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
CPU
central processing unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
DCAITI
Daimler Center for Automotive Information Technology Innovations . . . . . . . . . . . . . . . . . . . 2
DENM
Decentralized Environmental Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
DReaM
Driver Reaction Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
ETC
Estimated Time to Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
ETSI
European Telecommunications Standards Institute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
FOKUS
Fraunhofer-Institut fr Offene Kommunikationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
GNU
GNUs Not Unix!
GPL
GNU General Public License
HPI
Hasso-Plattner-Institut fr Softwaresystemtechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
HLA
high-level architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
IDE
integrated development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
IEEE
Institute of Electrical and Electronics Engineers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
INETMANET Internet Mobile Ad hoc Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

JAR
Java Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
JRE
Java Runtime Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
JiST
Java in Simulation Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
JSON
JavaScript Object Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
M&S
modelling and simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
MAC
Media Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
MANET
Mobile Ad hoc Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
NANO
Nanos ANOther editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
ns-3
network simulator 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
OMNeT++
OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
PUM
Position Update Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
RAM
random-access memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
RNG
Random Number Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
RSU
Road Side Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
RTF
Real Time Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
SUMO
Simulation of Urban Mobility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
SWANS
Scalable Wireless Ad hoc Network Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
TraCI
Traffic Control Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
UUID
universally unique identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
V2V
Vehicle-to-Vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11 List of Acronyms
11 List of Acronyms
V2X
Vehicle-2-X. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
VIM
Vi IMproved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
VISSIM
Verkehr In Stdten - Simulationsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
VSim
Visualizing Simulations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
VSimRTI
Vehicle-2-X Simulation Runtime Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
W3C
World Wide Web Consortium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
XML
Extensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
92
Appendix A
VSimRTI deployment
You will find a collection of all relevant data.
A.1 VSimRTI Folder Structure

The VSimRTI all-in-one package has a clear separation of binary files, general VSimRTI configuration
files and simulation scenario specific configuration files in different folders. The
vsimrti/bin
folder contains all binary files needed for execution of VSimRTI. Normally, you do not have to make
changes here.
General VSimRTI configuration files, which are used through all scenarios can be found in the
vsimrti/etc
folder.
These files contain information about how simulators interact, which remote hosts exists etc.. If you only
want to perform simulations using the preconfigured simulators in the all-in-one package you do not
need to make changes here. In the
vsimrti/scenarios
folder you can find the scenario specific configuration files, separated by component, e.g. traffic simulator
or communication simulator.
This configuration can be changed in the file
vsimrti/etc/defaults.xml
(see A.1).
For normal usage of VSimRTI, this configuration does not need to be changed. Please edit this file only, if
you know what you are doing, as unwanted side effects might occur.
The configuration of VSimRTI ambassadors is done by using configuration files in the folder
vsimrti/scenarios/<scenarioName>/<federateid>
.
To configure scenario specific VSimRTI options, e.g. to define which simulators should be active in a
simulation scenario, you can adjust the
file located in
Appendix A VSimRTI deployment
A.1 VSimRTI Folder Structure
vsimrti/scenarios/<scenarioName>/vsimrti
. The overall folder structure is as follows:
vsimrti
bin ........................................................ path containing binary files
etc .......................................... path containing general configuration files
defaults.xml ............................................................ (see A.1)
hosts.json .............................................................. (see A.2)
logback.xml ............................................................. (see A.3)
lib ................................... path containing system specific (non JAR) libraries
logs .............................................................. path for all log files
scenarios .................................. path for scenario specific configuration files
Schwanebeck ......................... path containing Schwanebeck example scenario
Tiergarten ............................. path containing Tiergarten example scenario
tmp ......................................... path for temporary files during a simulation
simrun.sh ........................................ shell script to start a simulation series
simrun.bat ...................................... batch script to start a simulation series
systeminfo.txt ............................................................. (see A.4)
vsimrti.sh ...................................... shell script to start a single simulation
vsimrti.bat ..................................... batch script to start a single simulation
vsimrti.dat ...................................................... VSimRTI license file
vsimrti-license.lcs ............................................. VSimRTI license file
Figure A.1: VSimRTI folder structure
94
A.2 File listings
A.2 File listings

etc/defaults.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
<! - - file version: 2013 -04 -13 -->
< configuration xmlns:xsi = " http: // www . w3 . org /2001/ XMLSchema - instance "
x s i : n o N a m e s p a c e S c h e m a L o c a t i o n = " http: // www . dcaiti . tu - berlin . de / research /
simulation / download / get / etc / defaults . xsd " >
< federates >
< federate class = " com . dcaiti . vsimrti . fed . swans . ambassador . S w an s Am ba s sa do r " >
< id > swans </ id >
< deploy > true </ deploy >
< start > true </ start >
< host > local </ host >
< port > 5000 </ port >
< config > swans_config . xml </ config >
< optimistic value = " false " >
< window SizeI nNS value = " -1 " / >
< s t a t e S a v e M a n a g e r type = " SIMPLE " / >
</ optimistic >
< ps eudoFe derate > </ pseudo Federa te >
< messages >
< message > AddedVehicle </ message >
< message > AddedRsu </ message >
< message > A d d e d T r a f f i c L i g h t </ message >
< message > V e h i c l e M o v e m e n t s </ message >
< message > SendV 2XMess age </ message >
< message > V e h i c l e T i l e M i g r a t i o n </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . omnetpp . ambassador . O m n e t p p A m b a s s a d o r " >
< id > omnetpp </ id >
< port > 4998 </ port >
< config > omnetpp . ini </ config >
< messages >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . ns3 . ambassador . Ns3Ambassador " >
< id > ns3 </ id >
< port > 5011 </ port >
< config > ns3_config . xml </ config >
< messages >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . sumo . ambassador . SumoA mbassa dor " >
< id > sumo </ id >
95
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
A.2 File listings

< port > 5002 </ port >
< config > sumo_config . json </ config >
< messages >
< message > V e h i c l e T y p e s I n i t M e s s a g e </ message >
< message > V e h i c l e P a t h s I n i t M e s s a g e </ message >
< message > SetMaxSpeed </ message >
< message > SlowDown </ message >
< message > C h a n g e S t a t i c R o u t e </ message >
< message > C h a n g e S t a t i c R o u t e B y E d g e </ message >
< message > ChangeLane </ message >
< message > C h a n g e T r a f f i c L i g h t s S t a t e </ message >
< message > Stop </ message >
< message > Resume </ message >
< message > S u m o T r a c i B y t e A r r a y M e s s a g e </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . app . ambassador . A p p l i c a t i o n A m b a s s a d o r " >
< id > application </ id >
< port > 5007 </ port >
< config > a p p l i c a t i o n s _ c o n f i g . json </ config >
< ps eudoFe derate >
{
" enable " : false ,
" preExecution " : [
" echo Hint use: command | tee file . ext for redirect " ,
" touch appRedirect . log " ,
" xterm "
],
" p s e u d o S t a r t C o m m a n d " : " tail -f appRedirect . log "
}
</ p seudo Federa te >
< messages >
< message > A d d e d C h a r g i n g S t a t i o n </ message >
< message > SensorData </ message >
< message > V e h i c l e N a v i g a t i o n U p d a t e </ message >
< message > R e c e i v e V 2 X M e s s a g e </ message >
< message > R e c e i v e C e l l M e s s a g e </ message >
< message > U p d a t e T r a f f i c L i g h t </ message >
< message > S u m o T r a c i B y t e A r r a y M e s s a g e R e s p o n s e C o n t a i n e r </ message >
< message > C h a n g e V e h i c l e S t a t e </ message >
< message > C h a r g i n g S t a t i o n U p d a t e </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . navi . N a v i g a t i o n A m b a s s a d o r " >
< id > navigation </ id >
< deploy > false </ deploy >
< start > false </ start >
< config > n a v i g a t i o n _ c o n f i g . json </ config >
< messages >
< message > ChangeRoute </ message >
< message > ChangeTarget </ message >
96
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
A.2 File listings
< message > R aw A dd ed V eh ic l e </ message >

</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . eworld . ambassador . E w o r l d A m b a s s a d o r " >
< id > eworld </ id >
< port > 5300 </ port >
< config > eworld_config . json </ config >
< optimistic value = " false " > </ optimistic >
< messages >
< message > S e n s o r R e g i s t r a t i o n </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . eventserver . ambassador . E v e n t s e r v e r A m b a s s a d o r " >
< id > eventserver </ id >
< config > e v e n t s e r v e r _ c o n f i g . json </ config >
< optimistic value = " false " > </ optimistic >
< messages >
< message > S e n s o r R e g i s t r a t i o n </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . mapping3 . M a p p i n g A m b a s s a d o r " >
< id > mapping3 </ id >
< config > map ping_c onfig . json </ config >
< messages >
< message > S c e n a r i o T r a f f i c L i g h t s </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . cell . ambassador . Cell Ambass ador " >
< id > cell </ id >
< windo wSizeI nNS value = " -1 " / >
</ optimistic >
< messages >
< message > S en d Ce ll M es sa g e </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . battery . ambassador . B a t t e r y A m b a s s a d o r " >
< id > battery </ id >
97
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
A.2 File listings

< config > bat tery_c onfig . xml </ config >
< windo wSizeI nNS value = " -1 " / >
</ optimistic >
< messages >
< message > C ha r gi ng S ta rt e d </ message >
< message > C ha r gi ng S to pp e d </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . c ha r gi n gs ta t io n . ambassador .
ChargingStationAmbassador ">
< id > c h ar g in gs t at io n </ id >
< config > c h a r g i n g s t a t i o n _ c o n f i g . json </ config >
< messages >
< message > ChargeRequest </ message >
< message > S t o p C h a r g e R e q u e s t </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . behavior . ambassador . B e h a v i o r A m b a s s a d o r " >
< id > behavior </ id >
< config > b e ha v io r_ c on fi g . xml </ config >
< messages >
< message > B eh a vi or M es sa g e </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . visual . V i s u a l i z a t i o n A m b a s s a d o r " >
< id > visualizer </ id >
< port > 5099 </ port >
< update >1 </ update >
< config > v i s u a l i z e r _ c o n f i g . xml </ config >
< messages >
< message > SensorData </ message >
< message > V e h i c l e N a v i g a t i o n U p d a t e </ message >
< message > R e c e i v e V 2 X M e s s a g e </ message >
< message > R e c e i v e C e l l M e s s a g e </ message >
< message > S en d Ce ll M es sa g e </ message >
98
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
A.2 File listings
< message > U p d a t e T r a f f i c L i g h t </ message >

< message > C h a r g i n g S t a t i o n U p d a t e </ message >
< message > SetMaxSpeed </ message >
< message > SlowDown </ message >
< message > ChangeRoute </ message >
< message > C h a n g e S t a t i c R o u t e </ message >
< message > ChangeLane </ message >
< message > C h a n g e T r a f f i c L i g h t s S t a t e </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . hefei . ambassador . He fe i Am ba s sa do r " >
< id > hefei </ id >
< port > 44444 </ port >
< config > hefei_config . xml </ config >
< messages >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . opendss . ambassador . O p e n D s s A m b a s s a d o r " >
< id > opendss </ id >
< port > 5113 </ port >
< config > ope ndss_c onfig . xml </ config >
< messages >
< message > D i s c h a r g i n g S t a r t e d </ message >
< message > Resume </ message >
< message > C ha r gi ng S ta rt e d </ message >
< message > C ha r gi ng S to pp e d </ message >
</ messages >
</ federate >
< federate class = " com . dcaiti . vsimrti . fed . g e n e r i c s o c k e t i n t e r a c t i o n . ambassador .
GenericSocketAmbassador ">
< id > G e n e r i c S o c k e t A m b a s s a d o r </ id >
< port > 9999 </ port >
< config > gsa . json </ config >
< ps eudoFe derate >
{
" enable " : false ,
" preExecution " : [
" touch appRedirect . log " ,
" xterm "
],
" p s e u d o S t a r t C o m m a n d " : " tail -f appRedirect . log "
}
</ pseudo Federa te >
</ federate >
</ federates >
</ configuration >
Listing A.1: VSimRTI: file listing: etc/defaults.xml
99
A.2 File listings
etc/hosts.json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
" localHosts " : [
{
" id " : " local " ,
" w o r k i n g D i r e c t o r y " : " ./ tmp " ,
" address " : " localhost " ,
" op er a ti ng S ys t em " : " linux "
}
],
" remoteHosts " : [
{
" id " : " remote " ,
" w o r k i n g D i r e c t o r y " : " / home / vsimrti / test / tmp " ,
" address " : " 192.168.0.1 " ,
" op er a ti n gS ys t em " : " linux " ,
" user " : " username " ,
" password " : " password " ,
" port " : 22
}
]
}
Listing A.2: VSimRTI: file listing: etc/hosts.json
etc/logback.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<! - - file version: 2013 -04 -05 -->
simulation / download / get / etc / logback . xsd " >
<! - - timestamp key =" timestamp " datePattern =" yyyy - MM - dd - HH:mm:ss " / -->
<! - - # # # # # # # # # # # # # # # # # # # # # # # # APPENDER # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -->
<! - - Console logger -->
< if condition = isDefined (" logDirectory ") >
< then >
< property name = " logDirectory " value = " ${ logDirectory } " / >
< appender name = " STDOUT " class = " ch . qos . logback . core . C o ns o le Ap p en de r " >
< encoder class = " ch . qos . logback . classic . encoder . P a t t e r n L a y o u t E n c o d e r " >
< pattern >% date % -5 level % logger {0} - % msg % n </ pattern >
</ encoder >
</ appender >
<! - - Logger for Time Advances -->
< appender name = " STDOUT - TimeAdvance " class = " ch . qos . logback . core . Co ns o le Ap p en de r " >
<! - - Difference to previous logger: no % n at line end ... -->
< pattern >% date { HH:mm:ss } - % msg </ pattern >
</ encoder >
</ appender >
<! - - Logger for DBloading progress -->
< appender name = " STDOUT - DbLoading " class = " ch . qos . logback . core . C on so l eA p pe nd e r " >
<! - - Difference to previous logger: no % n at line end ... -->
< pattern >% date { HH:mm:ss . SSS } - % msg </ pattern >
</ encoder >
</ appender >
<! - - Logger for plain messages -->
< appender name = " STDOUT - MessageOnly " class = " ch . qos . logback . core . Co ns o le Ap p en d er " >
< pattern >% msg % n </ pattern >
100
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
A.2 File listings
</ encoder >

</ appender >
<! - - File Appender for different components -->
< appender name = " VsimrtiLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ VSimRTI . log </ file >
</ encoder >
</ appender >
< appender name = " TrafficLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Traffic . log </ file >
</ encoder >
< append > false </ append >
</ appender >
< appender name = " C o m m u n i c a t i o n L o g " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Communication . log </ file >
</ encoder >
</ appender >
< appender name = " C o m m u n i c a t i o n D e t a i l s L o g " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ C o m m u n i c a t i o n D e t a i l s . log </ file >
< pattern >% msg % n </ pattern >
</ encoder >
</ appender >
< appender name = " Gen ericSo ckLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Gene ricSoc kLog . log </ file >
</ encoder >
</ appender >
< appender name = " App licati onLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Application . log </ file >
</ encoder >
</ appender >
< appender name = " A p p l i c a t i o n D e t a i l s L o g " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ A p p l i c a t i o n D e t a i l s . log </ file >
</ encoder >
</ appender >
< appender name = " StatisticsLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ statistics . csv </ file >
< pattern >% date % -5 level % logger {0} [% thread ] - % msg % n </ pattern >
</ encoder >
</ appender >
< appender name = " MappingLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Mapping . log </ file >
</ encoder >
</ appender >
< appender name = " BehaviorLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Behavior . log </ file >
</ encoder >
</ appender >
< logger name = " d b L o a d i n g P r o g r e s s " additivity = " false " level = " INFO " >
101
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
A.2 File listings
< appender - ref ref = " STDOUT - DbLoading " / >

</ logger >
< appender name = " NavigationLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Navigation . log </ file >
</ encoder >
</ appender >
< appender name = " Env ironme ntLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Environment . log </ file >
</ encoder >
</ appender >
< appender name = " CellLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Cell . log </ file >
</ encoder >
</ appender >
< appender name = " BatteryLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Battery . log </ file >
</ encoder >
</ appender >
< appender name = " C h a r g i n g S t a t i o n L o g " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ C h ar gi n gS t at io n . log </ file >
</ encoder >
</ appender >
< appender name = " PowerLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Power . log </ file >
< layout class = " ch . qos . logback . classic . PatternLayout " >
</ layout >
</ appender >
<! - - FileAppender for application - specific logfiles , filename will be changed
during runtime -->
< appender name = " a p p l o g F i l e A p p e n d e r " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ apps / application -000000. log </ file >
< pattern >% date - % msg % n </ pattern >
</ encoder >
</ appender >
< appender name = " EmissionLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Emissions . log </ file >
< layout class = " ch . qos . logback . classic . PatternLayout " >
</ layout >
</ appender >
<! - - # # # # # # # # # # # # # # # # # # # # # # # # LOGGER # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -->
<! - - Creating the reference between certain VSimRTI classes and logback
appenders -->
< logger name = " VSimRT IStar ter " additivity = " false " level = " INFO " >
< appender - ref ref = " VsimrtiLog " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . g e n e r i c s o c k e t i n t e r a c t i o n " additivity = " false "
level = " ALL " >
< appender - ref ref = " Ge neric SockLo g " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . sumo " additivity = " false " level = " INFO " >
< appender - ref ref = " TrafficLog " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . swans " additivity = " false " level = " INFO " >
102
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
A.2 File listings
<! - - < logger name =" com . dcaiti . vsimrti . fed . omnetpp " additivity =" false " level ="
INFO " > -->
< appender - ref ref = " C o m m u n i c a t i o n L o g " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . ns3 " additivity = " false " level = " INFO " >
< appender - ref ref = " C o m m u n i c a t i o n L o g " / >
</ logger >
<! - - NOTE: do not specify logging levels other than " INFO " use SWANS log4j .
properties
or omnetpp . ini ( OMNeT ++) for logging configuration -->
< logger name = " SwansFederate " additivity = " false " level = " INFO " >
<! - - < logger name =" O m ne tp p Fe de r at e " additivity =" false " level =" INFO " > -->
< appender - ref ref = " C o m m u n i c a t i o n D e t a i l s L o g " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . app " additivity = " false " level = " INFO " >
< appender - ref ref = " A pplica tionLo g " / >
</ logger >
< logger name = " A p p l i c a t i o n F e d e r a t e " additivity = " false " level = " ERROR " >
< appender - ref ref = " A p p l i c a t i o n D e t a i l s L o g " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . eworld " additivity = " false " level = " INFO " >
< appender - ref ref = " E nviron mentLo g " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . eventserver " additivity = " false " level = " INFO " >
< appender - ref ref = " E nviron mentLo g " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . behavior " additivity = " false " level = " INFO " >
< appender - ref ref = " BehaviorLog " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . mapping3 " additivity = " false " level = " INFO " >
< appender - ref ref = " MappingLog " / >
</ logger >
< logger name = " N a v i g a t i o n A m b a s s a d o r " additivity = " false " level = " DEBUG " >
< appender - ref ref = " NavigationLog " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . cell " additivity = " false " level = " INFO " >
< appender - ref ref = " CellLog " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . battery " additivity = " false " level = " INFO " >
< appender - ref ref = " BatteryLog " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . c ha rg i ng st a ti on " additivity = " false " level = "
TRACE " >
< appender - ref ref = " C h a r g i n g S t a t i o n L o g " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . opendss " additivity = " false " level = " INFO " >
< appender - ref ref = " PowerLog " / >
</ logger >
< logger name = " statistics " additivity = " false " level = " OFF " >
< appender - ref ref = " StatisticsLog " / >
</ logger >
<! - - Logger for application - specific logfiles NOTE: do not specify logging
levels other than " INFO " use applications logback . xml for logging
configuration -->
< logger name = " A p p l i c a t i o n L o g g e r " additivity = " false " level = " INFO " >
< appender - ref ref = " a p p l o g F i l e A p p e n d e r " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . rti . services . time " additivity = " false " level = " INFO
">
< appender - ref ref = " STDOUT - TimeAdvance " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . start " additivity = " false " level = " INFO " >
< appender - ref ref = " STDOUT - MessageOnly " / >
</ logger >
< logger name = " com . dcaiti . vsimrti . fed . hefei " additivity = " false " level = " INFO " >
< appender - ref ref = " EmissionLog " / >
</ logger >
103
231
232
233
234
235
236
237
238
239
240
241
242
A.2 File listings
< logger name = " com . dcaiti . hefei " additivity = " false " level = " INFO " >
< appender - ref ref = " EmissionLog " / >
</ logger >
<! - - All other stuff , which was not logged by other loggers before goes
to stdout and VSimRTI . log -->
< root level = " INFO " >
< appender - ref ref = " STDOUT " / >
< appender - ref ref = " VsimrtiLog " / >
</ root >
</ then >
</ if >
</ configuration >
Listing A.3: VSimRTI: file listing: etc/logback.xml
systeminfo.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
{ " userid " : " 0 " ,

" version " : " 1.0 " ,
arch " : " i686 " ,
" os " : " Linux " ,
" osversion " : " 12.04 " ,
" cpumodel " : " atom ( tm ) cpun270@1 .60 ghz " ,
" sockets " :1 ,
" cores " :2 ,
" memory " :1024 ,
" type " : " checkin " ,
" loginmd5 " : " 7 f e 5 b 9 b 9 3 0 5 c e 3 f f c d 1 8 e 3 2 b f 0 f 0 b 9 d 9 " ,
" simulatio nuuid " : " " ,
" macs " : [ " 00 : 22 :0 0 :0 0: 0 e: 0 0 " ," 00 : 00 :5 4 :0 0 :0 0: 0 0 " ]}
Listing A.4: VSimRTI: file listing: systeminfo.txt
104
Appendix B
Example scenario Schwanebeck
Appendix B Example scenario Schwanebeck
B.1 Folder Structure
B.1 Folder Structure

Schwanebeck
application .......................................................................
applications ...................................................................
rsu ..........................................................................
trafficlight ................................................................
vehicle ......................................................................
applications_config.json .............................................. (see B.1)
battery ............................................................................
battery_config.xml ..................................................... (see B.2)
cell ...............................................................................
network.json ............................................................ (see B.3)
eworld .............................................................................
eworld_config.json ..................................................... (see B.4)
schwanebeck.ewd ........................................ not listed (binary content)
schwanebeckExport.json ................................................ (see B.5)
vsimrti/scenarios/<scenarioName>/mapping3 .....................................
vsimrti/scenarios/<scenarioName>/mapping3/mapping_config.json .... (see B.6)
navigation ........................................................................
navigation_config.json ................................................ (see B.7)
readme.txt .............................................................. (see B.8)
schwanebeck.db ......................................... not listed (binary content)
sources ............................................................................
schwanebeck.osm ........................................... partially listed (see B.9)
sumo ...............................................................................
schwanebeck.edg.xml ..................................... partially listed (see B.10)
schwanebeck.net.xml ..................................... partially listed (see B.11)
schwanebeck.nod.xml ..................................... partially listed (see B.12)
schwanebeck.rou.xml ................................................... (see B.13)
schwanebeck.sumo.cfg ................................................. (see B.14)
sumo_config.json ...................................................... (see B.15)
swans ..............................................................................
swans_config.xml ...................................................... (see B.16)
visualizer ........................................................................
visualizer_config.xml ................................................ (see B.17)
vsimrti ............................................................................
vsimrti_config.xml .................................................... (see B.18)
simrun_config.xml ..................................................... (see B.19)
Figure B.1: Scenario Schwanebeck: folder structure
106
B.2 File listings
B.2 File listings

application/applications_config.json
1
2
3
4
5
6
{
" msg " : {
" min i m a l C a m L e n g t h " : 1500 ,
" m in i m a l D e n m L e n g t h " : 1500
}
}
Listing B.1: Scenario Schwanebeck: file listing: application/applications_config.json
battery/battery_config.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
< configuration >
< VehicleModel className = " com . dcaiti . vsimrti . fed . battery . sim . models . vehicle . ElectricSmart " >
< Mass > 1060 </ Mass >
< ReferenceArea > 1.95 </ ReferenceArea >
< D ra g Co e ff ic i en t > 0.375 </ D ra gC o ef f ic ie n t >
< T a n k T o W h e e l E f f i c i e n c y > 0.7 </ T a n k T o W h e e l E f f i c i e n c y >
< E l e t r i c M o t o r O p e r a t i n g V o l t a g e > 350 </ E l e t r i c M o t o r O p e r a t i n g V o l t a g e >
< C o n s u m e r O p e r a t i n g V o l t a g e > 12 </ C o n s u m e r O p e r a t i n g V o l t a g e >
< Battery className = " com . dcaiti . vsimrti . fed . battery . sim . models . battery .
VerySimpleBatteryModel ">
< NumberOfCells > 93 </ NumberOfCells >
< CellVoltage > 4.3 </ CellVoltage >
< C e l l C a p a c i t y I n A h > 50 </ C e l l C a p a c i t y I n A h >
< eff_Summer > 0.8448 </ eff_Summer >
< Re chargi ngType >2 </ Recha rgingT ype >
< StartSOC > 1.00 </ StartSOC >
< RandomizeSOC > false </ RandomizeSOC >
</ Battery >
< Consumers >
< Radio > 10 </ Radio >
< HeadLight > 100 </ HeadLight >
</ Consumers >
</ VehicleModel >
< Envir o n m e n t M o d e l className = " com . dcaiti . vsimrti . fed . battery . sim . models . environment .
DefaultEnvironment ">
< Gravity > 9.81 </ Gravity >
< FluidDensity > 1.293 </ FluidDensity >
< R o l l i n g R e s i s t a n c e C o e f f i c i e n t > 0.01 </ R o l l i n g R e s i s t a n c e C o e f f i c i e n t >
</ Envi r o n m e n t M o d e l >
</ configuration >
Listing B.2: Scenario Schwanebeck: file listing: battery/battery_config.xml
cell/cell_config.xml
1
2
3
4
5
6
7
8
9
{
" configuration " : {
" randomSeed ": -1 , /* -1 uses stochastic behaviour */
" deterministic " :true ,
" max N o d e B a n d w i d t h " :100000000 ,
" queueType " : " ENABLED " /* Default is disabled */
},
" logging " : {
" logP u ms Wi t hI n fo " :true
107
10
11
B.2 File listings
}
}
Listing B.3: Scenario Schwanebeck: file listing: cell/cell_config.xml
eworld/eworld_config.json
1
2
3
4
5
6
{
" jsonFile " : {
" name " : " s c h w a n e b e c k E x p o r t . json " ,
" path " : " . "
}
}
Listing B.4: Scenario Schwanebeck: file listing: eworld/eworld_config.json
eworld/schwanebeckExport.json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
{
" envEvents " : [
{
" eventType " : " Ice " ,
" strength " : 1 ,
" id " : 0 ,
" startTime " : 0 ,
" endTime " : 1220 ,
" location " : {
" center " : {
" latitude " : 52.62979037903763 ,
" longitude " : 13.564979189525287 ,
" altitude " : 0.0 ,
" changed " : false ,
" obs " : []
},
" circlePoint " : {
" latitude " : 52.63464414277449 ,
" longitude " : 13.564797785342535 ,
" altitude " : 0.0 ,
" obs " : []
},
" radius " : 536.9958680283227 ,
" id " : 0 ,
" edges " : [] ,
" obs " : [] ,
" CL ASS_ME TA_KEY " : " de . hpi . eworld . model . db . data . event . C i r c l e L o c a t i o n M o d e l "
},
" obs " : []
}
]
}
Listing B.5: Scenario Schwanebeck: file listing: eworld/schwanebeckExport.json
mapping3/mapping_config.json
108
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
B.2 File listings
{
" vehicles " :[
{
" targetDensity " :720 ,
" route " :0 ,
" types " :[
{
" applications " :[ " com . dcaiti . vsimrti . app . W e a t h e r W a r n i n g A p p . W e a t h e r W a r n i n g A p p " ] ,
" name " : " App " ,
" weight " :0.8
},
{
" name " : " noApp " ,
" weight " :0.2
}
]
}
]
}
Listing B.6: Scenario Schwanebeck: file listing:mapping3/mapping_config.json
navigation/navigation_config.xml
1
2
3
4
{
" a u t o m a t i c R o u t e G e n e r a t i o n " : " false " ,
" al l ow F r e e R e r o u t i n g " : " false "
}
Listing B.7: Scenario Schwanebeck: file listing: navigation/navigation_config.json
navigation/readme.txt
1
2
3
4
5
This folder contains the VSimRTI map database .

Basically , it is a SQlite database with information about the
road network , pre - calculated routes for navigation and
departure times for vehicles .
This database can be generated using the VSimRTI scenario - convert tool .
Listing B.8: Scenario Schwanebeck: file listing: navigation/readme.txt
109
B.2 File listings
sources/schwanebeck.osm
Note: This file is partially listed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<? xml version = " 1.0 " encoding = " utf -8 " ? >
<! - - file version: 2012 -10 -12 -->
< osm version = " 0.6 " generator = " Merkaartor " >
< bound box = " 52.577262 ,13.492866 ,52.681787 ,13.640298 " origin = " http: // www . openstreetmap . org / api
/0.6 " / >
< node id = " 267479090 " lat = " 52.62158822 " lon = " 13.49774950 " >
</ node >
< way id = " -30310496 " >
< nd ref = " 267479090 " / >
< nd ref = " 28830304 " / >
< tag k = " highway " v = " motorway " / >
< tag k = " int_ref " v = " E 55 " / >
< tag k = " lanes " v = " 2 " / >
< tag k = " name " v = " Berliner Ring " / >
< tag k = " note:name " v = " Der reg_name , sowie ggf . der loc_name sind dem zugehrigen
W i k i p e d i a a r t i k e l entnommen . " / >
< tag k = " oneway " v = " yes " / >
< tag k = " ref " v = " A 10 " / >
< tag k = " reg_name " v = " Berliner Ring " / >
</ way >
< node id = " 28830304 " lat = " 52.62278700 " lon = " 13.49292588 " >
</ node >
Listing B.9: Scenario Schwanebeck: file listing: sources/schwanebeck.osm
sumo/schwanebeck.edg.xml

1
2
3
4
5
< edges >

< edge id = " 24605507 _ 2 6 7 4 7 8 8 1 1 _ 2 6 7 4 7 2 6 4 6 _ 2 6 7 4 7 8 8 1 1 " from = " 267478811 " to = " 267472646 " numLanes =
" 2 " speed = " 13.89 " / >
< edge id = " 30602177 _ 6 4 6 6 0 5 9 6 _ 3 9 9 3 3 9 1 7 _ 6 4 6 6 0 5 9 6 " from = " 64660596 " to = " 618499890 " numLanes = " 1 "
speed = " 19.44 " / >
< edge id = " 30602177 _ 6 4 6 6 0 5 9 6 _ 3 9 9 3 3 9 1 7 _ 6 1 8 4 9 9 8 9 0 " from = " 618499890 " to = " 157564466 " numLanes = " 1
" speed = " 19.44 " / >
< edge id = " 30602177 _ 6 4 6 6 0 5 9 6 _ 3 9 9 3 3 9 1 7 _ 1 5 7 5 6 4 4 6 6 " from = " 157564466 " to = " 157559191 " numLanes = " 1
" speed = " 19.44 " / >
Listing B.10: Scenario Schwanebeck: file listing: sumo/schwanebeck.edg.xml
sumo/schwanebeck.net.xml

1
2
3
4
5
6
7
8
<! - - generated on 03/10/14 12 :39:31 by SUMO netconvert Version 0.19.0
<? xml version ="1.0" encoding =" UTF -8"? >
< configuration xmlns:xsi =" http: // www . w3 . org /2001/ XMLSchema - instance "
x s i : n o N a m e s p a c e S c h e m a L o c a t i o n =" http: // sumo - sim . org / xsd / n e t c o n v e r t C o n f i g u r a t i o n . xsd " >
< input >
110
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
B.2 File listings
< node - files value =" D: \ DCAITI \ VSimRTI \ Scenario Convert \ defaults \ s ch wa n eb ec k _n ew . nod . xml
"/ >
< edge - files value =" D: \ DCAITI \ VSimRTI \ Scenario Convert \ defaults \ s ch wa n eb ec k _n ew . edg . xml
"/ >
< connection - files value =" D: \ DCAITI \ VSimRTI \ Scenario Convert \ defaults \ s c hw an e be c k_ ne w .
con . xml "/ >
</ input >
< output >
< output - file value =" D: \ DCAITI \ VSimRTI \ Scenario Convert \ defaults \ s ch w an eb e ck _ ne w . net .
xml "/ >
</ output >
</ configuration >
-->
< net version = " 0.13 " xmlns:xsi = " http: // www . w3 . org /2001/ XMLSchema - instance "
x s i : n o N a m e s p a c e S c h e m a L o c a t i o n = " http: // sumo - sim . org / xsd / net_file . xsd " >
< location netOffset = " -397979.14 , -5826114.76 " convBoundary = " 0.00 ,0.00 ,9884.45 ,11727.35 "
origBoundary = " 397979.14 ,5826114.76 ,407863.59 ,5837842.11 " projParameter = " ! " / >
< edge id = ": -1166 _0 " function = " internal " >
< lane id = ": -1166 _0_0 " index = " 0 " speed = " 22.22 " length = " 0.10 " shape = " 2625.88 ,4442.58
2625.88 ,4442.58 " / >
</ edge >
< edge id = ": -8570 _0 " function = " internal " >
2626.29 ,4445.43 " / >
2625.94 ,4442.15 " / >
Listing B.11: Scenario Schwanebeck: file listing: sumo/schwanebeck.net.xml
sumo/schwanebeck.nod.xml

1
2
3
4
5
< nodes >

< node
< node
< node
< node
id = " 21508747 " x = " 401585.1058 " y = " 5832082.5701 " type = " priority " / >
Listing B.12: Scenario Schwanebeck: file listing: sumo/schwanebeck.nod.xml
sumo/schwanebeck.rou.xml
1
2
3
4
5
<? xml version = " 1.0 " ? >

<! - - Generated by VSimRTI -->
< routes >
< vType id = " default " length = " 7.5 " maxSpeed = " 50 " minGap = " 2.0 " > < carFollowing - Krauss accel = "
0.80 " decel = " 4.5 " sigma = " 0.5 " tau = " 1 " / > </ vType >
< route id = " 1 " edges = " 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 8 8 3 0 2 1 9 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 6 7 9 2 6 3 8 4
4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 6 7 9 2 6 3 8 7 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 6 0 6 3 5 2 7 7 4067968
_ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 6 7 9 2 5 6 7 7 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 1 5 0 8 7 3 9 4067968
_ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 1 5 0 8 7 5 7 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 6 7 9 2 5 3 7 6 4067968
_ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 6 0 6 3 5 6 2 9 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 6 7 9 2 5 2 5 1 4067968
_ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 5 9 9 8 2 6 2 3 0 5477467 _ 3 9 9 3 3 9 2 7 _ 3 9 9 3 3 9 1 7 _ 3 9 9 3 3 9 2 7 5477467
_ 3 9 9 3 3 9 2 7 _ 3 9 9 3 3 9 1 7 _ 2 6 7 9 2 3 7 3 1 5477467 _ 3 9 9 3 3 9 2 7 _ 3 9 9 3 3 9 1 7 _ 3 9 9 3 3 9 3 2 5477467
_ 3 9 9 3 3 9 2 7 _ 3 9 9 3 3 9 1 7 _ 2 6 7 9 2 3 7 3 3 5477467 _ 3 9 9 3 3 9 2 7 _ 3 9 9 3 3 9 1 7 _ 3 9 9 3 4 0 6 5 5477467
111
< route
</ routes >
B.2 File listings
_ 3 9 9 3 3 9 2 7 _ 3 9 9 3 3 9 1 7 _ 2 6 7 9 2 3 7 3 7 5477467 _ 3 9 9 3 3 9 2 7 _ 3 9 9 3 3 9 1 7 _ 2 6 7 9 2 3 7 3 9 5477467
_ 3 9 9 3 3 9 2 7 _ 3 9 9 3 3 9 1 7 _ 2 6 7 9 2 3 7 4 1 30602177 _ 3 9 9 3 3 9 1 7 _ 7 5 6 7 9 6 4 4 _ 3 9 9 3 3 9 1 7 30602177
_ 3 9 9 3 3 9 1 7 _ 7 5 6 7 9 6 4 4 _ 7 5 6 6 6 5 9 4 30602177 _ 3 9 9 3 3 9 1 7 _ 7 5 6 7 9 6 4 4 _ 7 6 5 6 5 7 0 1 30602177
_ 3 9 9 3 3 9 1 7 _ 7 5 6 7 9 6 4 4 _ 7 3 9 3 5 6 8 4 7 30602177 _ 3 9 9 3 3 9 1 7 _ 7 5 6 7 9 6 4 4 _ 2 1 5 0 8 7 4 8 30602177
_ 3 9 9 3 3 9 1 7 _ 7 5 6 7 9 6 4 4 _ 7 3 9 3 5 6 8 3 9 30602177 _ 3 9 9 3 3 9 1 7 _ 7 5 6 7 9 6 4 4 _ 7 5 6 7 3 0 5 7 30602177
_ 3 9 9 3 3 9 1 7 _ 7 5 6 7 9 6 4 4 _ 7 3 9 3 5 6 8 3 0 30602177 _ 3 9 9 3 3 9 1 7 _ 7 5 6 7 9 6 4 4 _ 3 0 3 1 8 4 5 1 9 30602177
_ 3 9 9 3 3 9 1 7 _ 7 5 6 7 9 6 4 4 _ 7 3 5 8 6 2 6 8 30602177 _ 3 9 9 3 3 9 1 7 _ 7 5 6 7 9 6 4 4 _ 7 6 5 9 6 5 5 1 1 24605499
_ 7 5 6 7 9 6 4 4 _ 3 3 8 3 6 0 9 8 2 _ 7 5 6 7 9 6 4 4 24605499 _ 7 5 6 7 9 6 4 4 _ 3 3 8 3 6 0 9 8 2 _ 2 1 5 0 8 7 4 7 24605499
_ 7 5 6 7 9 6 4 4 _ 3 3 8 3 6 0 9 8 2 _ 7 6 5 9 6 5 5 0 9 24605499 _ 7 5 6 7 9 6 4 4 _ 3 3 8 3 6 0 9 8 2 _ 7 3 5 8 6 2 6 4 24605499
_ 7 5 6 7 9 6 4 4 _ 3 3 8 3 6 0 9 8 2 _ 2 1 5 0 8 7 5 6 24605499 _ 7 5 6 7 9 6 4 4 _ 3 3 8 3 6 0 9 8 2 _ 7 3 5 9 2 3 4 7 24605499
_ 3 3 8 3 6 0 9 8 2 _ 7 6 5 8 2 4 8 6 _ 3 3 8 3 6 0 9 8 2 24605499 _ 3 3 8 3 6 0 9 8 2 _ 7 6 5 8 2 4 8 6 _ 6 0 1 0 5 9 3 5 2 24605499
_ 7 6 5 8 2 4 8 6 _ 2 6 7 4 7 2 6 3 5 _ 7 6 5 8 2 4 8 6 24605499 _ 7 6 5 8 2 4 8 6 _ 2 6 7 4 7 2 6 3 5 _ 2 1 5 0 8 7 5 5 24605499
_ 7 6 5 8 2 4 8 6 _ 2 6 7 4 7 2 6 3 5 _ 7 3 5 8 6 6 8 8 24605499 _ 7 6 5 8 2 4 8 6 _ 2 6 7 4 7 2 6 3 5 _ 2 1 5 0 8 7 4 6 24605499
_ 7 6 5 8 2 4 8 6 _ 2 6 7 4 7 2 6 3 5 _ 7 3 5 8 6 2 6 1 24605499 _ 7 6 5 8 2 4 8 6 _ 2 6 7 4 7 2 6 3 5 _ 7 3 5 8 6 2 6 0 24605499
_ 7 6 5 8 2 4 8 6 _ 2 6 7 4 7 2 6 3 5 _ 6 6 1 7 4 9 2 4 0 24605499 _ 7 6 5 8 2 4 8 6 _ 2 6 7 4 7 2 6 3 5 _ 4 1 6 0 6 5 9 5 9 24605499
_ 7 6 5 8 2 4 8 6 _ 2 6 7 4 7 2 6 3 5 _ 2 1 5 0 8 7 4 5 24605499 _ 7 6 5 8 2 4 8 6 _ 2 6 7 4 7 2 6 3 5 _ 6 6 1 7 4 9 2 3 7 24605499
_ 7 6 5 8 2 4 8 6 _ 2 6 7 4 7 2 6 3 5 _ 7 3 5 8 6 2 5 7 24605507 _ 2 6 7 4 7 2 6 3 5 _ 2 6 7 4 7 8 8 1 1 _ 2 6 7 4 7 2 6 3 5 24605507
_ 2 6 7 4 7 2 6 3 5 _ 2 6 7 4 7 8 8 1 1 _ 2 6 7 4 7 2 6 3 4 24605507 _ 2 6 7 4 7 2 6 3 5 _ 2 6 7 4 7 8 8 1 1 _ 2 6 7 4 7 2 6 3 3 24605507
_ 2 6 7 4 7 2 6 3 5 _ 2 6 7 4 7 8 8 1 1 _ 2 6 7 4 7 2 6 3 2 24605507 _ 2 6 7 4 7 2 6 3 5 _ 2 6 7 4 7 8 8 1 1 _ 3 3 8 7 3 1 5 3 3 24606309
_ 2 6 7 4 7 8 8 1 1 _ 2 6 7 4 7 8 7 7 8 _ 2 6 7 4 7 8 8 1 1 24606309 _ 2 6 7 4 7 8 8 1 1 _ 2 6 7 4 7 8 7 7 8 _ 2 6 7 4 7 8 8 1 0 9714317
_ 2 6 7 4 7 8 7 7 8 _ 2 7 0 3 1 1 5 1 _ 2 6 7 4 7 8 7 7 8 9714239 _ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 2 7 0 3 1 1 5 1 9714239
_ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 3 2 2 3 9714239 _ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 3 1 9 0 9714239
_ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 7 6 6 8 4 7 0 1 9714239 _ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 7 6 6 8 4 7 0 2 9714239
_ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 7 6 6 8 4 7 0 3 9714239 _ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 7 6 6 8 4 7 0 4 9714239
_ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 7 6 6 8 4 7 0 5 9714239 _ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 7 6 6 8 4 7 0 6 9714239
_ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 7 6 6 8 4 7 0 7 9714239 _ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 7 6 6 8 4 7 0 8 9714239
_ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 7 6 6 8 4 7 1 1 9714239 _ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 8 7 3 0 9714239
_ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 7 6 6 8 4 7 1 2 9714239 _ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 7 6 6 8 4 7 1 3 9714239
_ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 8 7 2 7 9714239 _ 2 7 0 3 1 1 5 1 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 8 7 2 8 9714239
_27031151_76684720_ -1166 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 7 6 6 8 4 7 2 0 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 5 8 7 9 0 7 0 6 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 6 7 4 7 8 9 6 7 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 5 9 3 2 4 3 1 7 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 5 8 7 9 0 7 0 2 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 9 6 7 1 2 1 6 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 5 8 7 9 0 6 9 9 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 6 8 4 9 3 1 5 9 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 5 8 7 9 0 6 9 5 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 9 6 7 1 2 1 7 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 5 8 7 9 0 6 9 2 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 5 9 3 2 4 3 1 1 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 6 7 4 7 9 0 0 2 25589884
_76684720_267479090_59324304 " />
id = " 0 " edges = " 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 8 8 3 0 2 1 9 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 6 7 9 2 6 3 8 4
4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 6 7 9 2 6 3 8 7 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 6 0 6 3 5 2 7 7 4067968
_ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 6 7 9 2 5 6 7 7 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 1 5 0 8 7 3 9 4067968
_ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 1 5 0 8 7 5 7 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 6 7 9 2 5 3 7 6 4067968
_ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 6 0 6 3 5 6 2 9 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 6 7 9 2 5 2 5 1 4067968
_ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 5 9 9 8 2 6 2 3 0 62710154 _ 3 9 9 3 3 9 2 7 _ 3 9 9 3 3 9 2 1 _ 3 9 9 3 3 9 2 7 62710154
_ 3 9 9 3 3 9 2 7 _ 3 9 9 3 3 9 2 1 _ 2 6 7 9 2 3 6 7 2 62710371 _ 3 9 9 3 3 9 2 1 _ 6 5 3 6 3 _ 3 9 9 3 3 9 2 1 65361
_ 6 5 3 6 3 _ 2 6 7 9 2 2 3 5 6 _ 6 5 3 6 3 -65347 _ 2 6 7 9 2 2 3 5 6 _ 2 7 8 9 4 7 2 3 8 _ 2 6 7 9 2 2 3 5 6 25589882
_ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 7 8 9 4 7 2 3 8 25589882 _ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 7 9 2 3 5 1 0 25589882
_ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 9 7 1 2 0 5 25589882 _ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 7 9 2 2 0 3 9 25589882
_ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 9 7 1 2 0 4 25589882 _ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 1 5 0 8 7 6 2 25589882
_ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 7 9 2 2 0 4 2 25589882 _ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 7 9 2 2 0 4 3 25589882
_ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 9 7 1 2 0 3 25589882 _ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 7 9 2 2 0 4 4 25589882
_ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 9 7 1 2 0 2 25589882 _ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 9 7 1 1 9 8 25589882
_ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 7 9 2 1 6 1 0 25589882 _ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 1 5 0 8 7 6 1 25589882
_ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 9 7 1 1 9 7 25589882 _ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 7 4 7 1 1 6 0 25589882
_ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 7 9 2 3 0 8 1 25589882 _ 2 7 8 9 4 7 2 3 8 _ 2 1 5 0 8 7 6 0 _ 2 6 7 9 2 1 3 6 4 62710381
_ 2 1 5 0 8 7 6 0 _ 2 6 7 4 7 1 4 1 9 _ 2 1 5 0 8 7 6 0 62710381 _ 2 1 5 0 8 7 6 0 _ 2 6 7 4 7 1 4 1 9 _ 2 1 5 0 8 7 6 3 25589884
_ 2 6 7 4 7 1 4 1 9 _ 2 1 5 0 8 7 5 2 _ 2 6 7 4 7 1 4 1 9 25589884 _ 2 6 7 4 7 1 4 1 9 _ 2 1 5 0 8 7 5 2 _ 9 6 7 1 2 1 5 25589884
_ 2 1 5 0 8 7 5 2 _ 7 6 6 8 4 7 2 0 _ 2 1 5 0 8 7 5 2 25589884 _21508752_76684720_ -8570 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 7 6 6 8 4 7 2 0 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 5 8 7 9 0 7 0 6 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 6 7 4 7 8 9 6 7 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 5 9 3 2 4 3 1 7 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 5 8 7 9 0 7 0 2 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 9 6 7 1 2 1 6 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 5 8 7 9 0 6 9 9 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 6 8 4 9 3 1 5 9 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 5 8 7 9 0 6 9 5 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 9 6 7 1 2 1 7 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 5 8 7 9 0 6 9 2 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 5 9 3 2 4 3 1 1 25589884
_ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 2 6 7 4 7 9 0 0 2 25589884 _ 7 6 6 8 4 7 2 0 _ 2 6 7 4 7 9 0 9 0 _ 5 9 3 2 4 3 0 4 " / >
Listing B.13: Scenario Schwanebeck: file listing: sumo/schwanebeck.roud.xml
112
B.2 File listings
sumo/schwanebeck.sumo.cfg
1
2
3
4
5
6
7
8
9
10
< configuration >

< input >
<net - file value = " schwanebeck . net . xml " / >
< route - files value = " schwanebeck . rou . xml " / >
</ input >
< time >
< begin value = " 0 " / >
< end value = " 10000 " / >
</ time >
</ configuration >
Listing B.14: Scenario Schwanebeck: file listing: sumo/schwanebeck.sumo.cfg
sumo/sumo_config.json
1
2
3
{
" s u m o C o n f i g u r a t i o n F i l e " : " schwanebeck . sumo . cfg "
}
Listing B.15: Scenario Schwanebeck: file listing: sumo/sumo_config.json
swans/swans_config.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<! - - file version: 2012 -11 -28 -->
simulation / download / get / scenarios / scenarioname / swans / swans_config . xsd " >
< common >
< dimX > 1200000 </ dimX >
< dimY > 2200000 </ dimY >
< random >
< generator > lcg </ generator >
< seed >0 </ seed >
< bbsP >7 </ bbsP >
< bbsQ > 37 </ bbsQ >
</ random >
< pathloss >
< model > freespace </ model >
< d0 > 1.0 </ d0 >
< d1 > 200.0 </ d1 >
< d2 > 500.0 </ d2 >
< n0 > 1.9 </ n0 >
< n1 > 3.8 </ n1 >
< n2 > 3.8 </ n2 >
</ pathloss >
< fastfading >
< model > none </ model >
< kfactor >1 </ kfactor >
</ fastfading >
< frequency > 2400000000 </ frequency >
< bandwidth > 10000000 </ bandwidth >
< temperature > 290 </ temperature >
< tempfactor > 10.0 </ tempfactor >
< ambientnoise >0 </ ambientnoise >
< routing >
< protocol > cggc </ protocol >
</ routing >
</ common >
113
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
B.2 File listings
< vehicle >

< antennaheight > 1.5 </ antennaheight >
< txpower > 15 </ txpower >
< txantennagain >0 </ txantennagain >
< rxsensitivity > -91 </ rxsensitivity >
< rxthreshold > -81 </ rxthreshold >
</ vehicle >
< rsu >
< antennaheight > 10.0 </ antennaheight >
< txpower > 15 </ txpower >
< txantennagain >0 </ txantennagain >
< rxsensitivity > -91 </ rxsensitivity >
< rxthreshold > -81 </ rxthreshold >
</ rsu >
</ configuration >
Listing B.16: Scenario Schwanebeck: file listing: swans/swans_config.xml
114
B.2 File listings
visualizer/visualizer_config.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
<! - - file version: 2013 -11 -26 -->
simulation / download / get / scenarios / scenarioname / visualizer /
v i s u a l i z e r _ c o n f i g . xsd " >
< visualizer id = " fi levisu alizer " enabled = " false " update = " 5 " loader = " com . dcaiti . vsimrti . fed .
visualizer . F i l e V i s u a l i z e r C o n f i g " >
< filename > visualizer . csv </ filename >
< directory >. </ directory >
< separator >; </ separator >
< messages >
< entries >
< entry > Time </ entry >
< entry > Updated:Name </ entry >
< entry > U p d a t e d : P o s i t i o n . Latitude </ entry >
< entry > U p d a t e d : P o s i t i o n . Longitude </ entry >
< entry > Updated:Speed </ entry >
< entry > U p d a t e d : D i r e c t i o n </ entry >
</ entries >
</ message >
< message id = " R e c e i v e V 2 X M e s s a g e " >
< entries >
< entry >" RECV_MESSAGE " </ entry >
< entry > MsgId </ entry >
< entry > NodeName </ entry >
< entry > Type </ entry >
</ entries >
</ message >
< message id = " S endV2X Messag e " >
< entries >
< entry >" SEND_MESSAGE " </ entry >
< entry > MsgId </ entry >
< entry > Source NodeNa me </ entry >
< entry > Type </ entry >
<! - - < entry > Destination . Position . Latitude </ entry > -->
<! - - < entry > Destination . Position . Longitude </ entry > -->
<! - - < entry > Destination . Radius </ entry > -->
</ entries >
</ message >
< message id = " AddedVehicle " enabled = " true " >
< entries >
< entry >" ADDED_VEHICLE " </ entry >
< entry > A p p l i c a t i o n V e h i c l e . Name </ entry >
< entry > A p p l i c a t i o n V e h i c l e . Applications </ entry >
< entry > VehicleType . Name </ entry >
</ entries >
</ message >
< message id = " A d d e d T r a f f i c L i g h t " >
< entries >
< entry >" A D D E D _ T R A F F I C L I G H T " </ entry >
< entry > A p p l i c a t i o n T r a f f i c L i g h t . Name </ entry >
< entry > A p p l i c a t i o n T r a f f i c L i g h t . Applications </ entry >
< entry > T r a f f i c L i g h t G r o u p . FirstPosition . Latitude </ entry >
< entry > T r a f f i c L i g h t G r o u p . FirstPosition . Longitude </ entry >
</ entries >
</ message >
< message id = " AddedRsu " >
< entries >
115
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
B.2 File listings
< entry >" ADDED_RSU " </ entry >

< entry > Applic ationR su . Name </ entry >
< entry > Applic ationR su . Applications </ entry >
< entry > Applic ationR su . Position . Latitude </ entry >
< entry > Applic ationR su . Position . Longitude </ entry >
</ entries >
</ message >
</ messages >
</ visualizer >
< visualizer id = " eworld " enabled = " false " loader = " com . dcaiti . vsimrti . fed . visualizer .
e w o r l d v i s u a l i z e r . config . E w o r l d V i s u a l i z e r C o n f i g " >
< synchronized > true </ synchronized >
< port > 50500 </ port >
< messages >
< message id = " A d d e d T r a f f i c L i g h t " > </ message >
< message id = " AddedRsu " > </ message >
< message id = " AddedVehicle " > </ message >
< message id = " V e h i c l e M o v e m e n t s " > </ message >
</ messages >
</ visualizer >
< visualizer id = " websocket " enabled = " true " loader = " com . dcaiti . vsimrti . fed . visualizer .
WebsocketVisualizerConfig ">
< synchronized > true </ synchronized >
< port > 46587 </ port >
< messages >
< message id = " V e h i c l e M o v e m e n t s " enabled = " true " > </ message >
< message id = " R e c e i v e V 2 X M e s s a g e " enabled = " true " > </ message >
< message id = " S endV2X Messag e " enabled = " true " > </ message >
< message id = " R e c e i v e C e l l M e s s a g e " enabled = " false " > </ message >
< message id = " Se n dC el l Me s sa ge " enabled = " false " > </ message >
< message id = " AddedRsu " enabled = " true " > </ message >
< message id = " A d d e d T r a f f i c L i g h t " enabled = " false " > </ message >
< message id = " A d d e d C h a r g i n g S t a t i o n " enabled = " false " > </ message >
< message id = " C h a r g i n g S t a t i o n U p d a t e " enabled = " false " > </ message >
</ messages >
</ visualizer >
< visualizer id = " A SCTVis ualize r " enabled = " false " loader = " com . dcaiti . vsimrti . fed . asct .
ASCTVisualizerConfig ">
< directory > I T E F V i s u a l i z e r _ L o g s </ directory >
< separator >\ , </ separator >
< drehbuchid > 4000 </ drehbuchid >
< websceconnect > false </ websceconnect >
< messages >
< entries >
< entry > Updated:Name </ entry >
< entry convertvalue = " v s i m r t i _ t i m e _ c o n v e r t e r " > Updated:Time </ entry >
< entry >" 1 0 0 4 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 " </ entry >
< entry convertvalue = " 1000000 " > U p d a t e d : P o s i t i o n . Latitude </ entry >
< entry convertvalue = " 1000000 " > U p d a t e d : P o s i t i o n . Longitude </ entry >
< entry convertvalue = " 10000 " > U p d a t e d : D i r e c t i o n </ entry >
< entry convertvalue = " 1000 " > Updated:Speed </ entry >
</ entries >
</ message >
</ messages >
</ visualizer >
</ configuration >
Listing B.17: Scenario Schwanebeck: file listing: visualizer/visualizer_config.xml
116
B.2 File listings
vsimrti/vsimrti_config.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
<! - - file version: 2013 -02 -26 -->
x s i : n o N a m e s p a c e S c h e m a L o c a t i o n = " https: // www . dcaiti . tu - berlin . de / research /
simulation / download / get / scenarios / scenarioname / vsimrti / v simrti _confi g .
xsd " >
< simulation >
< id > Schwanebeck </ id >
< starttime >0 </ starttime >
< endtime > 600 </ endtime >
< WGS84UTMTransformConfig >
{
" centerCoordinates ": {
" longitude " : 13.559532165527344 ,
" latitude " : 5 2 . 6 2 5 5 6 0 9 8 0 6 7 3 3 3 5
},
" ca r te si a nO ff s et " : {
" x " : -397979.14 ,
" y " : -5826114.76
}
}
</ W G S 8 4 U T M T r a n s f o r m C o n f i g >
< threads >1 </ threads >
</ simulation >
< federates >
<! - - Cellular simulators -->
< federate id = " cell " active = " false " / >
<! - - Electric vehicle simulators -->
< federate id = " battery " active = " false " / >
<! - - Network simulators -->
< federate id = " swans " active = " true " / >
< federate id = " omnetpp " active = " false " / >
< federate id = " ns3 " active = " false " / >
<! - - Traffic simulators -->
< federate id = " sumo " active = " true " / >
< federate id = " vissim " active = " false " / >
<! - - Application simulators -->
< federate id = " application " active = " true " / >
<! - - Environment simulators -->
< federate id = " eworld " active = " false " / >
< federate id = " eventserver " active = " true " / >
< federate id = " navigation " active = " true " / >
<! - - Mapping -->
< federate id = " mapping3 " active = " true " / >
<! - - Visualization -->
< federate id = " visualizer " active = " true " / >
<! - - Emission dispersion -->
< federate id = " hefei " active = " false " / >
</ federates >
</ configuration >
Listing B.18: Scenario Schwanebeck: file listing: vsimrti/vsimrti_config.xml
vsimrti/simrun_config.xml
1
2
3
4
5
6
7
<! - - file version: 2012 -11 -28 -->
<! - This configuration induces the execution of 6 simulations
(2 dimensions with 3 parameter for each dimension ) .
The simulations will be executed one after another ( sequential mode ) .
following simulations would be triggered:
117
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
B.2 File listings
The parameter set

( V2XVehiclePercentage , C l a s s i c V e h i c l e P e r c e n t a g e and S imulat iontim e )
nest to parameter
( txpower ) .
They define the dimensions of the simulations matrix .
===== 001. simulation =====
V 2 X V e h i c l e P e r c e n t a g e =0
C l a s s i c V e h i c l e P e r c e n t a g e =100
Simulationtime =100
TxPower =14
===== 002. simulation =====
Simulationtime =100
TxPower =15
===== 003. simulation =====
Simulationtime =100
TxPower =14
===== 004. simulation =====
Simulationtime =100
TxPower =15
===== 005. simulation =====
Simulationtime =100
TxPower =14
===== 006. simulation =====
Simulationtime =100
TxPower =15
-->
simulation / download / get / scenarios / scenarioname / vsimrti / simrun_config . xsd
"
arguments = " -c scenarios / Schwanebeck / vsimrti / vs imrti_ config . xml -u userid -w 0 "
executable = " vsimrti . sh " location = " / home / userid / vsimrti - allinone / vsimrti "
persistent = " false " >
< dimension name = " Simula tionRu ns " >
< parameter name = " endtime " file = " vsimrti / vsim rti_co nfig . xml "
fileFormat = " xml " item = " // simulation / endtime " type = " ValueList " >
< value > 100 </ value >
</ parameter >
</ dimension >
< parameter name = " TxPower " file = " swans / swans_config . xml "
fileFormat = " xml " item = " // vehicle / txpower " type = " ValueList " >
</ parameter >
</ configuration >
Listing B.19: Scenario Schwanebeck: file listing: vsimrti/simrun_config.xml
118
Appendix C
Example scenario Tiergarten
C.1 Folder Structure

Tiergarten
application .......................................................................
applications ...................................................................
rsu ..........................................................................
trafficlight ................................................................
vehicle ......................................................................
applications_config.json .............................. not listed (in this release)
vsimrti/scenarios/<scenarioName>/mapping3 .....................................
vsimrti/scenarios/<scenarioName>/mapping3/mapping_config.json .... (see B.6)
navigation ........................................................................
navigation_config.json ................................ not listed (in this release)
tiergarten.db .......................................... not listed (binary content)
omnetpp ............................................................................
omnetpp.ini ............................................................. (see C.1)
sources ............................................................................
tiergarten.osm ......................................... not listed (in this release)
sumo ...............................................................................
sumo_config.json ....................................... not listed (in this release)
tiergarten.edg.xml ..................................... not listed (in this release)
tiergarten.net.xml ..................................... not listed (in this release)
tiergarten.nod.xml ..................................... not listed (in this release)
tiergarten.rou.xml ..................................... not listed (in this release)
tiergarten.sumo.cfg .................................... not listed (in this release)
swans ..............................................................................
swans_config.xml ....................................... not listed (in this release)
visualizer ........................................................................
visualizer_config.xml ................................. not listed (in this release)
vsimrti ............................................................................
vsimrti_config.xml ..................................... not listed (in this release)
Figure C.1: Scenario Tiergarten: folder structure
Appendix C Example scenario Tiergarten
C.2 File listings
C.2 File listings

omnetpp/omnetpp.ini
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
[ General ]
network = Simulation
simtime - scale = -9
record - eventlog = false
cmdenv - express - mode = false
cmdenv - event - banners = false
# EventScheduler
scheduler - class = " V S i m R T I E v e n t S c h e d u l e r "
vsimrtieventscheduler - debug = false
# ScenarioMa na g er
*. mgmt . cmdenv - ev - output = true
*. mgmt . debug = false
*. playgrou nd Si z eX =5000
*. playgrou nd Si z eY =1000
# ChannelControl
*. channelC ontrol . pMax =100 mW
*. channelC ontrol . sat = -110 dBm
*. channelC ontrol . alpha =2
*. channelC ontrol . c a r r i e r F r e q u e n c y =5.9 GHz
# *. channelCont rol . c a r r i e r F r e q u e n c y =2.4 GHz = bg ,5.1 GHz = a ,5.9 GHz = p
*. channelC ontrol . p r o p a g a t i o n M o d e l = " FreeSp aceMod el "
# *. channelCont rol . p r o p a g a t i o n M o d e l =" P a t h L o s s R e c e p t i o n M o d e l " ," T w o R a y G r o u n d M o d e l " ," RiceModel " ,"
RayleighModel " ," NakagamiModel " ," FreeSp aceMod el " ," L o g N o r m a l S h a d o w i n g M o d e l "
# Vehiclespe ci f ic
# (1) LoggingPrints
*. veh [*].**. cmdenv - ev - output = false
# (2) MAC
*. veh [*]. wlan . mac . address = " auto "
*. veh [*]. wlan . mac . maxQueueSize =10
*. veh [*]. wlan . mac . bitrate =6 e6bps
*. veh [*]. wlan . mac . retryLimit =7
*. veh [*]. wlan . mac . cwMinData =15
*. veh [*]. wlan . mac . cw MinBro adcas t =31
*. veh [*]. wlan . mac . basicBitrate =3 e6bps
# *. veh [*]. wlan . mac . basicBitrate =3 e6 = p ,6 e6 = a
*. veh [*]. wlan . mac . opMode = " p "
# *. veh [*]. wlan . mac . opMode =1= b ,2= g ,3= a
# (3) PHYandRadio
*. veh [*]. wlan . radio . T r a n s m i s s i o n A n t e n n a G a i n I n d B =0 dB
# *. veh [*]. wlan . radio . T r a n s m i s s i o n A n t e n n a G a i n I n d B =1=0 dB
*. veh [*]. wlan . radio . R e c e i v e A n t e n n a G a i n I n d B =0 dB
# *. veh [*]. wlan . radio . R e c e i v e A n t e n n a G a i n I n d B =1=0 dB
*. veh [*]. wlan . radio . S y s t e m L o s s F a c t o r =0 dB
# *. veh [*]. wlan . radio . S y s t e m L o s s F a c t o r =1=0 dB
*. veh [*]. wlan . radio . sigma =1
*. veh [*]. wlan . radio . nak_m =1
*. veh [*]. wlan . radio . KdB =1
*. veh [*]. wlan . radio . T r a n s m i t e r A n t e n n a H i g h =2 m
*. veh [*]. wlan . radio . R e c e i v e r A n t e n n a H i g h =2 m
*. veh [*]. wlan . radio . channelNumber =0
*. veh [*]. wlan . radio . c a r r i e r F r e q u e n c y =5.9 GHz
*. veh [*]. wlan . radio . t r a n s m i t t e r P o w e r =50 mW
*. veh [*]. wlan . radio . bitrate =6 Mbps
*. veh [*]. wlan . radio . thermalNoise = -110 dBm
*. veh [*]. wlan . radio . pathLossAlpha =2
*. veh [*]. wlan . radio . snirThreshold =4 dB
120
Appendix C Example scenario Tiergarten
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
C.2 File listings
*. veh [*]. wlan . radio . sensitivity = -85 dBm

*. veh [*]. wlan . radio . systemLoss =0
*. veh [*]. wlan . radio . ht =2 m
*. veh [*]. wlan . radio . hr =2 m
*. veh [*]. wlan . radio . p a t h L o s s E x p o n e n t =2
*. veh [*]. wlan . radio . s h a d o w i n g V a r i a n c e =1
*. veh [*]. wlan . radio . s h a d o w i n g N u m b e r o f S a m p l e s =10
*. veh [*]. wlan . radio . r e c e i v e r A n t e n n a G a i n =1
*. veh [*]. wlan . radio . phyOpMode = " p "
*. veh [*]. wlan . radio . ID =0
*. veh [*]. wlan . radio . channelModel =2
*. veh [*]. wlan . radio . a t t e n u a t i o n M o d e l = " F reeSpa ceMode l "
# RSUspecific
# (1) LoggingPrints
*. rsu [*].**. cmdenv - ev - output = false
# (2) MAC
*. rsu [*]. wlan . mac . address = " auto "
*. rsu [*]. wlan . mac . maxQueueSize =10
*. rsu [*]. wlan . mac . bitrate =6 e6bps
*. rsu [*]. wlan . mac . retryLimit =7
*. rsu [*]. wlan . mac . cwMinData =15
*. rsu [*]. wlan . mac . cw MinBro adcas t =31
*. rsu [*]. wlan . mac . basicBitrate =3 e6bps
*. rsu [*]. wlan . mac . opMode = " p "
# (3) PHYandRadio
*. rsu [*]. wlan . radio . T r a n s m i s s i o n A n t e n n a G a i n I n d B =0 dB
*. rsu [*]. wlan . radio . R e c e i v e A n t e n n a G a i n I n d B =0 dB
*. rsu [*]. wlan . radio . S y s t e m L o s s F a c t o r =0 dB
*. rsu [*]. wlan . radio . sigma =1
*. rsu [*]. wlan . radio . nak_m =1
*. rsu [*]. wlan . radio . KdB =1
*. rsu [*]. wlan . radio . T r a n s m i t e r A n t e n n a H i g h =10 m
*. rsu [*]. wlan . radio . R e c e i v e r A n t e n n a H i g h =10 m
*. rsu [*]. wlan . radio . channelNumber =0
*. rsu [*]. wlan . radio . c a r r i e r F r e q u e n c y =5.9 GHz
*. rsu [*]. wlan . radio . t r a n s m i t t e r P o w e r =50 mW
*. rsu [*]. wlan . radio . bitrate =6 Mbps
*. rsu [*]. wlan . radio . thermalNoise = -110 dBm
*. rsu [*]. wlan . radio . pathLossAlpha =2
*. rsu [*]. wlan . radio . snirThreshold =4 dB
*. rsu [*]. wlan . radio . sensitivity = -85 dBm
*. rsu [*]. wlan . radio . systemLoss =0
*. rsu [*]. wlan . radio . ht =10 m
*. rsu [*]. wlan . radio . hr =10 m
*. rsu [*]. wlan . radio . p a t h L o s s E x p o n e n t =2
*. rsu [*]. wlan . radio . s h a d o w i n g V a r i a n c e =1
*. rsu [*]. wlan . radio . s h a d o w i n g N u m b e r o f S a m p l e s =10
*. rsu [*]. wlan . radio . r e c e i v e r A n t e n n a G a i n =1
*. rsu [*]. wlan . radio . phyOpMode = " p "
*. rsu [*]. wlan . radio . ID =0
*. rsu [*]. wlan . radio . channelModel =2
*. rsu [*]. wlan . radio . a t t e n u a t i o n M o d e l = " F reeSpa ceMode l "
Listing C.1: Scenario Tiergarten: file listing: omnetpp/omnetpp.ini
121

Vsimrti User Manual 0.13.1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Vsimrti User Manual 0.13.1

Загружено:

Авторское право:

Доступные форматы

VSimRTI: Vehicle-2-X Simulation

The developer alliance

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

Table 1.1: Supported Java versions

1.2 Download and install

1.2 Download and install

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

1.4.1 Federates and Ambassadors

1.4.2 Root configuration

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

2.2 Host configuration

3.1 Kinds of simulators

3.1.1 Network simulators

3.1 Kinds of simulators

3.1.2 Traffic simulators

individual vehicles that are being actuated by macroscopic control variables.

3.1.3 Cellular simulators

3.1.4 Application simulators

3.1.5 Environment simulators

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

3.1 Kinds of simulators

3.1.6 Navigation simulators

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

Cornell Research Foundation, Inc.

open source (Cornell Research Foundation, Inc. License)

via released installation script

3.2.1 swans-ambassador folder structure

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

.......................... Installation script for SWANS

Figure 3.3: SWANS folder structure

chmod 755 swans_installer

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

OMNeT++ Community and OpenSim Ltd.

Windows (mingw), Linux

open source for academic use

via released installation script

3.3.1 omnetpp-ambassador folder structure

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

The OMNeT++ federate as executable

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

# Setting the PATH variable

Installation shell script

chmod 755 set_env

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

Tom Henderson, Mathieu Lacage, George Riley, Mitch Watrous,

C++ (core) and Python (bindings)

GNU/Linux FreeBSD Mac OS X

free software: GNU GPLv2

Deployed in VSimRTI all-in-one

no (and need a patch to link)

3.4.1 ns3-ambassador folder structure

.................................... ambassador configuration file

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

............................... Installation script for ns-3

Figure 3.7: ns3-ambassador federate folder structure

The ns-3 installation script accomplishes the following tasks:

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

ns3::ConstantSpeedPropagationDelayModel and the ns-3 standard propagation loss model

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

ns3::FriisPropagationLossModel. Radio propagation models in ns-3 can easily be exchanged with