Vsimrti User Manual 0.13.1

(1)

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

Björn Schünemann

Julia Ullrich

Version 0.13.1

March 25, 2014

(2)

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 für Offene Kommunikationssysteme (FOKUS),

Daimler Center for Automotive Information Technology Innovations (DCAITI) and Automotive Services

and Communication Technologies (ASCT).

Contact information

VSimRTIMailing List (developer team)

[email protected]

VSimRTI: Smart Mobility Simulation

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

FraunhoferFOKUS:ASCTCompetence Center

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

(3)

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

3.2.3 Configuration . . . 9

3.3 OMNeT++ . . . 11

3.3.1 omnetpp-ambassador folder structure . . . 11

3.4 ns-3 . . . 15

3.4.1 ns3-ambassador folder structure. . . 16

3.5 SUMO. . . 20

3.5.1 sumo-ambassador folder structure . . . 20

3.5.4 Further information . . . 21

3.6 VISSIM . . . 22

3.7 VSimRTI Eventserver . . . 23

3.7.1 eventserver-ambassador folder structure . . . 23

3.8 eWorld . . . 24

3.8.1 eworld-ambassador folder structure. . . 24

(4)

Contents Contents

3.10 VSimRTI application simulator . . . 31

3.10.2 application-ambassador folder structure . . . 31

3.10.3 Libraries . . . 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.2 navigation-ambassador folder structure . . . 46

3.12 Behavior Module . . . 47

3.12.1 Introduction . . . 47

3.12.2 Planning . . . 48

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

(5)

10Additional information 88 10.1 Overview . . . 88 10.2 PATH configuration . . . 88 10.3 Copyright. . . 90 11List of Acronyms 91 A VSimRTI deployment 93

A.1 VSimRTI Folder Structure . . . 93

A.2 File listings . . . 95

B Example scenario Schwanebeck 105

B.1 Folder Structure . . . 106

B.2 File listings . . . 107

C Example scenario Tiergarten 119

C.1 Folder Structure . . . 119

(6)

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 theVSimRTIfeatures 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 need more specific information on a configuration have a look at the javadocs provided alongside the current

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

Extensible Markup Language (XML) style configs.

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

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

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

configuration process.

VSimRTI at a glance

VSimRTIwas built to support users performingV2Xsimulations while maintaining the flexibility to choose which simulators to use. It offers interfaces for the integration of different simulators, e.g. for network, traffic, and environment simulations to provide flexibility to exchange a simulator without changing the underlying infrastructure. For the synchronization and the communication among all components the implemented infrastructure uses common concepts defined in the Institute of Electrical and Electronics

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

the runtime 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 √

(7)

1.2 Download and install

• Download vsimrti-bin.zip from the DCAITI website.

• The package

vsimrti-bin.zip

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

vsimrti

throughout this document.

1.3 License

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

whilst helping 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, you

can 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 theVSimRTI mailing

list.A member of staff registers the new user at theVSimRTIlicense 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)

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

VSimRTIuses the federate-ambassador concept inspired by the concept of theHLA. 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

(9)

2.1 Overview

VSimRTIcan be configured by adapting the files in the /vsimrti/etc directory. 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/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.

(10)

3 Simulators

VSimRTIcouples different simulators and can’t 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 ourmailing 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 Städten - 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

(11)

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.

(12)

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)

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 was

developed 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/<scenarioName>/swans/swans_config.xml

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

Figure 3.2: swans-ambassadorfolder structure

(14)

3 Simulators 3.2 JiST/SWANS

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 Linear

Congruential Generator, MersenneTwister and BlumBlumShub) • Propagation models for path loss and fast fading

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

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

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

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

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

(15)

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

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

(17)

• TheOMNeT++federate as executable

• TheINETMANETmodel framework as library

• An exemplary

vsimrti/scenarios/<scenarioName>/omnetpp/omnetpp.ini

configuration file

The executable was compiled for 64-bit GNU/Linux based operating systems. It was successfully set up under Ubuntu 10.04.2 LTS and Gentoo-Linux 1.12.14 and depends mainly on the installed shared libraries. First of all it requires OMNeT++ libraries. That means OMNeT++ needs to be installed prior 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.

l i b d l . so .2 l i b s t d c ++. so .6 l i b m . so .6 l i b g c c _ s . so .1 l i b c . so .6 l i b p t h r e a d . so .0 l i b t k 8 .5. so l i b t c l 8 .5. so l i b z . so .1 l i b x m l 2 . so .2 l i b m p i _ c x x . so .0 l i b m p i . so .0 libopen - rte . so .0 libopen - pal . so .0 l i b n s l . so .1 l i b u t i l . so .1 l i b X 1 1 . so .6 l i b X f t . so .2 l i b x c b . so .1 l i b f o n t c o n f i g . so .1 l i b f r e e t y p e . so .6 l i b X r e n d e r . so .1 l i b X a u . so .6 l i b X d m c p . so .6 l i b e x p a t . 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

(18)

3 Simulators 3.3 OMNeT++

4. Copy the binaries from the OMNeT++ binary package to fed-folder in the VSimRTI all-in-one package to receive the folder structure as presented in the following Table.

5. Set up an

omnetpp.ini

file in the omnetpp folder of the scenario to be simulated. An example file can be found in the configuration folder of the OMNeT++ package and the tiergarten scenario is already set up according to this scheme.

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

vsimrti/etc/logback.xml

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

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

Listing 3.2: OMNeT++ environment variables.

# S e t t i n g the P A T H v a r i a b l e

e x p o r t P A T H = $ P A T H :/ opt / bin / omnetpp - 4 . 1 / bin or

e x p o r t P A T H = $ P A T H :/ usr / l o c a l / bin / omnetpp - 4 . 1 / bin # S e t t i n g the L D _ L I B R A R Y _ P A T H v a r i a b l e

e x p o r t L D _ L I B R A R Y _ P A T H = $ L D _ L I B R A R Y _ P A T H : i n e t m a n e t

Installation shell script

vsimrti bin

fed

omnetpp

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

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

Figure 3.5: OMNeT++ folder structure

The VSimRTI all-in-one package comes with an experimental installation script for the bash-shell, that automates the task of the OMNeT++/INETMANET installation.

1. Make the script executable:

chmod 755 set_env

chmod 755 omnet_installer

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

./set_env

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

(19)

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 Radio

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

3 Simulators 3.4 ns-3

3.4 ns-3

The network simulator 3 (ns-3) is a discrete-event network simulator, that was started as an 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 GUI-based 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 download1the 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 (seehttp://www.

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

the ns-3 installation guide, the officially supported platforms include (please note, that plenty of other distributions are likely to work with ns-3 regardless):

• Fedora 17 (32/64 bit) with g++-4.7.0 • Fedora 15 (64 bit) with g++-4.6.3 • Ubuntu 12.04 (32/64 bit) with g++-4.6.3 • Ubuntu 10.04.4 LTS (64 bit) with g++-4.4.3 • OS X Mountain Lion 10.7.4 with g++-4.2.1 • OS X Snow Leopard 10.6.8 with g++-4.2.1 • FreeBSD 8.2 (32 bit) with g++-4.2.1 • Cygwin 1.7.9-1 with g++-4.5.3

(21)

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

<scenarioName> ns3

ns3_config.xml ...ambassador configuration file

Figure 3.6: ns3-ambassador folder structure

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

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

3.4.2 Installation

VSimRTI offers support for the current stable release of ns-3 (3.15), that was released in August 2012 (older versions of ns-3 (prior to 3.15) are not supported). The coupling to VSimRTI is designed in a manner of minimal code changes on the ns-3 simulator itself to keep the update capabilities for future versions.

Prerequisites

For GNU/Linux platforms, the minimal requirements to run basic simulations are a gcc or clang compiler and a Python interpreter:

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

(22)

• FreeBSD x86 and x86_64: gcc version 4.2, clang versions 3.0 and 3.1. • Mac OS X ppc and x86: gcc versions 4.0 and 4.2,

The core of ns-3 requires a gcc/g++ installation of 3.4 or greater and Python 2.4 or greater. As mentioned in the ns-3 documentation, different options require additional support. At least you need the following packages to be installed:

Listing 3.3:Ns-3: Minimum requirements gcc

g ++ p y t h o n python - dev

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

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

Run the installation script

Important: Ns-3 requires several packages to be installed on your computer. You will

need to ensure, that all required libraries are present on your system before proceeding. You may need superuser permissions to install packages.

To ease the installation of ns-3 for VSimRTI, the installation process has been delegated to an installation script, that can be found in the associated ns-3 federate folder.

vsimrti bin

fed ns3

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

Figure 3.7: ns3-ambassador federate folder structure

The ns-3 installation script accomplishes the following tasks: 1. Download ns-3 tarball from the offical sources

2. Download the ns-3 federate for VSimRTI.

3. Apply a patch to ns-3 in order to make it work with VSimRTI. 4. Add the ns-3 federate to the waf build system.

5. Configure and build the patched ns-3 with the ns-3 federate. In order to start the simulation, the following steps need to be performed:

1. Set up theconfWifi.xml-file in the scenario folder (see section3.4.3). An exampleconfWifi.xml

-file is shipped with the Tiergarten scenario.

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

(23)

3. At last ns-3 has to be activated in thevsimrti_config.xmland the simulation can be started.

3.4.3 Configuration

The whole ns-3 specific configuration is done via theconfWifi.xmlandconfigTechnologies.xml

files. Listing 3.4:confWifi.xml < ?xml v e r s i o n=" 1.0 " e n c o d i n g =" UTF -8 " s t a n d a l o n e=" no "? > < w i f i > < !- - I P v 4 a d d r e s s g e n e r a t o r - -> < ip a d d r e s s =" 1 9 2 . 1 6 8 . 0 . 0 " m a s k =" 2 5 5 . 2 5 5 . 0 . 0 "/ > < !- - C a l c u l a t e a p r o p a g a t i o n d e l a y - -> < d e l a y m o d e l = " 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 "/ > < !- - M o d e l i z e the p r o p a g a t i o n l o s s t h r o u g h a t r a n s m i s s i o n m e d i u m - -> < l o s s m o d e l = " 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 "/ > < w i f i C o n f i g u r a t i o n >

< !- - C r e a t e non QoS - e n a b l e d MAC l a y e r s - ->

< w i f i M a c p r o p e r t y =" t y p e " v a l u e =" n s 3 : : A d h o c W i f i M a c "/ > < !- - W i f i PHY m o d e - -> < w i f i M a n a g e r p r o p e r t y =" p h y M o d e " v a l u e =" O f d m R a t e 5 4 M b p s "/ > < !- - W i f i m a n a g e r - -> < w i f i M a n a g e r p r o p e r t y =" t y p e " v a l u e =" n s 3 : : C o n s t a n t R a t e W i f i M a n a g e r "/ > < !- - The e n e r g y of a r e c e i v e d s i g n a l s h o u l d be h i g h e r t h a n t h i s t h r e s h o l d ( dbm ) to a l l o w ⤦ Ç the PHY l a y e r to d e t e c t the s i g n a l - ->

< w i f i P h y p r o p e r t y =" E n e r g y D e t e c t i o n T h r e s h o l d " v a l u e =" -81.0 "/ >

< !- - The e n e r g y of a r e c e i v e d s i g n a l s h o u l d be h i g h e r t h a n t h i s t h r e s h o l d ( dbm ) to a l l o w ⤦ Ç the PHY l a y e r to d e c l a r e CCA B U S Y s t a t e - ->

< w i f i P h y p r o p e r t y =" C c a M o d e 1 T h r e s h o l d " v a l u e =" -99.0 "/ > < !- - T r a n s m i s s i o n g a i n ( dB ) - -> < w i f i P h y p r o p e r t y =" T x G a i n " v a l u e =" 0.0 "/ > < !- - R e c e p t i o n g a i n ( dB ) - -> < w i f i P h y p r o p e r t y =" R x G a i n " v a l u e =" 0.0 "/ > < !- - N u m b e r of t r a n s m i s s i o n p o w e r l e v e l s a v a i l a b l e b e t w e e n T x P o w e r S t a r t and T x P o w e r E n d ⤦ Ç i n c l u d e d - -> < w i f i P h y p r o p e r t y =" T x P o w e r L e v e l s " v a l u e =" 1 "/ > < !- - M a x i m u m a v a i l a b l e t r a n s m i s s i o n l e v e l ( dbm ) - -> < w i f i P h y p r o p e r t y =" T x P o w e r E n d " v a l u e =" 1 7 . 0 "/ > < !- - M i n i m u m a v a i l a b l e t r a n s m i s s i o n l e v e l ( dbm ) - -> < w i f i P h y p r o p e r t y =" T x P o w e r S t a r t " v a l u e =" 1 7 . 0 "/ >

< !- - L o s s ( dB ) in the Signal - to - Noise - R a t i o due to non - i d e a l i t i e s in the r e c e i v e r - -> < w i f i P h y p r o p e r t y =" R x N o i s e F i g u r e " v a l u e =" 0.0 "/ >

< !- - C h a n n e l c e n t e r f r e q u e n c y = C h a n n e l s t a r t i n g f r e q u e n c y + 5 MHz * ( nch - 1) - -> < w i f i P h y p r o p e r t y =" C h a n n e l N u m b e r " v a l u e =" 1 "/ >

< / w i f i C o n f i g u r a t i o n > < / w i f i >

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.

(24)

ns3::FriisPropagationLossModel. Radio propagation models in ns-3 can easily be exchanged with the ns-3 class registration system (see the ns-3 documentation for details). The Wi-Fi configuration includes additional parameters, like sending power and antenna gain.

Listing 3.5:configTechnologies.xml < ?xml v e r s i o n=" 1.0 " e n c o d i n g =" UTF -8 " s t a n d a l o n e=" no "? > < n s 3 C o n f i g u r a t i o n > < / n s 3 C o n f i g u r a t i o n >

The configuration manager of the ns-3 federate defines, which installer should be loaded for the Wi-Fi

device (refering to theconfWifi.xml) and the mobility model. Usually, you don’t need to take any

(25)

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/<scenarioName>/sumo/sumo_config.json

sumo ... <scenarioName>.edg.xml ...Edge file

<scenarioName>.net.xml ...Network file

<scenarioName>.nod.xml ...Node file

<scenarioName>.rou.xml ...Route file

<scenarioName>.sumo.cfg ...sumo configuration file

sumo_config.json ...ambassador configuration file

Figure 3.8: sumo-ambassadorfolder structure

3.5.2 Installation

For Microsoft Windows operating systems download and extract

sumo_winbin.zip

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

GNU/Linux binaries or build sumo by yourself. Please refer to theSUMOWiki for further

(26)

3 Simulators 3.5 SUMO

In order to runSUMOwith VSimRTI you need to make theSUMObinaries available system wide by

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

3.5.3 Configuration

TheSUMOconfiguration consists of sumo specific config files and the sumo-ambassador configuration

file.

vsimrti/scenarios/<scenarioName>/sumo

. Your main configuration file name must end with the suffix *.cfg. TheSUMOWiki covers more

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

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,SUMOsubscribes 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, ChangeRoute and ChangeStaticRoute should not be used concurrently.

Known Issues

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

(27)

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 ourmailing

(28)

3 Simulators 3.7 VSimRTI Eventserver

3.7 VSimRTI Eventserver

3.7.1 eventserver-ambassador folder structure

vsimrti/scenarios/<scenarioName>/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)

3.8 eWorld

The Hasso-Plattner-Institut für 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/<scenarioName>/eworld/eworld_config.json

eworld ... <scenarioName>.ewd ...eWorld binary file

eworld_config.json ...ambassador configuration file

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

(30)

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

This class provide different ways to input data.

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

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

(31)

3.9 VSimRTI cellular simulator

3.9.1 cell-ambassador folder structure

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

<scenarioName> cell

network.json ...Network configuration file

regions.json ...Regions configuration file

geoserver.json ... Geoserver configuration file

Figure 3.11: cell-ambassador folder structure

3.9.2 Installation

3.9.3 Configuration

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

< !- - C e l l f e d e r a t e - ->

< f e d e r a t e id =" c e l l " a c t i v e =" t r u e " / >

to the

vsimrti/scenarios/<scenarioName>/cell/network.json

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

< !- - N e t w o r k s i m u l a t o r f e d e r a t e s - -> < f e d e r a t e id =" s w a n s " a c t i v e =" f a l s e " / > < f e d e r a t e id =" o m n e t p p " a c t i v e =" f a l s e " / >

The simulation of cellular communication inVSimRTIconsists 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

(32)

3 Simulators 3.9 VSimRTI cellular simulator

The cellular simulator in its current version delivers every message. There is no simulation of a maximum capacity of the cellular network, no dead zone, no simulation of the individual antennas of the network. A delay estimation is carried out, deterministic or non deterministic.

The global configuration for the cellular simulator in

vsimrti/scenar-ios/<scenarioName>/cell/network.json, including the global region, could look like this:

{ "configuration":{ "randomSeed":-1, "deterministic":true, "maxNodeBandwidth":100000000 /* Bit/s */ }, "delay":{ "delayAverage":300, "minDelay":20, "delayType":"ConstantDelay", "pdr":1.0, "throughput":5000000, "simpleRandomDelaySteps":3 }, "logging":{ "logPumsWithInfo":true } }

Note that all bandwidths are given in bit per second and all delays in milliseconds. Also, every json configuration goes through a minifier, so comments are allowed in the configuration files. An example

would be themaxNodeBandwidthoption.

The Geoserver

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

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

(Unicast), every node (Broadcast) or all nodes within a specified region (Geocast). Messages directed to

nobody are interpreted as Position Update Messages (PUM)s.

The messages are forwarded through the cellular network to a central instance, here called Geoserver. The design chosen for this element closely resembles the design chosen within SimTD.

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

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

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 thegeoserver.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 took ta> (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 true for transmissions from the Geoserver to a node.

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

estimation is specified with bydelay.delayType.

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

the lag being exactly equal tonetwork.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

(34)

3 Simulators 3.9 VSimRTI cellular simulator

• 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 invsimrti/scenarios/<scenarioName>/cell/regions.json. An

ex-ample definition for a single region called Ernst-Reuter-Platz could look like this:

{

"regions":[

{ /* First local region */ "area":{ "a":{ "longitude":13.249512, "latitude":52.871782 }, "b":{ "longitude":13.842773, "latitude":52.401749 } }, "name":"Ernst-Reuter-Platz", "delayType":"SimpleRandomDelay",

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

"throughput":35000, /* This is in bit/s */ "simpleRandomDelaySteps":3, "pdr":1.0, "pdrType": "DETERMINISTIC", "regionType":"SQUARE" } ] }

Note that a represents the upper-left point of the rectangle and b the lower-right. For further information about the possible options, please refer to the VSimRTI API documentation.

(35)

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 don’t 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

(36)

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/<scenarioName>/application/applications_config.json <scenarioName> application ... applications ... rsu ... trafficlight ... vehicle ... applications_config.json ... Configuration file for the ambassador.

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

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

mapping_config.xml Main configuration file, combines all object properties and defines ratio of vehicle types in the simulation.

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

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

Figure 3.12: application-ambassador folder structure

3.10.3 Libraries

To develop applications you need to reference to the following libraries. • vsimrti/bin/fed/application/application-federate-x.x.x-shaded.jar

3.10.4 Configuration

(37)

Most of the actual configuration of the applications is done by the 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 theCAM-Generation is thePUM-Generation. APUMis the equivalent to a

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

same.

3.10.5 Development of application

Overview

Developing custom applications is rather easy in VSimRTI. If you learn quicker by just looking at source code yourself: The applications that come with VSimRTI have the Java Source-Files included in their respective Jar-File. Just open the Jar-File with an archiver of choice and look around.

To develop your own application you have to know three important concepts of the simulator. One: The interfaces which every application has to implement.

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

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

The Application interface

The Application Simulator is the framework for the application and is responsible for basic housekeeping duties, such as time management, starting and initializing the application. Every application needs to

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

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

+initialize(applicationLayer : ApplicationLayer) : v... +receiveMessage(msg : TypedV2XMessage) : void +dispose() : void

<<Interface>> Application

<<Property>> <+minimalTimerCallInterval : l... +timerCall(time : long) : void

<<Interface>> TimerCall Visual Paradigm for UML Standard Edition(Technische Universitaet Berlin)

(38)

3 Simulators 3.10 VSimRTI application simulator

The Application layer

Every application has access to its own application layer.

<<Property>> <+>communicationPoolActive : bool... <<Interface>>

PoolCommunicationModule

+initialize(applicationLayer : ApplicationLayer) : v... +receiveMessage(msg : TypedV2XMessage) : void +dispose() : void <<Interface>> Application <<Property>> <+applicationT... +f() : ApplicationToFacility <<Interface>> ApplicationToFacilityReferen

ce <<Property>> <+>userTaggedValue : byte[] <<Interface>>

UserTaggedValueStorage

<<Property>> <+>cellCommunicationModuleActive : bool... <<Interface>>

CellCommunicationModule

<<Interface>>

FacilityLayer

<<Property>> <+nodes : HashMap<String, Double> <<Property>> <+routes : HashMap<String, ArrayList<Strin...

<<Interface>>

VehicleRoutingInformation

<<Property>> <+>wLANCommunicationModuleActive : bool... <<Interface>> WLANCommunicationModule <<Interface>> CommunicationMod ule +triggerTimerCallUpdate() : void <<Interface>> TriggerTimerCallUpdate <<Interface>> ApplicationLaye r

<<Property>> +>conﬁguration : CFacilityTimerInterce... <<Property>> <+enabled : boolean <<Property>> +>facilityLayer : FacilityLayer

<<Interface>>

FacilityTimerInterceptor

<<Property>> <+minimalTimerCallInterval : l... +timerCall(time : long) : void

<<Interface>> TimerCall <<Interface>> PoolAccess +sendPUM() : void +sendCAM() : void <<Interface>> MessageSender

<<Property>> <+communicationModuleReference : CommunicationMo... <<Interface>>

CommunicationModuleReference

+sendUdpMessageTopo(msg : TypedV2XMessage) : void +sendTCPMessageTopo(msg : TypedV2XMessage) : void

<<Interface>> ApplicationLayerSendMessage <<Property>> <+p... <<Interface>> PoolAccessReferen ce

<<Property>> <+unitType : UnitType <<Property>> <+logger : Logger

<<Interface>>

ApplicationToFacility

-useFirstTimerCall : boolean = true -lastTimerCall : long +SafeTimerLong(timerCall : TimerC... +checkTimer(time : long) : boolean +reset() : void SafeTimerLong +facilityLayer -timerCall +poolAccessReference +applicationToFacility +communicationModuleReference

Visual Paradigm for UML Standard Edition(Technische Universitaet Berlin)

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.

(39)

Provider interface

<<Property>> +ctrLanes : Collection<String> <<Property>> +traﬃcLightGroup : TraﬃcLightGr...

<<Interface>>

TraﬃcLightProvider

<<Property>> +vehicleProviderReference : VehicleProvider <<Interface>>

VehicleProviderReference

<<Property>> +basicProviderReference : BasicProvider <<Interface>>

BasicProviderReference

<<Property>> +rSUProviderReference : RSUProvider <<Interface>>

RSUProviderReference

<<Property>> +traﬃcLightProviderReference : TraﬃcLightProvider <<Interface>>

TraﬃcLightProviderReference

<<Interface>>

RSUProvider

<<Property>> +heading : double <<Property>> +vehicleTau : double <<Property>> +vehicleSigma : double <<Property>> +vehicleMaxSpeed : double <<Property>> +vehicleMaxAcceleration : double <<Property>> +vehicleMaxDeceleration : double <<Property>> +vehicleClass : VehicleClass <<Property>> +currentCurveRadius : double <<Property>> +vehicleLeftBlinkerOn : boolean <<Property>> +vehicleRightBlinkerOn : boolean <<Property>> +vehicleBrakeLightOn : boolean <<Property>> +vehicleFogLightOn : boolean <<Property>> +vehicleFrontLightOn : boolean <<Property>> +vehicleHighBeamLightOn : boolean <<Property>> +cO2Emissions : double <<Property>> +currentRoadLength : double <<Property>> +currentRoadMaxSpeed : double <<Property>> +road : String <<Property>> +speed : double <<Property>> +lane : int <<Property>> +route : List<String> <<Property>> +routeId : String <<Property>> +stopped : boolean <<Property>> +charging : boolean <<Property>> +stateOfCharge : ﬂoat <<Property>> +batteryEmpty : boolean <<Property>> +batteryFull : boolean

<<Interface>> VehicleProvider <<Interface>> PoolProviderReference <<Interface>> PoolProvider

<<Property>> +currentTime : long <<Property>> +longLat : Double <<Property>> +directPosition : DirectPosition <<Property>> +longTimeStamp : long <<Property>> +unitType : UnitType <<Property>> +unitName : String <<Property>> +systemState : SystemState <<Property>> +attribute : SystemState +getStateOfEnvironmentSensor(type : SensorType)... <<Interface>> BasicProvider +traﬃcLightProviderReference +basicProviderReference +vehicleProviderReference +rSUProviderReference

Figure 3.15: Provider class diagram

Controller interface

<<Interface>>

BasicControlle r

<<Property>> +basicControlReference : BasicController <<Interface>> BasicControllerReference <<Interface>> PoolController <<Interface>> PoolControllerReference <<Interface>> RSUController

<<Property>> +rSUControlReference : RSUController <<Interface>>

RSUControllerReference

<<Property>> +phaseRemainingDuration ... <<Property>> +programById : String

<<Interface>>

TraﬃcLightController

<<Property>> +traﬃcLightControlReference : TraﬃcLightContr... <<Interface>>

TraﬃcLightControllerReference

+setMaximumSpeed(speed : ﬂoat, data : BehaviorDataStruct) : void +slowDown(speed : ﬂoat, interval : int, data : BehaviorDataStruct) : void +changeRoute(longLat : Double, travelTime : long, data : BehaviorDataStruct) : void +changeRoute(edgeIdList : List<String>, data : BehaviorDataStruct) : void +changeTarget(longLat : Double, data : BehaviorDataStruct) : void +changeLane(targetLaneIndex : int, duration : int, data : BehaviorDataStruct) : void +changeLane(changeLaneMode : ChangeLaneMode, duration : int, data : BehaviorDataStruct) : void +sendSumoTraciByteArrayMessage(msgId : String, msg : byte [], data : BehaviorDataStruct) : void +stop(edgeID : String, position : double, laneIndex : byte, duration : int, stopFlag : byte, data : BehaviorDataSt... +resume(data : BehaviorDataStruct) : void

+requestStartCharging(vehicleID : String, time : long, vehiclePosition : Double) : void +requestStopCharging(vehicleID : String, time : long, vehiclePosition : Double) : void

<<Interface>>

VehicleController

<<Property>> +vehicleControlReference : VehicleController <<Interface>>

VehicleControllerReference

<<Property>> +maximumSpeed : float +slowDown(speed : float, interval : int) : void +changeRoute(longLat : Double, travelTime : long) : void +changeRoute(edgeIdList : List<String>) : void +changeTarget(longLat : Double) : void +changeLane(targetLaneIndex : int, duration : int) : void +changeLane(changeLaneMode : ChangeLaneMode, duration : int) : void +sendSumoTraciByteArrayMessage(msgId : String, msg : byte []) : void +stop(edgeID : String, position : double, laneIndex : byte, duration : int, ... +resume() : void <<Interface>> VehicleControllerNoBehavior +rSUControlReference +basicControlReference +vehicleControlReference +trafficLightControlReference

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