Simulation Coupling Limitations with Respect to Shared Entities
Constraints
Khadim Ndiaye
1
, Flavien Balbo
1
, Jean-Paul Jamont
2
and Michel Occello
2
1
Mines Saint-Etienne, Univ. Lyon, Univ. Jean Monnet, IOGS, CNRS, UMR 5516 LHC, Institut Henri Fayol,
F-42023 Saint-Etienne, France
2
Univ. Grenoble Alpes, Grenoble INP, LCIS, F-26000 Valence, France
Keywords:
Simulation Coupling, Interoperability, Multi-agent based Simulation.
Abstract:
Simulation coupling is a mean by which already developed tools are reused and run together for the sake of
capitalizing on existing endeavours. A main challenge to microscopic simulation coupling is the synchroniza-
tion of schedulers, which are in charge of ordering internal actions for their respective simulation. To achieve
a consistent execution of the overall simulations, simulation coupling must tackle challenges to interoperabil-
ity and schedulers’ synchronization. In the scope of microscopic simulations, functional coupling objectives
can be categorized into different levels from coupled simulations that only exchange aggregated information,
to a coupling that highlights novel behaviours. Our goal in this paper is to show that the existing coupling
solutions fail to implement the problem where the coupling objective is to combine individual behaviors from
diverse microscopic simulations, in order to create new ones. This failure is due to the fact that these solutions
consider microscopic simulations to be coupled, as whole components with autonomous schedulers instead
of a composite set of behaviors. The limitations are shown using the DEVS formalism to describe coupled
microscopic simulation under different coupling objectives, with a formalization of constraints induced by
shared components.
1 INTRODUCTION
The study of complex systems is a difficult and time
consuming task as it involves various and heteroge-
neous domains of expertise. Microscopic simulation
models have become a widely used tool in many dis-
ciplines dealing with systems made up of autonomous
entities (Grimm and al, 2006). From domain specific
tools, domain experts build independent simulations
specific to their interest. The coupling of those simu-
lations is a mean to reuse already made efforts, in or-
der to get a representation of the overall systems. For
instance, to study the impact of emergency responses
plans and methods on people and infrastructures, a
fire propagation simulation, a crowd evacuation sim-
ulation and a sensor network simulation are coupled
in (Jalali et al., 2011). The simulators used in that
study were already developed and each dedicated to a
specific task.
A coupling is driven by a set of requirements
and constraints so that the end result is meaning-
ful. A same set of simulations can be subject to dif-
ferent coupling objectives. For instance, coupling a
macroscopic and microscopic traffic simulations can
whether help to calibrate the latter, or allow to study
the effects of drivers’ behavioural change in traffic
flows or congestions.
In this paper, we exhibit a type of coupling prob-
lem that most coupling solutions fail to implement. In
fact, the coupling objective to this problem constraints
scheduling relations on simulations, as a result of
shared components between simulations. Examples
of shared components are a spatial environment or
a stock exchange market, which evolutions depend
on the synchronization of actions from the coupled
simulations. Unlike whole component simulations
that exhibit a irreducible behaviour, microscopic sim-
ulations have a composite set of distinguishable be-
haviours. The problem we highlight arises when parts
of the simulations are coupled, as opposed to cou-
pling microscopic simulations as whole components.
There are two issues to consider for the shared com-
ponents consistency. The first one is the equity be-
tween agents activated by different schedulers in ac-
cessing the shared component, whilst the second is the
consistency of the resulting simulation with regards to
338
Ndiaye, K., Balbo, F., Jamont, J-P. and Occello, M.
Simulation Coupling Limitations with Respect to Shared Entities Constraints.
DOI: 10.5220/0006859603380346
In Proceedings of 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH 2018), pages 338-346
ISBN: 978-989-758-323-0
Copyright © 2018 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

coupling objectives. Our focus is targeted on Multi-
Agent Based Simulations (MABS) as a microscopic
simulation models, in the rest of the paper.
The paper is organised as follows. Coupling so-
lutions are presented along with challenges specific
to simulation coupling in Section 2. This section
also presents Discrete Time Specified System (DTSS)
coupled systems from the DEVS formalism. Section
3 begins by describing MABS as DTSS coupled sys-
tems in order to represent the behaviour of coupled
microscopic simulations. Then it showcases the limits
of current coupling solutions with regard to the shared
components challenge by introducing a formalism to
describe coupling objectives , before concluding with
some insights on our future works.
2 BACKGROUND ON COUPLING
SOLUTIONS
In this section, challenges that arise in the scope
of simulation coupling are first discussed. Then it
presents selected coupling solutions and how they ad-
dress coupling challenges.
2.1 Simulation Coupling Challenges
Simulation coupling is a mean by which already de-
veloped tools are reused and run together for the sake
of capitalizing on existing endeavors The issues to
coupling simulations that were developed indepen-
dently, are mainly due to the identification and trans-
lation of coupling objectives (Kasputis and Ng, 2000),
and to simulation heterogeneity. The heterogeneity
may concern the formalism used, the programming
language and more generally the domain of interest.
We distinguish two family types of challenges: in-
teroperability (data exchange, structure and transfor-
mation) and synchronization (time management and
scheduling).
(C1) Data Exchange: coupling independently
developed simulators requires information exchange
between the simulators. An information may con-
sist of data used by the executed models, or may be
events shared throughout the simulators for synchro-
nization purposes. Data exchange mechanism should
be generic enough to allow the routing of any data
structure and should also handle scalability.
(C2) Data Structure and Transformation: sim-
ulations from different domains deal with different
kind of data, or different representations of the same
information. An agreed upon semantic must be
shared by the coupled simulations to deal with the
exchanged information. The issue is to share infor-
mation that is meaningful to each simulations.
(C3) Time Management: simulation models may
be expressed in different time representation (contin-
uous, discrete event or discrete time) and scales (sec-
onds, days, ...). A consistent coupling solution may
ensure a simultaneous execution of the simulations by
aligning local clocks according a global time clock:
that is the local causality constraint (Fujimoto, 2001).
(C4) Global Scheduling: When simulations are
coupled, simulated components may comply to a con-
straining scheduling policy originating from the cou-
pling objective. So the problem is how to make use of
local schedulers to reflect the desired global schedul-
ing.
2.2 Simulation Coupling Solutions
We categorize existing coupling solutions using a
classification that reflects the difference between solu-
tions, depending on how they implement the coupling
of simulations. The four coupling solution types are
described as follows:
Conceptual Model Translation: approaches us-
ing model translation to unify the system’s concep-
tion. The diverse simulation models are wrapped
under a common formalism and then composed by
means of integration or hierarchical construction. It
is the case of the Discrete Event System Specifica-
tion Bus (DEVS Bus) (Kim et al., 2003), which is
a simulation infrastructure developed for heteroge-
neous simulators to interoperate. Its architecture al-
lows to manage the time advancement (C3) and offers
a consistent message passing mechanism between the
simulations (C1, C2).
External Medium Use: approaches introducing
an external component as a facilitator to the coupling
problem. It can also be an interface implemented by
the simulation models to sustain their interoperabil-
ity. The High Level Architecture (HLA) fall under
this category. It is a standard composed of an inter-
face specification, the Object Model Template (OMT)
and a set of conception rules. The interface specifica-
tion describes the APIs and services provided by the
RunTime Infrastructure (RTI). The RTI, as an external
medium, is a middleware that provides time manage-
ment services (C3) and means for federates to com-
municate data with each other (C1). The designer de-
cides what and how information are exchanged and
used in the federates (C2) by writing a Federate Ob-
ject Model (FOM).
Common Component Mediation: approaches
using a shared component between the coupled mod-
els. In order to sustain interoperability, simulation
Simulation Coupling Limitations with Respect to Shared Entities Constraints
339

models that some component, can use that compo-
nent as a proxy to exchange information. The En-
vironment Interface Standard(Behrens et al., 2009)
(EIS), is a coupling solution that uses the environment
to ensure interoperability among participating agent
platforms. It allows to build distributed and hetero-
geneous Multi-Agent Systems (MAS), by advocating
for the separation of agents’ execution from their en-
vironment. Modeling a trans-platform MAS problem
with EIS, means to define independently a shared en-
vironment model with controllable entities, by which
platforms can indirectly communicate (C1, C2).
Implemented Model Composition: approaches
aiming to compose simulators with respect to their
implementations. It means that the technical imple-
mentation of the simulation model is preserved as op-
posed to the conceptual model translation approach.
The Multi-agent Environment for Complex-SYstem
CO-simulation (Camus et al., 2016) (MECSYCO)
is an ad hoc solution at simulations’ composability.
MECSYCO uses the concept of coupling artifact to
reify interactions between simulation models. The
coupling artifact are in charge of routing and trans-
forming (C1,C2) input and output data from simula-
tions. For coordination between simulation models
(C3), a decentralized and conservative time manage-
ment approach is implemented.
2.3 DTSS Modeling of MABS
2.3.1 Motivation
The theory of modeling and simulation of (Zei-
gler et al., 2000) introduces a family of formalism
(Discrete Event System Specification(DEVS), Dis-
crete Time Specified System (DTSS) and Differential
Equation Specified System (DESS)) to model contin-
uous and discrete event systems. It provides rigorous
foundations for modeling and simulation, and also in-
troduces concepts of modular and hierarchical model
composition. Hence making it a solid groundwork for
a MABS coupling formalism.
DEVS’s hierarchical modeling focuses on the re-
lations between components. As such, it is suit-
able to represent multi-agent based simulations re-
sulting from the interactions between agents. This
feature explains why many works represent MAS us-
ing DEVS formalism (M
¨
uller, 2008; Steiniger et al.,
2012). However, the features of MABS schedulers are
of prime interest when choosing the required formal-
ism. DTSS simulators implement a fixed time step
scheduling algorithm that jumps from one simulation
step to the next, and computes the next simulated sys-
tem’s state and output values. In this light, DTSS is
more in resemblance of how most multi-agent simu-
lation platforms behave.
2.3.2 Coupling DTSS Components
The hierarchy of system specification introduced in
(Zeigler et al., 2000) describes the levels at which a
system may be known in order to report its complex-
ity, with increasing structural specificity. The level
of description used in this hierarchy specifies systems
from a behavioral point of view (lowest level), for
instance as a black box, to internal structure design
(highest level) as in complex systems. The hierar-
chy specifies two ways DTSS components are cou-
pled depending on the required system description
level: multicomponent DTSS (multiDTSS) and dis-
crete time specified network (DTSN).
MultiDTSS: is a system composed by interacting
DTSS components (M
d
— eq. 2) that influence each
other though their state transition functions.
multiDT SS =< X,Y, D, {M
d
}, c > (1)
X is the input set of the multiDTSS and Y its out-
put set. D is the index set of the DTSS components,
{M
d
}. A multiDTSS time base takes discrete val-
ues characterized by the time step constant c. This
time step constant is shared by all DTSS components,
{M
d
}. For all d ∈ D, M
d
is specified by:
M
d
=< X
d
,Y
d
, Q
d
, I
d
, E
d
, δ
d
, λ
d
> (2)
X
d
and Y
d
are respectively the input and output set
of M
d
. Q
d
is the set of all possible states the com-
ponent can have. δ
d
is the state transition function.
It processes the current state according to the previ-
ous state and the input. λ
d
is the output function of
the system. I
d
⊆ D is the set of components’ indexes
on which M
d
has read access, meaning their states are
variables in M
d
’s state transition and output functions.
E
d
⊆ D is the set of components’ indexes on which
M
d
has write access on, meaning the components on
which it can set their state values. Despite the influ-
ence relations between components in a multiDTSS,
their scheduling is not constrained. A multiDTSS is
simulated by iterative scheduling without specific or-
dering over the components, and by executing their
state transition functions.
DTSN: is a higher level of specification where
components are coupled through their input and out-
put interfaces rather than interacting directly through
their state and state transition functions as in multi-
DTSS. A Discrete Time Specified Network is struc-
tured as:
DT SN
N
=< X
N
,Y
N
, D, {M
d
}, {I
d
}, {Z
d
}, c > (3)
SIMULTECH 2018 - 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications
340

N is the index used to designate the DTSN. X
N
and Y
N
are the external inputs and outputs of the network. c
is the time step constant and D the index set of com-
ponents, {M
d
}. The set of influencers I
d
is the index
set of components which outputs are coupled to M
d
’s
input through Z
d
which is the interface map of M
d
.
Z
d
indicates which of the inputs of a component M
d
are associated to which outputs of its influencers in
I
d
. Components need to have all their inputs available
in order to execute. This means that the scheduling
is constrained by the influencers. Let us note that I
d
may also contain the index of the network DTSN, i.e.
d ∈ D ∪ {N}.
Because of the constraints induced by {Z
d
}, a spe-
cific order needs to be observed in the execution of
DTSN components. To resolve the concern about in-
put and output interdependencies, the execution of a
DTSN uses a coordinator which schedules its sub-
ordinate components in the right sequence, meaning
that only when all components’ inputs are available
that is the component ready to go (Zeigler et al.,
2000).
The choice on the coupling model (multiDTSS
or DTSN) is determined by the level of specification
needed in the coupling. If we can precisely isolate
their states and how those states influence each other
(δ
d
in eq. 2), the multiDTSS specification can be
used. The result is a multiDTSS of multiDTSS and
the simulation of such coupling model does not re-
quire a specific ordering in how the components are
executed. If however this process to capture influ-
ences between components turns out insufficient, a
DTSN modeling may be used instead. coordinators
are used to resolve localized scheduling constraints
between a component and its influencers. A root co-
ordinator is then used to monitor the overall schedul-
ing.
3 SHARED ENTITY
CONSTRAINTS
This section highlights the constraints on shared com-
ponents between coupled microscopic simulations re-
sulting from specific coupling objectives, and how ex-
isting coupling solutions lack to address them. Be-
cause a MABS is a set of interacting agents, we first
describe it using the hierarchy typologies that cou-
pled DTSS provides. Then basic coupling objectives
are presented, along with an example for each type of
coupling objective. Finally, the constraints from cou-
pling objectives are formalized into relations, in order
to measure how they affect the scheduling of coupled
MABS.
3.1 MABS as DTSS Coupling
The main components of a MABS architecture are:
environment, agents, actions’ scheduler, and inter-
actions. The environment is composed by a set of
objects and agents with perceivable properties. The
scheduler is in charge of activating the agents between
time steps. Agents are components with autonomous
processes that are capable of acting on the environ-
ment and communicating with each other. Agents
can have internal properties that are hidden or per-
ceivable ones reachable by others in the environment.
Because interactions in the MABS are relevant to
coupled DTSS models, only perceivable properties
of agents are considered. As such, these terms are
defined in the sense of EASI (Saunier et al., 2014).
The states of an agent, object or message are contex-
tual information that characterize them at any given
time. A state of an element d : s
d
= {(p
i
, v
i
) : p
i
∈
P
d
, v
i
∈ Dom
i
∈ Dom
d
}, is a set of 2-tuples of proper-
ties P
d
= {p
i
} and values from Dom
d
= {Dom
i
} cou-
ples (where Dom
i
is the domain of p
i
). Q
d
is the set
of all possible states s
d
a component can have.
An agent’s state transition does not solely depend
on its own state, but may also depend on other states
it perceives. So the set of agents in a MABS are inter-
acting components, that influence each other through
their state. MABS can then be seen as a multiDTSS
with agents as DTSS components. As such, we model
a MABS as a multiDTSS of agents defined by:
mabs
α
=< X
α
,Y
α
, D, {ag
d
}, c >, (4)
X
α
is the set of all perceivable states , i.e. messages,
agents’ and objects’ states in the MABS. Y
α
is the
overall output of all agents in the MABS. D is the
index set of the agents and c is the time step for all
agents. ag
d
is an agent represented as a DTSS com-
ponent and its parameters are defined similarly to the
specification of M
d
(eq. 2):
ag
d
=< X
d
,Y
d
, Q
d
, I
d
, E
d
, δ
d
, λ
d
> (5)
X
d
is the set of perceivable states by the agent. Y
d
is
the set of messages and agent’s actions on the envi-
ronment. Q
d
is the set of states the agent can have.
However, the term influence used in coupled
DTSS, differs from its general meaning in MABS. In
fact, agent’s autonomy does not allow for others to
directly set its states. So the only agent, an agent ag
d
can set its state, is itself : E
d
= {d} for all d ∈ D.
Hence the state transition function bears the follow-
ing form:
δ
d
: Q
d
× X
d
→ Q
d
Q
i
⊂ X
d
⊂ X
α
, ∀i ∈ I
d
. It means that influencing states
are passed to agent through its input.
Simulation Coupling Limitations with Respect to Shared Entities Constraints
341

If all components are DTSS, and there is no delay-
less cycles and all the components have the same time
step, then the resulting structure of a coupled DTSS
is proved to be equivalent to a DTSS (Zeigler et al.,
2000). In other words, DTSS is closed under the cou-
pling operation. Hence the MABS represented as a
multiDTSS can also be considered as a DTSS, and be
coupled with other MABS in the same way.
Given the nature of agents’ interactions, a single
MABS is specified as a multiDTSS. But when cou-
pling MABS themselves, new relations can arise be-
tween agents from different simulations, depending
on the coupling objective.
3.2 Coupling Objective of MABS
A coupling objective is the desired result achieved by
observing a set of requirements and constraints. Let
us consider the coupling of two independent MABS,
mabs
α
and mabs
β
along with their set of agents {ag
α
i
}
and {ag
β
i
}, in order to obtain a new simulation noted
mabs
γ
. We highlight three types of coupling objec-
tives a designer have, with increasing level of con-
straints in the relations between agents:
Conjoint Execution of Simulations (Case 1):
the designer jointly executes MABS where agents
throughout simulations do not influence each other
directly. Instead, information at the level of the sim-
ulations are shared. It is for instance the case of the
functional coupling objective of studying the effect of
weather on traffic” with mabs
α
and mabs
β
represent-
ing respectively the weather and traffic MABS. The
simulated traffic flow is used by the weather simula-
tion to compute air pollution and weather conditions
will have effects on the traffic simulation. We use
the coupling operator ⊥ to note this kind of coupling:
mabs
γ
=mabs
α
⊥ mabs
β
.
Merging Agents Into Same Simulation (Case 2):
agents in different simulations need to be aware of
each other and influence mutually as if they are in the
same simulation. For instance, with the objective to
”simulate different vehicle models in the same traf-
fic simulation”, different models of vehicle (car and
truck models for instance) from different simulations
need to share a same road network. The respective
positions of vehicles in one simulation, will influence
the behavior of vehicles in the other. Using the oper-
ator ∪, we note: mabs
γ
=mabs
α
∪ mabs
β
Building New Behaviors (Case 3): the designer
builds up new behaviors by composing existing agent
behaviors in different simulations. In addition to be-
ing aware of each other existence, agents through the
simulations need to have new interactions in order to
reflect the new behaviors to be built up. In the exam-
ple of the functional coupling objective: combine a
traffic simulation with a convoy simulation to give the
latter a realistic behavior, the concept of vehicle and
convoy are already modeled but the behavior of adapt-
ing the convoy’s movement to the vehicles’, exists in
neither. We use the notation: mabs
γ
=mabs
α
⊕ mabs
β
In section 3.3, we describe the relations induced
by the existence of shared components into what we
call shared entities, to evaluate the constraints they
impose on the implementation.
3.3 Shared Entity Definition
We define a shared entity as any element that is at
least represented in two simulations to be coupled, in
accordance with a coupling objective. In the case of
coupling a convoy with vehicles, the concept position
of a vehicle is shared by the vehicle and the convoy it
belongs to, because the convoy’s position is obtained
by mean of aggregation of its constituting vehicles’
positions. The sharing of such concept implies that
the modification of the position of a vehicle should
directly impact the position of its corresponding con-
voy, whilst the related vehicle and convoy are in dif-
ferent simulations When composition agents’ behav-
ior in order to create new ones, agents in different sim-
ulations, which were formerly independent, will now
influence each other by their perceivable states.
These common properties may belong to specifi-
cally simulated objects in the environments or be sub-
part of agent properties. In this context, we distin-
guish two types of shared entities: real and abstract
ones. Real shared entities are objects in the environ-
ment that are explicitly simulated components in at
least one simulation, while abstract ones are concepts
assimilated to a subset of agent properties. For in-
stance, the road network is a real shared entity and
the position of a vehicle is a abstract shared entity be-
cause it is a vehicle property and subpart of a convoy
properties. It is important to distinguish the two types,
as we will see later in this paper, that they do not im-
pose the same constraints.
A coupling objective requires interoperability and
synchronization relations between simulations. So
does the shared entity as an instance of the coupling
relations. In that sense, its definition is separated
into two parts: I
e
for data exchange and transforma-
tion, and S
e
for time management and scheduling. A
shared entity e between two agents ag
α
k
and ag
β
l
is de-
fined by:
SIMULTECH 2018 - 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications
342

e = (I
e
, S
e
)
I
e
= (ag
α
k
, ag
β
l
, P
e
, (trans f orm
i
j
)
i, j
)
with : 0 < i <| P
e
|, j ∈ {k, l}
S
e
= (ag
α
k
, ag
β
l
, li f eCycle
e
)
P
e
= {p
i
e
} ⊆ P
k
T
P
l
Q
i
e
state set o f property p
i
e
trans f orm
i
k
= write
i
l
◦ read
i
k
, and
trans f orm
i
l
= write
i
k
◦ read
i
l
write
i
k
: Q
k
→ Q
i
e
, and write
i
l
: Q
l
→ Q
i
e
read
i
k
: Q
i
e
→ Q
k
, and read
i
l
: Q
i
e
→ Q
l
li f eCycle
e
= (scheduling
e
, create
e
, destroy
e
)
scheduling
e
(rwAccess
e
(k), rwAccess
e
(l)) : a
permutation on {k, l}
I
e
is the interoperability part of the sharing rela-
tion and P
e
is the set of shared properties associated
to the shared entity e. Both real and abstract shared
entities model the sharing relation over some prop-
erty values. The family of functions (trans f orm
i
j
)
i, j
describes how information on the shared entity is
adapted to be perceivable by the agents, where the
indexes i and j represent the index of the property
to be transformed and the index of the agent which
uses it. There are two accesses an agent can have on
shared entity: read and write accesses. For instance,
a transformation function can be the result of a com-
position of two operations: translation of agents states
into shared entity states(write
i
j
), and the translation of
shared entity states into agent states(read
i
j
).
S
e
controls how the exchange mechanism defined
by I
e
is performed, by determining specific actions
to occur depending on states in Q
e
. It represents the
synchronization relation where li f eCycle
kl
directs
the creation, destruction and scheduling of the related
agents, upon an update of shared entity’s state. For
instance, a convoy have a read access to a position
while the corresponding vehicle have a write access
on it. So the state of the shared entity position needs
to be updated by the vehicle before the convoy is
executed. li f eCylcle’s create and destroy functions,
define actions to take upon creation and destruction
events (e.g. if a vehicle leaves its simulation, the
convoy needs not to take into account its position
anymore and the corresponding shared entity is
destroyed).
The sharing of properties implies changes in the
structure in each of these MABS components because
the set of influencees in each MABS have to change.
In the following, we will see how new influences re-
sulting from coupling objectives, affect the network
of coupled MABS using the DTSS modeling intro-
duced in 3.1.
3.4 Constraints on Coupled MABS
To couple MABS, the closure of coupling operations
on DTSS can be used by coupling the two resulting
multiDTSS to obtain another multiDTSS or DTSN
specification. We have also defined shared entities
from a coupling objective in two parts correspond-
ing to the interoperability and synchronization chal-
lenges. Let us consider the three cases corresponding
to the different types of coupling objectives, and dis-
cuss how their implementation could be achieved.
Case 1 ( ⊥): this is the case where agents in dif-
ferent simulations mabs
α
and mabs
β
do not influence
each other individually. So there is no shared enti-
ties between agents of MABS to be coupled, but there
is still synchronization and interoperability issues to
resolve. We can use the multiDTSS or DTSN spec-
ification composed by mabs
α
and mabs
β
to achieve
the coupling. The choice is driven by the conditions
given earlier in Section 2.3.2. For instance, a coupled
MABS system as a DTSN is given by :
mabs
α
⊥ mabs
β
=< X ,Y, D, {mabs
d
}, {I
d
}, {Z
d
}, c >
(6)
The terms are defined similarly to (3). D = {α, β}. Z
d
maps out which output of one simulation is fed to the
other: Z
α
(Y
β
) = X
α
and Z
β
(Y
α
) = X
β
.
Case 2 (∪): agents from different simulations live
in the same environment, which they need to share
the state. Hence there must be a non-trivial defini-
tion of I
e
in their shared entities. But there is no con-
straint on how simulations are executed. They could
run in parallel or sequentially for instance. So the
li f eCycle function in their S
e
may not be necessarily
defined. Since shared entities impose no constraints
on the scheduling of sharing agents, the same reason-
ing from case 1 can be applied with changes in the in-
terface maps {Z
d
}. The information exchange mech-
anism from I
e
will be translated in the definition of
Z
d
of the MABS. So the states defined in the shared
entity e are given to the output of the MABS, which
are connected thanks to their interface maps. For in-
stance, if I
e
= (ag
α
k
, ag
β
l
, P
e
, (trans f orm
i
j
)
i, j
), and if
ag
α
k
have write access on e and ag
β
l
read access on e,
then mabs
α
is added to E
α
k
and mabs
β
to I
β
l
.
Case 3 (⊕): coupled agents must share state infor-
mation when their behaviors are combined to create
new ones. So the shared entities must enable interop-
eration (I
e
) and maintain consistency of shared prop-
erties on both sides (S
e
). Consequently, this changes
the structure in each of these MABS components be-
cause the set of influencees in each MABS have to
change. For instance, for any two agents ag
α
k
and
ag
β
l
sharing an entity e, if ag
α
k
have write access on
Simulation Coupling Limitations with Respect to Shared Entities Constraints
343

properties in e then the corrected influencees set E
0
α
k
in mabs
α
becomes: E
0
α
k
= E
α
k
∪ {l}. Coupling the
MABS as in (eq. 6) will not be possible because of
the new influence sets with specific scheduling con-
straints. In fact, each coupled component is only
able to schedule the behavior of its constituting com-
ponents, but in the mabs
α
’s structure, there are ele-
ments from mabs
β
existing in E
0
α
k
. To avoid having
Figure 1: Hierarchical coupling network.
agents scheduled by different MABS in the same mul-
tiDTSS, the solution is to rethink the network hier-
archy, as presented in Figure 1. Instead of coupling
agents from a same simulation into a MABS and then
couple the resulting MABSs, agents must be grouped
with respect to their shared entities. To do so, agents
sharing an entity are firstly coupled in a DTSN we call
miniSched:
miniSched
e
=< X,Y, D, {ag
d
}, {I
d
}, {Z
d
}, c > (7)
With e a shared entity among {ag
d
} and Z
d
con-
structed from interoperability relation in I
e
and
scheduling relation in S
e
. DTSN is chosen because
of the explicit need of scheduling constraints. So
the order in which related agents need to be exe-
cuted is constrained by the miniSched. Now since the
miniScheds are DTSN related to each other by cou-
pling objectives, we can build a DTSN or multiDTSS
of miniScheds like in (eq. 6):
mabs
α
⊕ mabs
β
=< X,Y, D, {miniSched
d
},
{I
d
}, {E
d
}, c >
(8)
3.5 Coupling Solutions and Shared
Entities
The constraints induced by shared entities is that the
resulting network is executed by several MABS. In
fact, each agents is run in its own simulation by its
proper scheduler. We presented 4 categories of cou-
pling solutions to group solutions according to the ap-
proach they take in section 2.2. However, since we
are interested in the coupling of MABS that are exe-
cuted independently, solutions that use same concep-
tual model translation are not discussed. In the fol-
lowing, we will discuss how solutions try to address
each of the cases presented in the last section.
External medium use is a way to make simulations
interoperate by serving as a message passing and syn-
chronization mechanism. Let us take HLA as an ex-
ample. HLA’s RTI acts as a medium that enables mes-
sage passing and time coordination. It is analogous to
the coordination used in DTSN components. In fact,
coupling simulations with HLA comes to execute a
DTSN specification obtained by translating the state
transition function, output function and interface map
into RTI and federate ambassadors. for that reason,
HLA is well suited for case 1 and 2. So a HLA fed-
eration (ftn) composed of DTSS federates (fdte)is a
DTSN where the RTI is the coordinator :
f tn =< X ,Y, D, {DT SS f dte
d
}, {I
d
}, {Z
d
}, c > (9)
For HLA to implement the coupling objective in case
3, the DT SS f dtes need to be chosen among two pos-
sibilities: MABS federates or agent federates. But
agents can not be chosen as federates as they are not
controlled directly by the RTI but are rather activated
by local schedulers. Also MABS can not be consid-
ered as federates because the scheduling constraints
of the shared entities will not be fulfilled as discussed
in Section 3.4.
Then we might consider using HLA to implement
the network in eq.8 which respects the scheduling
constraints, by using miniScheds as DT SS f dtes:
f tn =< X ,Y, D, {miniSched f dte
d
}, {I
d
}, {Z
d
}, c >
(10)
Since miniScheds couple agents in different simula-
tions, they can be seen a federation of agent federates:
miniSched f dte
e
=< X
e
,Y
e
, D, {ag
d
}, {I
d
}, {Z
d
}, c >
(11)
There is two coupling levels: between components
sharing entities and between miniScheds. Not only
would we need a medium for each miniSched, but also
a medium to help all these media to interoperate. So
the medium should be conceptualized with a hierar-
chical design. With HLA, the RTI should be able to
consider a federation as a federate. (Ahn et al., 2010)
and (Kim and Kim, 2006) introduced hierarchy into
HLA federations. But with those solutions, the fed-
erations’ execution are independent. Which is not the
case here because agents in different federations are
still managed by the same scheduler. Another solu-
tion would be to bring the hierarchy into the RTI like
coordinators in DTSN abstract simulations. In this
case, a federation could be composed of RTI feder-
ates. However, that is not the case in the RTI specifi-
cation, making it impossible for HLA to satisfy con-
straints in case 3, because of its lack to control the
scheduling of agent in federates.
Component mediation solutions are alternatives to
resolve the shared entity problem. The common com-
ponent could manage shared entities through which
SIMULTECH 2018 - 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications
344

agents interact. EIS’s environment model contains
controllable components on which agents act and in-
teract. These controllable components can be used to
represent shared entities. Nevertheless, time synchro-
nization on actions is still needed. For instance with
EIS, the environment interface does not provide any
time synchronization mechanism as it is originally
meant for agent platforms and not for simulations in
particular. Since the shared entities would live in the
environment model, shared entities with synchroniza-
tion constraints can not be handled. Thus the impos-
sibility of case 3.
Finally, implemented model composition solu-
tions like MECSYCO deals with specific type of sim-
ulations, abiding by specific interfaces in their imple-
mentations. As such, they only allow to couple sim-
ulations as a whole (case 1) and not the coupling of
agents across different simulations. Thus not enabling
to implement such a network in figure 1.
4 CONCLUSION
This paper presented a challenge to microscopic sim-
ulations coupling that is yet to be addressed by exist-
ing coupling solutions. This challenge arises when
designing the coupling of simulations where com-
ponents on which synchronization is required, are
shared. We defined the concept of shared entities to
report of components sharing between coupled simu-
lations. To show the limitations of existing coupling
solutions with regards to this challenge, we proceeded
to study the constraint resulting from different cou-
pling objective on coupled MABS, with we repre-
sented using the DTSS formalism. We showed that
the limitations are due to a lack of active scheduling
approach by the current solutions.
Our future work is targeted to the proposal of a
coupling model that takes into account the shared en-
tity challenge. For genericity purposes, and along side
the coupling model, we will work on a formal frame-
work to define coupling objectives in terms of inter-
operability and scheduling relations between a set of
simulations to be coupled. A formalization of cou-
pling objectives will enable to detect inconsistencies
before the implementation. It will also enable their
structural analysis in order to correspond to a given
coupling objective, the suitable coupling solutions.
ACKNOWLEDGMENT
This work was carried out thanks to funds from
Rhone-Alpes Region’s ARC 7 program (www.arc7-
territoires-mobilites.rhonealpes.fr): ”Innovations,
mobilit
´
es, territoires et dynamiques urbaines”.
REFERENCES
Ahn, J. H., Seok, M. G., Sung, C. H., and Kim, T. G.
(2010). Hierarchical Federation Composition for In-
formation Hiding in HLA-Based Distributed Simula-
tion. In 2010 IEEE/ACM 14th International Sympo-
sium on Distributed Simulation and Real Time Appli-
cations, pages 223–226.
Behrens, T. M., Dix, J., and Hindriks, K. V. (2009). To-
wards an Environment Interface Standard for Agent-
Oriented Programming. Technical Report IfI-09-09,
Institut f
¨
ur Informatik, TU Clausthal.
Camus, B., Paris, T., Vaubourg, J., Presse, Y., Bourjot, C.,
Ciarletta, L., and Chevrier, V. (2016). MECSYCO:
a Multi-agent DEVS Wrapping Platform for the Co-
simulation of Complex Systems. PhD thesis.
Fujimoto, R. M. (2001). Parallel simulation: parallel and
distributed simulation systems. In Proceedings of the
33nd conference on Winter simulation, pages 147–
157. IEEE Computer Society.
Grimm, V. and al (2006). A standard protocol for describing
individual-based and agent-based models. Ecological
Modelling, 198(1):115 – 126.
Jalali, L., Mehrotra, S., and Venkatasubramanian, N.
(2011). Interoperability of Multiple Autonomous
Simulators in Integrated Simulation Environments.
Spring SIW, 11.
Kasputis, S. and Ng, H. C. (2000). Model composabil-
ity: formulating a research thrust: composable simula-
tions. In Proceedings of the 32nd conference on Win-
ter simulation, pages 1577–1584. Society for Com-
puter Simulation International.
Kim, J.-H. and Kim, T. G. (2006). Hierarchical HLA:
Mapping hierarchical model structure into hierarchi-
cal federation. In International conference on model-
ing and simulation–methodology, tools, software ap-
plications (M&S-MTSA’06). Calgary, Canada, pages
75–80.
Kim, Y. J., Kim, J. H., and Kim, T. G. (2003). Hetero-
geneous Simulation Framework Using DEVS BUS.
SIMULATION, 79(1):3–18.
M
¨
uller, J.-P. (2008). Towards a Formal Semantics of Event-
Based Multi-agent Simulations. In MABS, volume
5269, pages 110–126. Springer.
Saunier, J., Balbo, F., and Pinson, S. (2014). A formal
model of communication and context awareness in
multiagent systems. Journal of Logic, Language and
Information, 23(2):219–247.
Steiniger, A., Kr
¨
uger, F., and Uhrmacher, A. M. (2012).
Modeling agents and their environment in Multi-
Simulation Coupling Limitations with Respect to Shared Entities Constraints
345

Level-DEVS. In Proceedings of the 2012 Winter Sim-
ulation Conference (WSC), pages 1–12.
Zeigler, B. P., Praehofer, H., and Kim, T. G. (2000). Theory
of Modeling and Simulation, Second Edition. Aca-
demic Press, San Diego, 2 edition edition.
SIMULTECH 2018 - 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications
346