Towards a Hybrid Co-Simulation Framework:
HLA-Based Coupling of MATSim and SUMO
Moritz Gütlein, Reinhard German, and Anatoli Djanatliev
Computer Networks and Communication Systems, Dept. of Computer Science, University of Erlangen-Nürnberg, Germany
{moritz.guetlein,reinhard.german,anatoli.djanatliev}@fau.de
Abstract—Recent topics of interest such as smart cities and
autonomous driving are currently in focus of many research
activities. In this context, simulations are used to evaluate
new algorithms, performance of current technologies, or the
impact of upcoming products. In particular, they allow finding
errors and optimizing parameter sets prospectively, prior to a
real-world implementation. Simulation models of many traffic
problems need to handle large-scale scenarios, connect entities
from different domains, and run in feasible time. In order to
meet these challenges, an extendable multi-level traffic simulation
approach is proposed in this paper. We briefly introduce existing
traffic simulation techniques, name upcoming problems, available
solution approaches, and topics regarding the development of our
framework. As a first step, we coupled two different resolution
levels of traffic simulation by using High Level Architecture
(HLA) and evaluated this approach in light of simulation results
and simulation performance.
Index Terms—Multi-level simulation, traffic simulation, simu-
lation coupling, HLA, SUMO, MATSim
I. INTRODUCTION
Since the early 2000’s many publications have been pub-
lished in the area of multi-level simulation considering use
cases where one single modeling paradigm is not sufficient
[1]–[14]. Modeling and simulation of a real world system
requires the selection of an adequate technique that usually
has to fit two requirements at the same time. Firstly, the mod-
eling paradigm needs to offer the possibility to answer posed
questions. Secondly, it has to provide realizability in terms of
the available data basis and computational resource aspects.
One solution approach to handle these two requirement is
to cover multiple levels of abstraction. Furthermore, many
real-world scenarios are not homogeneous at all and embrace
problems that differ greatly in their way to be modeled and
simulated. With that, on the one hand there is a need to
combine different simulations with different levels of detail.
On the other hand, this implies the additional need for tool
combinations from different domains. This is covered by the
field of co-simulation.
In the area of transport simulation, there are articles that
cover one of them; topics of co-simulation or topics of multi-
level and hybrid simulation. The combination of these two
concepts at once would offer the advantage of high perfor-
mance, a more flexible level of detail, and decent adaptation
to the use case at the same time. However, to the best of our
knowledge the interaction of applying and combining both
concepts of coupling simultaneously is not investigated yet.
Although being equipped with modern hardware, we are still
978-1-5386-5048-6/18/$31.00 ©2018 IEEE
confronted with massive problems in terms of feasibility, as
for example recently stated in [15]. This particularly applies
for simulations of holistic cross-domain traffic scenarios that
consider a broader time frame than few minutes and cover the
space of a whole city.
In order to evaluate large-scale scenarios in the field of
transport simulation, we suggest a new framework for multi-
level co-simulation. This framework enables modeling of
complex scenarios, allows a flexible performance usage, and
is dynamically extendable by tools from different problem
domains. Moreover, it allows scaling of model parts to differ-
ent abstraction levels. We initially coupled MATSim [16] and
SUMO [17] using High Level Architecture (HLA). Both tools
are representing popular open source candidates from two
different modeling paradigms for traffic simulations, namely
mesoscopic and microscopic. This contribution is structured as
follows: First, we give an overview of recent works focusing
on this problem domain and introduce base elements of traffic
simulation in Section 2. Thereafter, we present core ideas of
our framework in Section 3 and describe our first coupling
approach in Section 4. Finally, we present performance mea-
surements in Section 5 and discuss future issues.
II. RELATED WORK
Co-simulation may be defined as “the coordinated execution
of two or more models that differ in their representation as well
as in their runtime environment” [18]. We want to define co-
simulation as the coordinated execution of two or more models
that differ in their domain as well as in their runtime environ-
ment. Otherwise, we would confuse with the other separation
types, whose focus may rely on the combination of different
modeling paradigms (hybrid simulation) or levels of detail
in the same domain (multi-level simulation). Applications for
co-simulation in the traffic domain include the simulation of
vehicular ad hoc networks. There are toolkits available that
couple one traffic simulation tool with one network simulation
tool, e.g., Veins [19] coupling SUMO with OMNeT++ [20].
Hybrid simulation [21], [22] is defined as the combined
application of different modeling paradigms like Discrete
Event Simulation (DES) and System Dynamics (SD). As a
result, it enables possibilities to model large complex systems.
Classical applications can be found in healthcare (e.g., [23]),
but also in the field of traffic simulation (e.g., [8]) when
modeling macroscopic traffic with analytical models and cou-
pling them with DES. Looking at co-simulations, there is even

Macro
Meso
Micro
Submicro
Fig. 1. Four categories of traffic simulations.
more potential in using hybrid simulations to solve problems
from the traffic domain, for example by using SD models
for general traffic flows and micro simulations to simulate a
certain junction.
[24] published one of the first articles investigating HLA in
the field of traffic simulation by splitting up tasks to multiple
instances of the same tool. HLA also offers the possibility to
implement co-simulations. Further details on HLA follow in
the next section.
As drawn in Figure 1, different types of traffic simulation
are typically divided into four categories depending on their
level of detail: macroscopic, mesoscopic, microscopic, and
submicroscopic. In a macroscopic view, traffic is seen as a
flow or stream and therefore widely modeled continuously
with first or higher order differential equations, mostly based
on gas-kinetic concepts. Famous models are Aw-Rascle-Zhang
[25], [26] and Lighthill-Whitham-Richards [27], [28]. Besides
the lack of detailed information, this modeling paradigm
has several advantages (i.e., computational performance and
low data requirements). In particular, there is no significant
influence of the density scaling of traffic on the computational
effort. On the other hand, scenarios are not modeled straight-
forward. Microscopic traffic simulation enables to represent
every road user as an individual actor that behaves indepen-
dently. This kind of model can be realized by using DES,
based on so-called car-following models like the Intelligent-
Driver Model [29]. In a car-following model, the behavior of
each vehicle is calculated by taking into account its desired
velocity and the distance and speed of the vehicle in front
of it. It provides possibilities to represent additional aspects
at a detailed level (e.g., acceleration), but at the expense
of computational performance. Mesoscopic simulation can be
placed between the two just presented paradigms. Usually, the
traffic flow is already broken down to an (semi-)individual
level. Such models are implemented in a more coarse way
than microscopic simulations, e.g., vehicles can traverse streets
as groups or streets are represented as simple FIFO-queues
[3]. Finally, the submicroscopic simulation gets even more
into detail and permits, e.g., to simulate information flow
between control units inside a vehicle, or to take into account
what rolling friction the car’s tires have on the current road
segment’s surface.
TABLE I
OVERVIEW OVER T RAFFIC S IMULATION A PPROACHES .
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [30] [11] [12] [13] [14]
Macro X X - X X - - X X X - X - - -
Meso - - X - X X X - - - - - X X X
Micro X X X X X X X X X X - X X X X
Submicro - - - - - - - - - X X - - - -
Modality v v v v p v v v v v v v p tp v
Additional
- - (X) - - - - - - - X - - - (X)
Domain
v= vehicles, t = public transport, p = pedestrians
[31] recently gave an overview of current developments
in multi-level traffic simulation. We supplemented parts of
their work with additional information, resulting in a summary
given in Table I. According to the table, one can derive that
there is no approach that is able to connect all four established
traffic simulation levels. Besides that, barely any attention
is paid to multi-modality support. Existing approaches for
connecting simulators, which represent different levels of
detail, mostly narrow down to pure car traffic, although nowa-
days many simulation tools offer a wide range of modalities
including pedestrians, trains, trucks, bicycles, and buses.
Generally, it can be stated that there neither exist a fully
connected and at the same time bidirectional approach that
is covering all abstraction levels of traffic simulation, nor
a combined multi-level and cross-domain concept. In this
paper, we introduce initial ideas for a new flexible simulation
framework based on HLA that permits to investigate future
questions regarding trending topics like smart cities or au-
tonomous driving.
III. MULTI-DIMENSIONAL FRAMEWORK
As just mentioned, the proposed framework should provide
multi-level ability granting support for hybrid coupling, co-
simulation, scalability through a distributed architecture, ex-
tendability, and an easy control interface (multi-dimensional).
We divide a set of components that are forming an entire
and composed scenario in a three dimensional grid. The
grid contains an axis for level-of-detail, spatial coverage,
and domain affiliation as depicted in Figure 2, representa-
tively filled with some possible commercial, open source, and
conceptual tools. Drawing a picture of a fictional use case,
one could image having tools from four different domains:
environment, population, traffic, and network. The first domain
could be populated by a tool for weather simulation. Generated
information would influence the behavior of vehicles in the
traffic domain and decisions made in the population domain.
Mobility plans would be created in this domain. Fictional
needs to get to a destination result in planned trips with a
route, mode, and departure time. These trips would act as input
parameters for the traffic simulation. In the traffic domain, it
would be conceivable to split up the work for different regions
to tools with different levels of detail. Some region may be
considered as very important. This would result, besides a
microscopic traffic simulation of this area, in an additional
simulation of vehicular network communication by OMNeT++
from the network domain in this region.
The main concepts of the framework that enable such
simulation compounds are briefly described in the following.
level
macro
WeatherSim
meso
Visum
MATSim
micro
Population
submicro
SUMO
OMNeT ++
Sim
environment space
ADTF
population
traffic
network
domain
Fig. 2. Three-dimensional partitioning grid.
A. Simulation Tool Coupling
The horizontal plane of Figure 2 represents the framework’s
co-simulation layer. The different domains are distinguished
by the different vertical planes of the grid. As mentioned
in Section II, one famous application of co-simulation is the
combination of a traffic simulation with a network simulation.
This allows to investigate phenomena of wireless car com-
munication and their impact on specific traffic situations like
accidents or optimization of traffic light phase times.
1) Multi-Level Simulation: The vertical plane represents the
different levels of modeling resolution whose combinations
come down to multi-level simulations. These can be defined
as “tools that can operate at more than one level of resolution”
[32]. Thinking of standard abilities of recent online map
providers, the zoom function illustrates possible use cases for
multi-level applications. In a coarse view, you can observe
traffic situations and plan your route, or identify congested
roads. On the other side, when you zoom in, you may be able
to get information about the direction of a one-way road or
nearby parking spaces. Of course, this concept can be applied
to traffic simulation, too. Multi-level simulation can be used to
model holistic scenarios of whole cities, e.g., concerning the
surrounding motorway ring in a coarse level as well as single
crossings in the city center at highest level of detail.
2) Distributed Simulation: Naturally, multi-level simulation
is closely related to co-simulation and by some definitions, it
is even part of it. Furthermore, it is also related to the field
of distributed simulation (DS). As the name suggests, DS is
a technology enabling the distribution of a single simulation
program to a system composed of multiple interconnected
computers [33]. By means of scalability, simulation splitting
and distribution enables the feasible simulation of large-scale
real world scenarios.
3) High Level Architecture: HLA as a standard describes
rules and methods to realize a distributed simulation, enabling
the interoperability of simulation tools [34]. Rising up from the
military field it gained importance in multiple new application
fields nowadays, and is used, for instance, in the field of
traffic simulation. A participating simulation tool is called
federate. Multiple federates can be connected by using a Run-
Time-Infrastructure (RTI). The RTI acts as a middleware,
coordinates the interactions of the federates, and handles the
time management. Together with a Federation Object Model
(FOM), they form a federation. The FOM is a file that contains
a specification of the possible interactions in the federation.
B. General Capabilities
As initially mentioned, we create a framework that allows
complex simulation scenarios to be run in feasible time.
This will be realized through the connection of the different
vertical and horizontal layers. Besides that performance and
interoperability criteria, we want to assure the following two
major points.
1) Extendability: Extendability is important to us to not
only fit the needs of one type of a problem, but to model and
simulate as many different problem types as possible. Regard-
less of this, it is sometimes necessary to replace tools. This can
be because of licensing reasons, or a limited support. In terms
of extendability, HLA includes further suitable features. An
already existing and well-defined HLA setup of tools can be
extended easily and seamlessly with other tools by just writing
a corresponding federate. Other techniques that couple two
tools directly through deep code intrusions have the potential
to be more performant, but cannot provide flexibility at this
level at the same time.
2) Consistency: Another main topic is going to be the
realization of consistency between all simulation parts of a
scenario. [3] names consistency in route choice and network
representation, consistency of traffic dynamics, and consis-
tency in traffic performance as main requirements for coupling
mesoscopic and microscopic traffic simulations. Combining
not only these two, but also all four levels of traffic simulation
and additionally components from different domains makes
this problem even more important for us.
C. Information Transfer Between System Boundaries
The core idea of information transfer between different
simulation tools relies on the already addressed point of
extendability. Every instance is responsible to interpret dif-
ferent subsets of incoming data based on a defined superset
of properties of a so-called trafficTransferInteraction. This
interaction can result either in the direct adoption of incoming
road users or just a slight modification of the receivers current
internal traffic state. These changes depend on the given traffic
information, configuration parameters, current state, and the
modeling level and paradigm of the receiver.
In the opposite way, when sending out flows or vehicles,
the sender instance does not know the type of the receiver.
All relevant information (from a sending point of view) is put
into the transfer interaction. In this way, new simulation tools
can be easily integrated without the need for adjusting the
existing tools, what meets our need for extendability. Besides
the question of what information has to flow to achieve the
transfer of traffic, we need to specify how to detect at which
point in time and space that traffic has to be transferred. In
order to satisfy the consistency rule regarding the network
representation, we create a global view on the scenario that
can be used to define system boundaries. These boundaries are
represented in shape of road segments that form border links.
1) Aggregation and Disaggregation: When representation
levels between system boundaries do not differ, the inter-
pretation and adoption of transferred traffic information is
straightforward. In case that traffic information from a more
detailed level is adopted, aggregation is needed to synthesize
information, e.g., by averaging. More complicated to realize is
the other way round, when traffic from a more coarse level has
to be adopted. Disaggregation has to be used to make smart
guesses to collect additional information needed in the new
representation level. An exemplary concept for achieving this
are so-called flux capacitors used by [8]. It utilizes Poisson
processes that are well known to model arrival times.
[35] proposed the concept of superagents in the healthcare
domain. An adaption of the concept to the traffic domain
would be another possible solution that works in both direc-
tions. In mesoscopic queue-based models, vehicles influence
each other only in an indirect way. That is because no
car-following or similar models, which calculate individual
behavior dependent on the vehicle’s surrounding area, are
used. The indirect influence happens for example when a road
is fully occupied. Due to the queue-based approach, no further
vehicles will be added to the full queue representing this road.
In this way, traffic jams can be modeled. Therefore, the com-
putational effort of the simulation can be reduced by scaling
down the capacity of the road network while simultaneously
scaling down the number of traveling vehicles. Phenomena
of interest, e.g., congestion, can still be observed. In order to
transfer traffic information into finer levels, individual agents
need to be derived. They have to be realistically distributed in
space and time. Naturally, when going back to upper levels,
they need to be aggregated again.
Speaking about multi-dimensionality, there is a need for
analogous (dis)aggregation concepts for all additional domains
that are going to be connected.
2) Ghosting: Usually, it is not enough to transfer solely
the information of a single car. The context also matters. To
preserve the already named consistency of traffic dynamics, it
is important to have a common link in neighboring simulation
regions. That common border link is simulated in both worlds
to be able to transfer congestion information across system
boundaries. Without common links, it would be necessary to
have a high communication and controlling overhead between
the two simulation instances to know if the border link can be
entered. Due to the concept of having these two representations
of an entity, this is called ghosting.
IV. COUPLING OF MATSIM AND SUMO
MATSim and SUMO are two very famous representatives
of open source mesoscopic and microscopic traffic simulation
tools. Therefore, they seem like a good draw to implement
core-concepts and capture first measures on them.
SUMO is an open source tool for microscopic traffic sim-
ulation. It uses car-following models to calculate the actions
of road users in discretized time steps. MATSim on the other
hand is a tool for mesoscopic traffic simulation, simulating
daily plans of agents with a queue-based model named QSim
in the default case. Its authors label it microscopic, due
to the individual representation of each traffic participant,
but the traffic characteristics are mesoscopic according to
our definition. Concisely, this means that travel times of an
individual agent that has no properties like current speed are
dependent on the capacity, utilization, minimal travel time, and
outflow-rate of a link.
A. Architecture
To meet the requirements arising from the points mentioned
before, we decided to use HLA as an architecture to couple the
used simulation tools. Therefore, we implemented two simu-
lation wrappers containing federates to enable communication
between the simulation tools and the RTI. Additionally, we
implemented a component called SimulationController as a
third federate besides the MATSim and SUMO federates (Fig-
ure 3). It publishes the scenario setup, e.g., the underlying road
network, time step sizes, and simulation start and end time.
This is done by setting up the configurations inside the tool
that comes with a GUI as depicted in Figure 4. Afterwards,
it announces the parameters (like system boundaries) for each
connected simulation instance (Figure 5).
Two different types of data need to be exchanged. Control
data contains information about the global simulation time
and information about the current boundaries of the simulation
tools in the whole scenario. Simulation data contains runtime
information about traffic flows or road users that need to be
transferred between simulation instances. To enable scalability
and distribution abilities, we explicitly hide global knowl-
edge of available information between the simulation tools.
Moreover, we accept that there are different representations of
traffic in each detail level. We solely use HLA interactions
to signal the border crossing of traffic between tools and
let these interactions influence the local traffic situation, but

MATSim SUMO
Simulation
Controller
Federate Federate
HLA RTI
Fig. 3. Coupling architecture.
Fig. 4. SimulationController GUI.
Fig. 5. Coupled scenario: SUMO (inside) and MATSim.
do not preserve predefined objects over borders. As a result,
three custom interaction types besides the time management
functionalities have been defined: staticConfigInteraction, dy-
namicConfigInteraction, and trafficTransferInteractions (tTI).
The staticConfigInteraction is needed for an initial setup
before the simulation run is started. In a minimal setup, this
contains the scenarios name to load the corresponding map,
the time step lengths, and the start and end time of the
simulation. Afterwards, but also before simulation is started,
the dynamicConfigInteraction is used to publish (border-)link
responsibilities. Therefore, responsibilities and border links
could be changed during runtime by publishing this again.
When published, the simulation instances know which regions
they have to care about and on which border links they may
have to start a tTI.
A tTI can have multiple properties from which all except
for newLink are optional: newLink, sourceLink (id, speed,
flowRate, travelTime & length), sourceInstance, sourceAgen-
tId, route. Even route information is not a necessary property.
Thinking of a macroscopic instance initiating a tTI that is
triggered by the relation between flow rate and past time since
last discretization or other stochastic decisions, there is no
destination. There is just the need to create a road user on the
FOM Legend:
configInteraction
Interaction
Mandatory Attribute
staticConfigInteraction
Optional Attribute
scenarioName Possible Extension
timeStepSizes, startTime, endTime
dynamicConfigInteraction
linkResponsabilites
borderLinkResponsabilites
trafficTransferInteraction
newLink
sourceLink: id, speed, flowRate, travelTime, length
sourceInstance, sourceAgentId
route
subroute:linkList, transportMode
transportMode, scalingFactor
Fig. 6. Federate Object Model.
incoming border link. Similarly, the instances only know about
their own outgoing border links, not about the destination, and
not about incoming border links, as this is not needed for
adoption.
This leads to a Federation Object Model (FOM) that con-
tains the three named interactions with the given attributes
(Figure 6). Extending the framework to multi-modality would
require modification of the base case. It would especially
require the specification of what type of transportMode needs
to be transferred and provide the ability to partition a single
route to subroutes with different transport modes. At the
moment, the difference between the two used detail levels
consists of how movement for a single entity is calculated.
Multi-resolution can also be achieved by scaling up a small
subset of entities to represent an entire population. In that
case, a scalingFactor would be necessary to achieve consis-
tency across system boundaries. Integrating tools of different
simulation domains into the federation would demand to add
additional interaction types to the FOM.
B. Time Management
For time synchronization, we use the integrated conservative
time management functionalities of the RTI. After each simu-
lation step, the simulation tools are requesting an advance in
simulation time (HLA terminology: Time Advance Request)
that is corresponding to their own step length. If only two
tools are connected, it is sufficient and possibly more efficient
if both tools are requesting an advance for the maximum
step length. As soon as possible, the RTI provides the new
simulation time, which enables the federate to proceed (HLA
terminology: Time Advance Grant). A tool can continue once a
simulation time stamp is received that is at least equal to their
current simulation time plus their own time step length. In a
typical case, this may be 10ms for SUMO and 1000ms for
MATSim. They both would request an advance to t0 +1000ms,
which leads to one simulation step in MATSim and 100
simulation steps in SUMO before they get synchronized again.
C. Implementation
As middleware, we used an open source HLA implementa-
tion called Portico [36]. Portico supports different HLA ver-
sions and provides C++ and Java interfaces. In the following,
the specific details of connecting SUMO and MATSim are
presented.
1) SUMO: SUMO offers an API called Traffic Control
Interface (TraCI). With this API, it is possible to retrieve
information about road users and streets, to create new road
users, and modify plans and behavior of existing ones. Addi-
tionally, it is possible to control the simulation run. Therefore,
the implementation of the wrapper and the federate for SUMO
was straightforward and no direct interference with the SUMO
source code was needed.
In the other way round, this means that we cannot directly
subscribe to something like a “road-enter-event”. Instead, we
constantly have to check for all road users An , if they are
now on a lane that is part of a road labeled as a border link.
When a particular road user Ax is located on such a link, we
need to generate a tTI, containing relevant data like speed and
route, and let Ax end its trip in the local world after traversing
the current link. This means at the same time that we need to
listen for incoming tTI of other instances and react to them
by putting new road users in our local world. In this specific
setup, there are two possibilities: A tTI has already current
speed and further detailed information embedded or not. In
the first case, the tTI was sent from another SUMO instance
and the data can therefore directly be used to spawn a copy of
the transferred road user in the local SUMO instance. In the
second case, the tTI was sent from a MATSim instance, where
no speed attribute exists. It only contains information about
the length l and travel time t of the last traversed link. This
information is used to calculate the average speed vavg = tl ,
which will be used as initial speed for the road user that has
to be created. In both tools, an agent id is transmitted and
inherited, to be able to keep track of vehicles across borders.
In order to know which of the network’s links are currently
labeled with a border link property, the federate needs to
subscribe to dynamicConfigInteractions and save the received
information. Parameters transmitted over staticConfigInterac-
tions are processed in the same way. When the wrapper is
started up, it spawns two processes: SUMO and the federate.
The federate has to connect itself to the spawned SUMO
instance over TCP by using SUMO’s Traffic Control Interface
(TraCI) and furthermore has to connect to the federation.
When this is done, it continuously...
• ... asks the federation for a time advance t and when
granted lets the SUMO simulation run for t.
• ... checks, if based on subscribed interactions actions have
to be made. This can be the adoption of incoming vehicles
or the modification of link responsibilities and border
tags.
• ... checks, if based on the internal SUMO state inter-
actions have to be published, namely the dismissal of
vehicles.
2) MATSim: Unfortunately, MATSim does not provide an
API like SUMO. Therefore, it was necessary to look into
the code base and modify some parts of the core logic. The
advantage of the required code intrusion is that the result is
much more efficient than the SUMO variant, where the API
has to be called over TCP. Only when the transfer of an agent
Ax from a link L1 to a link L2 is going to be processed and
is possible, e.g., due to no congestion, it is checked if the
link L2 is labeled as a border link. In the case it is, a tTI is
published and the plans of agent Ax are modified locally to
end his trip after reaching the end of link L2 . To give finer
modeled tools a starting point to assume unknown properties
like speed, the tTI is filled with the length of L1 , the time Ax
needed to traverse L1 , and its current route. When receiving
a tTI either from SUMO or from MATSim, all parameters
besides newLink, sourceAgentId, and route are dismissed. A
new vehicle is created and spawned, based on the remaining
types of information. While the simulation is running, a loop
continuously asks for a time advance and checks if actions
have to be made, as it is done in the SUMO federate.
3) SimulationController: The SimulationController orches-
trates the synergy of the different tools, in this first use
case MATSim and SUMO. Initially, a road map is loaded
and converted to the different needed MATSim and SUMO
formats. Secondly, the user can define a spatial area in which
SUMO handles the simulation by dragging up a window. The
surrounding area will be simulated by MATSim. Roads that
intersect the drawn window are identified and labeled as border
links. Additionally, the user can define the simulation step size
of the tools and the start and end time. In a third step, it is pos-
sible to start up a HLA federation and the SUMO and MATSim
wrappers. Once the federation is established, we can announce
the static settings by using the staticConfigInteraction and the
current responsibilities and system boundaries by publishing
(border-)link-instance pairs via dynamicConfigInteractions to
MATSim and SUMO and finally start the simulation.
V. EVALUATION
In order to evaluate the gains and drawbacks, a real world
scenario was simulated in multiple ways. This was done pure
mesoscopically (MATSim), pure microscopically (SUMO),
and in a coupled way (MATSim coupled with SUMO) where
only the city center was simulated microscopically. Measured
values are the computational effort on one hand, scenario
specific the average of travel times, average route lengths, and
the number of departed and arrived cars on the other hand.
Additionally, aggregated link volumes per time were captured.
Link volume is defined as the number of vehicles that pass
over a link in respect to time.
 TABLE II TABLE VI
F IVE S OLO RUNS OF Cottbus 3k S CENARIO . T HREE C OUPLED RUNS OF Cottbus 3k S CENARIO .

Simulator MATSim SUMO SUMO SUMO SUMO Step size (ms)

Step size (ms) 1000 1000 100 10 1 MATSim 1000 1000 1000
Departed cars 3300 3330 3330 3330 3330 SUMO 1000 10 1
Not arrived 0 0 18 18 0 Departed cars
Lengtha (m) 12682.80 12887.58 12855.75 12855.75 12855.75 MATSim 4025 4023 4022
a
Duration (s) 714.23 759.0 761.60 759.99 740.84 SUMO 1015 1015 1015
CPU time (s) 3.02 28.06 213.42 1751.02 14723.48 Not arrived
a: Average over all simulated trips in simulation run. MATSim 0 0 0
SUMO 1 1 1
Avg. trip length (m)
MATSim 11251.82 11250.43 11261.29
TABLE III SUMO 5482.41 5503.52 5481.46
F IVE S OLO RUNS OF Cottbus 3k S CENARIO IN OWN F EDERATIONS . Avg. trip duration (s)
MATSim 639.82 639.74 639.48
Simulator MATSim SUMO SUMO SUMO SUMO SUMO 131.54 132.69 133.96
Step size (ms) 1000 1000 100 10 1 CPU time (s) 2208.71 2210.56 2850.71
Departed cars 3330 3330 3330 3300 3300
Not arrived 0 18 18 0 0
Lengtha (m) 12682.80 12887.58 12855.75 12855.75 12887.58
a
Duration (s) 714.23 759.08 761.60 759.99 740.84 TABLE VII
CPU time (s) 1101.23 2239.00 2474.67 4204.59 17666.45 T HREE C OUPLED RUNS OF Cottbus 11k S CENARIO .
a: Average over all simulated trips in simulation run.
Step size (ms)
MATSim 1000 1000 1000
SUMO 1000 10 1
Departed cars
The simulations were run single-threaded on a standard MATSim 13460 13417 13417
laptop having an i7-7600U at 2.8Ghz. In the coupled scenarios, SUMO 3469 3467 3467
Not arrived
each part of the federation was run on its own core. The MATSim 0 0 0
scenarios that we used are based on an existing scenario that SUMO 2 1 1
was published by [37]. It represents commuter traffic in the Avg. trip length (m)
MATSim 11400.76 11419.87 11419.87
German city Cottbus on a regular working day. We derived two SUMO 5421.90 5403.99 5403.99
scenarios out of it. To achieve this, we filtered out all trips that Avg. trip duration (s)
did not start between 7am and 9am and reduced randomly the MATSim 646.03 646.73 646.73
SUMO 130.86 134.25 134.52
number of trips contained in the base scenario to have 11100 CPU time (s) 2210.58 2502.97 4223.22
trips (called 11k Scenario) left to be taken and another time
to have 3300 trips (called 3k Scenario) left to be taken.
Both scenarios are simulated with a step time of 1000ms
and 1ms in SUMO. These are usual times investigating ve-
in MATSim and with a step time of 1000ms, 100ms, 10ms,
hicular communications. Having a fixed step time of 1000ms
for MATSim is appropriate, keeping in mind that there is
TABLE IV
no information about current speeds, absolute positions, or
F IVE S OLO RUNS OF Cottbus 11k S CENARIO . behavior of vehicles due to the mesoscopic simulation. In
the coupled runs, the scenario was distributed in such a
Simulator MATSim SUMO SUMO SUMO SUMO
Step size (ms) 1000 1000 100 10 1
way that the city center was simulated by SUMO and the
Departed 11100 11083 11082 11085 11084 surrounding areas by MATSim. When running MATSim with
Not arrived 0 1609 1518 1367 1367 a fixed step size of 1000ms, it is sufficient that connected
Lengtha (m) 12923.86 11973.35 12061.43 12156.16 12156.23
Durationa (s) 725.17 1477.19 1420.41 1326.63 1327.45
tools are each requesting time advances of 1000ms from the
CPU time (s) 8.32 134.19 1192.80 9851.38 105381.27 federation. Additionally, the scenarios are simulated separately
a: Average over all simulated trips in simulation run. with MATSim and SUMO forming independent federations
(Table III & Table V). Time requests are instantly granted, if
the tools are the only members of their federation. In this way,
TABLE V it is possible to analyze the overhead of the time management.
F IVE S OLO RUNS OF Cottbus 11k S CENARIO IN OWN F EDERATIONS .
Regarding the computational times, there is nothing much
Simulator MATSim SUMO SUMO SUMO SUMO surprising in the outcome of the different solo runs at first
Step size (ms) 1000 1000 100 10 1 glance. With decreasing step length the calculation time in-
Departed cars 11100 11083 11082 11085 11084
Not arrived 0 1609 1518 1367 1367 creases, up to 105381.27s in the case of SUMO with 1ms on
Lengtha (m) 12923.86 11973.35 12061.43 12156.16 12156.23 the 11k Scenario (Table IV). More surprising is the amount of
Durationa (s) 725.17 1477.34 1420.43 1326.63 1327.45 time needed for the HLA time management: Comparing Ta-
CPU time (s) 1102.33 2557.19 3677.54 12752.08 104612.72
a: Average over all simulated trips in simulation run. ble II and Table III, the federated MATSim run takes almost a
factor of 400 longer than the unfederated run with a CPU time
of 3.02s. In absolute numbers: 1101.23s − 3.02s = 1098.21s. 7000
Volume per Time - Cottbus 3k Scenario

The scenario has been run for 3 hours in simulation time MATSim
6000 SUMO
with a step size of 1000ms, resulting in 3 · 60 · 60 = 10800 Coupled Sum
Coupled MATSim
time steps. This means that we have an average overhead of 5000 Coupled SUMO

1098.21s ÷ 10800 = 0.10169s ≈ 102ms per time step just

Link Volume
4000
for time management. Similar conclusions can be drawn when
comparing the managed and unmanaged SUMO runs or when 3000

looking at the 11k Scenario in Table IV and Table V. This

2000
requires more investigation to determine whether time can
be saved on side of the HLA implementation, within of our 1000

wrappers, or on both sides. 0

7AM 8AM 9AM 10AM
However, we still can benefit from using HLA in the Simulation Time

coupled way, where the scenario is distributed across both

Fig. 7. Aggregated traffic volumes per time: Cottbus 3k Scenario.
tools (Table VI & Table VII). Naturally, this is the case when
the computational effort overcomes the timing overhead. First,
Volume per Time - Cottbus 11k Scenario
we look at the column of Table VII, where the scenario is run 20000
MATSim
with MATSim and SUMO each having a 1000ms time step SUMO
Coupled Sum
length. It took 2210.58s. The pure SUMO run took 134.19s 15000 Coupled MATSim
Coupled SUMO
(Table IV) at a 1000ms time step. Due to the full microscopic
simulation, it is even considered more accurate. Looking at the

Link Volume
10000
coupled simulation run of the 11k Scenario with MATSim and
SUMO having a 1000ms and 1ms time step respectively, the
benefits can clearly be seen. Instead of 105381.27s in the pure 5000
SUMO run (Table IV) at a time step of 1ms, the coupled
simulation of the scenario took 4223.22s (Table VII). This
0
corresponds to almost a factor of 25. Figure 7 and Figure 8 7AM 8AM 9AM 10AM
are showing the simulated traffic volumes of the different runs. Simulation Time

’MATSim’ and ’SUMO’ curves describe the traffic volume of

the solo runs. ’Coupled Sum’ describe the aggregated traffic
volumes of the coupled runs, with ’Coupled MATSim’ and
’Coupled SUMO’ showing their corresponding amounts to
that aggregation. Besides time considerations, a varied traffic
pattern outcome can be seen because of different modeling
paradigms.
Therefore, the need for reasonable tool choices can be
deduced. Assuming the microsimulation to be more precisely,
improper results of the mesosimulation can be observed when
it comes to crowded traffic scenarios as in the 11k Scenario. In
the relaxed 3k Scenario, almost no difference can be noticed.
This probably can be traced back to congestions at crossings
either due to missing information like signal light placements
and timings needed for a proper microsimulation, or having
an amount of traffic volume that has to lead to congestions.
Furthermore, it can be seen that especially in the 11k Scenario
the amount of cars that cannot reach their destination is
quite high in the SUMO simulation, whereas every vehicle
reaches its destination in the MATSim simulation (Table IV).
In the SUMO solo runs, more than 15 vehicles could not
even depart because their spawning links were congested.
Another outcome of this phenomenon can be observed in the
average trip durations. Whereas the times are around 1400s in
simulation time for the SUMO runs, MATSim trips take only
725.17s in average. If the scenario is not crowded by so many
vehicles, the results of both MATSim and SUMO are between
700s and 800s (Table II).
Fig. 8. Aggregated traffic volumes per time: Cottbus 11k Scenario.
VI. CONCLUSION AND OUTLOOK
In this paper, we proposed a multi-dimensional frame-
work enabling flexible couplings of tools using HLA. We
presented possible benefits of coupling two different traffic
simulation tools that are representing two different levels of
detail, namely mesoscopic and microscopic. It was possible to
reduce the computational effort of a complex traffic scenario
tremendously. We are able to set the underlying network,
system boundaries, and simulation parameters via the simula-
tion controller component, enabling dynamic adaption during
simulation runs in future. By using the HLA architecture, it
is possible to integrate additional tools seamlessly. Therefore,
the potential gains related to large-scale scenarios are definitely
worth further work.
As a first next step, we are going to bring in the scaling
factor that was addressed in Section III, moving us more into
the hybrid field. As a second step, we want to couple more
than two different levels of traffic representation and combine
this coupling with tools from another domain. This will require
extending the FOM. Moreover, we will investigate about the
influence of optimistic time management approaches and the
dynamic switching between optimistic and conservative time
management based on current scenario situation. In parallel,
we need to decrease the time management transmission la-
tency. Speaking of dynamic switching, we also intent to ex-
plore use cases, where it seems useful to change the scenario’s
component topology dynamically. This could happen based on
load balancing aspects, ego car following intentions, or the
reaction on extraordinary situations inside the simulation that
need to be simulated in a different mode of representation.
R EFERENCES
[1] E. Bourrel and J.-B. Lesort, “Mixing micro and macro representations of
traffic flow: A hybrid model based on the LWR theory,” Transportation
Research Record: J. of the Trans. Res. Board, vol. 1852, no. 1, pp.
193–200, 2003.
[2] M. S. El Hmam, H. Abouaissa, D. Jolly, and A. Benasser, “Towards an
hybrid simulation approach of transportation systems,” IFAC Proceed-
ings Volumes, vol. 37, no. 19, pp. 75–80, 2004.
[3] W. Burghout, H. N. Koutsopoulos, and I. Andreasson, “A discrete-event
mesoscopic traffic simulation model for hybrid traffic simulation,” in
Intelligent Transportation Systems Conference. IEEE, 2006, pp. 1102–
1107.
[4] G. Flotterod and K. Nagel, “High speed combined micro/macro simu-
lation of traffic flow,” in Intelligent Transportation Systems Conference.
IEEE, 2007, pp. 1114–1119.
[5] N. Gaud, F. Gechter, S. Galland, and A. Koukam, “Holonic multiagent
multilevel simulation application to real-time pedestrians simulation in
urban environment,” in Proceedings of the 20th International Joint
Conference on Artifical Intelligence, ser. IJCAI’07. San Francisco,
CA, USA: Morgan Kaufmann Publishers Inc., 2007, pp. 1275–1280.
[6] R. Claes and T. Holvoet, “Multi-model traffic microsimulations,” in
Proceedings of the 2009 Winter Simulation Conference, Rossetti et al.,
Eds. Piscataway, New Jersey: IEEE, 2009, pp. 1113–1123.
[7] J. Casas, J. Perarnau, and A. Torday, “The need to combine different traf-
fic modelling levels for effectively tackling large-scale projects adding
a hybrid meso/micro approach,” Procedia - Social and Behavioral
Sciences, vol. 20, no. Supplement C, pp. 251–262, 2011.
[8] J. Sewall, D. Wilkie, and M. C. Lin, “Interactive hybrid simulation of
large-scale traffic,” ACM Transactions on Graphics, vol. 30, no. 6, pp.
135:1–135:12, Dec. 2011.
[9] W. Huang, “Hytran: A new approach for the combination of macroscopic
and microscopic traffic flow models,” Ph.D. dissertation, University of
Technology Graz, 2013.
[10] P. Kumar, R. Merzouki, B. Conrard, V. Coelen, and B. O. Bouamama,
“Multilevel modeling of the traffic dynamic,” IEEE Transactions on
Intelligent Transportation Systems, vol. 15, no. 3, pp. 1066–1082, 2014.
[11] D. Zehe, D. Grotzky, H. Aydt, W. Cai, and A. Knoll, “Traffic simulation
performance optimization through multi-resolution modeling of road
segments.” ACM, 2015, pp. 281–288.
[12] L. Crociani, G. Lämmel, and G. Vizzari, “Multi-scale simulation for
crowd management: A case study in an urban scenario,” in Autonomous
Agents and Multiagent Systems, ser. Lecture Notes in Computer Science.
Springer, Cham, 2016, pp. 147–162.
[13] G. Lämmel, M. Chraibi, A. U. Kemloh Wagoum, and B. Steffen, Hybrid
Multi- and Inter-Modal Transport Simulation: A Case Study on Large-
Scale Evacuation Planning. US National Research Council, 2016.
[14] P. B. Mirchandani, P. Li, and X. Zhou, “Integrating meso- and micro-
simulation models to evaluate traffic management strategies,” 2016.
[15] A. Brummer, R. German, and A. Djanatliev, “On the necessity of
three-dimensional considerations in vehicular network simulation,” in
14th Annual Conference on Wireless On-demand Network Systems and
Services (WONS), Härri et al., Eds. IEEE, 2018, pp. 75–82.
[16] M. Balmer, K. Axhausen, and K. Nagel, “Agent-based demand-modeling
framework for large-scale microsimulations,” Transportation Research
Record: J. of the Trans. Res. Board, vol. 1985, no. 1, pp. 125–134,
2006.
[17] D. Krajzewicz, G. Hertkorn, C. Rössel, and P. Wagner, “SUMO
(Simulation of Urban MObility)-an open-source traffic simulation,” in
Proceedings of the 4th Middle East Symposium on Simulation and
Modelling (MESM20002), 2002, pp. 183–187.
[18] F. Schloegl, S. Rohjans, S. Lehnhoff, J. Velasquez, C. Steinbrink,
and P. Palensky, “Towards a classification scheme for co-simulation
approaches in energy systems,” in 2015 International Symposium on
Smart Electric Distribution Systems and Technologies (EDST). IEEE,
2015, pp. 516–521.
[19] C. Sommer, R. German, and F. Dressler, “Bidirectionally coupled
network and road traffic simulation for improved ivc analysis,” IEEE
Transactions on Mobile Computing, vol. 10, no. 1, pp. 3–15, 2011.
[20] A. Varga and R. Hornig, “An overview of the omnet++ simulation
environment,” in Proceedings of the 1st International Conference on
Simulation Tools and Techniques for Communications, Networks and
Systems & Workshops. ICST (Institute for Computer Sciences, Social-
Informatics and Telecommunications Engineering), 2008, p. 60.
[21] T. Eldabi, M. Balaban, S. Brailsford, N. Mustafee, R. E. Nance, B. S.
Onggo, and R. G. Sargent, “Hybrid simulation: Historical lessons,
present challenges and futures,” in Proceedings of the 2016 Winter
Simulation Conference, Roeder et al., Eds. Piscataway, New Jersey:
IEEE, 2016, pp. 1388–1403.
[22] J. Zulkepli, T. Eldabi, and N. Mustafee, “Hybrid simulation for mod-
elling large systems: An example of integrated care model,” in Proceed-
ings of the 2012 Winter Simulation Conference, Laroque et al., Eds.
Piscataway, New Jersey: IEEE, 2012, pp. 1–12.
[23] A. Djanatliev and R. German, “Prospective healthcare decision-making
by combined system dynamics, discrete-event and agent-based sim-
ulation,” in Proceedings of the 2013 Winter Simulation Conference,
Pasupathy et al., Eds. Piscataway, New Jersey: IEEE, 2013, pp. 270–
281.
[24] U. Klein, T. Schulze, S. Straßburger, and H.-p. Menzler, “Distributed
traffic simulation based on the high level architecture,” in In Proceedings
of the Simulation Interoperability Workshop, 1998.
[25] A. Aw and M. Rascle, “Resurrection of ’second order’ models of traffic
flow,” SIAM J. on Appl. Maths., vol. 60, no. 3, pp. 916–938, 2000.
[26] H. M. Zhang, “A non-equilibrium traffic model devoid of gas-like
behavior,” Transportation Research Part B: Methodological, vol. 36,
no. 3, pp. 275–290, 2002.
[27] M. J. Lighthill and G. B. Whitham, “On kinematic waves. i. flood
movement in long rivers,” Proceedings of the Royal Society of London.
Series A, Mathematical and Physical Sciences, vol. 229, no. 1178, pp.
281–316, 1955. [Online]. Available: http://www.jstor.org/stable/99768
[28] P. I. Richards, “Shock Waves on the Highway,” Operations Research,
vol. 4, no. 1, pp. 42–51, 1956.
[29] M. Treiber and D. Helbing, “Realistische mikrosimulation von strassen-
verkehr mit einem einfachen modell,” in 16th Symposium Simulation-
stechnik ASIM, vol. 2002, 2002, p. 80.
[30] Y. Xu, W. Cai, H. Aydt, and M. Lees, “Efficient graph-based dynamic
load-balancing for parallel large-scale agent-based traffic simulation,” in
Proceedings of the Winter Simulation Conference 2014, Tolk et al., Eds.
Piscataway, New Jersey: IEEE, 2014, pp. 3483–3494.
[31] I. Tchappi Haman, V. C. Kamla, S. Galland, and J. C. Kamgang, “To-
wards an multilevel agent-based model for traffic simulation,” Procedia
Computer Science, vol. 109, no. Supplement C, pp. 887–892, 2017.
[32] D. D. Hill and W. M. vanCleemput, “Sable: A tool for generating
structured, multi-level simulations,” in Papers on Twenty-five Years of
Electronic Design Automation, ser. 25 years of DAC. New York, NY,
USA: ACM, 1988, pp. 365–272.
[33] R. M. Fujimoto, Parallel and Distributed Simulation Systems. Wiley
New York, 2000, vol. 300.
[34] F. Kuhl, R. Weatherly, and J. Dahmann, Creating Computer Simulation
Systems: An Introduction to the High Level Architecture. Prentice Hall
PTR, 1999.
[35] A. Djanatliev and R. German, “Towards a guide to domain-specific
hybrid simulation,” in Proceedings of the 2015 Winter Simulation
Conference, Yilmaz et al., Eds. Piscataway, New Jersey: IEEE, 2015,
pp. 1609–1620.
[36] Portico, “The poRTIco project,” 2018, accessed June 17nd , 2018.
[Online]. Available: http://www.porticoproject.org/
[37] TU Berlin, “MATSim scenarios,” 2018, accessed June 17nd ,
2018. [Online]. Available: https://svn.vsp.tu-berlin.de/repos/public-
svn/matsim/scenarios/countries/de/cottbus