Vsimrti User Manual 0.13.1

8/10/2019 Vsimrti User Manual 0.13.1

1/126

VSimRTI: Vehicle-2-X Simulation

Runtime Infrastructure

User Documentation

Michalis Adamidis Sebastian Dunkel Jan Henning Jiajun Hu

Franz Kage Bernard Ladenthin Nico Naumann Robert Protzmann

Tobias Queck Stefan Reichel David Rieck Alexander Scheck

Erik Schleiff Bjrn Schnemann Julia Ullrich

Version 0.13.1

March 25, 2014


2/126

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

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

The developer alliance

The developer alliance consists of Fraunhofer-Institut fr Offene Kommunikationssysteme (FOKUS),Daimler Center for Automotive Information Technology Innovations(DCAITI) and Automotive Services

and Communication Technologies (ASCT).

Contact information

VSimRTI Mailing List (developer team)

[email protected]

VSimRTI:Smart Mobility Simulation

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

Fraunhofer FOKUS:ASCT Competence Center

http://www.fokus.fraunhofer.de/en/asct/index.html

DCAITI

http://www.dcaiti.tu-berlin.de
mailto:[email protected]://www.dcaiti.tu-berlin.de/research/simulationhttp://www.fokus.fraunhofer.de/en/asct/index.htmlhttp://www.dcaiti.tu-berlin.de/http://www.dcaiti.tu-berlin.de/http://www.fokus.fraunhofer.de/en/asct/index.htmlhttp://www.dcaiti.tu-berlin.de/research/simulationmailto:[email protected]


3/126

Contents

1 Introduction 1

1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Download and install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.1 Federates and Ambassadors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.2 Root configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 VSimRTI configuration 4

2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Host configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Simulators 5

3.1 Kinds of simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 Network simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.2 Traffic simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.3 Cellular simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.4 Application simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.5 Environment simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.6 Navigation simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 JiST/SWANS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.1 swans-ambassador folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1 omnetpp-ambassador folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4 ns-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4.1 ns3-ambassador folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5 SUMO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5.1 sumo-ambassador folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5.4 Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.6 VISSIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.7 VSimRTI Eventserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.7.1 eventserver-ambassador folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.7.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.7.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.8 eWorld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.8.1 eworld-ambassador folder structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.8.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.8.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.9 VSimRTI cellular simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.9.1 cell-ambassador folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26


4/126

Contents Contents

3.9.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.9.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.10 VSimRTI application simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.10.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.10.2 application-ambassador folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.10.3 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.10.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.10.5 Development of application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.10.6 FacilityTimerInterceptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.10.7 Remote debugging of applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.10.8 Mapping 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.11 VSimRTI navigation simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.11.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.11.2 navigation-ambassador folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.11.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.12 Behavior Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.12.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.12.3 Adjusting an application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.12.4 Creating a custom data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.12.5 Matching between a BehaviorDataStruct and normal messages . . . . . . . . . . . . . 50

3.12.6 Creating a new model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 Visualizers 52

4.1 Kinds of Visualizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2 eWorld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2.1 eWorld VSimRTI visualizer plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3 VsimrtiFileVisualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.3.1 Configuring the File Visualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.4 VSimRTI web visualizer (VSim) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.5 VSimRTI WebSocket visualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5 Create a scenario 73

5.1 Road network data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.1.1 Using OpenStreetMap data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2 Road network data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3 VSimRTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6 Run simulations 77

6.1 Run a simulation via CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.1.1 VSimRTIEmbeddedStarter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.2 Run a simulation set via CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.3.1 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7 Scenario Schwanebeck 83

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2 WeatherWarningApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.3 Run a single simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8 Scenario Tiergarten 85

8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8.2 CamExampleApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

9 Additional tools 86

9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

9.2 scenario-convert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 4


5/126

Contents Contents

10Additional information 88

10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

10.2 PATH configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

10.3 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

11List of Acronyms 91

A VSimRTI deployment 93

A.1 VSimRTIFolder Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

A.2 File listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

B Example scenario Schwanebeck 105

B.1 Folder Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

B.2 File listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

C Example scenario Tiergarten 119

C.1 Folder Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

C.2 File listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120



6/126

1 Introduction

1.1 Overview

This documentation is part of the current release ofVSimRTIand aims at supporting users in their first

steps with the software. We try to explain most of the VSimRTIfeatures and configurations with two

example scenarios named Schwanebeck (see chapter7) and Tiergarten (see chapter8).

Having said that we do not aim to give full disclosure for every configuration option here. If you needmore specific information on a configuration have a look at the javadocs provided alongside the current

release which are available for all JavaScript Object Notation (JSON) style configs or the Appendix for

Extensible Markup Language (XML) style configs.

If you have any questions or need further support please feel free to contact our support team via our

mailing list.Please include logfiles and scenario files in your request, if relevant. We also look forward

to get your feedback for improvements of the VSimRTIdocumentation as well as the installation and

configuration process.

VSimRTIat a glance

VSimRTIwas built to support users performingV2Xsimulations while maintaining the flexibilityto choose

which simulators to use. It offers interfaces for the integration of different simulators, e.g. for network,

traffic, and environment simulations to provide flexibility to exchange a simulator without changing the

underlying infrastructure. For the synchronization and the communication among all components the

implemented infrastructure uses common concepts defined in the Institute of Electrical and Electronics

Engineers (IEEE)standard for modelling and simulation (M&S) high-level architecture(HLA). Thus

the runtime infrastructureVSimRTIallows a flexible combination of time-discrete simulators forV2X

simulations. Based on the (possibly differing) requirements of a specific scenario arbitrary simulators

can be added toVSimRTIand are executed together.

VSimRTIis written in the programming language Java and deployed as Java Archive(JAR) files. Therefore

for execution a compatible Java Runtime Environment(JRE) for your operating system needs to be

installed. The following table shows the supported versions

Version Supported

6.0.35 and before no

7.0.1 and above

Table 1.1: Supported Java versions


7/126

1 Introduction 1.2 Download and install

1.2 Download and install

Download vsimrti-bin.zip from the DCAITI website.

The packagevsimrti-bin.zip

has to be extracted to an arbitrary path. This installation path is referenced as

vsimrti

throughout this document.

1.3 License

The licensing mechanism was introduced for a better release control. It improves the user support

whilst helping thedeveloper teamto deactivate outdated releases which cannot be maintained anymore.Each user needs to be registered at the license server to obtain a license which is a very straightforward

procedure.

1. For registration, the user id and basic system information are stored at the server. After the first

start ofVSimRTIwithout a valid license a warning appears, stating that there was no license file

found and a

vsimrti/systeminfo.txt

text file is generated.

For the initial launch of VSimRTI, without license, any user name can be used. As an example, youcan use -u abc.

2. The created file contains basic information in plain text about the machine on whichVSimRTIwas

executed and is used to identify the user. The system info needs to be sent to the VSimRTI mailing

list.A member of staff registers the new user at the VSimRTIlicense server as soon as possible,

usually within one workday. When your license is active, you get an email with your userid.

3. The following information is stored to identify your machine:

central processing unit(CPU) model id

CPUcores

CPUarchitecture

Media Access Control (MAC) addresses

operating system name

operating system version

random-access memory(RAM)size

sockets

hashed user id



8/126

1 Introduction 1.4 Concept

VSimRTIversion

4. Directly after confirmation by theVSimRTIteam the license is activated. On the nextVSimRTIrun

with an available Internet connection to theVSimRTIlicense server a valid license is generated and

a local copy is stored in theVSimRTIfolder.

5. The local license files

vsimrti/vsimrti-license.lcs

and

vsimrti/vsimrti.dat

are valid for the next 14 days. In this period no Internet connection is needed for the execution of

VSimRTI. Every time when an Internet connection to the license server can be established the local

license file is renewed for a further 14 days.

Notice: You should not backup the license files. If you have a registered account and a

valid license is present on the license server you will always receive a new license file.

1.4 Concept

In contrast to existing fixed simulator couplingsVSimRTIallows the easy integration and exchangeability

of simulators. Thus, the high flexibility ofVSimRTIenables the coupling of the most appropriate simula-

tors for a realistic presentation of vehicle traffic, emissions, wireless communication, and the execution of

V2Xapplications. Depending on the specific requirements of a simulation scenario the most appropriate

simulators can be used.

1.4.1 Federates and Ambassadors

VSimRTI uses the federate-ambassador concept inspired by the concept of the HLA.Using this concept, it

is possible to couple different simulation systems with a remote control interface. Attaching an additional

simulator only requires that the ambassador interface is implemented and the specified commands can

be executed.

1.4.2 Root configuration

This ambassador can be configured with a configuration file. The specific path is

vsimrti/scenarios//vsimrti/vsimrti_config.xml



9/126

2 VSimRTI configuration

2.1 Overview

VSimRTIcan be configured by adapting the files in the/vsimrti/etcdirectory. A full example of the default

configuration files can be found inA.2.

2.2 Host configuration

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

vsimrti/etc/hosts.json

Notice: The documentation for the VSimRTI specific component is freely available on

the DCAITI website, explaining all available options.

This file is used for configuring simulation runs using multiple machines. Under normal circumstances it

is not necessary to change this file.

InVSimRTIthere are two kinds of hosts: local and remote hosts. All host have to be identified with a

unique string that is valid for the remainder of the configuration to reference a defined host.

For a local host additionally the operating system and a name of a directory that is used to deploy needed

federates is necessary. Values for operating systems are "linux"or"windows".

The syntax for referenced paths has to be chosen according to operating system standards (e.g./vsimr-

ti/tempfor GNU/Linux andC:\vsimrti\tempfor 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.


10/126

3 Simulators

VSimRTIcouples different simulators and cant be run alone. Therefore, it requires pre-installed sim-

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

tion provided on theVSimRTI website. To run other simulators than the provided ones, an additional

component has to be written, which couples the simulator toVSimRTI. 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 figure3.1gives an overview of the currently available simulators forVSimRTI

vsimrti

network simulators ...................................................... (see3.1.1)

Java in Simulation Time (JiST)/Scalable Wireless Ad hoc Network Simula-

tor (SWANS) ............................................................. (see3.2)

OMNeT++ (OMNeT++) ......................................................(see3.3)

network simulator 3 (ns-3) ............................................(see3.4)

traffic simulators ...................................................... (see3.1.2)

Simulation of Urban Mobility (SUMO) .................................. (see3.5)

Verkehr In Stdten - Simulationsmodell (VISSIM) ....................(see3.6)

cellular simulators ..................................................... (see3.1.3)

VSimRTI cellular simulator (built in) ............................... (see3.9)

environment simulators ..................................................(see3.1.5)

VSimRTI Eventserver ....................................................(see3.7)

eWorld environment simulator .......................................... (see3.8)

application simulators ..................................................(see3.1.4)

VSimRTI application simulator (built in) ...........................(see3.10)VSimRTI mapping3 (built in) .....................................(see3.10.8)

naviagtion simulators ...................................................(see3.1.6)

VSimRTI navigation simulator (built in) ............................(see3.11)

Figure 3.1:VSimRTIsimulator structure

3.1.1 Network simulators

A network simulator is a piece of software modeling the behavior of a network by calculating the inter-

actions between all partaking entities. ForVSimRTIand more specifically the communication in a V2X


11/126

3 Simulators 3.1 Kinds of simulators

environment this refers to simulations of the wireless transmissions taking place between the various

simulated entities.

Notice: To permit parallel usageSWANSandOMNeT++are connected toVSimRTIon

different ports (which is not mandatory).

3.1.2 Traffic simulators

A traffic simulator is a software modeling the movements of users in a traffic system. Users can mean

cars, pedestrians, trains, ships, planes etc. Traffic simulators can be discriminated by various measures,

of which one is the used scope:

Microscopic models Simulate each car individually and through the interaction of multiple cars

also traffic flows. They are commonly used for situations such as a traffic crossing or an on-ramp

situation.

Macroscopic models Models of a traffic flow without the modelling of individual cars. Instead the

traffic flow is computed using models derived from fluid dynamics or gas-kinetics. By this the

simulation is computationally far less expensive, so more cars and wider areas can be simulated.

An example would be the prediction of traffic jams.

Mesoscopic models Try to bridge the gap between macroscopic and microscopic simulation using

individual vehicles that are being actuated by macroscopic control variables.

Sub-Microscopic models Used to simulate a car in as much detail as possible. The prediction of the

behavior is the most precise of all models, but also computationally the most expensive.

The two currently supported traffic simulatorSUMOandVISSIMare both microscopic traffic simula-

tors.

3.1.3 Cellular simulators

Cellular simulators are a special case of network simulators: They simulate the communication taking

place within a cellular network. They can be used as an alternative or addition to a classic network

simulator.

3.1.4 Application simulators

An application simulator is an important component enabling the simulation and creation ofV2X

applications. It follows the European Telecommunications Standards Institute (ETSI) standards for

Vehicle-to-Vehicle (V2V) communication. These standards contain message definitions like Decentralized

Environmental Notification Messages(DENM)and Cooperative Awareness Messages (CAM)and also a

general application container design.

3.1.5 Environment simulators

This kind of simulator simulate certain events such as rain, fog, snow, etc..



12/126

3 Simulators 3.1 Kinds of simulators

3.1.6 Navigation simulators

This is an auxiliary simulator enabling the conversion between different navigational messages used in

the various other simulators.



13/126

3 Simulators 3.2 JiST/SWANS

3.2 JiST/SWANS

SWANSis a scalable wireless network simulator built atop theJiSTplatform.

It was originally released in 2004 by the Cornell University and is free for academic use. Since it wasdeveloped for the simulation of Mobile Ad hoc Network(MANET)s it comes along with the most impor-

tant models for communication according to IEEE 802.11 on the one hand and exhibits a reasonable

performance in large scale scenarios on the other hand. In the meantime several extensions from other

departments came up with the VANET extension from University Ulm being the most interesting. This

version includes a new Routing Protocol for Geographic Routing, several bugfixes and enhanced mobility

models and is the basis of V2X communication research connected withVSimRTI.

In the release 0.9.9 ofVSimRTI,SWANSwas extended with a new propagation model Three Log Distance

Path Loss which is currently in experimental state.

Software information

Developer(s) Cornell Research Foundation, Inc.

University Ulm

Written in Java

Operating system Cross-platform

License open source (Cornell Research Foundation, Inc. License)

Website http://jist.ece.cornell.edu/

http://vanet.info/jist-swans.html

Supported version(s) 1.1.1

Installation via released installation script

Table 3.1: Software information:JiST/SWANS

3.2.1 swans-ambassador folder structure


vsimrti/scenarios//swans/swans_config.xml

swans ............................................................................

swans_config.xml .................................ambassador configuration file

Figure 3.2: swans-ambassadorfolder structure

3.2.2 Installation

http://jist.ece.cornell.edu/http://vanet.info/jist-swans.htmlhttp://vanet.info/jist-swans.htmlhttp://jist.ece.cornell.edu/


14/126


Manual installation

To installSWANS,download and extract the contents of the provided swans-patch-0.13.1.zip file in the

vsimrti/bin/fed/swans

folder of your vsimrti installation.

Installation shell script

vsimrti

bin

fed

swans

swans_installer.sh ..........................Installation script for SWANS

Figure 3.3:SWANSfolder structure

The VSimRTI all-in-one package comes with a installation script for the bash-shell, that automates the

task of theSWANSinstallation.

1. Make the script executable:

chmod 755 swans_installer

2. Now the script is ready to run by typing the following:

./swans_installer

3.2.3 Configuration

TheSWANSconfiguration file contains settings of the used model parameters especially for the radio

channel, the physical layer and the routing protocol on the network layer. It consists of one section for

common parameters and two sections for node specific parameters to support different configurations

for vehicles and RSUs.

Common

Dimensions of the simulated area (NOTE: dimX and dimY must not be smaller than spatial expan-

sions which are configured for the traffic simulator e.g.SUMO)

Configuration of the Random Number Generator(RNG) settings (with 3 supported RNGs LinearCongruential Generator, MersenneTwister and BlumBlumShub)

Propagation models for path loss and fast fading

Path loss models Free Space, Two Ray Ground and Table do not require further parameters

Three Log Distance Model defines parameters d0, d1, d2 for reference distances and n0, n1,

n2 for path loss exponents (NOTE: this model is still experimental)

Fast fading models None and Rayleigh Fading do not require further parameters

Fast fading model for Rice Fading defines the k-factor for the relation of the dominant LOS

path over the equal distributed NLOS paths



15/126


Common parameters for physical layer (NOTE: default values ofSWANSassume the standard IEEE

802.11b, even if IEEE 802.11p is the reference standard for vehicular communication)

Routing models

None means no routing is applied and V2X messages are sent using singlehop broadcasting

CGGC (Cached Greedy GeoCast) configures the georouting protocol implemented by Ulm

University

Node Specific (Vehicle and RSU)

Specific physical layer parameters for vehicles and RSUs (e.g. different antenna heights, tx power,

rx sensitivity)



16/126

3 Simulators 3.3 OMNeT++

3.3 OMNeT++

OMNeT++itself is solely the simulation platform for discrete-event systems. Even though it is primarily

targeted at simulating computer networks and distributed systems, it cannot be used without any

extensions for wireless communication. For this kind of simulations, external model frameworks have

to be included. Currently there are two prominent model frameworks which cover whole model suites

for according focus of wireless research. These are the Mobility Framework and the INET Framework.

A further interesting project is INETMANET which is a development branch of the INET Framework. It

was extended with special focus on MANET simulations, including more sophisticated models for Radio

Channel and PHY Layer as well as further Routing Protocols. Compared to INET master branch the model

capabilities are better suited for V2X communication. Hence INETMANET is used for the integration of

OMNeT++ to the VSimRTI simulation environment.

For an Internet Mobile Ad hoc Network (INETMANET) extension you should look closer on the website

https://github.com/inetmanet.


Developer(s) OMNeT++ Community and OpenSim Ltd.

Written in C++

Operating system Windows (mingw), Linux

License open source for academic use

Website http://www.omnetpp.org/

https://github.com/inetmanet

Supported version(s) 4.1

Installation via released installation script

Table 3.2: Software information:OMNeT++

3.3.1 omnetpp-ambassador folder structure

The omnetpp.ini file has to be located in the omnetpp folder of the scenario configuration.

omnetpp ..........................................................................

omnetpp.ini .......................................ambassador configuration file

Figure 3.4: omnetpp-ambassador folder structure

3.3.2 Installation

The OMNeT++ binaries are not included in theVSimRTIall-in-one Package. But an additional binary

package was set up and can be downloaded from the VSimRTI release area. It contains:

https://github.com/inetmanethttps://github.com/inetmanethttp://www.omnetpp.org/https://github.com/inetmanethttps://github.com/inetmanethttp://www.omnetpp.org/https://github.com/inetmanet


17/126


TheOMNeT++federate as executable

TheINETMANETmodel framework as library

An exemplary

vsimrti/scenarios//omnetpp/omnetpp.iniconfiguration file

The executable was compiled for 64-bit GNU/Linux based operating systems. It was successfully set

up under Ubuntu 10.04.2 LTS and Gentoo-Linux 1.12.14 and depends mainly on the installed shared

libraries. First of all it requires OMNeT++ libraries. That means OMNeT++ needs to be installed prior

toVSimRTIand the omnetpp-federate. The second type of required libraries are general libs which are

shipped with current GNU/Linux distributions or need to be installed manually. These are:

Listing 3.1: OMNeT++ dependencies.

libdl.so.2

libstdc++.so.6libm.so.6

libgcc_s.so.1

libc.so.6

libpthread.so.0

libtk8.5.so

libtcl8.5.so

libz.so.1

libxml2.so.2

libmpi_cxx.so.0

libmpi.so.0

libopen -rte.so.0

libopen -pal.so.0

libnsl.so.1

libutil.so.1

libX11.so.6libXft.so.2

libxcb.so.1

libfontconfig.so.1

libfreetype.so.6

libXrender.so.1

libXau.so.6

libXdmcp.so.6

libexpat.so.1

Finally the libinet.so is required which is actually the library for the INETMANET model framework.

Set up OMNeT++

Manual installation

To set up OMNeT++ with VSimRTI the following steps are promised to be successful:

1. Install OMNeT++ 4.1 according to the procedure, described on the OMNeT++ website

(www.omnetpp.org).

2. Include the bin folder to the PATH depending on the location OMNeT++ is installed (see listing3.2).

3. Include the libraries in the LD_LIBRARY_PATH environment variable. This can be checked with

ldd. At least the libinet.so in the inetmanet-folder needs to be added (see listing3.2).



18/126


4. Copy the binaries from the OMNeT++ binary package to fed-folder in the VSimRTI all-in-one

package to receive the folder structure as presented in the following Table.

5. Set up an

omnetpp.ini

file in the omnetpp folder of the scenario to be simulated. An example file can be found in

the configuration folder of the OMNeT++ package and the tiergarten scenario is already set up

according to this scheme.

6. For reasonable result logging, the logger-configuration in

vsimrti/etc/logback.xml

has to be adapted to support the OMNeT++ ambassador and federate.

7. At last OMNeT++ has to be activated in the vsimrti_config.xml and the simulation can be started.

Listing 3.2: OMNeT++ environment variables.

# S e tt i ng t he P A TH v a ri a bl e

export PATH= $PATH:/opt/ bin/omnetpp -4.1/bin

or

export PATH= $PATH:/usr/ local/bin/ omnetpp -4.1/bin

# S e t t i n g t h e L D _ L I B R A R Y _ P A TH v a r i a bl e

export L D _ L I B R AR Y _ P A T H = $ L D _ L I B R A RY _ P A T H : i n e t m a n et

Installation shell script

vsimrti

bin

fedomnetpp

set_env.sh ..................Script to set the required environment variables

omnet_installer.sh ........... Installation script for OMNeT++/INETMANET

Figure 3.5: OMNeT++ folder structure

The VSimRTI all-in-one package comes with an experimental installation script for the bash-shell, that

automates the task of the OMNeT++/INETMANET installation.

1. Make the script executable:

chmod 755 set_env

chmod 755 omnet_installer

2. Run the first script to set the required environment variables for the OMNeT++/INETAMET installa-

tion:

./set_env

3. Run the second script to install OMNeT++/INETMANET:

./omnet_installer



19/126


3.3.3 Configuration

The whole OMNeT++ specific configuration is done via the omnetpp.ini file. It covers static parts for

the simulator coupling as the specificVSimRTIEvent Scheduler and the ScenarioManager. Furthermore

logging configurations and the typical parameters for the communication layers (MAC, PHY and RadioChannel) are addressed. The communication parameters are, similar to theSWANSimplementation,

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.



20/126

3 Simulators 3.4 ns-3

3.4 ns-3

Thenetwork simulator 3 (ns-3) is a discrete-event network simulator, that was started as an open-

source project by a team led byTom Hendersonfrom theUniversity of Washingtonin July 2006 and

made its first release in June 2008.Ns-3is 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 popularnetwork 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-2still 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-3has a relatively steep learning curve, especially compared to GUI-

based simulators. If you have no prior experience withns-3, we recommend to familiarize yourself with

the ns-3 simulation environment and the ns-3 simulation basics first. The ns-3 documentation can befound under:

http://www.nsnam.org/documentation

To take your first steps with ns-3, you might want to download1 the latest version, build a copy ofns-3(it

uses the Python-based build-systemwaf) and take a look at the examples, that are shipped within most

of the ns-3source code repositories and packages. You might also examine the simulation output and try

to adjust it.

Typically, ans-3user will work under a Linux environment. For those running under Windows, there

do exist environments which simulate the Linux environment to various degrees. Thens-3 project has

in the past (but not presently) supported theCygwinenvironment for these users (see http://www.

cygwin.comfor details on downloading).MiniGWis presently not officially supported. According to

thens-3installation guide, the officially supported platforms include (please note, that plenty of other

distributions are likely to work with ns-3 regardless):

Fedora 17 (32/64 bit) with g++-4.7.0

Fedora 15 (64 bit) with g++-4.6.3

Ubuntu 12.04 (32/64 bit) with g++-4.6.3

Ubuntu 10.04.4 LTS (64 bit) with g++-4.4.3

OS X Mountain Lion 10.7.4 with g++-4.2.1

OS X Snow Leopard 10.6.8 with g++-4.2.1

FreeBSD 8.2 (32 bit) with g++-4.2.1

Cygwin 1.7.9-1 with g++-4.5.3

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

http://www.nsnam.org/documentationhttp://www.cygwin.com/http://www.cygwin.com/http://www.cygwin.com/http://www.cygwin.com/http://www.nsnam.org/documentation


21/126


Important: As stated above,ns-3 is primarily developed on and for GNU/Linux plat-

forms. Since Windows is such a widely used platform and Cygwin is not a perfect emulation

of any Linux, we highly recommended for non-Linux users to consider the installation of a

Linux virtual machine with a virtual machine environment, such as VMware2 or VirtualBox3.


Developer(s) Tom Henderson, Mathieu Lacage, George Riley, Mitch Watrous,

Gustavo Carneiro, Tommaso Pecorella and others

Written in C++ (core) and Python (bindings)

Operating system GNU/Linux FreeBSD Mac OS X

License free software:GNU GPLv2

Website http://www.nsnam.org/

Supported version(s) 3.15

Deployed inVSimRTIall-in-one no (and need a patch to link)

Table 3.3: Software information:ns-3

3.4.1 ns3-ambassador folder structure

ns3

ns3_config.xml .................................... ambassador configuration file

Figure 3.6: ns3-ambassador folder structure

Important: Currently, there is no need to configure the ns-3 ambassador with a XML-

configuration file (i.e. the configuration file is not read by the ambassador).

3.4.2 Installation

VSimRTI offers support for the current stable release ofns-3 (3.15), that was released in August 2012 (olderversions ofns-3(prior to 3.15) are not supported). The coupling to VSimRTI is designed in a manner of

minimal code changes on thens-3simulator 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 clangcompiler

and aPythoninterpreter:

Linux x86 and x86_64: gcc versions 4.1 through 4.7 and, 3.4.6, clang versions 3.0 and 3.1.

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

http://www.nsnam.org/http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_(Windows)http://www.nsnam.org/wiki/index.php/HOWTO_use_VirtualBox_to_run_simulations_on_Windows_machineshttp://www.nsnam.org/wiki/index.php/HOWTO_use_VirtualBox_to_run_simulations_on_Windows_machineshttp://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_(Windows)http://www.nsnam.org/


22/126


FreeBSD x86 and x86_64: gcc version 4.2, clang versions 3.0 and 3.1.

Mac OS X ppc and x86: gcc versions 4.0 and 4.2,

The core ofns-3requires a gcc/g++ installation of 3.4 or greater and Python 2.4 or greater. As mentioned

in thens-3documentation, different options require additional support. At least you need the following

packages to be installed:

Listing 3.3: Ns-3: Minimum requirements

gc c

g ++

python

python -dev

For a complete list of required packages for different distributions, please refer to the ns-3 installation

guide:

http://www.nsnam.org/wiki/index.php/Installation

Run the installation script

Important: Ns-3requires 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 ofns-3 for VSimRTI, the installation process has been delegated to an installation

script, that can be found in the associated ns-3 federate folder.

vsimrtibin

fed

ns3

ns3_installer.sh ............................... Installation script for ns-3

Figure 3.7: ns3-ambassador federate folder structure

Thens-3installation script accomplishes the following tasks:

1. Download ns-3tarball from the offical sources

2. Download thens-3federate for VSimRTI.

3. Apply a patch tons-3in order to make it work with VSimRTI.

4. Add thens-3federate to the waf build system.

5. Configure and build the patchedns-3with thens-3federate.

In order to start the simulation, the following steps need to be performed:

1. Set up the confWifi.xml-file in the scenario folder (see section 3.4.3). An example confWifi.xml-

file is shipped with the Tiergarten scenario.

2. For reasonable result logging, the logger-configuration in vsimrti/etc/logback.xmlhas to be

adapted to support thens-3ambassador and federate.

http://www.nsnam.org/wiki/index.php/Installationhttp://www.nsnam.org/wiki/index.php/Installation


23/126


3. At lastns-3has to be activated in the vsimrti_config.xml and the simulation can be started.

3.4.3 Configuration

The wholens-3specific configuration is done via the confWifi.xmlandconfigTechnologies.xml

files.

Listing 3.4: confWifi.xml


24/126


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

thens-3class registration system (see thens-3documentation for details). The Wi-Fi configuration

includes additional parameters, like sending power and antenna gain.

Listing 3.5: configTechnologies.xml


25/126

3 Simulators 3.5 SUMO

3.5 SUMO

SUMOis an highly portable, microscopic and continuous road traffic simulation package. It is designed

to handle large road networks faster than real-time. Each vehicle has an own route and is simulated

individually.


Developer(s) German Aerospace Center

Written in C++

Operating system GNU/Linux and Microsoft Windows


Website http://sumo.sourceforge.net/


Deployed inVSimRTIall-in-one no

Table 3.4: Software information:SUMO

3.5.1 sumo-ambassador folder structure


vsimrti/scenarios//sumo/sumo_config.json

sumo .............................................................................

.edg.xml ..............................................Edge file

.net.xml ........................................... Network file

.nod.xml .............................................Node file

.rou.xml .............................................Route file

.sumo.cfg ............................... sumo configuration file

sumo_config.json .................................ambassador configuration file

Figure 3.8: sumo-ambassadorfolder structure

3.5.2 Installation

For Microsoft Windows operating systems download and extract

sumo_winbin.zip

from the SUMO website. For GNU/Linux operating systems download and extract the provided

GNU/Linux binaries or build sumo by yourself. Please refer to the SUMOWiki for further informa-

tion.

http://sumo.sourceforge.net/http://sumo.sourceforge.net/


26/126

3 Simulators 3.5 SUMO

In order to run SUMOwith VSimRTI you need to make the SUMObinaries available system wide by

adding theSUMObinary folder to your PATH environment variable (see section10.2).

3.5.3 ConfigurationNotice: The documentation for the VSimRTI specific component is freely available on


TheSUMOconfiguration 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 . TheSUMOWiki covers more

information and also a tutorial about the different configuration files. Route-, network- and SUMO

configuration files have been generated (using scenario-convert or by yourself). The last step is the

creation of a sumo-ambassadorconfiguration file.

In contrast to standard traffic simulations usingSUMOonly,VSimRTIhandles theSUMOfiles in a slight

different way , i.e. the route file for a simulation is created at runtime to enable dynamic routing. To get

correct simulation results, we recommend using the scenario-convert tool to create the SUMO files out

of OpenStreetMap data (see section ??).

3.5.4 Further information

VSimRTI specific information

Notice: SUMObroadcasts 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 Ve-

hicleTypesInitMessage , VehiclePathsInitMessage , SetMaxSpeed , SlowDown , ChangeRoute ,

ChangeStaticRoute and ChangeTrafficLightsState.

Important: The difference between ChangeRoute and ChangeStaticRoute is that

ChangeRoute uses the Re-route feature ofSUMOwhere a new route is calculated internally

bySUMOaccording to a better travel time. ChangeStaticRoute is always used in conjunction

with the NavigationAmbassador which does the route calculation andSUMOtakes this route

statically even if it has e.g. a worse travel time. To avoid confusions of routes, ChangeRouteand ChangeStaticRoute should not be used concurrently.

Known Issues

Traffic light handling in sumo has changed with version 0.13.0, which breaks the support of the

tls.join command of netconvert in VSimRTI > 0.9.12



27/126

3 Simulators 3.6 VISSIM

3.6 VISSIM

VISSIMis a microscopic multi-modal traffic flow simulation software.


Developer(s) PTV Planung Transport Verkehr AG

Written in C++

Operating system Microsoft Windows


Website http://www.ptv-vision.com/de/produkte/vision-traffic-

suite/ptv-vissim/

Supported version(s) >5.30

Deployed inVSimRTIall-in-one

Table 3.5: Software information:VISSIM

To run VISSIM with VSimRTI, additional configuration and modification ofVISSIMis necessary. If you

have any questions or need further support, please feel free to contact our support team via our mailing

list.

http://vissim.de/http://vissim.de/http://vissim.de/http://vissim.de/


28/126

3 Simulators 3.7 VSimRTI Eventserver

3.7 VSimRTI Eventserver

3.7.1 eventserver-ambassador folder structure


vsimrti/scenarios//eventserver/eventserver_config.json

eventserver .....................................................................

eventserver_config.json ..........................Eventserver configuration file

Figure 3.9: eventserver-ambassador folder structure

3.7.2 Installation

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

3.7.3 Configuration



The root node of the configuration is a list of environment events. Each event require the type of the

event, a rectangle area, a strength and the time window.



29/126

3 Simulators 3.8 eWorld

3.8 eWorld

The Hasso-Plattner-Institut fr Softwaresystemtechnik (HPI)in Potsdam founded in year 2009 a combi-

nation of enviroment simulator and traffic visualizer aspecially for traffic visualisation and analysis. The

core of the eWorld enviroment simulator is called eWorldEventServer.

It is capable of handling vehicle movement messages and create sensor events according to environmental

data.

The eWorld-eventserver can be used to simulate events (e.g. rain, fog, ice, ...). The eWorld-eventserver

can be considered as an interface between a socket and the eWorld data management (*.ewd and *.json

export file).


Developer(s) HPI

Written in Java

Operating system Cross-platform


Website http://eworld.sourceforge.net/


Deployed inVSimRTIall-in-one

Table 3.6: Software information: eWorld

3.8.1 eworld-ambassador folder structure


vsimrti/scenarios//eworld/eworld_config.json

eworld ...........................................................................

.ewd ..........................................eWorld binary file

eworld_config.json ............................... ambassador configuration file

Export.json .............................eWorldJSONexport file

Figure 3.10: eworld-ambassador folder structure

3.8.2 Installation

Simply download and use from the website. Be sure to use the latest eWorld release (1.0.1) when using

the latest VsimRTI release.

http://eworld.sourceforge.net/http://eworld.sourceforge.net/


30/126

3 Simulators 3.8 eWorld

3.8.3 Configuration

You can configure the eWorldEventServer via Command Line Interface(CLI) with a base64 encoded json

configuration object from class CEworldEventServer .

This class provide different ways to input data.

A database configuration CDatabase database, a ewd file configuration CFile ewdFile, a json

export file CFile jsonFile or a json string String jsonString .

The prefered way is a export from eWorld to a jsonFile. Afterwards just put the exportet file (.json, .js, .txt)

in the configuration directory mentioned above.

To create a eWorld scenario, please refer to the eWorld Website. There you find a detailed user manual.



31/126

3 Simulators 3.9 VSimRTI cellular simulator

3.9 VSimRTI cellular simulator

3.9.1 cell-ambassador folder structure

The VSimRTI cellular simulator can be configured via three distinct configuration files, which can be

found within the scenarios folder structure:

cell

network.json .........................................Network configuration file

regions.json ..........................................Regions configuration file

geoserver.json ..................................... Geoserver configuration file

Figure 3.11: cell-ambassador folder structure

3.9.2 Installation


3.9.3 Configuration

TheVSimRTIbuilt-in cellular simulator enables the applications to use cellular phone communication.

If you use the cellular simulator you must not use any other network simulator.

The applications have to be altered for the use with the cellular simulator as well as the scenario.

We provide a cellular configuration file in the example scenario Schwanebeck. Please note that in the

default configuration of this scenario the Cellular Simulator is deactivated. To activate the cellular

simulator just add

< f e d e r a te i d =" c e l l " active= " t r u e " / >

to the

vsimrti/scenarios//cell/network.json

(or, if this line already exist, make sure active is true). With this done you now can deactivate all network

simulators:

< f e d e r a te i d =" s w a n s " active= " f a l s e " / >

< f e d e r a te i d =" o m n e t p p " active= " f a l s e " / >

The simulation of cellular communication in VSimRTIconsists of two parts: The cellular simulator

itself and the various changes made to the Application Simulator. These changes are done in a generic

way, making the cellular simulator exchangeable. Users interested in a more sophisticated simulation

of cellular communication may use other simulators and develop ambassadors connecting them to

VSimRTI.



32/126


The cellular simulator in its current version delivers every message. There is no simulation of a maximum

capacity of the cellular network, no dead zone, no simulation of the individual antennas of the network.

A delay estimation is carried out, deterministic or non deterministic.

The global configuration for the cellular simulator in vsimrti/scenar-

ios//cell/network.json, including the global region, could look like this:

{

"configuration":{

"randomSeed":-1,

"deterministic":true,

"maxNodeBandwidth":100000000 /* Bit/s */

},

"delay":{

"delayAverage":300,

"minDelay":20,

"delayType":"ConstantDelay",

"pdr":1.0,

"throughput":5000000,

"simpleRandomDelaySteps":3

},

"logging":{

"logPumsWithInfo":true

}

}

Note that all bandwidths are given in bit per second and all delays in milliseconds. Also, every json

configuration goes through a minifier, so comments are allowed in the configuration files. An example

would be themaxNodeBandwidth option.

The Geoserver

The vehicles, also called nodes, send out messages. The process is very analogous to that of normal

V2X-Messages. The content is therefore the same. The messages can be directed to one single node

(Unicast), every node (Broadcast) or all nodes within a specified region (Geocast). Messages directed tonobody are interpreted as Position Update Messages(PUM)s.

The messages are forwarded through the cellular network to a central instance, here called Geoserver.

The design chosen for this element closely resembles the design chosen within SimTD.

The Geoserver keeps a list of all nodes and updates their position with every new incoming message (be

it aPUMor any other). Based on this stored information the messages are then processed. This means in

particular: A Geocast is commenced based on the latest positional information found stored within the

Geoserver. When a node has not send out a PUM yet it will not receive the message. If the last known

position of the node is outside the targeted area the node will not receive the message even if it moved

into the area in the meantime.



33/126


The Geoserver is also able to recast warnings by itself. If this option is enabled (

warnings.mergeWarnings ) than all Geocasts will be put into a list. At regular intervals (

warnings.reemitInterval ) the warnings will be reemitted, i.e. send to all nodes within the

original geocast-area. The warnings is only send once to every node (The Geoserver keeps a list of all

nodes it has send the warning too).

Additionally the Geoserver tries to merge similar warnings. If the type is the same and the distance is

close enough (smaller than warnings.mergeDistance ) than the newer warning will be ignored. Also a

warning will be discarded after a certain time ( warnings.keepAliveTime), given that no other warning

was received which was merged with the original warning.

The configuration of the Geoserver can be adjusted in the geoserver.jsonfile. A working sample

configuration could look like this:

{

"warnings":{"mergeDistance":100,

"mergeWarnings":true,

"reemitInterval":1000,

"keepAliveTime":600

},

"positionTable":{

"positionGuessInterval":1000

}

}

Delay estimation

The most important feature of the cellular simulator is a estimation of the delay experienced through the

transport over the cellular network. Currently no delay is emulated for the transportation and calculation

done in the backbone of the network. This is mainly due to the expected delay being very small and

constant, thus having little effect on the simulation.

The messages are correctly ordered according to their delay: If message A was to be transmitted td

seconds before message B but tookta> (td+ tb)to be transmitted over the network (tbbeing the delay

experienced by message B) than message A will arrive after message B at the Geoserver. The same is truefor transmissions from the Geoserver to a node.

The cellular simulator offers various modes to estimate the delay of the transmissions. The type of

estimation is specified with bydelay.delayType.

delay.delayType = constantDelay, Constant Delay: The message is transmitted with

the lag being exactly equal to network.delay.delayAverageMs.

delay.delayType = simpleRandomDelay, Simple Random Delay: The lag is random, be-

ing a multiple ofnetwork.delay.delayAverageMs. The number of possible delays can be con-

figured in network.json.



34/126


delay.delayType = gammaRandomDelay, Gamma Random Delay: A gamma distribution is

used to estimate the lag, with = 2 and = 2. The minimum delaydelay.minDelayMsis added

to the result. The curve is fitted so that the maximum likelihood for the delay is exactly equal to

delay.delayAverageMs.

delay.delayType = gammaSpeedDelay, Gamma Speed Delay: This mode closely resem-

bles the Gamma Random Delay. Additionally a penalty for the velocity with which the node

is moving is calculated. This penalty is then multiplied with the original delay.

Delay regions

Additionally the user has the option to define regions with custom delays. This can be used to simulate

areas with bad reception, crowded areas etc.

The regions should be stored in vsimrti/scenarios//cell/regions.json. An ex-

ample definition for a single region called Ernst-Reuter-Platzcould look like this:

{

"regions":[

{ /* First local region */

"area":{

"a":{

"longitude":13.249512,

"latitude":52.871782

},

"b":{

"longitude":13.842773,

"latitude":52.401749

}

},

"name":"Ernst-Reuter-Platz",

"delayType":"SimpleRandomDelay",

"fixedDelay":200, /* This is in milliseconds */

"minDelay":300,

"throughput":35000, /* This is in bit/s */

"simpleRandomDelaySteps":3,

"pdr":1.0,

"pdrType": "DETERMINISTIC",

"regionType":"SQUARE"

}

]

}

Note that arepresents the upper-left point of the rectangle and bthe lower-right. For further information

about the possible options, please refer to the VSimRTI API documentation.



35/126


When no regions are found the delay specified in thenetwork.json-File under delay is treated as a

global fall back estimator: If the node (the vehicle) is not within a specified region the delay is estimated

using the data specified there.

Default values for the configuration

Since VSimRTI version 0.13.0 the cell configuration can be minimal, which means default values are

used for ommited keys. However, default values dont make sense for every key in the cell configuration.

Default values are defined for the following fields:

delayType, defaults to ConstantDelay

pdrType, defaults to Deterministic

fixedDelay, standard is set to 300ms

minDelay, defaults to 150ms

simpleRandomDelayStepsis set to 3 if omitted.



36/126

3 Simulators 3.10 VSimRTI application simulator

3.10 VSimRTI application simulator

The application simulator implements a multi-layered application container with own application and

facility layer and interfaces to the network layer. It serves as a framework for users to create custom V2X

applications.

3.10.1 Installation


3.10.2 application-ambassador folder structure


vsimrti/scenarios//application/applications_config.json

application .....................................................................

applications .................................................................

rsu ........................................................................

trafficlight ..............................................................

vehicle ....................................................................

applications_config.json ............... Configuration file for the ambassador.

mapping3 ........................................................................

mapping_config.json ...................... Configuration file for the ambassador.

mapping ..........................................................................

applications.xml ... Enables detailed mapping of applications to simulation objects.

mapping_config.xml Main configuration file, combines all object properties and defines

ratio of vehicle types in the simulation.

rsu_positions.xml ............... Configuration of Road Side Units (RSU)locations.

vehicle_properties.xml ..................... Define special attributes for vehicle.

Figure 3.12: application-ambassador folder structure

3.10.3 Libraries

To develop applications you need to reference to the following libraries.

vsimrti/bin/fed/application/application-federate-x.x.x-shaded.jar

3.10.4 Configuration





37/126


Most of the actual configuration of the applications is done by the mapping-simulator. The mapping-

simulator is responsible for spawning the entities of the simulation and therefore also decide which

application to map onto which entity.

To deploy an application you have to put it into the appropriate subdirectory for the simulated unit.

In the application configuration file you can specify various settings to manage the message sending and

receiving of applications.

In the msg section, the minimal message length can be set in bytes.

It is also possible to configure theCAMsending behavior. This functionality has been revised in version

0.11.0, leading to probable issues with older scenarios.

To deactivate theCAM-Generation in general just delete the complete section.

Completely analogous to the CAM-Generation is thePUM-Generation. APUMis the equivalent to a

CAMwithin cellular communication. Simply rename the cam -section to pum . All options are exactly thesame.

3.10.5 Development of application

Overview

Developing custom applications is rather easy in VSimRTI. If you learn quicker by just looking at source

code yourself: The applications that come with VSimRTI have the Java Source-Files included in their

respective Jar-File. Just open the Jar-File with an archiver of choice and look around.

To develop your own application you have to know three important concepts of the simulator.

One: The interfaces which every application has to implement.

Two: The interfaces you can use to retrieve information, send messages and exert control over the

vehicle.

And three: In case you want to change the content of automatically sent CAMs you need to know about

that as well.

The Application interface

The Application Simulator is the framework for the application and is responsible for basic housekeeping

duties, such as time management, starting and initializing the application. Every application needs to

implement the Application interface, providing methods for the simulator to call in case of certain

events. These methods have to be implemented, even when left empty.

Figure 3.13: Application class diagram



38/126


The Application layer

Every application has access to its own application layer.

Figure 3.14: Application layer class diagram

Provider and Controller interface



Applications can be specific to one of three types of entities:RSUs, traffic lights and of course vehicles.For each of them a specialized provider and controller is available.



39/126


Provider interface

Figure 3.15: Provider class diagram

Controller interface

Figure 3.16: Contro class diagram

CAM content

The following section will show how CAMs are implemented in VSimRTI and how you can alter them.

CAMs consist of four parts:

Header with generic information

MessageBody

ServiceList

TaggedValue list



40/126


First of all generic information like protocol version, creation time stamp are transmitted. Normally

this data set follows a network beacon, already containing data like position and speed. Nevertheless

this functionality must be implemented in the network layer, that means in the network simulator. At

the moment this is not supported and is therefore compensated in the next message part, the message

body.

The body can contain either RSU or Vehicle awareness data. In the first case, only the RSU type is

submitted, but this probably changes with a new CAM specification. In the second case, we provide data

like vehicle width, length, position, speed, type and heading. However, the specification is not completely

implemented, especially acceleration data, as well as light and brake status are missing. The third part of

the CAM specification, the service list, is also not implemented. This will probably change, when a list of

services is defined by the ETSI.

Last but not least a message can contain optional data. This is fully implemented and is used for our

traffic light CAM messages, which provide the traffic light status.

The CAM sending interval can be configured, more information can be found in the configuration section

of the application simulator.

User defined tagged values

You can also send an arbitrary byte field. In this way every byte sent via CAM can be controlled,

nevertheless this is often connected with some serious work.

You may also want to safely serialize / deserialize objects.

If the control of every byte is not needed, the DefaultObjectSerialization can be used. This class converts

an object into a byte field and vice versa.

The main advantage of this approach is the easy way to handle the marshalling: it is all already done. So

the developer can focus on the main facts.

After the user defined tagged value was added, it will be sent with the nextCAM.For more information

have a closer look at the example applications.

Create a "Hello world" application using eclipse

Create a new project in eclipse (FileNew Java Project). Name your application HelloWorldApp

and select JavaSE-1.7 as theJREversion. 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 followingJARand add it to your project:

vsimrti/bin/fed/application/application-federate-x.x.x-shaded.jar

Right click on the "Hello world" Project and choose (New Package). Name the package something

like com.mycompany.vsimrti.applications.HelloWorldApp . Right click on the package and chose

(NewClass). Name the class HelloWorldApp, add the interface



41/126


com.dcaiti.vsimrti.fed.app.api.interfaces.Application

and confirm.

Figure 3.17: HelloWorldApp

You can now continue and make modifications. To deploy the application you have to export the project

(File Export Java/Jar File) and put theJARin the folder

vsimrti/scenarios//application/applications/vehicle

.

Notice: You can download the example Application "HelloWorldApp" from the web-

site.



42/126


Applications that access SUMO TraCI

If SUMO is used as a traffic simulator and a special functionality is required, the

sendSumoTraciByteArrayMessage function in the VehicleControl can be used.

The function expects a string (a unique identifier which will be assigned to the response) and a byte array

(representing the complete Traffic Control Interface (TraCI)request including the header). The message

identifier can be an empty string, but must be not null.

In many cases the command will trigger a response. The application can receive it if

it implements the SumoTraciByteArrayMessageApplication interface. The function

receiveSumoTraciByteArrayMessageResponse() must be implemented. This function will

receive a SumoTraciByteArrayMessageResponse object. This response contains the specified

identifier. The application must handle the identification process of the response itself.

Notice: A response is only delivered to the vehicle which issued the request, butto every

application which implements the SumoTraciByteArrayMessageResponse interface. To

prevent unintentional delivery each application should use an immutable universally unique

identifier (UUID).

Important: Be careful when using this interface and the TraCI commands. The

commands are delivered toTraCIwithout any prior checks.

An example use case: Get the speed from a specific vehicle

This is a short introduction to the deployed application TestSumoTraciByteArrayMessageApp. You should

have a look at the source files for a better understanding.

3.10.6 FacilityTimerInterceptors

The application simulator has an interface to intercept the timer call in the facility layer. This interface

allows a customized creation ofCAMandPUMmessages.

You can instantiate different and multiple interceptors at once and each of them is individually config-

urable. Place the application configuration in the path

vsimrti/scenarios//application/applications_config.json

.

Standard interceptors

We provide two standard packages.

com.dcaiti.vsimrti.fed.app.facilitytimerinterceptors.etsi and

com.dcaiti.vsimrti.fed.app.facilitytimerinterceptors.interval .

Both provide

an CAMGeneration ,



43/126


an PUMGeneration ,

and an CAMandPUMGeneration class.

They all work the same, but send different messages in condition (onlyCAM,onlyPUMor both mes-

sages).

Default configuration Without explicit configuration for theETSIor interval interceptor, a default

configuration is loaded. For theETSIinterceptor have a look at the class CMaxDelta and for the interval

interceptor have a look at the class CInterval .

Notice: For more information about this component, please have a look at the javadoc

(doxygen) documentation.

Configure an interceptor

To instantiate andconfigure interceptors you must specify thethe desired classes in the configuration with

a fully qualified names of the desired classes. Optionally you can deliver a string and a file to configure

each interceptor separate. The delivered configuration is evaluated by the specified interceptor.

Notice: Please do not forget to quote a string with slashes (Escape String). Add back-

slashes before characters that need to be quoted (double quote ").

Notice: If you are using a configuration file and a string and place both ways identical

parameters with different values, the string should always have a higher priority.

Example configurations for standard interceptors

Do not want to use an interceptor This example illustrates the option to doesnt use an inter-

ceptor.

Hint: You can also delete the file. By default there will be no standard interceptor.

{

" _ c o m m e n t " : " W e d o es n t n e ed a n y i n t er c ep t o r . ",

" f a c i l i t y T i m e r I n t e r c e p t o r s " : null

}

Listing 3.6: applications_config.json

Overwrite the ETSI parameter This example illustrates the option to overwrite theETSIparame-

ter via file. An additional file (called ETSIParameter.json in this example) is required. If you are using a

relative file reference, place the additional file in the path

vsimrti/scenarios//application/applications

.



44/126


{

" f a c i l i t y T i m e r I n t e r c e p t o r s " : {

" i n t e r c e p t o r s " : [

{

" c l a s s N a m e " : " c o m . d c a i t i . v s i mr t i . f e d . a p p . f a c i l i t y t im e r i n t e r c e pt o r s . e t s i .

C A M a n d P U M Ge n e r a t i o n "," c o n f i g u r a t i o n F i l e " : " E T S I P a r a m et e r . j s o n "

}

]

}

}


{

" m i n I n t e r v a l " : 1 0 0 0 00 0 0 0 ,

" m a x I n t e r v a l " : 1 0 0 0 00 0 0 0 0 ,

" p o s i t i o n C h a n g e " : 5 . 0 ,

" h e a d i n g C h a n g e " : 4 .0 ,

" v e l o c i t y C h a n g e " : 1 . 0}

Listing 3.8: ETSIParameter.json

This example illustrates the option to overwrite the ETSIparameter via string. No additional file is

required.

{


" i n t e r c e p t o r s " : [

{

" c l a s s N a m e " : " c o m . d c a i t i . v s i mr t i . f e d . a p p . f a c i l i t y t im e r i n t e r c e pt o r s . e t s i .

C A M a n d P U M Ge n e r a t i o n ",

" c o n f i g u r a t i o n S t r i n g " : " { \" m i n I n t e r v a l \ " : 1 0 0 0 00 0 0 0 , \ " m a x I n t e rv a l \ " :

1 0 0 00 0 00 0 0 , \ " p o si t io n C ha n g e \" : 5 .0 , \ " h e ad i n gC h a ng e \ " : 4 .0 , \ "

v e l o c it y C h a n g e \ " : 1 . 0 } "

}

]

}

}


Overwrite the interval parameter This example illustrates the option to overwrite the interval

parameter via string.

{


" i n t e r c e p t o r s " : [

{

" c l a s s N a m e " : " c o m . d c a i t i . v s i mr t i . f e d . a p p . f a c i l i t y t im e r i n t e r c e pt o r s . i n t e r v a l .

C A M G e n e ra t i o n " ,

" _ c o m m e n t " : " T he i n te r va l h a s t h e u n it n s . ",

" c o n f i g u r a t i o n S t r i n g " : " { \" i n t e r v a l \ " : 1 0 0 0 0 0 00 0 } "

}

]

}

}


VSimRTI: Vehicle-2-X Simulation Runtime Infr

Vsimrti User Manual 0.13.1

Documents

Transcript of Vsimrti User Manual 0.13.1