Vsimrti User Manual 18.0

vsimrti-user-manual-18.0

User Manual:

Open the PDF directly: View PDF .
Page Count: 141

Download
Open PDF In Browser	View PDF

VSimRTI: Vehicle-2-X Simulation
Runtime Infrastructure
User Documentation

Michalis Adamidis

Manuel Bock

Jan Henning
Sven Erik Jeroschewski
Robert Protzmann
Stefan Rulewitz

Sebastian Dunkel

Adrian Herrmann

Jiajun Hu

Franz Kage

Bernard Ladenthin

Tobias Queck

Alexander Scheck

Julia Ullrich

Roland Cristea

Stefan Reichel
Erik Schleiff

Sascha-Gaetano Urso

Version 18.0
April 24, 2018

Karl Hübner
Nico Naumann
David Rieck
Björn Schünemann

Michael Weiner

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 für 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

https://www.fokus.fraunhofer.de/asct
DCAITI

http://www.dcaiti.tu-berlin.de

Contents
1 Introduction
1.1 Overview . . . . . . . . . . . . . . .
1.2 Download and install . . . . . . . .
1.3 Update . . . . . . . . . . . . . . . .
1.4 License . . . . . . . . . . . . . . . .
1.5 Concept . . . . . . . . . . . . . . . .
1.5.1 Federates and Ambassadors
1.5.2 Scenario configuration . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

1
1
1
2
2
3
3
3

2 Run simulations
2.1 Run a single simulation via CLI .
2.1.1 VSimRTIEmbeddedStarter
2.2 Results . . . . . . . . . . . . . . .
2.2.1 Logging . . . . . . . . . . .
2.3 Run a simulation set via CLI . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

4
4
5
7
7
8

3 Simulators
3.1 Kinds of simulators . . . . . . . . . . . . . . . . . . .
3.1.1 Network simulators . . . . . . . . . . . . . . .
3.1.2 Traffic simulators . . . . . . . . . . . . . . . .
3.1.3 Application simulators . . . . . . . . . . . . .
3.1.4 VSimRTI communication simulators . . . . .
3.1.5 Environment simulators . . . . . . . . . . . .
3.1.6 Electricity simulators . . . . . . . . . . . . . .
3.2 OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 omnetpp-ambassador folder structure . . .
3.2.2 Installation . . . . . . . . . . . . . . . . . . . .
3.3.3 Installation in Docker environment . . . . .
3.2.4 Configuration . . . . . . . . . . . . . . . . . .
3.3 ns-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 ns3-ambassador folder structure . . . . . . .
3.3.2 Installation . . . . . . . . . . . . . . . . . . . .
3.3.3 Installation in Docker environment . . . . .
3.3.4 Configuration . . . . . . . . . . . . . . . . . .
3.4 SUMO . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 sumo-ambassador folder structure . . . . .
3.4.2 Installation . . . . . . . . . . . . . . . . . . . .
3.4.3 Configuration . . . . . . . . . . . . . . . . . .
3.4.4 Using the SUMO GUI with VSimRTI . . . . .
3.4.5 Routes and Vehicle Types . . . . . . . . . . .
3.4.6 Further information . . . . . . . . . . . . . .
3.4.7 VSimRTI specific information . . . . . . . . .
3.5 VSimRTI Application Simulator . . . . . . . . . . . .
3.5.1 applicationNT-ambassador folder structure
3.5.2 Installation . . . . . . . . . . . . . . . . . . . .
3.5.3 Libraries . . . . . . . . . . . . . . . . . . . . .
3.5.4 Basic functionality . . . . . . . . . . . . . . .
3.5.5 Gather information in an application . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

9
9
9
10
10
10
11
11
12
12
13
19
15
16
17
17
19
20
22
22
22
23
23
23
24
24
25
25
25
25
25
26

.
.
.
.
.

Contents

3.6

3.7

3.8

3.9

Contents

3.5.6 Equipped units . . . . . . . . . . . . . . . . . . . .
3.5.7 Technical details . . . . . . . . . . . . . . . . . . .
3.5.8 Configuration . . . . . . . . . . . . . . . . . . . . .
3.5.9 Development of applications . . . . . . . . . . . .
3.5.10 Debugging of applications . . . . . . . . . . . . . .
3.5.11 Internal ETSI applications . . . . . . . . . . . . . .
3.5.12 Sending Cooperative Awareness Messages (CAM)
3.5.13 Access SUMO TraCI from applications . . . . . . .
3.5.14 Navigation . . . . . . . . . . . . . . . . . . . . . . .
3.5.15 Mapping 3 . . . . . . . . . . . . . . . . . . . . . . .
VSimRTI Cellular Simulator . . . . . . . . . . . . . . . . .
3.6.1 cell2-ambassador folder structure . . . . . . . . .
3.6.2 Installation . . . . . . . . . . . . . . . . . . . . . . .
3.6.3 Configuration . . . . . . . . . . . . . . . . . . . . .
3.6.4 Operation . . . . . . . . . . . . . . . . . . . . . . .
VSimRTI Simple Network Simulator . . . . . . . . . . . .
3.7.1 sns-ambassador folder structure . . . . . . . . . .
3.7.2 Installation . . . . . . . . . . . . . . . . . . . . . . .
3.7.3 Configuration . . . . . . . . . . . . . . . . . . . . .
3.7.4 Operation . . . . . . . . . . . . . . . . . . . . . . .
VSimRTI Eventserver . . . . . . . . . . . . . . . . . . . . .
3.8.1 eventserver-ambassador folder structure . . . . .
3.8.2 Installation . . . . . . . . . . . . . . . . . . . . . . .
3.8.3 Configuration . . . . . . . . . . . . . . . . . . . . .
VSimRTI Battery Simulator . . . . . . . . . . . . . . . . .
3.9.1 battery-ambassador folder structure . . . . . . .
3.9.2 Installation . . . . . . . . . . . . . . . . . . . . . . .
3.9.3 Introduction . . . . . . . . . . . . . . . . . . . . . .
3.9.4 Vehicle model . . . . . . . . . . . . . . . . . . . . .
3.9.5 Battery model . . . . . . . . . . . . . . . . . . . . .
3.9.6 Environment model . . . . . . . . . . . . . . . . .
3.9.7 Sample configuration . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

26
26
26
27
29
30
31
32
32
33
36
36
37
37
40
41
41
41
41
42
44
44
44
44
45
45
45
45
45
45
46
46

4 Tutorial Tiergarten
4.1 Mapping Configuration . . . . . . .
4.2 Inter-Vehicle Communication . . . .
4.3 Intra-Vehicle Communication . . . .
4.3.1 The traffic light application .
4.4 Interpretation of simulation results

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

47
48
49
53
54
55

5 Tutorial Barnim
5.1 Overview . . . . . . . . . . . . . .
5.2 Mapping configuration . . . . . .
5.3 VSimRTI configuration . . . . . .
5.4 Applications . . . . . . . . . . . .
5.4.1 DEN-Message handling .
5.4.2 Cellular Communication .
5.5 Conclusion . . . . . . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

56
56
57
58
58
59
59
60

6 Tutorial Traffic Lights
6.1 Use scenario-convert to export traffic lights . . . . . . . . . . . . . . . . .
6.2 Determine the traffic lights that should be equipped with applications .
6.3 Configure the mapping for traffic lights . . . . . . . . . . . . . . . . . . .
6.4 The Traffic Light API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

61
61
62
62
63

.
.
.
.
.
.
.

.
.
.
.
.
.
.

7 Tutorial LuST
64
7.1 Execute the LuST scenario with VSimRTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

4

Contents

Contents

7.2 Current limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8 Create a new scenario
8.1 Road network data . . . . . . . . .
8.1.1 Using OpenStreetMap data
8.2 Vehicles and Routes . . . . . . . . .
8.3 VSimRTI . . . . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

66
66
66
68
69

9 Visualizers
9.1 Kinds of Visualizers . . . . . . . . . . . . . . . . . . . . . . . .
9.2 VSimRTI WebSocket Visualizer . . . . . . . . . . . . . . . . .
9.3 VSimRTI File Visualizer . . . . . . . . . . . . . . . . . . . . . .
9.3.1 Configuring the File Visualizer . . . . . . . . . . . . .
9.4 VSimRTI Integrated Test and Evaluation Framework (ITEF)

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

72
72
73
74
74
78

10Run simulation series
10.1 Simulation Runner . . . . . . .
10.1.1 Usage . . . . . . . . . . .
10.1.2 Configuration . . . . . .
10.1.3 Parametrization . . . . .
10.1.4 Additional Information .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

80
80
80
81
83
85

.
.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.

.
.
.
.
.

.
.
.
.
.

11Additional tools
86
11.1 scenario-convert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
12VSimRTI configuration
12.1 Overview . . . . . . . . . .
12.2 Federates configuration .
12.2.1 Federate priorities
12.3 Host configuration . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

90
90
90
91
91

13Additional information
92
13.1 PATH configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
14List of Acronyms

94

A VSimRTI deployment
96
A.1 VSimRTI Folder Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A.2 File listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
B Example scenario Barnim
108
B.1 Folder Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
B.2 File listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
C Example scenario Tiergarten
123
C.1 Folder Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
C.2 File listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
D Package Additional Examples

126

E Configuration Schemata

128

F References

134

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

5

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 VSimRTI’s features and configurations by providing two
tutorials named Barnim (see chapter 5) and Tiergarten (see chapter 4).
If you need more information regarding VSimRTI or a specific configuration, we ask you to take a look
at the Doxygen documentation provided alongside the current release. Documentation is available for
all JSON style configs. Apart from that the appendix provides information for the respective XML style
configurations.
If you have any questions or need further support, please feel free to contact our support team via our
mailing list. Please attach relevant log files and scenario files to your inquiry. We look forward to receiving
your feedback concerning further improvements of the VSimRTI documentation as well as the installation
and configuration process.

VSimRTI at a glance
VSimRTI was built to provide users with the flexibility to perform various V2X simulations with their own
choice of simulators. In order to provide the flexibility to exchange a simulator without changing the
underlying infrastructure, VSimRTI offers several interfaces for the integration of different simulators,
e.g. for network, traffic, and environment simulations. For the synchronization and the communication
purposes, 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. Consequently, a compatible Java Runtime Environment (JRE) for your operating system must be installed to
execute VSimRTI. Currently, Java version 8 is required to run VSimRTI.

1.2 Download and install
• Download vsimrti-bin-18.0.zip from the DCAITI website .
• The package vsimrti-bin-18.0.zip has to be extracted to an arbitrary path. This installation
path is referenced as vsimrti throughout the entire document.

1 Introduction

1.3 Update

1.3 Update
In order to update VSimRTI to a new version, please perform the following steps manually:
• Backup your personal simulation scenarios from VSimRTI’s scenarios directory.
• Remove your old VSimRTI installation completely.
• Install VSimRTI according to the previous section.
• Copy your simulation scenarios back to VSimRTI’s scenarios directory.
• Migrate your scenarios to individual changes in the new VSimRTI version according to the

vsimrti-conversion-guide-18.0.pdf , which can be found on the DCAITI website .

1.4 License
The licensing mechanism was introduced for a better release control. It improves user support whilst
helping our developer team to deactivate outdated releases which cannot be maintained anymore. Every
user needs to be registered at the license server to obtain a license.
1. Running the

firstStart

script in the VSimRTI root folder causes the file

vsimrti/systeminfo.txt to be generated. This file is also generated when VSimRTI is
run without a valid license file or an invalid user.
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 staff member registers the new user at the VSimRTI license server as soon as possible, usually
within one workday. When your license is active, an email containing your user id will be sent to
you.
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
• VSimRTI version

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

2

1 Introduction

1.5 Concept

4. Your license will be activated directly after confirmation by the VSimRTI team. 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 will be renewed for another 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.
Notice: If you encounter any problems with corrupt license files, you can also use the

firstStart script to reset the local license files and retrieve a new copy during the next run.
Notice: If the firstStart script does not result in a vsimrti/systeminfo.txt file,
please check if you have sufficient rights on your machine. You can also try to start the

vsimrti script instead, by calling vsimrti.sh -u  -s Barnim.
This command will always fail, due to the missing license, however, it may generate the
required systemInfo.txt.

1.5 Concept
In contrast to existing fixed simulator couplings VSimRTI allows easy integration and exchangeability
of simulators. Depending on your specific requirements, the high flexibility of VSimRTI enables you to
couple the most appropriate simulators for a realistic presentation of vehicle traffic, emissions, wireless
communication, and the execution of V2X applications.

1.5.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 implementation of the appropriate ambassador interface and the possiblity to
execute its specified commands.

1.5.2 Scenario configuration
Any scenario needs to be configured with a configuration file.

The specific path to this file is

vsimrti/scenarios//vsimrti/vsimrti_config.xml .

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

3

2 Run simulations
Notice: Install the required simulators for the specific scenario and have a valid license
(see section 1.4).

2.1 Run a single simulation via CLI
To run a single simulation via Command Line Interface (CLI) calling the VSimRTI start script with the
following command line arguments. The VSimRTI start script supports following arguments.

-c, - -configuration The
pendent

and

located

includes

other

primary
in

necessary

VSimRTI

the

according

configuration

configuration
scenario
files.

file

which

folder.

is

This

Usually

you

will

scenario

file

de-

transitively

use

the

file

your

scenario

is

lo-

VSimRTI

(i.e.

vsimrti/scenarios//vsimrti/vsimrti_config.xml .
-s, - -scenario If
cated

in

the
the

VSimRTI
default

configuration
scenario

file

directory

of
of

in

vsimrti/scenarios//vsimrti/vsimrti_config.xml ), this option can
be used instead of the -c option by passing only the scenario name
(-s ).

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

-g, - -performance-GUI Opens a GUI Panel which provides several charts regarding the current
simulation run, such as the progression of the Real Time Factor or memory consumption of the
simulation.

-b, - -realtimeBrake With this parameter, the simulation will be slowed done to a desired Real Time
Factor, if possible. When simulations already run slower than real time, this factor will have no
effect. For example, use -b 1 to execute the simulation in real time.

-v, - -start-visualizer Opens a page in your default browser which visualizes all vehicle movements of the simulation on a map. This option only works, if your scenario has configured the
websocket visualizer (see section 9.2).

2 Run simulations

2.1 Run a single simulation via CLI

GNU/Linux
Listing 2.1: VSimRTI GNU/Linux start command.

./ vsimrti . sh -c ./ scenarios / < scenario name >/ vsimrti / vsimr ti_con fig . xml -u userid

Microsoft Windows
Listing 2.2: VSimRTI Microsoft Windows start command.

vsimrti . bat -c .\ scenarios \ < scenario name >\ vsimrti \ vs imrti_ confi g . xml -u userid

2.1.1 VSimRTIEmbeddedStarter
The VSimRTIEmbeddedStarter is 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 than the start scripts. E.g. the VSimRTIEmbeddedStarter can search in configuration files for
the given scenario id. The embedded starter has a user friendly CLI and many options.
Listing 2.3: VSimRTI VSimRTIEmbeddedStarter help command.

usage : java - jar V s i m r t i E m b e d d e d S t a r t e r . jar
-b , - - realtimeBrake < REALTIMEFACTOR >
Set value for real time brake .
-c , - - config < PATH >
Path to Scenario configuration file
( vs imrti_ config . xml ) . Can be used instead
of " -s " parameter . ( mandatory ) .
-- classpaths
Class paths . Default is " . " ( working
directory ) .
-d , - - defaults - file < PATH >
Path to VSimRTI configuration file
( default : etc / defaults . xml )
-e , - - exte r n a l W a t c h D o g < PORTNUMBER >
Specific external watchdog port number
-g , - - performance - GUI
Opens performance GUI
-h , - - hosts < PATH >
Path to host configuration file ( default :
etc / hosts . json )
-- help
Shows this help information .
-l , - - logger < PATH >
Path to logback configuration file
( default : etc / logback . xml )
-- logback - path < PATH >
Use specific logback . xml
-o , - - l o g g i n g L e v e l O v e r r i d e < LOGLEVEL >
Overrides the log level to new value ( e . g .
DEBUG )
-p , - - process - builder
Start VSimRTI using P rocess Builde r .
-- pipe
Use pipe redirect ( only for
-- process - builder
-- print - jar - files
Print the found jar files .
-- print - parameter
Print the parameter before start .
-s , - - scenario < NAME >
The name of the VSimRTI scenario . Can be
used instead of " -c " parameter .
( mandatory )
-- simrun
Use the VSimRTI simulation runner .
-- strict - configuration - path
The starter pass - through the configuration
path as it is .
-u , - - user < USERID >
Your UserId ( mandatory ) . Please read the
user manual if you do not have a UserId
yet .
-v , - - start - visualizer
Starts the web socket visualizer .
-- verbose
Print information at start .
-- version
Print the version information and exits .
-w , - - watchdog - interval < SECONDS >
Kill VSimRTI process after n seconds if a
federate is not responding . 0 disables the
watchdog . ( default : 30)

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

5

2 Run simulations

2.1 Run a single simulation via CLI

Listing 2.4: VSimRTI VSimRTIEmbeddedStarter start command.

java - jar VsimrtiEmbeddedStarter -18.0. jar -u userid -n scenarioId

While VSimRTI is running, it prints some information on the command line:

_

X

[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 2.1: Output of VSimRTI while running

The current simulation progress is shown in the following format.
• current wallclock time
• 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.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

6

2 Run simulations

2.2 Results

2.2 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- . 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-
appsNT .............................................................................
_ ................. Detailed application specific logs for each unit.
OperatingSystem.log ................. Detailed operating system logs for the unit.
ExampleApp.log ............. Detailed application specific logs for each application.
ApplicationNT.log ...................... Information about the application ambassador.
Battery.log ................... Battery ambassador log for simulation of electric vehicles.
Cell2.log ....................................................... Cellular network log.
ChargingStation.log ................................ ChargingStation ambassador log.
Communication.log ........................ (Ad hoc) network simulation ambassador log.
CommunicationDetails.log .... Detailed output of network simulator (ns-3 or OMNeT++).
Environment.log ................................ Logs of the environmental eventserver.
Mapping.log .............................................. Mapping configuration logs.
Navigation.log . Detailed logs about navigation component in the application ambassador.
statistics.csv .................. Simulation overview in comma separated value-format.
Traffic.log ................................... Traffic simulation log (SUMO or others).
visualizer.csv ........................... Recorded data of the VSimRTI File Visualizer.
VSimRTI.log ............ General VSimRTI information, e.g. startup sequence information.
Figure 2.2: VSimRTI log folder structure

2.2.1 Logging
The main configuration file is vsimrti/etc/logback.xml . 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 vsimrti/etc/logback.xml . This might also influence the
simulation performance because of a possibly high amount of data to be logged.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

7

2 Run simulations

2.3 Run a simulation set via CLI

Federate specific logging
Depending on the simulation purpose, further configuration possibilities for federate specific logging
may be of interest.
For instance, OMNeT++ exhibits an elaborated logging concept. The omnetpp.ini in the scenario folder
includes options to adjust the logging levels. The outputs of this federate are written into Communica-

tionDetails.log.

2.3 Run a simulation set via CLI
Notice: The following options are only available with a commercial license of VSimRTI.
For further information on licenses, please refer to our mailing list .
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. Please refer to 10.1.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

8

3 Simulators
VSimRTI couples different simulators and can’t 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)
Objective Modular Network Testbed in C++ (OMNeT++) ................. (see 3.2)
network simulator 3 (ns-3) ............................................ (see 3.3)
traffic simulators ...................................................... (see 3.1.2)
Simulation of Urban Mobility (SUMO) .................................. (see 3.4)
application simulators .................................................. (see 3.1.3)
VSimRTI Application Simulator (built in) ............................ (see 3.5)
VSimRTI Mapping (built in) ...................................... (see 3.5.15)
VSimRTI navigation simulator (built in) ....................... (see 3.5.14)
VSimRTI communication simulators ...................................... (see 3.1.4)
VSimRTI Cellular Simulator (built in) ............................... (see 3.6)
VSimRTI Simple Network Simulator (SNS) (built in) .................. (see 3.7)
environment simulators .................................................. (see 3.1.5)
VSimRTI Eventserver (built in) ....................................... (see 3.8)
electricity simulators .................................................. (see 3.1.6)
VSimRTI Battery Simulator (built in) ................................ (see 3.9)
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 participating entities. For VSimRTI and, more specifically, the communication in a V2X
environment this refers to simulations of the wireless transmissions taking place between the various
simulated entities. The provided simulators are prepared to simulate a communication stack basing on
the IEEE 802.11p network interfaces with IP and UDP on top. However, according to their model base,

3 Simulators

3.1 Kinds of simulators

alternative set ups are possible. Currently, VSimRTI supports the commonly known network simulators
OMNeT++ and ns-3, and the built in communication simulator SNS.

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 currently supported traffic simulator SUMO is a microscopic traffic simulator.

3.1.3 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.4 VSimRTI communication simulators
For different reasons of convenience or extended analysis capabilities, VSimRTI ships with two additional
communication simulators:
• The Cellular Simulator is a special case of network simulator to simulate the communication taking
place within a cellular network, such as Universal Mobile Telecommunications System (UMTS) and
Long Term Evolution (LTE).
• The Simple Network Simulator is written in Java and already tightly integrated in VSimRTI. It offers
a lightweight and fast solution for simulation of ad hoc communication.
The provided VSimRTI communication simulators can be used as an alternative (SNS) or addition (Cell2)
to classic network simulators.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

10

3 Simulators

3.1 Kinds of simulators

3.1.5 Environment simulators
This kind of simulator simulates certain environmental events such as rain, fog, snow, etc..

3.1.6 Electricity simulators
In connection with VSimRTI, electricity simulators enable investigations in the field of electric mobility.
For this purpose, VSimRTI ships with the built in VSimRTI Battery Simulator.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

11

3 Simulators

3.2 OMNeT++

3.2 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 OMNeT++ - Model library
for wired, wireless and mobile networks (INET) Framework. As INET provides all models necessary for
simulating Vehicle-2-X communication, it is selected for the integration to VSimRTI.
For more information on the INET extension you should look closer on the website
https://inet.omnetpp.org.
Software information
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://inet.omnetpp.org

Supported version(s)

OMNeT++ 4.6
INET 3.0

Dependencies

libprotobuf 3.3.0

Installation

via released installation script
Table 3.1: Software information: OMNeT++

3.2.1 omnetpp-ambassador folder structure
The omnetpp.ini file has to be located in the omnetpp folder of the scenario configuration.


omnetpp ..........................................................................
omnetpp_config.json .............................. Ambassador configuration file
omnetpp.ini ................................. OMNeT++ federate configuration file
Figure 3.2: omnetpp-ambassador folder structure

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

12

3 Simulators

3.2 OMNeT++

3.2.2 Installation
The VSimRTI all-in-one package comes with an installation script for the bash-shell, which automates
the task of the OMNeT++/INET installation.

Prerequisites

The OMNeT++/INET federate furthermore depends upon:
• libprotobuf 3.3.0
Please make sure these libraries are installed before running the installation script.

Installation shell script

vsimrti
bin
fed
omnetpp
Dockerfile ......................... Docker file for OMNeT++/INET federate
omnet_installer.sh .................. Installation script for OMNeT++/INET
Figure 3.3: OMNeT++ folder structure

Please execute the following steps for installing the OMNeT++/INET federate:
1. Follow the link and download the source code of OMNeT++ 4.6 (omnetpp-4.6-src.tgz) :

https://omnetpp.org/omnetpp/download/30-omnet-releases/2290-omnet-4-6-source-ide-tgz
2. Make the installation script executable:

chmod 755 omnet_installer.sh
3. Make sure all dependencies are met by your system.
4. Run the script to install OMNeT++/INET:

./omnet_installer.sh -s /path/to/omnetpp-4.6-src.tgz

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

13

3 Simulators

3.2 OMNeT++

3.2.3 Installation in Docker environment
Notice: This is an experimental feature. Please refer to our mailing list if you experience
any problems.
This guide gives instructions to execute the OMNeT++ federate inside a docker container. If you already
installed OMNeT++ on your machine following the steps before, you can skip this section.
Docker1 is a new approach to execute software. More precisely, it "wraps software in a complete filesystem
that contains everything it needs to run: code, runtime, system tools, and system libraries". As a result, the
software is executed within a container and its execution does not rely on the environment the container
is running in.
In context of VSimRTI, this approach allows to execute OMNeT++ within a docker container. The user
does not need to manually install OMNeT++ and can even run OMNeT++ on Windows hosts.
1. Install Docker ≥ 1.13 on your machine.
2. To get everything work, please make sure to execute the following steps depending on your
operating system:
• Windows - In the settings, share the drive where VSimRTI is installed on. You may need to
restart docker in the reset tab.
• Linux - Make sure your user account belongs to the unix-group "docker". You may need to
restart your machine.
3. Switch to the location of the Dockerfile in vsimrti/bin/fed/omnetpp
4. Follow the link and download the source code of OMNeT++ 4.6 (omnetpp-4.6-src.tgz) and place
the downloaded file into the vsimrti/bin/fed/omnetpp directory:

https://omnetpp.org/omnetpp/download/30-omnet-releases/2290-omnet-4-6-source-ide-tgz
5. Execute the following command on command line:

docker build -t omnetpp-federate:18.0 .
This could take a while to finish.
6. Enter the name of the docker image etc/defaults.xml in the omnetpp-section into the tag

dockerImage:
< federate class = " ... " >
< id >omnetpp
...
< dockerImage >omnetpp-federate:18.0
...


You can test the installation of your docker image with the Tiergarten scenario, by activating omnetpp in
the vsimrti_config.xml.

1 https://www.docker.com/

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

14

3 Simulators

3.2 OMNeT++

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

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

15

3 Simulators

3.3 ns-3

3.3 ns-3
The ns-3 is a discrete-event network simulator, that was started as an open-source 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 download2 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
• Ubuntu
• OS X Mountain Lion, Snow Leopard, ...
• FreeBSD
• Cygwin
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 VMware3 or VirtualBox4 .

2 Please note, that downloading ns-3 via tarball is simpler than the Mercurial process since all of the pieces are pre-packaged for

you.
3 http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_(Windows)
4 http://www.nsnam.org/wiki/index.php/HOWTO_use_VirtualBox_to_run_simulations_on_Windows_machines

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

16

3 Simulators

3.3 ns-3

Software information
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/

Supported version(s)

3.25

Dependencies

libprotobuf 3.3.0
libxml2
libsqlite3

Deployed in VSimRTI all-in-one

no (and need a patch to link)
Table 3.2: Software information: ns-3

3.3.1 ns3-ambassador folder structure

ns3
ns3_config.json .................................. Ambassador configuration file
configTechnologies.xml .......................... ns-3 federate configuration file
confWifi.xml ..................................... ns-3 federate configuration file
Figure 3.4: ns3-ambassador folder structure

3.3.2 Installation
VSimRTI offers support for the current stable release of ns-3 (3.25), that was released in March 2016. Older
versions of ns-3 (prior to 3.25) are not supported. However, also for newer versions we cannot guarantee
the correct operation. 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. At least you need the following packages to be installed:
Listing 3.1: ns-3:

Minimum requirements

gcc
g ++
python
python - dev

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

17

3 Simulators

3.3 ns-3

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
For the connection to VSimRTI, the ns-3 federate furthermore depends upon
• libxml2
• libsqlite3
• libprotobuf 3.3.0
Please make sure these libraries are installed before running the installation script.
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
Dockerfile.sh ................................. Dockerfile for ns-3 federate
ns3_installer.sh ............................... Installation script for ns-3
Figure 3.5: 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.3.4). 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.
3. At last ns-3 has to be activated in the vsimrti_config.xml and the simulation can be started.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

18

3 Simulators

3.3 ns-3

3.3.3 Installation in Docker environment
Notice: This is an experimental feature. Please refer to our mailing list if you experience
any problems.
This guide gives instructions to execute the ns-3 federate inside a docker container. If you already installed
ns-3 on your machine following the steps before, you can skip this section.
Docker5 is a new approach to execute software. More precisely, it "wraps software in a complete filesystem
that contains everything it needs to run: code, runtime, system tools, and system libraries". As a result, the
software is executed within a container and its execution does not rely on the environment the container
is running in.
In context of VSimRTI, this approach allows to execute ns-3 within a docker container. The user does not
need to manually install ns-3 and can even run ns-3 on Windows hosts.
1. Install Docker ≥ 1.13 on your machine.
2. To get everything work, please make sure to execute the following steps depending on your
operating system:
• Windows - In the settings, share the drive where VSimRTI is installed on. You may need to
restart docker in the reset tab.
• Linux - Make sure your user account belongs to the unix-group "docker". You may need to
restart your machine.
3. Switch to the location of the Dockerfile in vsimrti/bin/fed/ns3
4. Execute the following command on command line:

docker build -t ns3-federate:18.0 .
This could take a while to finish.
5. Enter the name of the docker image etc/defaults.xml in the ns3-section into the tag

dockerImage:
< federate class = " ... " >
< id >ns3
...
< dockerImage >ns3-federate:18.0
...


You can test the installation of your docker image with the Tiergarten scenario, by activating ns3 in the

vsimrti_config.xml.

5 https://www.docker.com/

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

19

3 Simulators

3.3 ns-3

3.3.4 Configuration
The whole ns-3 specific configuration is done via the confWifi.xml and configTechnologies.xml
files.
Listing 3.2: confWifi.xml


< wifi >

< ipConfig u ra ti o n >
< ip address = " 192.168.0.0 " mask = " 255.255.0.0 " / >


< 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 " / >


< 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 " / >

< wif iCo n f i g u r a t i o n >

< wifiMac property = " type " value = " n s 3 : : A d h o c W i f i M a c " / >

< wifiManager property = " phyMode " value = " O fdmRat e54Mbp s " / >

< 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 " / >

< 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 " / >

< wifiPhy property = " C c a M o d e 1 T h r e s h o l d " value = " -99.0 " / >

< wifiPhy property = " TxGain " value = " 0.0 " / >

< wifiPhy property = " RxGain " value = " 0.0 " / >

< wifiPhy property = " TxPowerLevels " value = " 1 " / >

< wifiPhy property = " TxPowerEnd " value = " 17.0 " / >

< wifiPhy property = " TxPowerStart " value = " 17.0 " / >

< wifiPhy property = " RxNoiseFigure " value = " 0.0 " / >

< wifiPhy property = " ChannelNumber " value = " 1 " / >



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
ns3::FriisPropagationLossModel. Radio propagation models in ns-3 can easily be exchanged with

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

20

3 Simulators

3.3 ns-3

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.3: 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 " / >



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 don’t need to take any
changes and simply use the default configuration file, that ships with the ns-3 federate.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

21

3 Simulators

3.4 SUMO

3.4 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.
Software information
Developer(s)

German Aerospace Center

Written in

C++

Operating system

GNU/Linux and Microsoft Windows

License

free software: GNU GPLv2
since 0.31.0: EPL-2.0

Website

http://sumo.dlr.de/

Supported version(s)

0.30.0 . . . 0.32.0

Deployed in VSimRTI all-in-one

no
Table 3.3: Software information: SUMO

Important: Please note that VSimRTI only supports SUMO 0.30.0 or higher.

3.4.1 sumo-ambassador folder structure
This ambassador can be configured with a configuration file. The specific path is

vsimrti/scenarios//sumo/sumo_config.json

sumo .............................................................................
.nod.xml ............................................. Node file
.edg.xml .............................................. Edge file
.con.xml ........................................ Connection file
.net.xml ........................................... Network file
.rou.xml ............................................. Route file
.sumo.cfg ............................... sumo configuration file
sumo_config.json ................................. ambassador configuration file
Figure 3.6: sumo-ambassadorfolder structure

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

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

22

3 Simulators

3.4 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 13.1).

3.4.3 Configuration
Notice: The documentation for the VSimRTI specific component is freely available on
the DCAITI website , explaining all available options.
The SUMO configuration consists of sumo specific config files and the sumo-ambassador configuration
file. vsimrti/scenarios//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 scenarioconvert 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 11.1).

3.4.4 Using the SUMO GUI with VSimRTI
It is also possible to use the Graphical User Interface (GUI) of SUMO in order to visualize and interact
with the simulation. To achieve this, VSimRTI can be configured that it starts the GUI process of SUMO
as the federate rather than the command line interface.
In order to use the SUMO GUI with VSimRTI, please open the file vsimrti/etc/defaults.xml
and

replace

the

entry

com.dcaiti.vsimrti.fed.sumo.ambassador.SumoAmbassador with

com.dcaiti.vsimrti.fed.sumo.ambassador.SumoGUIAmbassador .
Afterwards VSimRTI can be executed as usual. However, the traffic simulation has to be triggered manually
within the GUI window of SUMO. Additionally, the field Delay within the GUI can be used to slow
down the simulation. For further information about the graphical interface please consider the SUMO
documentation.
Notice: Keep in mind to launch VSimRTI with the argument -w 0 in order to disable
the watchdog timer. Otherwise it would shutdown VSimRTI if you pause the simulation in
the SUMO GUI.

3.4.5 Routes and Vehicle Types
For the simulation the traffic simulator SUMO is started as a background process. In preparation, VSimRTI
automatically generates all files needed, such as routes and vehicle types definition. In particular, VSimRTI
generates a *.rou.xml which contains all vehicle types from the mapping3 configuration and all routes
from the scenario database. This also means, that any route referenced by the mapping3 configuration
must be available in the scenario database. Additionally, the *.rou.xml in the scenario configuration of
SUMO will always be overwritten by VSimRTI at the start of the simulation.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

23

3 Simulators

3.4 SUMO

If you want to use SUMO specific parameters for the vehicle types (e.g. to define the car following model
or the emission class), you can predefine them in the file .rou.xml of your scenario.
All parameters you define their will be used when the route file is generated for the simulation (except
all paramaters which are defined in the mapping3 configuration such as accel, decel, tau, etc.). The
Tiergarten scenario provides such example file.

3.4.6 Further information
Notice: We recommend to use the 64 bit version of SUMO if you want to simulate
scenarios with a big traffic network.

3.4.7 VSimRTI specific information
Notice:

The SumoAmbassador 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 ,

ChangeSpeed , SlowDown , PropagateNewRoute , ChangeStaticRoute and ChangeTrafficLightsState.
Important: Even though the SumoAmbassador is able to receive ChangeRoute messages which will result in using the internal Re-route feature of SUMO, it is strongly recommended to use the navigation functionality of the ApplicationNTAmbassador by using the
provided API.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

24

3 Simulators

3.5 VSimRTI Application Simulator

3.5 VSimRTI Application Simulator
The application simulator is a sophisticated simulator to provide simulation units (e.g. vehicles, road side
units, traffic lights, charging stations) an interface to run their logic. The latest application simulator has
been developed from scratch and is called ApplicationSimulatorNT.

3.5.1 applicationNT-ambassador folder structure
This ambassador can be configured with a configuration file. The specific path is

vsimrti/scenarios//applicationNT/applicationNT_config.json

applicationNT ...................................................................
applications .................................................................
applicationNT_config.json ............... Configuration file for the ambassador.
.db ................................. Database file for navigation.
mapping3 ........................................................................
mapping_config.json ...................... Configuration file for the ambassador.
Figure 3.7: applicationNT-ambassador folder structure

3.5.2 Installation
This simulator does not need to be installed. It is delivered as part of the VSimRTI-installation package.

3.5.3 Libraries
To develop applications you need to reference to jar files you will find in the following directories:
• vsimrti/bin/ambassadors/applicationNT-ambassador-18.0.jar
• vsimrti/bin/ambassadors/lib/*.jar
• vsimrti/bin/lib/*.jar
• vsimrti/bin/core/vsimrti-18.0.jar

3.5.4 Basic functionality
Each logical unit is recognized as a separate simulation unit. The application simulator can load different
applications for each simulation unit. For each application there is a general class and an extension for
the particular type of the simulation unit (e.g. Vehicle extends SimulationUnit).
This application may request information from an object and wants to control this.

For each

simulation object, an operating system will be created. For each application, there is an operating
system and an extension of the operating system for the particular type (e.g. VehicleApplication extends
AbstractApplication).

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

25

3 Simulators

3.5 VSimRTI Application Simulator

3.5.5 Gather information in an application
To gather information in an application from a simulation unit, there exist typically two different ways.

React on changes

Applications will be notified on changes. All applications must implement methods that are called before
and after a change. Typically, these methods are named before* and after*. Please note that not all changes
of information notify applications through this mechanism. Some information must be evaluated by
sampling. As an example, the method getStateOfEnvironmentSensor could not notify the application
by changing its state.

Sample information

The sampling of information at specific times can be done by requesting future events.

Self events

An event is a notification with information at a future point in the simulation. With a self-event, applications can wake up themselves at certain time steps. An event can be requested at any simulation point to
trigger an event execution.

3.5.6 Equipped units
All units are generally classified into two types, units that have application logic or not. Equipped vehicles
can also use a predefined ETSI application.

3.5.7 Technical details
• The simulator does not use concurrent processing.
• The logs are based on the application name.

3.5.8 Configuration
Notice: The documentation for the VSimRTI specific component is freely available on
the DCAITI website , explaining all available options.
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.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

26

3 Simulators

3.5 VSimRTI Application Simulator

3.5.9 Development of applications
Overview

Developing custom applications in VSimRTI is rather easy. The best way to learn is by looking at the
source code of actual applications. For this purpose, we provide the source code of all tutorial applications
and further examples. You can find the source code on the DCAITI website .
For an easy understanding of the application API, the following questions and their answers should
help:
• What is required to get my own application run in VSimRTI?
In VSimRTI it is very easy to build your own application. First, it needs to inherit from the Ab-

stractApplication class (see following section). Secondly, the application must be mapped to
a vehicle (or RSU, or traffic light, . . . ) via the mapping configuration (see section 3.5.15). Finally,
the application must be compiled as a Jar-File and placed into the application directory of your
scenario.
• How can I access vehicle functions from within the application, such as sending V2X messages?
Every applications has access to the OperatingSystem of the underlying unit which allows to
change its state or to initiate actions, such as sending messages to other vehicles.
• How can I react on events during the simulation, such as receiving V2X messages?
For each application you decide, which events the application should listening to. For example,
if your application needs to react upon incoming V2X messages, it simply implements the Com-

municationApplication interface. In the following section you can find all available interfaces
applications can implement.

Create a ’Hello world’ application using eclipse
Create a new project in eclipse (File ↦ New ↦ Java Project). Name your application HelloWorldApp .
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
JARs and add them to your project:
• vsimrti/bin/ambassadors/applicationNT-ambassador-18.0.jar
• vsimrti/bin/ambassadors/lib/*.jar
• vsimrti/bin/lib/*.jar
• vsimrti/bin/core/vsimrti-18.0.jar
Right click on the "Hello world" Project and choose (New ↦ Package).
age something like

com.mycompany.vsimrti.applications .

age and chose (New ↦ Class).

Name the class

Name the pack-

Right click on the pack-

HelloWorldApp , extend from the Class

[..]applicationNT.ambassador.simulationUnit.applications.AbstractApplication
and confirm. Afterwards, you need to specify the type of operating system  your application is

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

27

3 Simulators

3.5 VSimRTI Application Simulator

running on by parameterizing the extended AbstractApplication by one of the following
classes6 :
• VehicleOperatingSystem - for applications mapped to normal vehicles.
• ElectricVehicleOperatingSystem - for applications for vehicles with electro mobility features.
• RoadSideUnitOperatingSystem - for applications mapped to Road Side Units (RSU)s.
• TrafficLightOperatingSystem - for applications mapped to traffic lights.
• ChargingStationOperatingSystem - for applications mapped to charging stations.
Furthermore, your application can implement the following interfaces7 in order to get informed on
specific events:
• VehicleApplication - get informed when information about the vehicles state is updated.
• ElectricVehicleApplication - get informed on electric vehicle specific events.
• CommunicationApplication - react on incoming V2X messages.
• VSimRTIApplication - get informed on VSimRTI internal events.
• TrafficLightApplication - get noticed when the traffic light program is changed.
• ChargingStationApplication - react on state changes of the charging station.
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//applicationNT/applications .
Notice: You can download the example Application HelloWorldApp , which is part of
the AdditionalExamples package, from the website.
In the following picture you can find the example application HelloWorldApp opened in eclipse.

6 See package com.dcaiti.vsimrti.fed.applicationNT.ambassador.simulationUnit.operatingSystem.*
7 See package com.dcaiti.vsimrti.fed.applicationNT.ambassador.simulationUnit.applicationInterfaces.*

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

28

3 Simulators

3.5 VSimRTI Application Simulator

Figure 3.8: HelloWorldApp

3.5.10 Debugging of applications
To debug an application, remote debugging needs to be used. The following steps need to be performed
in order to debug the application:
1. Open the application in your IDE
2. Modify your vsimrti.sh or vsimrti.bat, depending on if you are on windows or a Unix-like
system. Examples can be found below.
3. Add a new debug profile for remote debugging, make sure port 4100 (or whichever was provided in
the call to VSimRTI)
4. Launch VSimRTI with the argument -w 0 to disable the watchdog timer will interfere with debugging

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

29

3 Simulators

3.5 VSimRTI Application Simulator

Listing 3.4: "vsimrti.sh on Unix-like systems"

#!/ bin / bash
set -e
source common . sh
ja vaM emo ry S i z e X m s = " "
ja vaM emo ry S i z e X m x = " "
ja vaP rox yS e t t i n g s = " - Djava . net . u s e S y s t e m P r o x i e s = true "
ja vaD ebu gS e t t i n g s = " - agentlib:jdwp = transport = dt_socket , server =y , suspend =y , address =4100 "
cmd = " java ${ j a v a P r o x y S e t t i n g s } ${ j a v a M e m o r y S i z e X m s } ${ j a v a D e b u g S e t t i n g s } ${ j a v a M e m o r y S i z e X m x } ⤦
Ç - cp . : ${ core } : ${ libs } : ${ ambassadors } : ${ am ba s sa d or _l i bs } : ./ etc - Djava . library . path =./ lib ⤦
Ç com . dcaiti . vsimrti . start . X ML C on f ig Ru n ne r $* "
$ cmd

Listing 3.5: "vsimrti.bat on windows systems"

@ECHO OFF
SetLocal E n a b l e D e l a y e d E x p a n s i o n
call common . bat
set jav aM e m o r y S i z e X m s =
set jav aM e m o r y S i z e X m x =
set jav aP r o x y S e t t i n g s = - Djava . net . u s e S y s t e m P r o x i e s = true
set jav aD e b u g S e t t i n g s = - Xdebug - X r u n j d w p : t r a n s p o r t = dt_socket \ , server = y \ , suspend = y \ , address =4100
java % ja va P r o x y S e t t i n g s % % j a v a D e b u g S e t t i n g s % % j a v a M e m o r y S i z e X m s % % j a v a M e m o r y S i z e X m x % - cp ! libs ⤦
Ç ! - Djava . library . path =./ lib com . dcaiti . vsimrti . start . X ML Co n fi g Ru nn e r %*
EndLocal
exit / b % errorlevel %

3.5.11 Internal ETSI applications
We provide ETSI conform applications which implement specific CAM generation rules. You can find
them in the package
• com.dcaiti.vsimrti.fed.applicationNT.etsiApplications.impl .

ETSI Application (Vehicle)

For example, to provide ETSI functionality for your vehicle, you can load the ETSI application

com.dcaiti.vsimrti.fed.applicationNT.etsiApplications.impl.Vehicle .
This application generates ETSI data for its simulation unit (e.g. heading, position, speed and time for
vehicles). According to its configuration, the application then sends out CAMs to other vehicles in range.
Note that the messages are only send when the time lies between the configured minimum and maximum
interval.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

30

3 Simulators

3.5 VSimRTI Application Simulator

Default configuration Without explicit configuration for the ETSI a default configuration is loaded.

For the ETSI interceptor have a look at the class CEtsi .
Notice: For more information about this component, please have a look at the javadoc
(doxygen) documentation.
Currently, the default configuration for the ETSI application looks like this:
{
" maxStart Offset " : 1000000000 ,
" minInterval " : 100000000 ,
" maxInterval " : 1000000000 ,
" position Change " : 4 ,
" headingChange " : 4 ,
" velocity Change " : 0.5
}

In general, the numeric values should be interpreted as time delta. E.g., if the ETSI values change by the
given amount, a new CAM is sent. The only exceptions are the minimum and maximum intervals. If the
time lies over the maximum interval, a CAM is sent even if the difference between the ETSI values isn’t
high enough. If the difference is high enough but the minimum interval isn’t surpassed, no message will
be sent.

3.5.12 Sending Cooperative Awareness Messages (CAM)
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
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.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

31

3 Simulators

3.5 VSimRTI Application Simulator

3.5.13 Access SUMO TraCI from applications
If SUMO is used as a traffic simulator and a special functionality is required, the sendSumoTraciByteAr-

rayMessage function in the OperatingSystem 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.
In all cases the command will trigger a response. The application can receive the response from the
method onSumoTraciByteArrayMessageResponse. This method will receive a SumoTraciByteArrayMes-

sageResponse object. This response contains the specified identifier. The application must handle the
identification process of the response itself.
Notice: A response is delivered to every application. To prevent unintentional delivery
each application request 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.
Notice: You can find the example application TestSumoTraciByteArrayMessageApp
in the additional examples bundle on the DCAITI website .

3.5.14 Navigation
The navigation of vehicles is handled completely by the application simulator. Each vehicle is equipped
with a navigation system which provides all required information and functions for navigational purposes:
• Retrieve the current position and heading of the vehicle.
• Get the target of the vehicle.
• Calculate various routes from the current position to an arbitrary target.
• Choose a suitable route out of existing ones from the current position to an arbitrary target.
• Switch onto a specific route.
In order to provide routing functionality, a map model based on Open Street Map data is used, which
needs to be transformed before the simulation using scenario-convert. The map data including initial
routes for vehicles is provided with the database file which needs to be located in

vsimrti/scenarios//applicationNT/.db

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

32

3 Simulators

3.5 VSimRTI Application Simulator

Configuration
If the database needs to be located somewhere else, the path can be specified in

vsimrti/scenarios//applicationNT/applicationNT_config.json:
{
...
" navigationConfiguration ": {
" databaseFile " : " path / to / scenario . db "
}
}

Usage
The following snippet show, how the navigation system can be used within an application:
// get navigation module
IN avi gat io n M o d u l e n a v i g a t i o n M o d u l e = g e t O p e r a t i n g S y s t e m () . g e t N a v i g a t i o n M o d u l e () ;
// choose target position to current target
RoutingPos i ti o n targe tPosit ion = new Ro u ti ng P os it i on ( n a v i g a t i o n M o d u l e . g e t T a r g e t P o s i t i o n () ) ;
// set routing parameters to fastest route search
Ro uti ngP ar a m e t e r s params = new R o u t i n g P a r a m e t e r s () . costFunction ( I R o u t i n g C o s t F u n c t i o n . Fastest ) ;
// calculate routes
RoutingRes p on s e response = n a v i g a t i o n M o d u l e . c a lc ul a te R ou te s ( targetPosition , params ) ;
// switch to best route
if ( response . getBestRoute () != null ) {
boolean routeSwitched = n a v i g a t i o n M o d u l e . switchRoute ( response . getBestRoute () ) ;
...
}

3.5.15 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 Extensible Markup
Language (XML) for configuration.
The configuration for the Mapping3-Federate is located in

vsimrti/scenarios//mapping3/mapping_config.json .
In this file an object is described in JavaScript Object Notation (JSON), which will at runtime be parsed
using the MappingFramework-Class.
Notice: The documentation for the VSimRTI specific component is freely available on
the DCAITI website , explaining all available options.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

33

3 Simulators

3.5 VSimRTI Application Simulator

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.

The rsus-section offers the possibility to define instances of RSU’s. To reuse a prototype simply
specify its name in the name-property. All relevant properties will then be automatically filled in. At least,
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
one weight differs from zero. So in case you don’t 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.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

34

3 Simulators

3.5 VSimRTI Application Simulator

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 user’s 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.4: 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.
Notice: For more information about this component, please have a look at the javadoc
(doxygen) documentation.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

35

3 Simulators

3.6 VSimRTI Cellular Simulator

3.6 VSimRTI Cellular Simulator
The VSimRTI built-in Cellular Simulator enables the applications to use cellular network communication.
The simulation of cellular communication in VSimRTI consists of two parts:
1. The Cellular Simulator itself and
2. The applications that can communicate over cellular networks in the Application Simulator
These changes are done in a generic way, making the cellular simulator exchangeable. Users interested
in a different kind of simulation of cellular communication may use other simulators and develop
ambassadors connecting them to VSimRTI.
The Cellular Simulator in the current state consists of three main modules:
1. Uplink Module
2. Geocaster Module
3. Downlink Module
The Geocaster module simulates a mandatory component for ITS communication. It is inspired by
the several architectures from research projects as simTD or CONVERGE to enable ITS use cases over
cellular networks. It mainly takes over the task of an addressing and routing component with geographic
knowledge to support geo-addressing. However, it also supports regular topological addressing.
The Uplink and Downlink Module are responsible for the transmission simulation. They account for the
aspects of transmission delays, packet losses and available data rates. In this context, Uplink and Downlink
always refer to the direction towards respectively from the Geocaster. For instance, a transmission
from an Internet-based server towards a vehicle would include an Uplink between the server and the
Geocaster and a Downlink between the Geocaster and the vehicle. While the Uplink direction only allows
point-to-point communication (Unicast), the Downlink supports point-to-point (Unicast) as well as
point-to-multipoint (Multicast).

3.6.1 cell2-ambassador folder structure
The VSimRTI cellular simulator can be configured via three distinct configuration files, which can be
found within the scenarios folder structure:


cell2
cell2_config.json ......................... Cellular ambassador configuration file
network.json ......................................... Network configuration file
regions.json .......................................... Regions configuration file
Figure 3.9: cell2-ambassador folder structure

The network and regions configuration files are referenced in the cellular ambassador configuration
file.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

36

3 Simulators

3.6 VSimRTI Cellular Simulator

3.6.2 Installation
This simulator does not need to be installed. It is delivered as part of the VSimRTI-installation package.

3.6.3 Configuration
We provide a cellular configuration file in the example scenarios of Tiergarten and Barnim. Please note
that in the default configuration of this scenario the Cellular Simulator is deactivated. To activate the
cellular simulator just add

< federate id = " cell2 " active = " true " / >

to the vsimrti_config.xml (or, if this line already exist, make sure ’active’ is set to ’true’). With
this done you now can deactivate all network simulators if only cellular simulation is intended in the
investigated scenario. However, it is also possible to use multiple communication technologies (of ad hoc
and cellular) in a hybrid scenario.
The central configuration for the cellular simulator in the file

vsimrti/scenarios//cell2/cell2_config.json could look like this:
{
" debug Ge o ca st i ng " : false ,
" visua l i z e R e g i o n s " : true ,
" n e t w o r k C o n f i g u r a t i o n F i l e " : " network . json " ,
" r e g i o n C o n f i g u r a t i o n F i l e " : " regions . json "
}

The visualizeRegions-option from the cell2_config.json is used to write a KML-file that visualizes the
used cell regions. Google Earth can be used to display it.
The configuration for the global network in the cellular simulator in the file

vsimrti/scenarios//cell2/network.json could look like this:
{
# global region has no area
" globalRegion " : {
" uplink " : {
" delay " : {
" type " :
" delay " :
" prpl " :
0,
" retries " :
2
}
" capacity " :
},
" downlink " : {
" unicast " : {
" delay " : {
" type " :
" delay " :
" prpl " :
" retries " :
}
},
" multicast " : {
" delay " : {
" type " :

definition ( is the default region )

" ConstantDelay " ,
100 ,

28000000

" ConstantDelay " ,
50 ,
0,
2

" ConstantDelay " ,

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

37

3 Simulators

3.6 VSimRTI Cellular Simulator

" delay " :
" prpl " :
},
" us ableCa pacit y " :
},
" capacity " :

100 ,
0
0.6
42200000

}
}

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 comment before the globalRegion option.

Delay regions

Additionally the user has the option to define regions with individual delays. This can be used to simulate
areas with bad reception, crowded areas etc.
The regions should be stored in vsimrti/scenarios//cell2/regions.json. An
example definition for a single region called Ernst-Reuter-Platz could look like this:
{
" regions " : [
{
" id " : " Ernst - Reuter - Platz " ,
" area " : {
" nw " : { " lon " :13 .3249 , " lat " :52 .5131 } ,
" se " : { " lon " :13 .3273 , " lat " :52 .5125 }
},
" uplink " : {
" delay " : {
" type " :
" SimpleRandomDelay ",
" steps " :
4,
" minDelay " :
50 ,
" maxDelay " :
200 ,
" prpl " :
0.8 ,
" retries " :
2
},
" capacity " :
28000000
},
" downlink " : {
" unicast " : {
" delay " : {
" type " :
" SimpleRandomDelay ",
" steps " :
3,
" minDelay " :
100 ,
" maxDelay " :
200 ,
" retries " :
2
}
},
" multicast " : {
" delay " : {
" type " :
" SimpleRandomDelay ",
" steps " :
3,
" minDelay " :
120 ,
" maxDelay " :
220 ,
" prpl " :
0.8
},
" us ableCa pacit y " :
0.6
},
" capacity " :
42200000
}

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

38

3 Simulators

3.6 VSimRTI Cellular Simulator

}
]
}

Note that nw represents the upper-left (north-west) point of the rectangle and se the lower-right (southeast). For further information about the possible options, please refer to the VSimRTI API documentation.
The actual configuration of the uplink and the downlink modules for each region exhibits the identical
format as configuration of the globalRegion in the network.json.
When no regions are found, or if a node (a vehicle) is not within a specified region, the globalRegion
defined in the network.json-File will be used as the delay model.

Transmission simulation

One of the most important feature of the cellular simulator is an estimation of the delay experienced
through the transport over the cellular network.
The cellular simulator offers various modes to estimate the delay of the transmissions. The type of
estimation is specified with by delayType for the uplink and downlink for each region.
• delay.type = ’ConstantDelay’: The message is transmitted with the latency being exactly
equal to delay.
• delay.type = ’SimpleRandomDelay’: The latency can assume different (randomly generated
and uniformly distributed) values between minDelay and maxDelay. The number of different
values is determined by steps.
• delay.type = ’GammaRandomDelay’: A gamma distribution is used to estimate the latency, with
α = 2 and β = 2. The minimum delay minDelay is added to the result. The curve is fitted so that the
maximum likelihood for the delay is exactly equal to expDelay.
• delay.type = ’GammaSpeedDelay’: This mode closely resembles the GammaRandomDelay.
Additionally, a penalty for the velocity with which the node is moving is calculated. This penalty
is then added to the original delay. The GammaRandomDelay and the GammaSpeedDelay are
derived from a measurement campaign during a research project at the DCAITI.
The two different modes for the downlink are unicast and multicast which are configured separately.
Multicast aims to simulate the features of Multimedia Broadcast Multicast Service (MBMS). The main
difference in terms of the transmission for unicast and multicast is the handling of undeliverable messages.
For unicast, the options prpl and retries are used. Pr is short for packet retransmit and denotes the
probability for a failed delivery and a subsequent retransmit. The maximum number of retries for
the retransmit is configured through the retries-option. The probability of a successful retransmit is
recalculated on every try.
In case of multicast the prpl is used as packet loss rate. The value is factored into the delay calculation. In
contrast to the unicast, just one transmission attempt is made for multicast.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

39

3 Simulators

3.6 VSimRTI Cellular Simulator

3.6.4 Operation
Beside the transmission simulation, the Addressing and Routing is the other important aspect of the
Cellular Simulator. This task is enabled by the Geocaster.
The Geocaster evaluates the message headers for cellular messages, which are created by the communicating applications in the Application Simulator.
It supports the following addressing and casting schemes.
CellTopocast is the normal unicast, where the Geocaster simply resolves the single receiver via the

IPResolver. Hence, the CellTopocast directly routes the message further. Currently, Topocast doesn’t
allow broadcast or anycast addresses, but any transmission protocols (tcp, udp).
CellGeoUnicast addresses every node in the destination area is individually. In this way it takes a

geographic address and results in a loop to generate multiple unicasts.
CellGeoBroadcast, which is basically MBMS, uses one broadcast to all nodes in the destined regions.

The MBMS uses the different transmission mode of multicast in the downlink. CellGeoUnicast as
well as CellGeoBroadcast require broadcast, but don’t allow tcp (as ack for broadcasts is denied).

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

40

3 Simulators

3.7 VSimRTI Simple Network Simulator

3.7 VSimRTI Simple Network Simulator
As well as the network simulators OMNeT++ and ns-3, the VSimRTI built-in Simple Network Simulator
(SNS) aims at simulating ad hoc communication for V2X scenarios. In contrast to the other simulators,
SNS is already bundled with VSimRTI and can be used directly out off the box, and due to Java language,
in an operating system independent way.
SNS implements abstract communication models to support the following important communication
principles for V2X applications:
TopoCast currently implemented as Singlehop Topocast, to communicate either to all or an individual

destination node in the direct communication range of the sender.
GeoCast to communicate, similar to Georouting, to nodes in a certain geographic destination area,

with the options of unicast (to address one node), broadcast (to address all nodes) and anycast (to
address the first one of all reachable nodes).
SNS does not implement a full featured IEEE 802.11p communication stack, as the other simulators could
do. It does not consider particular detailed properties of the communication, e.g. signal fading models,
PHY Layer reception, MAC Layer scheduling, detailed Geo Routing protocols etc. Due to this, SNS is an
interesting alternative several reasons and suited for users aiming for quick and easy use without the
need of detailed models.
However, when detailed communication charactersitcs need to be considered, the other simulators are
the better choice.

3.7.1 sns-ambassador folder structure
The SNS can be configured via the sns_config.json which can be found within the scenarios folder
structure:


sns
sns_config.json

.......................................... SNS configuration file
Figure 3.10: sns-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 SNS configuration basically consists of the two components for singlehop (direct Topocast) and
multihop (Georouting) transmission. Each of these transmission modes base on the delay configuration,
which is already known from the Cell2 Simulator (3.6).

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

41

3 Simulators

3.7 VSimRTI Simple Network Simulator

The singlehop component additionally includes the singlehop radius, which actually is the direct communication range of the sender - meaning that all nodes within this distance can successfully receive the
according message. In the context of the fundamental Freespace Model, which is implemented by the
classic network simulators OMNeT++ and ns-3 this value results from the carrier frequency, transmission
power, receiver sensitivity and antenna properties (gains) etc. Additionally, the delay supports the value
for packet retransmission and packet loss (prpl), which allows the simulation of packet errors within
the communication range. However, in contrast to fading models as the Rayleigh or Rice Fading, the
simulated packet errors in SNS are distributed uniformly over the whole communication range and do
not, for instance, increase with higher distances (which would be more realistic.
The multihop component only consists of the delay configuration including the value for prpl and
according transmission retries. In this case, the destined communication area is determined by the
dissemination area in the GeocastDestinationAddress.
An example definition for SNS, with relatively short delays in the order of microseconds or low milliseconds for direct singlehop and slightly higher delays for multihop could look like this:
{
" version " : " 0.16.0 " ,
" singlehop " : {
" _singlehop radius in m " : 0 ,
" radius " :
509.4 ,
" _delay config according to vsimrti - communication " : 0 ,
" delay " : {
" type " :
" SimpleRandomDelay ",
" steps " :
5,
" minDelay " :
0.4 ,
" maxDelay " :
2.4 ,
" prpl " :
0,
" retries " :
0
}
},
" multihop " : {
" _delay config according to vsimrti - communication " : 0 ,
" delay " : {
" type " :
" GammaRandomDelay ",
" minDelay " :
10 ,
" expDelay " :
30 ,
" prpl " :
0,
" retries " :
2
}
}
}

3.7.4 Operation
The individual steps of operation for the two modes of Topocast (direct singlehop) and Geocast (georouting with multihop) transmission are as following.

Simulation of direct singlehop transmission

1. get transmission radius from configuration (to simulate tx power, carrier frequency and antenna
properties etc.)

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

42

3 Simulators

3.7 VSimRTI Simple Network Simulator

2. determine potential receiver nodes in the sending radius (without original sender)
3. calculate equal delay for all nodes
4. simulate successful message transmission (via prpl) for each node

Simulation of geocast routing transmission

1. get destination area from geocast header in message (to simulate georouting)
2. determine potential receiver nodes in the destination area (including original sender due to rebroadcasting in geocast)
3. calculate specific delay for each node
4. simulate successful message transmission (with packet loss and possible retransmissions via prpl)
for each node

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

43

3 Simulators

3.8 VSimRTI Eventserver

3.8 VSimRTI Eventserver
3.8.1 eventserver-ambassador folder structure
This ambassador can be configured with a configuration file. The specific path is

vsimrti/scenarios//eventserver/eventserver_config.json

eventserver .....................................................................
eventserver_config.json .......................... Eventserver configuration file
Figure 3.11: eventserver-ambassador folder structure

3.8.2 Installation
This simulator does not need to be installed. It is delivered as part of the VSimRTI-installation package.

3.8.3 Configuration
Notice: The documentation for the VSimRTI specific component is freely available on
the DCAITI website , explaining all available options.
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.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

44

3 Simulators

3.9 VSimRTI Battery Simulator

3.9 VSimRTI Battery Simulator
3.9.1 battery-ambassador folder structure
This ambassador can be configured with a configuration file. The specific path is

vsimrti/scenarios//battery/battery_config.json

battery ..........................................................................
battery_config.json .............................. ambassador configuration file
Figure 3.12: battery-ambassador folder structure

3.9.2 Installation
This simulator does not need to be installed. It is delivered as part of the VSimRTI-installation package.

3.9.3 Introduction
The VSimRTI Battery Simulator is used to simulate electric vehicles. It takes environment, vehicle
characteristics and the battery itself into account. The main feature of the battery ambassador is that it
can utilize dynamic class loading to use a battery model provided by the user, depending on the given
needs. This also holds true for the environment model and the vehicle model. However, simple models
for vehicle, environment and the battery are provided and will be briefly explained in the following
sections.

3.9.4 Vehicle model
The vehicle model holds the general properties of a vehicle. Examples would be the weight of the vehicle
and the voltage at which the electric engine operates. However, as with the other models, the provided
class for the vehicle model direct affects what can be configured here. If other properties are needed for
the vehicle, this is the right place to put them. To implement an own vehicle, the class AVehicleModel
has to be extended.

3.9.5 Battery model
The battery model defines the battery used by the vehicle itself. Useful properties could be the number
of cells and their capacity. As with the vehicle, this class can be freely defined and use configuration
values placed in the batteryModelConfig-area. To implement an own battery model, the class ABat-

teryModel needs to be extended.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

45

3 Simulators

3.9 VSimRTI Battery Simulator

3.9.6 Environment model
Normally environmental factors like rolling resistance of the given underground or air drag go into this
section. At the current state, just a minimal environment model is bundled with the battery ambassador,
mainly to show what is possible. To implement a custom environment model, AEnvironmentModel has
to be extended.

3.9.7 Sample configuration
{
" v eh icl e M o d e l C l a s s " : " com . dcaiti . vsimrti . fed . battery . sim . models . vehicle . ElectricSmart " ,
" ve h ic l e M o d e l C o n f i g " : {
" Mass " : 1060 ,
" ReferenceArea " : 1.95 ,
" Dr a gC oe f fi ci e nt " : 0.375 ,
" T a n k T o W h e e l E f f i c i e n c y " : 0.7 ,
" 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 ,
" 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
},
" b at ter y M o d e l C l a s s " : " com . dcaiti . vsimrti . fed . battery . sim . models . battery . ⤦
Ç VerySimpleBatteryModel ",
" ba t te r y M o d e l C o n f i g " : {
" NumberOfCells " : 93 ,
" CellVoltage " : 4.3 ,
" C e l l C a p a c i t y I n A h " : 50 ,
" eff_Summer " : 0.8448 ,
" Re chargi ngType " : 2 ,
" MinSOC " : 0.30 ,
" MaxSOC " : 0.70
},
" e n v i r o n m e n t M o d e l C l a s s " : " com . dcaiti . vsimrti . fed . battery . sim . models . environment . ⤦
Ç DefaultEnvironment ",
" environmentModelConfig ": {
" Gravity " : 9.81 ,
" FluidDensity " : 1.293 ,
" 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
},
" consumers " : [ { " Radio " : 10 } , { " HeadLight " : 100 } ]
}

This listing shows how the vehicle, environment and battery model classes for the bundled models are
configured. Additionally, an arbitrary number of consumers can be configured that draw additional
power from the battery. In this case, headlights and a radio are pre-defined.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

46

4 Tutorial Tiergarten
This tutorial aims to provide a general overview of the VSimRTI application concept and shows two
examples that involve ad hoc communication via IEEE 802.11p between different participants and
message passing from one application to another that run on the same vehicle. Additionally, a short
introduction will be given on Traffic Lights, with a more in-depth description following in Chapter 6. The
tutorial is split up into five main parts:
1. How to equip a vehicle with one or more applications. This process is called mapping.
2. An example application that shows how to implement communication between different vehicles
via a wireless ad hoc network.
3. The next part of the tutorial shows how to accomplish message passing between two applications
that run on the same vehicle.
4. An overview of the traffic light application and a summary about what can be done with the traffic
light from within the application.
5. The last part of the tutorial shows how to retrieve the results of a simulation run.
The scenario itself consists of three vehicles that drive down a road in consecutive order and pass a Road
Side Unit (RSU) that emits messages in a fixed interval. The vehicles will receive the messages from the
RSU as soon as they are in communication range. After completing this tutorial the reader should be

Figure 4.1: Overview of Tiergarten tutorial scenario

able to deploy own applications according to his needs and make use of ad hoc communication among
vehicles and intra-vehicle communication among applications on the same vehicle. The VSimRTI cell
simulator that is used to simulate cellular network communication will be covered in tutorial 2.

4 Tutorial Tiergarten

4.1 Mapping Configuration

4.1 Mapping Configuration
In order to use applications they have to be assigned (mapped in VSimRTI terminology) to a simulation
entity. In this tutorial, we will assign applications to a RSU that is placed along the road (the red symbol
in picture 4.1) and to the vehicles. In order to do this the following steps are necessary:
1. Navigate to the mapping3 folder of the tiergarten tutorial scenario.
2. Edit the mapping_config.json to let it point to the correct classes for your application, define
prototypes and to add entities to the simulation.
The mapping is already configured correctly, so we will continue with a description of the important parts
of the mapping configuration.

Prototype Section

This section contains the properties of the simulated entities, including their applications. You can, for
example, configure the maximum speed and the length of a vehicle. Normally, the default values are fine
here. In order to map one or more applications you have to fill in the complete class identifier including
the package in the applications array. In this tutorial, we have mapped two applications to the vehicles
and one application to the RSU.
Mapping for the vehicles:

"applications":["com.dcaiti.vsimrti.app.tutorials.tiergarten.TiergartenVehicle",
"com.dcaiti.vsimrti.app.tutorials.tiergarten.TiergartenVehicleSlave"]
Mapping for the RSU:

"applications":["com.dcaiti.vsimrti.app.tutorials.tiergarten.TiergartenRSU"]
In order for VSimRTI to be able to locate these classes, the resulting .jar archive should be placed in
the applicationNT folder of your scenario. For our tutorial we have packaged the needed classes

TiergartenVehicle, TiergartenVehicleSlave and TiergartenRSU into one .jar file. However, this
isn’t a strict requirement. What these classes actually do and how they are implemented will be covered
in the next two parts of this tutorial.

Vehicle and RSU sections

This part of the mapping is used to actually bring entities like vehicles and RSUs into the simulation. For
example, we placed the RSU that is equipped with the TiergartenRSU application at the specific geo
coordinate with latitude = 52.5130607 and longitude = 13.328910. Usually, this and the mapping of its
application is all that is necessary to make use of an RSU. For this tutorial we go with just one RSU but
analogous to adding multiple vehicles we could also add more of them if the need arises.
Spawning vehicles is a little bit more complex than adding a RSU. Vehicles are configured as groups from
which we have three in this tutorial scenario. Exemplary, we will describe one of these groups in more
detail:

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

48

4 Tutorial Tiergarten

4.2 Inter-Vehicle Communication

" vehicles " : [
{
" startingTime " :1 .0 ,
" route " :0 ,
" max N u m b e r V e h i c l e s " :1 ,
" types " : [{ " name " : " PKW " }]
},
...
]
Listing 4.1: Example Vehicle Group

• startingTime: Defines at which second the vehicle is spawned, in this case one second after the
beginning of the simulation.
• route: Describes which route these vehicle group should use. For now it is sufficient to know that
there is one route with the id 0 that leads the vehicles near the RSU that is already defined in this
tutorial scenario.
• maxNumberVehicles: Used to determine how many vehicles should be in that group. Here, we go
with just one single vehicle.
• types: This array maps to the defined PKW (german for passenger car) prototype from the proto-

types-section of the mapping.

4.2 Inter-Vehicle Communication
This second part describes the TiergartenVehicle and TiergartenRSU applications which are used
for inter-vehicle communication in more detail. As a coarse overview, the TiergartenRSU application
sends out a defined message at a fixed interval. These messages are received and written to the log file by
the TiergartenVehicle application. First, we start off with the class definition and will run through the
methods we have to implement in order to get the communication working.

Class definition
public class T i e r g a r t e n V e h i c l e extends AbstractApplication < VehicleOperatingSystem > implements ⤦
Ç VehicleApplication , C o m m u n i c a t i o n A p p l i c a t i o n
Listing 4.2: TiergartenVehicle: Class definition for a vehicle application

In general, every vehicle application will extend the AbstractApplication abstract class with the VehicleOperatingSystem type parameter. The VehicleOperatingSystem is the main way to interact with the
underlying vehicle and gives a wide array of functionality to the user. Also, depending on the needs of the
application, several interfaces have to be implemented. For our scenario we implement VehicleAppli-

cation to denote that the application is intended to run on a vehicle and CommunicationApplication
to be able to use the actual communication facilities we need for this tutorial. In general, it makes sense to
let the IDE generate the bodies of the methods that need implementation and fill them with functionality
if needed or letting them empty otherwise.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

49

4 Tutorial Tiergarten

4.2 Inter-Vehicle Communication

Application initialization

During the initialization procedure of communicating applications, the communication modules (WLANModule or CellModule) need to be activated. For example, activating the WLAN module can be achieved
with the following code snipped:
@Override
public void setup () {
getLog () . infoSimTime ( this , " Initialize application " ) ;
g et O pe r a t i n g S y s t e m () . getAd HocMod ule () . enable ( new A d H o c M o d u l e C o n f i g u r a t i o n ()
. addRadio () . channel ( AdHocChannel . CCH ) . power (50) . create ()
);
getLog () . infoSimTime ( this , " Activated AdHoc Module " ) ;
}
Listing 4.3: TiergartenVehicle activate WLAN module

Since we want to communicate over ad hoc Wifi we have to turn on the Wifi-module of the car. Here
you can specify the mode of operation. The first argument says if the vehicle should be able to receive
messages, how strong the Wifi antenna is (50mW in this case) and which ad hoc channel to use.
Note: The honoring of these arguments depends on the underlying network simulator. Currently, ns-3
and OMNeT++ make use of these arguments.

Receiving the V2X messages
In order to act upon received messages from other simulation entities, the receiveV2XMessage from the

CommunicationApplication interface is used. In our tutorial scenario we don’t do something special
upon message receiving and just write the name of the sender into the log file.
@Override
public void r e c e i v e V 2 X M e s s a g e ( R e c e i v e d V 2 X M e s s a g e r e c e i v e d V 2 X M e s s a g e ) {
getLog () . infoSimTime ( this , " Received V2X Message from {} " ,
r ec e iv e d V 2 X M e s s a g e . getMessage () . getRouting () . g e t S o u r c e A d d r e s s C o n t a i n e r () . getSourceName () ) ;
}
Listing 4.4: TiergartenVehicle: Class definition for a vehicle application

This is basically all it takes to receive messages from another simulation entity. Normally, the application
author uses an own message class that derives from V2XMessage and casts it to his specific class in order
to handle messages easier.

Sending the V2X messages
Since the receiving application is now set up we move on to the sending side of this tutorial. The sending
takes place from the RSU via a broadcast, so every vehicle in transmission range will receive the message
sent by it. Picture 4.2 shows the communication range of the RSU which is dependent from the settings in
the communication simulator. The actual sending takes place in the TiergartenRSU application which
is equipped to the RSU via the mapping configuration.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

50

4 Tutorial Tiergarten

4.2 Inter-Vehicle Communication

Figure 4.2: Example of RSU communication range

ApplicationNT event model

In order to send messages at a fixed interval we make use of the event based model of the VSimRTI
application simulator. A high level description in what we need to do in order to send messages at a
specific interval can be summarized as follows:
1. Line up an event every X seconds. For this tutorial an interval of two seconds was chosen.
2. Once the event gets processed in the processEvent()-method the actual sending of the message
will be triggered.
3. All information necessary for the sending will be assembled in sendAdHocBroadcast() and the
message gets actually sent out.

Application Setup
@Override
public void setUp () {
getLog () . infoSimTime ( this , " Initialize application " ) ;
g et O pe r a t i n g S y s t e m () . getA dHocMo dule () . enable ( new A d H o c M o d u l e C o n f i g u r a t i o n ()
. addRadio () . channel ( AdHocChannel . CCH ) . power (50) . create ()
);
getLog () . infoSimTime ( this , " Activated WLAN Module " ) ;
sample () ;
}
Listing 4.5: TiergartenRSU: Setup for the RSU application

The setup for the RSU is the same as for the vehicle where we activate the Wifi module. Additionally, the

sample() method gets called which is responsible for the events.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

51

4 Tutorial Tiergarten

4.2 Inter-Vehicle Communication

Event scheduling

The next step is to line up the event at the interval we desire. The method we use for that, sample(),
looks like this:
public void sample () {
final Event event = new Event ( g e t O p e r a t i n g S y s t e m () . g e t S i m u l a t i o n T i m e () + TIME_INTERVAL , ⤦
Ç this ) ;
g et O pe r a t i n g S y s t e m () . g e tE ve n tM an a ge r () . addEvent ( event ) ;
getLog () . infoSimTime ( this , " Sending out AdHoc broadcast " ) ;
s en d Ad H o c B r o a d c a s t () ;
}
Listing 4.6: TiergartenRSU: Event sampling

Here, an Event is created which will be received at the current time in simulation plus the defined interval
which is set to two seconds. The second argument for the event creation is a reference to the originating
class instance. For our tutorial, the this reference is sufficient here. After we created the event, it is added
to the event queue via addEvent() which will result in a call to processEvent() at the given interval.

Message sending

After we made sure the method that does the actual sending of the message is called at the specified
interval, we take a closer look at the sendAdHocBroadcast() method we defined in the TiergartenRSU
class:
private void s e n d A d H o c B r o a d c a s t () {
final T o p o c a s t D e s t i n a t i o n A d d r e s s tda = T o p o c a s t D e s t i n a t i o n A d d r e s s . g e t B r o a d c a s t S i n g l e H o p ⤦
Ç () ;
final D e s t i n a t i o n A d d r e s s C o n t a i n e r dac = D e s t i n a t i o n A d d r e s s C o n t a i n e r . ⤦
Ç c r e a t e T o p o c a s t D e s t i n a t i o n A d d r e s s A d H o c ( tda ) ;
final Me ssageR outing routing = new Mes sageRo uting ( dac , g e t O p e r a t i n g S y s t e m () . ⤦
Ç g e n e r a t e S o u r c e A d d r e s s C o n t a i n e r () ) ;
final In t er Ve h ic le M sg message = new In t er Ve h ic le M sg ( routing , g e t O p e r a t i n g S y s t e m () . ⤦
Ç getPosition () ) ;
g et O p e r a t i n g S y s t e m () . getAd HocMod ule () . sen dV2XMe ssage ( message ) ;
}
Listing 4.7: TiergartenRSU: Event sampling

We step through this method line by line and explain what each statement does:
1. The destination address for this method is constructed in the first line. We use the helper-method

getBroadcastSingleHop() to denote that we want to send a single hop broadcast.
2. After that, we wrap the destination address in a container that is created via createTopocastDes-

tinationAddressAdHoc(). Since we use ad hoc wifi for this tutorial this method will suffice.
3. The next step is to create the routing for the message. The routing basically ties together a destination address and a source address. We use the destination address we created in the first two
lines and use the default source address that can be created with the generateSourceAddress-

Container() method.
4. The last step in crafting the message is to create an instance of our custom message class InterVe-

hicleMsg. The actual payload is the position of the sender, other payloads are possible depending
on the requirements of the application.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

52

4 Tutorial Tiergarten

4.3 Intra-Vehicle Communication

5. The message is sent out using the sendV2XMessage()-method that is provided by the operating
system.
These steps conclude the sending of the message. The procedure is the same for sending messages from
a vehicle instead of a RSU.

4.3 Intra-Vehicle Communication
This part of the tutorial describes the steps necessary for letting two applications to communicate with
each other on the same vehicle. Here, we use the TiergartenVehicle application as the sender and

TiergartenVehicleSlave as the receiver. In general, the approach is similar to the sending of a V2X
message and also makes use of the event system.

Message sending

First, we start off with the sending side. The event code should look familiar:
@Override
public void a f t e r U p d a t e V e h i c l e I n f o () {
final List  applications = g e t O p e r a t i n g S y s t e m () . g e tA pp l ic at i on s () ;
final In tr a Ve h ic le M sg message = new In tr a Ve h ic le M sg ( g e t O p e r a t i n g S y s t e m () . getId () ,
random . nextInt ( MAX_ID ) ) ;
for ( Application application : applications ) {
final Event event = new Event ( g e t O p e r a t i n g S y s t e m () . g e t S i m u l a t i o n T i m e () + 1 , application ⤦
Ç , message ) ;
this . g e t O p e r a t i n g S y s t e m () . g et E ve n tM an a ge r () . addEvent ( event ) ;
}
}
Listing 4.8: TiergartenVehicle: Sending intra application message

One noteworthy thing is that we use the afterUpdateVehicleInfo()-method to line up a new event.
This method is called automatically if the vehicle info (for example, speed or heading) gets updated,
which usually takes place at every time step of the simulation.
The general approach works like this:
1. Get a list of all applications that run on the vehicle using getApplications().
2. Create a new message. Here we use our own custom message called IntraVehicleMsg which
takes an randomly generated id and the name of the vehicle as payload. Again, this is for tutorial
purposes and could be anything.
3. After that we iterate over every applications that runs on the vehicle, in this case two: Tiergarten-

Vehicle and TiergartenVehicleSlave.
4. Then, an event is constructed for each app running on the vehicle and added to the event queue
the same way as in the inter-vehicle example.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

53

4 Tutorial Tiergarten

4.3 Intra-Vehicle Communication

Receiving the message

The actual receiving of the message takes place in the TiergartenVehicleSlave application. Since the
intra vehicle messages are basically treated as an event, the code is straight forward here:
@Override
public void processEvent ( Event event ) throws Exception {
Object resource = event . getResource () ;
if ( resource != null && resource instanceof Int raVehi cleMs ) {
final In tr a Ve h ic le M sg message = ( In t ra Ve h ic l eM sg ) resource ;
if ( message . getOrigin () . equals ( g e t O p e r a t i n g S y s t e m () . getId () ) ) {
getLog () . infoSimTime ( this , " Received message from another application " ) ;
}
}
}
Listing 4.9: TiergartenVehicleSlave: Receiving intra application message

The general concept here is that the payload is wrapped as an object in the actual event. The procedure
here is as follows:
1. Retrieve the resource from the event using getResource()
2. Check if there is actually some kind of payload
3. Make sure the payload is of the expected type
4. Cast the payload to an actual class and do something with it.

4.3.1 The traffic light application
As can be seen in the mapping configuration there is an additional prototype defined for traffic lights:
{
" applications " : [ " com . dcaiti . vsimrti . app . tutorials . tiergarten . trafficLight . ⤦
Ç T ra ff i cL ig h tA p p " ] ,
" name " : " TrafficLight "
}
Listing 4.10: Traffic Light Prototype

These prototype is used to map the referenced application onto two specific traffic lights, as shown in the
following listing.
tls " : [
{
" tlName " : " 27011311 " ,
" name " : " TrafficLight "
},
{
" tlName " : " 252864801 " ,
" name " : " TrafficLight "
}
]
Listing 4.11: Traffic Light Mapping

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

54

4 Tutorial Tiergarten

4.4 Interpretation of simulation results

The use case shown for tutorial purposes here is simple: The two traffic lights referenced in the mapping
default to always red. Their application then waits for a V2X message with a “secret” payload in it (the

GreenWaveMsg) and switches the traffic light program to always green upon receiving that message. The
application mapped onto the traffic light then switches back to its previous program after 20 simulation
time steps have passed. An in-depth explanation of traffic light functionality can be found in Chapter 6.

4.4 Interpretation of simulation results
The last part of the tutorial describes how to retrieve the actual simulation results. For this tutorial, the
results are quite simple and simply show the arrival of the Inter- and IntraVehicle messages. So after
executing the simulation using the following command:
./ vsimrti . sh -u < user > -s Tiergarten
Listing 4.12: Running the simulation with the Tiergarten scenario (Unix machine)

vsimrti . bat -u < user > -s Tiergarten
Listing 4.13: Running the simulation with the Tiergarten scenario (Windows machine)

Afterwards, in the log directory of VSimRTI a new folder should be created containing all log files of the
simulation run. Within, the sub-folder appsNT contains the log files for each simulation unit and its
application. For example, for the vehicles we end up with two log files: TiergartenVehicle.log and

TiergartenVehicleSlave.log.
This following snippet shows the receiving of the V2X messages that were sent by the RSU:
INFO
INFO
INFO
INFO

-

Initialize application ( at simulation time 6.000 ,000 ,000 s )
Activated AdHoc Module ( at simulation time 6.000 ,000 ,000 s )
Received V2X Message from rsu_0 ( at simulation time 18.000 ,400 ,000 s )
Received V2X Message from rsu_0 ( at simulation time 20.000 ,400 ,000 s )
Listing 4.14: Snippet from TiergartenVehicle.log

Next, we see the contents of the IntraVehicleMessage that originates from another app on the vehicle:
INFO
INFO

- Initialize application ( at simulation time 2.000 ,000 ,000 s )
- Received message from another application: I n tr aV e hi cl e Ms g { origin = ’ veh_0 ’ , id =631} ...
Listing 4.15: Snippet from TiergartenVehicleSlave.log

The following log was generated by the RSU application and logs the sending of each ad hoc broadcast:
INFO
INFO
INFO
INFO

-

Initialize application ( at simulation time 0.000 ,000 ,000 s )
Activated WLAN Module ( at simulation time 0.000 ,000 ,000 s )
Sending out AdHoc broadcast ( at simulation time 0.000 ,000 ,000 s )
Sending out AdHoc broadcast ( at simulation time 2.000 ,000 ,000 s )
Listing 4.16: Snippet from TiergartenRSU.log

This concludes the first tutorial and hopefully gave an idea on how to use the VSimRTI application
simulator to send out and receiving messages to other simulation entities or inside the same vehicle.
The OperatingSystem.log files do not contain specific application output and is mainly used for
debugging purposes and won’t be discussed in this tutorial.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

55

5 Tutorial Barnim
The following tutorial shows some of the more advanced features of VSimRTI and will take a closer look
at different federates. The term federates describes the High Level Architecture and basically denotes a
dedicated simulator with whom the simulation infrastructure can communicate. The following topics
will be covered in this tutorial:
• How to use and react to DENMs Decentralized Environmental Notification Message.
• Enabling and using a different communication simulator on the basis of the VSimRTI cell simulator.
• The integration of electric mobility aspects into a simulation.
Note: The topics from the last tutorial, especially how to map applications and the basics of how to
implement them are not covered in this tutorial. If you are not yet familiar with these concepts you should
have a look at the preceding tutorials.

5.1 Overview
The scenario used for this tutorial is more complex than the Tiergarten tutorial; thus, we will provide you
a short explanation. Picture 5.1 shows an overview of the Barnim scenario, exhibiting an icy road section
along the highway.

Figure 5.1: Overview of Barnim tutorial scenario

5 Tutorial Barnim

5.2 Mapping configuration

In this scenario, several cars drive on the blue route and are forced to slow down in a specific section due
to icy conditions. The rest of the scenario can be described as follows:
1. A car (Car A) which is equipped with ad hoc communication (WiFi) capabilities detects an environmental hazard - in this case an icy section of the road.
2. Car A now sends out a DENM which reaches other cars in its (relatively small) dissemination area.
With multi hop routing, the DENM message is transported upstream towards other vehicles.
3. Cars that do not have any form of communication equipment are not warned and drive towards
the icy part of the road. Since they have careful and responsible drivers they slow down to avoid
accidents.
4. Cars that are equipped with the appropriate communication equipment are able to receive the
DENM, which induces them to use a different route (green) which is safer and faster due to the lack
of ice on it.
5. Last but not least, the WeatherServer (technically implemented as an RSU) propagates information
over the cellular network and could therefore be located virtually everywhere.
We also have some electric vehicles here, mainly to demonstrate how the VSimRTI battery ambassador
works. Later in this tutorial, we will show you how to access statistics such as the state of charge of the
battery from within an application.

5.2 Mapping configuration
This section gives a short explanation of the mapping we use in this scenario. First of all we use five
different types of entities. One RSU which acts as the WeatherServer and four types of cars, each of
them loaded with different applications. As usual, the configuration takes place in mapping3/mapping_-

config.json in your scenario folder.
1. Normal vehicles which cannot communicate shall demonstrate how to use electric vehicles in
a scenario (60% of all vehicles). They are only equipped with the com.dcaiti.vsimrti.app.

tutorials.barnim.SlowDownApp-application which induces them to reduce their speed as soon
as their onboard sensors detect hazardous conditions. After leaving the hazardous area, they will
resume by increasing their speed again.
2. Vehicles equipped with ad hoc wifi. They might not be able to receive the DENM due to
range limitations and drive into the icy section nonetheless. They are equipped with the

com.dcaiti.vsimrti.app.tutorials.barnim.WeatherWarningApp-application and the com.
dcaiti.vsimrti.app.tutorials.barnim.SlowDownApp-application (20% of all vehicles).
3. Cellular communication enabled vehicles which are able to communicate with the WeatherServer. These vehicles are equipped with the com.dcaiti.vsimrti.app.tutorials.barnim.

WeatherWarningAppCell-application, which is a specialized form of the normal weather warning application that can make use of cellular communication. They are also equipped with the

com.dcaiti.vsimrti.app.tutorials.barnim.SlowDownApp-application (10% of all vehicles).

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

57

5 Tutorial Barnim

5.3 VSimRTI configuration

4. Electric vehicles cannot communicate since they are only equipped with the com.dcaiti.

vsimrti.app.tutorials.barnim.SlowDownApp-application. Apart from that, they also incorporate an electrical battery which empties during driving (10% of all vehicles).
5. The WeatherServer is only equipped with cellular equipment. Despite the greater distance it is able
to warn vehicles that can also make use of cellular communication.

5.3 VSimRTI configuration
Since several applications are mapped, we need to make sure that the corresponding simulators are
enabled. This is done in the main VSimRTI configuration file that resides in vsimrti/vsimrti_con-

fig.xml in your scenario. The last part of that configuration file is used to enable and disable certain
simulators according to the needs of the user.
Per default, any simulation of cellular communication is disabled. In order to enable communication via
cellular networks in this scenario, you need to enable the cell2 simulator by setting the field active to

true:

< federate id = " cell2 " active = " true " / >
Listing 5.1: VSimRTI configuration for barnim example scenario

5.4 Applications
This section deals with the specific details of the WeatherWarningApplication. We will cover in particular how to enable and use cellular communication, how to react to DEN-Messages and how the user can
achieve a re-routing of vehicles.

Overview

Here we will explain the application logic and the main ideas behind it in general terms and will go
into the implementation details in the following sections. All of the subsequent points stay the same
regardless of what form of communication is used.
• If the sensor picks up an event, the vehicle sends out a DEN-message (via cellular communication
or ad hoc) with the position that was recorded in order to warn other vehicles.
• The application also contains code to react upon DENMs received from other vehicles. Depending
on the configured behavior of the application, either a slow down or a re-routing is performed.
Most of the things that are happening here like re-routing, interval-handling and sending out ad hoc
messages were already covered in the first tutorial and will not be discussed in detail in this tutorial.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

58

5 Tutorial Barnim

5.4 Applications

5.4.1 DEN-Message handling
Receiving

First of all, we look at the receiving side of the DENM here. Since the message is a normal V2X message it
is received through the receiveV2XMessage()-method which is part of the application interface.
if (!( msg instanceof DENM ) ) {
getLog () . info ( " Ignoring message of type : {} " , msg . getClassName () ) ;
return ;
}
Listing 5.2: Testing wether or not message is a DENM

Analogous to a normal message, we check with instanceof, if it is of a type that we are interested in, in
this case DENM. Afterwards, we perform a potential route change if not already done.

Sending

In case the sensor detects an environmental hazard the vehicle sends out a DEN-message to warn
other vehicles. If WeatherWarningAppCell is mapped, cellular communication is used, in case of

WeatherWarningApp ad hoc WiFi is used as described in the Tiergarten tutorial.

5.4.2 Cellular Communication
We will now take a closer look at how the communication via the VSimRTI cellular simulator works.
The application we point to in the mapping is a specialized form of the normal WeatherWarningApplication and can be found under its full identifier com.dcaiti.vsimrti.app.tutorials.barnim.

WeatherWarningAppCell. It overloads the useCellNetwork-method which returns a constant true in
order to indicate that we want to use cellular communication inside the base application. The reason for
this overloading is to provide a distinct class to which we can point in the mapping. The actual logic that
is required to send messages via cell is done in the base WeatherWarning application, so the overloading
just signals that we want to use cellular communication.
The method where the actual sending takes place is called reactOnEnvironmentData(). The following
code snippet shows the steps necessary to send a DEN-message via the cellular network:
GeoCircle dest = new GeoCircle ( v_longLat , 3000) ;
G e o c a s t D e s t i n a t i o n A d d r e s s gda = G e o c a s t D e s t i n a t i o n A d d r e s s . c r ea te B ro ad c as t ( dest ) ;
final D e s t i n a t i o n A d d r e s s C o n t a i n e r dac ;
if ( useCell Netwo rk () ) {
dac = D e s t i n a t i o n A d d r e s s C o n t a i n e r . c r e a t e G e o U n i c a s t D e s t i n a t i o n A d d r e s s C e l l ( gda ) ;
} else {
dac = D e s t i n a t i o n A d d r e s s C o n t a i n e r . c r e a t e G e o c a s t D e s t i n a t i o n A d d r e s s A d H o c ( gda ) ;
}
MessageRou ting mr = new M essage Routin g ( dac , g e t O p e r a t i n g S y s t e m () . g e n e r a t e S o u r c e A d d r e s s C o n t a i n e r ⤦
Ç () ) ;
DENM denm = new DENM ( mr , g e t O p e r a t i n g S y s t e m () . g e t S i m u l a t i o n T i m e () , v_longLat , roadId , type , ⤦
Ç strength , newSpeed , 0.0 f ) ;
g et O pe r at i n g S y s t e m () . getA dHocMo dule () . sen dV2XMe ssage ( denm ) ;
Listing 5.3: Example for sending over cellular networks

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

59

5 Tutorial Barnim

5.5 Conclusion

The sending is the same as in the Tiergarten tutorial, except that we decide via an if-statement whether
or not cellular communication or ad hoc WiFi is used. Note the two different methods - one is ending
with Cell the other with AdHoc, depending on what we want to use in the application.

5.5 Conclusion
This concludes the description of the VSimRTI tutorial scenarios Tiergarten and Barnim. The following
list sums up the things we have covered in this tutorial series:
• Getting a general idea on how to configure VSimrti, especially how to enable and disable different,
coupled simulators.
• How to map different applications to a vehicle or a road side unit
• Achieving inter- and intra-application communication...
• ... via cellular networks or AdHoc wifi
• Receiving and handling of messages
• Basic interaction with the OperatingSystem by means of changing a route
• How to find and process the results of a simulation run with the help of generated log files.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

60

6 Tutorial Traffic Lights
In this brief tutorial we will discuss how to interact with traffic lights via VSimRTI. Usually the position
and the lanes they control are coming from the OpenStreetmap-data, which we will also assume during
this tutorial. Note that this tutorial is intended to be used with the Tiergarten scenario described in the
first tutorial in Chapter 4, so creating a new scenario for is not necessary here and the Traffic Light data is
already exported.
At first we cover the general steps necessary to enable traffic lights and eventually “map” applications
onto them. Each step is described in more detail later on.
1. Tell scenario-convert to export the traffic light information into the database
2. Determine the node ids of the traffic lights which should have applications on them
3. Adjust the mapping configuration of VSimRTI accordingly and assign the desired application(s)
onto one or more traffic lights.
Additional information on how to use traffic lights, how they are modeled within sumo and how their
phases work can be found in the sumo wiki under

http://sumo.dlr.de/wiki/Simulation/Traffic_Lights

6.1 Use scenario-convert to export traffic lights
Although the Tiergarten scenario which we are focusing on in this tutorial already has the traffic lights
exported from the .osm file, this step is important if you desire to set up an own scenario. For the
Tiergarten example, the scenario-convert command line looks like this:
scenario - convert -18.0. jar -- osm2sumo -d tiergarten . db -i tiergarten . osm -l -n
Listing 6.1: Export of traffic lights using scenario-convert

Note the -l switch here that actually exports the traffic light information from the .osm file to the
tiergarten.db database. If this command line switch is omitted the traffic lights will not be available in the
scenario. More information on how traffic lights are handled by Open Streetmap can be found in their
wiki: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals

6 Tutorial Traffic Lights

6.2 Determine the traffic lights that should be equipped with applications

6.2 Determine the traffic lights that should be equipped
with applications
The next step is to decide which traffic lights should have applications on them. Since their ID(s) have to
be referenced in the mapping, we will have to determine them first. There are several ways to do this, e.g.
taking them directly from the database using a tool like sqlitebrowser or extract them directly with a text
editor from the .net.xml file that gets generated by scenario-convert for usage with sumo. However, here
we will focus on a graphical approach using sumo-gui since it is the easiest way to determine the exact
traffic lights we want to map applications too.

Figure 6.1: Locating traffic lights in sumo gui

Figure 6.1 shows how to locate a specific traffic light, or more precise, a traffic light group. The process
is as simple as scrolling to the desired traffic light, right click on it and write down the number behind
tlLogic in the drop down menu or use the copy to clipboard feature of the sumo gui. This id is then used
in the next section which explains how to actually map applications to a traffic light.

6.3 Configure the mapping for traffic lights
Now that we have the ids of the traffic lights we can modify the mapping to assign application(s) to them.
Note that the tutorial scenario already has applications assigned to two arbitrary traffic lights, so the
mapping file bundled with it can also be used as a starting point here. In general, the mapping looks the
same as for vehicles or RSUs. First, we define a prototype that is used for all subsequent traffic lights:
1

{

2

" prototypes " : [
{
" applications " : [ " com . vsimrti . applications . a d d i t i o n a l s a m p l e s . misc . ⤦
Ç TrafficLightExample "],
" name " : " TrafficLight "
}
]

3
4
5
6
7
8

}
Listing 6.2: Protype for traffic light

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

62

6 Tutorial Traffic Lights

6.4 The Traffic Light API

The listing 6.2 shows an additional prototype called TrafficLight that gets associated with the Traffi-

cLightExample application. Note that the application that should run on the traffic light has to extend
AbstractApplication in order to work. The next step is to use
this prototype and assign it to a traffic light we found in the section before using the sumo gui:
1
2
3
4
5
6
7
8
9
10

" tls " : [
{
" tlName " : " 2 7 0 1 1 3 1 1 " ,
" name " : " TrafficLight "
},
{
" tlName " : " 2 5 2 8 6 4 8 0 1 " ,
" name " : " TrafficLight "
}
]
Listing 6.3: Example mapping of traffic lights

Listing 6.3 shows as an example how this prototype is assigned via the name attribute to specific traffic
lights. The important aspect here is that tlName refers to the id of the traffic light we found via the sumo
gui in section 6.2 which must exactly match each other.

6.4 The Traffic Light API
In order to access the traffic light functionality from within an application it must extend the

AbstractApplication abstract class. There are two main functionalities provided by it, reachable from the application operating system that can be acquired by using
the getOperatingSystem() method:
• Change the currently active traffic light program via setProgramById()
• Adjust the remaining time of the currently active phase via setPhaseRemainingDuration()
However, adding a new traffic light program from within the application at runtime using the VSimRTI
application interface is currently not possible and has to be done beforehand via sumo as described
here: http://sumo.dlr.de/wiki/Simulation/Traffic_Lights. The two main ways of doing this is
to use an additional-file or the tls_csv2SUMO.py tool bundled with sumo. However, it is possible to
add a new program by using the TraCI interface as described here: http://sumo.dlr.de/wiki/TraCI/

Change_Traffic_Lights_State.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

63

7 Tutorial LuST
The Luxembourg SUMO Traffic (LuST) scenario is a traffic simulation scenario which aims to provide
realistic traffic patterns of a common mid-size European city during an average day [4]. This traffic
simulation scenario for SUMO has been developed by Lara Codecá et al. and is publicly available via
GitHub1 . The following tutorial shows, how the LuST scenario can be integrated into VSimRTI in order to
assess your own mobile application at large scale.
Notice: Also, you can use this scenario as a blueprint for integrating your own prepared
SUMO scenarios into VSimRTI.

Figure 7.1: Overview of the simulation site of the LuST scenario [4]

• Area: 156 km2

• Number of intersections: 4.473

• Total length of all roads: 930 km

• Number of traffic lights: 203

• Total length of highways: 89 km

• Number of vehicles during 24h of simulation
time: 215.526

1 https://github.com/lcodeca/LuSTScenario

7 Tutorial LuST

7.1 Execute the LuST scenario with VSimRTI

7.1 Execute the LuST scenario with VSimRTI
You can find a prepared VSimRTI scenario for the LuST scenario in the pre-installed scenario directory.
However, to get this scenario working, you need to execute the following steps:
1. In the subdirectory sumo of the LuST scenario directory, you can find several scripts which will
help you to download the actual SUMO scenario from the official sources on GitHub. Depending
on which operating system you use and which version control system client you have installed,
you can use one of the provided batch or shell script files. If you do not have a git or svn client
installed, you can also manually download and unzip the SUMO scenario from https://github.

com/lcodeca/LuSTScenario . Please note that the SUMO scenario must be placed inside the
sumo subdirectory of the scenario.
2. In order to execute VSimRTI with the scenario, you need to pass the given defaults.xml to the
executable. On Windows, this can be done by executing VSimRTI as follows:
vsimrti . bat -u < user - id > -s LuST -d scenarios / LuST / defaults . xml -w 0

Please note that the execution of this scenario might take a long time, due to the massive amount of
vehicles simulated in this scenario. If you want to assess your mobility applications in combination
with further simulators (e.g. Cell2), the simulation might slow down even more.
Finally, you can map your own applications onto vehicles using the prepared mapping_config.json.
Please note that applications can only be mapped for each vehicle type (see limitations below). Furthermore, you can activate any communication simulator, such as Cell2 or SNS, to integrate communication
simulation into your assessment.

7.2 Current limitations
The integration of the LuST scenario is currently a work in progress and therefore not all features are
available. The following limitations currently exist:
• No mapping of applications on single vehicles. It is currently not possible to map applications on
single vehicles. Instead, only vehicle types can be mapped with them. Of course, the applications
are running solely on each simulated vehicle which belongs to the respective vehicle type the
application is mapped on.
• No definition of own vehicle spawner. Currently, all simulated vehicles are spawned by the SUMO
traffic scenario itself. There is no way to add additional vehicles via the mapping_config.json.
• No routing capabilities in applications. Applications cannot use the navigation module of the
vehicle. Furthermore, detailed information about the current route or the road position (upcoming
nodes, type of the current road) is also not available to the applications. This is due to the missing
scenario-database, which is currently not possible to create from the LuST road network.
• No valid support of traffic light applications. The mapping of applications onto traffic lights has
not yet been tested.
• There may be more limitations we are currently not aware of.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

65

8 Create a new scenario
This chapter is intended to act as a checklist for all tasks, needed to create a new scenario. Basically, a
new scenario means that the simulation is performed in a different road network where vehicles have
different routes. Moreover, the number of vehicles can also vary.

8.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 (OSM) data which is freely available and comprehensive. Also if data in the target area is
not up to date 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. 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.

8.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=yes).
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

8 Create a new scenario

8.1 Road network data

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 -18.0. jar -- osm2db -i path / to / 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 -18.0. jar -- db2sumo -d path / to / database . db -n

The example execution should have created a number of SUMO specific network files (nodes, edges
and connections). The parameter -n automatically executes SUMOs netconvert command after the
export to create the needed netfile (requires SUMO to be in the systems path). If you want to have traffic
lights generated by netconvert, you need to add the option --export-traffic-lights to the command
above.
Now you have processed the road network to be in formats usable by VSimRTI and its connected simulators.
Regarding files, the output of these two steps should be the following:
• .db - scenario database (including road network)
• .nod.xml - SUMO node file
• .edg.xml - SUMO edge file
• .con.xml - SUMO connection file
• .net.xml - SUMO network file (after executing netconvert)
• .sumo.cfg - SUMO configuration file

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

67

8 Create a new scenario

8.2 Vehicles and Routes

8.2 Vehicles and Routes
VSimRTI contains a navigation component which supports the usage of different routes, vehicles can
be mapped to. In order to make the routes accessible for the simulation in VSimRTI, they have to be
available in the scenario database. There are two ways to achieve this:
• Generate routes with scenario-convert
or
• Import an existing SUMO route file

Generate routes
scenario-convertoffers possibilities to generate routes for the simulation. With the following command
you can generate routes from one geo-point (latitude,longitude) to another:
java - jar scenario - convert -18.0. jar -d path / to / database . db -g -- route - begin - latlon LAT , LON -- ⤦
Ç route - end - latlon LAT , LON

If geo-points are given as input, the route generation might fail due to unmatchable points. In this case,
you may use the following command in order to calculate routes from one street node to another:
java - jar scenario - convert -18.0. jar -d path / to / database . db -g -- route - begin - node - id NODE_ID -- ⤦
Ç route - end - node - id NODE_ID

The required node ids can be determined from the source OSM file or the generated SUMO network file.
For more than one route between the given points/nodes, the parameter –number-of-routes NUMBER
can be used. The calculated routes are directly written into the database. If you need to export them into
a SUMO readable format, you can use the command:
java - jar scenario - convert -18.0. jar -- db2sumo -d path / to / databsae . db -r < scenarioname >. rou . xml

Import routes from SUMO route file
If you want to use the tools provided by SUMO, e.g. duarouter4 , to calculate a set of routes for the
simulation, you need to import the resulting routes into the scenario-database of VSimRTI. Note, if
you use such tools, please always use the network file generated by scenario-convert. The route file
(*.rou.xml) generated by those tools can be directly imported into the database by using scenarioconvert. For this purpose, you can use the following command:
java - jar scenario - convert -18.0. jar -- sumo2db -r routefile . rou . xml -d path / to / databsae

This command will read the routes in the route file and write them in the supplied database file. The
database file needs be the same you used to export the network file. If the route file also contained vehicle
definitions these will be converted into a mapping3 configuration file. You will need to adapt this file later
on to achieve a meaningful mapping between vehicles and applications. For more information regarding
this please refer to chapter 3.5.15.
4 http://sumo.dlr.de/wiki/DUAROUTER

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

68

8 Create a new scenario

8.3 VSimRTI

8.3 VSimRTI
Now you have everything you need to create a configuration set that VSimRTI will recognize as a scenario. A scenario is generally a folder structure that reflects the different components usually found in a
simulation. The example tutorials of Barnim and Tiergarten also follow this specific folder structure.
The complete set of components is depicted in the Listing 8.1.


applicationNT
battery
eventserver
cell2
mapping3
ns3
omnetpp
sources
sns
sumo
visualizer
vsimrti
Figure 8.1: Scenario: folder structure for complete component set

However, a subset of all components already allows reasonable simulations. The most important components are mentioned in the following part.

Applications and Mapping (applicationNT, mapping3)

Usually you want the simulated vehicles to be equipped with some kind of applications that influence the
vehicles behavior. To do that you copy the jar files of your applications to the folder application/ap-

plications. To further configure the behavior of the application simulator have a look at chapter
3.5.
Having the applications in place you will have to copy your mapping file to the folder mapping3. If
you don’t 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.5.15.

Navigation (applicationNT)

The generated database file .db needs to moved into the applicationNT folder. As
long as you only have one database file in this folder you don’t need to do anything more. VSimRTI will
recognize the file automatically.
For further info on navigation in the application simulator have a look at chapter 3.5.14.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

69

8 Create a new scenario

8.3 VSimRTI

Traffic Simulator (sumo)

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

Communication Simulator (cell2, ns3, omnetpp, sns)

There is an extensive default configuration provided in the simulators folder in the tutorials of Barnim
and Tiergartenfor all communication simulators.
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.
• For OMNeT++, it concerns the values of constraintArea in the omnetpp.ini.
• For the CELL simulator, the expansions do not need to be configured directly. However, the areas
of the configured regions (in regions.json) have to be in line with the scenario location.
• The SNS also comes without an additional expansion definition.
Important: Larger values for the spatial expansion of the simulation area are also usually possible for the communication simulators. However, much larger this might decrease
the performance. Smaller values lead to wrong behavior and will crash the simulation!
For further information on the communication simulators, have a look at Chapters 3.2, 3.3, 3.6, and 3.7.

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 analyze.
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.
Within the IPResolverConfig tag the address resolution scheme is specified. The subnets for all node
types are described in JSON format.
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.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

70

8 Create a new scenario

8.3 VSimRTI

Further components

Several components (as the battery configuration or the visualizer configuration) are generally scenario
independent and can be copied from the existing tutorial scenarios Barnim and Tiergarten.
The event server component (to simulate an icy road etc.) obviously also depends on the scenario location.
The position of the event should be in line with and be located in the area of the scenario.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

71

9 Visualizers
9.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 9.1 gives a overview about the current coupled
visualizers. More than one visualizer of the same type can be defined.

vsimrti
VSimRTI WebSocket Visualizer ............................................. (see 9.2)
VSimRTI File Visualizer .................................................. (see 9.3)
VSimRTI Integrated Test and Evaluation Framework (ITEF) .............. (see 9.4)
user defined visualizer ..........................................................
Figure 9.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. To get
an instant impression of a simulation, the WebSocket Visualizer shows vehicle movements on a Google
Map.
The visualizers are integrated into the simulation with a visualization ambassador.

9 Visualizers

9.2 VSimRTI WebSocket Visualizer

9.2 VSimRTI WebSocket Visualizer
To get a 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 command line parameter -v.
Important: By default, the WebSocket Visualizer does not work on Microsoft Edge.
UWP (Universal Windows Platform) apps on Windows 10 do not have direct network access
but are subject to a network isolation for security reasons, preventing localhost loopback
by default. While Microsoft Edge itself does allow localhost access, it treats localhost as an
Internet site, which leads to restrictions e.g. for IPC over IP. To prevent this, an exception
for Edge must be added to the network isolation via the following command in an elevated
command prompt:
C h e c k N e t I s o l a t i o n Loopba ckExem pt -a -n = " Microsoft . M i c r o s o f t E d g e _ 8 w e k y b 3 d 8 b b w e "

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

73

9 Visualizers

9.3 VSimRTI File Visualizer

9.3 VSimRTI File Visualizer
The File Visualizer is a tool which gives you the opportunity to log specific VSimRTI message types.

9.3.1 Configuring the File Visualizer
• The main configuration file is located at

vsimrti/scenarios//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:

< message id = " V e h i c l e M o v e m e n t s " >
< entries >
< entry >" MOVE_VEHICLE " 
< entry > TimeInSec 
< entry > Updated:Id 
< entry > U p d a t e d : A p p l i c a t i o n N r 
< entry > U p d a t e d : P o s i t i o n . Latitude 
< entry > U p d a t e d : P o s i t i o n . Longitude 


Listing 9.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.
< entry >" MOVE_VEHICLE " 
Listing 9.2: An example for constant type entry.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

74

9 Visualizers

9.3 VSimRTI File Visualizer

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 
Listing 9.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 
Listing 9.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 can’t
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 
Listing 9.5: An example for simple extended method type entry.

With existing methods of VehicleMovements and its super class Message , we can’t 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 
Listing 9.6: An example for assisting extended method type entry.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

75

9 Visualizers

9.3 VSimRTI File Visualizer

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 
Listing 9.7: An example for cascaded iteration.

What we haven’t met yet, is that, if in the definition of entries, several different iterating operations exists,
for example:
< entry > Senders:Id 
< entry > Receivers:Id 
Listing 9.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 9.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 9.1: A list of all extended methods

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

76

9 Visualizers

9.3 VSimRTI File Visualizer

Method

Type

VehicleMovements.getUpdated()

List

VehicleInfo.getId()

String

VehicleInfo.getPosition()

GlobalPosition

GlobalPosition.getLatitude()

double

Message.getTime()

long

VehicleInfo.getType()

UnitType
Table 9.2: A list of some basic methods

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

77

9 Visualizers

9.4 VSimRTI Integrated Test and Evaluation Framework (ITEF)

9.4 VSimRTI Integrated Test and Evaluation Framework
(ITEF)
Notice:

ITEF is only available with a commercial license of VSimRTI. For further

information on licences, please refer to our mailing list .
The Integrated Test and Evaluation Framework (ITEF) is a webtool for planning and evaluating vehicular
communication scenarios. It is suited for field operational tests as well as simulations.
ITEF also offers a variety of visualization features, making a comparison of different vehicles or between
equipped and unequipped vehicles easy. It is structured into 4 screens, whereas the following 3 screens
are intended for the visualization.
The Replay screen (see Figure 9.2) is intended to be used for an initial overview of the test run. The
main feature is the display of the vehicle movements on a map, while the player can be used to playback
the movement situation. In this manner, the ITEF allows a location and time dependent evaluation of
simulation test runs.
The Evaluate screen (see Figure 9.3) allows the detailed investigation of the correlations in a test run. The
main feature of this screen is to display the behavior summarized over the whole run. The structure of
this screen with is similar to the Replay screen. However, the focus here is on the detailed (statistical)
summary of evaluated metrics.
Finally, the Statistics screen (see Figure 9.4) provides statistical evaluations of the test and simulation run.
Currently, statistics on Vehicle Speed, Travel Time, Travel Distance and several more are supported.

Figure 9.2: ITEF Replay Screen

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

78

9 Visualizers

9.4 VSimRTI Integrated Test and Evaluation Framework (ITEF)

Figure 9.3: ITEF Evaluate Screen

Figure 9.4: ITEF Statistics Screen

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

79

10 Run simulation series
10.1 Simulation Runner
Notice: The simulation runner is only available with a commercial license of VSimRTI.
For further information on licences, please refer to our mailing list .
The simulation runner is a tool for automatic simulation parametrization and execution. Accordingly,
a comfortable way exists to configure the execution of multiple simulations, e.g. of simulation series
including several runs where only few parameters are changed in each run. With the simulation runner,
a simulation series can be defined, for example, where the V2X penetration rate is changed in each
simulation run. As a result, VSimRTI starts all simulation runs automatically according to the defined
parameters.

10.1.1 Usage
The simulation runner is started as follows:
GNU/Linux
./ simrun . sh -c / scenarios / < scenario name >/ vsimrti / simrun_config . xml -p ⤦
Ç numberofparallelsimulations
Listing 10.1: VSimRTI simulation runner start command for GNU/Linux.

GNU/Linux
java - jar VsimrtiEmbeddedStarter - x . x . x . jar -s -u userid -- strict - configuration - path -c ⤦
Ç scenarios / < scenario name >/ vsimrti / simrun_config . xml
Listing 10.2: VSimRTI VSimRTIEmbeddedStarter simulation runner start command for GNU/Linux.

Microsoft Windows
simrun . bat -c \ scenarios \ < scenario name >\ vsimrti \ simrun_config . xml -p ⤦
Ç numberofparallelsimulations
Listing 10.3: VSimRTI simulation runner start command for Microsoft Windows.

Microsoft Windows
java - jar VsimrtiEmbeddedStarter - x . x . x . jar -u userid -s -- strict - configuration - path -c ⤦
Ç scenarios \ < scenario name >\ vsimrti \ simrun_config . xml
Listing 10.4: VSimRTI VSimRTIEmbeddedStarter simulation runner start command for Microsoft Windows.

10 Run simulation series

10.1 Simulation Runner

Configuration file

The configuration file vsimrti/scenarios//vsimrti/simrun_config.xml contains the parameterization information.

10.1.2 Configuration
The example in listing 10.5 shows a complete configuration. Using this configuration the simulationrunner would try to run a scenario called Barnim while adapting the mapping (see 3.5.15), the configuration file of SNS, and VSimRTI (see 8.3) configuration files. The actual simulation is triggered by generating
an adapted scenario folder and calling the same executable the user would normally trigger himself.
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


< 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 / scenarios / scenarioname / vsimrti / simrun_config . xsd " >

< vsimrti location = " / path / to / vsim rti_fo lder " executable = " vsimrti . sh " username = " user_id " / >
< scenario name = " Barnim " config = " scenarios / Barnim / vsimrti / v simrti _confi g . xml " persistent = " ⤦
Ç false " repetitions = " 1 " >
 - o TRACE 
 - w 0 


< dimension name = " P e n e t r a t i o n R a t e s " >
< parameter name = " V 2 X V e h i c l e P e r c e n t a g e " file = " mapping3 / mappi ng_con fig . json " fileFormat = " ⤦
Ç json " item = " vehicles [0]. types [0]. weight " type = " ValueList " >
< value > 0.0 
< value > 0.5 
< value > 0.75 

< parameter name = " C l a s s i c V e h i c l e P e r c e n t a g e " file = " mapping3 / mappi ng_con fig . json " ⤦
Ç fileFormat = " json " item = " vehicles [0]. types [1]. weight " type = " ValueList " >
< value >1 
< value > 0.5 
< value > 0.25 

< parameter name = " Si mulati ontime " file = " vsimrti / vsim rti_co nfig . xml " fileFormat = " xml " item ⤦
Ç = " // simulation / endtime " type = " ValueList " >
< value > 100 
< value > 100 
< value > 100 



< parameter name = " Si n gl eh o pR ad i us " file = " sns / sns_config . json " fileFormat = " json " item = " ⤦
Ç singlehop . radius " type = " ValueList " >
< value > 500 
< value > 600 


Listing 10.5: Simulation Runner configuration example

The configuration contains three distinct parts of configuration. The system specific definition, the
scenario definition and the parametrization. While the first two parts will be explained as part of this
section, the parametrization will be explained in it’s own section.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

81

10 Run simulation series

10.1 Simulation Runner

system specific definition
1
2

< vsimrti location = " / path / to / vsim rti_fo lder " executable = " vsimrti . sh "
username = " user_id " p a r a l l e l S i m u l a t i o n s = " 1 " / >
Listing 10.6: example of system specific definition in configuration file

The system specific part of the configuration (see listing 10.6) is the only part of the configuration that
can be overwritten using a second configuration file. It contains the following values:
• location of the VSimRTI installation to use (can be relative or absolute).
• executable used to start the simulation. This value is optional and will automatically be set to the
default *.bat or *.sh file when omitted.
• username needed to check the license against. This is the user name given to you when registering
your system with us.
• parallelSimulations defines how many simulations are started in parallel to speed up things.
This value is optional and defaults to 1. Be aware that you should only use this if you have multiple
cores available. This might also coincide with the threads option in the VSimRTI configuration.

scenario definition
1
2
3
4

< scenario name = " Barnim " config = " scenarios / Barnim / vsimrti / vs imrti_ config . xml " persistent = " false ⤦
Ç " repetitions = " 1 " >
 - o TRACE 
 - w 0 

Listing 10.7: example of scenario definition in configuration file

The scenario definition (see listing 10.7) contains everything needed to identify the scenario to execute
along with parameters that needs to passed to the VSimRTI executable. It contains the following values:
• name of the simulation to run. This is expected to be the same as the scenarios folder name and
is used to automatically generate the path pointing to the scenarios vsimrti_config.xml in a
default case. It can be omitted if the config option is set.
• config is an optional value containing the concrete path to the scenarios vsimrti_config.xml.
This can be used if the scenario is not placed in the default scenarios folder (which is discouraged)
and overwrites the path generated by the name attribute. Either name or config have to be defined!
• persistent defines if the generated scenario folders (containing the adapted configuration files
for every single simulation to be executed) will be kept after simulation (value true) or deleted
(value false).
• repetitions is an optional value containing the number of times each simulation should be
repeated. Setting this to a value other than 1 only makes sense if some part of the simulation follows
stochastic models (like non deterministic vehicle spawning).
The configuration can also contain a number of additional arguments that are passed to the executable
without any changes, separated by spaces.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

82

10 Run simulation series

10.1 Simulation Runner

10.1.3 Parametrization
The heart of this tool is the parametrization of simulations. Using this, one can define values in the
default configuration that are adapted between simulation runs. How many simulation runs are performed is defined by the number of changes configured enriched with the information about simulation
repetitions.
For the example in listing 10.5 it is expected that the mapping file to be changed has one vehicles
definition spawning multiple cars with a weighted type distribution defining first the equipped and then
the unequipped vehicles.

Parameters
1
2
3
4
5
6

< parameter name = " V 2 X V e h i c l e P e r c e n t a g e " file = " mapping3 / mappin g_conf ig . json "
fileFormat = " json " item = " vehicles [0]. types [0]. weight " type = " ValueList " >
< value >0 
< value > 50 
< value > 75 

Listing 10.8: example of a parametrization for a single value

Each value that should be changed in a run is defined by a parameter element identified by a name
(see listing 10.8). The base value is the file which should be changed (relative to the scenario folder).
Currently it is needed to define what fileFormat is expected from that file, which has impact on the
syntax of the item definition which denotes what part of this file should be changed (this will be explained
in a bit). The final value is the type which denotes how the value change behaves. The child elements
depend on this definition and will also be explained in a bit.

fileFormat can be one of xml or json. The item syntax is as followed:
• xml: contains an XPath1 expression
• json: contains an array-style definition of the target value. The value in listing 10.8 would change
line 13 in listing 10.9. (In the first entry of vehicles the attribute weight of the types first entry).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

{
" prototypes " :[{ " name " : " PKW " }] ,
" vehicles " :[
{
" startingTime " : 5.0 ,
" targetDensity " :1200 ,
" m a x N u m b e r V e h i c l e s " : 250 ,
" route " : " 1 " ,
" 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 " : " PKW " ,
" weight " :0.2
},
{
" name " : " PKW " ,
" weight " :0.8
}
1 https://en.wikipedia.org/wiki/XPath

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

83

10 Run simulation series

19
20
21
22

10.1 Simulation Runner

]
}
]
}
Listing 10.9: mapping file expected for example

type can currently only have two entries:
• ValueList: This expects a list of values as child elements of the parameter. Each value will be
used for at least one permutation.
• IntegerGenerator: This automatically generates integer values to write as values. The generated
numbers can be configured by adding these attributes to the parameter element:
– offset denoting a minimal number where generation should start (this will be the first value),
default is 0.
– step denoting the number that will be added to the previous value to generate the new one,
default is 1.
In contrast to ValueList this can create an infinite number of values.

Permutation of parameters

When multiple such parameter elements are defined, a permutation for each specific value definition is
generated. Lets say defined are parameters A and B and each parameter has values a and b. The resulting
permutations would be:
1
2
3
4

A =a ,
A =a ,
A =b ,
A =b ,

B=a
B=b
B=a
B=b

Dimensions

Sometimes it is wanted to group some value changes. This can be necessary when changed values need
to sum up to a specific value or when specific (named) output files need to be defined. This can be
done by enclosing the affected parameters into a dimension definition. Doing this the values of each

parameter are connected by their index. For this to work the number of values for each parameter have
to be the same. The example in listing 10.5 utilizes this function to make sure the vehicle percentages
sum up to 100. The generated permutations for the dimension enclosed parameters are:
1
2
3

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
V 2 X V e h i c l e P e r c e n t a g e =50 , C l a s s i c V e h i c l e P e r c e n t a g e =50
V 2 X V e h i c l e P e r c e n t a g e =75 , C l a s s i c V e h i c l e P e r c e n t a g e =25

When additionally parameters are defined which are not enclosed in the dimension tag or another

dimension tag is defined, then the permutations will be extended even further. The full permutation for
listing 10.5 is as follows:

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

84

10 Run simulation series

1
2
3
4
5
6

Penetra t i o n R a t e s ( 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) ,
Penetra t i o n R a t e s ( 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) ,
Penetra t i o n R a t e s ( V 2 X V e h i c l e P e r c e n t a g e =50 , C l a s s i c V e h i c l e P e r c e n t a g e =50) ,
Penetra t i o n R a t e s ( V 2 X V e h i c l e P e r c e n t a g e =50 , C l a s s i c V e h i c l e P e r c e n t a g e =50) ,
Penetra t i o n R a t e s ( V 2 X V e h i c l e P e r c e n t a g e =75 , C l a s s i c V e h i c l e P e r c e n t a g e =25) ,
Penetra t i o n R a t e s ( V 2 X V e h i c l e P e r c e n t a g e =75 , C l a s s i c V e h i c l e P e r c e n t a g e =25) ,

10.1 Simulation Runner

Si ng l eh op R ad i us =500
Si ng l eh op R ad i us =600
Si ng l eh op R ad i us =500
Si ng l eh op R ad i us =600
Si ng l eh op R ad i us =500
Si ng l eh op R ad i us =600

10.1.4 Additional Information
These are some side effects to remember when working with this tool.

Ports: The Simulation Runner supports automatic assigning of free ports for federates. This means

that all federates configured in the defaults.xml will get a free port configured by default. This enables
multiple simulations to be run simultaneously as long as the federates are started by VSimRTI. If some
federates are not started through VSimRTI but are already running, this will not work.

Paths: Relative paths of the files to be modified will be expanded with the deployment directory of the

current simulation run to an absolute one.

Adaptations: All values will be modified in copies of the original scenario. The copies will be placed

in the simrunner folder in the VSimRTI base directory and will be (if not deactivated by configuration)
deleted upon completion of the simulation.

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

85

11 Additional tools
11.1 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 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:
1

scenariocon v er t -- osm2sumo -i < osmFile > -d < dbFile > -n -- export - traffic - lights -- generate - ⤦
Ç routes -- route - begin - latlon 50.429997 ,8.6567009 -- route - end - latlon 50.429024 ,8.6642044
Listing 11.1: Exemplary call of scenario-convert.jar .

(import OpenStreetMap file to database, generate routes by given coordinates, generate network with
sumo-netconvert and export to SUMO configuration files).

11 Additional tools

11.1 scenario-convert

Usage
The following listing 2 provides an overview about the scenario-convert functions.
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
63

Usage : scenario - convert [ OPERATION ] -d < DATABASEFILE > [ OPTIONS ]*
Examples ( options in [] are optional ) :
1. Import an osm file and write data into database
scenario - convert -- osm2db -i < OSMFILE > [ - o ] [ - d < DATABASE >]
2. Export db content to sumo - readable files
scenario - convert -- db2sumo -d < DATABASE > [ - s < SUMOPREFIX >] [ - n ]
3. Reimport a sumo routefile into a database
scenario - convert -- sumo2db -d < DATABASE > -r < ROUTEFILE >
4. Combine steps 1 and 2
scenario - convert -- osm2sumo -d < DATABASE > -i < OSMFILE > [ - s < SUMOPREFIX >]
5. Export db content to Shapefile format
scenario - convert -- db2shp -d < DATABASE >
6. Import an srtm file and write elevation data to nodes of an existing database
scenario - convert -- srtm2db -i < SRTMFILE > -d < DATABASE >
------------------------------------------------------------------------------CONFIGURATION FILE :
-c , -- config - file FILE

OPERATIONS :
-- osm2db -i [ - o ] [ - d ]
-- srtm2db -i [ - d ]
-- db2sumo -d [ - s ] [ - n ] [ - l ]
-- sumo2db [ - i ] [ - r -d ]
-- osm2sumo
-- db2shp -d
-- osm2shp -d
-- srtm2db -i -d

-- update -d

CONFIGURATION OPTIONS :
-i , -- input - file FILE

-d , -- database FILE

-s , -- sumo - prefix SUMOPREFIX
-- import - zone
-- import - lon / - - import - lat

-r , -- route - file FILE
-- export - routes
-f , -- force

Optional , refers to a configuration file which
contains all parameters in JSON format . Single
options can be set by the following parameters .

Imports an OSM file creating a new database .
Imports an SRTM file creating a new database .
Exports the network to SUMO node and edge files .
Imports a SUMO Network / Routefile . Be aware that
you have to re - export an imported network !
Combination of osm2db and db2sumo .
Exports the network into Shapefile format .
Combination of osm2db and db2shp .
Imports an SRTM file and writes elevation data
to nodes .
Updates the given database to the current scheme .

Defines an input file to use in an import .
File type is dependend on the import operation .
( OSM File / Database file / SUMO net file )
When importing : file to import to . Either omit
the file extension or set it to ’. db ’.
For export operations : file to load from .
For update operations : file to update .
Prefix for the generated sumo files
( uses database name when not defined ) .
UTM zone of location for projecting coords in
default format ( e . g . 32 n ) .
center longitude / latitude of imported region
to project coordinates .
ATTENTION : Zone and coordinate parameters are
mutually exclusive alternatives !
Sumo *. rou . xml file location
Export existing route data to *. rou . xml
( only in combination with db2sumo ) .
Force overwrite of existing files
( do not increment file names ) .

INTERNAL ROUTE GENERATION
( If you use this , a route file containing these routes will be generated too )

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

87

11 Additional tools

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

11.1 scenario-convert

-g , -- generate - routes

Generate routes based on the given options .
Please see below for possible options ,
You will at least need start and end coordinates

Start of route :
-- route - begin - lat
-- route - begin - lon
-- route - begin - latlon

Latitude of point , needs longitude defined !
Longitude of point , needs latitude defined !
Combined value in format [ latitude ] ,[ longitude ]
( this is an alternative to separate definition !)
OSM node id as start point
( this is an alternative to the options above !)

-- route - begin - node - id
End of route :
-- route - end - lat
-- route - end - lon
-- route - end - latlon

Latitude of point , needs longitude defined !
Longitude of point , needs latitude defined !
Combined value in format [ latitude ] ,[ longitude ]
( this is an alternative to separate definition !)
OSM node id as start point
( this is an alternative to the options above !)

-- route - end - node - id

-- number - of - routes INT

Optional , limits the maximum number of generated
routes . Default is 1.

ADDITIONAL TOOLS
-o , -- execute - osmosis

Execute osmosis to apply automatic filters to
the given osm file ( only for osm2xxx ) .
Write osm building information in database
Ignore all defined turn restrictions on OSM import .
Turns off the removal of unconnected parts from the
main traffic network graph . Since several components of
VSimRTI require one main graph without disconnected ways
and nodes , this option should be used only if the
cleanup procedure is faulty .
Automatically start sumo netconvert after export
to create netfile ( only with xxx2sumo )
export traffic light information for nodes
Define a property file which contains speed information
which are used to set the speed for OSM ways without a
max speed tag . ( only with osm2xxx )
If set to true , the maxspeed tags of ways are ignored and
replaced by either default values , or by speed information
defined via the -- osm - speeds - file option . ( only with osm2xxx )
export traffic light information for nodes
Print current version number

-b , -- import - buildings
-- ignore - turn - restrictions
-- disable - graph - cleanup

-n , -- execute - netconvert
-l , -- export - traffic - lights
-- osm - speeds - file

-- osm - speeds - overwrite

-l , -- export - traffic - lights
-v , -- version

Listing 11.2: Overview about scenario-convert options.

The following listing 3 shows a JSON example file which can be used with the -c option of scenarioconvert.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

{
" operati ng_mod e " :

" osm2db " ,

" input_path " :
" database_path " :

" path / to / input . osm " ,
" path / to / database . db " ,

" sumo_prefix " :

" SUMO_PREFIX " ,

" e xe c u t e _ n e t c o n v e r t " :
" export_traffic_lights ":
" export_routes " :
" impor t _ b u i l d i n g s " :
" force _ ov er w ri te " :
" disable_graph_cleanup ":
" ignore_turn_restrictions ":

true ,
true ,
true ,
false ,
false ,
false ,
false ,

" gener a te _r o ut es " :
" numbe r _ o f _ r o u t e s " :

true ,
2,

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

88

11 Additional tools

19
20
21
22
23
24
25
26

11.1 scenario-convert

" route _ be gi n _l at " :
" route _ be gi n _l on " :
" route_end_lat " :
" route_end_lon " :

52.5 ,
13.4 ,
52.2 ,
13.1 ,

" osm_overwrite_speeds ":
" osm_s p ee ds _ fi le " :

false ,
" path / to / speeds . properties "

}
Listing 11.3: Example file for scenario-convert configuration with JSON

Furthermore, in listing 4 you can find a properties file which can be used during the import of OSM data
in order to define speeds for ways, which do not have a maxspeeds-tag defined. For this purpose use the
option - -osm-speeds-file . In the speed properties file, for each way type a speed value can
be defined, according to the OSM highway key 1 .
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

# the unit the speed values are defined in [ kmh , ms ]
speed . unit = kmh
# the default speed for all way types which are not defined here
speed . default = 30
# autobahn
highway . motorway = 130
highway . motorway_link = 70
# bundesstrasse ( germany )
highway . trunk = 70
highway . trunk_link = 65
# linking bigger town
highway . primary = 65
highway . primary_link = 60
# linking towns + villages
highway . secondary = 60
highway . secon dary_l ink = 50
# streets without middle line separation
highway . tertiary = 50
highway . tertiary_link = 40
highway . residential = 30
# special roads
highway . living_street = 5
highway . service = 20
# unclassified roads
highway . unclassified = 30
highway . road = 20
# forest tracks
highway . track 15
Listing 11.4: Example file which can be used to configure speeds for ways during OSM import

1 http://wiki.openstreetmap.org/wiki/Key:highway

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

89

12 VSimRTI configuration
12.1 Overview
VSimRTI can be configured by adapting the files in the /vsimrti/etc directory. The following technical
aspects of VSimRTI can be configured:
• vsimrti/etc/defaults.xml - Configuration of all federates which are coupled with VSimRTI.
• vsimrti/etc/hosts.json - Configuration of the machines the simulations are executed on.
• vsimrti/etc/logback.xml - Logging configuration of VSimRTI and its federates.
A full example of the default configuration files can be found in A.2.

12.2 Federates configuration
This part of software can be configured with a configuration file. The specific path is

vsimrti/etc/defaults.xml This file is used for configuring all federates and simulators coupled with
VSimRTI. For each federate you can define various aspects:
• What’s the id and class of the federate?
• On which host is the federate running?
• How is the federate started?
• What is the name of the configuration file for the federate?
• For which messages is the federate subscribing?
• The priority of the federate when it comes to message distribution.
A detailed description of the various parameters can be found in the documentation available on the
DCAITI website .

12 VSimRTI configuration

12.3 Host configuration

12.2.1 Federate priorities
There might be cases where it is important that a certain federate receives messages with equal timestamps before or after the other ones. In the context of VSimRTI for example, it is often desirable that
the Application Simulator receives the vehicle movements-message after the traffic simulator to avoid
problematic behavior in the first simulator. The configuration file defaults.xml allows for a fine grained
adjustment of the federate priorities.
For

example,

a

federate

with

a

certain

priority

looks

like

this:

. That

means that the Sumo Ambassador has an priority of 20, where the following rules apply to the priorities:
• Priorities range from 0 to 100.
• 0 is the highest priority, e.g. the federate with this priority assigned will receive the message first.
• The default priority if none is given is 50.
Note that VSimRTI ships with sane default values for the priority and a modification is only necessary in
rare cases.

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

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

91

13 Additional information
Here you find helpful information regarding VSimRTI and its configuration.

13.1 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 Nano’s ANOther editor (NANO).
1
2
3
4
5
6
7
8
9
10
11
12

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

13 Additional information

13.1 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.
(Don’t forget a semicolon to seperate).
7. Click “OK”, click “OK”, click “OK”, . . . .

3
2

1

6
7

4

5
8

Figure 13.1: Edit PATH variable in Microsoft Windows

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

93

14 List of Acronyms
ASCT

Automotive Services and Communication Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

CAM

Cooperative Awareness Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

CLI

Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

CPU

central processing unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

DCAITI

Daimler Center for Automotive Information Technology Innovations . . . . . . . . . . . . . . . . . . . . 2

DENM

Decentralized Environmental Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

ETC

Estimated Time to Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

ETSI

European Telecommunications Standards Institute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

EPL

Eclipse Public License

FOKUS

Fraunhofer-Institut für Offene Kommunikationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

GUI

Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

GNU

GNU’s Not Unix!

GPL

GNU General Public License

HLA

High-Level Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

IEEE

Institute of Electrical and Electronics Engineers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

INET

OMNeT++ - Model library for wired, wireless and mobile networks . . . . . . . . . . . . . . . . . . . . . 12

ITEF

Integrated Test and Evaluation Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

JAR

Java Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

JRE

Java Runtime Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

JSON

JavaScript Object Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

LTE

Long Term Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

LuST

Luxembourg SUMO Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

M&S

modelling and simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

MAC

Media Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

MBMS

Multimedia Broadcast Multicast Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

NANO

Nano’s ANOther editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

ns-2

network simulator 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

ns-3

network simulator 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

OMNeT++

Objective Modular Network Testbed in C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

OSM

Open Street Map

RAM

random-access memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

RSU

Road Side Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

RTF

Real Time Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

SNS

Simple Network Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

SUMO

Simulation of Urban Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

TraCI

Traffic Control Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

UMTS

Universal Mobile Telecommunications System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

14 List of Acronyms

14 List of Acronyms

UUID

universally unique identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

V2V

Vehicle-to-Vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

V2X

Vehicle-2-X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

VIM

Vi IMproved. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

VSimRTI

Vehicle-2-X Simulation Runtime Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

XML

Extensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

95

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

configure

ulators

should

scenario
be

specific
active

in

VSimRTI
a

options,

simulation

e.g.
scenario,

vsimrti/scenarios//vsimrti/vsimrti_config.xml

to
you

define

which

sim-

can

adjust

the

file

located

in

vsimrti/scenarios//vsimrti . The overall folder structure is as follows:

Appendix A VSimRTI deployment

A.1 VSimRTI Folder Structure

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
Barnim .................................... path containing Barnim 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

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

97

Appendix A VSimRTI deployment

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



< 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 . omnetpp . ambassador . O m n e t p p A m b a s s a d o r " >
< id > omnetpp 
< deploy > true 
< start > true 
< host > local 
< port > 4998 
< dockerImage > 
< config > omn etpp_c onfig . json 
< messages >
< message > AddedVehicle 
< message > AddedRsu 
< message > A d d e d T r a f f i c L i g h t 
< message > V e h i c l e M o v e m e n t s 
< message > SendV 2XMess age 
< message > C o n f i g u r e A d H o c C o m m u n i c a t i o n 


< federate class = " com . dcaiti . vsimrti . fed . ns3 . ambassador . Ns3Ambassador " >
< id > ns3 
< deploy > true 
< start > true 
< host > local 
< port > 5011 
< dockerImage > 
< config > ns3_config . json 
< messages >
< message > AddedVehicle 
< message > AddedRsu 
< message > A d d e d T r a f f i c L i g h t 
< message > V e h i c l e M o v e m e n t s 
< message > SendV 2XMess age 
< message > C o n f i g u r e A d H o c C o m m u n i c a t i o n 


< federate class = " com . dcaiti . vsimrti . fed . sns . ambassador . SnsAmbassador " >
< id > sns 
< deploy > false 
< start > false 
< host > local 
< config > sns_config . json 
< messages >
< message > AddedVehicle 
< message > AddedRsu 
< message > A d d e d T r a f f i c L i g h t 
< message > V e h i c l e M o v e m e n t s 
< message > SendV 2XMess age 
< message > C o n f i g u r e A d H o c C o m m u n i c a t i o n 


< federate class = " com . dcaiti . vsimrti . fed . sumo . ambassador . SumoA mbassa dor " >
< id > sumo 
< deploy > true 
< start > true 
< host > local 
< port >0 
< config > sumo_config . json 

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

98

Appendix A VSimRTI deployment

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

A.2 File listings

< 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 > V e h i c l e P a t h s I n i t M e s s a g e 
< message > AddedVehicle 
< message > SetMaxSpeed 
< message > SlowDown 
< message > P r o p a g a t e N e w R o u t e 
< message > C h a n g e S t a t i c R o u t e 
< 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 > ChangeLane 
< 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 > Stop 
< message > Resume 
< 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 > E n a b l e D i s t a n c e S e n s o r s 
< message > C h a n g e V e h i c l e P a r a m e t e r s 
< message > ChangeSpeed 
< message > Vehic leCont rol 
< message > V e h i c l e M o v e m e n t s 


< federate class = " com . dcaiti . vsimrti . fed . applicationNT . ambassador . ⤦
Ç ApplicationNTAmbassador ">
< id > applicationNT 
< deploy > false 
< start > false 
< host > local 
< port >0 
< config > a p p l i c a t i o n N T _ c o n f i g . json 
< messages >
< message > AddedRsu 
< message > A d d e d C h a r g i n g S t a t i o n 
< message > A d d e d T r a f f i c L i g h t 
< message > AddedVehicle 
< message > A p p l i c a t i o n S p e c i f i c M e s s a g e 
< message > C h a n g e V e h i c l e S t a t e 
< message > C h a r g i n g S t a t i o n U p d a t e 
< message > C h a r g i n g R e j e c t e d 
< message > V e h i c l e E l e c t r i c I n f o r m a t i o n M e s s a g e 
< message > P r o p a g a t e N e w R o u t e 
< message > R e c e i v e V 2 X M e s s a g e 
< message > R e c e i v e F u l l V 2 X M e s s a g e 
< message > A c k n o w l e d g e V 2 X M e s s a g e 
< message > SensorData 
< 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 > U p d a t e T r a f f i c L i g h t 
< message > V e h i c l e M o v e m e n t s 
< 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 > V e h i c l e T y p e s I n i t M e s s a g e 


< 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 
< deploy > false 
< start > false 
< host > local 
< config > e v e n t s e r v e r _ c o n f i g . json 
< messages >
< message > S e n s o r R e g i s t r a t i o n 
< message > V e h i c l e M o v e m e n t s 


< 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 
< deploy > false 
< start > false 
< host > local 

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

99

Appendix A VSimRTI deployment

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

A.2 File listings

< config > map ping_c onfig . json 
< messages >
< 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 > S c e n a r i o T r a f f i c L i g h t s 
< message > S c e n a r i o A d d e d V e h i c l e 


< federate class = " com . dcaiti . vsimrti . fed . cell2 . ambassador . Ce ll 2 Am ba s sa do r " >
< id > cell2 
< deploy > false 
< start > false 
< host > local 
< config > cell2_config . json 
< messages >
< message > AddedVehicle 
< message > AddedRsu 
< message > A d d e d T r a f f i c L i g h t 
< message > A d d e d C h a r g i n g S t a t i o n 
< message > V e h i c l e M o v e m e n t s 
< message > SendV 2XMess age 
< message > C o n f i g u r e C e l l C o m m u n i c a t i o n 


< 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 
< deploy > false 
< start > false 
< host > local 
< config > bat tery_c onfig . json 
< messages >
< message > AddedVehicle 
< message > V e h i c l e M o v e m e n t s 
< message > C ha r gi ng S ta rt e d 
< message > C ha r gi ng S to pp e d 


< 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 
< deploy > false 
< start > false 
< host > local 
< config > c h a r g i n g s t a t i o n _ c o n f i g . json 
< messages >
< message > A d d e d C h a r g i n g S t a t i o n 
< message > ChargeRequest 
< message > S t o p C h a r g e R e q u e s t 
< message > C h a r g i n g S t a t i o n U p d a t e 


< 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 " >
< deploy > false 
< start > false 
< id > visualizer 
< host > local 
< port > 5099 
< update >1 
< config > v i s u a l i z e r _ c o n f i g . xml 
< 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 > V e h i c l e P a t h s I n i t M e s s a g e 
< message > AddedVehicle 
< message > AddedRsu 
< message > A d d e d T r a f f i c L i g h t 
< message > A d d e d C h a r g i n g S t a t i o n 
< message > V e h i c l e M o v e m e n t s 
< message > SensorData 

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

100

Appendix A VSimRTI deployment

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

A.2 File listings

< message > V e h i c l e E l e c t r i c I n f o r m a t i o n M e s s a g e 
< message > U p d a t e T r a f f i c L i g h t 
< message > C h a r g i n g S t a t i o n U p d a t e 
< message > SetMaxSpeed 
< message > SlowDown 
< message > ChangeRoute 
< message > C h a n g e S t a t i c R o u t e 
< message > ChangeLane 
< 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 > A p p l i c a t i o n I t e f M e s s a g e 
< message > SendV 2XMess age 
< message > R e c e i v e V 2 X M e s s a g e 
< message > D e l e t e V 2 X M e s s a g e 


< federate class = " com . dcaiti . vsimrti . fed . phabmacs . ambassador . P h a b m a c s A m b a s s a d o r " >
< id > phabmacs 
< deploy > true 
< start > true 
< host > local 
< port > 50423 
< config > p h ab m ac s_ c on fi g . json 
< j a v a M e m o r y S i z e X m s > 100 
< j a v a M e m o r y S i z e X m x > 4086 



< classpath >../../../../ federates / phabmacs / phabmacs - federate / target / classes 

-->

 - Xdebug - X r u n j d w p : t r a n s p o r t = dt_socket \ , server = y \ , suspend = n ⤦
Ç \ , address =8086  -->
< 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 > V e h i c l e P a t h s I n i t M e s s a g e 
< message > AddedVehicle 
< message > AddedRsu 
< message > ChangeSpeed 
< message > S et A cc el e ra ti o n 
< message > SetMaxSpeed 
< message > SlowDown 
< message > C h a n g e S t a t i c R o u t e 
< 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 > ChangeLane 
< message > Stop 
< message > Resume 
< 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 > P r o p a g a t e N e w R o u t e 
< message > SetActuators 
< message > SendV 2XMess age 
< message > R e c e i v e V 2 X M e s s a g e 
< message > CurrentEvents 
< message > Vehic leCont rol 
< message > V e h i c l e M o v e m e n t s 


< federate class = " com . dcaiti . vsimrti . fed . phasca . ambassador . P h a s c a A m b a s s a d o r " >
< id > phasca 
< deploy > true 
< start > false 
< host > local 

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

101

Appendix A VSimRTI deployment

259
260
261
262
263
264
265

A.2 File listings

< config > phasca_config . json 
< messages >
< message > AddedVehicle 




Listing A.1: VSimRTI: file listing: etc/defaults.xml

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

102

Appendix A VSimRTI deployment

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



< 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 / logback . xsd " >



< 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 



< appender name = " STDOUT - TimeAdvance " class = " ch . qos . logback . core . Co 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 { HH:mm:ss } - % msg 



< appender name = " STDOUT - DbLoading " class = " ch . qos . logback . core . C on so l eA p pe nd e 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 { HH:mm:ss . SSS } - % msg 



< appender name = " STDOUT - MessageOnly " class = " ch . qos . logback . core . Co ns o le Ap p en d er " >
< 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 >% msg % n 

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

103

Appendix A VSimRTI deployment

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

A.2 File listings




< appender name = " VsimrtiLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ VSimRTI . log 
< 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 


< appender name = " TrafficLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Traffic . log 
< 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 

< append > false 

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


< 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 
< 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 >% msg % n 

< append > false 

< appender name = " A p p l i c a t i o n N T L o g " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ ApplicationNT . log 
< 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 


< appender name = " A p p l i c a t i o n N t L o g D e l e g a t i o n " class = " ch . qos . logback . classic . sift . ⤦
Ç S if t in gA p pe nd e r " >
< discriminator >
< key > path 
< defaultValue > unknown 

< sift >
< appender name = " FILE -${ unitId } " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ appsNT /${ path }. log 
< layout class = " ch . qos . logback . classic . PatternLayout " >
< pattern >% date % -5 level - % msg % n 




< appender name = " G e n e r a l P u r p o s e A m b a s s a d o r " class = " ch . qos . logback . classic . sift . ⤦
Ç S if t in gA p pe nd e r " >
< discriminator >
< key > loggerId 
< defaultValue > unknown 

< sift >
< appender name = " FILE -${ loggerId } " class = " ch . qos . logback . core . FileAppender " ⤦
Ç >
< file > ${ logDirectory }/ loggerId -${ loggerId }. log 
< layout class = " ch . qos . logback . classic . PatternLayout " >
< pattern >% date % -5 level % logger {0} - % msg % n 




VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

104

Appendix A VSimRTI deployment

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

A.2 File listings


< appender name = " StatisticsLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ statistics . csv 
< 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} [% thread ] - % msg % n 


< appender name = " MappingLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Mapping . log 
< 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 


< logger name = " d b L o a d i n g P r o g r e s s " additivity = " false " level = " INFO " >
< appender - ref ref = " STDOUT - DbLoading " / >

< appender name = " NavigationLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Navigation . log 
< 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 


< appender name = " Env ironme ntLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Environment . log 
< 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 


< appender name = " Cell2Log " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Cell2 . log 
< 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 


< appender name = " BatteryLog " class = " ch . qos . logback . core . FileAppender " >
< file > ${ logDirectory }/ Battery . log 
< 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 


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




< logger name = " VSimRT IStar ter " additivity = " false " level = " INFO " >
< appender - ref ref = " VsimrtiLog " / >

< logger name = " com . dcaiti . vsimrti . docker " additivity = " false " level = " INFO " >
< appender - ref ref = " VsimrtiLog " / >

< logger name = " com . dcaiti . vsimrti . fed . sumo " additivity = " false " level = " INFO " >
< appender - ref ref = " TrafficLog " / >

< 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 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 name = " com . dcaiti . vsimrti . fed . sns " additivity = " false " level = " INFO " >

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

105

Appendix A VSimRTI deployment

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

A.2 File listings

< appender - ref ref = " C o m m u n i c a t i o n L o g " / >


< logger name = " com . dcaiti . vsimrti . fed . ns3 . ambassador . N s 3 A m b a s s a d o r O u t p u t " ⤦
Ç 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 name = " com . dcaiti . vsimrti . fed . omnetpp . ambassador . O m n e t p p A m b a s s a d o r O u t p u t " ⤦
Ç 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 name = " com . dcaiti . vsimrti . fed . applicationNT . ambassador . navigation " ⤦
Ç additivity = " false " level = " INFO " >
< appender - ref ref = " NavigationLog " / >

< logger name = " com . dcaiti . vsimrti . fed . applicationNT " additivity = " false " level = " INFO ⤦
Ç ">
< appender - ref ref = " A p p l i c a t i o n N T L o g " / >

< logger name = " A p p l i c a t i o n N t L o g D e l e g a t e " additivity = " false " level = " INFO " >
< appender - ref ref = " A p p l i c a t i o n N t L o g D e l e g a t i o n " / >

< logger name = " com . dcaiti . vsimrti . fed . eventserver " additivity = " false " level = " INFO " >
< appender - ref ref = " E nviron mentLo g " / >

< logger name = " com . dcaiti . vsimrti . fed . mapping3 " additivity = " false " level = " INFO " >
< appender - ref ref = " MappingLog " / >

< logger name = " com . dcaiti . vsimrti . lib . routing " additivity = " false " level = " INFO " >
< appender - ref ref = " NavigationLog " / >

< logger name = " com . graphhopper " additivity = " false " level = " INFO " >
< appender - ref ref = " NavigationLog " / >

< logger name = " net . sf . jsi " additivity = " false " level = " OFF " >
< appender - ref ref = " NavigationLog " / >

< logger name = " com . dcaiti . vsimrti . fed . cell2 " additivity = " false " level = " INFO " >
< appender - ref ref = " Cell2Log " / >

< logger name = " com . dcaiti . vsimrti . fed . battery " additivity = " false " level = " INFO " >
< appender - ref ref = " BatteryLog " / >

< logger name = " com . dcaiti . vsimrti . fed . phabmacs " additivity = " false " level = " INFO " >
< appender - ref ref = " TrafficLog " / >

< logger name = " com . dcaiti . vsimrti . fed . ch a rg i ng st a ti on " additivity = " false " level = " ⤦
Ç INFO " >
< appender - ref ref = " C h a r g i n g S t a t i o n L o g " / >

< logger name = " statistics " additivity = " false " level = " OFF " >
< appender - ref ref = " StatisticsLog " / >

< logger name = " com . dcaiti . vsimrti . rti . services . time " additivity = " false " level = " INFO ⤦
Ç ">
< appender - ref ref = " STDOUT - TimeAdvance " / >

< logger name = " com . dcaiti . vsimrti . start " additivity = " false " level = " INFO " >
< appender - ref ref = " STDOUT - MessageOnly " / >


< root level = " INFO " >
< appender - ref ref = " STDOUT " / >
< appender - ref ref = " VsimrtiLog " / >


VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

106

Appendix A VSimRTI deployment

227
228
229
230

A.2 File listings




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

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

107

Appendix B
Example scenario Barnim
You will find a collection of all relevant data.

B.1 Folder Structure
Barnim
applicationNT .....................................................................
applications ...................................................................
Barnim.db ............................................... not listed (binary content)
battery ............................................................................
battery_config.json .................................................... (see B.1)
eventserver .......................................................................
eventserver_config.json ............................. not listed (in this release)
cell2 ..............................................................................
cell2_config.json ...................................................... (see B.2)
network.json ............................................................ (see B.3)
regions.json ............................................................ (see B.4)
mapping3 ...........................................................................
mapping_config.json .................................................... (see B.5)
sns ................................................................................
sns_config.json ........................................................ (see B.6)
sources ............................................................................
Barnim_fixed.osm .......................................... partially listed (see B.7)
sumo ...............................................................................
Barnim.edg.xml ............................................ partially listed (see B.8)
Barnim.net.xml ............................................ partially listed (see B.9)
Barnim.nod.xml ........................................... partially listed (see B.10)
Barnim.rou.xml ........................................................ (see B.11)
Barnim.sumo.cfg ....................................................... (see B.12)
sumo_config.json ...................................................... (see B.13)
visualizer ........................................................................
visualizer_config.xml ................................................ (see B.14)
vsimrti ............................................................................
vsimrti_config.xml .................................................... (see B.15)
simrun_config.xml ..................................................... (see B.16)
Figure B.1: Scenario Barnim: folder structure

Appendix B Example scenario Barnim

B.2 File listings

B.2 File listings
battery/battery_config.json
1
2
3
4
5
6
7
8
9
10
11

{
" v ehi cl e M o d e l C l a s s " : " com . dcaiti . vsimrti . fed . battery . sim . models . vehicle . ElectricSmart " ,
" ve h ic l e M o d e l C o n f i g " : {
" Mass " : 1060 ,
" ReferenceArea " : 1.95 ,
" Dr ag C oe ff i ci e nt " : 0.375 ,
" T a n k T o W h e e l E f f i c i e n c y " : 0.7 ,
" 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 ,
" 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
},
" b att er y M o d e l C l a s s " : " com . dcaiti . vsimrti . fed . battery . sim . models . battery . ⤦
Ç VerySimpleBatteryModel ",
" ba t te r y M o d e l C o n f i g " : {
" NumberOfCells " : 93 ,
" CellVoltage " : 4.3 ,
" C e l l C a p a c i t y I n A h " : 50 ,
" eff_Summer " : 0.8448 ,
" Re chargi ngType " : 2 ,
" MinSOC " : 0.30 ,
" MaxSOC " : 0.70
},
" e n v i r o n m e n t M o d e l C l a s s " : " com . dcaiti . vsimrti . fed . battery . sim . models . environment . ⤦
Ç DefaultEnvironment ",
" environmentModelConfig ": {
" Gravity " : 9.81 ,
" FluidDensity " : 1.293 ,
" 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
},
" consumers " : [ { " Radio " : 10 } , { " HeadLight " : 100 } ]

12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

}
Listing B.1: Scenario Barnim: file listing: battery/battery_config.json

cell2/cell2_config.json
1
2
3
4
5
6

{
" debug G eo ca s ti ng " : false ,
" visua l i z e R e g i o n s " : false ,
" n e t w o r k C o n f i g u r a t i o n F i l e " : " network . json " ,
" r e g i o n C o n f i g u r a t i o n F i l e " : " regions . json "
}
Listing B.2: Scenario Barnim: file listing: cell2/cell2_config.json

cell2/network.json
1
2
3
4
5
6
7
8
9
10

{
" globalRegion " : {
" uplink " : {
" delay " : {
" type " :
" delay " :
" prpl " :
" retries " :
},
" capacity " :

" ConstantDelay " ,
100 ,
0,
2
28000000

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

109

Appendix B Example scenario Barnim

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

B.2 File listings

},
" downlink " : {
" unicast " : {
" delay " : {
" type " :
" delay " :
" prpl " :
" retries " :
}
},
" multicast " : {
" delay " : {
" type " :
" delay " :
" prpl " :
},
" usable Capac ity " :
},
" capacity " :
}

" ConstantDelay " ,
100 ,
0,
2

" ConstantDelay " ,
100 ,
0
0.6
42200000

}
}
Listing B.3: Scenario Barnim: file listing: cell2/network.json

cell2/regions.json
1
2
3
4

{
" regions " : [
]
}
Listing B.4: Scenario Barnim: file listing: cell2/regions.json

mapping3/mapping_config.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

{
" prototypes " :[
{
" name " : " PKW " ,
" accel " :2.6 ,
" decel " :4.5 ,
" length " :5.00 ,
" maxSpeed " :70.0 ,
" minGap " :2.5 ,
" sigma " :0.5 ,
" tau " :1
},
{
" name " : " electricPKW " ,
" vehicleClass " : " El e ct ri c Ve hi c le " ,
" accel " :2.6 ,
" decel " :4.5 ,
" length " :5.00 ,
" maxSpeed " :40.0 ,
" minGap " :2.5 ,
" sigma " :0.5 ,
" tau " :1
},
{
" applications " :[ " com . dcaiti . vsimrti . app . tutorials . barnim . WeatherServer " ] ,

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

110

Appendix B Example scenario Barnim

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

" name " : " WeatherServer "
}
],
" rsus " :[
{
" lat " :52.65027421760045 ,
" lon " :13.545005321502686 ,
" name " : " WeatherServer "
}
],
" vehicles " :[
{
" startingTime " : 5.0 ,
" targetDensity " :1200 ,
" m a x N u m b e r V e h i c l e s " : 120 ,
" route " : " 1 " ,
" types " :[
{
" applications " :[ " com . dcaiti . vsimrti . app . tutorials . barnim . W e a t h e r W a r n i n g A p p C e l l " ⤦
Ç , " com . dcaiti . vsimrti . app . tutorials . barnim . SlowDownApp " ] ,
" name " : " PKW " ,
" weight " :0.1
},
{
" applications " :[ " com . dcaiti . vsimrti . app . tutorials . barnim . W e a t h e r W a r n i n g A p p " , " ⤦
Ç com . dcaiti . vsimrti . app . tutorials . barnim . SlowDownApp " ] ,
" name " : " PKW " ,
" weight " :0.2
},
{
" applications " :[ " com . dcaiti . vsimrti . app . tutorials . barnim . SlowDownApp " ] ,
" name " : " PKW " ,
" weight " :0.6
},
{
" applications " :[ " com . dcaiti . vsimrti . app . tutorials . barnim . SlowDownApp " ] ,
" name " : " electricPKW " ,
" weight " :0.1
}
]
}
]

45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

B.2 File listings

}
Listing B.5: Scenario Barnim: file listing:mapping3/mapping_config.json

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

111

Appendix B Example scenario Barnim

B.2 File listings

sns/sns_config.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

{
" version " : " 0.16.0 " ,
" singlehop " : {
" _singlehop radius in m " : 0 ,
" radius " :
509.4 ,
" _delay config according to vsimrti - communication " : 0 ,
" delay " : {
" type " :
" SimpleRandomDelay ",
" steps " :
5,
" minDelay " :
0.4 ,
" maxDelay " :
2.4 ,
" prpl " :
0,
" retries " :
0
}
},
" multihop " : {
" _delay config according to vsimrti - communication " : 0 ,
" delay " : {
" type " :
" GammaRandomDelay ",
" minDelay " :
10 ,
" expDelay " :
30 ,
" prpl " :
0,
" retries " :
2
}
}
}
Listing B.6: Scenario Barnim: file listing: sns/sns_config.json

sources/Barnim_fixed.osm

Note: This file is partially listed.
1
2
3
4
5
6
7
8
9
10
11
12
13
14


< osm version = ’ 0.6 ’ upload = ’ true ’ generator = ’ JOSM ’ >
< bounds minlat = ’ 52.59241 ’ minlon = ’ 13.51215 ’ maxlat = ’ 52.65827 ’ maxlon = ’ 13.6227 ’ origin = ’ ⤦
Ç CGImap 0.3.3 (11990 thorn -02. openstreetmap . org ) ’ / >
< node id = ’ 9671195 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 43566 ’ user = ’ anbr ’ visible = ’ true ’ ⤦
Ç version = ’4 ’ changeset = ’ 2383615 ’ lat = ’ 52.5798854 ’ lon = ’ 13.6374307 ’ / >
< node id = ’ 9671197 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 43566 ’ user = ’ anbr ’ visible = ’ true ’ ⤦
Ç version = ’5 ’ changeset = ’ 14033189 ’ lat = ’ 52.5905574 ’ lon = ’ 13.6219588 ’ / >
< node id = ’ 9671202 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 429794 ’ user = ’ SennaHB ’ visible = ’ ⤦
Ç true ’ version = ’5 ’ changeset = ’ 13985567 ’ lat = ’ 52.6051075 ’ lon = ’ 13.5993505 ’ / >
< node id = ’ 21508739 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 43566 ’ user = ’ anbr ’ visible = ’ true ’ ⤦
Ç version = ’6 ’ changeset = ’ 17739489 ’ lat = ’ 52.6639091 ’ lon = ’ 13.5696135 ’ / >
< node id = ’ 21508746 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 118278 ’ user = ’ Panketaler ’ visible = ⤦
Ç ’ true ’ version = ’ 12 ’ changeset = ’ 19973396 ’ lat = ’ 52.6240762 ’ lon = ’ 13.5434165 ’ / >
< node id = ’ 21508747 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 118278 ’ user = ’ Panketaler ’ visible = ⤦
Ç ’ true ’ version = ’ 27 ’ changeset = ’ 4921151 ’ lat = ’ 52.6297992 ’ lon = ’ 13.5459023 ’ / >
< node id = ’ 21508748 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 118278 ’ user = ’ Panketaler ’ visible = ⤦
Ç ’ true ’ version = ’4 ’ changeset = ’ 4746323 ’ lat = ’ 52.6392207 ’ lon = ’ 13.5605381 ’ / >
< node id = ’ 21508756 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 118278 ’ user = ’ Panketaler ’ visible = ⤦
Ç ’ true ’ version = ’6 ’ changeset = ’ 19973383 ’ lat = ’ 52.6266342 ’ lon = ’ 13.5441771 ’ / >
< node id = ’ 21508757 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 43566 ’ user = ’ anbr ’ visible = ’ true ’ ⤦
Ç version = ’4 ’ changeset = ’ 17739489 ’ lat = ’ 52.662124 ’ lon = ’ 13.569613 ’ / >
< node id = ’ 21508763 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 429794 ’ user = ’ SennaHB ’ visible = ’ ⤦
Ç true ’ version = ’8 ’ changeset = ’ 18626470 ’ lat = ’ 52.614571 ’ lon = ’ 13.5536105 ’ / >
< node id = ’ 26971235 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 429794 ’ user = ’ SennaHB ’ visible = ’ ⤦
Ç true ’ version = ’9 ’ changeset = ’ 16740262 ’ lat = ’ 52.6126837 ’ lon = ’ 13.5681426 ’ / >

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

112

Appendix B Example scenario Barnim

15
16
17
18
19
20
21
22

B.2 File listings

< node id = ’ 26971236 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 429794 ’ user = ’ SennaHB ’ visible = ’ ⤦
Ç true ’ version = ’9 ’ changeset = ’ 16740262 ’ lat = ’ 52.6124118 ’ lon = ’ 13.5701801 ’ / >
< node id = ’ 26971237 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 579301 ’ user = ’ Lamarqe ’ visible = ’ ⤦
Ç true ’ version = ’5 ’ changeset = ’ 12440961 ’ lat = ’ 52.6236544 ’ lon = ’ 13.5757994 ’ / >
< node id = ’ 26971240 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 429794 ’ user = ’ SennaHB ’ visible = ’ ⤦
Ç true ’ version = ’5 ’ changeset = ’ 13985567 ’ lat = ’ 52.6137568 ’ lon = ’ 13.564784 ’ / >
< node id = ’ 26971241 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 90528 ’ user = ’ Peter Maiwald ’ ⤦
Ç visible = ’ true ’ version = ’4 ’ changeset = ’ 8364243 ’ lat = ’ 52.6135612 ’ lon = ’ 13.565324 ’ / >
< node id = ’ 26971244 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 429794 ’ user = ’ SennaHB ’ visible = ’ ⤦
Ç true ’ version = ’6 ’ changeset = ’ 13985567 ’ lat = ’ 52.614347 ’ lon = ’ 13.5636669 ’ / >
< node id = ’ 26971267 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 429794 ’ user = ’ SennaHB ’ visible = ’ ⤦
Ç true ’ version = ’9 ’ changeset = ’ 18626470 ’ lat = ’ 52.6141673 ’ lon = ’ 13.5561542 ’ / >
< node id = ’ 26971272 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 429794 ’ user = ’ SennaHB ’ visible = ’ ⤦
Ç true ’ version = ’ 11 ’ changeset = ’ 12771612 ’ lat = ’ 52.6131516 ’ lon = ’ 13.5672267 ’ / >
< node id = ’ 26971273 ’ timestamp = ’ 2014 -03 -25 T09:54:31Z ’ uid = ’ 429794 ’ user = ’ SennaHB ’ visible = ’ ⤦
Ç true ’ version = ’ 14 ’ changeset = ’ 18626470 ’ lat = ’ 52.6150704 ’ lon = ’ 13.5439418 ’ / >
Listing B.7: Scenario Barnim: file listing: sources/Barnim_fixed.osm

sumo/Barnim.edg.xml

Note: This file is partially listed.
1
2
3
4
5

< edges >
< edge id = " 23995140 _ 2 6 0 1 6 2 5 3 9 _ 2 6 0 1 6 2 5 5 4 _ 2 6 0 1 6 2 5 3 9 " from = " 260162539 " to = " 260162554 " numLanes = ⤦
Ç " 1 " speed = " 8.33 " / >
< edge id = " 23995140 _ 2 6 0 1 6 2 5 3 9 _ 2 6 0 1 6 2 5 5 8 _ 2 6 0 1 6 2 5 3 9 " from = " 260162539 " to = " 260162558 " numLanes = ⤦
Ç " 1 " speed = " 8.33 " / >
< edge id = " 116570245 _ 1 3 1 3 8 8 5 5 0 9 _ 8 6 6 6 1 4 4 8 8 _ 1 3 1 3 8 8 5 5 0 9 " from = " 1313885509 " to = " 866613837 " ⤦
Ç numLanes = " 2 " speed = " 22.22 " / >
< edge id = " 116570245 _ 1 3 1 3 8 8 5 5 0 9 _ 8 6 6 6 1 4 4 8 8 _ 8 6 6 6 1 3 8 3 7 " from = " 866613837 " to = " 2026362890 " ⤦
Ç numLanes = " 2 " speed = " 22.22 " / >
Listing B.8: Scenario Barnim: file listing: sumo/Barnim.edg.xml

sumo/Barnim.net.xml

Note: This file is partially listed.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17



< 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 . dlr . de / 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 >
< node - files value =" D: \ dev \ scenarios \ Barnim - Startaufgabe \ applicationNT \ Barnim . nod . xml ⤦
Ç "/ >
< edge - files value =" D: \ dev \ scenarios \ Barnim - Startaufgabe \ applicationNT \ Barnim . edg . xml ⤦
Ç "/ >
< connection - files value =" D: \ dev \ scenarios \ Barnim - Startaufgabe \ applicationNT \ Barnim . con ⤦
Ç . xml "/ >

< output >
< output - file value =" D: \ dev \ scenarios \ Barnim - Startaufgabe \ applicationNT \ Barnim . net . xml ⤦
Ç "/ >


VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

113

Appendix B Example scenario Barnim

18
19
20
21
22
23
24
25
26
27
28
29
30

B.2 File listings


-->
< net version = " 0.27 " 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 . dlr . de / xsd / net_file . xsd " >
< location netOffset = " -397957.77 , -5826114.68 " convBoundary = " 0.00 ,0.00 ,9905.80 ,10297.64 " ⤦
Ç origBoundary = " 397957.77 ,5826114.68 ,407863.57 ,5836412.32 " projParameter = " ! " / >
< edge id = " :1003778301_0 " function = " internal " >
< lane id = " :1 00 3 77 8 30 1_ 0 _0 " index = " 0 " speed = " 8.33 " length = " 0.29 " shape = " ⤦
Ç 1221.68 ,7155.88 ,68.90 1221.42 ,7155.74 ,68.90 " / >

< edge id = " :1003778301_1 " function = " internal " >
< lane id = " :1 00 3 77 8 30 1_ 1 _0 " index = " 0 " speed = " 8.33 " length = " 0.31 " shape = " ⤦
Ç 1223.08 ,7152.88 ,68.90 1223.34 ,7153.03 ,68.90 " / >

Listing B.9: Scenario Barnim: file listing: sumo/Barnim.net.xml

sumo/Barnim.nod.xml

Note: This file is partially listed.
1
2
3
4
5

< nodes >
< node
< node
< node
< node

id = " 866613617 " x = " 401721.2894 " y = " 5830383.5757 " z = " 58.9788 " type = " priority " / >
id = " 2632245436 " x = " 399909.1546 " y = " 5834705.7934 " z = " 60.0000 " type = " priority " / >
id = " 41240371 " x = " 405205.4892 " y = " 5835368.8690 " z = " 69.9442 " type = " priority " / >
id = " 268746480 " x = " 402891.3857 " y = " 5833194.2388 " z = " 68.1866 " type = " priority " / >
Listing B.10: Scenario Barnim: file listing: sumo/Barnim.nod.xml

sumo/Barnim.rou.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22



< 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 / d u a r o u t e r C o n f i g u r a t i o n . xsd " >
< input >

< trip - files value =".\ trips . xml "/ >

< output >
< output - file value =" Barnim . rou . xml "/ >


-->
< routes 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 / routes_file . xsd " >


VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

114

Appendix B Example scenario Barnim

23

24

< route
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
< route
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç

B.2 File listings

id = " 1 " edges = " 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 4 5 0 9 3 8 9 1 4 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 73017982 ⤦
_ 3 9 9 3 3 9 2 1 _ 2 0 2 6 3 6 2 9 4 0 _ 3 9 9 3 3 9 2 1 73017982 _ 3 9 9 3 3 9 2 1 _ 2 0 2 6 3 6 2 9 4 0 _ 2 0 2 6 3 6 2 9 4 3 -3366 ⤦
_ 2 0 2 6 3 6 2 9 4 0 _ 1 3 1 3 8 8 5 5 0 2 _ 2 0 2 6 3 6 2 9 4 0 -3366 _ 2 0 2 6 3 6 2 9 4 0 _ 1 3 1 3 8 8 5 5 0 2 _ 2 0 2 6 3 6 2 9 3 8 -3366 ⤦
_ 2 0 2 6 3 6 2 9 4 0 _ 1 3 1 3 8 8 5 5 0 2 _ 2 3 6 4 4 7 4 8 5 1 -3366 _ 2 0 2 6 3 6 2 9 4 0 _ 1 3 1 3 8 8 5 5 0 2 _ 1 3 1 3 8 8 5 4 4 2 -3366 ⤦
_ 2 0 2 6 3 6 2 9 4 0 _ 1 3 1 3 8 8 5 5 0 2 _ 2 0 2 6 3 6 2 9 3 4 -3366 _ 2 0 2 6 3 6 2 9 4 0 _ 1 3 1 3 8 8 5 5 0 2 _ 2 3 6 4 4 7 4 8 5 0 -3366 ⤦
_ 2 0 2 6 3 6 2 9 4 0 _ 1 3 1 3 8 8 5 5 0 2 _ 2 0 2 6 3 6 2 9 3 0 -3366 _ 2 0 2 6 3 6 2 9 4 0 _ 1 3 1 3 8 8 5 5 0 2 _ 2 0 2 6 3 6 2 9 2 9 73017981 ⤦
_ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 1 3 1 3 8 8 5 5 0 2 73017981 _ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 2 3 6 4 4 7 4 8 4 9 73017981 ⤦
_ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 1 3 1 3 8 8 5 4 9 3 73017981 _ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 2 3 6 4 4 7 4 8 4 7 73017981 ⤦
_ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 1 3 1 3 8 8 5 4 5 5 73017981 _ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 1 3 1 3 8 8 5 4 5 2 73017981 ⤦
_ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 8 6 6 6 1 4 2 1 8 73017981 _ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 1 3 1 3 8 8 5 4 7 4 73017981 ⤦
_ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 8 6 6 6 1 4 1 2 7 73017981 _ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 8 6 6 6 1 4 3 7 9 73017981 ⤦
_ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 8 6 6 6 1 4 7 6 0 73017981 _ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 8 6 6 6 1 3 7 6 1 73017981 ⤦
_ 1 3 1 3 8 8 5 5 0 2 _ 8 6 6 6 1 4 5 2 6 _ 8 6 6 6 1 4 2 5 4 116570220 _ 8 6 6 6 1 4 5 2 6 _ 8 6 6 6 1 3 6 1 1 _ 8 6 6 6 1 4 5 2 6 116570220 ⤦
_ 8 6 6 6 1 4 5 2 6 _ 8 6 6 6 1 3 6 1 1 _ 1 3 1 3 8 8 5 3 8 3 116570220 _ 8 6 6 6 1 4 5 2 6 _ 8 6 6 6 1 3 6 1 1 _ 2 3 1 4 3 7 4 8 3 0 116570220 ⤦
_ 8 6 6 6 1 4 5 2 6 _ 8 6 6 6 1 3 6 1 1 _ 2 0 2 6 3 6 2 9 1 8 73017984 _ 8 6 6 6 1 3 6 1 1 _ 8 6 6 6 1 3 6 9 3 _ 8 6 6 6 1 3 6 1 1 73017984 ⤦
_ 8 6 6 6 1 3 6 1 1 _ 8 6 6 6 1 3 6 9 3 _ 2 5 3 8 5 7 4 1 9 1 73017984 _ 8 6 6 6 1 3 6 1 1 _ 8 6 6 6 1 3 6 9 3 _ 1 3 1 3 8 8 5 5 2 1 73017984 ⤦
_ 8 6 6 6 1 3 6 1 1 _ 8 6 6 6 1 3 6 9 3 _ 1 3 1 3 8 8 5 4 8 9 73017984 _ 8 6 6 6 1 3 6 1 1 _ 8 6 6 6 1 3 6 9 3 _ 8 6 6 6 1 4 3 6 2 73017984 ⤦
_ 8 6 6 6 1 3 6 1 1 _ 8 6 6 6 1 3 6 9 3 _ 8 6 6 6 1 4 7 0 0 106057563 _ 8 6 6 6 1 3 6 9 3 _ 8 6 6 6 1 4 4 7 4 _ 8 6 6 6 1 3 6 9 3 106057563 ⤦
_ 8 6 6 6 1 3 6 9 3 _ 8 6 6 6 1 4 4 7 4 _ 8 6 6 6 1 4 2 0 7 106057563 _ 8 6 6 6 1 3 6 9 3 _ 8 6 6 6 1 4 4 7 4 _ 1 3 1 3 8 8 5 4 1 3 106057563 ⤦
_ 8 6 6 6 1 3 6 9 3 _ 8 6 6 6 1 4 4 7 4 _ 1 3 1 3 8 8 5 4 5 1 116570250 _ 8 6 6 6 1 4 4 7 4 _ 8 6 6 6 1 3 8 3 3 _ 8 6 6 6 1 4 4 7 4 116570250 ⤦
_ 8 6 6 6 1 4 4 7 4 _ 8 6 6 6 1 3 8 3 3 _ 2 0 2 6 3 6 2 8 5 5 116570250 _ 8 6 6 6 1 4 4 7 4 _ 8 6 6 6 1 3 8 3 3 _ 1 3 1 3 8 8 5 4 7 3 116570237 ⤦
_ 8 6 6 6 1 3 8 3 3 _ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 3 8 3 3 116570237 _ 8 6 6 6 1 3 8 3 3 _ 8 6 6 6 1 3 9 9 2 _ 1 3 1 3 8 8 5 4 8 4 116570237 ⤦
_ 8 6 6 6 1 3 8 3 3 _ 8 6 6 6 1 3 9 9 2 _ 2 0 2 6 3 6 2 8 4 2 116570237 _ 8 6 6 6 1 3 8 3 3 _ 8 6 6 6 1 3 9 9 2 _ 1 3 1 3 8 8 5 3 8 6 116570237 ⤦
_ 8 6 6 6 1 3 8 3 3 _ 8 6 6 6 1 3 9 9 2 _ 1 3 1 3 8 8 5 5 2 4 116570237 _ 8 6 6 6 1 3 8 3 3 _ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 1 9 5 116570237 ⤦
_ 8 6 6 6 1 3 8 3 3 _ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 5 7 0 116570237 _ 8 6 6 6 1 3 8 3 3 _ 8 6 6 6 1 3 9 9 2 _ 1 3 1 3 8 8 5 4 4 1 116570237 ⤦
_ 8 6 6 6 1 3 8 3 3 _ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 3 4 9 7 165881196 _ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 8 6 6 6 1 3 9 9 2 165881196 ⤦
_ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 8 6 6 6 1 4 6 8 4 165881196 _ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 1 3 1 3 8 8 5 5 4 8 165881196 ⤦
_ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 1 3 1 3 8 8 5 5 3 1 165881196 _ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 2 0 2 6 3 6 2 8 4 7 165881196 ⤦
_ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 1 3 1 3 8 8 5 5 1 1 165881196 _ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 2 0 2 6 3 6 2 8 4 8 165881196 ⤦
_ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 1 3 1 3 8 8 5 5 1 5 165881196 _ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 1 3 1 3 8 8 5 4 7 1 165881196 ⤦
_ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 1 3 1 3 8 8 5 4 3 5 165881196 _ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 1 3 1 3 8 8 5 3 9 3 165881196 ⤦
_ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 1 3 1 3 8 8 5 4 9 2 165881196 _ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 1 3 1 3 8 8 5 4 5 4 165881196 ⤦
_ 8 6 6 6 1 3 9 9 2 _ 8 6 6 6 1 4 3 2 0 _ 1 3 1 3 8 8 5 4 1 5 232375390 _ 8 6 6 6 1 4 3 2 0 _ 8 6 6 6 1 4 3 2 3 _ 8 6 6 6 1 4 3 2 0 232375390 ⤦
_ 8 6 6 6 1 4 3 2 3 _ 8 6 6 6 1 4 0 6 2 _ 8 6 6 6 1 4 3 2 3 248048346 _ 8 6 6 6 1 4 0 6 2 _ 8 6 6 6 1 3 5 0 6 _ 8 6 6 6 1 4 0 6 2 248048344 ⤦
_ 8 6 6 6 1 3 5 0 6 _ 8 6 6 6 1 3 5 5 5 _ 8 6 6 6 1 3 5 0 6 245434998 _ 8 6 6 6 1 3 5 5 5 _ 1 3 1 3 8 8 5 5 3 2 _ 8 6 6 6 1 3 5 5 5 245434998 ⤦
_ 8 6 6 6 1 3 5 5 5 _ 1 3 1 3 8 8 5 5 3 2 _ 2 3 8 9 9 8 6 8 1 8 245434998 _ 8 6 6 6 1 3 5 5 5 _ 1 3 1 3 8 8 5 5 3 2 _ 8 6 6 6 1 3 9 0 5 116570222 ⤦
_ 1 3 1 3 8 8 5 5 3 2 _ 2 0 2 6 3 6 2 8 1 4 _ 1 3 1 3 8 8 5 5 3 2 116570222 _ 1 3 1 3 8 8 5 5 3 2 _ 2 0 2 6 3 6 2 8 1 4 _ 1 3 1 3 8 8 5 4 3 1 ⤦
116570222 _ 1 3 1 3 8 8 5 5 3 2 _ 2 0 2 6 3 6 2 8 1 4 _ 2 0 2 6 3 6 2 8 2 7 116570222 ⤦
_ 1 3 1 3 8 8 5 5 3 2 _ 2 0 2 6 3 6 2 8 1 4 _ 2 0 2 6 3 6 2 8 2 1 192079314 _ 2 0 2 6 3 6 2 8 1 4 _ 6 9 2 7 5 5 3 8 1 _ 2 0 2 6 3 6 2 8 1 4 ⤦
192079314 _ 2 0 2 6 3 6 2 8 1 4 _ 6 9 2 7 5 5 3 8 1 _ 2 5 1 0 5 7 5 5 6 7 182262835 _ 6 9 2 7 5 5 3 8 1 _ 4 9 8 3 2 2 9 8 _ 6 9 2 7 5 5 3 8 1 " / >
id = " 2 " edges = " 4067968 _ 2 8 8 3 0 2 1 9 _ 3 9 9 3 3 9 2 7 _ 2 4 5 0 9 3 8 9 1 4 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 3 5 3 7 6 8 9 1 _ 3 9 9 3 3 9 2 7 5477467 ⤦
_ 3 9 9 3 3 9 2 7 _ 3 3 5 3 7 6 8 9 1 _ 3 9 9 3 4 0 6 5 5477467 _ 3 9 9 3 3 9 2 7 _ 3 3 5 3 7 6 8 9 1 _ 2 6 7 9 2 3 7 3 7 5477467 ⤦
_ 3 9 9 3 3 9 2 7 _ 3 3 5 3 7 6 8 9 1 _ 2 6 7 9 2 3 7 3 9 5477467 _ 3 9 9 3 3 9 2 7 _ 3 3 5 3 7 6 8 9 1 _ 2 6 7 9 2 3 7 4 1 166752304 ⤦
_ 3 3 5 3 7 6 8 9 1 _ 3 9 9 3 3 9 1 7 _ 3 3 5 3 7 6 8 9 1 166752304 _ 3 9 9 3 3 9 1 7 _ 7 5 6 6 6 5 9 4 _ 3 9 9 3 3 9 1 7 166752304 ⤦
_ 3 9 9 3 3 9 1 7 _ 7 5 6 6 6 5 9 4 _ 5 6 4 0 0 6 5 8 0 166752304 _ 7 5 6 6 6 5 9 4 _ 7 5 6 7 3 0 5 7 _ 7 5 6 6 6 5 9 4 166752304 ⤦
_ 7 5 6 6 6 5 9 4 _ 7 5 6 7 3 0 5 7 _ 7 6 5 6 5 7 0 1 166752304 _ 7 5 6 6 6 5 9 4 _ 7 5 6 7 3 0 5 7 _ 7 3 9 3 5 6 8 4 7 166752304 ⤦
_ 7 5 6 6 6 5 9 4 _ 7 5 6 7 3 0 5 7 _ 2 1 5 0 8 7 4 8 166752304 _ 7 5 6 6 6 5 9 4 _ 7 5 6 7 3 0 5 7 _ 7 3 9 3 5 6 8 3 9 166752304 ⤦
_ 7 5 6 7 3 0 5 7 _ 3 0 3 1 8 4 5 1 9 _ 7 5 6 7 3 0 5 7 166752304 _ 7 5 6 7 3 0 5 7 _ 3 0 3 1 8 4 5 1 9 _ 7 3 9 3 5 6 8 3 0 166752304 ⤦
_ 3 0 3 1 8 4 5 1 9 _ 1 7 8 1 9 6 3 8 8 7 _ 3 0 3 1 8 4 5 1 9 166752301 _ 1 7 8 1 9 6 3 8 8 7 _ 7 3 5 8 6 2 6 8 _ 1 7 8 1 9 6 3 8 8 7 166752301 ⤦
_ 1 7 8 1 9 6 3 8 8 7 _ 7 3 5 8 6 2 6 8 _ 2 2 5 0 6 8 3 3 8 7 30602177 _ 7 3 5 8 6 2 6 8 _ 7 5 6 7 9 6 4 4 _ 7 3 5 8 6 2 6 8 30602177 ⤦
_ 7 3 5 8 6 2 6 8 _ 7 5 6 7 9 6 4 4 _ 7 6 5 9 6 5 5 1 1 229068361 _ 7 5 6 7 9 6 4 4 _ 2 1 5 0 8 7 4 7 _ 7 5 6 7 9 6 4 4 229068361 ⤦
_ 2 1 5 0 8 7 4 7 _ 2 6 2 1 1 5 2 9 8 6 _ 2 1 5 0 8 7 4 7 229068361 _ 2 1 5 0 8 7 4 7 _ 2 6 2 1 1 5 2 9 8 6 _ 7 6 5 9 6 5 5 0 9 229068361 ⤦
_ 2 1 5 0 8 7 4 7 _ 2 6 2 1 1 5 2 9 8 6 _ 2 6 2 5 9 8 2 3 3 3 229068361 _ 2 1 5 0 8 7 4 7 _ 2 6 2 1 1 5 2 9 8 6 _ 2 6 2 1 1 5 3 0 1 0 229068361 ⤦
_ 2 1 5 0 8 7 4 7 _ 2 6 2 1 1 5 2 9 8 6 _ 2 6 2 1 1 5 3 0 0 9 229068361 _ 2 1 5 0 8 7 4 7 _ 2 6 2 1 1 5 2 9 8 6 _ 2 6 2 1 1 5 3 0 0 3 229068361 ⤦
_ 2 1 5 0 8 7 4 7 _ 2 6 2 1 1 5 2 9 8 6 _ 2 6 2 1 1 5 2 9 9 9 229068361 _ 2 1 5 0 8 7 4 7 _ 2 6 2 1 1 5 2 9 8 6 _ 7 3 5 8 6 2 6 4 229068361 ⤦
_ 2 1 5 0 8 7 4 7 _ 2 6 2 1 1 5 2 9 8 6 _ 2 1 5 0 8 7 5 6 229068361 _ 2 6 2 1 1 5 2 9 8 6 _ 2 6 2 1 1 5 2 9 8 3 _ 2 6 2 1 1 5 2 9 8 6 111283478 ⤦
_ 2 6 2 1 1 5 2 9 8 3 _ 2 6 2 1 1 5 2 9 7 4 _ 2 6 2 1 1 5 2 9 8 3 111283478 _ 2 6 2 1 1 5 2 9 8 3 _ 2 6 2 1 1 5 2 9 7 4 _ 2 6 2 1 1 5 2 9 7 7 ⤦
111283478 _ 2 6 2 1 1 5 2 9 8 3 _ 2 6 2 1 1 5 2 9 7 4 _ 2 6 2 1 1 5 2 9 7 5 229068360 ⤦
_ 2 6 2 1 1 5 2 9 7 4 _ 2 6 2 1 1 5 2 9 7 2 _ 2 6 2 1 1 5 2 9 7 4 229068360 _ 2 6 2 1 1 5 2 9 7 2 _ 2 1 5 0 8 7 4 6 _ 2 6 2 1 1 5 2 9 7 2 229068360 ⤦
_ 2 6 2 1 1 5 2 9 7 2 _ 2 1 5 0 8 7 4 6 _ 6 0 1 0 5 9 3 5 2 229068360 _ 2 6 2 1 1 5 2 9 7 2 _ 2 1 5 0 8 7 4 6 _ 1 6 0 0 9 9 1 1 5 8 229068360 ⤦
_ 2 6 2 1 1 5 2 9 7 2 _ 2 1 5 0 8 7 4 6 _ 1 6 0 0 9 9 1 1 6 0 229068357 _ 2 1 5 0 8 7 4 6 _ 2 5 1 0 5 6 4 8 0 6 _ 2 1 5 0 8 7 4 6 229068357 ⤦
_ 2 1 5 0 8 7 4 6 _ 2 5 1 0 5 6 4 8 0 6 _ 1 6 0 0 9 9 1 1 5 9 229068357 _ 2 1 5 0 8 7 4 6 _ 2 5 1 0 5 6 4 8 0 6 _ 1 6 0 0 9 9 1 1 5 5 229068357 ⤦
_ 2 1 5 0 8 7 4 6 _ 2 5 1 0 5 6 4 8 0 6 _ 2 3 7 7 0 5 0 4 0 2 229068357 _ 2 1 5 0 8 7 4 6 _ 2 5 1 0 5 6 4 8 0 6 _ 1 6 0 0 9 9 1 1 5 7 229068357 ⤦

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

115

Appendix B Example scenario Barnim

Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç
Ç

25
26
27
28

B.2 File listings

_ 2 1 5 0 8 7 4 6 _ 2 5 1 0 5 6 4 8 0 6 _ 6 6 1 7 4 9 2 4 0 229068357 _ 2 1 5 0 8 7 4 6 _ 2 5 1 0 5 6 4 8 0 6 _ 4 1 6 0 6 5 9 5 9 229068357 ⤦
_ 2 1 5 0 8 7 4 6 _ 2 5 1 0 5 6 4 8 0 6 _ 1 6 0 0 9 9 1 1 5 4 229068357 _ 2 1 5 0 8 7 4 6 _ 2 5 1 0 5 6 4 8 0 6 _ 6 6 1 7 4 9 2 3 7 146875503 ⤦
_ 2 5 1 0 5 6 4 8 0 6 _ 2 7 0 3 1 2 3 2 _ 2 5 1 0 5 6 4 8 0 6 146875503 _ 2 5 1 0 5 6 4 8 0 6 _ 2 7 0 3 1 2 3 2 _ 1 6 0 0 9 9 1 1 5 3 146875503 ⤦
_ 2 5 1 0 5 6 4 8 0 6 _ 2 7 0 3 1 2 3 2 _ 1 6 0 0 9 9 1 1 5 6 146875503 _ 2 5 1 0 5 6 4 8 0 6 _ 2 7 0 3 1 2 3 2 _ 1 5 8 7 7 0 0 3 4 2 146875503 ⤦
_ 2 5 1 0 5 6 4 8 0 6 _ 2 7 0 3 1 2 3 2 _ 2 5 1 0 5 6 4 8 0 4 146871033 _ 2 7 0 3 1 2 3 2 _ 2 7 0 3 1 2 2 9 _ 2 7 0 3 1 2 3 2 227901601 ⤦
_ 2 7 0 3 1 2 2 9 _ 8 6 6 6 1 3 8 4 1 _ 2 7 0 3 1 2 2 9 227901601 _ 2 7 0 3 1 2 2 9 _ 8 6 6 6 1 3 8 4 1 _ 2 5 2 6 3 9 0 8 5 9 227901601 ⤦
_ 2 7 0 3 1 2 2 9 _ 8 6 6 6 1 3 8 4 1 _ 8 6 6 6 1 3 7 9 9 227901601 _ 2 7 0 3 1 2 2 9 _ 8 6 6 6 1 3 8 4 1 _ 8 6 6 6 1 4 0 0 8 227901601 ⤦
_ 2 7 0 3 1 2 2 9 _ 8 6 6 6 1 3 8 4 1 _ 1 3 1 3 8 8 5 4 3 9 227901601 _ 2 7 0 3 1 2 2 9 _ 8 6 6 6 1 3 8 4 1 _ 1 3 1 3 8 8 5 5 2 7 227901601 ⤦
_ 2 7 0 3 1 2 2 9 _ 8 6 6 6 1 3 8 4 1 _ 1 3 1 3 8 8 5 4 3 6 227901601 _ 2 7 0 3 1 2 2 9 _ 8 6 6 6 1 3 8 4 1 _ 8 6 6 6 1 3 7 8 6 245432872 ⤦
_ 8 6 6 6 1 3 8 4 1 _ 8 6 6 6 1 4 5 7 8 _ 8 6 6 6 1 3 8 4 1 116570239 _ 8 6 6 6 1 4 5 7 8 _ 8 6 6 6 1 3 5 5 5 _ 8 6 6 6 1 4 5 7 8 116570239 ⤦
_ 8 6 6 6 1 4 5 7 8 _ 8 6 6 6 1 3 5 5 5 _ 1 3 1 3 8 8 5 4 5 6 245434998 _ 8 6 6 6 1 3 5 5 5 _ 1 3 1 3 8 8 5 5 3 2 _ 8 6 6 6 1 3 5 5 5 245434998 ⤦
_ 8 6 6 6 1 3 5 5 5 _ 1 3 1 3 8 8 5 5 3 2 _ 2 3 8 9 9 8 6 8 1 8 245434998 _ 8 6 6 6 1 3 5 5 5 _ 1 3 1 3 8 8 5 5 3 2 _ 8 6 6 6 1 3 9 0 5 116570222 ⤦
_ 1 3 1 3 8 8 5 5 3 2 _ 2 0 2 6 3 6 2 8 1 4 _ 1 3 1 3 8 8 5 5 3 2 116570222 _ 1 3 1 3 8 8 5 5 3 2 _ 2 0 2 6 3 6 2 8 1 4 _ 1 3 1 3 8 8 5 4 3 1 ⤦
116570222 _ 1 3 1 3 8 8 5 5 3 2 _ 2 0 2 6 3 6 2 8 1 4 _ 2 0 2 6 3 6 2 8 2 7 116570222 ⤦
_ 1 3 1 3 8 8 5 5 3 2 _ 2 0 2 6 3 6 2 8 1 4 _ 2 0 2 6 3 6 2 8 2 1 192079314 _ 2 0 2 6 3 6 2 8 1 4 _ 6 9 2 7 5 5 3 8 1 _ 2 0 2 6 3 6 2 8 1 4 ⤦
192079314 _ 2 0 2 6 3 6 2 8 1 4 _ 6 9 2 7 5 5 3 8 1 _ 2 5 1 0 5 7 5 5 6 7 182262835 _ 6 9 2 7 5 5 3 8 1 _ 4 9 8 3 2 2 9 8 _ 6 9 2 7 5 5 3 8 1 " / >

 Standard route ⤦
Ç -->
 Ausweichroute ⤦
Ç -->

Listing B.11: Scenario Barnim: file listing: sumo/Barnim.roud.xml

sumo/Barnim.sumo.cfg
1
2
3
4
5
6
7
8
9
10

< configuration >
< input >

< route - files value = " Barnim . rou . xml " / >

< time >
< begin value = " 0 " / >
< end value = " 10000 " / >


Listing B.12: Scenario Barnim: file listing: sumo/Barnim.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 " : " Barnim . sumo . cfg "
}
Listing B.13: Scenario Barnim: file listing: sumo/sumo_config.json

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

116

Appendix B Example scenario Barnim

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

ïż£ 

< 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 / 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 = " true " 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 
< directory >. 
< separator >; 
< messages >
< message id = " V e h i c l e M o v e m e n t s " >
< entries >
< entry >" MOVE_VEHICLE " 
< entry > Time 
< entry > Updated:Name 
< entry > U p d a t e d : P o s i t i o n . Latitude 
< entry > U p d a t e d : P o s i t i o n . Longitude 
< entry > Updated:Speed 
< entry > U pd at e d: H ea di n g 


< message id = " R e c e i v e V 2 X M e s s a g e " >
< entries >
< entry >" RECV_MESSAGE " 
< entry > Time 
< entry > MessageId 
< entry > ReceiverName 
< entry > Type 


< message id = " S endV2X Messag e " >
< entries >
< entry >" SEND_MESSAGE " 
< entry > Time 
< entry > MessageId 
< entry > SourceName 
< entry > Type 
 Destination . Position . Latitude  -->
 Destination . Position . Longitude  -->
 Destination . Radius  -->


< message id = " AddedVehicle " enabled = " true " >
< entries >
< entry >" ADDED_VEHICLE " 
< entry > Time 
< entry > A p p l i c a t i o n V e h i c l e . Name 
< entry > A p p l i c a t i o n V e h i c l e . Applications 
< entry > A p p l i c a t i o n V e h i c l e . VehicleType . Name 


< 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 > Time 
< 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 > 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 > T r a f f i c L i g h t G r o u p . FirstPosition . Latitude 
< entry > T r a f f i c L i g h t G r o u p . FirstPosition . Longitude 


< message id = " AddedRsu " >
< entries >

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

117

Appendix B Example scenario Barnim

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

B.2 File listings

< entry >" ADDED_RSU " 
< entry > Time 
< entry > Applic ationR su . Name 
< entry > Applic ationR su . Applications 
< entry > Applic ationR su . Position . Latitude 
< entry > Applic ationR su . Position . Longitude 




< 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 . ⤦
Ç EworldVisualizerConfig ">
< synchronized > true 
< host > local 
< port > 50500 
< messages >
< message id = " A d d e d T r a f f i c L i g h t " > 
< message id = " AddedRsu " > 
< message id = " AddedVehicle " > 
< message id = " V e h i c l e M o v e m e n t s " > 


< visualizer id = " websocket " enabled = " true " loader = " com . dcaiti . vsimrti . fed . visualizer . ⤦
Ç WebsocketVisualizerConfig ">
< synchronized > true 
< port > 46587 
< messages >
< message id = " V e h i c l e M o v e m e n t s " enabled = " true " > 
< message id = " R e c e i v e V 2 X M e s s a g e " enabled = " true " > 
< message id = " S endV2X Messag e " enabled = " true " > 
< message id = " R e c e i v e C e l l M e s s a g e " enabled = " false " > 
< message id = " Se n dC el l Me s sa ge " enabled = " false " > 
< message id = " AddedVehicle " enabled = " true " > 
< message id = " AddedRsu " enabled = " true " > 
< message id = " A d d e d T r a f f i c L i g h t " enabled = " false " > 
< 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 id = " C h a r g i n g S t a t i o n U p d a t e " enabled = " false " > 



Listing B.14: Scenario Barnim: file listing: visualizer/visualizer_config.xml

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

118

Appendix B Example scenario Barnim

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
49
50
51
52
53
54
55
56
57
58
59
60
61

ïż£ 
< 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 = " https: // www . dcaiti . tu - berlin . de / research / ⤦
Ç simulation / download / get / scenarios / scenarioname / vsimrti / v simrti _confi g . ⤦
Ç xsd " >
< simulation >

< id > Barnim 

< starttime >0 
< endtime > 1200 

< randomSeed > 268965854 



< WGS84UTMTransformConfig >
{
" centerCoordinates ": {
" longitude " : 13.56 ,
" latitude " : 52.63
},
" ca r te si a nO ff s et " : {
" x " : -397957.77 ,
" y " : -5826114.68
}
}


< IPResolverConfig >
{
netMask: " 255.255.0.0 " ,
vehicleNet: " 10.1.0.0 " ,
rsuNet: " 10.2.0.0 " ,
tlNet: " 10.3.0.0 " ,
csNet: " 10.4.0.0 " ,
serverNet: " 10.5.0.0 "
}

< threads >1 

< federates >

< federate id = " cell2 " active = " false " / >

< federate id = " omnetpp " active = " false " / >
< federate id = " ns3 " active = " false " / >
< federate id = " sns " active = " true " / >

< federate id = " sumo " active = " true " / >

< federate id = " applicationNT " active = " true " / >

< federate id = " eventserver " active = " true " / >

< federate id = " battery " active = " true " / >
< federate id = " ch ar g in g st at i on " active = " false " / >

< federate id = " mapping3 " active = " true " / >

< federate id = " visualizer " active = " true " / >



VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

119

Appendix B Example scenario Barnim

B.2 File listings

Listing B.15: Scenario Barnim: file listing: vsimrti/vsimrti_config.xml

vsimrti/simrun_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




< 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 / scenarios / scenarioname / vsimrti / simrun_config . xsd " >

< vsimrti location = " / path / to / your / vs imrti_ folder " executable = " vsimrti . sh " username = " ⤦
Ç your_user_id " / >
< scenario name = " Barnim " config = " scenarios / Barnim / vsimrti / v simrti _confi g . xml " persistent = " ⤦
Ç false " repetitions = " 1 " progr essLog ger = " true " >
 - o TRACE 
 - w 0 


< dimension name = " Si mulati onRuns " >
< parameter name = " V 2 X V e h i c l e P e r c e n t a g e " file = " mapping3 / mappi ng_con fig . json " fileFormat = " ⤦
Ç json " item = " vehicles [0]. types [0]. weight " type = " ValueList " >
< value >0 
< value > 50 
< value > 75 
< value >0 
< value >0 

< parameter name = " C e l l V e h i c l e P e r c e n t a g e " file = " mapping3 / mappi ng_con fig . json " fileFormat ⤦
Ç = " json " item = " vehicles [0]. types [0]. weight " type = " ValueList " >
< value >0 
< value >0 
< value >0 
< value > 50 
< value > 75 

< parameter name = " C l a s s i c V e h i c l e P e r c e n t a g e " file = " mapping3 / mappi ng_con fig . json " ⤦
Ç fileFormat = " json " item = " vehicles [0]. types [2]. weight " type = " ValueList " >
< value > 100 
< value > 50 
< value > 25 
< value > 50 
< value > 25 

< parameter name = " Si mulati ontim e " file = " vsimrti / vsim rti_co nfig . xml " fileFormat = " xml " item ⤦
Ç = " // simulation / endtime " type = " ValueList " >

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

121

Appendix B Example scenario Barnim

120
121
122
123
124
125
126
127
128
129
130
131
132
133

B.2 File listings

< value > 100 
< value > 100 
< value > 100 
< value > 100 
< value > 100 



< parameter name = " Si n gl eh o pR ad i us " file = " sns / sns_config . json " fileFormat = " json " item = " ⤦
Ç singlehop . radius " type = " ValueList " >
< value > 500 
< value > 600 


Listing B.16: Scenario Barnim: file listing: vsimrti/simrun_config.xml

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

122

Appendix C
Example scenario Tiergarten
You will find a collection of all relevant data.

C.1 Folder Structure
Tiergarten
applicationNT .....................................................................
applications ...................................................................
applicationNT_config.json ............................. not listed (in this release)
tiergarten.db .......................................... not listed (binary content)
cell2 ..............................................................................
cell2_config.json ...................................... not listed (in this release)
network.json ............................................ not listed (in this release)
regions.json ............................................ not listed (in this release)
mapping3 ...........................................................................
mapping_config.json .................................... not listed (in this release)
omnetpp ............................................................................
omnetpp.ini ............................................................. (see C.1)
ns3 ................................................................................
configTechnologies.xml ................................ not listed (in this release)
confWifi.xml ............................................ not listed (in this release)
sns ................................................................................
sns_config.json ........................................ not listed (in this release)
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)
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

[ General ]
# SimulationParameters
# -------------------# network *. ned - file and time - scale in nanoseconds
network = Simulation
simtime - scale = -9
# EventSchedul er
# -------------# scheduler - class and debugging option for more verbose logging
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
# connection settings , when omnetpp - federate is started manually
vsimrtieventscheduler - host = " localhost "
vsimrtieventscheduler - port = 4998
# RecordingModi
# ------------record - eventlog = false
cmdenv - express - mode = false
cmdenv - event - banners = false
# random numbers
# ------------num - rngs = 3
Simulation . mobility . rng -0 = 1
Simulation . wlan [*]. mac . rng -0 = 2
# general logging output
# -------------*. mgmt . cmdenv - ev - output = true
*. mgmt . debug = false
*. veh [*].**. cmdenv - ev - output = false
*. rsu [*].**. cmdenv - ev - output = false

# ########## application settings ############
Simulation . rsu [*]. udpApp . maxProcDelay = 1e -3
Simulation . veh [*]. udpApp . maxProcDelay = 1e -3

# ########## UDP Settings

## # ## # ## ## # ## ##

# ########## network layer settings ##########
# ########## mac and phy settings ############
**. wlan0 . opMode = " p "
**. wlan0 . bitrate = 6 Mbps
**. wlan0 . mac . basicBitrate = 3 Mbps
# we have to set this explicitly because the default value ⤦
Ç of 1 Mbps is not part of 802.11 p
**. wlan0 . mac . con trolBi trate = 3 Mbps
**. wlan0 . mac . retryLimit = 7
**. wlan0 . mac . maxQueueSize = 10
**. wlan0 . mac . cwMinData = 15
**. wlan0 . mac . cwM inMult icast = 31

**. wlan0 . radio . bandName = " 5.9 GHz " # this string actually selects the band from {2.4; 5; 5.9} ⤦
Ç ( see " IIeee 80211B and . h ")
**. wlan0 . radio . c a r r i e r F r e q u e n c y = 5.9 GHz

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

124

Appendix C Example scenario Tiergarten

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

C.2 File listings

**. wlan0 . radio . bandwidth = 10 MHz
**. wlan0 . radio . receiver . snirThreshold = 4 dB
**. wlan0 . radio . receiver . sensitivity = -81 dBm

**. wlan1 . opMode = " p "
**. wlan1 . bitrate = 6 Mbps
**. wlan1 . mac . basicBitrate = 3 Mbps
# we have to set this explicitly because the default value ⤦
Ç of 1 Mbps is not part of 802.11 p
**. wlan1 . mac . con trolBi trate = 3 Mbps
**. wlan1 . mac . retryLimit = 7
**. wlan1 . mac . maxQueueSize = 10
**. wlan1 . mac . cwMinData = 15
**. wlan1 . mac . cwM inMult icast = 31
**. wlan1 . radio . bandName = " 5.9 GHz " # this string actually selects the band from {2.4; 5; 5.9} ⤦
Ç ( see " IIeee 80211B and . h ")
**. wlan1 . radio . c a r r i e r F r e q u e n c y = 5.9 GHz
**. wlan1 . radio . bandwidth = 10 MHz
**. wlan1 . radio . receiver . snirThreshold = 4 dB
**. wlan1 . radio . receiver . sensitivity = -81 dBm
# ########## radio medium settings ###########
Simulation . radioMedium . r ad io M od e Fi lt e r = true
# use this filter for increased performance -> ⤦
Ç does not compute transmissions to receivers whose radio is turned off
Simulation . radioMedium . l is te n in g Fi lt e r = true
# second filter that may improve performance
Simulation . radioMedium . b ac kg r ou n dN oi s e . power = -110 dBm
Simulation . radioMedium . m e d i u m L i m i t C a c h e . c a r r i e r F r e q u e n c y = 5.9 GHz
Simulation . radioMedium . p ro pa g at i on Ty p e = " C o n s t a n t S p e e d P r o p a g a t i o n "
Simulation . radioMedium . pathLossType = " F r e e S p a c e P a t h L o s s "
Simulation . radioMedium . o b s t a c l e L o s s T y p e = " "
# ##########
mobility
###################
**. mobility . c o n s t r a i n t A r e a M i n X = 0 m
**. mobility . c o n s t r a i n t A r e a M i n Y = 0 m
**. mobility . c o n s t r a i n t A r e a M i n Z = 0 m
**. mobility . c o n s t r a i n t A r e a M a x X = 5000 m
**. mobility . c o n s t r a i n t A r e a M a x Y = 5000 m
**. mobility . c o n s t r a i n t A r e a M a x Z = 0 m
Listing C.1: Scenario Tiergarten: file listing: omnetpp/omnetpp.ini

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

125

Appendix D
Package Additional Examples

Appendix D Package Additional Examples

Appendix D Package Additional Examples

This package shows different sample applications for several application spectrum. Here you can download the AdditionalExamples-18.0-sources.zip file:

https://www.dcaiti.tu-berlin.de/research/simulation/download/
The following table describes these applications.
Applications from the "Additional Examples" package
HelloWorldApp

This is a simple Hello World application. It prints a hello world string
in an interval.

Interconnect

This simple application demonstrates an interconnection between
applications which are running on same units.

IntervalSampling

This simple application demonstrates a sampling in a specific interval.
When the simulation starts it initialise with a random generated offset
(e.g. 150 ms). Afterwards a fixed interval will be invoked (e.g. 1 second).
For example there are the following time steps:
t = {0 ms, 150 ms, 1150 ms, 2150 ms, ...}

MultithreadSampling

This simple application demonstrates a concurrency task. In a scenario
may exist many vehicles (e.g. veh_0, veh_1, veh_2, ...). This application
demonstrate the following behavior:
veh_0, veh_1, veh_2, ... start a thread
veh_0, veh_1, veh_2, ... do some logic parallel to each other
veh_0, veh_1, veh_2, ... join the thread

MyMessage

This application shows how to create a message.

RandomSampling

This application demonstrates a sampling in a random interval. One
random simulation point will be choosen when the initialisation starts.
For example: t = {0 ms, 300 ms, 967 ms, 1487 ms, ...}

TestSumoTraciMsg

This sample shows the interaction between an application and the
TraCI interface of SUMO.

UpdateVehicleInfo

This application reacts on a vehicle info update. Mostly a vehicle info
will be triggered from a traffic simulator (e.g. SUMO).

UserTaggedValueRoundtrip

If the control of every byte is not needed, the DefaultObjectSerial-

ization can be used. This class converts an object into a byte field
and obversely.
VSimRTIMessage

This simple application shows how to create a VSimRTI-message and
sends it to all simulators. This application could also react on Appli-

cationSpecificMessage s.
VehicleConfiguration

This simple application demonstrates a configurable application.
Table D.1: Applications from the "Hello world package

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

127

Appendix E
Configuration Schemata
Some of the required JSON configuration files are automatically validated by VSimRTI and, therefore,
must follow a specific schema1 . If you have problems with VSimRTI accepting your configuration files,
please make sure they follow the respective schema:

JSON Schema for cell2/cell2_config.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

{
" $schema " : " http :// json - schema . org / schema # " ,
" type " : " object " ,
" properties " : {
" b a n d w i d t h M e a s u r e m e n t I n t e r v a l " : { " type " : " number " , " minimum " : 1 } ,
" bandwidthMeasurements ": {
" type " : " array " ,
" items " : [
{
" type " : " object " ,
" properties " : {
" fromRegion " : { " type " : " string " } ,
" toRegion " : { " type " : " string " } ,
" transmissionMode ": {
" type " : " string " ,
" enum " : [ " UplinkUnicast " , " D o wn li n kU n ic as t " , " D o w n l i n k M u l t i c a s t " ⤦
Ç ]
}
},
" required " : [
" fromRegion " , " toRegion " , " t r a n s m i s s i o n M o d e "
]
}
]
},
" n e t w o r k C o n f i g u r a t i o n F i l e " : { " type " : " string " } ,
" r e g i o n C o n f i g u r a t i o n F i l e " : { " type " : " string " }
},
" required " : [
" networkConfigurationFile "
]
}
Listing E.1: JSON Schema for cell2_config.json

1 The schemata listed here follow the specification at http://json-schema.org/documentation.html

Appendix E Configuration Schemata

Appendix E Configuration Schemata

JSON Schema for cell2/network_config.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
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

{
" $schema " : " http :// json - schema . org / schema # " ,
" type " : " object " ,
" properties " : {
" globalRegion " : {
" type " : " object " ,
" properties " : {
" uplink " : {
" type " : " object " ,
" properties " : {
" delay " : { " $ref " : " #/ definitions / delay " } ,
" capacity " : { " $ref " : " #/ definitions / capacity " }
},
" required " : [ " delay " , " capacity " ]
},
" downlink " : {
" type " : " object " ,
" properties " : {
" unicast " : { " $ref " : " #/ definitions / unicast " } ,
" multicast " : { " $ref " : " #/ definitions / multicast " } ,
" capacity " : { " $ref " : " #/ definitions / capacity " }
},
" required " : [ " unicast " , " multicast " , " capacity " ]
}
}
}
},
" required " : [ " globalRegion " ] ,
" definitions " : {
" delay " : {
" oneOf " : [
{
" type " : " object " ,
" properties " : {
" type " : { " type " : " string " ,
" enum " : [ " G a m m a R a n d o m D e l a y " , " G a mm aS p ee dD e la y " ]} ,
" minDelay " : { " type " : " number " ,
" minimum " : 0} ,
" expDelay " : { " type " : " number " ,
" minimum " : 0} ,
" prpl " : { " type " : " number " ,
" minimum " : 0} ,
" retries " : { " type " : " number " ,
" minimum " : 0}
},
" required " : [ " type " , " minDelay " , " expDelay " , " prpl " ]
},
{
" type " : " object " ,
" properties " : {
" type " : { " type " : " string " ,
" enum " : [ " ConstantDelay " ]} ,
" delay " : { " type " : " number " ,
" minimum " : 0} ,
" prpl " : { " type " : " number " ,
" minimum " : 0} ,
" retries " : { " type " : " number " ,
" minimum " : 0}
},
" required " : [ " type " , " delay " , " prpl " ]
},
{
" type " : " object " ,
" properties " : {

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

129

Appendix E Configuration Schemata

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

Appendix E Configuration Schemata

" type " : { " type " : " string " ,
" enum " : [ " S i m p l e R a n d o m D e l a y " ]} ,
" steps " : { " type " : " number " ,
" minimum " : 0} ,
" minDelay " : { " type " : " number " ,
" minimum " : 0} ,
" maxDelay " : { " type " : " number " ,
" minimum " : 0} ,
" prpl " : { " type " : " number " ,
" minimum " : 0} ,
" retries " : { " type " : " number " ,
" minimum " : 0}
},
" required " : [ " type " , " steps " , " minDelay " , " maxDelay " , " prpl " ]
}
]
},
" unicast " : {
" type " : " object " ,
" properties " : {
" delay " : { " $ref " : " #/ definitions / delay " }
},
" required " : [ " delay " ]
},
" multicast " : {
" type " : " object " ,
" properties " : {
" delay " : { " $ref " : " #/ definitions / delay " } ,
" usable Capac ity " : { " type " : " number " ,
" minimum " : 0.0 ,
" maximum " : 1.0}
},
" required " : [ " delay " , " u sableC apacit y " ]
},
" capacity " : {
" oneOf " : [
{
" type " : " integer " ,
" minimum " : 0
},
{
" type " : " string " ,
" pattern " : " ^ unlimited$ "
}
]
}
}
}
Listing E.2: JSON Schema for network_config.json

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

130

Appendix E Configuration Schemata

Appendix E Configuration Schemata

JSON Schema for cell2/regions_config.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
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

{
" $schema " : " http :// json - schema . org / schema # " ,
" type " : " object " ,
" properties " : {
" regions " : {
" type " : " array " ,
" items " : [
{
" type " : " object " ,
" properties " : {
" polygon " : {
" type " : " object " ,
" coordinates " : [
{ " $ref " : " #/ definitions / geopoint " }
],
" required " : [ " coordinates " ]
},
" area " : {
" type " : " object " ,
" properties " : {
" nw " : { " $ref " : " #/ definitions / geopoint " } ,
" se " : { " $ref " : " #/ definitions / geopoint " }
},
" required " : [ " nw " , " se " ]
},
" id " : { " type " : " string " } ,
" uplink " : {
" type " : " object " ,
" properties " : {
" delay " : { " $ref " : " #/ definitions / delay " } ,
" capacity " : { " $ref " : " #/ definitions / capacity " }
},
" required " : [ " delay " , " capacity " ]
},
" downlink " : {
" type " : " object " ,
" properties " : {
" unicast " : { " $ref " : " #/ definitions / unicast " } ,
" multicast " : { " $ref " : " #/ definitions / multicast " } ,
" capacity " : { " $ref " : " #/ definitions / capacity " }
},
" required " : [ " unicast " , " multicast " , " capacity " ]
}
},
" anyOf " : [
{ " required " : [ " area " , " id " , " uplink " , " downlink " ]} ,
{ " required " : [ " polygon " , " id " , " uplink " , " downlink " ]}
]
}
]
}
},
" definitions " : {
" delay " : {
" oneOf " : [
{
" type " : " object " ,
" properties " : {
" type " : { " type " : " string " ,
" enum " : [ " G a m m a R a n d o m D e l a y " , " G a mm aS p ee dD e la y " ]} ,
" minDelay " : { " type " : " number " ,
" minimum " : 0 ,
" e x c l u s i v e M i n i m u m " : true } ,
" expDelay " : { " type " : " number " ,

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

131

Appendix E Configuration Schemata

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
129
130
131
132

Appendix E Configuration Schemata

" minimum " : 0 ,
" e x c l u s i v e M i n i m u m " : true } ,
" prpl " : { " type " : " number " ,
" minimum " : 0} ,
" retries " : { " type " : " number " ,
" minimum " : 0}
},
" required " : [ " type " , " minDelay " , " expDelay " , " prpl " ]
},
{
" type " : " object " ,
" properties " : {
" type " : { " type " : " string " ,
" enum " : [ " ConstantDelay " ]} ,
" delay " : { " type " : " number " ,
" minimum " : 0 ,
" e x c l u s i v e M i n i m u m " : true } ,
" prpl " : { " type " : " number " ,
" minimum " : 0} ,
" retries " : { " type " : " number " ,
" minimum " : 0}
},
" required " : [ " type " , " delay " , " prpl " ]
},
{
" type " : " object " ,
" properties " : {
" type " : { " type " : " string " ,
" enum " : [ " S i m p l e R a n d o m D e l a y " ]} ,
" steps " : { " type " : " number " ,
" minimum " : 0} ,
" minDelay " : { " type " : " number " ,
" minimum " : 0 ,
" e x c l u s i v e M i n i m u m " : true } ,
" maxDelay " : { " type " : " number " ,
" minimum " : 0 ,
" e x c l u s i v e M i n i m u m " : true } ,
" prpl " : { " type " : " number " ,
" minimum " : 0} ,
" retries " : { " type " : " number " ,
" minimum " : 0}
},
" required " : [ " type " , " steps " , " minDelay " , " maxDelay " , " prpl " ]
}
]
},
" unicast " : {
" type " : " object " ,
" properties " : {
" delay " : { " $ref " : " #/ definitions / delay " }
},
" required " : [ " delay " ]
},
" multicast " : {
" type " : " object " ,
" properties " : {
" delay " : { " $ref " : " #/ definitions / delay " } ,
" usabl eCapac ity " : { " type " : " number " ,
" minimum " : 0.0 ,
" maximum " : 1.0}
},
" required " : [ " delay " , " u sableC apacit y " ]
},
" geopoint " : {
" type " : " object " ,
" properties " : {
" lon " : { " type " : " number " } ,

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

132

Appendix E Configuration Schemata

133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150

Appendix E Configuration Schemata

" lat " : { " type " : " number " }
},
" required " : [ " lon " , " lat " ]
},
" capacity " : {
" oneOf " : [
{
" type " : " integer " ,
" minimum " : 0
},
{
" type " : " string " ,
" pattern " : " ^ unlimited$ "
}
]
}
}
}
Listing E.3: JSON Schema for regions_config.json

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

133

F References
[1] B ENZ, Thomas ; S CHÜNEMANN, Björn ; K ERNCHEN, Ralf ; K ILLAT, Moritz ; R ICHTER, Andreas: A
Comprehensive Simulation Tool Set for Cooperative Systems. In: Advanced Microsystems for
Automotive Applications 2010 : Smart Systems for Green Cars and Safe Mobility (2010), May, S.
411–422. ISBN 978–3–642–12647–5
[2] B ISSMEYER, Norbert ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja ; S CHMIDT, Christian: Simulation of
attacks and corresponding driver behavior in vehicular ad hoc networks with VSimRTI. In: Proceedings of the 4th International ICST Conference on Simulation Tools and Techniques. ICST,
Brussels, Belgium, Belgium : ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), 2011 (SIMUTools ’11). – ISBN 978–1–936968–00–8, 162–167
[3] C HUANG, David ; S CHÜNEMANN, Björn ; R IECK, David ; R ADUSCH, Ilja: GRIND: An Generic Interface
for Coupling Power Grid Simulators with Traffic, Communication and Application Simulation Tools.
In: SIMUL 2013, The Fifth International Conference on Advances in System Simulation, 2013. –
ISBN 978–1–61208–308–7, S. 174–177
[4] C ODECÁ, Lara ; F RANK, Raphaël ; FAYE, Sébastien ; E NGEL, Thomas: Luxembourg SUMO Traffic
(LuST) Scenario: Traffic Demand Evaluation. In: IEEE Intelligent Transportation Systems Magazine 9 (2017), Nr. 2, S. 52–63
[5] H ÜBNER, Karl ; C RISTEA, Roland ; RULEWITZ, Stefan ; R ADUSCH, Ilja ; S CHÜNEMANN, Björn: Implementation of Cognitive Driver Models in Microscopic Traffic Simulations. In: Proceedings of
the 9th EAI International Conference on Simulation Tools and Techniques. ICST, Brussels, Belgium, Belgium : ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications
Engineering), 2016 (SIMUTOOLS’16). – ISBN 978–1–63190–120–1, 104–111
[6] H ÜBNER, Karl ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja: Sophisticated Route Calculation Approaches
for Microscopic Traffic Simulations. In: Proceedings of the 8th International Conference on Simulation Tools and Techniques. ICST, Brussels, Belgium, Belgium : ICST (Institute for Computer
Sciences, Social-Informatics and Telecommunications Engineering), 2015 (SIMUTools ’15). – ISBN
978–1–63190–079–2, 147–154
[7] H ÜBNER, Karl ; S CHÜNEMANN, Börn ; S CHILLING, Tom ; R ADUSCH, Ilja: On assessing road safety
aspects of a cycling router application. In: 2017 15th International Conference on ITS Telecommunications (ITST), 2017, S. 1–8
[8] K ATSAROS, Konstantinos ; K ERNCHEN, Ralf ; D IANATI, Mehrdad ; R IECK, David ; Z INOVIOU, Charalambos: Application of vehicular communications for improving the efficiency of traffic in urban
areas. In: Wireless Communications and Mobile Computing 11 (2011), Nr. 12, S. 1657–1667

F References

F References

[9] L OBACH, S. ; R ADUSCH, I.: Integration of Communication Security into Advanced Simulation
Environments for ITS. In: Vehicular Technology Conference (VTC Fall), 2011 IEEE, 2011. – ISSN
1090–3038, S. 1 –6
[10] N AUMANN, Nico ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja: VSimRTI - Simulation Runtime Infrastructure for V2X Communication Scenarios. In: Proceedings of the 16th World Congress and
Exhibition on Intelligent Transport Systems and Services (ITS Stockholm 2009), ITS Stockholm
2009, September 2009
[11] N AUMANN, Nico ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja ; M EINEL, Christoph: Improving V2X
Simulation Performance with Optimistic Synchronization. In: Services Computing Conference,
2009. APSCC 2009. IEEE Asia-Pacific, 2009. – ISBN 978–1–4244–5338–2, S. 52–57
[12] P ROTZMANN, R. ; M AHLER, K. ; O LTMANN, K. ; R ADUSCH, I.: Extending the V2X simulation environment VSimRTI with advanced communication models. In: ITS Telecommunications (ITST), 2012
12th International Conference on, 2012, S. 683–688
[13] P ROTZMANN, Robert ; M ASSOW, Kay ; R ADUSCH, Ilja: An Evaluation Environment and Methodology
for Automotive Media Streaming Applications. In: Innovative Mobile and Internet Services in
Ubiquitous Computing (IMIS), 2014 Eighth International Conference on IEEE, 2014, S. 297–304
[14] P ROTZMANN, Robert ; M ASSOW, Kay ; R ADUSCH, Ilja: On performance estimation of prefetching
algorithms for streaming content in automotive environments. In: Wireless On-demand Network
Systems and Services (WONS), 2014 11th Annual Conference on IEEE, 2014, S. 147–147
[15] P ROTZMANN, Robert ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja: The influences of communication
models on the simulated effectiveness of V2X applications. In: Vehicular Networking Conference
(VNC), 2010 IEEE, 2010. – ISBN 978–1–4244–9526–9, S. 102 –109
[16] P ROTZMANN, Robert ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja: The influences of communication
models on the simulated effectiveness of V2X applications. In: Communications Magazine, IEEE
49 (2011), november, Nr. 11, S. 149 –155. http://dx.doi.org/10.1109/MCOM.2011.6069722. –
DOI 10.1109/MCOM.2011.6069722. – ISSN 0163–6804
[17] P ROTZMANN, Robert ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja: Effects of Random Number Generators on V2X Communication Simulation. In: TAN, Gary (Hrsg.) ; Y EO, GeeKin (Hrsg.) ; T URNER,
StephenJohn (Hrsg.) ; T EO, YongMeng (Hrsg.): AsiaSim 2013 Bd. 402, Springer Berlin Heidelberg,
2013 (Communications in Computer and Information Science). – ISBN 978–3–642–45036–5, 200-211
[18] P ROTZMANN, Robert ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja: On Site-Specific Propagation Models
for the Evaluation of V2X Applications. In: Communication Technologies for Vehicles (Nets4CarsFall), 2014 7th International Workshop on IEEE, 2014, S. 35–39
[19] P ROTZMANN, Robert ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja: A Sensitive Metric for the Assessment of
Vehicular Communication Applications. In: Advanced Information Networking and Applications
(AINA), 2014 IEEE 28th International Conference on IEEE, 2014, S. 697–703
[20] QUECK, Tobias ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja: Runtime Infrastructure for Simulating
Vehicle-2-X Communication Scenarios. In: VANET ’08: Proceedings of the fifth ACM international
workshop on VehiculAr Inter-NETworking. New York, NY, USA : ACM, 2008. – ISBN 978–1–60558–
191–0, S. 78–79

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

135

F References

F References

[21] QUECK, Tobias ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja ; M EINEL, Christoph: Realistic Simulation of
V2X Communication Scenarios. In: APSCC ’08: Proceedings of the 2008 IEEE Asia-Pacific Services
Computing Conference. Washington, DC, USA : IEEE Computer Society, 2008. – ISBN 978–0–7695–
3473–2, S. 1623–1627
[22] R IECK, David ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja ; M EINEL, Christoph: Efficient traffic simulator
coupling in a distributed V2X simulation environment. In: SIMUTools ’10: Proceedings of the
3rd International ICST Conference on Simulation Tools and Techniques. ICST, Brussels, Belgium,
Belgium : ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications
Engineering), 2010. – ISBN 978–963–9799–87–5, S. 1–9
[23] S CHÜNEMANN, Björn: V2X simulation runtime infrastructure VSimRTI: An assessment tool to
design smart traffic management systems. In: Computer Networks 55 (2011), October, 3189–
3198.

http://dx.doi.org/http://dx.doi.org/10.1016/j.comnet.2011.05.005. – DOI

http://dx.doi.org/10.1016/j.comnet.2011.05.005. – ISSN 1389–1286
[24] S CHÜNEMANN, Björn ; M ASSOW, Kay ; R ADUSCH, Ilja: A Novel Approach for Realistic Emulation
of Vehicle-2-X Communication Applications. In: Vehicular Technology Conference, 2008. VTC
Spring 2008. IEEE, 2008. – ISSN 1550–2252, S. 2709–2713
[25] S CHÜNEMANN, Björn ; M ASSOW, Kay ; R ADUSCH, Ilja: Realistic Simulation of Vehicular Communication and Vehicle-2-X Applications. In: Simutools ’08: Proceedings of the 1st international
conference on Simulation tools and techniques for communications, networks and systems &
workshops. ICST, Brussels, Belgium, Belgium : ICST (Institute for Computer Sciences, SocialInformatics and Telecommunications Engineering), 2008. – ISBN 978–963–9799–20–2, S. 1–9
[26] S CHÜNEMANN, Björn ; R IECK, David ; R ADUSCH, Ilja: Performance and scalability analyses of
federation-based V2X simulation systems. In: Ad Hoc Networking Workshop (Med-Hoc-Net), 2012
The 11th Annual Mediterranean, 2012. – ISBN 978–1–4673–2038–2, S. 119 –126
[27] S CHÜNEMANN, Björn ; W EDEL, Jan W. ; R ADUSCH, Ilja: V2X-Based Traffic Congestion Recognition
and Avoidance. In: Tamkang Journal of Science and Engineering 13 (2010), March, Nr. 1, 63-70.

http://www2.tku.edu.tw/~tkjse/13-1/catology.htm. – ISSN 1560–6686
[28] W EDEL, Jan W. ; S CHÜNEMANN, Björn ; R ADUSCH, Ilja: V2X-Based Traffic Congestion Recognition and
Avoidance. In: Parallel Architectures, Algorithms, and Networks, International Symposium on
0 (2009), S. 637–641. http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/

I-SPAN.2009.71. – DOI http://doi.ieeecomputersociety.org/10.1109/I–SPAN.2009.71. ISBN 978–0–
7695–3908–9

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure

136



---

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : No
Page Count                      : 141
Page Mode                       : UseOutlines
Author                          : 
Title                           : 
Subject                         : 
Creator                         : LaTeX with hyperref package
Producer                        : pdfTeX-1.40.18
Create Date                     : 2018:04:24 11:34:33+02:00
Modify Date                     : 2018:04:24 11:34:33+02:00
Trapped                         : False
PTEX Fullbanner                 : This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3

EXIF Metadata provided by EXIF.tools