IEEE INTELLIGENT TRANSPORATION SYSTEMS MAGAZINE, VOL. 2, NO. 3, FALL 2010 1

Realizing an effective and flexible ITS evaluationstrategy through modular and multi-scaled traffic

simulationMathias Baur, Matthew Fullerton, Fritz Busch

Abstract —The next generation of transportation systems employing advanced ITS and vehicular inter-networkingare difficult to evaluate because of their inherent complexity. Advanced control algorithms, sensor setups, multiplecommunication media, and the varying driver reactions require new planning and evaluation strategies. While simulationtools are often used to study the likely effects of such systems in advance, we do not fully know what to expect as theoutcome of a given implementation, making it difficult to validate a simulation’s output. Data collection from a varietyof field-tests is beginning to provide this data, but simulation definition, implementation and validation tools are all inneed of improvement in order to keep up. Here we propose a new simulation framework that can translate a single ITSuse case to different simulation tools with multiple traffic networks and/or data sets. This allows simulation tools to becompared and combined as appropriate for the given use case in order to improve both the validity and scalability of thesimulation, and to facilitate better cooperation between those working in this rapidly developing field.

Index Terms —ITS, traffic simulation, simulation framework, vtSim, multi-scaling, simulation evaluation, validation,communication modeling.

✦

COPYRIGHT NOTICE

This is the submitted accepted manuscript forpublication in the IEEE ITS Magazine Fall 2010with minor corrections added by the authors.This manuscript c© 2010 IEEE. Personal useof this material is permitted. Permission fromIEEE must be obtained for all other uses, inany current or future media, including reprint-ing/republishing this material for advertisingor promotional purposes, creating new col-lective works, for resale or redistribution toservers or lists, or reuse of any copyrightedcomponent of this work in other works.

1 INTRODUCTION

THE central problem facing new Intelli-gent Transportation Systems (ITS) stake-

holders is an uncertainty of the likely effects

• M. Baur, M. Fullerton, F. Busch are with the Departmentof Traffic Control and Engineering, Technische UniversitatMunchen, Munich, Germany.E-mail:mathias.baur@vt.bv.tum.de,matthew.fullerton@vt.bv.tum.de, fritz.busch@vt.bv.tum.de

of such systems on a large scale. Small-scaledriver warning and assistance systems (withand without networking technologies) have en-joyed far more rapid deployment partly be-cause they can be easily tested with a singleequipped vehicle amongst unequipped traffic.When it comes to networking large numbersof vehicles with a specific traffic safety or ef-ficiency goal in mind, a portion of the trafficnetwork with its population of vehicles has tobe considered. Hence the exploration of thesesystems is proceeding with both field tests(e.g. EuroFOT, COOPERS, simTD) and trafficsimulations.

Transportation science considers field testsunable to examine truly large scale scenarios(i.e. anything above a few percent of vehi-cles equipped with a cooperative system underhigh traffic volumes) while policy makers (i.e.field test funders) deem simulation in this areato be largely unvalidated because there is nosuitable field test results available for compar-ison. This is different from conventional trafficsimulation of existing one-to-many ITS applica-tions, where the communication method, exact

IEEE INTELLIGENT TRANSPORATION SYSTEMS MAGAZINE, VOL. 2, NO. 3, FALL 2010 2

locations of the distributed data (e.g. variablemessage signs) and effects on the traffic flowcan be easily established.

To help overcome this conflict, we propose anew simulation framework, that can translatediverse ITS data and applications to differentsimulation tools and handle the resulting di-verse types of output. This not only solves thepractical issues of combining diverse data andtools, but also allows them to be compared andcombined as appropriate for the given researchquestion.

The motivation behind the framework is ex-plained in Section 2. Previous and current workin the same area is briefly reviewed in Sec-tion 3 before laying out a set of requirementsin Section 4. The framework is then describedin detail in Section 5. A simple feasibility studyusing a skeleton implementation of the frame-work has been performed and the results arepresented in Section 6. Finally, an outlook forfuture work is laid out in Section 7.

2 MOTIVATION

Modern ITS applications employ both newdriver information and communication be-tween vehicles and the infrastructure or othervehicles. For valid simulation-based testing, werequire the ability to simulate each compo-nent of the system easily and accurately andalso to be able to integrate smaller-scale real-world data. This comes not only from infras-tructure/vehicle trials but also from tests withdrivers to examine how the new systems’ in-terventions are acted upon.

The individual components necessary tomeet these goals have for the most part alreadybeen developed. What is lacking is a methodwhereby they can be combined in a flexibleway to examine the proposed system at hand.As the scope of traffic simulation grows, suchan approach could also facilitate the simulationof some elements in detail and others in ap-proximation through the use of multiple simu-lation tools in parallel or in sequence (termedmulti-scaling in this paper). Hence, tools for thecombined evaluation of diverse results typesmust also be included.

Such a framework also holds some advan-tages of convenience and efficiency. It allowssoftware once seen as ‘bespoke’ to be usedagain in new situations. Although multipleimplementations of certain tools are desirableto aid validation, continuous reinventing of thewheel is clearly not. Furthermore, any attemptto improve the interoperability of different dataand network definition formats would likely bewelcomed by the traffic simulation community.By suitable abstraction of the integrated tools,the ‘glue’ of the framework can be publishedas open-source code for the simulation com-munity while still allowing the use of closed-source, commercial tools. This allows a richarray of simulation tools to be compared andcombined as appropriate for the given usecase in order to improve both the validity andscalability of the simulation, and cooperationbetween those working in this rapidly devel-oping field to be improved.

3 PREVIOUS AND ONGOING WORK

ITS applications have been one of the maindriving forces behind the increased modu-larization of traffic simulation. Through theprovision of modifiable software components(through scripting or recompilation) and appli-cation programming interfaces (API, e.g. COMon the Windows platform), engineers havebeen able to test various novel ideas (e.g.automated platoon management[3]). However,having to write new code for a single APIseverely limits general reusability.

In particular, much work has been car-ried out in the area of attaching communi-cation simulations to existing traffic simula-tions. There are very mature tools availablein both fields, and so a specialized couplingbetween the two is often seen as the mostexpedient way to test modern vehicle com-munication scenarios. One ongoing approachis the iTETRIS Project (http://www.ict-itetris.eu/),which aims to standardize the simulation ofcommunication in traffic networks through theEuropean Telecommunications Standards Insti-tute (ETSI). The project, funded by the Euro-pean Research Framework Programme 7 (FP7),

IEEE INTELLIGENT TRANSPORATION SYSTEMS MAGAZINE, VOL. 2, NO. 3, FALL 2010 3

aims to tightly integrate the traffic simula-tion SUMO[13] and the network simulationns-3[1], in a replicable and standardized way.The project is based upon the ETSI standardfor Intelligent Transportation Systems in termsof what aspects need to be simulated[10].A more flexible approach has been providedby the V2X Simulation Runtime Infrastructure(VSimRTI)[15]. This uses existing interfaces torun parallel simulations with multiple trafficsimulation tools and a single communicationssimulation[2], [16]. Although existing interfacesare used, they are wrapped in such a way thata developer can easily add another tool bywriting a similar wrapper. The framework alsoreduces computation times by using a morespatially detailed simulation tool only whererequired (i.e. complex intersections with ro-taries or traffic lights), while utilizing the samemap and communication model throughout.The runtime infrastructure is used to synchro-nize the simulation tools. Another example ofsuch multi-scaling is the traffic simulation toolAIMSUN (TSS, Barcelona) which allows micro,meso and macro elements to be connectedand run in parallel. However, AIMSUN is aclosed implementation, making the connectionof other external elements at the various scalesdifficult. Rather than run parallel simulations,the goal of our work is to provide diversedata sets and communication models to dif-ferent simulation engines, without trying tomaintain further control over the simulationsthemselves.

4 REQUIREMENTS

As described above, there is a need for anextensible, reusable, flexible and efficient sim-ulation framework for the testing of ITS appli-cations. The framework must provide:

• Use of a common network definition for-mat

• Use of a common scenario definition for-mat

• Separation and abstraction of the applica-tion logic

• Necessary merging of the above data asappropriate for each tool employed

• Separation and abstraction of communica-tion model from core simulation tool

• Use of a common data collection format• Provision of tool-specific-to-generic trans-

lation layers (input and output)• Output of a common results format with

respect to the original input data

Concerning file formats, it is desirable touse XML-based format specifications, as theycan be efficiently read, exchanged, and theirformat defined in a standardized way usingXML schema (XSD).

As noted in [15], if the simulations are tobe used in parallel and feed vehicles to andfrom one another, additional requirements onsynchronization would be necessary. Particu-larly important is the requirement of temporalsynchronization (i.e., that no vehicle can bein two simulations at once)[15]. However, forcertain scenarios (such as an on-ramp with anin-flow and out-flow) this requirement couldbe relaxed allowing simulations to be run insequence, with the framework tracking outputsand feeding them to the next more or less-detailed simulation. As one simulation’s out-put is another’s input, we require a commonapproach for input and output data. Such anapproach can also ease comparisons necessaryfor calibration and validation of the simula-tion (Section 5.3.2). By taking this commonapproach to input and output data, calibrationof the traffic simulation is also eased.

As mentioned in Section 3, the separationof the communication model from the trafficsimulation has long been a popular choice. Thecommunication in the scope of cooperative ITSsystems is not something (yet) that is necessaryfor the majority of traffic simulations, henceit makes sense to include it only optionally.Most existing work has taken the approachof simulating the communication in the samedetail as the vehicles (i.e. car to car packetmovements), e.g. [9], [6], [14]. This makes theadded complexity highly computationally ex-pensive, making its optional inclusion evenmore important. This is coupled with a needat this stage of still-emerging technologies andstandards to simulate many different commu-nication media[10].

IEEE INTELLIGENT TRANSPORATION SYSTEMS MAGAZINE, VOL. 2, NO. 3, FALL 2010 4

In terms of testing new ITS applications,new data is becoming available on the effectof information on the driver response. As asimple example, the ‘green light optimal speedadvisory’[4] ought to make a drastic change inthe driver’s normal braking and accelerationprofile (or more directly, a change in speed).Hence, the framework has to preserve tradi-tional, validated models of driving while beingable to make changes to the driving parameters(such as desired speed) that give simulationresults that are qualitatively similar to thoseobserved in driver testing.

5 FRAMEWORK DESCRIPTION

The approach described here focuses on theevaluation of ITS applications regarding traf-fic efficiency and safety. The goal is the cal-ibration and validation of diverse behavioral,traffic flow and communication models as wellas highly efficient, flexible and valid simula-tion of their application. The framework cou-ples modules in such a way so that no un-necessary overhead is generated while stillpreserving flexibility. In the following, it willbe termed vtSim (Validating environment forTraffic Simulation). The framework enablesmulti-scaling - the combination of appropriatetools at different modeling scales so that large-scale scenarios with a small number of small-scale changes can be examined (for example,the merging behavior at an on-ramp beinghighly relevant, but the traffic movements onthe main carriageway being of less interest).

The software language for those componentsof the framework that need to be newly devel-oped is Java due to its flexibility, understand-ability and frequency of use in the embeddedtechnology market. A block diagram showingthe framework’s major components is shownin Figure 1, and the individual components aredescribed in the paragraphs below.

5.1 Traffic, map and infrastructure data

The first step in preparing an application sim-ulation is the provision of data for input trafficflows and for the purposes of driver modelcalibration and validation (see Section 5.3.2).

Custo

DATEX II

Combina

Scenario

definition

VISSIM-

Wrapper

Communication

Model VISSIM

VISSIM C2X

JNI

Vehicle Positioning

and

Parameter Changes

via…

Traffic Safe

R

Behavioral

DataGIS

SUMO-

XML

om Data Interpreter(s)

Application

ation & Scaling Manager

Road

network

Generic

Wrapper

SUMO-

Wrapper …

Assig

n

Simulation

Tool

Sim API

SUMO

TraCI

<Protocoll>UDP

…

…

nm

en

t Wra

pp

er(s

)

Tool

ty and Efficiency measures

Results Manager

Fig. 1. The framework vtSim unites severalcore components containing simulation modelsand tools as well as functionality for wrappingand processing different simulation data andapplication/control algorithms.

Internally, data sets relevant to one simulationbasis are established. These may contain multi-ple forms of traffic data, such as detector dataor locations of lane changes (e.g. from overheadtrajectory recording). Each of these differenttypes is extended from a common base class tofacilitate plotting and data exchange. A goodbasis format for this data is the DATEX IIstandard[5] for exchanging traffic data betweenroad authorities, but additional data readingclasses can be plugged in so long as they sup-ply data in the common internal format. Datasuitable for deriving routing and traffic inputscan also be exported in the SUMO DFROUTERformat[5] (which are used internally by theframework, see below).

The same philosophy has been applied toroad network and infrastructure data. Here,the internal format is a Java representationof nodes, edge and connections based on theSUMO-XML-Schema. Again, foreign formatsare transformed to this common representation.One is the OpenStreetMap[11] database/file

IEEE INTELLIGENT TRANSPORATION SYSTEMS MAGAZINE, VOL. 2, NO. 3, FALL 2010 5

format. Hence, all important objects and infor-mation which need to be mapped from the realworld into a simulation road network can beprovided, such as:

• Roads and intersection represented asnodes and edges with exact positioningand identification and further informationsuch as

– Road type (e.g. highway or urbanstreet)

– Number of lanes

• Traffic light signals, mapped on roads,lanes and signal phases

• Priority rules• Detectors and measurement infrastructure• Traffic flow data

5.2 Combination and Scaling Manager

Ensuring that the right data is provided tothe right modules is the responsibility of thecombination and scaling manager. Based onthe scenario definition, the correct tools areselected (according to, for example, the scaleof detail of the simulation required). On thebasis of the supplied data, routes are generatedfor the vehicles in the simulation (this canbe accomplished, for example, by calling theSUMO DFROUTER tool). The complete inputof vehicle inputs and routes for the simulationtools is then translated from the final genericdata by specific assignment wrappers.

The manager is also responsible for assigningstarting characteristics for the simulation suchas vehicle characteristics or model selection. Adistinction is made between this, model andparameter-set assignment process, and the de-tailed simulation-application interaction that isfacilitated by other dedicated wrappers. Theformer is a one-time operation that leaves thesimulation tool free to proceed. The latter isa constant interaction of information provisionto the application and returned results of howindividual driver-vehicle unit behaviors shouldbe altered (see below).

The manager also configures what datashould be recorded from the simulation(s) tofacilitate the calibration, validation and multi-scaling processes. This includes the initial setup

of the various wrappers so that interaction withthe application can proceed.

5.3 ITS Application and altering of drivingbehavior5.3.1 ApplicationThe application is expected to be different forevery project and therefore will be written bythe simulation user. In order to make his orher life as straightforward as possible, an ITSapplication Java class is provided that can beextended to define the functionality of the ap-plication. Hence, it needs to be implementedagainst this well defined programming inter-face and does not need to take into accountwhich simulation tool is actually used. The in-terface wrappers for each supported simulationtool will handle the appropriate connectionbetween the vtSim API and the simulationtools’ programming interface. Depending onthe relevant tools’ interface implementation,the connection is realized in a way that is asappropriate as possible with respect to func-tionality and runtime efficiency.

5.3.2 Driver Behavior ModificationThe most crucial aspect of a valid traffic sim-ulation study is the gain of relevant, reliableand realistic results regarding traffic efficiencyand/or safety. For this purpose, the models fortraffic flow as well as for the driving behaviormust be calibrated to ensure that the interpre-tation of the measures of traffic flow in thewhole system can be relied upon. As a first stepfor driving behavior modeling and calibration,there must be a decision for an appropriatebasic model and, as a result, a decision for asimulation tool which uses this specific basemodel if there is any already available. Eachmodel needs input data from reality in orderto calibrate it appropriately. In terms of drivingbehavior, microscopic parameters of drivingprocesses must be assigned. The most impor-tant ones being acceleration, desired speed,desired/minimum following distance and lanechanging constraints.

These parameters can be set based on pre-vious knowledge, data taken directly from anequipped-vehicle or driving simulator, or can

IEEE INTELLIGENT TRANSPORATION SYSTEMS MAGAZINE, VOL. 2, NO. 3, FALL 2010 6

be fitted based on an iterative adjustment ofthe parameters to match global traffic flowmeasures. In either case the simulation mustbe subject to a validation against traffic flowdata from the real world (which has not beenused for calibration of the model). Traffic flowindicators for such a validation are traffic flowper hour, traffic density per kilometer and ag-gregated travel times among others.

Most simulation tools allow a flexible en-hancement or even a complete replacement ofthe behavioral model. The framework makesuse of this possibility to affect the drivingbehavior, within the scope of special situa-tions which are relevant with respect to theITS application defined (see above). Respec-tive behavioral data can be gained by drivingsimulator studies or real world tests of ITSapplications. Broadly speaking, there are twoways with which to enhance a traffic simulatorbehavior model in order to fulfill the require-ments of a dedicated simulation study:

• Various behavioral data need to be col-lected, aggregated and correctly appliedto the behavioral model thus extendingthe original model of the used simulationtool via new statistical distributions basedon microscopic data from vehicles in thereal world or in a driving simulator. Themodel is then affected purely by differentparameters which can be pre-assigned orswitched during runtime.

• Using a validated basic behavior modelfor general road traffic and overwritingit occasionally in specific situations. Theregarded situations have to be definedclearly (e.g. reaction to a system warn-ing). The model can then be dynamicallyswitched during runtime.

The framework offers the flexibility to definethe appropriate approach based on the config-uration selected by the user.

5.3.3 Communication model

The communication model governs the com-munication processes that have an impact onthe driving behavior within the scope of theITS application under test. The IDs of thosevehicles that have received messages will be

handed to the ITS application which can useit as a basis for the implementation of thesituational behavior model for those vehicles.The communication model can request trafficflow information from the respective simula-tion tool, and use this as a basis for decidingwhat communication takes place and is suc-cessful. This information is transferred fromthe simulation tool over a wrapper that isparticular to the simulation tool in use.

5.3.4 Simulation tool

A simulation tool executes the flow of vehi-cles via basic driver-vehicle models, a modelof the simulated road network and conductssimulations based on parameters (usually se-lected at random from a specified distribution).Usually, a graphical interface can be used inorder to setup and monitor the simulation.From the simulation tool access to vehicles’desired speeds, desired destinations and eachvehicle’s position is required. Macroscopically,we require measures such as link speed andintensity to provide data to the scenario deci-sion processes. Which traffic simulation tool(s)is/are to be used depends on the requirementsand aims of the simulation study. Differentsimulation tools, model implementations andparadigms are flexibly interchangeable or evencombinable within the framework.

5.3.5 Scenario Definition

The scenario definition, written in XML, de-fines which scenarios should be examined withwhich combination of tools. The relevant net-work portions, data sets and ITS applicationsare selected along with important parametersfor the ITS application at hand (e.g. rate ofequipped vehicles).

5.3.6 Results Manager

After a simulation study is conducted withthe use of these components, the output dataof the simulation tool(s) are collected by theresults manager. The results manager mod-ule provides automatic processing of simula-tion results in order to gather indicator val-ues regarding traffic safety and efficiency. Anysimulation tool and model produces results

IEEE INTELLIGENT TRANSPORATION SYSTEMS MAGAZINE, VOL. 2, NO. 3, FALL 2010 7

in a very specific way that makes it difficultor even impossible to compare and aggregatewithout a deeper insight and a careful han-dling of those data. Additionally the aggre-gated data provided are often not readily in-terpretable regarding traffic safety measures.To overcome this, simulation specific data canbe translated to the Surrogate Safety Assess-ment Module (Siemens Traffic Solutions, TX)format. This module (distributed free of chargeas a Java Application) permits the calculationof various measures that are proxy indica-tors for safety such as Time-To-Collision andPost-Encroachment-Time[8]. The results man-ager can also handle all data given as input forthe simulations thanks to the generic storageformat used by vtSim. This allows easy com-parison of real-world and simulated data forthe purposes of calibration/validation.

6 FEASIBILITY STUDY

The implemented vtSim framework core hasbeen tested in the scope of a feasibility study.It comprised a series of simulation studiesanalyzing a cooperative weather warning sce-nario. For the study we have used the simu-lation tool PTV Vision VISSIM, version 5.20.The connection between the vtSim applicationinterface and the VISSIM C2X interface libraryis handled by UDP sockets. In addition to theseconnection components, the necessary data in-put, map input, assignment management andresults display interface have also been imple-mented and tested.

6.1 Application and Behavioral Impact

The application evaluated is a cooperativewarning of standing water on the road ahead.All vehicles (traveling with a mean speed of80km/h) crossing the affected area send analert, and following vehicles in reception rangeare warned of the danger and instructed toslow down to a speed of 40km/h. In this exam-ple, drivers who receive the alert comply withthe information within the normal simulatedrange of deviation.

6.2 Communication ModelConsidering that the communication can beadded as an optional element in such a frame-work, it is very attractive to consider whetherits simulation can be simplified without loss ofaccuracy of the traffic effects. Through hybridsimulation[17] a sophisticated communicationmodel based on real data, instead of a fullparallel simulation of the ongoing networkcommunication, can be used[12]. The modelof Killat et al. requires the position of thesending vehicle and all equipped vehicles anduses multiple probability distributions (accord-ing to surrounding vehicle density) based onns-2 (www.isi.edu/nsnam/ns/) simulations to as-certain which vehicles successfully receive amessage[12]. It is used here in a simpler formthat ignores surrounding traffic density. Thecommunication model provides back to theapplication a list of vehicles which have suc-cessfully received a message. This informationis supplied by the same wrappers describedabove.

6.3 Demand and Map InputThe map for the simulation is taken from anedited portion of OpenStreetMap data betweenthree villages in the greater Munich area (Fig-ure 2). Traffic demand is entered directly usingthe Java user interface as fictitious traffic de-tectors. The demand (500veh/h entering frompoint A and 250veh/h exiting at point C, seeFigure 2), is used internally to generate thetraffic inputs and routes for the two simula-tions by the combination and scaling manager(Section 5.2). Hence, half the traffic will passover the standing water area (on the final linktowards point C) and half exits before this overa side road.

6.4 ResultsThe results show that traffic flow in both theno-intervention and application cases is ex-tremely similar. With both simulation tools wesee that traffic speed throughout the networkis slowed as desired. The first simulation wasconducted as a pure PTV Vision VISSIM 5.20simulation without processing any external ap-plication. The relevant traffic flow profile is

IEEE INTELLIGENT TRANSPORATION SYSTEMS MAGAZINE, VOL. 2, NO. 3, FALL 2010 8

B

(From Grasbrunn)

A

(From Putzbrunn)

(To Niederpframmern)

C

Fig. 2. Map transformation in vtSim. Toppane shows the feasibility study area (fromwww.openstreetmap.org). The lower two panesshow the map transformed for VISSIM andSUMO respectively. The map is first trans-formed to the open source SUMO XML formatbefore being imported into a Java representa-tion of the XML-Schema whereby it can be usedfurther and exported to VISSIM..

shown in the upper graph of Figure 3. Asexpected, no change in the speed profile can

be seen. A second simulation study used thecooperative warning described above and im-plemented for VISSIM’s C2X interface[12]. Thewarning is sent as soon as the vehicle entersthe area of the dangerous weather condition.Here, the effect of the speed reduction warningis reflected in a decrease in average speed forthe warning range. The speed reduction is seenat different locations owing to the different lo-cations of vehicles at the time of reception. Forthe last simulation, another version of the co-operative weather warning was implemented,this time as a Java model that was connectedwith the vtSim application interface and therespective communication model abstraction.The simulation outcome is nearly the same asin the preceding simulation. Again, the speedreduction in consequence of the warning leadsto a speed reduction for the surrounding trafficflow. The duration of the three simulations wasequal (3600 simulation seconds). After everysimulation run, the data were processed viathe vtSim results manager. The simulation re-sult plots were generated via the vtSim resultsmanager and shown in Figure 3.

This result shows that the approach is tech-nically feasible and suggests that the use ofdifferent techniques and models in the scope ofthe presented simulation framework is valid.

7 OUTLOOK

The need to examine potential vehicular inter-networking systems requires flexible simula-tion strategies both because of the nature of theelements to be examined and the greater needfor validation and comparison across tool sets.In addition, in such a rapidly developing field,it makes little sense for advances by one groupof researchers to be unusable by others simplybecause of the tool choice made.

Here a flexible simulation framework,dubbed ‘vtSim’ has been proposed thataddresses these issues. Several of the necessarynew components of the framework that ‘glue’existing tools together are already in use. Theimplementation has already made use of otheropen source software, in particular SUMO,and it is hoped it can continue to be extendedto improve the diversity of data and tools used

IEEE INTELLIGENT TRANSPORATION SYSTEMS MAGAZINE, VOL. 2, NO. 3, FALL 2010 9

0

5

10

15

20

25

30

35

40

45

50

55

60

65

70

75

80

85

90

95

100

Velo

city (

km

/h)

0 5 10 15 20 25 30 35 40 45 50 55 60

Time (minutes)

-0,75

-0,50

-0,25

0,00

0,25

0,50

0,75

1,00

1,25

1,50

1,75

2,00

2,25

2,50

2,75

3,00

3,25

3,50

3,75

4,00

4,25

4,50

4,75

5,00

Dis

tan

ce

(km

)

0

5

10

15

20

25

30

35

40

45

50

55

60

65

70

75

80

85

90

95

100

Velo

city (

km

/h)

0 5 10 15 20 25 30 35 40 45 50 55 60

Time (minutes)

-0,75

-0,50

-0,25

0,00

0,25

0,50

0,75

1,00

1,25

1,50

1,75

2,00

2,25

2,50

2,75

3,00

3,25

3,50

3,75

4,00

4,25

4,50

4,75

5,00

Dis

tan

ce

(km

)

0

5

10

15

20

25

30

35

40

45

50

55

60

65

70

75

80

85

90

95

100

Ve

locity (

km

/h)

0 5 10 15 20 25 30 35 40 45 50 55 60

Time (minutes)

-0,75

-0,50

-0,25

0,00

0,25

0,50

0,75

1,00

1,25

1,50

1,75

2,00

2,25

2,50

2,75

3,00

3,25

3,50

3,75

4,00

4,25

4,50

4,75

5,00

Dis

tan

ce

(km

)

1) VISSIM simulation without warning

2) VISSIM simulation with weather warning via VISSIM C2X API

3) VISSIM simulation with weather warning via vtSim

Fig. 3. Traffic speed profile for the area ofa dangerous weather scenario (ca. at km 3):1. without warning, 2. with weather warning inPTV Vision VISSIM via VISSIM C2X API, 3. withweather warning via vtSim using a connectionto VISSIM C2X API. All figures were generatedusing the vtSim results manager.

from researchers elsewhere in order to fostergreater collaboration and interoperability.

In order to accurately simulate the ef-fects of ITS systems, the correct response of

the driver must also be modeled, calibratedand validated[7], rather than assumed (Sec-tion 5.3.2). Although not discussed here, thereare already widely-in-use systems for the gath-ering of human-response driving data, such asthe driving simulation software SILAB (WIVW,Wurzburg, Germany). In the future, we willexplore whether automated integration of suchdata can also be applied to the applicationmodule, and what role such human data couldalso play in the results manager processing.

ACKNOWLEDGMENT

This work has been part-funded by the EU7th Framework Programme research project“Complex socio-technical system in ambient in-telligence” (SOCIONICAL) in the area of “Sci-ence of complex systems for socially intelligentICT”.

IEEE INTELLIGENT TRANSPORATION SYSTEMS MAGAZINE, VOL. 2, NO. 3, FALL 2010 10

REFERENCES

[1] A. Alvarez, R. Orea, S. Cabrero, X. G. Paneda, R. Garcıa,and D. Melendi. Limitations of network emulation withsingle-machine and distributed ns-3. In Proceedings ofSIMUTools Conference, 2010, March 2010.

[2] R. Barr, Z. Haas, and R. van Renesse. JiST: An efficientapproach to simulation using virtual machines. SoftwarePractice and Experience, 35(6):539–576, 2005.

[3] T. Dao, C. Clark, and J. Huissoon. Distributed platoonassignment and lane selection for traffic flow optimiza-tion. In 2008 IEEE Intelligent Vehicles Symposium, pages739–744, 2008.

[4] C. Dittrich, J. Lussmann, F. Busch, R. Manz, R. Stahlmann,and C. Menig. Greener roads by talking traffic lights- knowledge about queue length and next traffic lightsignalling. In International Conference on Sustainable Au-tomotive Technologies (ICSAT2010), 2010.

[5] EC DG for Transport and Energy. DATEX II V2.0 UserGuide, 2009.

[6] S. Eichler, B. Ostermaier, C. Schroth, and T. Kosch. Sim-ulation of car-to-car messaging: Analyzing the impacton road traffic. In 13th IEEE International Symposium onModeling, Analysis, and Simulation of Computer and Telecom-munication Systems, 2005, pages 507–510, 2005.

[7] M. Fullerton, A. Leonhardt, F. Busch, C. Maag, C. Mark,and H.-P. Kruger. Modeling Cooperative On-road Sys-tems. In International Workshop on Intelligent Transportation(WIT), 2010.

[8] D. Gettman and L. Head. Surrogate safety measuresfrom traffic simulation models, final report. Technical Re-port FHWA-RD-03-050, Federal Highway Administration,2003.

[9] C. Gorgorin, V. Gradinescu, R. Diaconescu, V. Cristea, andL. Ifode. An integrated vehicular and network simulatorfor vehicular ad-hoc networks. In 20th European Simulationand Modelling Conference, 2006.

[10] J. Gozalvez, S. Turksma, L. Lan, O. Lazaro, F. Cartolano,E. Robert, D. Krajzewicz, R. Bauza, F. Filali, M. Rockl,J. Leguay, C. Michelacci, J. Vreeswijk, J. Maneros, A. Gon-zalez, and M. Lenardi. iTETRIS: the framework for large-scale research on the impact of cooperative wireless vehic-ular communications systems in traffic efficiency. In Infor-mation and Communications Technologies (ICT-MobileSubmit2009), 2009.

[11] M. Haklay and P. Weber. OpenStreetMap: user-generatedstreet maps. IEEE Pervasive Computing, 7(4):12–18, 2008.

[12] M. Killat, F. Schmidt-Eisenlohr, H. Hartenstein, C. Rossel,P. Vortisch, S. Assenmacher, and F. Busch. Enabling effi-cient and accurate large-scale simulation of VANETs forvehicular traffic management. In Proceedings of the fourthACM international workshop on Vehicular ad hoc networks,pages 29–38. ACM New York, NY, USA, 2007.

[13] D. Krajzewicz, G. Hertkorn, C. Rossel, and P. Wagner.SUMO (Simulation of Urban MObility); an open-sourcetraffic simulation. In 4th Middle East Symposium on Simu-lation and Modelling (MESM2002), pages 183–187, 2002.

[14] C. Lochert, A. Barthels, A. Cervantes, M. Mauve, andM. Caliskan. Multiple simulator interlinking environmentfor IVC. In Proceedings of the 2nd ACM internationalworkshop on Vehicular ad hoc networks, page 88. ACM, 2005.

[15] D. Rieck, B. Schunemann, I. Radusch, and C. Meinel.Efficient traffic simulator coupling in a distributed v2xsimulation environment. In Proceedings of the third Inter-national ICST Conference on Simulation Tools and Techniques.ICST, 2010.

[16] E. Schoch, M. Feiri, F. Kargl, and M. Weber. Simulation ofad hoc networks: ns-2 compared to JiST/SWANS. In Pro-ceedings of the 1st international conference on Simulation toolsand techniques for communications, networks and systems &workshops, page 36. ICST (Institute for Computer Sciences,Social-Informatics and Telecommunications Engineering),2008.

[17] J. Shanthikumar and R. Sargent. A unifying view ofhybrid simulation/analytic models and modeling. Op-erations Research, 31(6):1030–1052, 1983.