Vsimrti User Manual 18.0

vsimrti-user-manual-18.0

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 141 [warning: Documents this large are best viewed by clicking the View PDF Link!]

VSimRTI: Vehicle-2-X Simulation
Runtime Infrastructure
User Documentation
Michalis Adamidis Manuel Bock Roland Cristea Sebastian Dunkel
Jan Henning Adrian Herrmann Jiajun Hu Karl Hübner
Sven Erik Jeroschewski Franz Kage Bernard Ladenthin Nico Naumann
Robert Protzmann Tobias Queck Stefan Reichel David Rieck
Stefan Rulewitz Alexander Scheck Erik Schleiff Björn Schünemann
Julia Ullrich Sascha-Gaetano Urso Michael Weiner
Version 18.0
April 24, 2018
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 of V2X applications.
The developer alliance
The developer alliance consists of Fraunhofer-Institut für Offene Kommunikationssysteme (
FOKUS
),
Daimler Center for Automotive Information Technology Innovations (
DCAITI
) and Automotive Services
and Communication Technologies (ASCT).
Contact information
VSimRTI Mailing List (developer team)
vsimrti@fokus.fraunhofer.de
VSimRTI: Smart Mobility Simulation
http://www.dcaiti.tu-berlin.de/research/simulation
Fraunhofer FOKUS:ASCT Competence Center
https://www.fokus.fraunhofer.de/asct
DCAITI
http://www.dcaiti.tu-berlin.de
Contents
1 Introduction 1
1.1 Overview ................................................. 1
1.2 Download and install .......................................... 1
1.3 Update .................................................. 2
1.4 License .................................................. 2
1.5 Concept .................................................. 3
1.5.1 Federates and Ambassadors .................................. 3
1.5.2 Scenario configuration ..................................... 3
2 Run simulations 4
2.1 Run a single simulation via CLI .................................... 4
2.1.1 VSimRTIEmbeddedStarter ................................... 5
2.2 Results .................................................. 7
2.2.1 Logging .............................................. 7
2.3 Run a simulation set via CLI ...................................... 8
3 Simulators 9
3.1 Kinds of simulators ........................................... 9
3.1.1 Network simulators ....................................... 9
3.1.2 Traffic simulators ........................................ 10
3.1.3 Application simulators ..................................... 10
3.1.4 VSimRTI communication simulators ............................. 10
3.1.5 Environment simulators .................................... 11
3.1.6 Electricity simulators ...................................... 11
3.2 OMNeT++ ................................................ 12
3.2.1 omnetpp-ambassador folder structure ........................... 12
3.2.2 Installation ............................................ 13
3.3.3 Installation in Docker environment ............................. 19
3.2.4 Configuration .......................................... 15
3.3 ns-3 .................................................... 16
3.3.1 ns3-ambassador folder structure ............................... 17
3.3.2 Installation ............................................ 17
3.3.3 Installation in Docker environment ............................. 19
3.3.4 Configuration .......................................... 20
3.4 SUMO ................................................... 22
3.4.1 sumo-ambassador folder structure ............................. 22
3.4.2 Installation ............................................ 22
3.4.3 Configuration .......................................... 23
3.4.4 Using the SUMO GUI with VSimRTI ............................. 23
3.4.5 Routes and Vehicle Types ................................... 23
3.4.6 Further information ...................................... 24
3.4.7 VSimRTI specific information ................................. 24
3.5 VSimRTI Application Simulator .................................... 25
3.5.1 applicationNT-ambassador folder structure ........................ 25
3.5.2 Installation ............................................ 25
3.5.3 Libraries ............................................. 25
3.5.4 Basic functionality ....................................... 25
3.5.5 Gather information in an application ............................ 26
Contents Contents
3.5.6 Equipped units ......................................... 26
3.5.7 Technical details ........................................ 26
3.5.8 Configuration .......................................... 26
3.5.9 Development of applications ................................. 27
3.5.10 Debugging of applications ................................... 29
3.5.11 Internal ETSI applications ................................... 30
3.5.12 Sending Cooperative Awareness Messages (CAM) ..................... 31
3.5.13 Access SUMO TraCI from applications ............................ 32
3.5.14 Navigation ............................................ 32
3.5.15 Mapping 3 ............................................ 33
3.6 VSimRTI Cellular Simulator ...................................... 36
3.6.1 cell2-ambassador folder structure .............................. 36
3.6.2 Installation ............................................ 37
3.6.3 Configuration .......................................... 37
3.6.4 Operation ............................................ 40
3.7 VSimRTI Simple Network Simulator ................................. 41
3.7.1 sns-ambassador folder structure ............................... 41
3.7.2 Installation ............................................ 41
3.7.3 Configuration .......................................... 41
3.7.4 Operation ............................................ 42
3.8 VSimRTI Eventserver .......................................... 44
3.8.1 eventserver-ambassador folder structure .......................... 44
3.8.2 Installation ............................................ 44
3.8.3 Configuration .......................................... 44
3.9 VSimRTI Battery Simulator ...................................... 45
3.9.1 battery-ambassador folder structure ............................ 45
3.9.2 Installation ............................................ 45
3.9.3 Introduction ........................................... 45
3.9.4 Vehicle model .......................................... 45
3.9.5 Battery model .......................................... 45
3.9.6 Environment model ...................................... 46
3.9.7 Sample configuration ...................................... 46
4 Tutorial Tiergarten 47
4.1 Mapping Configuration ........................................ 48
4.2 Inter-Vehicle Communication ..................................... 49
4.3 Intra-Vehicle Communication ..................................... 53
4.3.1 The traffic light application .................................. 54
4.4 Interpretation of simulation results ................................. 55
5 Tutorial Barnim 56
5.1 Overview ................................................. 56
5.2 Mapping configuration ......................................... 57
5.3 VSimRTI configuration ......................................... 58
5.4 Applications ............................................... 58
5.4.1 DEN-Message handling .................................... 59
5.4.2 Cellular Communication .................................... 59
5.5 Conclusion ................................................ 60
6 Tutorial Traffic Lights 61
6.1 Use scenario-convert to export traffic lights ............................. 61
6.2 Determine the traffic lights that should be equipped with applications ............. 62
6.3 Configure the mapping for traffic lights ............................... 62
6.4 The Traffic Light API .......................................... 63
7 Tutorial LuST 64
7.1 Execute the LuST scenario with VSimRTI .............................. 65
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 4
Contents Contents
7.2 Current limitations ........................................... 65
8 Create a new scenario 66
8.1 Road network data ........................................... 66
8.1.1 Using OpenStreetMap data .................................. 66
8.2 Vehicles and Routes ........................................... 68
8.3 VSimRTI ................................................. 69
9 Visualizers 72
9.1 Kinds of Visualizers ........................................... 72
9.2 VSimRTI WebSocket Visualizer .................................... 73
9.3 VSimRTI File Visualizer ......................................... 74
9.3.1 Configuring the File Visualizer ................................ 74
9.4 VSimRTI Integrated Test and Evaluation Framework (ITEF) ................... 78
10Run simulation series 80
10.1 Simulation Runner ........................................... 80
10.1.1 Usage ............................................... 80
10.1.2 Configuration .......................................... 81
10.1.3 Parametrization ......................................... 83
10.1.4 Additional Information ..................................... 85
11Additional tools 86
11.1 scenario-convert ............................................ 86
12VSimRTI configuration 90
12.1 Overview ................................................. 90
12.2 Federates configuration ........................................ 90
12.2.1 Federate priorities ....................................... 91
12.3 Host configuration ........................................... 91
13Additional information 92
13.1 PATH configuration ........................................... 92
14List of Acronyms 94
A VSimRTI deployment 96
A.1 VSimRTI Folder Structure ....................................... 96
A.2 File listings ................................................ 98
B Example scenario Barnim 108
B.1 Folder Structure .............................................108
B.2 File listings ................................................109
C Example scenario Tiergarten 123
C.1 Folder Structure .............................................123
C.2 File listings ................................................124
D Package Additional Examples 126
E Configuration Schemata 128
F References 134
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 5
1 Introduction
1.1 Overview
This documentation is part of the current release of
VSimRTI
and aims at supporting users in their first
steps with the software. We try to explain most of
VSimRTI
’s features and configurations by providing two
tutorials named Barnim (see chapter 5) and Tiergarten (see chapter 4).
If you need more information regarding
VSimRTI
or a specific configuration, we ask you to take a look
at the Doxygen documentation provided alongside the current release. Documentation is available for
all
JSON
style configs. Apart from that the appendix provides information for the respective
XML
style
configurations.
If you have any questions or need further support, please feel free to contact our support team via our
mailing list. Please attach relevant log files and scenario files to your inquiry. We look forward to receiving
your feedback concerning further improvements of the
VSimRTI
documentation as well as the installation
and configuration process.
VSimRTI at a glance
VSimRTI
was built to provide users with the flexibility to perform various
V2X
simulations with their own
choice of simulators. In order to provide the flexibility to exchange a simulator without changing the
underlying infrastructure,
VSimRTI
offers several interfaces for the integration of different simulators,
e.g. for network, traffic, and environment simulations. For the synchronization and the communication
purposes, the implemented infrastructure uses common concepts defined in the Institute of Electrical and
Electronics Engineers (
IEEE
) standard for modelling and simulation (
M&S
) High-Level Architecture (
HLA
).
Thus, the runtime infrastructure
VSimRTI
allows a flexible combination of time-discrete simulators for
V2X
simulations. Based on the (possibly differing) requirements of a specific scenario, arbitrary simulators
can be added to VSimRTI and are executed together.
VSimRTI
is written in the programming language Java and deployed as Java Archive (
JAR
) files. Conse-
quently, a compatible Java Runtime Environment (
JRE
) for your operating system must be installed to
execute VSimRTI. Currently, Java version 8 is required to run VSimRTI.
1.2 Download and install
• Download vsimrti-bin-18.0.zip from the DCAITI website .
•
The package
vsimrti-bin-18.0.zip
has to be extracted to an arbitrary path. This installation
path is referenced as vsimrti throughout the entire document.
1 Introduction 1.3 Update
1.3 Update
In order to update VSimRTI to a new version, please perform the following steps manually:
• Backup your personal simulation scenarios from VSimRTI’s scenarios directory.
• Remove your old VSimRTI installation completely.
• Install VSimRTI according to the previous section.
• Copy your simulation scenarios back to VSimRTI’s scenarios directory.
• Migrate your scenarios to individual changes in the new VSimRTI version according to the
vsimrti-conversion-guide-18.0.pdf , which can be found on the DCAITI website .
1.4 License
The licensing mechanism was introduced for a better release control. It improves user support whilst
helping our developer team to deactivate outdated releases which cannot be maintained anymore. Every
user needs to be registered at the license server to obtain a license.
1.
Running the
firstStart
script in the
VSimRTI
root folder causes the file
vsimrti/systeminfo.txt
to be generated. This file is also generated when
VSimRTI
is
run without a valid license file or an invalid user.
2.
The created file contains basic information in plain text about the machine on which
VSimRTI
was
executed and is used to identify the user. The system info needs to be sent to the VSimRTI mailing
list. A staff member registers the new user at the
VSimRTI
license server as soon as possible, usually
within one workday. When your license is active, an email containing your user id will be sent to
you.
3. The following information is stored to identify your machine:
• central processing unit (CPU) model id
•CPU cores
•CPU architecture
• Media Access Control (MAC) addresses
• operating system name
• operating system version
• random-access memory (RAM) size
• sockets
• hashed user id
•VSimRTI version
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 2
1 Introduction 1.5 Concept
4.
Your license will be activated directly after confirmation by the
VSimRTI
team. On the next
VSimRTI
run with an available Internet connection to the
VSimRTI
license server a valid license is generated
and a local copy is stored in the VSimRTI folder.
5.
The local license files
vsimrti/vsimrti-license.lcs
and
vsimrti/vsimrti.dat
are valid
for the next 14 days. In this period no Internet connection is needed for the execution of
VSimRTI
.
Every time when an Internet connection to the license server can be established, the local license
file will be renewed for another 14 days.
Notice:
You should not backup the license files. If you have a registered account and a
valid license is present on the license server, you will always receive a new license file.
Notice: If you encounter any problems with corrupt license files, you can also use the
firstStart
script to reset the local license files and retrieve a new copy during the next run.
Notice:
If the
firstStart
script does not result in a
vsimrti/systeminfo.txt
file,
please check if you have sufficient rights on your machine. You can also try to start the
vsimrti
script instead, by calling
vsimrti.sh -u <YOUR-EMAIL-ADDRESS> -s Barnim
.
This command will always fail, due to the missing license, however, it may generate the
required systemInfo.txt.
1.5 Concept
In contrast to existing fixed simulator couplings
VSimRTI
allows easy integration and exchangeability
of simulators. Depending on your specific requirements, the high flexibility of
VSimRTI
enables you to
couple the most appropriate simulators for a realistic presentation of vehicle traffic, emissions, wireless
communication, and the execution of V2X applications.
1.5.1 Federates and Ambassadors
VSimRTI
uses the federate-ambassador concept inspired by the concept of the
HLA
. Using this concept, it
is possible to couple different simulation systems with a remote control interface. Attaching an additional
simulator only requires implementation of the appropriate ambassador interface and the possiblity to
execute its specified commands.
1.5.2 Scenario configuration
Any scenario needs to be configured with a configuration file. The specific path to this file is
vsimrti/scenarios/<scenarioName>/vsimrti/vsimrti_config.xml .
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 3
2 Run simulations
Notice:
Install the required simulators for the specific scenario and have a valid license
(see section 1.4).
2.1 Run a single simulation via CLI
To run a single simulation via Command Line Interface (
CLI
) calling the
VSimRTI
start script with the
following command line arguments. The VSimRTI start script supports following arguments.
-c, - -configuration
The primary
VSimRTI
configuration file which is scenario de-
pendent and located in the according scenario folder. This file transitively
includes other necessary configuration files. Usually you will use the file
vsimrti/scenarios/<scenarioName>/vsimrti/vsimrti_config.xml .
-s, - -scenario
If the
VSimRTI
configuration file of your scenario is lo-
cated in the default scenario directory of
VSimRTI
(i.e. in
vsimrti/scenarios/<scenarioName>/vsimrti/vsimrti_config.xml
), this option can
be used instead of the -c option by passing only the scenario name
(-s <scenarioName>).
-u, - -userid
The id of the
VSimRTI
user which was assigned with the authentication for the
VSimRTI
release area. For better release control and support of
VSimRTI
users, a user id is needed to start a
simulation. The user id is connected to a dedicated VSimRTI license.
-w, - -watchdog-interval
The interval of the internal alive check (in seconds) which is used by
VSimRTI
to detect execution stalls. This parameter is not mandatory and it is also possible to turn
off the watchdog (-w 0) for debug sessions.
-o, - -loggingLevelOverride
Override all specified logging-levels. This option is useful for debug-
ging simulations. For example logging every possible event would be done with -o TRACE.
-g, - -performance-GUI
Opens a GUI Panel which provides several charts regarding the current
simulation run, such as the progression of the Real Time Factor or memory consumption of the
simulation.
-b, - -realtimeBrake
With this parameter, the simulation will be slowed done to a desired Real Time
Factor, if possible. When simulations already run slower than real time, this factor will have no
effect. For example, use -b 1 to execute the simulation in real time.
-v, - -start-visualizer
Opens a page in your default browser which visualizes all vehicle move-
ments of the simulation on a map. This option only works, if your scenario has configured the
websocket visualizer (see section 9.2).
2 Run simulations 2.1 Run a single simulation via CLI
GNU/Linux
Listing 2.1: VSimRTI GNU/Linux start command.
./ vsimr ti . sh -c ./ s ce na ri os / < sc en ar io name >/ vsimrti / vsimrt i_ co nf ig . xml - u u se rid
Microsoft Windows
Listing 2.2: VSimRTI Microsoft Windows start command.
vsimr ti . bat -c . \ s ce na rios \ < scen ario n ame >\ vsi mrt i \ v sim rt i_ c on fig . xml -u u se ri d
2.1.1 VSimRTIEmbeddedStarter
The VSimRTIEmbeddedStarter is a customizeable Java start program. You can also use this program
as template to embed
VSimRTI
in your Java application. The VSimRTIEmbeddedStarter is much more
powerful than the start scripts. E.g. the VSimRTIEmbeddedStarter can search in configuration files for
the given scenario id. The embedded starter has a user friendly CLI and many options.
Listing 2.3: VSimRTI VSimRTIEmbeddedStarter help command.
u sa ge : j av a - j ar V s i mr t i E mb e d de d S t ar t e r . ja r
-b , - - r e al t im e Br a ke < R EAL T IM EF A CT OR > Se t v alu e fo r r ea l t im e br a ke .
-c , - - c on fi g < PATH > Pat h t o S ce n ar io c on f ig u ra t io n f il e
( v simrti _c on f ig . xml ) . C an b e us ed i nste ad
of " - s " parameter . ( mandatory ).
-- classpaths Cla ss p at hs . Defa ul t is ". " (working
directory ).
-d , -- de fault s - fil e < PATH > Pat h to V Si mR TI configu ra ti on fil e
( d ef au lt : et c / default s . xml )
-e , - - e x te r na l Wa t ch D og < PO RTN UMB ER > S pe ci f ic ex t er nal w at c hd og po rt n umb e r
-g , - - p er fo rm a nc e - G UI O pe ns p e rf o rm a nc e GU I
-h ,- - hosts < PATH > Pat h to hos t c onfiguration f ile ( default :
et c / ho sts . jso n )
-- he lp Sho ws th is h el p i n fo rm a ti on .
-l , - - l og ge r < PATH > Pat h t o l og ba c k c on f ig u ra t io n f il e
( defau lt : etc / logb ac k .xml )
-- lo gb ac k - p at h < PAT H > Us e speci f ic lo gbac k . x ml
-o ,- - l o g gingLev e l O verride < LOGLEVEL > Overrides the log lev el to new valu e (e . g .
DEB UG )
-p , - - pr oc es s - b u il de r S ta rt V Sim R TI u sin g P r oc e ss B ui l de r .
-- pipe Use pipe re d i r e c t ( on ly for
-- pr oc es s - b ui l de r
-- print - jar - f il es Prin t the f ou nd jar f iles .
- - pri nt - p a ra m e te r Pr i nt t he p a ra m et e r b ef or e s ta r t .
-s ,- - scenario <NAME > The name of the V Si mRTI s ce nario . Can be
used i nstead of " - c " p ar am et er .
( mandatory )
-- si mr un Us e the V Sim RTI simulation r un ne r .
--strict - confi g uration - path The starter pass - through the con f i g u r a t i on
path as it is .
-u ,- - use r < USERID > Your UserId ( mandatory ). Plea s e read the
user manual if you do not h ave a UserId
ye t .
-v ,- - start - visualizer Star t s the web soc k et v i s u a l i z e r .
-- ve rbo se Pri nt information at s tart .
-- v e rsion Print the version information and e x its .
-w , - - w at c hd og - i n te r va l < SE CO ND S > K il l V S im R TI p r oc e ss af te r n s ec o nd s i f a
federate is not responding . 0 disables th e
watchdog . ( d efault : 30)
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 5
2 Run simulations 2.1 Run a single simulation via CLI
Listing 2.4: VSimRTI VSimRTIEmbeddedStarter start command.
jav a - ja r V simrtiEmbedd ed St arter -18.0. jar - u u se ri d - n s ce narioId
While VSimRTI is running, it prints some information on the command line:
_X
[user@gnulinux vsimrti]$ ./vsimrti -u userid -c scenarios/Schwanebeck/vsimrti/vsimrti_config.xml
2012-10-08 11:39:06,442 INFO c - License valid
2012-10-08 11:39:06,449 INFO FederationManagement - Federation with id= Schwanebeck is started
2012-10-08 11:39:06,451 INFO FederationManagement - join federate with id swans
2012-10-08 11:39:06,733 INFO FederationManagement - Start swans local in ./tmp/swans
2012-10-08 11:39:06,939 INFO FederationManagement - join federate with id sumo
2012-10-08 11:39:07,029 INFO FederationManagement - Start sumo local in ./tmp/sumo
2012-10-08 11:39:07,029 INFO FederationManagement - join federate with id application
2012-10-08 11:39:07,252 INFO FederationManagement - Start application local in ./tmp/application
2012-10-08 11:39:07,588 INFO FederationManagement - join federate with id navigation
2012-10-08 11:39:07,589 INFO FederationManagement - join federate with id eworld
2012-10-08 11:39:07,857 INFO FederationManagement - Start eworld local in ./tmp/eworld
eworld
2012-10-08 11:39:11,095 INFO FederationManagement - join federate with id mapping
2012-10-08 11:39:11,096 INFO FederationManagement - join federate with id visualizer
11:39:21.371 - Loading Database: 100%
2012-10-08 11:39:28,613 INFO SequentialTimeManagement - Simulating: 25000000000ns (25.0s)-62.0% (RTF:1,96, ETC:15s)
Figure 2.1: Output of VSimRTI while running
The current simulation progress is shown in the following format.
• current wallclock time
• log level
• unit name
• current simulation time in [ns] and [s]
• progress in %
• Real Time Factor (RTF)
• Estimated Time to Completion (ETC)
The
RTF
is the ratio of simulated time to simulation duration in wallclock time, e.g. a real time factor
greater than 1 means, the simulation is running faster than real time. Both
RTF
and
ETC
are calculated
based on the performance of the last five seconds of the simulation and should only give a rough overview,
how long a simulation can take. Depending on the simulation setup, the values can differ heavily between
start and end of a simulation.
Gather results
To get results from a simulation, the combined simulators have to be properly configured or a federate
has to be integrated that generates global results. For detailed information and visualization possibilities,
e.g. the FileVisualizer for detailed simulation data.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 6
2 Run simulations 2.2 Results
2.2 Results
VSimRTI
generates logfiles for each simulation run. Logs are generated for the ambassadors of each
coupled federate respectively simulator and for VSimRTI itself.
The logfiles are stored in the folder
vsimrti/logs/log-<timestamp>
. For each simulation run a new
folder is created.
In addition to standard logging output for each federate there is a
statistics.csv
file which con-
tains detailed information about sent and received
VSimRTI
messages. This file can be used to trace a
simulation run.
log-<timestamp>
appsNT .............................................................................
<unitType>_<unitId> ................. Detailed application specific logs for each unit.
OperatingSystem.log ................. Detailed operating system logs for the unit.
ExampleApp.log ............. Detailed application specific logs for each application.
ApplicationNT.log ...................... Information about the application ambassador.
Battery.log ................... Battery ambassador log for simulation of electric vehicles.
Cell2.log ....................................................... Cellular network log.
ChargingStation.log ................................ ChargingStation ambassador log.
Communication.log ........................ (Ad hoc) network simulation ambassador log.
CommunicationDetails.log .... Detailed output of network simulator (ns-3 or OMNeT++).
Environment.log ................................ Logs of the environmental eventserver.
Mapping.log .............................................. Mapping configuration logs.
Navigation.log . Detailed logs about navigation component in the application ambassador.
statistics.csv .................. Simulation overview in comma separated value-format.
Traffic.log ................................... Traffic simulation log (SUMO or others).
visualizer.csv ........................... Recorded data of the VSimRTI File Visualizer.
VSimRTI.log ............ General VSimRTI information, e.g. startup sequence information.
Figure 2.2: VSimRTI log folder structure
2.2.1 Logging
The main configuration file is
vsimrti/etc/logback.xml
. In this file, each output can be configured
in great detail. This file can be adjusted to your needs, e.g. you can set up a more detailed logging
for communication components but set a less verbose output for
VSimRTI
internal messages or traffic
simulation depending on your simulation focus.
VSimRTI
uses logback as logging framework and it is suggested to use logback for the other simula-
tors as well. Logback offers a lot of parameters to adapt the output to your needs. Please refer to
(
http://logback.qos.ch/manual/layouts.html#ClassicPatternLayout
) for a detailed overview
of parameters you can use in the logback.xml file.
Please note that you can adjust the output to your needs by setting different log levels (
ERROR
,
INFO
,
DEBUG
etc.) for each component in the file under
vsimrti/etc/logback.xml
. This might also influence the
simulation performance because of a possibly high amount of data to be logged.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 7
2 Run simulations 2.3 Run a simulation set via CLI
Federate specific logging
Depending on the simulation purpose, further configuration possibilities for federate specific logging
may be of interest.
For instance,
OMNeT++
exhibits an elaborated logging concept. The
omnetpp.ini
in the scenario folder
includes options to adjust the logging levels. The outputs of this federate are written into
Communica-
tionDetails.log.
2.3 Run a simulation set via CLI
Notice:
The following options are only available with a commercial license of VSimRTI.
For further information on licenses, please refer to our mailing list .
A common objective when running simulations is to assess the impact of different parameter settings for
a specific scenario on the results of the simulation. To this end, the simulation-runner is a tool to apply
different configurations to a scenario, after which a series of simulations is executed via
CLI
by calling the
simulation-runner start script. Please refer to 10.1.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 8
3 Simulators
VSimRTI
couples different simulators and can’t be run alone. Therefore, it requires pre-installed 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 documen-
tation provided on the
VSimRTI
website . To run other simulators than the provided ones, an additional
component has to be written, which couples the simulator to
VSimRTI
. If you have any questions or
need further support, please feel free to contact our support team via our mailing list.
3.1 Kinds of simulators
The figure 3.1 gives an overview of the currently available simulators for VSimRTI
vsimrti
network simulators ...................................................... (see 3.1.1)
Objective Modular Network Testbed in C++ (OMNeT++) ................. (see 3.2)
network simulator 3 (ns-3) ............................................ (see 3.3)
traffic simulators ...................................................... (see 3.1.2)
Simulation of Urban Mobility (SUMO) .................................. (see 3.4)
application simulators .................................................. (see 3.1.3)
VSimRTI Application Simulator (built in) ............................ (see 3.5)
VSimRTI Mapping (built in) ...................................... (see 3.5.15)
VSimRTI navigation simulator (built in) ....................... (see 3.5.14)
VSimRTI communication simulators ...................................... (see 3.1.4)
VSimRTI Cellular Simulator (built in) ............................... (see 3.6)
VSimRTI Simple Network Simulator (SNS) (built in) .................. (see 3.7)
environment simulators .................................................. (see 3.1.5)
VSimRTI Eventserver (built in) ....................................... (see 3.8)
electricity simulators .................................................. (see 3.1.6)
VSimRTI Battery Simulator (built in) ................................ (see 3.9)
Figure 3.1: VSimRTI simulator structure
3.1.1 Network simulators
A network simulator is a piece of software modeling the behavior of a network by calculating the interac-
tions between all participating entities. For
VSimRTI
and, more specifically, the communication in a
V2X
environment this refers to simulations of the wireless transmissions taking place between the various
simulated entities. The provided simulators are prepared to simulate a communication stack basing on
the
IEEE
802.11p network interfaces with IP and UDP on top. However, according to their model base,
3 Simulators 3.1 Kinds of simulators
alternative set ups are possible. Currently, VSimRTI supports the commonly known network simulators
OMNeT++ and ns-3, and the built in communication simulator SNS.
3.1.2 Traffic simulators
A traffic simulator is a software modeling the movements of users in a traffic system. Users can mean
cars, pedestrians, trains, ships, planes etc. Traffic simulators can be discriminated by various measures,
of which one is the used scope:
Microscopic models
Simulate each car individually and through the interaction of multiple cars
also traffic flows. They are commonly used for situations such as a traffic crossing or an on-ramp
situation.
Macroscopic models
Models of a traffic flow without the modelling of individual cars. Instead the
traffic flow is computed using models derived from fluid dynamics or gas-kinetics. By this the
simulation is computationally far less expensive, so more cars and wider areas can be simulated.
An example would be the prediction of traffic jams.
Mesoscopic models
Try to bridge the gap between macroscopic and microscopic simulation using
individual vehicles that are being actuated by macroscopic control variables.
Sub-Microscopic models
Used to simulate a car in as much detail as possible. The prediction of the
behavior is the most precise of all models, but also computationally the most expensive.
The currently supported traffic simulator SUMO is a microscopic traffic simulator.
3.1.3 Application simulators
An application simulator is an important component enabling the simulation and creation of
V2X
applications. It follows the European Telecommunications Standards Institute (
ETSI
) standards for
Vehicle-to-Vehicle (
V2V
) communication. These standards contain message definitions like Decentralized
Environmental Notification Messages (
DENM
) and Cooperative Awareness Messages (
CAM
) and also a
general application container design.
3.1.4 VSimRTI communication simulators
For different reasons of convenience or extended analysis capabilities,
VSimRTI
ships with two additional
communication simulators:
•
The Cellular Simulator is a special case of network simulator to simulate the communication taking
place within a cellular network, such as Universal Mobile Telecommunications System (
UMTS
) and
Long Term Evolution (LTE).
•
The Simple Network Simulator is written in Java and already tightly integrated in VSimRTI. It offers
a lightweight and fast solution for simulation of ad hoc communication.
The provided
VSimRTI
communication simulators can be used as an alternative (
SNS
) or addition (Cell2)
to classic network simulators.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 10
3 Simulators 3.1 Kinds of simulators
3.1.5 Environment simulators
This kind of simulator simulates certain environmental events such as rain, fog, snow, etc..
3.1.6 Electricity simulators
In connection with
VSimRTI
, electricity simulators enable investigations in the field of electric mobility.
For this purpose, VSimRTI ships with the built in VSimRTI Battery Simulator.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 11
3 Simulators 3.2 OMNeT++
3.2 OMNeT++
OMNeT++
itself is solely the simulation platform for discrete-event systems. Even though it is primarily
targeted at simulating computer networks and distributed systems, it cannot be used without any
extensions for wireless communication. For this kind of simulations, external model frameworks have to
be included. Currently there are two prominent model frameworks which cover whole model suites for
according focus of wireless research. These are the Mobility Framework and the OMNeT++ - Model library
for wired, wireless and mobile networks (
INET
) Framework. As
INET
provides all models necessary for
simulating Vehicle-2-X communication, it is selected for the integration to VSimRTI.
For more information on the
INET
extension you should look closer on the website
https://inet.omnetpp.org.
Software information
Developer(s) OMNeT++ Community and OpenSim Ltd.
Written in C++
Operating system Windows (mingw), Linux
License open source for academic use
Website http://www.omnetpp.org/
https://inet.omnetpp.org
Supported version(s) OMNeT++ 4.6
INET 3.0
Dependencies libprotobuf 3.3.0
Installation via released installation script
Table 3.1: Software information: OMNeT++
3.2.1 omnetpp-ambassador folder structure
The omnetpp.ini file has to be located in the omnetpp folder of the scenario configuration.
<scenarioName>
omnetpp ..........................................................................
omnetpp_config.json .............................. Ambassador configuration file
omnetpp.ini ................................. OMNeT++ federate configuration file
Figure 3.2: omnetpp-ambassador folder structure
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 12
3 Simulators 3.2 OMNeT++
3.2.2 Installation
The
VSimRTI
all-in-one package comes with an installation script for the bash-shell, which automates
the task of the OMNeT++/INET installation.
Prerequisites
The OMNeT++/INET federate furthermore depends upon:
• libprotobuf 3.3.0
Please make sure these libraries are installed before running the installation script.
Installation shell script
vsimrti
bin
fed
omnetpp
Dockerfile ......................... Docker file for OMNeT++/INET federate
omnet_installer.sh .................. Installation script for OMNeT++/INET
Figure 3.3: OMNeT++ folder structure
Please execute the following steps for installing the OMNeT++/INET federate:
1. Follow the link and download the source code of OMNeT++ 4.6 (omnetpp-4.6-src.tgz) :
https://omnetpp.org/omnetpp/download/30-omnet-releases/2290-omnet-4-6-source-ide-tgz
2. Make the installation script executable:
chmod 755 omnet_installer.sh
3. Make sure all dependencies are met by your system.
4. Run the script to install OMNeT++/INET:
./omnet_installer.sh -s /path/to/omnetpp-4.6-src.tgz
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 13
3 Simulators 3.2 OMNeT++
3.2.3 Installation in Docker environment
Notice:
This is an experimental feature. Please refer to our mailing list if you experience
any problems.
This guide gives instructions to execute the
OMNeT++
federate inside a docker container. If you already
installed OMNeT++ on your machine following the steps before, you can skip this section.
Docker
1
is a new approach to execute software. More precisely, it "wraps software in a complete filesystem
that contains everything it needs to run: code, runtime, system tools, and system libraries". As a result, the
software is executed within a container and its execution does not rely on the environment the container
is running in.
In context of
VSimRTI
, this approach allows to execute
OMNeT++
within a docker container. The user
does not need to manually install OMNeT++ and can even run OMNeT++ on Windows hosts.
1. Install Docker ≥1.13 on your machine.
2.
To get everything work, please make sure to execute the following steps depending on your
operating system:
•
Windows - In the settings, share the drive where
VSimRTI
is installed on. You may need to
restart docker in the reset tab.
•
Linux - Make sure your user account belongs to the unix-group "docker". You may need to
restart your machine.
3. Switch to the location of the Dockerfile in vsimrti/bin/fed/omnetpp
4.
Follow the link and download the source code of
OMNeT++
4.6 (omnetpp-4.6-src.tgz) and place
the downloaded file into the vsimrti/bin/fed/omnetpp directory:
https://omnetpp.org/omnetpp/download/30-omnet-releases/2290-omnet-4-6-source-ide-tgz
5. Execute the following command on command line:
docker build -t omnetpp-federate:18.0 .
This could take a while to finish.
6.
Enter the name of the docker image
etc/defaults.xml
in the
omnetpp
-section into the tag
dockerImage:
< federate cl as s = " .. . " >
<id >omnetpp</ id >
...
< do ck er Image >omnetpp-federate:18.0</ dockerImage >
...
</ fede ra te >
You can test the installation of your docker image with the Tiergarten scenario, by activating
omnetpp
in
the vsimrti_config.xml.
1https://www.docker.com/
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 14
3 Simulators 3.2 OMNeT++
3.2.4 Configuration
The whole
OMNeT++
specific configuration is done via the omnetpp.ini file. It covers static parts for the
simulator coupling as the specific
VSimRTI
Event Scheduler and the ScenarioManager. Furthermore,
logging configurations and the typical parameters for the communication layers (MAC, PHY and Radio
Channel) are addressed. The communication parameters are different for vehicles and RSUs. Please refer
to the OMNeT++ documentation on the
OMNeT++
homepage for further information about the structure
of the omnetpp.ini file.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 15
3 Simulators 3.3 ns-3
3.3 ns-3
The
ns-3
is a discrete-event network simulator, that was started as an open-source project by a team
led by
Tom Henderson
from the
University of Washington
in July 2006 and made its first release in June
2008.
ns-3
is targeted primarily towards research and educational use and thereby, also offers a vital
community of developers and maintainers. It was developed as a replacement for the popular network
simulator 2 (
ns-2
) and mainly focuses upon improving the core architecture, software integration, models,
and educational components for real-world network devices and protocols (regardless,
ns-2
still remains
in active use and will continued to be maintained in the near future). It simulates both unicast and
multicast protocols and is used extensively in research on mobile ad-hoc networks
Like other network simulators,
ns-3
has a relatively steep learning curve, especially compared to 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 download
2
the latest version, build a copy of
ns-3
(it
uses the Python-based build-system waf) and take a look at the examples, that are shipped within most
of the
ns-3
source code repositories and packages. You might also examine the simulation output and try
to adjust it.
Typically, a
ns-3
user will work under a Linux environment. For those running under Windows, there
do exist environments which simulate the Linux environment to various degrees. The
ns-3
project has
in the past (but not presently) supported the
Cygwin
environment for these users (see
http://www.
cygwin.com
for details on downloading).
MiniGW
is presently not officially supported. According to
the
ns-3
installation guide, the officially supported platforms include (please note, that plenty of other
distributions are likely to work with ns-3 regardless):
• Fedora
• Ubuntu
• OS X Mountain Lion, Snow Leopard, ...
• FreeBSD
• Cygwin
Important:
As stated above,
ns-3
is primarily developed on and for GNU/Linux 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 VMware
3
or VirtualBox
4
.
2
Please note, that downloading
ns-3
via tarball is simpler than the Mercurial process since all of the pieces are pre-packaged for
you.
3http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_(Windows)
4http://www.nsnam.org/wiki/index.php/HOWTO_use_VirtualBox_to_run_simulations_on_Windows_machines
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 16
3 Simulators 3.3 ns-3
Software information
Developer(s)
Tom Henderson, Mathieu Lacage, George Riley, Mitch Watrous,
Gustavo Carneiro, Tommaso Pecorella and others
Written in C++ (core) and Python (bindings)
Operating system GNU/Linux FreeBSD Mac OS X
License free software: GNU GPLv2
Website http://www.nsnam.org/
Supported version(s) 3.25
Dependencies libprotobuf 3.3.0
libxml2
libsqlite3
Deployed in VSimRTI all-in-one no (and need a patch to link)
Table 3.2: Software information: ns-3
3.3.1 ns3-ambassador folder structure
<scenarioName>
ns3
ns3_config.json .................................. Ambassador configuration file
configTechnologies.xml .......................... ns-3 federate configuration file
confWifi.xml ..................................... ns-3 federate configuration file
Figure 3.4: ns3-ambassador folder structure
3.3.2 Installation
VSimRTI offers support for the current stable release of
ns-3
(3.25), that was released in March 2016. Older
versions of
ns-3
(prior to 3.25) are not supported. However, also for newer versions we cannot guarantee
the correct operation. The coupling to
VSimRTI
is designed in a manner of minimal code changes on the
ns-3 simulator itself to keep the update capabilities for future versions.
Prerequisites
For GNU/Linux platforms, the minimal requirements to run basic simulations are a
gcc
or
clang
compiler
and a Python interpreter. At least you need the following packages to be installed:
Listing 3.1: ns-3: Minimum requirements
gcc
g ++
python
py thon - de v
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 17
3 Simulators 3.3 ns-3
For a complete list of required packages for different distributions, please refer to the
ns-3
installation
guide:
http://www.nsnam.org/wiki/index.php/Installation
For the connection to VSimRTI, the ns-3 federate furthermore depends upon
• libxml2
• libsqlite3
• libprotobuf 3.3.0
Please make sure these libraries are installed before running the installation script.
Run the installation script
Important: ns-3
requires several packages to be installed on your computer. You will
need to ensure, that all required libraries are present on your system before proceeding. You
may need superuser permissions to install packages.
To ease the installation of
ns-3
for VSimRTI, the installation process has been delegated to an installation
script, that can be found in the associated ns-3 federate folder.
vsimrti
bin
fed
ns3
Dockerfile.sh ................................. Dockerfile for ns-3 federate
ns3_installer.sh ............................... Installation script for ns-3
Figure 3.5: ns3-ambassador federate folder structure
The ns-3 installation script accomplishes the following tasks:
1. Download ns-3 tarball from the offical sources
2. Download the ns-3 federate for VSimRTI.
3. Apply a patch to ns-3 in order to make it work with VSimRTI.
4. Add the ns-3 federate to the waf build system.
5. Configure and build the patched ns-3 with the ns-3 federate.
In order to start the simulation, the following steps need to be performed:
1.
Set up the
confWifi.xml
-file in the scenario folder (see section 3.3.4). An example
confWifi.xml
-
file is shipped with the Tiergarten scenario.
2.
For reasonable result logging, the logger-configuration in
vsimrti/etc/logback.xml
has to be
adapted to support the ns-3 ambassador and federate.
3. At last ns-3 has to be activated in the vsimrti_config.xml and the simulation can be started.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 18
3 Simulators 3.3 ns-3
3.3.3 Installation in Docker environment
Notice:
This is an experimental feature. Please refer to our mailing list if you experience
any problems.
This guide gives instructions to execute the
ns-3
federate inside a docker container. If you already installed
ns-3 on your machine following the steps before, you can skip this section.
Docker
5
is a new approach to execute software. More precisely, it "wraps software in a complete filesystem
that contains everything it needs to run: code, runtime, system tools, and system libraries". As a result, the
software is executed within a container and its execution does not rely on the environment the container
is running in.
In context of
VSimRTI
, this approach allows to execute
ns-3
within a docker container. The user does not
need to manually install ns-3 and can even run ns-3 on Windows hosts.
1. Install Docker ≥1.13 on your machine.
2.
To get everything work, please make sure to execute the following steps depending on your
operating system:
•
Windows - In the settings, share the drive where
VSimRTI
is installed on. You may need to
restart docker in the reset tab.
•
Linux - Make sure your user account belongs to the unix-group "docker". You may need to
restart your machine.
3. Switch to the location of the Dockerfile in vsimrti/bin/fed/ns3
4. Execute the following command on command line:
docker build -t ns3-federate:18.0 .
This could take a while to finish.
5.
Enter the name of the docker image
etc/defaults.xml
in the
ns3
-section into the tag
dockerImage:
< federate cl as s = " .. . " >
<id >ns3</ id >
...
< do ck er Image >ns3-federate:18.0</ dockerImage >
...
</ fede ra te >
You can test the installation of your docker image with the Tiergarten scenario, by activating
ns3
in the
vsimrti_config.xml.
5https://www.docker.com/
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 19
3 Simulators 3.3 ns-3
3.3.4 Configuration
The whole
ns-3
specific configuration is done via the
confWifi.xml
and
configTechnologies.xml
files.
Listing 3.2: confWifi.xml
<? xm l v er si on = " 1.0 " e ncoding =" UT F - 8 " standalone=" n o "? >
< w if i >
<! -- IPv4 address generator -->
<ipConfiguration>
<ip address=" 192.168. 0.0 " mask=" 255.255.0. 0 "/ >
</ ipConfigu ra ti on >
<! -- C a l c u l a t e a pro p a g a t i o n de lay -->
<propagationDelayModel>
< d el ay m od el = "ns3::NonePropagationDelayModel"/ >
</ propag at io nD el ay Mo de l >
<! -- M o d e l ize the p r o p a g a ti o n l oss through a t r a n s m is sion medium -- >
<propagationLossModel>
< l os s m od e l = "ns3::FriisPropagationLossModel"/ >
</propagationLossModel>
<wifiConfiguration>
<! -- Cre a te non QoS - enabled MAC layers -- >
< w if iM ac prope r ty = " type " val ue = "ns3::AdhocWifiMac"/ >
<! -- Wifi PHY mode -->
< wi fi Ma nager p ro pert y = "phyMode" val ue = "OfdmRate54Mbps"/ >
<! -- Wifi mana g e r -- >
< wi fi Ma nager p ro pert y = " ty pe " v alue ="ns3::ConstantRateWifiManager"/ >
<! -- The energy of a receive d sig n al s hould be h igher than this threshold ( dbm ) to allow ⤦
Çthe PHY l ayer to d etect the s i g nal -- >
< w if iP hy prope r ty = "EnergyDetectionThreshold" v alue =" -81.0"/ >
<! -- The energy of a receive d sig n al s hould be h igher than this threshold ( dbm ) to allow ⤦
Çthe PHY l ayer to d e clare CCA BUSY stat e - - >
< w if iP hy prope r ty = "CcaMode1Threshold" v al ue = " - 99. 0 "/ >
<! -- T ra n sm i ss i on ga in ( d B ) - - >
< w if iP hy prope r ty = " TxGain " valu e =" 0. 0 "/ >
<! -- R ec eption gai n ( dB ) -- >
< w if iP hy prope r ty = " RxGain " valu e =" 0. 0 "/ >
<! -- Numb e r of transmissi o n power le vels available betwee n T xP owerStart and TxPowerEnd ⤦
Çincluded - - >
< w if iP hy prope r ty = "TxPowerLevels" v alue ="1"/ >
<! -- Maxim um a va il able t ransmissi on l ev el ( db m ) -- >
< w if iP hy prope r ty = " TxPowerEnd " v al ue = " 17.0 " / >
<! -- Minim um a va il able t ransmissi on l ev el ( db m ) -- >
< w if iP hy prope r ty = "TxPowerStart" v alue =" 17. 0 "/ >
<! -- Los s ( dB ) in the Signal - to - Noise - Ratio due to non - i d e a l i t i e s in the receiver - - >
< w if iP hy prope r ty = "RxNoiseFigure" v alue =" 0.0 " / >
<! -- Chann e l ce nter f r e q u ency = Channel starting f r e q u e n cy + 5 MHz * ( nch - 1) -->
< w if iP hy prope r ty = "ChannelNumber" v alue ="1"/ >
</ wifiCon f ig ur at io n >
</ wi fi >
The IP configuration information includes the network address and network mask. The
ns-3
propagation
module defines two generic interfaces, namely
PropagationLossModel
and
PropagationDelayModel
,
for the modelling of propagation loss respectively propagation delay.
In the default
confWifi.xml
, the Wi-Fi device uses the
ns-3
standard propagation delay model
ns3::ConstantSpeedPropagationDelayModel
and the
ns-3
standard propagation loss model
ns3::FriisPropagationLossModel
. Radio propagation models in
ns-3
can easily be exchanged with
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 20
3 Simulators 3.3 ns-3
the
ns-3
class registration system (see the
ns-3
documentation for details). The Wi-Fi configuration
includes additional parameters, like sending power and antenna gain.
Listing 3.3: configTechnologies.xml
<? xm l v er si on = " 1.0 " e ncoding =" UT F - 8 " standalone=" n o "? >
<ns3Configuration>
< i ns ta llers >
< i ns ta ller typ e ="ns3::WifiVehicleInstaller" name=" WifiVehicle " file=" c on fW ifi . xm l " ⤦
Çdefault=" t rue " / >
< i ns ta ller typ e =" ns3: : Mo bi li ty Mo delIns t al le r " name=" Mobility " default=" t ru e " / >
</ installers >
</ns3Configuration>
The configuration manager of the
ns-3
federate defines, which installer should be loaded for the Wi-Fi
device (refering to the
confWifi.xml
) and the mobility model. Usually, you don’t need to take any
changes and simply use the default configuration file, that ships with the ns-3 federate.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 21
3 Simulators 3.4 SUMO
3.4 SUMO
SUMO
is an highly portable, microscopic and continuous road traffic simulation package. It is designed
to handle large road networks faster than real-time. Each vehicle has an own route and is simulated
individually.
Software information
Developer(s) German Aerospace Center
Written in C++
Operating system GNU/Linux and Microsoft Windows
License free software: GNU GPLv2
since 0.31.0: EPL-2.0
Website http://sumo.dlr.de/
Supported version(s) 0.30.0 .. . 0.32.0
Deployed in VSimRTI all-in-one no
Table 3.3: Software information: SUMO
Important: Please note that VSimRTI only supports SUMO 0.30.0 or higher.
3.4.1 sumo-ambassador folder structure
This ambassador can be configured with a configuration file. The specific path is
vsimrti/scenarios/<scenarioName>/sumo/sumo_config.json
<scenarioName>
sumo .............................................................................
<scenarioName>.nod.xml ............................................. Node file
<scenarioName>.edg.xml .............................................. Edge file
<scenarioName>.con.xml ........................................ Connection file
<scenarioName>.net.xml ........................................... Network file
<scenarioName>.rou.xml ............................................. Route file
<scenarioName>.sumo.cfg ............................... sumo configuration file
sumo_config.json ................................. ambassador configuration file
Figure 3.6: sumo-ambassadorfolder structure
3.4.2 Installation
For Microsoft Windows operating systems download and extract
sumo_winbin.zip
from the
SUMO
website. For GNU/Linux operating systems download and extract the provided GNU/Linux binaries or
build sumo by yourself. Please refer to the SUMO Wiki for further information.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 22
3 Simulators 3.4 SUMO
In order to run
SUMO
with
VSimRTI
you need to make the
SUMO
binaries available system wide by
adding the SUMO binary folder to your PATH environment variable (see section 13.1).
3.4.3 Configuration
Notice:
The documentation for the VSimRTI specific component is freely available on
the DCAITI website , explaining all available options.
The
SUMO
configuration consists of sumo specific config files and the sumo-ambassador configuration
file.
vsimrti/scenarios/<scenarioName>/sumo
. Your main configuration file name must end with
the suffix
*.cfg
. The
SUMO
Wiki covers more information and also a tutorial about the different
configuration files. Route-, network- and
SUMO
configuration files have been generated (using scenario-
convert or by yourself). The last step is the creation of a sumo-ambassadorconfiguration file.
In contrast to standard traffic simulations using
SUMO
only,
VSimRTI
handles the
SUMO
files in a slight
different way , i.e. the route file for a simulation is created at runtime to enable dynamic routing. To get
correct simulation results, we recommend using the scenario-convert tool to create the SUMO files out
of OpenStreetMap data (see section 11.1).
3.4.4 Using the SUMO GUI with VSimRTI
It is also possible to use the Graphical User Interface (
GUI
) of
SUMO
in order to visualize and interact
with the simulation. To achieve this,
VSimRTI
can be configured that it starts the GUI process of
SUMO
as the federate rather than the command line interface.
In order to use the
SUMO GUI
with
VSimRTI
, please open the file
vsimrti/etc/defaults.xml
and replace the entry
com.dcaiti.vsimrti.fed.sumo.ambassador.SumoAmbassador
with
com.dcaiti.vsimrti.fed.sumo.ambassador.SumoGUIAmbassador .
Afterwards
VSimRTI
can be executed as usual. However, the traffic simulation has to be triggered manually
within the
GUI
window of
SUMO
. Additionally, the field Delay within the
GUI
can be used to slow
down the simulation. For further information about the graphical interface please consider the
SUMO
documentation.
Notice:
Keep in mind to launch
VSimRTI
with the argument
-w 0
in order to disable
the watchdog timer. Otherwise it would shutdown
VSimRTI
if you pause the simulation in
the SUMO GUI.
3.4.5 Routes and Vehicle Types
For the simulation the traffic simulator
SUMO
is started as a background process. In preparation,
VSimRTI
automatically generates all files needed, such as routes and vehicle types definition. In particular, VSimRTI
generates a
*.rou.xml
which contains all vehicle types from the mapping3 configuration and all routes
from the scenario database. This also means, that any route referenced by the mapping3 configuration
must be available in the scenario database. Additionally, the
*.rou.xml
in the scenario configuration of
SUMO will always be overwritten by VSimRTI at the start of the simulation.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 23
3 Simulators 3.4 SUMO
If you want to use
SUMO
specific parameters for the vehicle types (e.g. to define the car following model
or the emission class), you can predefine them in the file <scenarioName>.rou.xml of your scenario.
All parameters you define their will be used when the route file is generated for the simulation (except
all paramaters which are defined in the mapping3 configuration such as
accel
,
decel
,
tau
, etc.). The
Tiergarten scenario provides such example file.
3.4.6 Further information
Notice:
We recommend to use the 64 bit version of
SUMO
if you want to simulate
scenarios with a big traffic network.
3.4.7 VSimRTI specific information
Notice:
The
SumoAmbassador
broadcasts
VehicleMovements
in fixed time steps
and also sends a
TrafficLightUpdate
message, when the tl-state change was initiated
in the previous step. For dynamic change of vehicle behavior during simulation,
SUMO
subscribes to the messages
VehicleTypesInitMessage
,
VehiclePathsInitMessage
,
ChangeSpeed
,
SlowDown
,
PropagateNewRoute
,
ChangeStaticRoute
and
ChangeTraf-
ficLightsState.
Important:
Even though the
SumoAmbassador
is able to receive
ChangeRoute
mes-
sages which will result in using the internal Re-route feature of
SUMO
, it is strongly recom-
mended to use the navigation functionality of the
ApplicationNTAmbassador
by using the
provided API.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 24
3 Simulators 3.5 VSimRTI Application Simulator
3.5 VSimRTI Application Simulator
The application simulator is a sophisticated simulator to provide simulation units (e.g. vehicles, road side
units, traffic lights, charging stations) an interface to run their logic. The latest application simulator has
been developed from scratch and is called ApplicationSimulatorNT.
3.5.1 applicationNT-ambassador folder structure
This ambassador can be configured with a configuration file. The specific path is
vsimrti/scenarios/<scenarioName>/applicationNT/applicationNT_config.json
<scenarioName>
applicationNT ...................................................................
applications .................................................................
applicationNT_config.json ............... Configuration file for the ambassador.
<scenarioName>.db ................................. Database file for navigation.
mapping3 ........................................................................
mapping_config.json ...................... Configuration file for the ambassador.
Figure 3.7: applicationNT-ambassador folder structure
3.5.2 Installation
This simulator does not need to be installed. It is delivered as part of the VSimRTI-installation package.
3.5.3 Libraries
To develop applications you need to reference to jar files you will find in the following directories:
• vsimrti/bin/ambassadors/applicationNT-ambassador-18.0.jar
• vsimrti/bin/ambassadors/lib/*.jar
• vsimrti/bin/lib/*.jar
• vsimrti/bin/core/vsimrti-18.0.jar
3.5.4 Basic functionality
Each logical unit is recognized as a separate simulation unit. The application simulator can load different
applications for each simulation unit. For each application there is a general class and an extension for
the particular type of the simulation unit (e.g. Vehicle extends SimulationUnit).
This application may request information from an object and wants to control this. For each
simulation object, an operating system will be created. For each application, there is an operating
system and an extension of the operating system for the particular type (e.g. VehicleApplication extends
AbstractApplication<VehicleOperatingSystem>).
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 25
3 Simulators 3.5 VSimRTI Application Simulator
3.5.5 Gather information in an application
To gather information in an application from a simulation unit, there exist typically two different ways.
React on changes
Applications will be notified on changes. All applications must implement methods that are called before
and after a change. Typically, these methods are named before* and after*. Please note that not all changes
of information notify applications through this mechanism. Some information must be evaluated by
sampling. As an example, the method
getStateOfEnvironmentSensor
could not notify the application
by changing its state.
Sample information
The sampling of information at specific times can be done by requesting future events.
Self events
An event is a notification with information at a future point in the simulation. With a self-event, applica-
tions can wake up themselves at certain time steps. An event can be requested at any simulation point to
trigger an event execution.
3.5.6 Equipped units
All units are generally classified into two types, units that have application logic or not. Equipped vehicles
can also use a predefined ETSI application.
3.5.7 Technical details
• The simulator does not use concurrent processing.
• The logs are based on the application name.
3.5.8 Configuration
Notice:
The documentation for the VSimRTI specific component is freely available on
the DCAITI website , explaining all available options.
Most of the actual configuration of the applications is done by the mapping-simulator. The 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.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 26
3 Simulators 3.5 VSimRTI Application Simulator
3.5.9 Development of applications
Overview
Developing custom applications in
VSimRTI
is rather easy. The best way to learn is by looking at the
source code of actual applications. For this purpose, we provide the source code of all tutorial applications
and further examples. You can find the source code on the DCAITI website .
For an easy understanding of the application API, the following questions and their answers should
help:
•What is required to get my own application run in VSimRTI?
In
VSimRTI
it is very easy to build your own application. First, it needs to inherit from the
Ab-
stractApplication
class (see following section). Secondly, the application must be mapped to
a vehicle (or RSU, or traffic light, ... ) via the mapping configuration (see section 3.5.15). Finally,
the application must be compiled as a Jar-File and placed into the application directory of your
scenario.
•How can I access vehicle functions from within the application, such as sending V2X messages?
Every applications has access to the
OperatingSystem
of the underlying unit which allows to
change its state or to initiate actions, such as sending messages to other vehicles.
•How can I react on events during the simulation, such as receiving V2X messages?
For each application you decide, which events the application should listening to. For example,
if your application needs to react upon incoming V2X messages, it simply implements the
Com-
municationApplication
interface. In the following section you can find all available interfaces
applications can implement.
Create a ’Hello world’ application using eclipse
Create a new project in eclipse (File
↦
New
↦
Java Project). Name your application
HelloWorldApp
.
Confirm the creation of the project. Right click on the project and choose "Properties" to open the project
specific configuration options. In the dialog window select "Java Build Path" and click on the Libraries
tab. Choose "Add external JARs" and navigate to your vsimrti installation folder. Choose the following
JARs and add them to your project:
• vsimrti/bin/ambassadors/applicationNT-ambassador-18.0.jar
• vsimrti/bin/ambassadors/lib/*.jar
• vsimrti/bin/lib/*.jar
• vsimrti/bin/core/vsimrti-18.0.jar
Right click on the "Hello world" Project and choose (New
↦
Package). Name the pack-
age something like
com.mycompany.vsimrti.applications
. Right click on the pack-
age and chose (New
↦
Class). Name the class
HelloWorldApp
, extend from the Class
[..]applicationNT.ambassador.simulationUnit.applications.AbstractApplication<OS>
and confirm. Afterwards, you need to specify the type of operating system
<OS>
your application is
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 27
3 Simulators 3.5 VSimRTI Application Simulator
running on by parameterizing the extended
AbstractApplication<OS>
by one of the following
classes6:
•VehicleOperatingSystem - for applications mapped to normal vehicles.
•ElectricVehicleOperatingSystem
- for applications for vehicles with electro mobility features.
•RoadSideUnitOperatingSystem - for applications mapped to Road Side Units (RSU)s.
•TrafficLightOperatingSystem - for applications mapped to traffic lights.
•ChargingStationOperatingSystem - for applications mapped to charging stations.
Furthermore, your application can implement the following interfaces
7
in order to get informed on
specific events:
•VehicleApplication - get informed when information about the vehicles state is updated.
•ElectricVehicleApplication - get informed on electric vehicle specific events.
•CommunicationApplication - react on incoming V2X messages.
•VSimRTIApplication - get informed on VSimRTI internal events.
•TrafficLightApplication - get noticed when the traffic light program is changed.
•ChargingStationApplication - react on state changes of the charging station.
You can now continue and make modifications. To deploy the application you have
to export the project (File
↦
Export
↦
Java/Jar File) and put the
JAR
in the folder
vsimrti/scenarios/<scenarioName>/applicationNT/applications .
Notice:
You can download the example Application
HelloWorldApp
, which is part of
the AdditionalExamples package, from the website.
In the following picture you can find the example application HelloWorldApp opened in eclipse.
6See package com.dcaiti.vsimrti.fed.applicationNT.ambassador.simulationUnit.operatingSystem.*
7See package com.dcaiti.vsimrti.fed.applicationNT.ambassador.simulationUnit.applicationInterfaces.*
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 28
3 Simulators 3.5 VSimRTI Application Simulator
Figure 3.8: HelloWorldApp
3.5.10 Debugging of applications
To debug an application, remote debugging needs to be used. The following steps need to be performed
in order to debug the application:
1. Open the application in your IDE
2.
Modify your
vsimrti.sh
or
vsimrti.bat
, depending on if you are on windows or a Unix-like
system. Examples can be found below.
3.
Add a new debug profile for remote debugging, make sure port 4100 (or whichever was provided in
the call to VSimRTI)
4.
Launch
VSimRTI
with the argument
-w 0
to disable the watchdog timer will interfere with debug-
ging
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 29
3 Simulators 3.5 VSimRTI Application Simulator
Listing 3.4: "vsimrti.sh on Unix-like systems"
#! / bin / b as h
set -e
source common.sh
javaMemorySizeXms=" "
javaMemorySizeXmx=" "
javaProxySettings=" - D ja va . n et . u s eS ys t em P ro x ie s = t ru e "
javaDebugSettings=" - a g en t li b :j d wp = t ra ns p or t = d t_ so ck et , s e rv er = y , s us pe n d =y , a dd res s =41 00 "
cm d =" j ava ${ javaP r o x y Settings } ${ j a v a MemorySiz e X m s } ${ javaDebu g S e t tings } ${ javaM e m o r y Si z e X m x } ⤦
Ç- cp . : ${ c or e } : ${ l ib s } : ${ a m ba s sa d or s } : ${ a mb as s ad o r_ l ib s } : ./ e tc - D jav a . l i br ar y . p at h = ./ l ib ⤦
Çco m. dcaiti . v si mr ti . s tart . X ML Co nfigRunn er $* "
$ cm d
Listing 3.5: "vsimrti.bat on windows systems"
@EC HO OFF
SetLocal E nableD e l a y edExpa n s i on
cal l c om mo n . bat
set javaMemorySizeXms=
set javaMemorySizeXmx=
se t j avaProx yS et tings = - Dj ava . net . u se Sy stemPr ox ie s = tr ue
se t j av aDebugSe tt in gs =- Xdebu g - Xr un jd wp:trans po rt = dt_socket \, serv er = y\, suspen d =y\, address = 4100
java % j av aP ro xy Se tt in gs % % j a va De bu gS et ti ng s % % javaMem or yS iz eX ms % % java M em or yS iz eX mx % - cp ! libs⤦
Ç! - Djava . lib ra ry . path =./ l ib c om . dc aiti . vsimrti . s tart . XMLCo nf ig Ru nn er %*
EndLocal
exit / b % errorlevel %
3.5.11 Internal ETSI applications
We provide
ETSI
conform applications which implement specific CAM generation rules. You can find
them in the package
•com.dcaiti.vsimrti.fed.applicationNT.etsiApplications.impl .
ETSI Application (Vehicle)
For example, to provide ETSI functionality for your vehicle, you can load the ETSI application
com.dcaiti.vsimrti.fed.applicationNT.etsiApplications.impl.Vehicle .
This application generates ETSI data for its simulation unit (e.g. heading, position, speed and time for
vehicles). According to its configuration, the application then sends out CAMs to other vehicles in range.
Note that the messages are only send when the time lies between the configured minimum and maximum
interval.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 30
3 Simulators 3.5 VSimRTI Application Simulator
Default configuration
Without explicit configuration for the
ETSI
a default configuration is loaded.
For the ETSI interceptor have a look at the class CEtsi .
Notice:
For more information about this component, please have a look at the javadoc
(doxygen) documentation.
Currently, the default configuration for the ETSI application looks like this:
{
"maxStartOffset": 1000000000,
" minInterval " : 100000 0 00 ,
" maxInterval " : 1000000000,
"positionChange": 4 ,
"headingChange": 4 ,
"velocityChange": 0.5
}
In general, the numeric values should be interpreted as time delta. E.g., if the
ETSI
values change by the
given amount, a new CAM is sent. The only exceptions are the minimum and maximum intervals. If the
time lies over the maximum interval, a CAM is sent even if the difference between the
ETSI
values isn’t
high enough. If the difference is high enough but the minimum interval isn’t surpassed, no message will
be sent.
3.5.12 Sending Cooperative Awareness Messages (CAM)
The following section will show how CAMs are implemented in VSimRTI and how you can alter them.
CAMs consist of four parts:
• Header with generic information
• MessageBody
• ServiceList
• TaggedValue list
First of all generic information like protocol version, creation time stamp are transmitted. Normally
this data set follows a network beacon, already containing data like position and speed. Nevertheless
this functionality must be implemented in the network layer, that means in the network simulator. At
the moment this is not supported and is therefore compensated in the next message part, the message
body.
The body can contain either RSU or Vehicle awareness data. In the first case, only the RSU type is
submitted, but this probably changes with a new CAM specification. In the second case, we provide data
like vehicle width, length, position, speed, type and heading. However, the specification is not completely
implemented, especially acceleration data, as well as light and brake status are missing. The third part of
the CAM specification, the service list, is also not implemented. This will probably change, when a list of
services is defined by the ETSI.
Last but not least a message can contain optional data. This is fully implemented and is used for our
traffic light CAM messages, which provide the traffic light status.
The CAM sending interval can be configured, more information can be found in the configuration section
of the application simulator.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 31
3 Simulators 3.5 VSimRTI Application Simulator
3.5.13 Access SUMO TraCI from applications
If
SUMO
is used as a traffic simulator and a special functionality is required, the
sendSumoTraciByteAr-
rayMessage function in the OperatingSystem can be used.
The function expects a string (a unique identifier which will be assigned to the response) and a byte array
(representing the complete Traffic Control Interface (
TraCI
) request including the header). The message
identifier can be an empty string.
In all cases the command will trigger a response. The application can receive the response from the
method onSumoTraciByteArrayMessageResponse. This method will receive a
SumoTraciByteArrayMes-
sageResponse
object. This response contains the specified identifier. The application must handle the
identification process of the response itself.
Notice:
A response is delivered to every application. To prevent unintentional delivery
each application request should use an immutable universally unique identifier (UUID).
Important:
Be careful when using this interface and the
TraCI
commands. The
commands are delivered to TraCI without any prior checks.
Notice:
You can find the example application
TestSumoTraciByteArrayMessageApp
in the additional examples bundle on the DCAITI website .
3.5.14 Navigation
The navigation of vehicles is handled completely by the application simulator. Each vehicle is equipped
with a navigation system which provides all required information and functions for navigational pur-
poses:
• Retrieve the current position and heading of the vehicle.
• Get the target of the vehicle.
• Calculate various routes from the current position to an arbitrary target.
• Choose a suitable route out of existing ones from the current position to an arbitrary target.
• Switch onto a specific route.
In order to provide routing functionality, a map model based on Open Street Map data is used, which
needs to be transformed before the simulation using scenario-convert. The map data including initial
routes for vehicles is provided with the database file which needs to be located in
vsimrti/scenarios/<scenarioName>/applicationNT/<scenarioName>.db
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 32
3 Simulators 3.5 VSimRTI Application Simulator
Configuration
If the database needs to be located somewhere else, the path can be specified in
vsimrti/scenarios/<scenarioName>/applicationNT/applicationNT_config.json:
{
...
"navigationConfiguration": {
"databaseFile":" p at h / to / s c en ari o . d b "
}
}
Usage
The following snippet show, how the navigation system can be used within an application:
// get navigation module
INavi g a t i o nModule navigation M o d u l e = getO p e r a tingSyst e m () . get N a v i gationM o d u l e () ;
// choose target posi tion to c u rrent target
RoutingPosition targetPosition = new RoutingPosition(navigationModule.getTargetPosition());
// set rout in g p ar am et ers to f astest route se arch
Rout in gP ar ameters p ar ams = new R ou ti ngParam et er s () . co st Fu nc ti on ( IRo ut in gCostFu nc ti on . Faste st ) ;
// c a l c u l ate r o u tes
Routin g Re s po ns e resp on se = n av ig at io nM od ul e . c al cu la te R ou te s (targetPos ition , p arams );
// switch to be st route
if ( response . getBestRoute () != n ull ){
boole an routeSwitched = n av ig at io nModule . switchRoute ( response . getBestRoute () );
...
}
3.5.15 Mapping 3
The mapping configuration is used to define how many vehicles of a specific type should drive in a
simulation. You can choose between a deterministic mapping (producing the exact same sequence
of mapped vehicles in every simulation run with regard to the given ratios at each point in time the
simulation) and a stochastic mapping (resulting in a random order of mapped vehicles).
The new mapping ambassador was built to simplify the configuration of complex scenarios. It is not
as tightly linked to the database as its predecessor and relies on
JSON
rather than Extensible Markup
Language (XML) for configuration.
The configuration for the Mapping3-Federate is located in
vsimrti/scenarios/<scenarioName>/mapping3/mapping_config.json .
In this file an object is described in JavaScript Object Notation (
JSON
), which will at runtime be parsed
using the MappingFramework-Class.
Notice:
The documentation for the VSimRTI specific component is freely available on
the DCAITI website , explaining all available options.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 33
3 Simulators 3.5 VSimRTI Application Simulator
The Mapping-Framework-Class
The main class for the Mapping3-Configuration is the MappingFramework-Class. It is divided into six
parts: prototypes,rsus,tls,vehicles,matrixMappers and config.
In
prototypes
you can define models for other objects, which can later be reused in the other
sections. This makes it possible to reuse the definition of certain vehicles or the combination of multiple
applications, reducing redundancies.
The
rsus
-section offers the possibility to define instances of
RSU
’s. To reuse a prototype simply
specify its name in the name-property. All relevant properties will then be automatically filled in. At least,
you must define a position for every RSU.
In the
tls
-section traffic lights can be defined. The traffic lights themselves are already speci-
fied in the database of the scenario. Here applications can be mapped to them. Two different modes are
offered for that: You can map the entities to individual traffic lights by specifying the name of the traffic
light in the
tlName
-property. Alternatively you can define weights for the specified traffic lights, which
will then be the base for a random distribution through all traffic lights. The weights do not have to add
up to 100 or 1. Consequently all traffic lights will be mapped using the specified prototypes as soon as
one weight differs from zero. So in case you don’t want all traffic lights to have applications running on
them you have to define one traffic light without any applications and add a weight to it.
The
vehicles
-section is the centerpiece of the configuration. Here the departures, routes and
types of the vehicles are defined. It is divided into VehicleSpawner. These spawners are designed to
produce a traffic stream with the given traffic density (in vehicles/hour). By specifying a maximum
number of vehicles to be created you can also spawn individual vehicles. A VehicleSpawner offers the
possibility to combine multiple vehicle types. By specifying weights for the different vehicle types the
ratios between them can be defined. If no weights are defined they are assumed to be equal. Note: If at
least one vehicle type has a weight defined this does not apply! In that case all types without a defined
weight are ignored. Instead of specifying a route you can also choose two points (given in long/lat). If no
radius for the point is specified the closest point to the given position will be chosen. Otherwise a point
inside the radius will be select randomly.
It is also possible to define and use OD-Matrices. To do so add a ODMatrixMapper to the matrixMappers-
list. Each MatrixMapper consists of a list of points, the vehicle-types to be used and the actual flow-values
between each of the points. It is possible to define multiple matrices. This way distinctively different
compositions of the vehicle flows can be achieved. The MatrixMapper will be called before the actual
execution of the simulation and will generate vehicle-spawners for the flow between each of the points.
Thus the MatrixMapper is just a way to save work. If you want to use the extra-option that multiple
vehicleSpawners offer you should use them.
In the config extra options are defined.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 34
3 Simulators 3.5 VSimRTI Application Simulator
Mapping and Identifier
Every traffic object in
VSimRTI
has a globally unique string identifier. These identifiers are used to identify
a traffic object in
VSimRTI
as well as in different ambassadors. From user’s aspect, these identifiers will
be seen in the log files which are generated after a simulation. Therefore, it should be explained, which
identifier belongs to which traffic object.
Traffic Object VSimRTI Internal ID
Vehicle veh_[seqNr]
RSU rsu_[rsuName]
Traffic Light tl_[groupId]
Table 3.4: Mapping aspects
•seqNr is the sequence number of simulated vehicles, which starts from zero.
•rsuName is the element name defined by the user for the attribute RsuPosition.
•groupId is the group id of the traffic light.
Notice:
For more information about this component, please have a look at the javadoc
(doxygen) documentation.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 35
3 Simulators 3.6 VSimRTI Cellular Simulator
3.6 VSimRTI Cellular Simulator
The
VSimRTI
built-in Cellular Simulator enables the applications to use cellular network communication.
The simulation of cellular communication in VSimRTI consists of two parts:
1. The Cellular Simulator itself and
2. The applications that can communicate over cellular networks in the Application Simulator
These changes are done in a generic way, making the cellular simulator exchangeable. Users interested
in a different kind of simulation of cellular communication may use other simulators and develop
ambassadors connecting them to VSimRTI.
The Cellular Simulator in the current state consists of three main modules:
1. Uplink Module
2. Geocaster Module
3. Downlink Module
The Geocaster module simulates a mandatory component for ITS communication. It is inspired by
the several architectures from research projects as simTD or CONVERGE to enable ITS use cases over
cellular networks. It mainly takes over the task of an addressing and routing component with geographic
knowledge to support geo-addressing. However, it also supports regular topological addressing.
The Uplink and Downlink Module are responsible for the transmission simulation. They account for the
aspects of transmission delays, packet losses and available data rates. In this context, Uplink and Downlink
always refer to the direction towards respectively from the Geocaster. For instance, a transmission
from an Internet-based server towards a vehicle would include an Uplink between the server and the
Geocaster and a Downlink between the Geocaster and the vehicle. While the Uplink direction only allows
point-to-point communication (Unicast), the Downlink supports point-to-point (Unicast) as well as
point-to-multipoint (Multicast).
3.6.1 cell2-ambassador folder structure
The
VSimRTI
cellular simulator can be configured via three distinct configuration files, which can be
found within the scenarios folder structure:
<scenarioName>
cell2
cell2_config.json ......................... Cellular ambassador configuration file
network.json ......................................... Network configuration file
regions.json .......................................... Regions configuration file
Figure 3.9: cell2-ambassador folder structure
The network and regions configuration files are referenced in the cellular ambassador configuration
file.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 36
3 Simulators 3.6 VSimRTI Cellular Simulator
3.6.2 Installation
This simulator does not need to be installed. It is delivered as part of the VSimRTI-installation package.
3.6.3 Configuration
We provide a cellular configuration file in the example scenarios of Tiergarten and Barnim. Please note
that in the default configuration of this scenario the Cellular Simulator is deactivated. To activate the
cellular simulator just add
<! -- Cell feder a t e -- >
< f ed e ra te i d =" c el l2 " active=" tru e " / >
to the
vsimrti_config.xml
(or, if this line already exist, make sure ’active’ is set to ’true’). With
this done you now can deactivate all network simulators if only cellular simulation is intended in the
investigated scenario. However, it is also possible to use multiple communication technologies (of ad hoc
and cellular) in a hybrid scenario.
The central configuration for the cellular simulator in the file
vsimrti/scenarios/<scenarioName>/cell2/cell2_config.json could look like this:
{
" debugGe oc a st in g ": false ,
"visualizeRegions": true ,
"networkConfigurationFile":" n et wo rk . j so n ",
"regionConfigurationFile":" r eg io ns . j son "
}
The visualizeRegions-option from the
cell2_config.json
is used to write a KML-file that visualizes the
used cell regions. Google Earth can be used to display it.
The configuration for the global network in the cellular simulator in the file
vsimrti/scenarios/<scenarioName>/cell2/network.json could look like this:
{
# glo b al r e gion has no area definition (is the d e fault region )
"globalRegion": {
" upli nk " : {
" del ay " : {
" typ e ":"ConstantDelay",
" del ay " : 100 ,
" prp l ": 0 ,
"retries": 2
}
" capacity ": 2800000 0
},
" downlink ": {
"unicast": {
" del ay " : {
" typ e ":"ConstantDelay",
" del ay " : 50 ,
" prp l ": 0 ,
"retries": 2
}
},
" multicast ": {
" del ay " : {
" typ e ":"ConstantDelay",
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 37
3 Simulators 3.6 VSimRTI Cellular Simulator
" del ay " : 100 ,
" prp l ": 0
},
"usableCapacity": 0.6
},
" capacity ": 4220000 0
}
}
Note that all bandwidths are given in bit per second and all delays in milliseconds. Also, every json
configuration goes through a minifier, so comments are allowed in the configuration files. An example
would be the comment before the globalRegion option.
Delay regions
Additionally the user has the option to define regions with individual delays. This can be used to simulate
areas with bad reception, crowded areas etc.
The regions should be stored in
vsimrti/scenarios/<scenarioName>/cell2/regions.json
. An
example definition for a single region called Ernst-Reuter-Platz could look like this:
{
"regions": [
{
" id " :" Ern st - R eu ter - P la tz " ,
" are a ": {
" nw " : { "lon":13 .3249 , "lat":52 .5131 },
" se " : { "lon":13 .3273 , "lat":52 .5125 }
},
" upli nk " : {
" del ay " : {
" typ e ":"SimpleRandomDelay",
" ste ps " : 4,
" minDelay ": 50 ,
" maxDelay ": 200 ,
" prp l ": 0.8 ,
"retries": 2
},
" capacity ": 2800000 0
},
" downlink ": {
"unicast": {
" del ay " : {
" typ e ":"SimpleRandomDelay",
" ste ps " : 3,
" minDelay ": 100 ,
" maxDelay ": 200 ,
"retries": 2
}
},
" multicast ": {
" del ay " : {
" typ e ":"SimpleRandomDelay",
" ste ps " : 3,
" minDelay ": 120 ,
" maxDelay ": 220 ,
" prp l ": 0.8
},
"usableCapacity": 0.6
},
" capacity ": 4220000 0
}
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 38
3 Simulators 3.6 VSimRTI Cellular Simulator
}
]
}
Note that
nw
represents the upper-left (north-west) point of the rectangle and
se
the lower-right (south-
east). For further information about the possible options, please refer to the
VSimRTI
API documenta-
tion.
The actual configuration of the uplink and the downlink modules for each region exhibits the identical
format as configuration of the globalRegion in the network.json.
When no regions are found, or if a node (a vehicle) is not within a specified region, the globalRegion
defined in the network.json-File will be used as the delay model.
Transmission simulation
One of the most important feature of the cellular simulator is an estimation of the delay experienced
through the transport over the cellular network.
The cellular simulator offers various modes to estimate the delay of the transmissions. The type of
estimation is specified with by delayType for the uplink and downlink for each region.
•delay.type = ’ConstantDelay’
: The message is transmitted with the latency being exactly
equal to delay.
•delay.type = ’SimpleRandomDelay’
: The latency can assume different (randomly generated
and uniformly distributed) values between
minDelay
and
maxDelay
. The number of different
values is determined by steps.
•delay.type = ’GammaRandomDelay’
: A gamma distribution is used to estimate the latency, with
α=
2 and
β=
2. The minimum delay
minDelay
is added to the result. The curve is fitted so that the
maximum likelihood for the delay is exactly equal to expDelay.
•delay.type = ’GammaSpeedDelay’
: This mode closely resembles the GammaRandomDelay.
Additionally, a penalty for the velocity with which the node is moving is calculated. This penalty
is then added to the original delay. The GammaRandomDelay and the GammaSpeedDelay are
derived from a measurement campaign during a research project at the DCAITI.
The two different modes for the downlink are unicast and multicast which are configured separately.
Multicast aims to simulate the features of Multimedia Broadcast Multicast Service (
MBMS
). The main
difference in terms of the transmission for unicast and multicast is the handling of undeliverable messages.
For unicast, the options prpl and retries are used. Pr is short for packet retransmit and denotes the
probability for a failed delivery and a subsequent retransmit. The maximum number of retries for
the retransmit is configured through the retries-option. The probability of a successful retransmit is
recalculated on every try.
In case of multicast the prpl is used as packet loss rate. The value is factored into the delay calculation. In
contrast to the unicast, just one transmission attempt is made for multicast.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 39
3 Simulators 3.6 VSimRTI Cellular Simulator
3.6.4 Operation
Beside the transmission simulation, the Addressing and Routing is the other important aspect of the
Cellular Simulator. This task is enabled by the Geocaster.
The Geocaster evaluates the message headers for cellular messages, which are created by the communi-
cating applications in the Application Simulator.
It supports the following addressing and casting schemes.
CellTopocast
is the normal unicast, where the Geocaster simply resolves the single receiver via the
IPResolver. Hence, the CellTopocast directly routes the message further. Currently, Topocast doesn’t
allow broadcast or anycast addresses, but any transmission protocols (tcp, udp).
CellGeoUnicast
addresses every node in the destination area is individually. In this way it takes a
geographic address and results in a loop to generate multiple unicasts.
CellGeoBroadcast,
which is basically MBMS, uses one broadcast to all nodes in the destined regions.
The MBMS uses the different transmission mode of multicast in the downlink. CellGeoUnicast as
well as CellGeoBroadcast require broadcast, but don’t allow tcp (as ack for broadcasts is denied).
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 40
3 Simulators 3.7 VSimRTI Simple Network Simulator
3.7 VSimRTI Simple Network Simulator
As well as the network simulators
OMNeT++
and
ns-3
, the
VSimRTI
built-in Simple Network Simulator
(
SNS
) aims at simulating ad hoc communication for V2X scenarios. In contrast to the other simulators,
SNS
is already bundled with
VSimRTI
and can be used directly out off the box, and due to Java language,
in an operating system independent way.
SNS
implements abstract communication models to support the following important communication
principles for V2X applications:
TopoCast
currently implemented as Singlehop Topocast, to communicate either to all or an individual
destination node in the direct communication range of the sender.
GeoCast
to communicate, similar to Georouting, to nodes in a certain geographic destination area,
with the options of unicast (to address one node), broadcast (to address all nodes) and anycast (to
address the first one of all reachable nodes).
SNS
does not implement a full featured IEEE 802.11p communication stack, as the other simulators could
do. It does not consider particular detailed properties of the communication, e.g. signal fading models,
PHY Layer reception, MAC Layer scheduling, detailed Geo Routing protocols etc. Due to this,
SNS
is an
interesting alternative several reasons and suited for users aiming for quick and easy use without the
need of detailed models.
However, when detailed communication charactersitcs need to be considered, the other simulators are
the better choice.
3.7.1 sns-ambassador folder structure
The
SNS
can be configured via the sns_config.json which can be found within the scenarios folder
structure:
<scenarioName>
sns
sns_config.json .......................................... SNS configuration file
Figure 3.10: sns-ambassador folder structure
3.7.2 Installation
This simulator does not need to be installed. It is delivered as part of the VSimRTI-installation package.
3.7.3 Configuration
The
SNS
configuration basically consists of the two components for
singlehop
(direct Topocast) and
multihop
(Georouting) transmission. Each of these transmission modes base on the delay configuration,
which is already known from the Cell2 Simulator (3.6).
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 41
3 Simulators 3.7 VSimRTI Simple Network Simulator
The singlehop component additionally includes the singlehop
radius
, which actually is the direct com-
munication range of the sender - meaning that all nodes within this distance can successfully receive the
according message. In the context of the fundamental Freespace Model, which is implemented by the
classic network simulators
OMNeT++
and
ns-3
this value results from the carrier frequency, transmission
power, receiver sensitivity and antenna properties (gains) etc. Additionally, the delay supports the value
for packet retransmission and packet loss (
prpl
), which allows the simulation of packet errors within
the communication range. However, in contrast to fading models as the Rayleigh or Rice Fading, the
simulated packet errors in
SNS
are distributed uniformly over the whole communication range and do
not, for instance, increase with higher distances (which would be more realistic.
The multihop component only consists of the delay configuration including the value for prpl and
according transmission retries. In this case, the destined communication area is determined by the
dissemination area in the GeocastDestinationAddress.
An example definition for
SNS
, with relatively short delays in the order of microseconds or low millisec-
onds for direct singlehop and slightly higher delays for multihop could look like this:
{
"version":"0.16.0",
" singlehop ": {
" _singlehop radius in m" : 0,
" radi us " : 509.4 ,
" _d elay config according to vsi mrt i - c om mu ni ca ti on " : 0,
" del ay " : {
" typ e ":"SimpleRandomDelay",
" ste ps " : 5,
" minDelay ": 0.4 ,
" maxDelay ": 2.4 ,
" prp l ": 0 ,
"retries": 0
}
},
" multihop ": {
" _d elay config according to vsi mrt i - c om mu ni ca ti on " : 0,
" del ay " : {
" typ e ":"GammaRandomDelay",
" minDelay ": 10 ,
" expDelay ": 30 ,
" prp l ": 0 ,
"retries": 2
}
}
}
3.7.4 Operation
The individual steps of operation for the two modes of Topocast (direct singlehop) and Geocast (georout-
ing with multihop) transmission are as following.
Simulation of direct singlehop transmission
1.
get transmission radius from configuration (to simulate tx power, carrier frequency and antenna
properties etc.)
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 42
3 Simulators 3.7 VSimRTI Simple Network Simulator
2. determine potential receiver nodes in the sending radius (without original sender)
3. calculate equal delay for all nodes
4. simulate successful message transmission (via prpl) for each node
Simulation of geocast routing transmission
1. get destination area from geocast header in message (to simulate georouting)
2.
determine potential receiver nodes in the destination area (including original sender due to re-
broadcasting in geocast)
3. calculate specific delay for each node
4.
simulate successful message transmission (with packet loss and possible retransmissions via prpl)
for each node
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 43
3 Simulators 3.8 VSimRTI Eventserver
3.8 VSimRTI Eventserver
3.8.1 eventserver-ambassador folder structure
This ambassador can be configured with a configuration file. The specific path is
vsimrti/scenarios/<scenarioName>/eventserver/eventserver_config.json
<scenarioName>
eventserver .....................................................................
eventserver_config.json .......................... Eventserver configuration file
Figure 3.11: eventserver-ambassador folder structure
3.8.2 Installation
This simulator does not need to be installed. It is delivered as part of the VSimRTI-installation package.
3.8.3 Configuration
Notice:
The documentation for the VSimRTI specific component is freely available on
the DCAITI website , explaining all available options.
The root node of the configuration is a list of environment events. Each event require the type of the
event, a rectangle area, a strength and the time window.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 44
3 Simulators 3.9 VSimRTI Battery Simulator
3.9 VSimRTI Battery Simulator
3.9.1 battery-ambassador folder structure
This ambassador can be configured with a configuration file. The specific path is
vsimrti/scenarios/<scenarioName>/battery/battery_config.json
<scenarioName>
battery ..........................................................................
battery_config.json .............................. ambassador configuration file
Figure 3.12: battery-ambassador folder structure
3.9.2 Installation
This simulator does not need to be installed. It is delivered as part of the VSimRTI-installation package.
3.9.3 Introduction
The
VSimRTI
Battery Simulator is used to simulate electric vehicles. It takes environment, vehicle
characteristics and the battery itself into account. The main feature of the battery ambassador is that it
can utilize dynamic class loading to use a battery model provided by the user, depending on the given
needs. This also holds true for the environment model and the vehicle model. However, simple models
for vehicle, environment and the battery are provided and will be briefly explained in the following
sections.
3.9.4 Vehicle model
The vehicle model holds the general properties of a vehicle. Examples would be the weight of the vehicle
and the voltage at which the electric engine operates. However, as with the other models, the provided
class for the vehicle model direct affects what can be configured here. If other properties are needed for
the vehicle, this is the right place to put them. To implement an own vehicle, the class
AVehicleModel
has to be extended.
3.9.5 Battery model
The battery model defines the battery used by the vehicle itself. Useful properties could be the number
of cells and their capacity. As with the vehicle, this class can be freely defined and use configuration
values placed in the
batteryModelConfig
-area. To implement an own battery model, the class
ABat-
teryModel needs to be extended.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 45
3 Simulators 3.9 VSimRTI Battery Simulator
3.9.6 Environment model
Normally environmental factors like rolling resistance of the given underground or air drag go into this
section. At the current state, just a minimal environment model is bundled with the battery ambassador,
mainly to show what is possible. To implement a custom environment model,
AEnvironmentModel
has
to be extended.
3.9.7 Sample configuration
{
"vehicleModelClass":" com . dcaiti . v si mr ti . fed . batte ry . sim . models . ve hi cl e . El ec tr ic Smart " ,
"vehicleModelConfig": {
" Mas s ": 1060 ,
"ReferenceArea": 1.95 ,
" DragCoe ff i ci en t ": 0.375 ,
"TankToWheelEfficiency": 0.7 ,
"EletricMotorOperatingVoltage": 350 ,
"ConsumerOperatingVoltage": 12
},
"batteryModelClass":" com . dcaiti . v si mr ti . fed . batte ry . sim . models . ba tt er y .⤦
ÇVerySimpleBatteryModel",
"batteryModelConfig": {
"NumberOfCells": 93 ,
" CellVoltage " : 4.3 ,
"CellCapacityInAh": 50 ,
" eff_Summer ": 0.8448 ,
"RechargingType": 2 ,
" MinS OC " : 0.30 ,
" MaxS OC " : 0.70
},
"environmentModelClass":" c om . d ca it i . vsimrt i . fed . b atte ry . sim . m od el s . e nv i ro nm ent .⤦
ÇDefaultEnvironment",
"environmentModelConfig": {
"Gravity": 9.81 ,
"FluidDensity": 1.293 ,
"RollingResistanceCoefficient": 0.01
},
" consumers ":[{" Rad io " : 10 } , { " HeadLigh t ": 100 } ]
}
This listing shows how the vehicle, environment and battery model classes for the bundled models are
configured. Additionally, an arbitrary number of consumers can be configured that draw additional
power from the battery. In this case, headlights and a radio are pre-defined.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 46
4 Tutorial Tiergarten
This tutorial aims to provide a general overview of the VSimRTI application concept and shows two
examples that involve ad hoc communication via
IEEE
802.11p between different participants and
message passing from one application to another that run on the same vehicle. Additionally, a short
introduction will be given on Traffic Lights, with a more in-depth description following in Chapter 6. The
tutorial is split up into five main parts:
1. How to equip a vehicle with one or more applications. This process is called mapping.
2.
An example application that shows how to implement communication between different vehicles
via a wireless ad hoc network.
3.
The next part of the tutorial shows how to accomplish message passing between two applications
that run on the same vehicle.
4.
An overview of the traffic light application and a summary about what can be done with the traffic
light from within the application.
5. The last part of the tutorial shows how to retrieve the results of a simulation run.
The scenario itself consists of three vehicles that drive down a road in consecutive order and pass a Road
Side Unit (RSU) that emits messages in a fixed interval. The vehicles will receive the messages from the
RSU as soon as they are in communication range. After completing this tutorial the reader should be
Figure 4.1: Overview of Tiergarten tutorial scenario
able to deploy own applications according to his needs and make use of ad hoc communication among
vehicles and intra-vehicle communication among applications on the same vehicle. The VSimRTI cell
simulator that is used to simulate cellular network communication will be covered in tutorial 2.
4 Tutorial Tiergarten 4.1 Mapping Configuration
4.1 Mapping Configuration
In order to use applications they have to be assigned (mapped in VSimRTI terminology) to a simulation
entity. In this tutorial, we will assign applications to a RSU that is placed along the road (the red symbol
in picture 4.1) and to the vehicles. In order to do this the following steps are necessary:
1. Navigate to the mapping3 folder of the tiergarten tutorial scenario.
2.
Edit the
mapping_config.json
to let it point to the correct classes for your application, define
prototypes and to add entities to the simulation.
The mapping is already configured correctly, so we will continue with a description of the important parts
of the mapping configuration.
Prototype Section
This section contains the properties of the simulated entities, including their applications. You can, for
example, configure the maximum speed and the length of a vehicle. Normally, the default values are fine
here. In order to map one or more applications you have to fill in the complete class identifier including
the package in the
applications
array. In this tutorial, we have mapped two applications to the vehicles
and one application to the RSU.
Mapping for the vehicles:
"applications":["com.dcaiti.vsimrti.app.tutorials.tiergarten.TiergartenVehicle",
"com.dcaiti.vsimrti.app.tutorials.tiergarten.TiergartenVehicleSlave"]
Mapping for the RSU:
"applications":["com.dcaiti.vsimrti.app.tutorials.tiergarten.TiergartenRSU"]
In order for VSimRTI to be able to locate these classes, the resulting .jar archive should be placed in
the
applicationNT
folder of your scenario. For our tutorial we have packaged the needed classes
TiergartenVehicle
,
TiergartenVehicleSlave
and
TiergartenRSU
into one .jar file. However, this
isn’t a strict requirement. What these classes actually do and how they are implemented will be covered
in the next two parts of this tutorial.
Vehicle and RSU sections
This part of the mapping is used to actually bring entities like vehicles and RSUs into the simulation. For
example, we placed the RSU that is equipped with the
TiergartenRSU
application at the specific geo
coordinate with latitude = 52.5130607 and longitude = 13.328910. Usually, this and the mapping of its
application is all that is necessary to make use of an RSU. For this tutorial we go with just one RSU but
analogous to adding multiple vehicles we could also add more of them if the need arises.
Spawning vehicles is a little bit more complex than adding a RSU. Vehicles are configured as groups from
which we have three in this tutorial scenario. Exemplary, we will describe one of these groups in more
detail:
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 48
4 Tutorial Tiergarten 4.2 Inter-Vehicle Communication
" vehicles ":[
{
"startingTime":1 .0 ,
" rou te " :0 ,
"maxNumberVehicles":1 ,
" typ es " :[{" nam e ":" PK W " }]
},
...
]
Listing 4.1: Example Vehicle Group
•startingTime: Defines at which second the vehicle is spawned, in this case one second after the
beginning of the simulation.
•route
: Describes which route these vehicle group should use. For now it is sufficient to know that
there is one route with the id 0 that leads the vehicles near the RSU that is already defined in this
tutorial scenario.
•maxNumberVehicles
: Used to determine how many vehicles should be in that group. Here, we go
with just one single vehicle.
•types
: This array maps to the defined
PKW
(german for passenger car) prototype from the
proto-
types-section of the mapping.
4.2 Inter-Vehicle Communication
This second part describes the
TiergartenVehicle
and
TiergartenRSU
applications which are used
for inter-vehicle communication in more detail. As a coarse overview, the TiergartenRSU application
sends out a defined message at a fixed interval. These messages are received and written to the log file by
the TiergartenVehicle application. First, we start off with the class definition and will run through the
methods we have to implement in order to get the communication working.
Class definition
publ i c class T i ergartenV e h i c le exte n d s A b s t r a c t A p p l i c a t i o n < V e h i c l e O pe ra t in gS ys te m > i m p l e m e n t s ⤦
ÇVehicleApplication , CommunicationApplication
Listing 4.2: TiergartenVehicle: Class definition for a vehicle application
In general, every vehicle application will extend the
AbstractApplication
abstract class with the Vehi-
cleOperatingSystem type parameter. The VehicleOperatingSystem is the main way to interact with the
underlying vehicle and gives a wide array of functionality to the user. Also, depending on the needs of the
application, several interfaces have to be implemented. For our scenario we implement
VehicleAppli-
cation
to denote that the application is intended to run on a vehicle and
CommunicationApplication
to be able to use the actual communication facilities we need for this tutorial. In general, it makes sense to
let the IDE generate the bodies of the methods that need implementation and fill them with functionality
if needed or letting them empty otherwise.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 49
4 Tutorial Tiergarten 4.2 Inter-Vehicle Communication
Application initialization
During the initialization procedure of communicating applications, the communication modules (WLAN-
Module or CellModule) need to be activated. For example, activating the WLAN module can be achieved
with the following code snipped:
@Override
publ ic void setup () {
g et Lo g ( ) . i nf o Si m Ti m e ( this , " Initialize a pp li ca ti on " );
g et O pe ra t in g Sy st e m ( ) . g et A dH o cM od u le () . e nab l e ( ne w A dH o c Mo d ul eC o nf ig u ra t i on ()
. a dd Ra dio () . chann el ( A dHocChan ne l . CC H ). pow er ( 50) . c re at e ()
);
g et Lo g ( ) . i nf o Si m Ti m e ( this , " Activated AdHoc Mo du le " );
}
Listing 4.3: TiergartenVehicle activate WLAN module
Since we want to communicate over ad hoc Wifi we have to turn on the Wifi-module of the car. Here
you can specify the mode of operation. The first argument says if the vehicle should be able to receive
messages, how strong the Wifi antenna is (50mW in this case) and which ad hoc channel to use.
Note
: The honoring of these arguments depends on the underlying network simulator. Currently,
ns-3
and OMNeT++ make use of these arguments.
Receiving the V2X messages
In order to act upon received messages from other simulation entities, the
receiveV2XMessage
from the
CommunicationApplication
interface is used. In our tutorial scenario we don’t do something special
upon message receiving and just write the name of the sender into the log file.
@Override
publ ic void rece i ve V2 XM es sa ge ( R ec ei ve dV 2X Me ss ag e re ce iv ed V2 XM es sa ge ) {
g et Lo g ( ) . i nf o Si m Ti m e ( this , " R e ce iv e d V 2X M es s ag e fr om {} " ,
r ec e iv ed V 2X M es s ag e . g e tM essage ( ) . g et R ou t in g ( ) . g e tS o ur c e Ad d re s s Co n ta i n er () . g e tS o urc eN a me () ) ;
}
Listing 4.4: TiergartenVehicle: Class definition for a vehicle application
This is basically all it takes to receive messages from another simulation entity. Normally, the application
author uses an own message class that derives from V2XMessage and casts it to his specific class in order
to handle messages easier.
Sending the V2X messages
Since the receiving application is now set up we move on to the sending side of this tutorial. The sending
takes place from the RSU via a broadcast, so every vehicle in transmission range will receive the message
sent by it. Picture 4.2 shows the communication range of the RSU which is dependent from the settings in
the communication simulator. The actual sending takes place in the
TiergartenRSU
application which
is equipped to the RSU via the mapping configuration.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 50
4 Tutorial Tiergarten 4.2 Inter-Vehicle Communication
Figure 4.2: Example of RSU communication range
ApplicationNT event model
In order to send messages at a fixed interval we make use of the event based model of the VSimRTI
application simulator. A high level description in what we need to do in order to send messages at a
specific interval can be summarized as follows:
1. Line up an event every X seconds. For this tutorial an interval of two seconds was chosen.
2.
Once the event gets processed in the
processEvent()
-method the actual sending of the message
will be triggered.
3.
All information necessary for the sending will be assembled in
sendAdHocBroadcast()
and the
message gets actually sent out.
Application Setup
@Override
publ ic void setUp () {
g et Lo g ( ) . i nf o Si m Ti m e ( this , " Initialize a pp li ca ti on " );
g et O pe ra t in g Sy s te m () . g e tA d Ho c Mo d ul e ( ) . en a bl e ( new A d H oc M od u l eC o nf i g ur a ti o n ()
. a dd Ra dio () . chann el ( A dHocChan ne l . CC H ). pow er ( 50) . c re at e ()
);
g et Lo g ( ) . i nf o Si m Ti m e ( this , " Activated WLAN M od ule " );
sample();
}
Listing 4.5: TiergartenRSU: Setup for the RSU application
The setup for the RSU is the same as for the vehicle where we activate the Wifi module. Additionally, the
sample() method gets called which is responsible for the events.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 51
4 Tutorial Tiergarten 4.2 Inter-Vehicle Communication
Event scheduling
The next step is to line up the event at the interval we desire. The method we use for that,
sample()
,
looks like this:
publ i c void samp le () {
f in al E ve nt ev en t = n ew E ve nt ( g e tO p er a ti ng S ys t em ( ) . g et S im u la t i on T im e ( ) + T I ME _I NTE R VA L , ⤦
Çthi s );
g et O pe ra t in g Sy s te m () . g e tE v en t Ma n ag e r ( ) . a dd Ev e nt ( e ve nt ) ;
g et Lo g ( ) . i nf o Si m Ti m e ( this , " Sendin g out AdH oc b ro ad ca st " );
sendAdHocBroadcast();
}
Listing 4.6: TiergartenRSU: Event sampling
Here, an
Event
is created which will be received at the current time in simulation plus the defined interval
which is set to two seconds. The second argument for the event creation is a reference to the originating
class instance. For our tutorial, the
this
reference is sufficient here. After we created the event, it is added
to the event queue via
addEvent()
which will result in a call to
processEvent()
at the given interval.
Message sending
After we made sure the method that does the actual sending of the message is called at the specified
interval, we take a closer look at the
sendAdHocBroadcast()
method we defined in the
TiergartenRSU
class:
priva t e void se n d A d HocBroad c a s t () {
final TopocastDestinationAddress tda = TopocastDestinationAddress.getBroadcastSingleHop⤦
Ç() ;
fin al D es ti na ti onAddre ss Co nt ai ne r dac = Desti na ti on Ad dr es sC on ta in er .⤦
Çc re a te T op oc as t De st in a ti on Ad d re s sA dH oc ( t da ) ;
f in al M es s a ge R o ut i ng r ou t in g = n ew M e s sa g e Ro u t in g ( da c , g et O p e ra t i ng S y st e m ( ) .⤦
ÇgenerateSourceAddressContainer());
f in al I n te r Ve hi c le M sg me s sa ge = n ew I n te r Ve h ic l eM s g ( r ou ti ng , g e tO p er a ti ng S ys t em () .⤦
Çg et P os i ti on ( ) ) ;
g et O pe ra t in g Sy s te m () . g e tA d Ho c Mo d ul e ( ) . s en d V2 X Me s sa g e ( m e ss ag e ) ;
}
Listing 4.7: TiergartenRSU: Event sampling
We step through this method line by line and explain what each statement does:
1.
The destination address for this method is constructed in the first line. We use the helper-method
getBroadcastSingleHop() to denote that we want to send a single hop broadcast.
2.
After that, we wrap the destination address in a container that is created via
createTopocastDes-
tinationAddressAdHoc(). Since we use ad hoc wifi for this tutorial this method will suffice.
3.
The next step is to create the routing for the message. The routing basically ties together a desti-
nation address and a source address. We use the destination address we created in the first two
lines and use the default source address that can be created with the
generateSourceAddress-
Container() method.
4.
The last step in crafting the message is to create an instance of our custom message class
InterVe-
hicleMsg
. The actual payload is the position of the sender, other payloads are possible depending
on the requirements of the application.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 52
4 Tutorial Tiergarten 4.3 Intra-Vehicle Communication
5.
The message is sent out using the
sendV2XMessage()
-method that is provided by the operating
system.
These steps conclude the sending of the message. The procedure is the same for sending messages from
a vehicle instead of a RSU.
4.3 Intra-Vehicle Communication
This part of the tutorial describes the steps necessary for letting two applications to communicate with
each other on the same vehicle. Here, we use the
TiergartenVehicle
application as the sender and
TiergartenVehicleSlave
as the receiver. In general, the approach is similar to the sending of a V2X
message and also makes use of the event system.
Message sending
First, we start off with the sending side. The event code should look familiar:
@Override
publ i c void af t e r Update V e h i cleInf o () {
f in al Li st < ? e xt end s A pp li c at io n > a pp l ic a ti o ns = g et O per at i ng S ys t e m () . g e tA p pl i ca t io n s ( ) ;
fin al In traVeh ic le Msg m essage = n ew I nt ra Vehicle Ms g ( get Op er ating Sy st em () . ge tId () ,
rand om . n ex tI nt ( MAX_ID ) );
for ( A pp li ca tion application : applicat ion s ) {
f in al E ve nt ev en t = n ew E ve nt ( g e tO p er a ti ng S ys t em ( ) . g et S im u la t i on T im e ( ) + 1 , ap p li ca ti on ⤦
Ç, message);
thi s . g e tO pe r at i ng S ys te m ( ) . g et E ve n tM a na g er ( ) . a dd Event ( e ve nt ) ;
}
}
Listing 4.8: TiergartenVehicle: Sending intra application message
One noteworthy thing is that we use the
afterUpdateVehicleInfo()
-method to line up a new event.
This method is called automatically if the vehicle info (for example, speed or heading) gets updated,
which usually takes place at every time step of the simulation.
The general approach works like this:
1. Get a list of all applications that run on the vehicle using getApplications().
2.
Create a new message. Here we use our own custom message called
IntraVehicleMsg
which
takes an randomly generated id and the name of the vehicle as payload. Again, this is for tutorial
purposes and could be anything.
3.
After that we iterate over every applications that runs on the vehicle, in this case two:
Tiergarten-
Vehicle and TiergartenVehicleSlave.
4.
Then, an event is constructed for each app running on the vehicle and added to the event queue
the same way as in the inter-vehicle example.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 53
4 Tutorial Tiergarten 4.3 Intra-Vehicle Communication
Receiving the message
The actual receiving of the message takes place in the
TiergartenVehicleSlave
application. Since the
intra vehicle messages are basically treated as an event, the code is straight forward here:
@Override
publ ic v oid p ro ce ssEvent ( Event ev ent ) t hr ows E xc ep ti on {
O bj ec t r es ource = e ven t . g etRe so urce ( ) ;
if ( r e s o u r c e != null && resource i n s t a n c e o f IntraVe h i c l e M s ) {
fin al I nt ra Ve hi cl eM sg me ssage = ( In t ra Ve hi c le Ms g ) r esource ;
if ( m ess a ge . g etOr i gi n () . e qu al s ( g e tO p er at i ng S ys t em () . g et Id ( ) )) {
g et Lo g ( ) . i nf o Si m Ti m e ( this , " Received message from another applic at ion " );
}
}
}
Listing 4.9: TiergartenVehicleSlave: Receiving intra application message
The general concept here is that the payload is wrapped as an object in the actual event. The procedure
here is as follows:
1. Retrieve the resource from the event using getResource()
2. Check if there is actually some kind of payload
3. Make sure the payload is of the expected type
4. Cast the payload to an actual class and do something with it.
4.3.1 The traffic light application
As can be seen in the mapping configuration there is an additional prototype defined for traffic lights:
{
"applications":[" c om . d ca it i . vsimr ti . ap p . tutorials . t ie rgarten . t r af fi cLi gh t .⤦
ÇTrafficLightApp"],
" nam e ":"TrafficLight"
}
Listing 4.10: Traffic Light Prototype
These prototype is used to map the referenced application onto two specific traffic lights, as shown in the
following listing.
tl s ":[
{
"tlName" : " 2 70 11 311 " ,
"name": " TrafficLight"
},
{
"tlName" : " 252864801" ,
"name": " TrafficLight"
}
]
Listing 4.11: Traffic Light Mapping
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 54
4 Tutorial Tiergarten 4.4 Interpretation of simulation results
The use case shown for tutorial purposes here is simple: The two traffic lights referenced in the mapping
default to always red. Their application then waits for a V2X message with a “secret” payload in it (the
GreenWaveMsg
) and switches the traffic light program to always green upon receiving that message. The
application mapped onto the traffic light then switches back to its previous program after 20 simulation
time steps have passed. An in-depth explanation of traffic light functionality can be found in Chapter 6.
4.4 Interpretation of simulation results
The last part of the tutorial describes how to retrieve the actual simulation results. For this tutorial, the
results are quite simple and simply show the arrival of the Inter- and IntraVehicle messages. So after
executing the simulation using the following command:
./ v si mr t i . sh - u < u se r > - s T i er g ar t en
Listing 4.12: Running the simulation with the Tiergarten scenario (Unix machine)
v si m rt i . b at -u < u se r > - s T ie r g ar t en
Listing 4.13: Running the simulation with the Tiergarten scenario (Windows machine)
Afterwards, in the log directory of
VSimRTI
a new folder should be created containing all log files of the
simulation run. Within, the sub-folder
appsNT
contains the log files for each simulation unit and its
application. For example, for the vehicles we end up with two log files:
TiergartenVehicle.log
and
TiergartenVehicleSlave.log.
This following snippet shows the receiving of the V2X messages that were sent by the RSU:
INFO - Initialize ap p li ca ti on ( at s i m ul a t i o n time 6.000 ,000 , 000 s )
INFO - Activated AdHoc Modul e ( at simulation time 6 .000 ,0 00 ,000 s)
INFO - Received V2X M essage from r su_0 ( at simulation tim e 18.000 , 400 ,00 0 s)
INFO - Received V2X M essage from r su_0 ( at simulation tim e 20.000 , 400 ,00 0 s)
Listing 4.14: Snippet from TiergartenVehicle.log
Next, we see the contents of the IntraVehicleMessage that originates from another app on the vehicle:
INFO - Initialize ap p li ca ti on ( at s i m ul a t i o n time 2.000 ,000 , 000 s )
INF O - R ec ei ve d m es sa ge f rom another applicati on : Intr aV eh ic leMsg { origin = ’ v eh _0 ’ , id =631} ...
Listing 4.15: Snippet from TiergartenVehicleSlave.log
The following log was generated by the RSU application and logs the sending of each ad hoc broadcast:
INFO - Initialize ap p li ca ti on ( at s i m ul a t i o n time 0.000 ,000 , 000 s )
INF O - A c ti vated WLA N Mod u le ( a t s i mu lation tim e 0. 00 0 , 00 0 , 00 0 s )
INF O - S endi n g o ut A dH oc b r oa d ca st ( at s i mu l at i on t im e 0 .00 0 , 00 0 , 00 0 s )
INF O - S endi n g o ut A dH oc b r oa d ca st ( at s i mu l at i on t im e 2 .00 0 , 00 0 , 00 0 s )
Listing 4.16: Snippet from TiergartenRSU.log
This concludes the first tutorial and hopefully gave an idea on how to use the VSimRTI application
simulator to send out and receiving messages to other simulation entities or inside the same vehicle.
The
OperatingSystem.log
files do not contain specific application output and is mainly used for
debugging purposes and won’t be discussed in this tutorial.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 55
5 Tutorial Barnim
The following tutorial shows some of the more advanced features of VSimRTI and will take a closer look
at different federates. The term federates describes the High Level Architecture and basically denotes a
dedicated simulator with whom the simulation infrastructure can communicate. The following topics
will be covered in this tutorial:
• How to use and react to DENMs Decentralized Environmental Notification Message.
•
Enabling and using a different communication simulator on the basis of the VSimRTI cell simulator.
• The integration of electric mobility aspects into a simulation.
Note
: The topics from the last tutorial, especially how to map applications and the basics of how to
implement them are not covered in this tutorial. If you are not yet familiar with these concepts you should
have a look at the preceding tutorials.
5.1 Overview
The scenario used for this tutorial is more complex than the Tiergarten tutorial; thus, we will provide you
a short explanation. Picture 5.1 shows an overview of the Barnim scenario, exhibiting an icy road section
along the highway.
Figure 5.1: Overview of Barnim tutorial scenario
5 Tutorial Barnim 5.2 Mapping configuration
In this scenario, several cars drive on the blue route and are forced to slow down in a specific section due
to icy conditions. The rest of the scenario can be described as follows:
1.
A car (
Car A
) which is equipped with ad hoc communication (WiFi) capabilities detects an environ-
mental hazard - in this case an icy section of the road.
2. Car A
now sends out a DENM which reaches other cars in its (relatively small) dissemination area.
With multi hop routing, the DENM message is transported upstream towards other vehicles.
3.
Cars that do not have any form of communication equipment are not warned and drive towards
the icy part of the road. Since they have careful and responsible drivers they slow down to avoid
accidents.
4.
Cars that are equipped with the appropriate communication equipment are able to receive the
DENM, which induces them to use a different route (green) which is safer and faster due to the lack
of ice on it.
5.
Last but not least, the
WeatherServer
(technically implemented as an RSU) propagates information
over the cellular network and could therefore be located virtually everywhere.
We also have some electric vehicles here, mainly to demonstrate how the VSimRTI battery ambassador
works. Later in this tutorial, we will show you how to access statistics such as the state of charge of the
battery from within an application.
5.2 Mapping configuration
This section gives a short explanation of the mapping we use in this scenario. First of all we use five
different types of entities. One RSU which acts as the WeatherServer and four types of cars, each of
them loaded with different applications. As usual, the configuration takes place in
mapping3/mapping_-
config.json in your scenario folder.
1.
Normal vehicles which cannot communicate shall demonstrate how to use electric vehicles in
a scenario (60% of all vehicles). They are only equipped with the
com.dcaiti.vsimrti.app.
tutorials.barnim.SlowDownApp
-application which induces them to reduce their speed as soon
as their onboard sensors detect hazardous conditions. After leaving the hazardous area, they will
resume by increasing their speed again.
2.
Vehicles equipped with ad hoc wifi. They might not be able to receive the DENM due to
range limitations and drive into the icy section nonetheless. They are equipped with the
com.dcaiti.vsimrti.app.tutorials.barnim.WeatherWarningApp
-application and the
com.
dcaiti.vsimrti.app.tutorials.barnim.SlowDownApp-application (20% of all vehicles).
3.
Cellular communication enabled vehicles which are able to communicate with the Weath-
erServer. These vehicles are equipped with the
com.dcaiti.vsimrti.app.tutorials.barnim.
WeatherWarningAppCell
-application, which is a specialized form of the normal weather warn-
ing application that can make use of cellular communication. They are also equipped with the
com.dcaiti.vsimrti.app.tutorials.barnim.SlowDownApp
-application (10% of all vehicles).
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 57
5 Tutorial Barnim 5.3 VSimRTI configuration
4.
Electric vehicles cannot communicate since they are only equipped with the
com.dcaiti.
vsimrti.app.tutorials.barnim.SlowDownApp
-application. Apart from that, they also incor-
porate an electrical battery which empties during driving (10% of all vehicles).
5.
The WeatherServer is only equipped with cellular equipment. Despite the greater distance it is able
to warn vehicles that can also make use of cellular communication.
5.3 VSimRTI configuration
Since several applications are mapped, we need to make sure that the corresponding simulators are
enabled. This is done in the main VSimRTI configuration file that resides in
vsimrti/vsimrti_con-
fig.xml
in your scenario. The last part of that configuration file is used to enable and disable certain
simulators according to the needs of the user.
Per default, any simulation of cellular communication is disabled. In order to enable communication via
cellular networks in this scenario, you need to enable the
cell2
simulator by setting the field
active
to
true:
<! -- Cellula r netw o r k si mu l a t o r s - - >
< f ed e ra te i d =" c el l2 " active=" tru e "/ >
Listing 5.1: VSimRTI configuration for barnim example scenario
5.4 Applications
This section deals with the specific details of the
WeatherWarningApplication
. We will cover in partic-
ular how to enable and use cellular communication, how to react to DEN-Messages and how the user can
achieve a re-routing of vehicles.
Overview
Here we will explain the application logic and the main ideas behind it in general terms and will go
into the implementation details in the following sections. All of the subsequent points stay the same
regardless of what form of communication is used.
•
If the sensor picks up an event, the vehicle sends out a DEN-message (via cellular communication
or ad hoc) with the position that was recorded in order to warn other vehicles.
•
The application also contains code to react upon DENMs received from other vehicles. Depending
on the configured behavior of the application, either a slow down or a re-routing is performed.
Most of the things that are happening here like re-routing, interval-handling and sending out ad hoc
messages were already covered in the first tutorial and will not be discussed in detail in this tutorial.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 58
5 Tutorial Barnim 5.4 Applications
5.4.1 DEN-Message handling
Receiving
First of all, we look at the receiving side of the
DENM
here. Since the message is a normal V2X message it
is received through the receiveV2XMessage()-method which is part of the application interface.
if (!( m sg i ns ta nceof DEN M )) {
getL og () . info ( " I gnor i ng me s sa ge o f typ e : {} " , m sg . g e tC l as s Na me () ) ;
return;
}
Listing 5.2: Testing wether or not message is a DENM
Analogous to a normal message, we check with
instanceof
, if it is of a type that we are interested in, in
this case DENM. Afterwards, we perform a potential route change if not already done.
Sending
In case the sensor detects an environmental hazard the vehicle sends out a DEN-message to warn
other vehicles. If
WeatherWarningAppCell
is mapped, cellular communication is used, in case of
WeatherWarningApp ad hoc WiFi is used as described in the Tiergarten tutorial.
5.4.2 Cellular Communication
We will now take a closer look at how the communication via the VSimRTI cellular simulator works.
The application we point to in the mapping is a specialized form of the normal WeatherWarning-
Application and can be found under its full identifier
com.dcaiti.vsimrti.app.tutorials.barnim.
WeatherWarningAppCell
. It overloads the
useCellNetwork
-method which returns a constant true in
order to indicate that we want to use cellular communication inside the base application. The reason for
this overloading is to provide a distinct class to which we can point in the mapping. The actual logic that
is required to send messages via cell is done in the base WeatherWarning application, so the overloading
just signals that we want to use cellular communication.
The method where the actual sending takes place is called
reactOnEnvironmentData()
. The following
code snippet shows the steps necessary to send a DEN-message via the cellular network:
GeoCircle des t = ne w G eo Ci rc le ( v _long La t , 3 000) ;
GeocastDestinationAddress gda = GeocastDestinationAddress.createBroadcast(dest);
fin al D es ti na ti on Ad dr es sC on ta in er d ac ;
if ( u s eC e ll Ne t wo r k ( ) ) {
da c = D est in at io nA dd re ss Co nt ai ne r . c r ea te Ge o Un ic as t De s ti na ti o nA dd re s sC e ll ( g da ) ;
} else {
dac = De s ti na ti on Ad dr es sContai ne r . cr ea te Ge oc astDes ti na ti on Ad dressA dH oc ( gda );
}
M es s a ge R o ut i n g m r = n ew M e s sa g e Ro u t in g ( da c , g e t Op e r at i n gS y s t em () . g e ne r a t eS o u r ce A d d re s s C on t a i ne r ⤦
Ç() ) ;
DENM denm = new DENM (mr , getOper a t i n gS y s t e m () . ge t S imulation T i m e () , v_longLat , roadId , type , ⤦
Çstrength , newSpeed , 0.0f);
g et O pe ra t in g Sy s te m () . g e tA d Ho c Mo d ul e ( ) . s en d V2 X Me s sa g e ( d en m ) ;
Listing 5.3: Example for sending over cellular networks
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 59
5 Tutorial Barnim 5.5 Conclusion
The sending is the same as in the Tiergarten tutorial, except that we decide via an
if
-statement whether
or not cellular communication or ad hoc WiFi is used. Note the two different methods - one is ending
with Cell the other with AdHoc, depending on what we want to use in the application.
5.5 Conclusion
This concludes the description of the VSimRTI tutorial scenarios Tiergarten and Barnim. The following
list sums up the things we have covered in this tutorial series:
•
Getting a general idea on how to configure VSimrti, especially how to enable and disable different,
coupled simulators.
• How to map different applications to a vehicle or a road side unit
• Achieving inter- and intra-application communication...
• ... via cellular networks or AdHoc wifi
• Receiving and handling of messages
• Basic interaction with the OperatingSystem by means of changing a route
• How to find and process the results of a simulation run with the help of generated log files.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 60
6 Tutorial Traffic Lights
In this brief tutorial we will discuss how to interact with traffic lights via VSimRTI. Usually the position
and the lanes they control are coming from the OpenStreetmap-data, which we will also assume during
this tutorial. Note that this tutorial is intended to be used with the
Tiergarten
scenario described in the
first tutorial in Chapter 4, so creating a new scenario for is not necessary here and the Traffic Light data is
already exported.
At first we cover the general steps necessary to enable traffic lights and eventually “map” applications
onto them. Each step is described in more detail later on.
1. Tell scenario-convert to export the traffic light information into the database
2. Determine the node ids of the traffic lights which should have applications on them
3.
Adjust the mapping configuration of VSimRTI accordingly and assign the desired application(s)
onto one or more traffic lights.
Additional information on how to use traffic lights, how they are modeled within sumo and how their
phases work can be found in the sumo wiki under
http://sumo.dlr.de/wiki/Simulation/Traffic_Lights
6.1 Use scenario-convert to export traffic lights
Although the Tiergarten scenario which we are focusing on in this tutorial already has the traffic lights
exported from the .osm file, this step is important if you desire to set up an own scenario. For the
Tiergarten example, the scenario-convert command line looks like this:
scenari o - convert -18.0. jar - -osm2sumo -d tiergarten . db - i tiergarten . osm -l -n
Listing 6.1: Export of traffic lights using scenario-convert
Note the
-l
switch here that actually exports the traffic light information from the .osm file to the
tiergarten.db database. If this command line switch is omitted the traffic lights will not be available in the
scenario. More information on how traffic lights are handled by Open Streetmap can be found in their
wiki: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals
6 Tutorial Traffic Lights 6.2 Determine the traffic lights that should be equipped with applications
6.2 Determine the traffic lights that should be equipped
with applications
The next step is to decide which traffic lights should have applications on them. Since their ID(s) have to
be referenced in the mapping, we will have to determine them first. There are several ways to do this, e.g.
taking them directly from the database using a tool like sqlitebrowser or extract them directly with a text
editor from the .net.xml file that gets generated by scenario-convert for usage with sumo. However, here
we will focus on a graphical approach using sumo-gui since it is the easiest way to determine the exact
traffic lights we want to map applications too.
Figure 6.1: Locating traffic lights in sumo gui
Figure 6.1 shows how to locate a specific traffic light, or more precise, a traffic light group. The process
is as simple as scrolling to the desired traffic light, right click on it and write down the number behind
tlLogic
in the drop down menu or use the copy to clipboard feature of the sumo gui. This id is then used
in the next section which explains how to actually map applications to a traffic light.
6.3 Configure the mapping for traffic lights
Now that we have the ids of the traffic lights we can modify the mapping to assign application(s) to them.
Note that the tutorial scenario already has applications assigned to two arbitrary traffic lights, so the
mapping file bundled with it can also be used as a starting point here. In general, the mapping looks the
same as for vehicles or RSUs. First, we define a prototype that is used for all subsequent traffic lights:
1{
2" prototypes ":[
3{
4"applications":[" c om . v si mr ti . a ppl ic at ion s . a dd iti on alsa mp les . m isc .⤦
ÇTrafficLightExample"],
5" nam e ":"TrafficLight"
6}
7]
8}
Listing 6.2: Protype for traffic light
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 62
6 Tutorial Traffic Lights 6.4 The Traffic Light API
The listing 6.2 shows an additional prototype called TrafficLight that gets associated with the
Traffi-
cLightExample
application. Note that the application that should run on the traffic light has to extend
AbstractApplication<TrafficLightOperatingSystem>
in order to work. The next step is to use
this prototype and assign it to a traffic light we found in the section before using the sumo gui:
1" tl s ":[
2{
3" tlNa me " :"27011311",
4" nam e ":"TrafficLight"
5},
6{
7" tlNa me " :"252864801",
8" nam e ":"TrafficLight"
9}
10 ]
Listing 6.3: Example mapping of traffic lights
Listing 6.3 shows as an example how this prototype is assigned via the name attribute to specific traffic
lights. The important aspect here is that tlName refers to the id of the traffic light we found via the sumo
gui in section 6.2 which must exactly match each other.
6.4 The Traffic Light API
In order to access the traffic light functionality from within an application it must extend the
AbstractApplication<TrafficLightOperatingSystem>
abstract class. There are two main func-
tionalities provided by it, reachable from the application operating system that can be acquired by using
the getOperatingSystem() method:
• Change the currently active traffic light program via setProgramById()
• Adjust the remaining time of the currently active phase via setPhaseRemainingDuration()
However, adding a new traffic light program from within the application at runtime using the VSimRTI
application interface is currently not possible and has to be done beforehand via sumo as described
here:
http://sumo.dlr.de/wiki/Simulation/Traffic_Lights
. The two main ways of doing this is
to use an
additional
-file or the
tls_csv2SUMO.py
tool bundled with sumo. However, it is possible to
add a new program by using the TraCI interface as described here:
http://sumo.dlr.de/wiki/TraCI/
Change_Traffic_Lights_State.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 63
7 Tutorial LuST
The Luxembourg SUMO Traffic (
LuST
) scenario is a traffic simulation scenario which aims to provide
realistic traffic patterns of a common mid-size European city during an average day [
4
]. This traffic
simulation scenario for
SUMO
has been developed by Lara Codecá et al. and is publicly available via
GitHub
1
. The following tutorial shows, how the
LuST
scenario can be integrated into
VSimRTI
in order to
assess your own mobile application at large scale.
Notice:
Also, you can use this scenario as a blueprint for integrating your own prepared
SUMO scenarios into VSimRTI.
Figure 7.1: Overview of the simulation site of the LuST scenario [4]
• Area: 156 km2
• Total length of all roads: 930 km
• Total length of highways: 89 km
• Number of intersections: 4.473
• Number of traffic lights: 203
•
Number of vehicles during 24h of simulation
time: 215.526
1https://github.com/lcodeca/LuSTScenario
7 Tutorial LuST 7.1 Execute the LuST scenario with VSimRTI
7.1 Execute the LuST scenario with VSimRTI
You can find a prepared
VSimRTI
scenario for the
LuST
scenario in the pre-installed scenario directory.
However, to get this scenario working, you need to execute the following steps:
1.
In the subdirectory
sumo
of the
LuST
scenario directory, you can find several scripts which will
help you to download the actual SUMO scenario from the official sources on GitHub. Depending
on which operating system you use and which version control system client you have installed,
you can use one of the provided batch or shell script files. If you do not have a git or svn client
installed, you can also manually download and unzip the SUMO scenario from
https://github.
com/lcodeca/LuSTScenario
. Please note that the SUMO scenario must be placed inside the
sumo subdirectory of the scenario.
2.
In order to execute VSimRTI with the scenario, you need to pass the given
defaults.xml
to the
executable. On Windows, this can be done by executing VSimRTI as follows:
vsimr ti . bat - u < user - id > - s L uST - d scenarios / LuS T / defa ults . x ml - w 0
Please note that the execution of this scenario might take a long time, due to the massive amount of
vehicles simulated in this scenario. If you want to assess your mobility applications in combination
with further simulators (e.g. Cell2), the simulation might slow down even more.
Finally, you can map your own applications onto vehicles using the prepared
mapping_config.json
.
Please note that applications can only be mapped for each vehicle type (see limitations below). Further-
more, you can activate any communication simulator, such as Cell2 or SNS, to integrate communication
simulation into your assessment.
7.2 Current limitations
The integration of the
LuST
scenario is currently a work in progress and therefore not all features are
available. The following limitations currently exist:
•No mapping of applications on single vehicles.
It is currently not possible to map applications on
single vehicles. Instead, only vehicle types can be mapped with them. Of course, the applications
are running solely on each simulated vehicle which belongs to the respective vehicle type the
application is mapped on.
•No definition of own vehicle spawner.
Currently, all simulated vehicles are spawned by the SUMO
traffic scenario itself. There is no way to add additional vehicles via the mapping_config.json.
•No routing capabilities in applications.
Applications cannot use the navigation module of the
vehicle. Furthermore, detailed information about the current route or the road position (upcoming
nodes, type of the current road) is also not available to the applications. This is due to the missing
scenario-database, which is currently not possible to create from the LuST road network.
•No valid support of traffic light applications.
The mapping of applications onto traffic lights has
not yet been tested.
• There may be more limitations we are currently not aware of.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 65
8 Create a new scenario
This chapter is intended to act as a checklist for all tasks, needed to create a new scenario. Basically, a
new scenario means that the simulation is performed in a different road network where vehicles have
different routes. Moreover, the number of vehicles can also vary.
8.1 Road network data
The first step always is to prepare a road network the simulation should take place in. While in general it
is not relevant where the network data is coming from, we only provide ready to go import functions for
OpenStreetMap (
OSM
) data which is freely available and comprehensive. Also if data in the target area is
not up to date or needs to be adapted to the specific needs this can be done without problems.
In case there are ready to go scenarios for supported traffic simulators like SUMO we also try to support
that. Nevertheless, we cannot guarantee to support all tool specific functions, so we really recommend
using OpenStreetMap data as source.
If you already have data from other sources or want to use another data provider, additional steps might
be necessary. If you have any questions or need further support, please feel free to contact our support
team via our mailing list.
8.1.1 Using OpenStreetMap data
Preparing the data source
For this approach, simply download the
*.osm
file of the desired region using the openstreetmap.org
website or any other tool that supports
*.osm
file export (e.g. josm
1
or merkaartor
2
) and save it. Be
aware that we currently do not support the binary version *.pbf or any compressed versions.
Make sure that the file only contains complete ways. This means the file should not contain ways which
reference nodes that are outside the target areas bounds. Usually this only has to be checked if the
downloaded data was manually cropped with tools like osmosis
3
. Such tools usually also have an option
that will remove such ways (for osmosis this is completeWays=yes).
It is best practice to not let the source file contain roads clearly not usable (like bicycle or pedestrian
ways). This is to not clutter the simulation with unnecessary data resulting in a serious slow down for
some aspects of the simulation like routing. There are several ways to filter OpenStreetMap files, the
most convenient way is included in the tool we provide to process the source file, we will get back to that
1https://josm.openstreetmap.de/
2http://merkaartor.be/
3http://wiki.openstreetmap.org/wiki/Osmosis
8 Create a new scenario 8.1 Road network data
in a minute. If you need more control over the filter process we recommend to use osmosis or one of the
editors already mentioned.
Processing the data
VSimRTI
uses a database for internal storage of map and route data. Therefore it is necessary to con-
vert OpenStreetMap data into the
VSimRTI
specific database format. While converting we filter out
unnecessary information about the road network and prepare the data in a way, that allows us to provide
routing functionality and create a common base for other components in the simulation like the traffic
simulator.
To be able to do this we provide the tool scenario-convert which can be found in
vsimrti/bin/tools
. As
already mentioned this tool also provides a basic filtering for OpenStreetMap input. The usual command
to use in this case is:
jav a - j ar sc en ar io - c on ve rt -18.0. jar - - os m 2d b - i p at h / to / s our c e . os m - o
In this command
-o
provides the default filtering which filters out every street below type
tertiary
.
Executing this will generate you a new file with file ending
.db
which will be named the same as your
*.osm
file. So for the given command it would generate a
source.db
in the directory
source.osm
is
found. Additionally a second
*.osm
file with the suffix
_cleaned
will be created which is the filtered
source data actually used in the import process. With
-d
you can provide a custom file name for the
database alongside a path where it should be placed. If you provide a name please do so without the file
extension, the correct one will be added automatically.
Now you should have a brand new database which contains the road network. In the next step you need
to export the data in a format that can be understood by the traffic simulator to be used and still matches
the information in the database. To do so export that data from the database like this:
jav a - j ar sc en ar io - c on ve rt -18.0. jar - - db 2 su mo - d p at h / to / d a ta ba s e . db -n
The example execution should have created a number of
SUMO
specific network files (nodes, edges
and connections). The parameter
-n
automatically executes
SUMO
s netconvert command after the
export to create the needed netfile (requires
SUMO
to be in the systems path). If you want to have traffic
lights generated by netconvert, you need to add the option
--export-traffic-lights
to the command
above.
Now you have processed the road network to be in formats usable by
VSimRTI
and its connected simula-
tors.
Regarding files, the output of these two steps should be the following:
•<scenarioName>.db - scenario database (including road network)
•<scenarioName>.nod.xml - SUMO node file
•<scenarioName>.edg.xml - SUMO edge file
•<scenarioName>.con.xml - SUMO connection file
•<scenarioName>.net.xml - SUMO network file (after executing netconvert)
•<scenarioName>.sumo.cfg - SUMO configuration file
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 67
8 Create a new scenario 8.2 Vehicles and Routes
8.2 Vehicles and Routes
VSimRTI
contains a navigation component which supports the usage of different routes, vehicles can
be mapped to. In order to make the routes accessible for the simulation in
VSimRTI
, they have to be
available in the scenario database. There are two ways to achieve this:
• Generate routes with scenario-convert
or
• Import an existing SUMO route file
Generate routes
scenario-convertoffers possibilities to generate routes for the simulation. With the following command
you can generate routes from one geo-point (latitude,longitude) to another:
jav a - j ar sc en ar io - c on ve rt -18.0. jar - d p at h / to / d ata b as e . d b - g -- ro ute - be gin - l at lon LAT , LON - -⤦
Çroute - end - latlon LAT , LON
If geo-points are given as input, the route generation might fail due to unmatchable points. In this case,
you may use the following command in order to calculate routes from one street node to another:
jav a - j ar sc en ar io - c on ve rt -18.0. jar - d p at h / to / d ata b as e . d b - g -- ro ute - be gin - no de - id N OD E _I D --⤦
Çro ute - end - n ode - i d N OD E _I D
The required node ids can be determined from the source
OSM
file or the generated
SUMO
network file.
For more than one route between the given points/nodes, the parameter
–number-of-routes NUMBER
can be used. The calculated routes are directly written into the database. If you need to export them into
aSUMO readable format, you can use the command:
jav a - j ar sc en ar io - c on ve rt -18.0. jar - - db 2 su mo - d p at h / to / d a ta bs a e . db -r < s c en ar io n am e >. r ou . x ml
Import routes from SUMO route file
If you want to use the tools provided by
SUMO
, e.g. duarouter
4
, to calculate a set of routes for the
simulation, you need to import the resulting routes into the scenario-database of
VSimRTI
. Note, if
you use such tools, please always use the network file generated by scenario-convert. The route file
(
*.rou.xml
) generated by those tools can be directly imported into the database by using scenario-
convert. For this purpose, you can use the following command:
jav a - ja r s cena ri o - con ve rt -18.0. ja r - - su mo 2d b - r r ou te file . ro u . xml - d p at h / to / databsae
This command will read the routes in the route file and write them in the supplied database file. The
database file needs be the same you used to export the network file. If the route file also contained vehicle
definitions these will be converted into a mapping3 configuration file. You will need to adapt this file later
on to achieve a meaningful mapping between vehicles and applications. For more information regarding
this please refer to chapter 3.5.15.
4http://sumo.dlr.de/wiki/DUAROUTER
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 68
8 Create a new scenario 8.3 VSimRTI
8.3 VSimRTI
Now you have everything you need to create a configuration set that
VSimRTI
will recognize as a sce-
nario. A scenario is generally a folder structure that reflects the different components usually found in a
simulation. The example tutorials of Barnim and Tiergarten also follow this specific folder structure.
The complete set of components is depicted in the Listing 8.1.
<scenarioName>
applicationNT
battery
eventserver
cell2
mapping3
ns3
omnetpp
sources
sns
sumo
visualizer
vsimrti
Figure 8.1: Scenario: folder structure for complete component set
However, a subset of all components already allows reasonable simulations. The most important compo-
nents are mentioned in the following part.
Applications and Mapping (applicationNT, mapping3)
Usually you want the simulated vehicles to be equipped with some kind of applications that influence the
vehicles behavior. To do that you copy the jar files of your applications to the folder
application/ap-
plications
. To further configure the behavior of the application simulator have a look at chapter
3.5.
Having the applications in place you will have to copy your mapping file to the folder
mapping3
. If
you don’t have one by now have a look at the configuration for the default simulations provided with
VSimRTI.
For further information on controlling the mapping see chapter 3.5.15.
Navigation (applicationNT)
The generated database file
<scenarioName>.db
needs to moved into the
applicationNT
folder. As
long as you only have one database file in this folder you don’t need to do anything more.
VSimRTI
will
recognize the file automatically.
For further info on navigation in the application simulator have a look at chapter 3.5.14.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 69
8 Create a new scenario 8.3 VSimRTI
Traffic Simulator (sumo)
The generated files for the used traffic simulator go into the folder named after that simulator e.g.
SUMO
.
In the folder should be a configuration file that needs to be adapted, to point to the correct simulator
specific network file, e.g. <scenarioName>.sumo.cfg.
For further info on this type of simulators have a look at chapters 3.4.
Communication Simulator (cell2, ns3, omnetpp, sns)
There is an extensive default configuration provided in the simulators folder in the tutorials of Barnim
and Tiergartenfor all communication simulators.
Depending on the simulator you will need to tell the simulator the geographic extend of the simulation
area. You can find that data in the traffic simulators network file, e.g.
SUMO
s
*.net.xml
contains this
information in the convBoundary attribute of the location tag.
• For OMNeT++, it concerns the values of constraintArea in the omnetpp.ini.
•
For the CELL simulator, the expansions do not need to be configured directly. However, the
areas
of the configured regions (in regions.json) have to be in line with the scenario location.
• The SNS also comes without an additional expansion definition.
Important:
Larger values for the spatial expansion of the simulation area are also usu-
ally possible for the communication simulators. However, much larger this might decrease
the performance. Smaller values lead to wrong behavior and will crash the simulation!
For further information on the communication simulators, have a look at Chapters 3.2,3.3,3.6, and 3.7.
VSimRTI config
Having done that you are now ready to adapt the
vsimrti/vsimrti_config.xml
file to your needs. This
usually contains of setting the scenario id (recommended to use the scenarios folder name), adapting the
end time to cover everything you want to analyze.
An important setting is the transformation configuration, as this will control how geographic coordinates
will be converted to cartesians and back. Having a correct setting here is crucial to get correct results
that map to real world coordinates so the simulation results can be visualized in some way. The center
coordinate will be used to determine the correct UTMZone, the cartesianOffset can be determined by
having a look at the traffic simulators network file, e.g.
SUMO
s
*.net.xml
contains this information in
the netOffset attribute of the location tag.
Within the
IPResolverConfig
tag the address resolution scheme is specified. The subnets for all node
types are described in JSON format.
Last but not least make sure, that the correct simulators are activated and unused deactivated in the last
section of the configuration.
To simulate a generated scenario, copy the now ready scenario into the vsimrti/scenarios folder.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 70
8 Create a new scenario 8.3 VSimRTI
Further components
Several components (as the battery configuration or the visualizer configuration) are generally scenario
independent and can be copied from the existing tutorial scenarios Barnim and Tiergarten.
The event server component (to simulate an icy road etc.) obviously also depends on the scenario location.
The position of the event should be in line with and be located in the area of the scenario.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 71
9 Visualizers
9.1 Kinds of Visualizers
VSimRTI
provides several ways of data evaluation by so called visualizers. To visualize a scenario, different
visualizers can connect to a running simulation. Figure 9.1 gives a overview about the current coupled
visualizers. More than one visualizer of the same type can be defined.
vsimrti
VSimRTI WebSocket Visualizer ............................................. (see 9.2)
VSimRTI File Visualizer .................................................. (see 9.3)
VSimRTI Integrated Test and Evaluation Framework (ITEF) .............. (see 9.4)
user defined visualizer ..........................................................
Figure 9.1: VSimRTI visualizer structure
The visualization ambassador provides several ways to visualize and/or trace the activities that happen
during the simulation. The here explained visualization federate is responsible for providing data (in
form of subscribed messages) to the visualization component. The kind of visualization is completely
dependent on the component itself.
The
VSimRTI
File Visualizer aims to collect and format data for further processing after simulation. To get
an instant impression of a simulation, the
WebSocket Visualizer
shows vehicle movements on a Google
Map.
The visualizers are integrated into the simulation with a visualization ambassador.
9 Visualizers 9.2 VSimRTI WebSocket Visualizer
9.2 VSimRTI WebSocket Visualizer
To get a simple and instant impression of a simulation or to get an idea of how fast it runs or where a
simulation is located, the WebSocket Visualizer was created.
It shows a Google Map with markers, indicating the positions of all vehicles, updated as the simulation
progresses.
To start the visualization, simply open the visualizer.html in your browser. The WebSocket Visualizer is
enabled by default.
As soon, as the simulation is running, you can see the vehicle markers moving around.
You can also start the visualization at each simulation run, using the command line parameter -v.
Important:
By default, the WebSocket Visualizer does not work on Microsoft Edge.
UWP (Universal Windows Platform) apps on Windows 10 do not have direct network access
but are subject to a network isolation for security reasons, preventing localhost loopback
by default. While Microsoft Edge itself does allow localhost access, it treats localhost as an
Internet site, which leads to restrictions e.g. for IPC over IP. To prevent this, an exception
for Edge must be added to the network isolation via the following command in an elevated
command prompt:
Check N e t I s olation LoopbackExemp t -a -n= " Microsoft . Mic r os of tE dg e_ 8w ek yb 3d8bbwe "
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 73
9 Visualizers 9.3 VSimRTI File Visualizer
9.3 VSimRTI File Visualizer
The File Visualizer is a tool which gives you the opportunity to log specific VSimRTI message types.
9.3.1 Configuring the File Visualizer
• The main configuration file is located at
vsimrti/scenarios/<scenarioName>/visualizer/visualizer_config.xml
message record
•
Each message record is derived from a certain message type and composed of several entries, which
are separated by Element separator. A more detailed overview about the visualizable message types
in
VSimRTI
is given in the next chapter Results. The configuration of the file visualizer is explained
at the example of the VehicleMovements message.
• Attribute id indicates the message type, namely the class name of the message.
• Message has also an attribute enabled.
• The element entries defines the format and content of the finally visualized message record.
•
The element entries is composed of several sub-elements entry, which correspond to columns of a
message record and the sequence of the columns is the same as that of sub-elements entry.
entry
Basically, there are totally three types of entry: Just look at an example:
<? xm l v er si on = " 1.0 " e ncoding =" UT F - 8 " ? >
<message id="VehicleMovements">
<entries>
< e nt ry > "MOVE_VEHICLE"< / entry >
< e ntry > TimeInSec </ en try >
< e nt ry > U p da t ed : Id < / e nt ry >
< e nt ry > U p d at e d: A pp li c at i on Nr < / en try >
< e nt ry > U p da te d :P o si t io n . L at i tu de < / e nt ry >
< e nt ry > U p da te d :P o si t io n . L on g it u de </ e nt ry >
</entries>
</message>
Listing 9.1: Specific Configuration for message.
Constant
Every quoted entry is defined as a constant. The content inside the quotation will be directly visualized
into each corresponding message record.
< e nt ry > "MOVE_VEHICLE"< / entry >
Listing 9.2: An example for constant type entry.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 74
9 Visualizers 9.3 VSimRTI File Visualizer
Basic Method
The other two types of entry originate from the getXXX() methods of a certain object. For an entry, the
root object for method invoking is the corresponding message class, here VehicleMovements . If a null
object is returned before the last method of cascaded methods is invoked, then ”null” will be written
to the corresponding field. If a null object is returned by iteration method, then all fields involving this
iteration method will be set ”null”.
Iteration
< e nt ry > U p da t ed : Id < / e nt ry >
Listing 9.3: An example for method type entry with iteration.
The first part of this example is Updated , which means to invoke the getUpdated method of class
VehicleMovements . Then a list of VehicleInfo objects is returned. Then ;Id remains. The semicolon is an
operator for iteration, which means for each of the VehicleInfo objects in the returned list invoking getId
method.
Cascading
< e nt ry > U p da te d :P o si t io n . L at i tu de < / e nt ry >
Listing 9.4: An example for method type entry with iteration and cascading.
In this example, there is a dot operation. It is a cascade operation. Here getPosition method of VehicleInfo
class is called and a GlobalPosition object is returned. Then we continuously invoke the getLatitude
method of this GlobalPosition object.
Extended Method
All the methods involved above are the basic methods. There are also some functionality, which we can’t
extract from these existing methods. So an extended method set is offered to meet these requirements
and also as an extension point in the future.
simple extended method
< e ntry > TimeInSec </ en try >
Listing 9.5: An example for simple extended method type entry.
With existing methods of VehicleMovements and its super class Message , we can’t get the timestamp of a
message in second. (only Message.getTime , which returns a time in ns, is available). Here, getTimeInSec is
a method extension for Message class. The extended method set will be listed later.
assisting extended method
< e ntry > Up d a t e d:Ty p e < / entr y >
Listing 9.6: An example for assisting extended method type entry.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 75
9 Visualizers 9.3 VSimRTI File Visualizer
There are also methods both in the simple and extended method set. Taking getType method of VehicleInfo
as an example. If the type of a VehicleInfo object has not been set, this method will return null. But we
can take advantage of AddedVehiclesMapping messages to get its type. Thus, an extended getType will be
invoked if VehicleInfo.getType returns null.
Iteration
Basically, the method type of entry definition supports cascaded iteration as follows:
< e nt ry > L i st1 :L i st 2 :I d < / e nt ry >
Listing 9.7: An example for cascaded iteration.
What we haven’t met yet, is that, if in the definition of entries, several different iterating operations exists,
for example:
< e nt ry > S e nd e rs : Id < / e nt ry >
< e ntry > Re c e i v ers: I d < / entr y >
Listing 9.8: An example for multi-level iteration.
getSenders() and getReceivers() are two different iterations. In this case, a product of Ids in both list will be
generated. The result may look like this:
se nder1 , receive r1
se nder1 , receive r2
se nder2 , receive r1
se nder2 , receive r2
Listing 9.9: Visualising result of the above listing.
Note: the longest matched prefix will be considered as the same iterating operation, which means, they
are in the same level of iteration structure.
Method Sets
Method Type Info
Message.getTimeInSec() long
Message.getTimeInMS() long
ReceiveV2Xmessage.getType() String
SendV2Xmessage.getType() String
VehicleInfo.getApplicationNr() int
VehicleInfo.getType() UnitType @Deprecated
VehicleInfo.getTypeInOrdinal() int @Deprecated
Table 9.1: A list of all extended methods
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 76
9 Visualizers 9.3 VSimRTI File Visualizer
Method Type
VehicleMovements.getUpdated() List<VehicleInfo>
VehicleInfo.getId() String
VehicleInfo.getPosition() GlobalPosition
GlobalPosition.getLatitude() double
Message.getTime() long
VehicleInfo.getType() UnitType
Table 9.2: A list of some basic methods
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 77
9 Visualizers 9.4 VSimRTI Integrated Test and Evaluation Framework (ITEF)
9.4 VSimRTI Integrated Test and Evaluation Framework
(ITEF)
Notice: ITEF
is only available with a commercial license of VSimRTI. For further
information on licences, please refer to our mailing list .
The Integrated Test and Evaluation Framework (
ITEF
) is a webtool for planning and evaluating vehicular
communication scenarios. It is suited for field operational tests as well as simulations.
ITEF
also offers a variety of visualization features, making a comparison of different vehicles or between
equipped and unequipped vehicles easy. It is structured into 4 screens, whereas the following 3 screens
are intended for the visualization.
The Replay screen (see Figure 9.2) is intended to be used for an initial overview of the test run. The
main feature is the display of the vehicle movements on a map, while the player can be used to playback
the movement situation. In this manner, the ITEF allows a location and time dependent evaluation of
simulation test runs.
The Evaluate screen (see Figure 9.3) allows the detailed investigation of the correlations in a test run. The
main feature of this screen is to display the behavior summarized over the whole run. The structure of
this screen with is similar to the Replay screen. However, the focus here is on the detailed (statistical)
summary of evaluated metrics.
Finally, the Statistics screen (see Figure 9.4) provides statistical evaluations of the test and simulation run.
Currently, statistics on Vehicle Speed, Travel Time, Travel Distance and several more are supported.
Figure 9.2: ITEF Replay Screen
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 78
9 Visualizers 9.4 VSimRTI Integrated Test and Evaluation Framework (ITEF)
Figure 9.3: ITEF Evaluate Screen
Figure 9.4: ITEF Statistics Screen
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 79
10 Run simulation series
10.1 Simulation Runner
Notice:
The simulation runner is only available with a commercial license of VSimRTI.
For further information on licences, please refer to our mailing list .
The simulation runner is a tool for automatic simulation parametrization and execution. Accordingly,
a comfortable way exists to configure the execution of multiple simulations, e.g. of simulation series
including several runs where only few parameters are changed in each run. With the simulation runner,
a simulation series can be defined, for example, where the
V2X
penetration rate is changed in each
simulation run. As a result,
VSimRTI
starts all simulation runs automatically according to the defined
parameters.
10.1.1 Usage
The simulation runner is started as follows:
GNU/Linux
./ simr un . sh - c / s ce na ri os / < scenario name >/ v si mrti / simru n_ co nf ig . xml -p ⤦
Çnumberofparallelsimulations
Listing 10.1: VSimRTI simulation runner start command for GNU/Linux.
GNU/Linux
java - jar V s i m r t i E m b e d d e d St ar te r -x. x . x. jar -s - u userid -- strict - c o nfiguratio n - path - c ⤦
Çscenarios /< scenar io name >/ vsimrti / s im ru n_ co nf i g .xml
Listing 10.2: VSimRTI VSimRTIEmbeddedStarter simulation runner start command for GNU/Linux.
Microsoft Windows
simr un . bat -c \ s cenarios \ < sc enario name >\ vsimr ti \ s im ru n_config . xml - p ⤦
Çnumberofparallelsimulations
Listing 10.3: VSimRTI simulation runner start command for Microsoft Windows.
Microsoft Windows
java - jar V s i m r t i E m b e d d e d St ar te r -x. x . x. jar -u userid -s -- strict - c o nfigurati o n - path - c ⤦
Çscenarios \< scenar io name >\ vsimrti \ s im ru n_ co nf i g .xml
Listing 10.4: VSimRTI VSimRTIEmbeddedStarter simulation runner start command for Microsoft Windows.
10 Run simulation series 10.1 Simulation Runner
Configuration file
The configuration file
vsimrti/scenarios/<scenarioName>/vsimrti/simrun_config.xml
con-
tains the parameterization information.
10.1.2 Configuration
The example in listing 10.5 shows a complete configuration. Using this configuration the simulation-
runner would try to run a scenario called Barnim while adapting the mapping (see 3.5.15), the configura-
tion file of
SNS
, and
VSimRTI
(see 8.3) configuration files. The actual simulation is triggered by generating
an adapted scenario folder and calling the same executable the user would normally trigger himself.
1 < ? xml versi on = " 1.0 " encoding =" UT F - 8 " ? >
2 <configuration
3 xmlns:xsi =" h tt p: // w ww . w 3 . or g / 20 01/ X ML Sc he ma - i nstan c e "
4 xsi:noNamespaceSchemaLocation=" htt p: // www . d caiti .tu - b erlin . de / re se ar ch / s im ul ation / downloa d /⤦
Çget / scenarios / scenarioname / vsimr ti / s im ru n_c on fi g .xsd " >
5<!- - basic conf i g u r a t i on - - >
6 < vs im rti l oc at ion = " / pa th / t o / v sim rt i _f o ld e r " e xe cu table = " vsi m rt i . sh " username ="user_id" / >
7 < sc en ario nam e = "Barnim" config=" s ce narios / B ar ni m / vsimr ti / v simr ti _c o nf ig . xml " persistent ="⤦
Çfal se " repetitions = "1">
8<!- - argu ment > -o TRACE </ argument -->
9<! - - ar gu ment > - w 0 </ a r gu me n t - ->
10 </ scenario >
11
12 <!- - d efine connected v alues for c o n t r o l l e d cha n g e s -->
13 < di me nsion nam e = "PenetrationRates">
14 < parameter nam e = "V2XVehiclePercentage" file=" m ap pi ng 3 / m ap pi ng_c on fi g . jso n " fileFormat ="⤦
Çjson" item=" v eh ic le s [0]. types [0]. w eight " type=" V al ue L is t " >
15 < value > 0.0 </ value >
16 < value > 0.5 </ value >
17 < value > 0. 75 </ value >
18 </ paramete r >
19 < parameter nam e = "ClassicVehiclePercentage" file=" m ap pi ng 3 / m ap pi ng_co nf ig . j so n " ⤦
ÇfileFormat =" json " item=" v eh ic le s [0] . typ es [1] . weigh t " type=" V alueList " >
20 < val ue > 1 </ v al ue >
21 < value > 0.5 </ value >
22 < value > 0. 25 </ value >
23 </ paramete r >
24 < parameter nam e = "Simulationtime" file=" vsimrti / vsimrti _c on fi g . xml " fileFormat =" xml " item⤦
Ç=" // s im ul at io n / endtime " type=" Value Li st " >
25 < value > 100 </ value >
26 < value > 100 </ value >
27 < value > 100 </ value >
28 </ paramete r >
29 </ dimension >
30
31 <!- - d efine values for a u t omatically p e r m u ted si m u l a ti on s - ->
32 < pa ra meter nam e = " Si ng le h op Ra d iu s " file=" sn s / sns_config . j son " f il eF ormat = " json " item="⤦
Çsinglehop . radi us " type=" V alueList " >
33 < val ue > 5 00 < / v al ue >
34 < val ue > 6 00 < / v al ue >
35 </ parameter >
36 </ con fig ur a ti o n >
Listing 10.5: Simulation Runner configuration example
The configuration contains three distinct parts of configuration. The system specific definition, the
scenario definition and the parametrization. While the first two parts will be explained as part of this
section, the parametrization will be explained in it’s own section.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 81
10 Run simulation series 10.1 Simulation Runner
system specific definition
1 < v si mrti locati o n =" / pa th / to / v s im r ti _ fo l de r " executable=" v sim r ti . sh "
2 u sername = "user_id" parallelSimulations="1" / >
Listing 10.6: example of system specific definition in configuration file
The system specific part of the configuration (see listing 10.6) is the only part of the configuration that
can be overwritten using a second configuration file. It contains the following values:
•location of the VSimRTI installation to use (can be relative or absolute).
•executable
used to start the simulation. This value is optional and will automatically be set to the
default *.bat or *.sh file when omitted.
•username
needed to check the license against. This is the user name given to you when registering
your system with us.
•parallelSimulations
defines how many simulations are started in parallel to speed up things.
This value is optional and defaults to 1. Be aware that you should only use this if you have multiple
cores available. This might also coincide with the threads option in the VSimRTI configuration.
scenario definition
1 < s ce nario nam e = "Barnim" config=" s ce nari os / B ar ni m / v si mr ti / v si mr ti _ co nfig . xml " persistent = " false ⤦
Ç"repetitions = "1">
2 < ! -- a rg um en t > -o T RA CE < / argument - - >
3 < ! --argument >-w 0</ a rg um ent -->
4 </ scenario >
Listing 10.7: example of scenario definition in configuration file
The scenario definition (see listing 10.7) contains everything needed to identify the scenario to execute
along with parameters that needs to passed to the
VSimRTI
executable. It contains the following values:
•name
of the simulation to run. This is expected to be the same as the scenarios folder name and
is used to automatically generate the path pointing to the scenarios
vsimrti_config.xml
in a
default case. It can be omitted if the config option is set.
•config
is an optional value containing the concrete path to the scenarios
vsimrti_config.xml
.
This can be used if the scenario is not placed in the default scenarios folder (which is discouraged)
and overwrites the path generated by the
name
attribute. Either
name
or
config
have to be defined!
•persistent
defines if the generated scenario folders (containing the adapted configuration files
for every single simulation to be executed) will be kept after simulation (value
true
) or deleted
(value false).
•repetitions
is an optional value containing the number of times each simulation should be
repeated. Setting this to a value other than
1
only makes sense if some part of the simulation follows
stochastic models (like non deterministic vehicle spawning).
The configuration can also contain a number of additional
argument
s that are passed to the executable
without any changes, separated by spaces.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 82
10 Run simulation series 10.1 Simulation Runner
10.1.3 Parametrization
The heart of this tool is the parametrization of simulations. Using this, one can define values in the
default configuration that are adapted between simulation runs. How many simulation runs are per-
formed is defined by the number of changes configured enriched with the information about simulation
repetitions.
For the example in listing 10.5 it is expected that the mapping file to be changed has one
vehicles
definition spawning multiple cars with a weighted
type
distribution defining first the equipped and then
the unequipped vehicles.
Parameters
1 < p ar a me te r nam e = "V2XVehiclePercentage" file=" m ap pi ng 3 / m ap pi ng_c on fi g . jso n "
2 fileFormat =" json " item=" v eh ic le s [0] . typ es [0] . weigh t " type=" V a lu eL i st " >
3 < v alu e > 0 </ v al ue >
4 < v alu e > 50 < / v al ue >
5 < v alu e > 75 < / v al ue >
6 </ parameter >
Listing 10.8: example of a parametrization for a single value
Each value that should be changed in a run is defined by a
parameter
element identified by a
name
(see listing 10.8). The base value is the
file
which should be changed (relative to the scenario folder).
Currently it is needed to define what
fileFormat
is expected from that file, which has impact on the
syntax of the
item
definition which denotes what part of this file should be changed (this will be explained
in a bit). The final value is the
type
which denotes how the value change behaves. The child elements
depend on this definition and will also be explained in a bit.
fileFormat can be one of xml or json. The item syntax is as followed:
•xml: contains an XPath1expression
•json
: contains an array-style definition of the target value. The value in listing 10.8 would change
line 13 in listing 10.9. (In the first entry of
vehicles
the attribute
weight
of the
types
first entry).
1 {
2" p ro totypes " :[{" n ame ":" PKW " }] ,
3" v ehicl e s " :[
4 {
5"startingTime": 5.0 ,
6"targetDensity":1200 ,
7"maxNumberVehicles": 250 ,
8" rou te " :"1",
9" t yp es " :[
10 {
11 "applications":[ " com . d ca it i . v si mr ti . a pp . W ea th erWa rn ingA pp . W e at herWa rn ingA pp " ],
12 " nam e ":" P KW " ,
13 " weig ht " :0.2
14 },
15 {
16 " nam e ":" P KW " ,
17 " weig ht " :0.8
18 }
1https://en.wikipedia.org/wiki/XPath
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 83
10 Run simulation series 10.1 Simulation Runner
19 ]
20 }
21 ]
22 }
Listing 10.9: mapping file expected for example
type can currently only have two entries:
•ValueList
: This expects a list of
value
s as child elements of the
parameter
. Each value will be
used for at least one permutation.
•IntegerGenerator
: This automatically generates integer values to write as values. The generated
numbers can be configured by adding these attributes to the parameter element:
–offset
denoting a minimal number where generation should start (this will be the first value),
default is 0.
–step
denoting the number that will be added to the previous value to generate the new one,
default is 1.
In contrast to ValueList this can create an infinite number of values.
Permutation of parameters
When multiple such
parameter
elements are defined, a permutation for each specific value definition is
generated. Lets say defined are parameters A and B and each parameter has values a and b. The resulting
permutations would be:
1 A = a , B = a
2 A = a , B = b
3 A = b , B = a
4 A = b , B = b
Dimensions
Sometimes it is wanted to group some value changes. This can be necessary when changed values need
to sum up to a specific value or when specific (named) output files need to be defined. This can be
done by enclosing the affected
parameter
s into a
dimension
definition. Doing this the values of each
parameter
are connected by their index. For this to work the number of values for each
parameter
have
to be the same. The example in listing 10.5 utilizes this function to make sure the vehicle percentages
sum up to 100. The generated permutations for the dimension enclosed parameters are:
1 V 2X V eh i cl e Pe r ce n ta g e =0 , C l as s icV eh i cl e Pe r ce n ta g e = 10 0
2 V 2X Ve hicl eP er cent ag e =50 , C la ssicV eh ic leP er centag e =50
3 V 2X Ve hicl eP er cent ag e =75 , C la ssicV eh ic leP er centag e =25
When additionally parameters are defined which are not enclosed in the
dimension
tag or another
dimension
tag is defined, then the permutations will be extended even further. The full permutation for
listing 10.5 is as follows:
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 84
10 Run simulation series 10.1 Simulation Runner
1 P en e tr a ti o nR at es ( V 2 XV e hi c le P er c en t ag e =0 , C l as s icV eh i cl e Pe r ce n ta g e = 10 0) , S in g le h op R ad i us = 50 0
2 P en e tr a ti o nR at es ( V 2 XV e hi c le P er c en t ag e =0 , C l as s icV eh i cl e Pe r ce n ta g e = 10 0) , S in g le h op R ad i us = 60 0
3 Pe ne tr ationRa te s ( V2 XV eh icle Pe rc enta ge =50 , Cl as sicVe hi clePer ce ntage =50 ) , Sing le ho pRadius =50 0
4 Pe ne tr ationRa te s ( V2 XV eh icle Pe rc enta ge =50 , Cl as sicVe hi clePer ce ntage =50 ) , Sing le ho pRadius =60 0
5 Pe ne tr ationRa te s ( V2 XV eh icle Pe rc enta ge =75 , Cl as sicVe hi clePer ce ntage =25 ) , Sing le ho pRadius =50 0
6 Pe ne tr ationRa te s ( V2 XV eh icle Pe rc enta ge =75 , Cl as sicVe hi clePer ce ntage =25 ) , Sing le ho pRadius =60 0
10.1.4 Additional Information
These are some side effects to remember when working with this tool.
Ports:
The Simulation Runner supports automatic assigning of free ports for federates. This means
that all federates configured in the
defaults.xml
will get a free port configured by default. This enables
multiple simulations to be run simultaneously as long as the federates are started by
VSimRTI
. If some
federates are not started through VSimRTI but are already running, this will not work.
Paths:
Relative paths of the files to be modified will be expanded with the deployment directory of the
current simulation run to an absolute one.
Adaptations:
All values will be modified in copies of the original scenario. The copies will be placed
in the
simrunner
folder in the
VSimRTI
base directory and will be (if not deactivated by configuration)
deleted upon completion of the simulation.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 85
11 Additional tools
11.1 scenario-convert
scenario-convert is a tool used to work with a scenarios database by importing and exporting data from
external sources like OpenStreetMap SUMO etc.
This database is the basis for all map-related tasks, which can be performed by
VSimRTI
(e.g. navigation,
route calculation...).
Based on a
VSimRTI
database, scenario-convert can export the data to
SUMO
input formats, which
then can be used in the simulation. To enable dynamic rerouting of vehicles, scenario-convert gen-
erates, exports and imports route data from and to
SUMO
. This way, one can choose, whether to use
generated routes (all possible routes between a point A and B), use existing routes and import them via
scenario-convert or build own routes via the route generation tools supplied with the standard
SUMO
installation.
Workflow
An example workflow to create a valid map database would be as follows:
• get OpenStreetMap file of the desired region
• import OpenStreetMap file and export to SUMO using scenario-convert
• create routes using existing tools or manually in sumo
• import created routes back into database using scenario-convert
•
start simulation using the database, which now contains all relevant map data and route informa-
tion
The example scenario-convert call for this workflow would be as follows in listing 1:
1 scenar i o c o n vert -- os m 2 s u m o -i < o smFile > - d < dbFile > - n -- expor t - traffic - l ights -- generate -⤦
Çrout e s -- route - begin - latl o n 50 . 4 2 9 9 9 7 ,8.6567009 -- route - end - l atlon 5 0 . 4 2 9024 ,8.6642044
Listing 11.1: Exemplary call of scenario-convert.jar .
(import OpenStreetMap file to database, generate routes by given coordinates, generate network with
sumo-netconvert and export to SUMO configuration files).
11 Additional tools 11.1 scenario-convert
Usage
The following listing 2 provides an overview about the scenario-convert functions.
1 U sage : sce nario - convert [ O PERATION ] -d < DA TABASEFI LE > [ OPTION S ]*
2
3 Examples ( options in [] are optional ) :
4 1. Im p ort an osm file and w rite data i nto database
5 scenario - conve r t -- osm2d b -i < OS MFILE > [-o ] [ - d < D ATABASE >]
6 2. Ex p ort db c o n t ent to sumo - readable fi les
7 scenario - conve r t -- db2sumo - d < DA TABASE > [-s < S UMOPRE FIX >] [-n]
8 3. Reimport a sumo r o u t e f i l e i nto a data b a s e
9 scenario - conve r t -- sumo2db - d < DA TABASE > -r <ROUTEFILE >
10 4. Combine steps 1 and 2
11 scenario - conve r t -- osm2sumo - d < DATABAS E > -i <OSMFILE > [-s < SU MOPREF IX >]
12 5. Ex p ort db c o n t ent to Shapefile format
13 scenario - convert -- d b 2shp -d < DATABAS E >
14 6. Im p ort an srtm file and write el e v a t i o n data to nodes of an e x i sting d a t a b a se
15 s ce na ri o - c o nv e rt - - s rt m 2d b - i < S RT MF IL E > - d < D AT AB AS E >
16
17 -------------------------------------------------------------------------------
18
19 C ON FI GURATION F ILE :
20 -c , - - con fi g - f il e F IL E Opt io na l , r ef er s t o a c on f i gu r at i on fi le w hi c h
21 contains all parameters in JSON fo rmat . S in gle
22 optio n s can be set by the f o l l o w i n g parameters .
23
24 OPERATIONS :
25 - - os m2 db - i [ -o ] [ - d] I mp or ts an OSM f il e c re atin g a n ew d at ab as e .
26 -- srtm2d b - i [- d ] Imports an SRT M file creating a new database .
27 -- db2sum o - d [ - s] [-n ] [ - l] Expor t s the networ k to S UMO node and edge fi les .
28 -- sumo2d b [ - i ] [- r -d ] I mports a SU MO Network / Routefile . Be awar e that
29 you ha ve to re - expo rt an i mp or te d netwo rk !
30 - - os m2 su mo Combination of o sm 2db and d b2 su mo .
31 -- db2s h p -d E x p orts the n e twork into S h a p e f i l e fo r mat .
32 -- osm2sh p -d Co m b i na ti o n of osm2 d b and d b 2 shp .
33 -- srtm2d b - i -d Impor t s an SR TM file and write s elev a t i o n data
34 to n od es .
35
36 -- upda t e -d U p d ates the given database to the curre n t sc heme .
37
38
39 CONFI GU RA TI ON OPTI ON S :
40 -i, --input - file FILE Defin e s an inpu t file to use in an import .
41 File typ e is de p e n d e n d on the impor t operat i o n .
42 ( OS M File / D ata base fi le / SUMO n et fi le )
43 -d , -- d at abas e F IL E Whe n i mp orting : f il e t o i mp or t t o . Eit h er o mi t
44 the f ile extension or set it to ’.db ’.
45 For expor t operations : file to load f rom .
46 For upd at e o perations : file to u pd ate .
47 -s , -- sum o - p re fix S UM OPREFIX P re fix f or t he g en e ra ted sum o fi les
48 ( uses database name wh en not defined ) .
49 - - im po rt - z on e UT M z on e o f l oca t io n for p r oj e ct i ng co o rd s i n
50 d ef au l t f orm a t ( e . g. 3 2 n) .
51 - - imp ort - l on / -- i mpor t - la t c en ter longitu de / l ati tude o f i mp or ted reg io n
52 to p roject c oo rd in at es .
53 ATTENTION : Zone and c o o r d i n a t e parameters are
54 mutually exclusive a l ter n ati v es !
55 - r , - - ro ut e - f il e F I LE S um o * . ro u . x ml f il e l oc a ti o n
56 - - ex po rt - r out e s Ex por t e xis t in g r ou te d at a t o *. r ou . x ml
57 ( onl y in c ombination with d b2 su mo ) .
58 -f , -- for ce Fo rc e o ve r wr ite o f e xist i ng fi le s
59 ( do not i n cr ement fil e na mes ) .
60
61
62 INTERN A L R OUTE GENERATION
63 (If you use this , a rou t e file containing the se routes wi ll be generated too )
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 87
11 Additional tools 11.1 scenario-convert
64 -g , -- ge ne ra te - r o ut es Gener a te ro ute s b as ed on t he g iv en o p ti on s .
65 Ple a s e see be low for p o s sible options ,
66 You will at l east need start and end coordinates
67 S ta rt of route :
68 -- route - begin - lat Latitude of point , needs longit u d e defi n e d !
69 -- route - begin - lon Longitude of point , n eeds latitude defined !
70 -- route - begin - latl o n Combined va lue in format [ latitude ] ,[ longitude ]
71 ( thi s is an a lt ernative to s ep ar at e d ef in it ion !)
72 - - rout e - b eg in - no de - id O SM n od e id as s ta rt p oi nt
73 ( thi s is an a lt ernative to the o pt io ns ab ov e !)
74 End of r oute :
75 -- route - end -lat Latitude of point , needs lo n g i t u d e def i n e d !
76 -- route - end -lon Longitude of point , n eeds latitude defined !
77 - - ro ut e - e nd - l a tl on C om b in e d v al ue i n f or m at [ l a t it u de ] ,[ l o n gi t ud e ]
78 ( thi s is an a lt ernative to s ep ar at e d ef in it ion !)
79 - - rout e - end - no de - id O SM n od e id as s ta rt p oin t
80 ( thi s is an a lt ernative to the o pt io ns ab ov e !)
81
82 -- number - of - rout e s INT Option al , limits the maximu m nu m ber of g enerated
83 rou te s . Defa ul t is 1.
84
85 ADDITIONAL TOOL S
86 -o , -- ex ec ut e - o smos i s Exe c ut e o sm os i s to a pp ly a ut o ma ti c f i lt er s t o
87 the giv en osm f ile (only for osm2xx x ) .
88 -b , - - imp or t - b u il d in g s Wr ite o sm b u il din g i n fo r ma t io n in d a ta b as e
89 -- ignore - turn - restrictions Ignore all defined turn res t r i c t i o n s on OSM impo r t .
90 - - di sa bl e - gr aph - c lean u p Tu rn s of f t he r em ova l of u n co nnect ed p art s fr om t he
91 m ain traf f i c n e twork grap h . Since seve r a l c o m p o n e n t s of
92 VSimR T I re q u ire one main graph wi t h out di s c o nnected ways
93 and nodes , thi s o p tion s h ould be u sed only if the
94 clean up proced ure is faul ty .
95 -n , -- ex ec ut e - n e tc o nv er t A ut o ma t ic a ll y s ta rt su mo n e tc o nv e rt a fte r e xp or t
96 to c re at e n et fi le ( only w ith xxx2sumo )
97 -l , - - exp or t - t ra ff ic - l ig ht s e x po rt tr a ff ic l ig ht i n fo r ma t io n f or n od es
98 - -osm - spe eds - f ile Defi ne a p ropert y fil e wh ic h contains sp ee d i nf or mation
99 w h ich are used to set the spe ed for OSM ways without a
100 m ax spee d t ag . ( o nl y with o sm2x xx )
101 -- osm - speeds - o v e r w r i t e If set to true , the m a x s peed tags of ways are i gnored and
102 replaced by eith e r de fault values , or by s peed info r m a t i o n
103 defin ed via t he --osm - speeds - file o pt io n . ( only w ith o sm 2x xx )
104 -l , - - exp or t - t ra ff ic - l ig ht s e x po rt tr a ff ic l ig ht i n fo r ma t ion fo r n ode s
105 -v , -- v er si o n P ri nt c u rr en t v er s io n num b er
Listing 11.2: Overview about scenario-convert options.
The following listing 3 shows a JSON example file which can be used with the
-c
option of scenario-
convert.
1 {
2"operating_mode":" o sm2db " ,
3
4" input_path ":" p at h / to / i np ut . o sm " ,
5"database_path":" p at h / to / d a ta ba s e . db " ,
6
7" sumo_prefix " :" S UM O_P RE FIX " ,
8
9"execute_netconvert": true ,
10 "export_traffic_lights": true ,
11 "export_routes": true ,
12 "import_buildings": false ,
13 " force_ o ve r wr it e ": false ,
14 "disable_graph_cleanup": false ,
15 "ignore_turn_restrictions": false ,
16
17 " genera t e_ r ou te s ": true ,
18 "number_of_routes": 2 ,
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 88
11 Additional tools 11.1 scenario-convert
19 " route_ b eg i n_ la t ": 52.5 ,
20 " route_ b eg i n_ lo n ": 13.4 ,
21 "route_end_lat": 52.2 ,
22 "route_end_lon": 13.1 ,
23
24 "osm_overwrite_speeds": false ,
25 " osm_sp e ed s _f il e ":" p at h / to / s p ee ds . p r op er t ie s "
26 }
Listing 11.3: Example file for scenario-convert configuration with JSON
Furthermore, in listing 4 you can find a properties file which can be used during the import of OSM data
in order to define speeds for ways, which do not have a maxspeeds-tag defined. For this purpose use the
option
- -osm-speeds-file <FILE>
. In the speed properties file, for each way type a speed value can
be defined, according to the OSM highway key 1.
1# the u nit the speed va l ues are de fined in [kmh , ms ]
2 sp ee d . unit = kmh
3
4# the defaul t speed for all way types wh ich are not defined here
5 sp ee d . de fault = 30
6
7# autobahn
8 high wa y . mo to rway = 130
9 high wa y . mo to rway_link = 70
10
11 # b un desstrasse ( g er ma ny )
12 high wa y . tr unk = 70
13 high wa y . tr un k_ li nk = 65
14
15 # linki n g bi g ger town
16 high wa y . pr imary = 65
17 high wa y . pr im ar y_link = 60
18
19 # linking to wns + villages
20 high wa y . se co nd ar y = 60
21 high wa y . se co ndary_lin k = 50
22
23 # stree ts wi th ou t m iddle lin e s ep ar at io n
24 high wa y . te rtiary = 50
25 high wa y . te rt ia ry _link = 40
26 high wa y . re si de nt ia l = 30
27
28 # speci al ro ads
29 high wa y . li vi ng _s treet = 5
30 high wa y . se rvice = 20
31
32 # unclassified roads
33 high wa y . un cl as si fi ed = 30
34 high wa y . ro ad = 2 0
35
36 # forest tracks
37 high wa y . tr ac k 15
Listing 11.4: Example file which can be used to configure speeds for ways during OSM import
1http://wiki.openstreetmap.org/wiki/Key:highway
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 89
12 VSimRTI configuration
12.1 Overview
VSimRTI
can be configured by adapting the files in the
/vsimrti/etc
directory. The following technical
aspects of VSimRTI can be configured:
•vsimrti/etc/defaults.xml - Configuration of all federates which are coupled with VSimRTI.
•vsimrti/etc/hosts.json - Configuration of the machines the simulations are executed on.
•vsimrti/etc/logback.xml - Logging configuration of VSimRTI and its federates.
A full example of the default configuration files can be found in A.2.
12.2 Federates configuration
This part of software can be configured with a configuration file. The specific path is
vsimrti/etc/defaults.xml
This file is used for configuring all federates and simulators coupled with
VSimRTI. For each federate you can define various aspects:
• What’s the id and class of the federate?
• On which host is the federate running?
• How is the federate started?
• What is the name of the configuration file for the federate?
• For which messages is the federate subscribing?
• The priority of the federate when it comes to message distribution.
A detailed description of the various parameters can be found in the documentation available on the
DCAITI website .
12 VSimRTI configuration 12.3 Host configuration
12.2.1 Federate priorities
There might be cases where it is important that a certain federate receives messages with equal times-
tamps before or after the other ones. In the context of VSimRTI for example, it is often desirable that
the Application Simulator receives the vehicle movements-message after the traffic simulator to avoid
problematic behavior in the first simulator. The configuration file
defaults.xml
allows for a fine grained
adjustment of the federate priorities.
For example, a federate with a certain priority looks like this:
<federate
class="com.dcaiti.vsimrti.fed.sumo.ambassador.SumoAmbassador" priority="20">
. That
means that the Sumo Ambassador has an priority of 20, where the following rules apply to the priorities:
• Priorities range from 0 to 100.
• 0 is the highest priority, e.g. the federate with this priority assigned will receive the message first.
• The default priority if none is given is 50.
Note that VSimRTI ships with sane default values for the priority and a modification is only necessary in
rare cases.
12.3 Host configuration
This part of software can be configured with a configuration file. The specific path is
vsimrti/etc/hosts.json
Notice:
The documentation for the VSimRTI specific component is freely available on
the DCAITI website , explaining all available options.
This file is used for configuring simulation runs using multiple machines. Under normal circumstances it
is not necessary to change this file.
In
VSimRTI
there are two kinds of hosts: local and remote hosts. All hosts have to be identified with a
unique string that is valid for the remainder of the configuration to reference a defined host.
For a local host additionally the operating system and a name of a directory that is used to deploy needed
federates is necessary. Values for operating systems are "linux" or "windows".
The syntax for referenced paths has to be chosen according to operating system standards (e.g. /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.
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 91
13 Additional information
Here you find helpful information regarding VSimRTI and its configuration.
13.1 PATH configuration
PATH is an environment variable on operating systems, specifying a set of directories where executable
programs are located.
GNU/Linux
On GNU/Linux operating system you can edit you local .bash_profile in your home directory with your
favorite CLI editor e.g. Vi IMproved (VIM) or Nano’s ANOther editor (NANO).
1# .bash_profile
2
3# Get the a l iases and f u n c t i o ns
4 if [ -f ~/. bashrc ]; t hen
5 . ~/. bashrc
6 fi
7
8# User s p e cific e nv ir on m en t and s tartup p r ograms
9
10 PA TH = $PAT H : $H OME / bin : $HO ME / s umo /
11
12 exp o rt PATH
Listing 13.1: Add the SUMO location to PATH on GNU/Linux.
On most GNU/Linuxdistibutions you must log out and login to refresh the PATH variable. You can check
your path with the shell command echo $PATH .
13 Additional information 13.1 PATH configuration
Microsoft Windows
For Microsoft Windows please follow the instructions below.
1. Select “Computer” from the start menu. Choose “Properties” from the context menu.
2. Click “Advanced system settings” and switch to the “Advanced” tab in “System Properties”.
3. Click on “Environment Variables”.
4. Find “Path”, and click on it (choose it).
5. Click “Edit”.
6. Modify Path by adding the absolute location to the value for Path.
(Don’t forget a semicolon to seperate).
7. Click “OK”, click “OK”, click “OK”, . . . .
1
2
3
4
5
6
7
8
Figure 13.1: Edit PATH variable in Microsoft Windows
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 93
14 List of Acronyms
ASCT Automotive Services and Communication Technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
CAM CooperativeAwarenessMessages........................................................10
CLI CommandLineInterface..................................................................4
CPU centralprocessingunit.....................................................................2
DCAITI Daimler Center for Automotive Information Technology Innovations . . . . . . . . . . . . . . . . . . . . 2
DENM Decentralized Environmental Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
ETC EstimatedTimetoCompletion............................................................6
ETSI European Telecommunications Standards Institute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
EPL Eclipse Public License
FOKUS Fraunhofer-Institut für Offene Kommunikationssysteme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
GUI GraphicalUserInterface..................................................................23
GNU GNU’s Not Unix!
GPL GNU General Public License
HLA High-LevelArchitecture....................................................................1
IEEE Institute of Electrical and Electronics Engineers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
INET OMNeT++ - Model library for wired, wireless and mobile networks . . . . . . . . . . . . . . . . . . . . . 12
ITEF Integrated Test and Evaluation Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
JAR JavaArchive................................................................................1
JRE JavaRuntimeEnvironment................................................................1
JSON JavaScriptObjectNotation...............................................................33
LTE LongTermEvolution.....................................................................10
LuST LuxembourgSUMOTraffic...............................................................64
M&S modellingandsimulation.................................................................1
MAC MediaAccessControl......................................................................2
MBMS Multimedia Broadcast Multicast Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
NANO Nano’sANOthereditor....................................................................92
ns-2 networksimulator2......................................................................16
ns-3 networksimulator3........................................................................9
OMNeT++ Objective Modular Network Testbed in C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
OSM Open Street Map
RAM random-accessmemory...................................................................2
RSU RoadSideUnits...........................................................................28
RTF RealTimeFactor...........................................................................6
SNS SimpleNetworkSimulator.................................................................9
SUMO SimulationofUrbanMobility..............................................................9
TraCI TrafficControlInterface..................................................................32
UMTS Universal Mobile Telecommunications System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
14 List of Acronyms 14 List of Acronyms
UUID universallyuniqueidentifier.............................................................32
V2V Vehicle-to-Vehicle........................................................................10
V2X Vehicle-2-X.................................................................................2
VIM ViIMproved...............................................................................92
VSimRTI Vehicle-2-X Simulation Runtime Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
XML ExtensibleMarkupLanguage.............................................................33
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 95
Appendix A
VSimRTI deployment
You will find a collection of all relevant data.
A.1 VSimRTI Folder Structure
The
VSimRTI
all-in-one package has a clear separation of binary files, general
VSimRTI
configuration
files and simulation scenario specific configuration files in different folders. The
vsimrti/bin
folder
contains all binary files needed for execution of
VSimRTI
. Normally, you do not have to make changes
here.
General
VSimRTI
configuration files, which are used through all scenarios can be found in the
vsimrti/etc folder.
These files contain information about how simulators interact, which remote hosts exists etc.. If you
only want to perform simulations using the preconfigured simulators in the all-in-one package you do
not need to make changes here. In the
vsimrti/scenarios
folder you can find the scenario specific
configuration files, separated by component, e.g. traffic simulator or communication simulator.
This configuration can be changed in the file vsimrti/etc/defaults.xml (see A.1).
For normal usage of
VSimRTI
, this configuration does not need to be changed. Please edit this file only, if
you know what you are doing, as unwanted side effects might occur.
The configuration of
VSimRTI
ambassadors is done by using configuration files in the folder
vsimrti/scenarios/<scenarioName>/<federateid> .
To configure scenario specific
VSimRTI
options, e.g. to define which sim-
ulators should be active in a simulation scenario, you can adjust the
vsimrti/scenarios/<scenarioName>/vsimrti/vsimrti_config.xml
file located in
vsimrti/scenarios/<scenarioName>/vsimrti . The overall folder structure is as follows:
Appendix A VSimRTI deployment A.1 VSimRTI Folder Structure
vsimrti
bin ........................................................ path containing binary files
etc .......................................... path containing general configuration files
defaults.xml ............................................................ (see A.1)
hosts.json .............................................................. (see A.2)
logback.xml ............................................................. (see A.3)
lib ................................... path containing system specific (non JAR) libraries
logs .............................................................. path for all log files
scenarios .................................. path for scenario specific configuration files
Barnim .................................... path containing Barnim example scenario
Tiergarten ............................. path containing Tiergarten example scenario
tmp ......................................... path for temporary files during a simulation
simrun.sh ........................................ shell script to start a simulation series
simrun.bat ...................................... batch script to start a simulation series
systeminfo.txt ............................................................. (see A.4)
vsimrti.sh ...................................... shell script to start a single simulation
vsimrti.bat ..................................... batch script to start a single simulation
vsimrti.dat ...................................................... VSimRTI license file
vsimrti-license.lcs ............................................. VSimRTI license file
Figure A.1: VSimRTI folder structure
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 97
Appendix A VSimRTI deployment A.2 File listings
A.2 File listings
etc/defaults.xml
1 < ? xml versi on = " 1.0 " encoding =" UT F - 8 " ? >
2<!- - fi le version: 201 3 -04 -13 -->
3 < c onfigur at io n x ml ns:xsi = " ht t p: / / ww w . w3 . o rg / 2 00 1/ X ML Sc he ma - i n st ance "
4 xsi:noNamespaceSchemaLocation=" htt p: // www . d caiti .tu - b erlin . de / re se ar ch /⤦
Çsimul at io n / d ow nloa d / get / e tc / d ef aul ts . xsd " >
5 < f ederates >
6 < f ed erate cl as s = " com . d ca it i . vsimr ti . fed . o mn et pp . a mbassador . O m ne tpp Am bass ad or " >
7 < id > om ne tp p </ id >
8 < d eploy > true </ deploy >
9 < start > tr ue </ start >
10 < host >local </ host >
11 < port >4998 < / port >
12 < d oc ke rIm ag e > </ d o ck er Imag e >
13 < config > o mn e t p p _c o n f i g . json </ co nfig >
14 < messages >
15 < m e s sage > Ad ded V e h i c l e < / message >
16 < m e s sage > Ad d edRsu </ me s s a ge >
17 < m e s sage > Ad de d Tr a f f ic L i gh t < / messag e >
18 < m e s sage > Ve hi c l eM o v e me n t s </ me s s a ge >
19 < m e s sage > Se nd V 2 X M es s a g e < / message >
20 < m es sa ge > C o nf i gu r eA d Ho c Com mu n ic a ti o n < / m es sa ge >
21 </ mess ag es >
22 </ federate >
23 < f ed erate cl as s = " com . d ca it i . vsimr ti . fed . n s3 . a mbassador . N s3A mb as s ad or " >
24 < id >ns3 < /id >
25 < d ep lo y > t ru e < / d ep lo y >
26 < start > tr ue </ start >
27 < host >local </ host >
28 < port >5011 < / port >
29 < d oc ke rIm ag e > </ d o ck er Imag e >
30 < config > n s 3 _ c o n f i g . json </ config >
31 < messages >
32 < m e s sage > Ad ded V e h i c l e < / message >
33 < m e s sage > Ad d edRsu </ me s s a ge >
34 < m e s sage > Ad de d Tr a f f ic L i gh t < / messag e >
35 < m e s sage > Ve hi c l eM o v e me n t s </ me s s a ge >
36 < m e s sage > Se nd V 2 X M es s a g e < / message >
37 < m es sa ge > C o nf i gu r eA d Ho c Com mu n ic a ti o n < / m es sa ge >
38 </ mess ag es >
39 </ federate >
40 < f ed erate cl as s = " com . d ca it i . vsimr ti . fed . s ns . a mbassador . S nsA mb as s ad or " >
41 < id >sns < /id >
42 < d ep lo y > f al se < / d ep lo y >
43 < sta rt > f al se < / s ta rt >
44 < host >local </ host >
45 < config > s n s _ c o n f i g . json </ config >
46 < messages >
47 < m e s sage > Ad ded V e h i c l e < / message >
48 < m e s sage > Ad d edRsu </ me s s a ge >
49 < m e s sage > Ad de d Tr a f f ic L i gh t < / messag e >
50 < m e s sage > Ve hi c l eM o v e me n t s </ me s s a ge >
51 < m e s sage > Se nd V 2 X M es s a g e < / message >
52 < m es sa ge > C o nf i gu r eA d Ho c Com mu n ic a ti o n < / m es sa ge >
53 </ mess ag es >
54 </ federate >
55 < f ed erate cl as s = " com . d ca it i . vsimr ti . fed . s um o . ambassa do r . S um o Am bassa do r " >
56 < id > s um o < / id >
57 < d ep lo y > t ru e < / d ep lo y >
58 < start > tr ue </ start >
59 < host >local </ host >
60 < port >0 </ port >
61 < c on fi g > s u mo _conf ig . j so n < / con f ig >
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 98
Appendix A VSimRTI deployment A.2 File listings
62 < messages >
63 < m es sa ge > V e hi c le T yp e sI n it M es s ag e < / m es sa ge >
64 < m es sa ge > V e hi c le P at h sI n it M es s ag e < / m es sa ge >
65 < m e s sage > Ad ded V e h i c l e < / message >
66 < m es sa ge > S et M ax Speed < / m es sa g e >
67 < m e s sage > Sl o wDown </ me s s a ge >
68 < m e s sage > Pr op a ga t e N ew R o ut e < / messag e >
69 < m e s sage > Ch an g eS t a t ic R o ut e < / messag e >
70 < m es sa ge > C h an g eS t at i cR o ut e By E dg e < / m es sa ge >
71 < m e s sage > Ch a n g e L a n e < / message >
72 < m e s sage > ChangeT r a ff i cL i g ht s St a te < / messag e >
73 < m e s sage > Stop </ messa g e >
74 < m e s sage > Resume </ message >
75 < m e s sage > SumoTr a c i By t eA r ra y Me s s ag e </ me s s a ge >
76 < m e s sage > EnableD i s t an c e Se n so r s </ me s s age >
77 < m es sa ge > C h an g eV e hi c le P ar a me t er s < / m es sa ge >
78 < m es sa ge > C ha n ge Speed < / m es sa g e >
79 < m e s sage > Ve hi c l e C on t r o l < / message >
80 < m e s sage > Ve hi c l eM o v e me n t s </ me s s a ge >
81 </ mess ag es >
82 </ federate >
83 < f ed erate cl as s = " com . d ca it i . vsimr ti . fed . a ppl ic ationNT . a m ba ss ador .⤦
ÇApplicationNTAmbassador">
84 < id > a p pl i ca t io n NT < / id >
85 < d ep lo y > f al se < / d ep lo y >
86 < sta rt > f al se < / s ta rt >
87 < host >local </ host >
88 < port >0 </ port >
89 < c on fi g > a p pl i cat io n NT _ co n fig . j so n < / conf ig >
90 < messages >
91 < m e s sage > Ad d edRsu </ me s s a ge >
92 < m e s sage > AddedCha r g i ng S t at i on < / messag e >
93 < m e s sage > Ad de d Tr a f f ic L i gh t < / messag e >
94 < m e s sage > Ad ded V e h i c l e < / message >
95 < m e s sage > Applic a t i on S pe c if i cM e ss a ge < / message >
96 < m e s sage > ChangeVeh i c l eS t a te </ messa g e >
97 < m e s sage > Chargin g S t at i o nU p da t e </ me s s age >
98 < m e s sage > Ch ar g i ng R e j ec t e d </ me s s a ge >
99 <message>VehicleElectricInformationMessage</message>
100 < m e s sage > Pr op a ga t e N ew R o ut e < / messag e >
101 < m e s sage > Re ce i ve V 2 X Me s s ag e < / messag e >
102 < m e s sage > Receive F u l lV 2 X Me s sa g e </ me s s age >
103 < m e s sage > Acknowl e d g eV 2 X Me s sa g e </ me s s age >
104 < m e s sage > Se n s o r D a t a < / message >
105 < m e s sage > SumoT r a ci By t eA rr a yM es s ag eR e sp on s eC on t ai ne r </ mes s a ge >
106 < m e s sage > UpdateTra f f i cL i g ht </ messa g e >
107 < m e s sage > Ve hi c l eM o v e me n t s </ me s s a ge >
108 < m es sa ge > V e hi c le P at h sI n it M es s ag e < / m es sa ge >
109 < m es sa ge > V e hi c le T yp e sI n it M es s ag e < / m es sa ge >
110 </ mess ag es >
111 </ federate >
112 < f ed erate cl as s = " com . d ca it i . vsi mrti . f ed . e ventserve r . ambassador . E ve nt ser ve rAm ba ssa do r " >
113 < id > ev entserver < /id >
114 < d ep lo y > f al se < / d ep lo y >
115 < sta rt > f al se < / s ta rt >
116 < host >local </ host >
117 < c on fi g > e v en t se r ver _c o nf i g . j so n </ c on fi g >
118 < messages >
119 < m e s sage > SensorReg i s t ra t i on </ messa g e >
120 < m e s sage > Ve hi c l eM o v e me n t s </ me s s a ge >
121 </ mess ag es >
122 </ federate >
123 < f ed erate cl as s = " com . d ca it i . vsi mrti . f ed . m ap ping3 . M app in gAmb as sador " >
124 < id > m a pp in g 3 < / id >
125 < d ep lo y > f al se < / d ep lo y >
126 < sta rt > f al se < / s ta rt >
127 < host >local </ host >
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 99
Appendix A VSimRTI deployment A.2 File listings
128 < config > m ap p i n g _c o n f i g . json </ co nfig >
129 < messages >
130 < m es sa ge > V e hi c le P at h sI n it M es s ag e < / m es sa ge >
131 < m e s sage > Scenari o T r af f i cL i gh t s </ me s s age >
132 < m e s sage > Scenario A d d ed V e hi c le < / messag e >
133 </ mess ag es >
134 </ federate >
135 < f ed erate cl as s = " com . d ca it i . vsi mrti . f ed . c el l2 . a mbassador . C ell 2A mb a ss ador " >
136 < id > c el l 2 < / id >
137 < d ep lo y > f al se < / d ep lo y >
138 < sta rt > f al se < / s ta rt >
139 < host >local </ host >
140 < c on fi g > c e ll 2 _c onfi g . jso n < / conf ig >
141 < messages >
142 < m e s sage > Ad ded V e h i c l e < / message >
143 < m e s sage > Ad d edRsu </ me s s a ge >
144 < m e s sage > Ad de d Tr a f f ic L i gh t < / messag e >
145 < m e s sage > AddedCha r g i ng S t at i on < / messag e >
146 < m e s sage > Ve hi c l eM o v e me n t s </ me s s a ge >
147 < m e s sage > Se nd V 2 X M es s a g e < / message >
148 < m e s sage > Config u r e Ce l lC o mm u ni c at i on < / message >
149 </ mess ag es >
150 </ federate >
151 < f ed erate cl as s = " com . d ca it i . vsi mrti . f ed . b at te ry . a mb assador . B atte ry Amba ss ador " >
152 < id > ba tt er y </ id >
153 < d ep lo y > f al se < / d ep lo y >
154 < sta rt > f al se < / s ta rt >
155 < host >local </ host >
156 < config > b at t e r y _c o n f i g . json </ co nfig >
157 < messages >
158 < m e s sage > Ad ded V e h i c l e < / message >
159 < m e s sage > Ve hi c l eM o v e me n t s </ me s s a ge >
160 < m es sa ge > C har gi ngS ta rt ed </ m es sa ge >
161 < m es sa ge > C har gi ngS to pp ed </ m es sa ge >
162 </ mess ag es >
163 </ federate >
164 < f ed erate cl as s = " com . d ca it i . vsi mrti . f ed . c ha rg ingst at io n . a mbassador .⤦
ÇChargingStationAmbassador">
165 < id > ch argin gs ta tion < /id >
166 < d ep lo y > f al se < / d ep lo y >
167 < sta rt > f al se < / s ta rt >
168 < host >local </ host >
169 < c on fi g > c h ar g in gs t at i on _ co nf i g . j so n </ c on fi g >
170 < messages >
171 < m e s sage > AddedCha r g i ng S t at i on < / messag e >
172 < m e s sage > Ch ar g e R e q ues t </ messa g e >
173 < m e s sage > St op C ha r g e Re q u es t < / messag e >
174 < m e s sage > Chargin g S t at i o nU p da t e </ me s s age >
175 </ mess ag es >
176 </ federate >
177 < f ed erate cl as s = " com . d ca it i . vsi mrti . f ed . v is ua l . V isu al iza ti on Am bas sa do r " >
178 < d ep lo y > f al se < / d ep lo y >
179 < sta rt > f al se < / s ta rt >
180 < id > vi su alizer < /id >
181 < host >local </ host >
182 < port >5099 < / port >
183 < u pd at e > 1 </ u p da te >
184 < c on fi g > v i su a li z er _ co n fig . x ml < / con f ig >
185 < messages >
186 < m es sa ge > V e hi c le T yp e sI n it M es s ag e < / m es sa ge >
187 < m es sa ge > V e hi c le P at h sI n it M es s ag e < / m es sa ge >
188 < m e s sage > Ad ded V e h i c l e < / message >
189 < m e s sage > Ad d edRsu </ me s s a ge >
190 < m e s sage > Ad de d Tr a f f ic L i gh t < / messag e >
191 < m e s sage > AddedCha r g i ng S t at i on < / messag e >
192 < m e s sage > Ve hi c l eM o v e me n t s </ me s s a ge >
193 < m e s sage > Se n s o r D a t a < / message >
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 100
Appendix A VSimRTI deployment A.2 File listings
194 <message>VehicleElectricInformationMessage</message>
195 < m e s sage > UpdateTra f f i cL i g ht </ messa g e >
196 < m e s sage > Chargin g S t at i o nU p da t e </ me s s age >
197 < m es sa ge > S et M ax Speed < / m es sa g e >
198 < m e s sage > Sl o wDown </ me s s a ge >
199 < m es sa ge > C ha n ge Route < / m es sa g e >
200 < m e s sage > Ch an g eS t a t ic R o ut e < / messag e >
201 < m e s sage > Ch a n g e L a n e < / message >
202 < m e s sage > ChangeT r a ff i cL i g ht s St a te < / messag e >
203 < m e s sage > Applica t i o nI t ef M e ss a ge < / messag e >
204 < m e s sage > Se nd V 2 X M es s a g e < / message >
205 < m e s sage > Re ce i ve V 2 X Me s s ag e < / messag e >
206 < m e s sage > De le t e V2 X M e ss a g e </ me s s a ge >
207 </ mess ag es >
208 </ federate >
209 < f ed erate cl as s = " com . d ca it i . vsi mrti . f ed . p ha bmacs . a mb assador . P h ab mac sA mbas sa dor " >
210 < id > p h ab ma c s < / id >
211 < d ep lo y > t ru e < / d ep lo y >
212 < start > tr ue </ start >
213 < host >local </ host >
214 < port >50423 </ port >
215 < c on fi g > p h ab m ac s _c o nf i g . j so n </ c on fi g >
216 < javaMemor y S i z eX m s > 100 </ javaMemo r y S i z eX m s >
217 < javaMemor y S i z eX m x > 4086 </ javaMe m o r y SizeXmx >
218
219 <!- - Add c u stom c l a sspath e n t r ies to avoid copying jar f iles manually -->
220 <! -- Bas e d ir i s " t oo ls / V si mr ti Em bed de dSt ar te r / tm p / ph abm acs " - ->
221
222 <!- -
223 < j av aC lasspathEntries >
224 < class path > .. /. ./ ../../ federates / phabma cs / phab macs - f ederate / tar ge t/ classe s </⤦
Çclasspath >
225 </ javaClasspathEntries >
226 -->
227
228 <!- - Add c u stom J a v a A r g u ment f or debugging -->
229 <! -- < customJava Ar gum en t >- Xdeb ug - X ru nj dwp:tr an sp ort = dt_socket \ , server =y\ , su sp end = n⤦
Ç\, address =808 6 </ c us to mJ av aA rg um en t > - ->
230 < messages >
231 < m es sa ge > V e hi c le T yp e sI n it M es s ag e < / m es sa ge >
232 < m es sa ge > V e hi c le P at h sI n it M es s ag e < / m es sa ge >
233 < m e s sage > Ad ded V e h i c l e < / message >
234 < m e s sage > Ad d edRsu </ me s s a ge >
235 < m es sa ge > C ha n ge Speed < / m es sa g e >
236 < m es sa ge > S etA cc ele ra ti on </ m es sa ge >
237 < m es sa ge > S et M ax Speed < / m es sa g e >
238 < m e s sage > Sl o wDown </ me s s a ge >
239 < m e s sage > Ch an g eS t a t ic R o ut e < / messag e >
240 < m es sa ge > C h an g eS t at i cR o ut e By E dg e < / m es sa ge >
241 < m e s sage > Ch a n g e L a n e < / message >
242 < m e s sage > Stop </ messa g e >
243 < m e s sage > Resume </ message >
244 < m e s sage > ChangeT r a ff i cL i g ht s St a te < / messag e >
245 < m e s sage > Pr op a ga t e N ew R o ut e < / messag e >
246 < m e s sage > Se tAc t u a t o r s < / message >
247 < m e s sage > Se nd V 2 X M es s a g e < / message >
248 < m e s sage > Re ce i ve V 2 X Me s s ag e < / messag e >
249 < m e s sage > Cu rr e n t E v ent s </ messa g e >
250 < m e s sage > Ve hi c l e C on t r o l < / message >
251 < m e s sage > Ve hi c l eM o v e me n t s </ me s s a ge >
252 </ mess ag es >
253 </ federate >
254 < f ed erate cl as s = " com . d ca it i . vsi mrti . f ed . p ha sc a . a mb assador . P has ca Ambas sa dor " >
255 < id > ph asca < /id >
256 < d ep lo y > t ru e < / d ep lo y >
257 < sta rt > f al se < / s ta rt >
258 < host >local </ host >
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 101
Appendix A VSimRTI deployment A.2 File listings
259 < c on fi g > p h as c a_ c on fig . j so n < / conf ig >
260 < messages >
261 < m e s sage > Ad ded V e h i c l e < / message >
262 </ mess ag es >
263 </ federate >
264 < / fe derates >
265 </ con fig ur a ti o n >
Listing A.1: VSimRTI: file listing: etc/defaults.xml
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 102
Appendix A VSimRTI deployment A.2 File listings
etc/hosts.json
1 {
2" localHosts " : [
3 {
4" id " :" loca l ",
5"workingDirectory" :" ./ tm p " ,
6"address" :" localhost " ,
7" operati ng S ys te m " :" l in ux "
8 }
9 ],
10 " remoteHosts " : [
11 {
12 " id " :"remote",
13 "workingDirectory" :" / ho me / v si mr ti / t est / tmp " ,
14 "address" :" 1 92.1 68 .0.1 " ,
15 " operati ng S ys te m " :" l in ux " ,
16 " use r " :" usernam e ",
17 " password " :" password " ,
18 " por t " : 22
19 }
20 ]
21 }
Listing A.2: VSimRTI: file listing: etc/hosts.json
etc/logback.xml
1 < ? xml versi on = " 1.0 " encoding =" UT F - 8 " ? >
2<!- - fi le version: 201 3 -04 -05 -->
3 < c onfigur at io n x ml ns:xsi = " ht t p: / / ww w . w3 . o rg / 2 00 1/ X ML Sc he ma - i n st ance "
4 xsi:noNamespaceSchemaLocation=" htt p: // www . d caiti .tu - b erlin . de / re se ar ch /⤦
Çsimul at io n / d ow nloa d / get / e tc / l og ba ck . x sd " >
5<!- - ti me stamp key =" timestamp " d at eP at te rn =" yyyy - MM - dd - H H: mm :ss " / - ->
6
7<!- - ## ## ## ## ## ## ## ## ## ###### AP PENDER # ###### # ## ## ## ## ###### ## ## ## ## # -->
8<!- - C o nsole logger - - >
9
10 < if c o nd i ti o n = ’ i s D e f i n e d (" logDirectory ") ’>
11 < t he n >
12 < property na me = "logDirectory" value = "${logDirectory}"/ >
13 < appender na me = "STDOUT" class = " ch . q os . l o gb ac k . c or e . C o ns o le Ap p en d er " >
14 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
15 < pattern >% dat e % -5 level % lo gger {0} - % msg %n </ pattern >
16 </ enc od er >
17 </ appe nd er >
18 <!- - L ogger for Time Ad v a n c es - - >
19 < appender na me = " ST DOUT - T im eA dv an ce " c la ss = " ch . qos . l o gb ac k . c or e . C o ns ol e Ap p en d er " >
20 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
21 <!- - Difference to p r e vious l o g ger: no % n at line end ... -->
22 < pat te rn >% dat e { HH :mm :ss } - % ms g </ p at te rn >
23 </ enc od er >
24 </ appe nd er >
25 <!- - L ogger for D B l o a d ing pr o g r e ss - - >
26 < appender na me = " ST DOUT - D bL oading " c lass =" ch . q os . l o gb ac k . c or e . C o ns o le A pp e nd e r " >
27 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
28 <!- - Difference to p r e vious l o g ger: no % n at line end ... -->
29 < patt ern > % da te { H H: mm:ss . SS S } - % m sg < / pat tern >
30 </ enc od er >
31 </ appe nd er >
32 <!- - L ogger for plain mess a g e s -- >
33 < appender na me = " ST DOUT - M es sa ge On ly " c la ss = " ch . qo s . l ogb a ck . c or e . C o ns o le Ap p en d er " >
34 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
35 < patt ern > % msg %n </ p at tern >
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 103
Appendix A VSimRTI deployment A.2 File listings
36 </ enc od er >
37 </ appe nd er >
38 <!- - File A p p e n d e r for d i f f e r e n t components -->
39 < appender na me = " VsimrtiLog " c lass =" ch . q os . l o gb ac k . c or e . F ile Ap p en de r " >
40 < file >${ l og Di r ect o r y }/ VSimRTI . log </ fil e >
41 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
42 < pattern >% dat e % -5 level % lo gger {0} - % msg %n </ pattern >
43 </ enc od er >
44 </ appe nd er >
45 < appender na me = " TrafficLog " c lass =" ch . q os . l o gb ac k . c or e . F ile Ap p en de r " >
46 < file >${ l og Di r ect o r y }/ Traffic . log </ fil e >
47 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
48 < pattern >% dat e % -5 level % lo gger {0} - % msg %n </ pattern >
49 </ enc od er >
50 < append >false < / appen d >
51 </ appe nd er >
52 < appender na me = "CommunicationLog" class = " ch . q os . l ogb a ck . c or e . F i le A pp e nd e r " >
53 < file >${ logDir e c t o r y }/ Communic a t i o n . log </ file >
54 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
55 < pattern >% dat e % -5 level % lo gger {0} - % msg %n </ pattern >
56 </ enc od er >
57 </ appe nd er >
58 < appender na me = "CommunicationDetailsLog" class = " ch . q os . l og b ac k . c or e . F i le A pp e nd e r " >
59 < file >${ l og Di r ect o r y }/ C om mu ni ca ti on De ta i ls . log </ file >
60 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
61 < patt ern > % msg %n </ p at tern >
62 </ enc od er >
63 < append >false < / appen d >
64 </ appe nd er >
65 < appender na me = "ApplicationNTLog" class = " ch . q os . l ogb a ck . c or e . F i le A pp e nd e r " >
66 < file >${ logDir e c t o r y }/ Applicat i o n N T . log </ file >
67 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
68 < pattern >% dat e % -5 level % lo gger {0} - % msg %n </ pattern >
69 </ enc od er >
70 </ appe nd er >
71
72 < appender na me = "ApplicationNtLogDelegation" c lass =" ch . q os . l o gb ac k . c las s ic . s if t .⤦
ÇSiftingAppender">
73 < d is cr imi na to r >
74 < key > path </ key >
75 <defaultValue>unknown</defaultValue>
76 </ discriminato r >
77 < s if t >
78 < a pp en de r n ame = " FIL E -$ { u ni tId } " c lass = " ch . qo s . l og b ac k . c or e . F i le A pp e nd e r " >
79 < file >${ l og Di r ect o r y }/ appsNT /$ { path }. log </ fi le >
80 < l ay ou t cl ass = " ch . qos . lo gback . classi c . PatternLayout " >
81 < p a tt er n > % da te % -5 lev el - % m sg % n </ p a tt er n >
82 </ la yo ut >
83 </ appe nd er >
84 </ si ft >
85 </ appe nd er >
86
87 < appender na me = "GeneralPurposeAmbassador" class = " ch .qos . logback . clas si c . sift .⤦
ÇSiftingAppender">
88 < d is cr imi na to r >
89 < ke y > l o gg e rI d < / k ey >
90 <defaultValue>unknown</defaultValue>
91 </ discriminato r >
92 < s if t >
93 < a pp en de r n ame = " FIL E -$ { l og g er I d } " c lass = " ch . qo s . l og b ac k . c or e . F i le A pp e nd e r "⤦
Ç>
94 < file >${ l og Di r ect o r y }/ loggerId -${ l oggerId }. log </ file >
95 < l ay ou t cl ass = " ch . qos . lo gback . classi c . PatternLayout " >
96 < p a tt er n > % da te % -5 lev el % l ogg e r { 0} - % m sg % n </ p at tern >
97 </ la yo ut >
98 </ appe nd er >
99 </ si ft >
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 104
Appendix A VSimRTI deployment A.2 File listings
100 </ appe nd er >
101
102 < appender na me = "StatisticsLog" clas s =" ch . q os . l og b ac k . c or e . F i le A pp e nd e r " >
103 < file >${ logDir e c t o r y }/ statistics . csv </ file >
104 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
105 < p at te rn > % da te % -5 l ev el % l og ger { 0} [ % t hr ea d ] - % msg % n </ p at te rn >
106 </ enc od er >
107 </ appe nd er >
108 < appender na me = " MappingLog " c lass =" ch . q os . l o gb ac k . c or e . F i le A pp e nd e r " >
109 < file >${ logDir e c t o r y }/ Mappi n g . log </ file >
110 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
111 < p at te rn > % da te % -5 l ev el % l og ger { 0} - % m sg % n </ p at tern >
112 </ enc od er >
113 </ appe nd er >
114 < l og ge r n am e = "dbLoadingProgress" additivity =" false " lev el = " IN FO " >
115 < app en de r - r ef re f = " STDO UT - DbLoading " / >
116 </ log ge r >
117 < appender na me = "NavigationLog" clas s =" ch . q os . l og b ac k . c or e . F i le A pp e nd e r " >
118 < file >${ logDir e c t o r y }/ Navigation . log </ file >
119 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
120 < p at te rn > % da te % -5 l ev el % l og ger { 0} - % m sg % n </ p at tern >
121 </ enc od er >
122 </ appe nd er >
123 < appender na me = "EnvironmentLog" class = " ch . q os . l o gb ac k . c or e . F i le A pp e nd e r " >
124 < file >${ logDir e c t o r y }/ Environment . log </ file >
125 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
126 < p at te rn > % da te % -5 l ev el % l og ger { 0} - % m sg % n </ p at tern >
127 </ enc od er >
128 </ appe nd er >
129 < appender na me = " Cell2Log " clas s =" ch . q os . l og b ac k . c or e . F i le A pp e nd e r " >
130 < file > ${ l o gDir e c tory }/ Cell2 . log </ file >
131 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
132 < p at te rn > % da te % -5 l ev el % l og ger { 0} - % m sg % n </ p at tern >
133 </ enc od er >
134 </ appe nd er >
135 < appender na me = " BatteryLog " c lass =" ch . q os . l o gb ac k . c or e . F i le A pp e nd e r " >
136 < file >${ logDir e c t o r y }/ Batte r y . log </ file >
137 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
138 < p at te rn > % da te % -5 l ev el % l og ger { 0} - % m sg % n </ p at tern >
139 </ enc od er >
140 </ appe nd er >
141 < appender na me = "ChargingStationLog" clas s =" ch . q os . l og b ac k . c or e . F i le A pp e nd e r " >
142 < file >${ logDir e c t o r y }/ Charg i n g S t ation .log </ file >
143 < e nc od er cl as s = "ch . qo s. logbac k . cl as sic . encoder . Patt er nL ayoutEn co de r " >
144 < p at te rn > % da te % -5 l ev el % l og ger { 0} - % m sg % n </ p at tern >
145 </ enc od er >
146 </ appe nd er >
147
148 <!- - # ###### # # # ###### # # # ##### LOGGE R # ###### # # ###### # # ##### # # # ##### # -->
149 <!- - Creating the reference between certain VSimRT I cl a s s es and l o g b ack
150 appenders -->
151 < l og ge r n am e = "VSimRTIStarter" additivity=" fals e " lev el = " IN FO " >
152 < app en de r - r ef re f = " Vs im rt iL og " / >
153 </ log ge r >
154 < l og ge r n am e = " com . dc aiti . vsimrt i . do ck er " additivity =" fals e " l ev el = " INFO " >
155 < app en de r - r ef re f = " Vs im rt iL og " / >
156 </ log ge r >
157 < l og ge r n am e = " com . d ca it i . vsim rti . fe d . su mo " additivity=" fals e " lev el = " I NFO " >
158 < app en de r - r ef re f = " Tr af fi cL og " / >
159 </ log ge r >
160 < l og ge r n am e = " com . d caiti . vsi mr ti . fed . omnetpp " additivity=" f alse " level = " IN FO " >
161 < app en de r - r ef re f = "CommunicationLog"/ >
162 </ log ge r >
163 < l og ge r n am e = " com . d ca it i . vsim rti . fe d . ns3 " additivity=" f al se " l evel = " INFO " >
164 < app en de r - r ef re f = "CommunicationLog"/ >
165 </ log ge r >
166 < l og ge r n am e = " com . d ca it i . vsim rti . fe d . sns " additivity=" f al se " l evel = " INFO " >
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 105
Appendix A VSimRTI deployment A.2 File listings
167 < app en de r - r ef re f = "CommunicationLog"/ >
168 </ log ge r >
169 <!- - NO T E: do not specify logging leve l s o ther th an " INFO " use omnetp p . ini ( O MNeT⤦
Ç++) for l o g g ing co n f iguration - - >
170 < l og ge r n am e = " com . d ca it i . vsim rti . fe d . ns3 . a mb assador . N s3 Am bas sa dorO ut put " ⤦
Çadditivity =" false " lev el = " IN FO " >
171 < app en de r - r ef re f = "CommunicationDetailsLog"/ >
172 </ log ge r >
173 < l og ge r n am e = " com . d caiti . vsi mr ti . fed . omnetpp . ambassador . Om ne tp pAmba ss ad orOutp ut " ⤦
Çadditivity =" false " lev el = " IN FO " >
174 < app en de r - r ef re f = "CommunicationDetailsLog"/ >
175 </ log ge r >
176 < l og ge r n am e = " com . d ca it i . vsim rti . fe d . a pp li ca ti on N T . a mb as sador . n avigation " ⤦
Çadditivity =" false " lev el = " IN FO " >
177 < app en de r - r ef re f = "NavigationLog"/ >
178 </ log ge r >
179 < l og ge r n am e = " com . d ca it i . vsim rti . fe d . a pp li ca ti on N T " additivity = " false " leve l ="INFO⤦
Ç">
180 < app en de r - r ef re f = "ApplicationNTLog"/ >
181 </ log ge r >
182 < l og ge r n am e = "ApplicationNtLogDelegate" additivity =" fals e " lev el = " IN FO " >
183 < app en de r - r ef re f = "ApplicationNtLogDelegation"/ >
184 </ log ge r >
185 < l og ge r n am e = " com . d ca it i . vsim rti . fe d . event se rv er " additivity=" fals e " lev el = " IN FO " >
186 < app en de r - r ef re f = "EnvironmentLog"/ >
187 </ log ge r >
188 < l og ge r n am e = " com . d ca it i . vsim rti . fe d . mappi ng3 " additivity=" fal se " le ve l =" I NF O " >
189 < app en de r - r ef re f = " Ma pp in gL og " / >
190 </ log ge r >
191 < l og ge r n am e = " com . d caiti . vsi mr ti . lib . routing " additivity=" f alse " level = " IN FO " >
192 < app en de r - r ef re f = "NavigationLog"/ >
193 </ log ge r >
194 < l og ge r n am e = " co m . gr a ph ho pper " additivity=" fals e " lev el = " INF O " >
195 < app en de r - r ef re f = "NavigationLog"/ >
196 </ log ge r >
197 < l og ge r n am e = " net . sf . jsi " additivity=" false " leve l =" O FF " >
198 < app en de r - r ef re f = "NavigationLog"/ >
199 </ log ge r >
200 < l og ge r n am e = " com . d ca it i . vsim rti . fe d . ce ll 2 " additiv ity = " false " leve l =" IN FO " >
201 < app en de r - r ef re f = " Ce ll 2L og " / >
202 </ log ge r >
203 < l og ge r n am e = " com . d caiti . vsi mr ti . fed . battery " additivity=" f alse " level = " IN FO " >
204 < app en de r - r ef re f = " Ba tt er yL og " / >
205 </ log ge r >
206 < l og ge r n am e = " com . d ca it i . vsim rti . fe d . phabm acs " additivity=" fal se " le ve l =" I NF O " >
207 < app en de r - r ef re f = " Tr af fi cL og " / >
208 </ log ge r >
209 < l og ge r n am e = " com . d ca it i . vsim rti . fe d . c ha rging st at i on " additivity=" f alse " level = "⤦
ÇINFO">
210 < app en de r - r ef re f = "ChargingStationLog"/ >
211 </ log ge r >
212 < l og ge r n am e = " st at is ti cs " additivity=" fals e " lev el = " OFF " >
213 < app en de r - r ef re f = "StatisticsLog"/ >
214 </ log ge r >
215 < l og ge r n am e = " com . d ca it i . vsim rti . rt i . servi ces . t ime " a dd itivity = " false " leve l ="INFO⤦
Ç">
216 < app en de r - r ef re f = " STDO UT - Tim eA dv ance " / >
217 </ log ge r >
218 < l og ge r n am e = " com . dc ai ti . v si mrti . star t " additivity =" false " leve l =" IN FO " >
219 < app en de r - r ef re f = " STDO UT - Mes sa ge Only " / >
220 </ log ge r >
221 <!- - All other stuff , which was not logged by other loggers before goes
222 to s td ou t a nd V Si mR TI . l og -->
223 < r oo t l ev e l = " INFO " >
224 < app en de r - r ef re f = " ST DO UT " / >
225 < app en de r - r ef re f = " Vs im rt iL og " / >
226 </ ro ot >
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 106
Appendix A VSimRTI deployment A.2 File listings
227 < / then >
228 < / if >
229
230 </ con fig ur a ti o n >
Listing A.3: VSimRTI: file listing: etc/logback.xml
systeminfo.txt
1 {" userid " :" 0" ,
2"version":" 1 .0 " ,
3 arch":"i686" ,
4"os " :" Lin ux " ,
5"osversion" :" 12.04" ,
6"cpumodel ":"a to m ( tm ) c p un 270@1 . 60 g hz " ,
7"sockets":1 ,
8"cores":2 ,
9"memory":1024 ,
10 "type":"checkin" ,
11 "loginmd5 ":"7fe5b9b9305ce3ffcd18e32bf0f0b9d9" ,
12 "simulationuuid" : "" ,
13 "macs" : [" 00:22:00:00:0e:00","00:00:54:00:00:00" ]}
Listing A.4: VSimRTI: file listing: systeminfo.txt
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 107
Appendix B
Example scenario Barnim
You will find a collection of all relevant data.
B.1 Folder Structure
Barnim
applicationNT .....................................................................
applications ...................................................................
Barnim.db ............................................... not listed (binary content)
battery ............................................................................
battery_config.json .................................................... (see B.1)
eventserver .......................................................................
eventserver_config.json ............................. not listed (in this release)
cell2 ..............................................................................
cell2_config.json ...................................................... (see B.2)
network.json ............................................................ (see B.3)
regions.json ............................................................ (see B.4)
mapping3 ...........................................................................
mapping_config.json .................................................... (see B.5)
sns ................................................................................
sns_config.json ........................................................ (see B.6)
sources ............................................................................
Barnim_fixed.osm .......................................... partially listed (see B.7)
sumo ...............................................................................
Barnim.edg.xml ............................................ partially listed (see B.8)
Barnim.net.xml ............................................ partially listed (see B.9)
Barnim.nod.xml ........................................... partially listed (see B.10)
Barnim.rou.xml ........................................................ (see B.11)
Barnim.sumo.cfg ....................................................... (see B.12)
sumo_config.json ...................................................... (see B.13)
visualizer ........................................................................
visualizer_config.xml ................................................ (see B.14)
vsimrti ............................................................................
vsimrti_config.xml .................................................... (see B.15)
simrun_config.xml ..................................................... (see B.16)
Figure B.1: Scenario Barnim: folder structure
Appendix B Example scenario Barnim B.2 File listings
B.2 File listings
battery/battery_config.json
1 {
2"vehicleModelClass":" c om . d ca it i . vsimr ti . fed . b atte ry . si m . mo del s . v eh ic le . E l ec tr i cS ma r t " ,
3"vehicleModelConfig": {
4" Mas s ": 1060 ,
5"ReferenceArea": 1.95 ,
6" DragCoe ff i ci en t ": 0.375 ,
7" Tank T oW he el Ef fi ci en cy " : 0.7 ,
8" Elet ri cM ot or Op er at in gV oltage " : 350 ,
9"ConsumerOperatingVoltage": 12
10 },
11 "batteryModelClass":" c om . d ca it i . vsimr ti . fed . b atte ry . si m . mo del s . b at te ry .⤦
ÇVerySimpleBatteryModel",
12 "batteryModelConfig": {
13 "NumberOfCells": 93 ,
14 " CellVoltage " : 4.3 ,
15 "CellCapacityInAh": 50 ,
16 " eff_Summer ": 0.8448 ,
17 "RechargingType": 2 ,
18 " MinS OC " : 0.30 ,
19 " MaxS OC " : 0.70
20 },
21 " envi r on me nt Mo de lC la ss " :" co m . dc ai ti . v sim rti . fe d . bat tery . s im . m od el s . e nv ironment .⤦
ÇDefaultEnvironment",
22 "environmentModelConfig": {
23 "Gravity": 9.81 ,
24 "FluidDensity": 1.293 ,
25 " Roll in gR es is ta nc eC oe ff icient " : 0.01
26 },
27 " consumers ":[{" Radi o ": 10 }, { " He ad Li gh t ": 100 } ]
28 }
Listing B.1: Scenario Barnim: file listing: battery/battery_config.json
cell2/cell2_config.json
1 {
2" debugG e oc a st in g ": false ,
3"visualizeRegions": false ,
4"networkConfigurationFile":" n et wo rk . j so n ",
5"regionConfigurationFile":" r eg io ns . j son "
6 }
Listing B.2: Scenario Barnim: file listing: cell2/cell2_config.json
cell2/network.json
1 {
2"globalRegion": {
3"uplink": {
4" del ay " : {
5" typ e ":"ConstantDelay",
6" del ay " : 100 ,
7" prp l ": 0 ,
8"retries": 2
9 },
10 " capacity ": 280000 0 0
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 109
Appendix B Example scenario Barnim B.2 File listings
11 },
12 " downlink " : {
13 "unicast": {
14 " del ay " : {
15 " typ e ":"ConstantDelay",
16 " del ay " : 100 ,
17 " prp l ": 0 ,
18 "retries": 2
19 }
20 },
21 " multicast ": {
22 " del ay " : {
23 " typ e ":"ConstantDelay",
24 " del ay " : 100 ,
25 " prp l ": 0
26 },
27 "usableCapacity": 0.6
28 },
29 " capacity ": 422000 0 0
30 }
31 }
32 }
Listing B.3: Scenario Barnim: file listing: cell2/network.json
cell2/regions.json
1 {
2"regions": [
3 ]
4 }
Listing B.4: Scenario Barnim: file listing: cell2/regions.json
mapping3/mapping_config.json
1 {
2" p r ot o ty p es " :[
3 {
4" nam e ":" P KW " ,
5" a cc el " :2.6,
6" d ec el " :4.5,
7"length":5.00 ,
8" maxSpeed " :70.0 ,
9"minGap":2.5 ,
10 " s ig ma " :0.5,
11 " ta u " :1
12 },
13 {
14 " nam e ":" e l ec t ri c PK W " ,
15 "vehicleClass":" E le ct ri c Ve hi cl e " ,
16 " a cc el " :2.6,
17 " d ec el " :4.5,
18 "length":5.00 ,
19 " maxSpeed " :40.0 ,
20 "minGap":2.5 ,
21 " s ig ma " :0.5,
22 " ta u " :1
23 },
24 {
25 "applications":[ " com . d ca it i . v si mr ti . a pp . t ut orials . b ar ni m . W ea ther Se rv e r "],
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 110
Appendix B Example scenario Barnim B.2 File listings
26 " nam e ":"WeatherServer"
27 }
28 ],
29 " rsu s ":[
30 {
31 " la t " :52.65027421760045,
32 " lo n " :13.545005321502686 ,
33 " nam e ":"WeatherServer"
34 }
35 ],
36 " v ehicl e s " :[
37 {
38 "startingTime": 5.0 ,
39 "targetDensity":1200 ,
40 "maxNumberVehicles": 120 ,
41 " rou te " :"1",
42 " t yp es " :[
43 {
44 "applications":[ " com . d ca it i . v si mr ti . a pp . t ut orials . b ar ni m . W eath er War ni ngA pp Cel l "⤦
Ç," co m . dc ai ti . v si mr ti . a pp . t ut orials . b ar ni m . S lo wDownApp " ],
45 " nam e ":" P KW " ,
46 " weig ht " :0.1
47 },
48 {
49 "applications":[ " com . d ca it i . v si mr ti . a pp . t ut orials . b ar ni m . W ea t he rWar ni ngAp p " ,"⤦
Çco m . dc ait i . v si mr ti . a pp . t ut orials . b ar ni m . S lo wDownApp " ],
50 " nam e ":" P KW " ,
51 " weig ht " :0.2
52 },
53 {
54 "applications":[ " com . d ca it i . v si mr ti . a pp . t ut orials . b ar ni m . S lo wDownApp " ],
55 " nam e ":" P KW " ,
56 " weig ht " :0.6
57 },
58 {
59 "applications":[ " com . d ca it i . v si mr ti . a pp . t ut orials . b ar ni m . S lo wDownApp " ],
60 " nam e ":" e l ec t ri c PK W " ,
61 " weig ht " :0.1
62 }
63 ]
64 }
65 ]
66 }
Listing B.5: Scenario Barnim: file listing:mapping3/mapping_config.json
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 111
Appendix B Example scenario Barnim B.2 File listings
sns/sns_config.json
1 {
2"version":" 0 .16.0 " ,
3
4" singlehop ": {
5" _singlehop radius in m ": 0 ,
6"radius": 509.4 ,
7" _d elay config according to vsi mrti - commun i ca t io n ": 0 ,
8" del ay " : {
9" typ e ":"SimpleRandomDelay",
10 " ste ps " : 5,
11 " minDelay ": 0.4 ,
12 " maxDelay ": 2.4 ,
13 " prp l ": 0 ,
14 "retries": 0
15 }
16 },
17
18 " multihop ": {
19 " _del ay co nfig a cc or di ng to vsim rti - c ommunication " : 0,
20 " del ay " : {
21 " typ e ":"GammaRandomDelay",
22 " minDelay ": 10 ,
23 " expDelay ": 30 ,
24 " prp l ": 0 ,
25 "retries": 2
26 }
27 }
28 }
Listing B.6: Scenario Barnim: file listing: sns/sns_config.json
sources/Barnim_fixed.osm
Note: This file is partially listed.
1 < ? xm l v e rs io n = ’ 1.0 ’ e nc o di ng = ’ UTF - 8 ’? >
2 < o sm v er si o n = ’0.6 ’ upload=’ t ru e ’ g e ne rator = ’ J OS M ’ >
3 <bounds minlat=’ 52.5924 1 ’ minlon=’ 1 3.51215 ’ maxlat=’ 5 2. 65827 ’ maxlon=’13.6227’ origin=’⤦
ÇCGIm ap 0. 3. 3 (11 99 0 t hor n - 02 . o penstree tm ap . or g ) ’ / >
4 < no de id = ’9671195’ t im estamp = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’ 4 35 66 ’ user=’ a nb r ’ visible=’ t ru e ’ ⤦
Çversion=’4 ’ changeset = ’2383615’ lat = ’ 5 2.5798854 ’ l on = ’ 1 3. 63 74 30 7 ’ / >
5 < no de id = ’9671197’ t im estamp = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’ 4 35 66 ’ user=’ a nb r ’ visible=’ t ru e ’ ⤦
Çversion=’5 ’ changeset = ’ 1403318 9 ’ l at = ’ 5 2. 5905574 ’ l on = ’ 1 3. 6219588 ’ / >
6 < no de id = ’9671202’ t im estamp = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’429794’ user=’SennaHB’ visible=’⤦
Çtrue’ version=’ 5 ’ c h an ges e t = ’ 1 39 85 567 ’ l at = ’ 5 2. 6051075 ’ l on = ’ 1 3. 5993505 ’ / >
7 < no de id = ’ 2150 8 73 9 ’ t imest a mp = ’ 2014 - 03 -25 T09:54:31Z ’ u id = ’ 4 35 66 ’ user=’ a nb r ’ visible=’ t ru e ’ ⤦
Çversion=’6 ’ changeset = ’ 1773948 9 ’ l at = ’ 5 2. 6639091 ’ l on = ’ 1 3. 5696135 ’ / >
8 < no de id = ’ 2150 8 74 6 ’ t imest a mp = ’ 2014 - 03 -25 T09:54:31Z ’ u id = ’ 1 18 27 8 ’ user=’ P anketaler ’ visible=⤦
Ç’ t ru e ’ version=’12 ’ c ha ng e se t = ’ 1 99 73396 ’ l at = ’ 5 2. 6240762 ’ l on = ’ 1 3. 5434165 ’ / >
9 < no de id = ’ 2150 8 74 7 ’ t imest a mp = ’ 2014 - 03 -25 T09:54:31Z ’ u id = ’ 1 18 27 8 ’ user=’ P anketaler ’ visible=⤦
Ç’ t ru e ’ version=’27 ’ c ha ng e se t = ’4921151’ l at = ’ 5 2.6297992 ’ l on = ’ 1 3. 5459023 ’ / >
10 < no de id = ’ 2 150874 8 ’ t i me stam p = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’ 1 18 27 8 ’ user=’ P anketaler ’ visible=⤦
Ç’ t ru e ’ version=’4 ’ c ha ngese t = ’4746323’ la t = ’ 52.6392207 ’ l on = ’ 1 3. 5605381 ’ / >
11 < no de id = ’ 2150 8 75 6 ’ t imest a mp = ’ 2014 - 03 -25 T09:54:31Z ’ u id = ’ 1 18 27 8 ’ user=’ P anketaler ’ visible=⤦
Ç’ t ru e ’ version=’6 ’ c ha ngese t = ’ 1 9973383 ’ lat = ’ 5 2.6266342 ’ l on = ’ 1 3. 5441771 ’ / >
12 < no de id = ’ 2150 8 75 7 ’ t imest a mp = ’ 2014 - 03 -25 T09:54:31Z ’ u id = ’ 4 35 66 ’ user=’ a nb r ’ visible=’ t ru e ’ ⤦
Çversion=’4 ’ changeset = ’ 1773948 9 ’ l at = ’52.662124’ l on = ’ 1 3. 569613 ’ / >
13 < no de id = ’ 2150 8 76 3 ’ t imest a mp = ’ 2014 - 03 -25 T09:54:31Z ’ u id = ’ 4 29 79 4 ’ user=’SennaHB’ visible=’⤦
Çtrue’ version=’ 8 ’ c h an ges e t = ’ 1 86 26 470 ’ l at = ’ 5 2. 6145 7 1 ’ l on = ’ 1 3.5536105 ’ / >
14 < no de id = ’ 2697 1 23 5 ’ t imest a mp = ’ 2014 - 03 -25 T09:54:31Z ’ u id = ’ 4 29 79 4 ’ user=’SennaHB’ visible=’⤦
Çtrue’ version=’ 9 ’ c h an ges e t = ’ 1 67 40 262 ’ l at = ’ 5 2. 6126837 ’ l on = ’ 1 3. 5681426 ’ / >
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 112
Appendix B Example scenario Barnim B.2 File listings
15 < no de id = ’ 2 697123 6 ’ t i me stam p = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’ 4 29 79 4 ’ user=’SennaHB’ visible=’⤦
Çtrue’ version=’ 9 ’ c h an ges e t = ’ 1 67 40 262 ’ l at = ’ 5 2. 6124118 ’ l on = ’ 1 3. 5701801 ’ / >
16 < no de id = ’ 2 697123 7 ’ t i me stam p = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’ 5 79 30 1 ’ user=’Lamarqe’ visible=’⤦
Çtrue’ version=’ 5 ’ c h an ges e t = ’ 1 24 40 961 ’ l at = ’ 5 2. 6236544 ’ l on = ’ 1 3. 5757994 ’ / >
17 < no de id = ’ 2 697124 0 ’ t i me stam p = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’ 4 29 79 4 ’ user=’SennaHB’ visible=’⤦
Çtrue’ version=’ 5 ’ c h an ges e t = ’ 1 39 85 567 ’ l at = ’ 5 2. 6137568 ’ l on = ’ 1 3. 564784 ’ / >
18 < no de id = ’ 2 697124 1 ’ t i me stam p = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’ 9 05 28 ’ user=’ P et er M ai wa l d ’ ⤦
Çvisible=’ tr ue ’ version=’4 ’ c ha ngese t = ’8364243’ la t = ’ 52.6135612 ’ l on = ’ 1 3. 565324 ’ / >
19 < no de id = ’ 2 697124 4 ’ t i me stam p = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’ 4 29 79 4 ’ user=’SennaHB’ visible=’⤦
Çtrue’ version=’ 6 ’ c h an ges e t = ’ 1 39 85 567 ’ l at = ’ 5 2. 6143 4 7 ’ l on = ’ 1 3.5636669 ’ / >
20 < no de id = ’ 2 697126 7 ’ t i me stam p = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’ 4 29 79 4 ’ user=’SennaHB’ visible=’⤦
Çtrue’ version=’ 9 ’ c h an ges e t = ’ 1 86 26 470 ’ l at = ’ 5 2. 6141673 ’ l on = ’ 1 3. 5561542 ’ / >
21 < no de id = ’ 2 697127 2 ’ t i me stam p = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’ 4 29 79 4 ’ user=’SennaHB’ visible=’⤦
Çtrue’ version=’ 11 ’ c ha n ge set = ’ 1 27 7161 2 ’ l at = ’ 5 2.6131516 ’ l on = ’ 1 3. 5672267 ’ / >
22 < no de id = ’ 2 697127 3 ’ t i me stam p = ’ 2014 -03 -25 T 0 9 : 5 4 : 3 1 Z ’ u id = ’ 4 29 79 4 ’ user=’SennaHB’ visible=’⤦
Çtrue’ version=’ 14 ’ c ha n ge set = ’ 1 86 2647 0 ’ l at = ’ 5 2.6150704 ’ l on = ’ 1 3. 5439418 ’ / >
Listing B.7: Scenario Barnim: file listing: sources/Barnim_fixed.osm
sumo/Barnim.edg.xml
Note: This file is partially listed.
1 < e dg es >
2 < ed ge id = "23995140 _260162539_260162554_260162539" from=" 260162539 " to = " 260162554 " n um Lanes =⤦
Ç"1 " s peed =" 8.3 3 " / >
3 < ed ge id = "23995140 _260162539_260162558_260162539" from=" 260162539 " to = " 260162558 " n um Lanes =⤦
Ç"1 " s peed =" 8.3 3 " / >
4 < ed ge id = "116570245_1313885509_866614488_1313885509" from=" 1 31 38 855 09 " to = " 86 66 13837 " ⤦
ÇnumLanes = "2" speed = " 22. 22 " / >
5 < ed ge id = "116570245_1313885509_866614488_866613837" from=" 8 66613837 " to = " 20263 62890 " ⤦
ÇnumLanes = "2" speed = " 22. 22 " / >
Listing B.8: Scenario Barnim: file listing: sumo/Barnim.edg.xml
sumo/Barnim.net.xml
Note: This file is partially listed.
1 < ? xml versi on = " 1.0 " encoding =" UT F - 8 " ? >
2
3<!- - generated on 0 2 / 15/17 17 :22:13 by SUMO n e t c o n v e r t Ve r s i on 0 . 2 8.0
4<? xml v er sio n = "1 .0 " e nc od in g = " UTF -8" ? >
5
6< c on f igu ra t io n x mlns : xs i =" h tt p: / / ww w . w3 . o rg / 20 01 / X ML Sc he ma - i ns t an ce " ⤦
Çx si : no Na me sp ac eS ch em aL oc at i on =" htt p: // s um o . dlr . de / xs d / n et co nv er tC onf ig ur at io n . xs d ">
7
8<input >
9< node - f iles val ue =" D :\ de v \ scenarios \ Ba rnim - S tartaufga be \ ap pl ic a ti on N T \ Bar ni m . nod . x ml⤦
Ç"/ >
10 < edge - f iles val ue =" D :\ de v \ scenarios \ Ba rnim - S tartaufga be \ ap pl ic a ti on N T \ Bar ni m . edg . x ml⤦
Ç"/ >
11 < co nn ec ti on - f il es v al ue = " D: \ de v \ sc enarios \ Ba rnim - S tartaufga be \ ap pl ic a ti on N T \ Bar nim . c on⤦
Ç. xml "/ >
12 </ in put >
13
14 <output >
15 < outp ut - f il e v al ue =" D: \ d ev \ s ce na rios \ Bar nim - S tar ta uf gab e \ a pp licatio nN T \ B ar ni m . net . xm l⤦
Ç"/ >
16 </ out put >
17
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 113
Appendix B Example scenario Barnim B.2 File listings
18 </configuration >
19 -->
20
21 < n et v e rs i on = " 0.2 7 " xmlns:xsi =" h tt p: / / ww w . w3 . o rg / 20 01 / X ML Sc he ma - i ns t an ce " ⤦
Çxsi:noNamespaceSchemaLocation=" h ttp: // s umo . dl r . de / xsd / n et _f ile . x sd " >
22
23 < l ocatio n n et O ff se t = " -397957.77, -5826114.68" convBoundary="0.00 ,0.00 ,9905.80,10297.64" ⤦
ÇorigBoundary="397957.77,5826114.68,407863.57,5836412.32" projParameter="!"/ >
24
25 < e dg e i d = ":1003778301_0" f un ction = " internal " >
26 < l an e i d =" : 10 03 77 83 01 _0 _0 " in de x =" 0" spe ed = " 8. 33 " length=" 0.2 9 " s ha pe = "⤦
Ç1221.68,7155.88,68.90 1221.42,7155.74,68.90"/ >
27 < / ed ge >
28 < e dg e i d = ":1003778301_1" f un ction = " internal " >
29 < l an e i d =" : 10 03 77 83 01 _1 _0 " in de x =" 0" spe ed = " 8. 33 " length=" 0.3 1 " s ha pe = "⤦
Ç1223.08,7152.88,68.90 1223.34,7153.03,68.90"/ >
30 < / ed ge >
Listing B.9: Scenario Barnim: file listing: sumo/Barnim.net.xml
sumo/Barnim.nod.xml
Note: This file is partially listed.
1 < n od es >
2 < no de id = " 866613617 " x =" 401721.2894 " y ="5830383.5757" z="58.9788" type=" priority " / >
3 < no de id = " 2632245436 " x=" 399909.1546 " y="5834705.7934" z="60.0000" type=" priority " / >
4 < no de id = " 41240371 " x=" 4 05 205. 4892 " y= "5835368.8690" z="69.9442" ty pe = " pr io ri ty " / >
5 < no de id = " 268746480 " x =" 402891.3857 " y ="5833194.2388" z="68.1866" type=" priority " / >
Listing B.10: Scenario Barnim: file listing: sumo/Barnim.nod.xml
sumo/Barnim.rou.xml
1 < ? xml versi on = " 1.0 " encoding =" UT F - 8 " ? >
2
3<!- - generated on 0 4 / 15/14 14 :26:30 by SUMO d u a r outer Ve rsion 0 .19.0
4<? xml v er sio n = "1 .0 " e nc od in g = " UTF -8" ? >
5
6< c on f igu ra t io n x mlns : xs i =" h tt p: / / ww w . w3 . o rg / 20 01 / X ML Sc he ma - i ns t an ce " ⤦
Çx si : no Na me sp ac eS ch em aL oc at i on =" htt p: // s umo - s im . org / x sd / d ua ro ute rC onf ig ur at ion . x sd " >
7
8<input >
9< net - f il e v al ue =". \ B ar ni m . ne t . xml "/ >
10 < tri p - f il es va lu e = ". \ t ri ps . x ml " / >
11 </ in put >
12
13 <output >
14 < outp ut - f il e v al ue =" B ar ni m . ro u . xml "/ >
15 </ out put >
16
17 </configuration >
18 -->
19
20 < r ou tes xmlns:xsi = " ht tp: // w ww . w 3 . or g / 20 01/ X ML Sc he ma - i nstan c e " xsi:noNamespaceSchemaLocation="⤦
Çhtt p: // sumo - si m . org / xs d / ro ut es _fil e . xs d ">
21 <! -- vTy pe mo de l =" S UM O_KRAUSS " id =" P KW " / - ->
22
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 114
Appendix B Example scenario Barnim B.2 File listings
23 < ro ut e i d =" 1" edg es = " 40 67 968 _ 28 83021 9_ 39 9339 27 _2 4509 38 91 4 4 067968⤦
Ç_288 3 0 219_39 9 3 3 927_60 6 3 5629 406796 8 _28830 2 1 9_3993 3 9 2 7_267 9 2 5 251 40679 6 8 ⤦
Ç_288 3 0 219_39 9 3 3 927_5 9 9 8 26230 62710154 _3 9 9 3 3927_3 9 9 3 3921_ 3 9 9 33927 73017982⤦
Ç_39933921_2026362940_39933921 73017982_39933921_2026362940_2026362943 -3366⤦
Ç_2026362940_1313885502_2026362940 -3366_2026362940_1313885502_2026362938 -3366⤦
Ç_2026362940_1313885502_2364474851 -3366_2026362940_1313885502_1313885442 -3366⤦
Ç_2026362940_1313885502_2026362934 -3366_2026362940_1313885502_2364474850 -3366⤦
Ç_2026362940_1313885502_2026362930 -3366_2026362940_1313885502_2026362929 73017981⤦
Ç_1313885502_866614526_1313885502 73017981_1313885502_866614526_2364474849 73017981⤦
Ç_1313885502_866614526_1313885493 73017981_1313885502_866614526_2364474847 73017981⤦
Ç_1313885502_866614526_1313885455 73017981_1313885502_866614526_1313885452 73017981⤦
Ç_1313885502_866614526_866614218 73017981_1313885502_866614526_1313885474 73017981⤦
Ç_1313885502_866614526_866614127 73017981_1313885502_866614526_866614379 73017981⤦
Ç_1313885502_866614526_866614760 73017981_1313885502_866614526_866613761 73017981⤦
Ç_1313885502_866614526_866614254 116570220_866614526_866613611_866614526 116570220⤦
Ç_866614526_866613611_1313885383 116570220_866614526_866613611_2314374830 116570220⤦
Ç_866614526_866613611_2026362918 73017984_866613611_866613693_866613611 73017984⤦
Ç_866613611_866613693_2538574191 73017984_866613611_866613693_1313885521 73017984⤦
Ç_866613611_866613693_1313885489 73017984_866613611_866613693_866614362 73017984⤦
Ç_866613611_866613693_866614700 106057563_866613693_866614474_866613693 106057563⤦
Ç_866613693_866614474_866614207 106057563_866613693_866614474_1313885413 106057563⤦
Ç_866613693_866614474_1313885451 116570250_866614474_866613833_866614474 116570250⤦
Ç_866614474_866613833_2026362855 116570250_866614474_866613833_1313885473 116570237⤦
Ç_866613833_866613992_866613833 116570237_866613833_866613992_1313885484 116570237⤦
Ç_866613833_866613992_2026362842 116570237_866613833_866613992_1313885386 116570237⤦
Ç_866613833_866613992_1313885524 116570237_866613833_866613992_866614195 116570237⤦
Ç_866613833_866613992_866614570 116570237_866613833_866613992_1313885441 116570237⤦
Ç_866613833_866613992_866613497 165881196_866613992_866614320_866613992 165881196⤦
Ç_866613992_866614320_866614684 165881196_866613992_866614320_1313885548 165881196⤦
Ç_866613992_866614320_1313885531 165881196_866613992_866614320_2026362847 165881196⤦
Ç_866613992_866614320_1313885511 165881196_866613992_866614320_2026362848 165881196⤦
Ç_866613992_866614320_1313885515 165881196_866613992_866614320_1313885471 165881196⤦
Ç_866613992_866614320_1313885435 165881196_866613992_866614320_1313885393 165881196⤦
Ç_866613992_866614320_1313885492 165881196_866613992_866614320_1313885454 165881196⤦
Ç_866613992_866614320_1313885415 232375390_866614320_866614323_866614320 232375390⤦
Ç_866614323_866614062_866614323 248048346_866614062_866613506_866614062 248048344⤦
Ç_866613506_866613555_866613506 245434998_866613555_1313885532_866613555 245434998⤦
Ç_866613555_1313885532_2389986818 245434998_866613555_1313885532_866613905 116570222⤦
Ç_1313885532_2026362814_1313885532 116570222 _1313885532_2026362814_1313885431 ⤦
Ç116570222_1313885532_2026362814_2026362827 116570222⤦
Ç_1313885532_2026362814_2026362821 192079314 _2026362814_692755381_2026362814 ⤦
Ç192079314_2026362814_692755381_2510575567 182262835_692755381_49832298_692755381" / >
24 < ro ut e i d =" 2" edg es = " 40 67 968 _ 28 83021 9_ 39 9339 27 _2 4509 38 91 4 4 067968⤦
Ç_288 3 0 219_39 9 3 3 927_60 6 3 5629 406796 8 _28830 2 1 9_3993 3 9 2 7_267 9 2 5 251 40679 6 8 ⤦
Ç_288 3 0 219_39 9 3 3 927_5 9 9 8 26230 5477467 _399 3 3 927_33 5 3 7 6891_ 3 9 9 33927 5477467⤦
Ç_39933927_335376891_39934065 5477467_39933927_335376891_267923737 5477467⤦
Ç_39933927_335376891_267923739 5477467_39933927_335376891_267923741 166752304⤦
Ç_335 3 7 6891_3 9 9 33917_ 3 3 537689 1 166752304 _39933 9 1 7_7566 6 5 9 4_3993 3 9 17 1 66752304⤦
Ç_399 3 3 917_75 6 6 6 594_5 6 4 0 06580 16 6 7 5 2 3 0 4 _ 7 566659 4 _ 756730 5 7 _ 756665 9 4 166752304⤦
Ç_756 6 6 594_75 6 7 3 057_76 5 6 5701 1 6 6 7 5 2 3 0 4 _ 7 566659 4 _ 7 56730 5 7 _ 73935 6 8 4 7 166752304⤦
Ç_756 6 6 594_75 6 7 3 057_21 5 0 8748 1 6 6 7 5 2 3 0 4 _ 7 566659 4 _ 7 56730 5 7 _ 73935 6 8 3 9 166752304⤦
Ç_756 7 3 057_30 3 1 8 4519_ 7 5 6 73057 166752304 _ 7 5 673057 _ 3 0 31845 1 9 _ 73935 6 8 3 0 1667 5 2 3 0 4 ⤦
Ç_303184519_1781963887_303184519 166752301_1781963887_73586268_1781963887 166752301⤦
Ç_1781963887_73586268_2250683387 30602177_73586268_75679644_73586268 30602177⤦
Ç_735 8 6 268_75 6 7 9 644_7 6 5 9 65511 22 9 0 6 8 3 6 1 _ 7 567964 4 _ 215087 4 7 _ 756796 4 4 229068361⤦
Ç_21508747_2621152986_21508747 229068361_21508747_2621152986_765965509 229068361⤦
Ç_21508747_2621152986_2625982333 229068361_21508747_2621152986_2621153010 229068361⤦
Ç_21508747_2621152986_2621153009 229068361_21508747_2621152986_2621153003 229068361⤦
Ç_21508747_2621152986_2621152999 229068361_21508747_2621152986_73586264 229068361⤦
Ç_21508747_2621152986_21508756 229068361_2621152986_2621152983_2621152986 111283478⤦
Ç_2621152983_2621152974_2621152983 111283478 _2621152983_2621152974_2621152977 ⤦
Ç111283478_2621152983_2621152974_2621152975 229068360⤦
Ç_2621152974_2621152972_2621152974 229068360_2621152972_21508746_2621152972 229068360⤦
Ç_2621152972_21508746_601059352 229068360_2621152972_21508746_1600991158 229068360⤦
Ç_2621152972_21508746_1600991160 229068357_21508746_2510564806_21508746 229068357⤦
Ç_21508746_2510564806_1600991159 229068357_21508746_2510564806_1600991155 229068357⤦
Ç_21508746_2510564806_2377050402 229068357_21508746_2510564806_1600991157 229068357⤦
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 115
Appendix B Example scenario Barnim B.2 File listings
Ç_21508746_2510564806_661749240 229068357_21508746_2510564806_416065959 229068357⤦
Ç_21508746_2510564806_1600991154 229068357_21508746_2510564806_661749237 146875503⤦
Ç_2510564806_27031232_2510564806 146875503_2510564806_27031232_1600991153 146875503⤦
Ç_2510564806_27031232_1600991156 146875503_2510564806_27031232_1587700342 146875503⤦
Ç_2510564806_27031232_2510564804 146871033_27031232_27031229_27031232 227901601⤦
Ç_27031229_866613841_27031229 227901601_27031229_866613841_2526390859 227901601⤦
Ç_27031229_866613841_866613799 227901601_27031229_866613841_866614008 227901601⤦
Ç_27031229_866613841_1313885439 227901601_27031229_866613841_1313885527 227901601⤦
Ç_27031229_866613841_1313885436 227901601_27031229_866613841_866613786 245432872⤦
Ç_866613841_866614578_866613841 116570239_866614578_866613555_866614578 116570239⤦
Ç_866614578_866613555_1313885456 245434998_866613555_1313885532_866613555 245434998⤦
Ç_866613555_1313885532_2389986818 245434998_866613555_1313885532_866613905 116570222⤦
Ç_1313885532_2026362814_1313885532 116570222 _1313885532_2026362814_1313885431 ⤦
Ç116570222_1313885532_2026362814_2026362827 116570222⤦
Ç_1313885532_2026362814_2026362821 192079314 _2026362814_692755381_2026362814 ⤦
Ç192079314_2026362814_692755381_2510575567 182262835_692755381_49832298_692755381" / >
25
26 <!- - vehi c l e id ="0" t ype =" PKW " rout e ="1" de part ="1 " repno ="50 0 " p e riod ="5 " / > S t a n d ard r oute⤦
Ç-->
27 <!- - v ehicle id ="1 " type =" PKW " r oute ="2" depart ="3" repno ="20" p eriod = "20" /> A u s w e i c h route ⤦
Ç-->
28 < / routes >
Listing B.11: Scenario Barnim: file listing: sumo/Barnim.roud.xml
sumo/Barnim.sumo.cfg
1 <configuration >
2 <input >
3 <net - f ile valu e =" B ar ni m . net . xm l " />
4 < route - fil es v al ue = " Ba rn im . ro u . xml " / >
5 </ inp ut >
6 <time >
7 < b eg in v al ue = " 0 " / >
8 < end v al ue = " 10 000 " / >
9 </ time >
10 </configuration >
Listing B.12: Scenario Barnim: file listing: sumo/Barnim.sumo.cfg
sumo/sumo_config.json
1 {
2" sumo C on fi gu ra ti on Fi le " :" Barnim . sumo . cfg "
3 }
Listing B.13: Scenario Barnim: file listing: sumo/sumo_config.json
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 116
Appendix B Example scenario Barnim B.2 File listings
visualizer/visualizer_config.xml
1 ï ż£ < ? xml versio n = " 1.0 " e ncoding =" UT F - 8 " ? >
2<!- - fi le version: 201 3 -11 -26 -->
3 < c onfigur at io n x ml ns:xsi = " ht t p: / / ww w . w3 . o rg / 2 00 1/ X ML Sc he ma - i n st ance "
4 xsi:noNamespaceSchemaLocation=" htt p: // www . d caiti .tu - b erlin . de / re se ar ch /⤦
Çsimulation / downloa d /get / scenarios / scenario nam e / visualizer /⤦
Çv is uali ze r_co nf ig . xsd " >
5 < v isualizer i d ="filevisualizer" enabled=" t rue " update="5" loader=" c om . d ca it i . v si mr ti . f ed .⤦
Çvisualizer . FileV i su al iz er Co nf ig " >
6 < f il en ame > v isualizer . csv < / f il en am e >
7 < d i re ctor y > . </ d i re c to ry >
8 < s e pa rato r > ; </ s e pa r at or >
9 < m es sages >
10 < m es sa g e id = "VehicleMovements">
11 <entries>
12 < e nt ry > "MOVE_VEHICLE"< / entry >
13 < entry > Ti me </ entry >
14 < entry > Updated: N a m e < /entr y >
15 < entry > Upd a t e d: P os i t io n . Latitude </ entry >
16 < e nt ry > U p da te d :P o si t io n . L ong i tu d e < / ent ry >
17 < entry > Update d : S pee d < / entr y >
18 < e nt ry > U p da te d :H e ad i ng < / en try >
19 </ ent ri es >
20 </ mes sa ge >
21 < m es sa g e id = "ReceiveV2XMessage">
22 <entries>
23 < e nt ry > "RECV_MESSAGE"< / entry >
24 < entry > Ti me </ entry >
25 < entry > MessageId </ entry >
26 < entry > Receiver N a m e < /entr y >
27 < entry > Ty pe </ entry >
28 </ ent ri es >
29 </ mes sa ge >
30 < m es sa g e id = "SendV2XMessage">
31 <entries>
32 < e nt ry > "SEND_MESSAGE"< / entry >
33 < entry > Ti me </ entry >
34 < entry > MessageId </ entry >
35 < e nt ry > S o ur c eN a me < / e nt ry >
36 < entry > Ty pe </ entry >
37 <! -- < entry > D es ti na ti on . P os it ion . Lat itud e </ entr y > -->
38 <! -- < entry > D es ti na ti on . P os it ion . Long itude </ entry > -->
39 <!- - < entry > Destination . Radius </ entry > -->
40 </ ent ri es >
41 </ mes sa ge >
42 < m es sa g e id = "AddedVehicle" enabled=" tru e ">
43 <entries>
44 < e nt ry > "ADDED_VEHICLE"< / entry >
45 < entry > Ti me </ entry >
46 < e nt ry > A p p li c at i on V eh ic l e . N am e < / en try >
47 < e nt ry > A p p li c at i on V eh ic l e . A p pl i ca t io n s < / e nt ry >
48 < e nt ry > A p p li c at i on V eh ic l e . V e hi c le T yp e . N am e < / e nt ry >
49 </ ent ri es >
50 </ mes sa ge >
51 < m es sa g e id = "AddedTrafficLight">
52 <entries>
53 < e nt ry > "ADDED_TRAFFICLIGHT"</ entr y >
54 < entry > Ti me </ entry >
55 < entry > Ap p li c at io n Tr af f ic Li g ht . Na me </ entry >
56 < entry > Ap p li c at io n Tr af f ic Li g ht . Applic a t i o n s </ ent ry >
57 < entry > Tra f f ic L ig h t Gr o up . FirstP o s i t io n . Latitude </ en try >
58 < entry > Tra f f ic L ig h t Gr o up . FirstP o s i t io n . Longitude </ entry >
59 </ ent ri es >
60 </ mes sa ge >
61 < m es sa g e id = " A dd e dR su " >
62 <entries>
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 117
Appendix B Example scenario Barnim B.2 File listings
63 < e nt ry > " A DD E D_ R SU " < / entry >
64 < entry > Ti me </ entry >
65 < e nt ry > A p pli ca t io n Rs u . N am e < / en try >
66 < e nt ry > A p pli ca t io n Rs u . A p pl i ca t io n s < / e nt ry >
67 < entry > Applicati on Rs u . Po sition . Latitude </ ent ry >
68 < entry > Appli c a ti o n R su . Positio n . Longitude </ en try >
69 </ ent ri es >
70 </ mes sa ge >
71 </ messages >
72 < / vi sualizer >
73
74 < v isualizer i d =" ew or ld " enabled=" false "
75 l oader =" com . d ca it i . v si mr ti . f ed . v isualizer . e w or ldvis ua lizer . c on fi g .⤦
ÇEworldVisualizerConfig">
76 <synchronized>true</synchronized>
77 < host > local < /host >
78 < port > 50500 < /port >
79 < m es sages >
80 < m es sa g e id = "AddedTrafficLight"></message>
81 < m es sa g e id = " A dd e dR su " ></message>
82 < m es sa g e id = "AddedVehicle"></message>
83 < m es sa g e id = "VehicleMovements"></message>
84 </ messages >
85 < / vi sualizer >
86
87 < v isualizer i d =" websoc ke t " enabled=" t rue " loader=" c om . d ca it i . v si mr ti . f ed . v is ualizer .⤦
ÇWebsocketVisualizerConfig">
88 <synchronized>true</synchronized>
89 < port > 46587 < /port >
90 < m es sages >
91 < m es sa g e id = "VehicleMovements" enabled=" tru e "></message>
92 < m es sa g e id = "ReceiveV2XMessage" enabled=" t ru e " ></message>
93 < m es sa g e id = "SendV2XMessage" enabled=" t ru e " ></ mes sa ge >
94 < m es sa g e id = "ReceiveCellMessage" enabled=" f al se " ></message>
95 < m es sa g e id = " S e nd Ce l lM es sa ge " enabled=" false " ></message>
96 < m es sa g e id = "AddedVehicle" enabled=" tru e "></message>
97 < m es sa g e id = " A ddedRsu " enabled=" tr ue " ></message>
98 < m es sa g e id = "AddedTrafficLight" enabled=" fals e "> </ message >
99 < m es sa g e id = "AddedChargingStation" enabled=" fal se " ></message>
100 < m es sa g e id = "ChargingStationUpdate" enabled=" fals e "> </ message >
101 </ messages >
102 < / vi sualizer >
103
104 </ con fig ur a ti o n >
Listing B.14: Scenario Barnim: file listing: visualizer/visualizer_config.xml
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 118
Appendix B Example scenario Barnim B.2 File listings
vsimrti/vsimrti_config.xml
1 ï ż£ < ? xml versio n = " 1.0 " e ncoding =" UT F - 8 " ? >
2 < c onfigur at io n x ml ns:xsi = " ht t p: / / ww w . w3 . o rg / 2 00 1/ X ML Sc he ma - i n st ance "
3 xsi:noNamespaceSchemaLocation=" http s: // w ww . dc ai ti . tu - berl in . de / research /⤦
Çsimul at io n / d ow nloa d / get / s cenar ios / s cena ri on ame / v sim rti / v simrti _c on f ig .⤦
Çxs d " >
4 < s imulation >
5<!- - S c e nario name -->
6 < id > Ba rn im < /id >
7<!- - S i m u l a t i o n time frame -->
8 < s t ar ttim e > 0 </ s t ar t ti me >
9 < en d time > 1200 </ endti m e >
10 <!- - See d for pseudo ran d om n umber g e n e r a t o r used by most of the f e d e r a t es -->
11 < ra n d o m S e e d > 268965854 </ randomSeed >
12 <!- - P r o j e c t i o n bet w e e n g l obal and c a rtesian co o r d i na t es -->
13 <!- - c e n terCoord i n a t es: r o u g hly the center of s i m u l a t i o n a rea -->
14 <!- - c a r t e sianOffset : can be found in the g e n e r a t e d ne t work file for the t r a f fic ⤦
Çsim ulato r , e .g. the . net . xml fi le for sumo -->
15 <WGS84UTMTransformConfig>
16 {
17 "centerCoordinates": {
18 " longitude ": 13.56 ,
19 " latitude " : 52 .63
20 },
21 " cartesi an O ff se t ": {
22 "x": -397957.77 ,
23 "y": -5826114.68
24 }
25 }
26 </WGS84UTMTransformConfig>
27 <!- - G lobal IP management -->
28 <IPResolverConfig>
29 {
30 n e tMask: " 2 55.255 .0 .0 " ,
31 v e h i c l e N e t : " 1 0. 1. 0 .0 " ,
32 rsuNet: " 1 0 .2 .0.0 " ,
33 tlNet: " 1 0. 3. 0. 0 ",
34 csNet: " 1 0. 4. 0. 0 ",
35 s e r v e r N e t : " 1 0. 5. 0.0 "
36 }
37 </IPResolverConfig>
38 < th r eads >1 < / threads >
39 < / si mulation >
40 < f ederates >
41 <!- - C e l lular n e t work s i m u l a t o r -- >
42 < f e de ra t e id = " cell2 " active=" f al se " / >
43 <!- - V2X ( ad hoc ) n e twork s i m u l a t o r s -- >
44 < f e de ra t e id = "omnetpp" active=" fal se " / >
45 < f e de ra t e id = " ns3 " active=" f al se " / >
46 < f e de ra t e id = " sns " active=" t rue " / >
47 <!- - T r affic s i m u l a t o r s -- >
48 < f e de ra t e id = " sumo " active=" t rue " / >
49 <!- - A p p l i c a t i o n simulator - - >
50 < f e de ra t e id = "applicationNT" active=" tr ue " / >
51 <!- - E n v i r o n m e n t simulator - - >
52 < f e de ra t e id = " ev en tser ver " active=" true " / >
53 <!- - E l e ctric m o b i l i ty si m u l a t o r s -->
54 < f e de ra t e id = "battery" active=" tru e "/ >
55 < f e de ra t e id = " ch ar gi ng st a ti on " active=" false " / >
56 <!- - M a pping -->
57 < f e de ra t e id = " mapping3 " active=" tru e "/ >
58 <!- - V i s u a lization -->
59 < f e de ra t e id = " vi sualizer " active=" tru e "/ >
60 < / fe derates >
61 </ con fig ur a ti o n >
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 119
Appendix B Example scenario Barnim B.2 File listings
Listing B.15: Scenario Barnim: file listing: vsimrti/vsimrti_config.xml
vsimrti/simrun_config.xml
1 < ? xml versi on = " 1.0 " encoding =" UT F - 8 " ? >
2<!- - fi le version: 201 4 -08 -27 -->
3<!- -
4This c o n figuration i n duces the e x e c u t i o n of 6 s i m u l a t i o n s
5(2 d im en si ons with 5 p ar am et er for e ach dimension ).
6The simulatio n s will be ex e cuted one afte r a nother ( s e q u e n t i a l mode ) .
7following s i m u l a t i o n s would be triggered:
8
9The parameter set
10 ( V2XVehiclePercentage , CellVehiclePercentage , Clas si cV eh iclePe rc en ta ge and S im ul at io nt ime )
11 nest to parameter
12 ( Singleh op R ad iu s ).
13 The y d efine th e d im en si on s of the simulations m at rix .
14
15 === == 001. simulation === ==
16 V2XVehiclePercentage=0
17 CellVehiclePercentage=0
18 ClassicVehiclePercentage=100
19 Simulationtime=100
20 Single h o p R a d ius =5 00
21
22 === == 002. simulation === ==
23 V2XVehiclePercentage=0
24 CellVehiclePercentage=0
25 ClassicVehiclePercentage=100
26 Simulationtime=100
27 Single h o p R a d ius =6 00
28
29 === == 003. simulation === ==
30 V2XVehiclePercentage=50
31 CellVehiclePercentage=0
32 ClassicVehiclePercentage=50
33 Simulationtime=100
34 Single h o p R a d ius =5 00
35
36 === == 004. simulation === ==
37 V2XVehiclePercentage=50
38 CellVehiclePercentage=0
39 ClassicVehiclePercentage=50
40 Simulationtime=100
41 Single h o p R a d ius =6 00
42
43 === == 005. simulation === ==
44 V2XVehiclePercentage=75
45 CellVehiclePercentage=0
46 ClassicVehiclePercentage=25
47 Simulationtime=100
48 Single h o p R a d ius =5 00
49
50 === == 006. simulation === ==
51 V2XVehiclePercentage=75
52 CellVehiclePercentage=0
53 ClassicVehiclePercentage=25
54 Simulationtime=100
55 Single h o p R a d ius =6 00
56
57 === == 007. simulation === ==
58 V2XVehiclePercentage=0
59 Cell V e h i clePerc e n t age =50
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 120
Appendix B Example scenario Barnim B.2 File listings
60 ClassicVehiclePercentage=50
61 Simulationtime=100
62 Single h o p R a d ius =5 00
63
64 === == 008. simulation === ==
65 V2XVehiclePercentage=0
66 Cell V e h i clePerc e n t age =50
67 ClassicVehiclePercentage=50
68 Simulationtime=100
69 Single h o p R a d ius =6 00
70
71 === == 009. simulation === ==
72 V2XVehiclePercentage=0
73 Cell V e h i clePerc e n t age =75
74 ClassicVehiclePercentage=25
75 Simulationtime=100
76 Single h o p R a d ius =5 00
77
78 === == 010. simulation === ==
79 V2XVehiclePercentage=0
80 Cell V e h i clePerc e n t age =75
81 ClassicVehiclePercentage=25
82 Simulationtime=100
83 Single h o p R a d ius =6 00
84
85 -->
86 < c onfigurat io n
87 xmlns:xsi =" h tt p: // w ww . w 3 . or g / 20 01/ X ML Sc he ma - i nstan c e "
88 xsi:noNamespaceSchemaLocation=" http: // w ww . dc ai ti . tu - berli n .de / r esearch / s im ul at io n / do wn lo ad /⤦
Çge t / scenarios / s cenarion am e / v si mr ti / s im ru n_ co nf ig . xs d " >
89 <!- - basic conf i g u r a t i on - - >
90 < vs im rti l oc at i on = " / pa th / to / you r / vsimrti _f ol der " executable =" v simr t i . sh " userna me = "⤦
Çyour_user_id" / >
91 < sc ena r io n am e ="Barnim" config=" s cen arios / B ar ni m / v si mr ti / v sim rt i_confi g . xm l " p er si st ent = "⤦
Çfal se " repetitions = "1" progressLogger=" t ru e " >
92 <!- - argu ment > -o TRACE </ argument -->
93 <! - - ar gu ment > - w 0 </ a r gu me n t - ->
94 </ scenario >
95
96 <!- - de fine connected valu e s for controlled changes -->
97 < di mens i on n am e ="SimulationRuns">
98 < parameter nam e = "V2XVehiclePercentage" file=" m ap pi ng 3 / m ap pi ng_c on fi g . jso n " fileFormat ="⤦
Çjson" item=" v eh ic le s [0]. types [0]. w eight " type=" V al ue L is t " >
99 < val ue > 0 </ v al ue >
100 < va lue > 50 </ val ue >
101 < va lue > 75 </ val ue >
102 < val ue > 0 </ v al ue >
103 < val ue > 0 </ v al ue >
104 </ paramete r >
105 < p ar ameter nam e = " Ce ll Ve hi cl eP er ce nt ag e " file=" m app ing3 / map pi ng _conf ig . j son " fileFormat⤦
Ç=" jso n " item=" vehicles [ 0]. t ypes [ 0]. w ei ght " type=" ValueList " >
106 < val ue > 0 </ v al ue >
107 < val ue > 0 </ v al ue >
108 < val ue > 0 </ v al ue >
109 < val ue > 50 < / v al ue >
110 < val ue > 75 < / v al ue >
111 </ parameter >
112 < parameter nam e = "ClassicVehiclePercentage" file=" m ap pi ng 3 / m ap pi ng_co nf ig . j so n " ⤦
ÇfileFormat =" json " item=" v eh ic le s [0] . typ es [2] . weigh t " type=" V alueList " >
113 < value > 100 </ value >
114 < va lue > 50 </ val ue >
115 < va lue > 25 </ val ue >
116 < val ue > 50 < / v al ue >
117 < val ue > 25 < / v al ue >
118 </ paramete r >
119 < parameter nam e = "Simulationtime" file=" vsimrti / vsimrti _c on fi g . xml " fileFormat =" xml " item⤦
Ç=" // s im ul at io n / endtime " type=" Value Li st " >
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 121
Appendix B Example scenario Barnim B.2 File listings
120 < value > 100 </ value >
121 < value > 100 </ value >
122 < value > 100 </ value >
123 < value > 100 </ value >
124 < value > 100 </ value >
125 </ paramete r >
126 </ dimension >
127
128 <!- - d efine values for a u t omatically p e r m u ted si m u l a ti on s - ->
129 < pa rame t er n am e =" SinglehopR a di us " file=" sns / s ns_config . j son " f il eFormat = " json " item="⤦
Çsinglehop . radi us " type=" V alueList " >
130 < val ue > 5 00 < / v al ue >
131 < val ue > 6 00 < / v al ue >
132 </ parameter >
133 </ con fig ur a ti o n >
Listing B.16: Scenario Barnim: file listing: vsimrti/simrun_config.xml
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 122
Appendix C
Example scenario Tiergarten
You will find a collection of all relevant data.
C.1 Folder Structure
Tiergarten
applicationNT .....................................................................
applications ...................................................................
applicationNT_config.json ............................. not listed (in this release)
tiergarten.db .......................................... not listed (binary content)
cell2 ..............................................................................
cell2_config.json ...................................... not listed (in this release)
network.json ............................................ not listed (in this release)
regions.json ............................................ not listed (in this release)
mapping3 ...........................................................................
mapping_config.json .................................... not listed (in this release)
omnetpp ............................................................................
omnetpp.ini ............................................................. (see C.1)
ns3 ................................................................................
configTechnologies.xml ................................ not listed (in this release)
confWifi.xml ............................................ not listed (in this release)
sns ................................................................................
sns_config.json ........................................ not listed (in this release)
sources ............................................................................
tiergarten.osm ......................................... not listed (in this release)
sumo ...............................................................................
sumo_config.json ....................................... not listed (in this release)
tiergarten.edg.xml ..................................... not listed (in this release)
tiergarten.net.xml ..................................... not listed (in this release)
tiergarten.nod.xml ..................................... not listed (in this release)
tiergarten.rou.xml ..................................... not listed (in this release)
tiergarten.sumo.cfg .................................... not listed (in this release)
visualizer ........................................................................
visualizer_config.xml ................................. not listed (in this release)
vsimrti ............................................................................
vsimrti_config.xml ..................................... not listed (in this release)
Figure C.1: Scenario Tiergarten: folder structure
Appendix C Example scenario Tiergarten C.2 File listings
C.2 File listings
omnetpp/omnetpp.ini
1 [General]
2
3# SimulationParameters
4# --------------------
5# n et wo rk *. ned - f il e and ti me - scal e in nanosecond s
6 netw o r k = S i m u l a t i o n
7 s imti me - sc ale = -9
8
9# EventScheduler
10 # --------------
11 # scheduler - class and de b u g g i n g option for more v e rbose logging
12 sc hedul er - clas s = "VSimRTIEventScheduler"
13 vsimrtieventscheduler -debug = false
14 # c on ne ct io n setti ngs , wh en omnetpp - federate is start ed ma nu al ly
15 vsimrtieventscheduler -host = " l oc al host "
16 vsimrtieventscheduler -port = 4998
17
18 # RecordingModi
19 # -------------
20 record - e ventlog = fal se
21 c mden v - e xpre ss - mo de = fals e
22 c md env - ev ent - b an ner s = fa lse
23
24 # rand o m nu mbers
25 # -------------
26 num - r ngs = 3
27 Simulation . mobility .rng -0 = 1
28 S im u l at i on . w la n [ *] . m ac . rn g - 0 = 2
29
30 # general logging output
31 # --------------
32 *. m gmt . cm denv - ev - o ut pu t = tru e
33 *. mgm t . debu g = false
34 *. ve h [*].* *. cmd env - ev - o ut pu t = fal se
35 *. rs u [*].* *. cmd env - ev - o ut pu t = fal se
36
37
38 # ########## application settings ############
39 Simulation . rsu [*] . u dp Ap p . m axProcDel ay = 1 e -3
40 Simulation . veh [*] . u dp Ap p . m axProcDel ay = 1 e -3
41
42
43 # ########## UDP S et tings ### ## ## ## ## ## ##
44
45 # ########## n etwork laye r s et tings # ## ## ## ###
46
47 # ########## mac and phy s e t t i n gs ## ##########
48 * *. w lan0 . opMo de = " p"
49 * *. w la n0 . b it ra te = 6 M bp s
50
51 * *. w la n0 . m ac . b asic Bi tr ate = 3 M bps # we have to set this explicitly be cause the default value ⤦
Çof 1 M bps is n ot par t of 8 02 .1 1 p
52 * *. w la n0 . m ac . c on tr olBitra te = 3 M bp s
53 * *. w la n0 . m ac . r etryLimit = 7
54 * *. w la n0 . m ac . m axQu eu eS ize = 1 0
55 * *. w la n0 . m ac . c wMinDa ta = 15
56 * *. w la n0 . m ac . c wM in Multica st = 31
57
58
59 * *. w la n0 . radi o . ba ndN am e = " 5. 9 GHz " # this s tr in g actual ly s el ec ts the b and fro m { 2. 4; 5; 5.9 } ⤦
Ç( s ee " I I eee 80 2 11 B an d . h ")
60 * *. w la n0 . radi o . carri er Fr equenc y = 5.9 G Hz
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 124
Appendix C Example scenario Tiergarten C.2 File listings
61 * *. w la n0 . radi o . bandwi dth = 10 MH z
62 * *. w la n0 . radi o . re cei ve r . sn ir Th re shold = 4 dB
63 * *. w la n0 . radi o . re cei ve r . sensi ti vi ty = -81 dBm
64
65
66 * *. w lan1 . opMo de = " p"
67 * *. w la n1 . b it ra te = 6 M bp s
68 * *. w la n1 . m ac . b asic Bi tr ate = 3 M bps # we have to set this explicitly be cause the default value ⤦
Çof 1 M bps is n ot par t of 8 02 .1 1 p
69 * *. w la n1 . m ac . c on tr olBitra te = 3 M bp s
70 * *. w la n1 . m ac . r etryLimit = 7
71 * *. w la n1 . m ac . m axQu eu eS ize = 1 0
72 * *. w la n1 . m ac . c wMinDa ta = 15
73 * *. w la n1 . m ac . c wM in Multica st = 31
74
75 * *. w la n1 . radi o . ba ndN am e = " 5 .9 GHz " # thi s s tr in g actu ally selec ts the ba nd from { 2. 4; 5; 5 .9} ⤦
Ç( s ee " I I eee 80 2 11 B an d . h ")
76 * *. w la n1 . radi o . carri er Fr equenc y = 5.9 G Hz
77 * *. w la n1 . radi o . bandwi dth = 10 MH z
78 * *. w la n1 . radi o . re cei ve r . sn ir Th re shold = 4 dB
79 * *. w la n1 . radi o . re cei ve r . sensi ti vi ty = -81 dBm
80
81 # ########## radi o medium se t t i n g s # # # # # # # # ## #
82 Simulation . radioMedium . r ad io Mo de Fi lt er = t rue # u se th is f il te r fo r i ncr eased p er for ma nc e -> ⤦
Çdoes not co m pute t r ansmissions to receivers whose ra dio is t u rned off
83 Simulation . radioMedium . l is te ni ng Fi lt er = t rue # s econd filter that may improve p er fo rm an ce
84 Simulation . radioMedium . ba ck gr ou nd No is e . power = -110 dBm
85 Simulation . radioMedium . medium Li mi tC ac he . c ar ri er F re qu en cy = 5.9 GHz
86 Simulation . radioMedium . p ro pa ga ti on Ty pe = "ConstantSpeedPropagation"
87 Simulation . radioMedium . pathLoss Typ e = "FreeSpacePathLoss"
88 Simulation . radioMedium . o bs ta cl eL os sType = " "
89
90 # ########## mo bility ## ## ## ## ######## ## #
91 **. m obility . c on st ra intAreaM in X = 0 m
92 **. m obility . c on st ra intAreaM in Y = 0 m
93 **. m obility . c on st ra intAreaM in Z = 0 m
94 * *. m ob ilit y . c on str ai nt Ar ea Ma xX = 500 0 m
95 * *. m ob ilit y . c on str ai nt Ar ea Ma xY = 500 0 m
96 **. m obility . c on st ra intAreaM ax Z = 0 m
Listing C.1: Scenario Tiergarten: file listing: omnetpp/omnetpp.ini
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 125
Appendix D
Package Additional Examples
Appendix D Package Additional Examples Appendix D Package Additional Examples
This package shows different sample applications for several application spectrum. Here you can down-
load the AdditionalExamples-18.0-sources.zip file:
https://www.dcaiti.tu-berlin.de/research/simulation/download/
The following table describes these applications.
Applications from the "Additional Examples" package
HelloWorldApp
This is a simple Hello World application. It prints a hello world string
in an interval.
Interconnect
This simple application demonstrates an interconnection between
applications which are running on same units.
IntervalSampling
This simple application demonstrates a sampling in a specific interval.
When the simulation starts it initialise with a random generated offset
(e.g. 150 ms). Afterwards a fixed interval will be invoked (e.g. 1 second).
For example there are the following time steps:
t = {0 ms, 150 ms, 1150 ms, 2150 ms, ...}
MultithreadSampling
This simple application demonstrates a concurrency task. In a scenario
may exist many vehicles (e.g. veh_0, veh_1, veh_2, ...). This application
demonstrate the following behavior:
veh_0, veh_1, veh_2, ... start a thread
veh_0, veh_1, veh_2, ... do some logic parallel to each other
veh_0, veh_1, veh_2, ... join the thread
MyMessage This application shows how to create a message.
RandomSampling
This application demonstrates a sampling in a random interval. One
random simulation point will be choosen when the initialisation starts.
For example: t = {0 ms, 300 ms, 967 ms, 1487 ms, ...}
TestSumoTraciMsg
This sample shows the interaction between an application and the
TraCI interface of SUMO.
UpdateVehicleInfo
This application reacts on a vehicle info update. Mostly a vehicle info
will be triggered from a traffic simulator (e.g. SUMO).
UserTaggedValueRoundtrip
If the control of every byte is not needed, the
DefaultObjectSerial-
ization
can be used. This class converts an object into a byte field
and obversely.
VSimRTIMessage
This simple application shows how to create a VSimRTI-message and
sends it to all simulators. This application could also react on
Appli-
cationSpecificMessage s.
VehicleConfiguration This simple application demonstrates a configurable application.
Table D.1: Applications from the "Hello world package
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 127
Appendix E
Configuration Schemata
Some of the required
JSON
configuration files are automatically validated by
VSimRTI
and, therefore,
must follow a specific schema
1
. If you have problems with
VSimRTI
accepting your configuration files,
please make sure they follow the respective schema:
JSON Schema for cell2/cell2_config.json
1 {
2"$schema":" http :// json - schema . org / sc hema # ",
3" typ e ":" o bj ect " ,
4" properties ": {
5"bandwidthMeasurementInterval": { " typ e ":"number","minimum": 1 } ,
6" band w id th Me as ur em en ts " : {
7" typ e ":" a rr ay " ,
8" ite ms " : [
9 {
10 " typ e ":"object",
11 " properties ": {
12 " fromRegion ": { " type " :"string" },
13 " toRegion ": { " typ e ":" s tr ing " } ,
14 "transmissionMode": {
15 " typ e ":"string",
16 " enu m ": [ "UplinkUnicast","DownlinkUnicast","DownlinkMulticast" ⤦
Ç]
17 }
18 },
19 " required " : [
20 " fromRegion " ," to Re gion " ,"transmissionMode"
21 ]
22 }
23 ]
24 },
25 "networkConfigurationFile": { " type " :"string" } ,
26 "regionConfigurationFile": { " type " :" str in g " }
27 },
28 " required ": [
29 "networkConfigurationFile"
30 ]
31 }
Listing E.1: JSON Schema for cell2_config.json
1The schemata listed here follow the specification at http://json-schema.org/documentation.html
Appendix E Configuration Schemata Appendix E Configuration Schemata
JSON Schema for cell2/network_config.json
1 {
2"$schema":" http :// json - schema . org / sc hema # ",
3" typ e " :"object",
4" properties " : {
5"globalRegion" : {
6" typ e " :"object",
7" properties " : {
8"uplink" : {
9" typ e " :" obje ct " ,
10 " properties " : {
11 " del ay " :{" $re f " :" #/ d ef i ni t io n s / d el ay " },
12 " capacity " : { " $ ref " :" #/ definitions / capacity "}
13 },
14 " required " : [ " d el ay " ," c ap ac ity " ]
15 },
16 " downlink " : {
17 " typ e " :" obje ct " ,
18 " properties " : {
19 "unicast" : { " $ ref " :" #/ definitions / unicast "},
20 " multicast " : { " $ ref " :" #/ definitions / multicast "} ,
21 " capacity " : { " $ ref " :" #/ definitions / capacity "}
22 },
23 " required " : [ "unicast"," m ulticast " ," ca pa ci ty " ]
24 }
25 }
26 }
27 },
28 " required " : [ "globalRegion"],
29
30 " definitions " : {
31 " del ay " : {
32 " one Of " : [
33 {
34 " typ e " :" obje ct " ,
35 " properties " : {
36 " typ e " : {" typ e " :"string",
37 " enu m " : ["GammaRandomDelay","GammaSpeedDelay"]} ,
38 " minDelay " : { " t ype " :"number",
39 "minimum" : 0} ,
40 " expDelay " : { " t ype " :"number",
41 "minimum" : 0} ,
42 " prp l " : {" typ e " :"number",
43 "minimum" : 0} ,
44 "retries" : { " t ype " :" n umber " ,
45 "minimum" : 0}
46 },
47 " required " : [ " t ype " ," m in D el ay " ," e x pD elay " ," p rp l "]
48 },
49 {
50 " typ e " :" obje ct " ,
51 " properties " : {
52 " typ e " : {" typ e " :"string",
53 " enu m " : ["ConstantDelay"] } ,
54 " del ay " : {" type " :"number",
55 "minimum" : 0} ,
56 " prp l " : {" typ e " :"number",
57 "minimum" : 0} ,
58 "retries" : { " t ype " :" n umber " ,
59 "minimum" : 0}
60 },
61 " required " : [ " t ype " ," d el ay " ," p rp l "]
62 },
63 {
64 " typ e " :" obje ct " ,
65 " properties " : {
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 129
Appendix E Configuration Schemata Appendix E Configuration Schemata
66 " typ e " : {" typ e " :"string",
67 " enu m " : ["SimpleRandomDelay"]} ,
68 " ste ps " : {" type " :"number",
69 "minimum" : 0} ,
70 " minDelay " : { " t ype " :"number",
71 "minimum" : 0} ,
72 " maxDelay " : { " t ype " :"number",
73 "minimum" : 0} ,
74 " prp l " : {" typ e " :"number",
75 "minimum" : 0} ,
76 "retries" : { " t ype " :" n umber " ,
77 "minimum" : 0}
78 },
79 " required " : [ " t ype " ," s te ps " ," m i nD elay " ," m a xD elay " ," prpl " ]
80 }
81 ]
82 },
83 "unicast" : {
84 " typ e " :"object",
85 " properties " : {
86 " del ay " : {" $ref " :" #/ definitions / delay " }
87 },
88 " required " : [ " d elay "]
89 },
90 " multicast " : {
91 " typ e " :"object",
92 " properties " : {
93 " del ay " : {" $ref " :" #/ definitions / delay " },
94 "usableCapacity" : { " t ype " :" n umber " ,
95 "minimum" : 0.0 ,
96 "maximum" : 1.0}
97 },
98 " required " : [ " d elay " ,"usableCapacity"]
99 },
100 " capacity " : {
101 " one Of " : [
102 {
103 " typ e ":"integer",
104 "minimum": 0
105 },
106 {
107 " typ e ":"string",
108 "pattern" :" ^ unlimi ted$ "
109 }
110 ]
111 }
112 }
113 }
Listing E.2: JSON Schema for network_config.json
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 130
Appendix E Configuration Schemata Appendix E Configuration Schemata
JSON Schema for cell2/regions_config.json
1 {
2"$schema":" http :// json - schema . org / sc hema # ",
3" typ e " :"object",
4" properties " : {
5"regions" : {
6" typ e " :" arr ay " ,
7" ite ms " : [
8 {
9" typ e " :" obje ct " ,
10 " properties " : {
11 "polygon" : {
12 " typ e " :"object",
13 " coordinates " : [
14 {" $ref " :" #/ d ef i ni t io n s / g e op oi n t " }
15 ],
16 " required " : [ " c oo rdi nates " ]
17 },
18 " are a " : {
19 " typ e " :" obj ec t ",
20 " properties " : {
21 " nw " : {" $ref " :" #/ d ef in ition s / g eo p oi nt " },
22 " se " : {" $ref " :" #/ d ef in ition s / g eo p oi nt " }
23 },
24 " required " : [ "nw"," se " ]
25 },
26 " id " : { " typ e " :" strin g "},
27 " upli nk " : {
28 " typ e " :" obj ec t ",
29 " properties " : {
30 " del ay " : { " $re f " :" #/ d efinitions / dela y "},
31 " capacity " : { " $ref " :" #/ d efinit io ns / c ap a ci ty " }
32 },
33 " required " : [ " d elay " ," ca pa ci ty " ]
34 },
35 " downlink " : {
36 " typ e " :" obj ec t ",
37 " properties " : {
38 "unicast" : { " $ref " :" #/ d ef initions / unica st " },
39 " multicast " : { " $ ref " :" #/ d ef in it io ns / m ul ticast " },
40 " capacity " : { " $ref " :" #/ d efinit io ns / c ap a ci ty " }
41 },
42 " required " : [ "unicast"," m ulticast " ," ca pa ci ty " ]
43 }
44 },
45 " any Of " : [
46 {" required " : [ " a rea " ,"id","uplink"," downlink "]} ,
47 {" required " : [ "polygon","id","uplink"," d ow n li nk " ]}
48 ]
49 }
50 ]
51 }
52 },
53
54 " definitions " : {
55 " del ay " : {
56 " one Of " : [
57 {
58 " typ e " :" obje ct " ,
59 " properties " : {
60 " typ e " : {" typ e " :"string",
61 " enu m " : ["GammaRandomDelay","GammaSpeedDelay"]} ,
62 " minDelay " : { " t ype " :"number",
63 "minimum" : 0 ,
64 "exclusiveMinimum" : t rue } ,
65 " expDelay " : { " t ype " :"number",
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 131
Appendix E Configuration Schemata Appendix E Configuration Schemata
66 "minimum" : 0 ,
67 "exclusiveMinimum" : t rue } ,
68 " prp l " : {" typ e " :"number",
69 "minimum" : 0} ,
70 "retries" : { " t ype " :" n umber " ,
71 "minimum" : 0}
72 },
73 " required " : [ " t ype " ," m in D el ay " ," e x pD elay " ," p rp l "]
74 },
75 {
76 " typ e " :" obje ct " ,
77 " properties " : {
78 " typ e " : {" typ e " :"string",
79 " enu m " : ["ConstantDelay"] } ,
80 " del ay " : {" type " :"number",
81 "minimum" : 0 ,
82 "exclusiveMinimum" : t rue } ,
83 " prp l " : {" typ e " :"number",
84 "minimum" : 0} ,
85 "retries" : { " t ype " :" n umber " ,
86 "minimum" : 0}
87 },
88 " required " : [ " t ype " ," d el ay " ," p rp l "]
89 },
90 {
91 " typ e " :" obje ct " ,
92 " properties " : {
93 " typ e " : {" typ e " :"string",
94 " enu m " : ["SimpleRandomDelay"]} ,
95 " ste ps " : {" type " :"number",
96 "minimum" : 0} ,
97 " minDelay " : { " t ype " :"number",
98 "minimum" : 0 ,
99 "exclusiveMinimum" : t rue } ,
100 " maxDelay " : { " t ype " :"number",
101 "minimum" : 0 ,
102 "exclusiveMinimum" : t rue } ,
103 " prp l " : {" typ e " :"number",
104 "minimum" : 0} ,
105 "retries" : { " t ype " :" n umber " ,
106 "minimum" : 0}
107 },
108 " required " : [ " t ype " ," st eps " ," m in D el ay " ," m a xD elay " ," p rp l "]
109 }
110 ]
111 },
112 "unicast" : {
113 " typ e " :"object",
114 " properties " : {
115 " del ay " : {" $ref " :" #/ definitions / delay " }
116 },
117 " required " : [ " d elay "]
118 },
119 " multicast " : {
120 " typ e " :"object",
121 " properties " : {
122 " del ay " : {" $ref " :" #/ definitions / delay " },
123 "usableCapacity" : { " t ype " :" n umber " ,
124 "minimum" : 0.0 ,
125 "maximum" : 1.0}
126 },
127 " required " : [ " d elay " ,"usableCapacity"]
128 },
129 " geopoint " : {
130 " typ e " :"object",
131 " properties " : {
132 " lo n " : {" type " :"number"},
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 132
Appendix E Configuration Schemata Appendix E Configuration Schemata
133 " la t " : {" type " :"number"}
134 },
135 " required " : [ " l on " ," la t "]
136 },
137 " capacity " : {
138 " one Of " : [
139 {
140 " typ e ":"integer",
141 "minimum": 0
142 },
143 {
144 " typ e ":"string",
145 "pattern" :" ^ unlimi ted$ "
146 }
147 ]
148 }
149 }
150 }
Listing E.3: JSON Schema for regions_config.json
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 133
F References
[1]
BENZ, Thomas ; SCHÜNEMANN, Björn ; KERNCHEN, Ralf ; KILLAT, Moritz ; RICHTER, Andreas: A
Comprehensive Simulation Tool Set for Cooperative Systems. In:
Advanced Microsystems for
Automotive Applications 2010 : Smart Systems for Green Cars and Safe Mobility
(2010), May, S.
411–422. ISBN 978–3–642–12647–5
[2]
BISSMEYER, Norbert ; SCHÜNEMANN, Björn ; RADUSCH, Ilja ; SCHMIDT, Christian: Simulation of
attacks and corresponding driver behavior in vehicular ad hoc networks with VSimRTI. In:
Pro-
ceedings of the 4th International ICST Conference on Simulation Tools and Techniques
. ICST,
Brussels, Belgium, Belgium : ICST (Institute for Computer Sciences, Social-Informatics and Telecom-
munications Engineering), 2011 (SIMUTools ’11). – ISBN 978–1–936968–00–8, 162–167
[3]
CHUANG, David ; SCHÜNEMANN, Björn ; RIECK, David ; RADUSCH, Ilja: GRIND: An Generic Interface
for Coupling Power Grid Simulators with Traffic, Communication and Application Simulation Tools.
In:
SIMUL 2013, The Fifth International Conference on Advances in System Simulation
, 2013. –
ISBN 978–1–61208–308–7, S. 174–177
[4]
CODECÁ, Lara ; FRANK, Raphaël ; FAYE, Sébastien ; ENGEL, Thomas: Luxembourg SUMO Traffic
(LuST) Scenario: Traffic Demand Evaluation. In:
IEEE Intelligent Transportation Systems Maga-
zine 9 (2017), Nr. 2, S. 52–63
[5]
HÜBNER, Karl ; CRISTEA, Roland ; RULEWITZ, Stefan ; RADUSCH, Ilja ; SCHÜNEMANN, Björn: Im-
plementation of Cognitive Driver Models in Microscopic Traffic Simulations. In:
Proceedings of
the 9th EAI International Conference on Simulation Tools and Techniques
. ICST, Brussels, Bel-
gium, Belgium : ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications
Engineering), 2016 (SIMUTOOLS’16). – ISBN 978–1–63190–120–1, 104–111
[6]
HÜBNER, Karl ; SCHÜNEMANN, Björn ; RADUSCH, Ilja: Sophisticated Route Calculation Approaches
for Microscopic Traffic Simulations. In:
Proceedings of the 8th International Conference on Sim-
ulation Tools and Techniques
. ICST, Brussels, Belgium, Belgium : ICST (Institute for Computer
Sciences, Social-Informatics and Telecommunications Engineering), 2015 (SIMUTools ’15). – ISBN
978–1–63190–079–2, 147–154
[7]
HÜBNER, Karl ; SCHÜNEMANN, Börn ; SCHILLING, Tom ; RADUSCH, Ilja: On assessing road safety
aspects of a cycling router application. In:
2017 15th International Conference on ITS Telecom-
munications (ITST), 2017, S. 1–8
[8]
KATSAROS, Konstantinos ; KERNCHEN, Ralf ; DIANATI, Mehrdad ; RIECK, David ; ZINOVIOU, Char-
alambos: Application of vehicular communications for improving the efficiency of traffic in urban
areas. In: Wireless Communications and Mobile Computing 11 (2011), Nr. 12, S. 1657–1667
F References F References
[9]
LOBACH, S. ; RADUSCH, I.: Integration of Communication Security into Advanced Simulation
Environments for ITS. In:
Vehicular Technology Conference (VTC Fall), 2011 IEEE
, 2011. – ISSN
1090–3038, S. 1 –6
[10]
NAUMANN, Nico ; SCHÜNEMANN, Björn ; RADUSCH, Ilja: VSimRTI - Simulation Runtime Infras-
tructure for V2X Communication Scenarios. In:
Proceedings of the 16th World Congress and
Exhibition on Intelligent Transport Systems and Services (ITS Stockholm 2009)
, ITS Stockholm
2009, September 2009
[11]
NAUMANN, Nico ; SCHÜNEMANN, Björn ; RADUSCH, Ilja ; MEINEL, Christoph: Improving V2X
Simulation Performance with Optimistic Synchronization. In:
Services Computing Conference,
2009. APSCC 2009. IEEE Asia-Pacific, 2009. – ISBN 978–1–4244–5338–2, S. 52–57
[12]
PROTZMANN, R. ; MAHLER, K. ; OLTMANN, K. ; RADUSCH, I.: Extending the V2X simulation environ-
ment VSimRTI with advanced communication models. In:
ITS Telecommunications (ITST), 2012
12th International Conference on, 2012, S. 683–688
[13]
PROTZMANN, Robert ; MASSOW, Kay ; RADUSCH, Ilja: An Evaluation Environment and Methodology
for Automotive Media Streaming Applications. In:
Innovative Mobile and Internet Services in
Ubiquitous Computing (IMIS), 2014 Eighth International Conference on IEEE, 2014, S. 297–304
[14]
PROTZMANN, Robert ; MASSOW, Kay ; RADUSCH, Ilja: On performance estimation of prefetching
algorithms for streaming content in automotive environments. In:
Wireless On-demand Network
Systems and Services (WONS), 2014 11th Annual Conference on IEEE, 2014, S. 147–147
[15]
PROTZMANN, Robert ; SCHÜNEMANN, Björn ; RADUSCH, Ilja: The influences of communication
models on the simulated effectiveness of V2X applications. In:
Vehicular Networking Conference
(VNC), 2010 IEEE, 2010. – ISBN 978–1–4244–9526–9, S. 102 –109
[16]
PROTZMANN, Robert ; SCHÜNEMANN, Björn ; RADUSCH, Ilja: The influences of communication
models on the simulated effectiveness of V2X applications. In:
Communications Magazine, IEEE
49 (2011), november, Nr. 11, S. 149 –155.
http://dx.doi.org/10.1109/MCOM.2011.6069722
. –
DOI 10.1109/MCOM.2011.6069722. – ISSN 0163–6804
[17]
PROTZMANN, Robert ; SCHÜNEMANN, Björn ; RADUSCH, Ilja: Effects of Random Number Gener-
ators on V2X Communication Simulation. In: TAN, Gary (Hrsg.) ; YEO, GeeKin (Hrsg.) ; TURNER,
StephenJohn (Hrsg.) ; TEO, YongMeng (Hrsg.):
AsiaSim 2013
Bd. 402, Springer Berlin Heidelberg,
2013 (Communications in Computer and Information Science). – ISBN 978–3–642–45036–5, 200-211
[18]
PROTZMANN, Robert ; SCHÜNEMANN, Björn ; RADUSCH, Ilja: On Site-Specific Propagation Models
for the Evaluation of V2X Applications. In:
Communication Technologies for Vehicles (Nets4Cars-
Fall), 2014 7th International Workshop on IEEE, 2014, S. 35–39
[19]
PROTZMANN, Robert ; SCHÜNEMANN, Björn ; RADUSCH, Ilja: A Sensitive Metric for the Assessment of
Vehicular Communication Applications. In:
Advanced Information Networking and Applications
(AINA), 2014 IEEE 28th International Conference on IEEE, 2014, S. 697–703
[20]
QUECK, Tobias ; SCHÜNEMANN, Björn ; RADUSCH, Ilja: Runtime Infrastructure for Simulating
Vehicle-2-X Communication Scenarios. In:
VANET ’08: Proceedings of the fifth ACM international
workshop on VehiculAr Inter-NETworking
. New York, NY, USA : ACM, 2008. – ISBN 978–1–60558–
191–0, S. 78–79
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 135
F References F References
[21]
QUECK, Tobias ; SCHÜNEMANN, Björn ; RADUSCH, Ilja ; MEINEL, Christoph: Realistic Simulation of
V2X Communication Scenarios. In:
APSCC ’08: Proceedings of the 2008 IEEE Asia-Pacific Services
Computing Conference
. Washington, DC, USA : IEEE Computer Society, 2008. – ISBN 978–0–7695–
3473–2, S. 1623–1627
[22]
RIECK, David ; SCHÜNEMANN, Björn ; RADUSCH, Ilja ; MEINEL, Christoph: Efficient traffic simulator
coupling in a distributed V2X simulation environment. In:
SIMUTools ’10: Proceedings of the
3rd International ICST Conference on Simulation Tools and Techniques
. ICST, Brussels, Belgium,
Belgium : ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications
Engineering), 2010. – ISBN 978–963–9799–87–5, S. 1–9
[23]
SCHÜNEMANN, Björn: V2X simulation runtime infrastructure VSimRTI: An assessment tool to
design smart traffic management systems. In:
Computer Networks
55 (2011), October, 3189–
3198.
http://dx.doi.org/http://dx.doi.org/10.1016/j.comnet.2011.05.005
. – DOI
http://dx.doi.org/10.1016/j.comnet.2011.05.005. – ISSN 1389–1286
[24]
SCHÜNEMANN, Björn ; MASSOW, Kay ; RADUSCH, Ilja: A Novel Approach for Realistic Emulation
of Vehicle-2-X Communication Applications. In:
Vehicular Technology Conference, 2008. VTC
Spring 2008. IEEE, 2008. – ISSN 1550–2252, S. 2709–2713
[25]
SCHÜNEMANN, Björn ; MASSOW, Kay ; RADUSCH, Ilja: Realistic Simulation of Vehicular Commu-
nication and Vehicle-2-X Applications. In:
Simutools ’08: Proceedings of the 1st international
conference on Simulation tools and techniques for communications, networks and systems &
workshops
. ICST, Brussels, Belgium, Belgium : ICST (Institute for Computer Sciences, Social-
Informatics and Telecommunications Engineering), 2008. – ISBN 978–963–9799–20–2, S. 1–9
[26]
SCHÜNEMANN, Björn ; RIECK, David ; RADUSCH, Ilja: Performance and scalability analyses of
federation-based V2X simulation systems. In:
Ad Hoc Networking Workshop (Med-Hoc-Net), 2012
The 11th Annual Mediterranean, 2012. – ISBN 978–1–4673–2038–2, S. 119 –126
[27]
SCHÜNEMANN, Björn ; WEDEL, Jan W. ; RADUSCH, Ilja: V2X-Based Traffic Congestion Recognition
and Avoidance. In:
Tamkang Journal of Science and Engineering
13 (2010), March, Nr. 1, 63-70.
http://www2.tku.edu.tw/~tkjse/13-1/catology.htm. – ISSN 1560–6686
[28]
WEDEL, Jan W. ; SCHÜNEMANN, Björn ; RADUSCH, Ilja: V2X-Based Traffic Congestion Recognition and
Avoidance. In:
Parallel Architectures, Algorithms, and Networks, International Symposium on
0 (2009), S. 637–641.
http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/
I-SPAN.2009.71
. – DOI http://doi.ieeecomputersociety.org/10.1109/I–SPAN.2009.71. ISBN 978–0–
7695–3908–9
VSimRTI: Vehicle-2-X Simulation Runtime Infrastructure 136

Navigation menu