An Overview of the Quartz Modelling and Simulation Framework

Romain Franceschini

, Paul-Antoine Bisgambiglia

, Paul Bisgambiglia

and David R. C. Hill

University of Corsica, UMR 6134, Campus Grimaldi, Corte, France

Clermont Auvergne University, UMR 6158, ISIMA LIMOS, F-63173 Aubiere, France

Keywords:

Simulation Environment, Discrete-event Simulation, PDEVS, DPDEMAS, multiPDEVS.

Abstract:

Quartz is a modelling and simulation framework enabling the development and the execution of models based

on the Parallel Discrete Event System Speciﬁcation (PDEVS) formalism. In this paper we give an overview

of the tool by giving details on its design and features. An experimental comparison shows that Quartz yields

performances comparable to what is observed with aDEVS, one of the most efﬁcient tool implemented with

a compiled language. We present our efforts to provide dedicated expressions and veriﬁcation facilities to the

modeler and give examples of application domains that motivated this software. Namely, agent-based model-

ing through the Dynamic Parallel Discrete Event Multi-Agent (DPDEMAS) speciﬁcation and multicomponent

modeling with the multiPDEVS formalism.

1 INTRODUCTION

One among the many goals of the modelling and sim-

ulation ﬁeld is to provide tools to domain experts

so they may design and execute their models in a

convenient way. In this context, an important num-

ber of simulation framework based on the Discrete

Event System Speciﬁcation (DEVS) formalism (Zei-

gler et al., 2000) or its parallel variant (PDEVS) have

been proposed, e.g. VLE (Quesnel et al., 2009),

PyPDEVS (Van Tendeloo and Vangheluwe, 2014).

The DEVS formalism is a speciﬁcation language

which offers a precise description of the various enti-

ties involved in the modeling and simulation process.

In this paper we give an overview of Quartz,

a modelling and simulation framework based on

PDEVS (Chow, 1996). Its development is driven by

the following concerns: (1) allow the inclusion of the

framework in a larger simulation environment, (2) of-

fer acceptable performances in comparison with other

PDEVS-based simulators and (3), adopt an architec-

ture which facilitates the addition of new PDEVS

variant formalisms.

Among available simulation tools, three groups

can be established according to their strategy. The

ﬁrst allows full model compilation with its associ-

ated simulators all into an optimized executable. Con-

sequently, models must be programmed in a techni-

cal languages such as C++, as with the Virtual Lab-

oratory Environment (Quesnel et al., 2009), a.k.a

VLE, or with A Discrete EVent System simulator

(Nutaro, 1999), a.k.a aDEVS. Conversely, a second

group of simulators, such as PyPDEVS (Van Tende-

loo and Vangheluwe, 2014) or DEVS-Ruby (Frances-

chini et al., 2014), are based on interpreted lan-

guages, offering a more readable and intuitive syn-

tax for model developments, at the expense of perfor-

mances. A hybrid approach consists in implementing

parts of the simulator in a compiled language, while

offering a more ﬂexible language to develop mod-

els. DesignDEVS (Goldstein et al., 2017) lies in this

group: mainly implemented in C++, models can be

programmed with the Lua scripting language.

With the use of the Crystal language, Quartz lies

in the ﬁrst group of simulators implemented with a

technical language. However, due to Crystal similari-

ties with the Ruby syntax, its expressiveness is closest

to simulators belonging to the second group of sim-

ulators. As such, Quartz is able to produce an op-

timized executable since Crystal compiler relies on

the LLVM (Low Level Virtual Machine) infrastruc-

ture while offering a straightforward syntax to pro-

gram models with.

This paper is organized as follows. We ﬁrst intro-

duce the theory behind the PDEVS formalism and its

capabilities. Afterwards, an overview of the frame-

work is given to show how our concerns impacted its

design. We then focus on the features we introduce to

facilitate model development. Finally, we present the

applications domains that originally motivated the de-

120

Franceschini, R., Bisgambiglia, P-A., Bisgambiglia, P. and Hill, D.

An Overview of the Quartz Modelling and Simulation Framework.

DOI: 10.5220/0006864201200127

In Proceedings of 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH 2018), pages 120-127

ISBN: 978-989-758-323-0

velopment of Quartz and on which we carry our mod-

elling and simulation efforts.

2 BACKGROUND

The theory of modelling and simulation (TM&S) pro-

posed by (Zeigler et al., 2000) allows describing sys-

tems using the Parallel Discrete Event System Speci-

ﬁcation (PDEVS) in a modular and hierarchical way.

A coupled model describes a system as a network of

components while an atomic model describes the au-

tonomous behavior of a system. Formally, an atomic

model is described by M = (X, Y, S, δ

int

, δ

ext

, δ

con

where X and Y corresponds to the sets of input and

output port-values. S is the state of the system. Be-

havior is deﬁned by several state transitions, triggered

as events occur. There are two types of events: one

is triggered by the model itself and associated to the

internal transition (δ

int

); the second one depends on

inputs of the model and is associated to the external

transition (δ

ext

). A third transition function (δ

con

) al-

lows to handle simultaneous events of both kinds. In-

ternal events are planned via the time advance func-

tion ta. When they occur, the model can produce out-

puts via the λ function.

PDEVS has well-deﬁned operational semantics

thanks to the deﬁnition of abstract simulators, which

means models can be executed unambiguously on a

conforming implementation of the formalism. As

(Vangheluwe, 2000) previously showed, its generic

properties allows to represent other formalism. Con-

sequently, models expressed in several formalism can

be transformed to be executed in the same simulation

framework.

3 OVERVIEW

Quartz is a modelling and simulation framework im-

plemented in the Crystal programming language. It

can be considered as a replacement of DEVS-Ruby

(Franceschini et al., 2014). Crystal syntax is largely

inspired if not identical to the Ruby syntax. Mainly,

differences between the two lies in the possibility for

Crystal to add type annotations, this one being stati-

cally typed with type inference.

The architecture is designed to be generic and ex-

tensible, to allow the addition of other PDEVS-based

formalisms. To help the modeler design its models,

we expose an API (Application Programming Inter-

face) in agreement with the terms and concepts used

or deﬁned by the theory of M&S deﬁned by (Zei-

gler et al., 2000). The architecture respects as much

as possible the explicit separation principle between

modelling and simulation. This way, the modeler

can appreciate a familiar architecture, and can eas-

ily go from the model speciﬁcation to its implemen-

tation. The generic trait of the software is clearly

due to an extensive use of design patterns (Gamma

et al., 1994), such as Composite, Visitor, Observer,

or Publish-Subscribe. Figure 1 gives an overview of

the simulation components at play in the architecture,

while Figure 2 shows components at play in the mod-

elling part.

Simulation

Simulator

Processor

Coordinator

RootCoordinatorEventSet

«interface»

Simulable

realize

Notifier

«interface»

Notifiable

listeners

0..*

«interface»

Visitor

ProcessorAllocator

realize

creates

use

Figure 1: Simpliﬁed UML class diagram of simulation

components.

Model

AtomicModel CoupledModel

Port

InputPort

OutputPort

«interface»

Observer

State

downward

0..*

upward

0..*

siblings

0..*

«interface»

Observable

«interface»

Coupleable

0..*

host1

0..*

«interface»

Visitor

eic

0..*

eoc

0..*

Figure 2: Simpliﬁed UML class diagram of modeling com-

ponents.

To better explain our choices, we now develop

each trait that shaped the software design, in partic-

ular: the ability to react to events, modularity, and

performances.

3.1 Events

There are two types of events issued while simulating

a model.

The ﬁrst type of events is either related to model

state changes or to message passing through model

couplings. Those are issued on a per model-basis

through the Observer pattern. Such design can be

used to develop speciﬁc pieces of software that can

react to models dynamics. For example, one can de-

velop a graphical user interface for its model to help

An Overview of the Quartz Modelling and Simulation Framework

121

him better visualize the state of a model, which can

be laid out when necessary. Based on the same idea,

observing a port of a given model may be useful for

a piece of software responsible for plotting its values.

This pattern establish a simple way to react to the evo-

lution of models. It can be used by the modeler for

model-speciﬁc code, but can also be used by a larger

M&S environment relying on Quartz as a simulation

kernel.

The second type of events concerns the simula-

tion itself. They are issued to inform in which state

the model execution is. To propagate them, we use

the Publish/Subscribe pattern, so that software com-

ponents may be informed to one or more of the fol-

lowing events, depending on the messages they sub-

scribed for: 1) before/after simulation is initialized;

2) before/after simulation execution; 3) before/after a

simulation is abandoned (through an error or a cancel-

lation); 4) before/after a simulation is restarted. Sim-

ulation events can be useful at many different levels.

For example, the modeler can use them in its mod-

els to prepare or cleanup resources before and after a

simulation (e.g. open or closing a ﬁle). For the im-

plementers, this is an opportunity to develop new fea-

tures while having loose coupling between software

components. Finally, simulation events facilitates the

integration of the tool in a larger M&S environment.

In the same way, external plugins can also take ad-

vantage of those events. Also, the exposed simulation

API provides control to execute a simulation step-by-

step, to cancel it, to restart it, or to execute it until a

given virtual time.

3.2 Modularity

Through a modular design, our objective is to make

easier introducing new formalisms compatible with

PDEVS semantics (e.g. a PDEVS extension or a for-

malism that can be translated to PDEVS). Here, we

focus on two aspects illustrating Quartz modularity:

decoupling efforts of the I/O interface and tunable

event sets.

To support interactions between models, PDEVS

deﬁnes an input and output interface for each model,

so they can be coupled together. However, modular

couplings through I/O ports is not the only way to al-

low models to interact. In order to support formalisms

based on both modular and non-modular interactions,

a decomposition of the model is necessary to extract

its capacity to have I/O ports, which Quartz does by

providing a speciﬁc Coupleable interface (see Figure

2).

As (Van Tendeloo and Vangheluwe, 2014) sug-

gests, the most suitable scheduler directly depends on

the nature of the model. Therefore, we let the mod-

eller conﬁgure the scheduler for a speciﬁc simulation

usage. For cases where direct connection is disabled,

the modeler can conﬁgure the scheduler on a per cou-

pled model basis. We provide several event sets, gath-

ered as subclasses of the EventSet abstract class (see

Figure 1). To obtain better performances we imple-

mented two multi-list based event sets, which as their

names suggest rely on multiple lists to handle events,

deferring sorting process until really needed. We also

provide heap-based event sets, which can be preferred

by the modeller for a more predictable operation cost.

For cases where a speciﬁc event set is needed, the

modeler can eventually implements its own EventSet

subclass.

3.3 Performances

This section addresses our efforts to reduce the pro-

cessing time between each scheduled event. We ﬁrst

focus on the various optimizations we implements,

based on state-of-the art techniques. Then, through an

experiment, we show Quartz provides relative good

performances in comparison with other similar tools.

3.3.1 Optimization Techniques

A substantial amount of work dedicated to perfor-

mance improvement can be found in the literature. As

for Quartz, we treated the following aspects to offer

correct performances: 1) replacement of the original

message passing communication model by sequen-

tializing abstract simulators; 2) simpliﬁcation of the

model hierarchy when it has a depth superior to one;

3) implementation of a tunable event set, relying on

multiple priority queues where only active models are

considered.

Similarly to (Muzy and Nutaro, 2005), (Him-

melspach and Uhrmacher, 2006) or (Vicino et al.,

2015), Quartz is based on a sequential execution of

models. Message passing suggested in the abstract

simulators is not required and can equivalently be rep-

resented by a simple function call and the use of re-

turn values. As pointed out by (Vicino et al., 2015),

this call/return mechanism results in a predictable call

stack, which is linear to the depth of the model hier-

archy.

Note that if an important number of intermedi-

ate coupled models are to be simulated, the depth of

the hierarchy may cause a performance degradation,

if not cause a stack overﬂow. As a solution, we use

the direct connection (Chen and Vangheluwe, 2010),

an optimization technique that transforms the model

hierarchy in order to simplify it. The goal is to re-

duce the depth of the tree by removing intermediate

SIMULTECH 2018 - 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

122

coupled models, and by adjusting couplings between

models accordingly.

Direct connection allows to shorten the path a

message must take, but does not necessarily imply im-

proved execution time since as a result, the number of

models to be managed by a now unique coordinator

is larger. Depending on the naiveness of the event set

associated with the coordinator, which is responsible

to schedule events, processing time may become wor-

rying. Several multi-list based event sets, such as the

ladder queue (Tang et al., 2005) claim constant amor-

tized complexity for their operations. Those organize

events in different groups, which allows to postpone

sorting process until really needed, only on a small

part of queued events. Quartz provides an implemen-

tation of some of these structures, and lets the mod-

eller choose which to use as described in section 3.2.

3.3.2 Experimental Comparison

In order to evaluate performances of the framework

in comparison with other tools, results of an experi-

mental benchmark is proposed. We compare Quartz

with DEVS-Ruby (Franceschini et al., 2014), the tool

which inﬂuenced the presented framework, and with

aDEVS (Nutaro, 1999) which is considered in the lit-

erature as one of the most performing PDEVS based

simulator (Van Tendeloo and Vangheluwe, 2016).

The DEVStone benchmark (Wainer et al., 2011)

is used, it has been speciﬁcally proposed to com-

pare DEVS simulators and generates automatically

a model hierarchy following a conﬁgurable structure

and behavior. The environment used for our com-

parison is based on a Intel CoreTM i5-3360M, 16

GB (2xDDR3 1600Mhz) of RAM and a Toshiba

MK5061GS hard drive. The software stack relies

on Ubuntu 16.04, the Quartz framework (commit

a663dfe) compiled with Crystal 0.24.0 (in release

mode), aDEVS 2.8.1 compiled with gcc 4.8.2 (-O3

ﬂags), and DEVS-Ruby 0.5.1 interpreted by Ruby

2.2. Mean wall clock time of 10 repetitions is mea-

sured for each platform. DEVStone is conﬁgured

with a ﬁxed depth of 3, the ”HI” coupling type and

transition functions times set to 0secs. The varying

parameter is the width, which corresponds to the num-

ber of models in each level of the hierarchy.

Figure 3 is a graph of the results for each bench-

marked simulator. As we hoped for, the port of

DEVS-Ruby in Crystal results in a substantial perfor-

mance beneﬁt since Quartz is signiﬁcantly faster than

DEVS-Ruby. Moreover, Quartz is on the same order

of performance as aDEVS, which validates its effec-

tiveness.

0.2

0.4

0.6

0.8

200 400 600 800 1000 1200 1400 1600 1800 2000

Elapsed time (s)

DEVStone width

aDEVS 2.8.1 (gcc 4.8.2 -O3)

Quartz a663dfe (crystal 0.24.0)

DEVS-Ruby 0.5.1 (Ruby 2.2)

Figure 3: Mean execution times of each platform for the

DEVStone benchmark with a varying numbers of models.

4 MODEL DEVELOPMENT

To facilitate model development and its execution,

we address two particular issues. Given Quartz is a

framework, no GUI is proposed to help model design.

However, we propose dedicated expressions which

make programming models less tedious while allow-

ing to gather data about models statically. Also, in

order to guaranty models respects PDEVS syntax, we

work on a veriﬁcation system that allows to detect er-

rors statically or at runtime.

4.1 Dedicated Expressions

Our framework does not provide a graphical environ-

ment for the modeling phase. Instead, we rely on the

modeller capability to program its models given the

exposed API. Given models must be programmed, an

important aspect is to lower the barrier by easing code

reading and writing. With meta-programming tech-

niques, we offer a set of dedicated expressions. Crys-

tal supports lexical closures and has a macro system

allowing to react to speciﬁc changes during the con-

struction of the abstract syntax tree (AST) of a pro-

gram, which makes it well adapted to the deﬁnition

of a domain-speciﬁc language. Since the main part of

model code is found in atomic models, we here focus

on speciﬁc expressions we offer to ease programming.

Those are implemented using macros and are part of

the DSEL. The ﬁrst ones ease ports deﬁnition whereas

the second one ease state variables declaration.

4.1.1 Ports Declaration

Two expressions allows to declare ports associated

with a model at the class-level. Adding an input port

is associated with the input keyword; adding an out-

put port is associated with the output keyword. Both

An Overview of the Quartz Modelling and Simulation Framework

123

are formally deﬁned by the following BNF expres-

sion:

< ident > : := / a-ZA - Z_ /{/ a - ZA - Z0 -9 _ / }

< p ort nam e > ::= < ident > | ( ’" ’ < ident >

’" ’) | ( ’: ’ < por tna me >)

< por tdef > ::= (" i nput " | " outp u t ")

< p ort nam e > { ’ , ’ < por tname > }

Using such keywords is more concise than using

the provided API. Without them, the modeler has to

overload the constructor and use speciﬁc methods to

attach ports to the the model.

4.1.2 State Variables Declaration

Another expression is dedicated to the declaration of

a state variable associated with a model. The mod-

eler is then able to specify the name and type of each

variable using the state_var keyword, and may also

provide an initial value to it. It is deﬁned by the fol-

lowing BNF expressions:

<type > ::= /A -Z / { / a - zA -Z0 -9/ }

<svar > ::= " st a t e _ v a r "

< ident > ’: ’ < type > [( ’= ’ < arg >) | <

block >]

Note that <arg> and <block> terms represents any

argument that is assignable to a lexical closure as de-

ﬁned by the Crystal syntax. There is no restriction on

which type may be used as a state variable, so it is

possible to use advanced data structures. In addition

to make state variable declaration shorter, this macro

allows to identify statically all instance variables that

are part of the state of a model. We take advantage of

this via meta-programming techniques in order to pro-

vide several features seamlessly by generating auto-

matically: 1) model constructors for model initializa-

tion; 2) encapsulation of the state variables; 3) a spe-

ciﬁc State subclass associated with the model; 4) the

serialization and deserialization of the model state;

5) speciﬁc code to ease model parameters exploration.

4.2 Veriﬁcation

Veriﬁcation can be used to make sure a model does

not include errors. This process can be achieved

on different levels: either statically (before or dur-

ing compilation) or at runtime (during a simulation).

Some errors are tied to the speciﬁcities of a model,

whereas others are more generic. Generic ones can

be veriﬁed no matter which model is to be veriﬁed.

As one of our aim is to enforce modeling constraints,

Quartz attempts to detect some errors both at runtime

or statically.

4.2.1 Runtime Veriﬁcations

Quartz applies some generic veriﬁcations at runtime.

Those are related to generic properties that can be

veriﬁed for all PDEVS models, and includes: 1) re-

sult positivity when applying the time advance func-

tion; 2) couplings validity (e.g. no feedback loops, in-

volved models belonging to a common coupled model

or to the coupled itself); 3) belonging of ports ref-

erenced in a given output to the appropriate model;

4) compatibility of the processor with its associated

model.

As for errors related to models themselves, a fea-

ture allow the modeler to express speciﬁc properties

about their models that can be checked during sim-

ulation. Albeit this feature is not meant to perform

an exhaustive exploration of all possible states of a

model, invalid states can eventually be detected dur-

ing an iteration of the M&S process.

AtomicModel

RuntimeChecker

contexts: Array<Symbol>

check(instance: Verifiable)

«interface»

Verifiable

valid?(context: Symbol): Bool

errors(): Array<VerificationError>

0..*

Figure 4: UML class diagram of components involved in

runtime checks.

Figure 4 shows software components used to ver-

ify the state of a model. Atomic models implement

the Verifiable interface, and consequently hold a

reference to components encapsulating user-deﬁned

rules used to test properties (i.e. RuntimeChecker).

The modeler can specialize this component or use a

predeﬁned subclass.

In order to perform such veriﬁcations, each new

state produced after a transition triggers a check. If

the feature is enabled and that an error is detected, a

strict mode interrupts the simulation, while a normal

model warns the user.

A dedicated expression can be used to deﬁne prop-

erties to be checked. Following the approach we de-

scribed in section 4, properties are declared using the

check keyword at the class-level, in the same way as

for the state_var keyword.

Listing 1 shows the deﬁnition of a sample model.

In this example, all instances of SampleModel will

have a state ”bearing” whose type is a 2 bytes integer

representing an angular value. The check keyword is

used to verify that the angle is always in [0, 360[.

cl a ss S a m p l e M o d e l < AtomicModel

stat e _ v a r bearin g : Int 16 = 90

ch e ck : beari ng , n u m e r i c a l i t y : { gte :

0, lt : 3 60}

def i n t e r n a l_t r a n s i t i on

@be a r i n g = -123

end

SIMULTECH 2018 - 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

124

end

Listing 1: Deﬁnition of a sample model using dedicated

expressions.

The internal transition assigns an invalid value to the

bearing variable. The error is catched at runtime and

produce the following output:

(10:17 : 5 1 : 2 7 3 ) > ’ nav ’ is i n v alid (

con t e x t : ’ internal_trans i t i o n ’ , v time :

1. 0) . Erro r s : [’ beari ng ’ mu st be

gre a t e r tha n or eq u al to 0]

4.2.2 Static Veriﬁcations

Compared to checks performed at runtime, static ver-

iﬁcation can detect errors much earlier in the develop-

ment process of a model. It is preferable since compi-

lation can be aborted if errors are detected. According

to the adopted metamodel, a language type system al-

ready allows to statically raise some structural errors.

However, some syntactic errors are more difﬁcult to

detect and require a speciﬁc analysis of the program

syntax tree. Using Crystal macro system, we are able

to react to speciﬁc events during compilation. For ex-

ample, the inherited macro deﬁnition within a class

offers an opportunity to apply veriﬁcations to all its

subclasses.

As a proof of concept, we give an example by

checking if the time advance function of an atomic

model is syntactically correct. Since Quartz use in-

stance variables to store the state of an atomic model,

any method can access and mutate its state. If this

is consistent with PDEVS regarding transitions func-

tions, it is not the case for the time advance function.

Here, all methods that belongs to AtomicModel sub-

classes are checked. When the method corresponds to

the time advance function, its body is inspected via a

macro. If an instance variable marked as a state vari-

able is modiﬁed, compilation is aborted with a con-

textual error message.

cl a ss MyMod e l < A t o m i c M o d e l

stat e _ v a r x : Int 3 2

def tim e _ a d v a n c e

@x = 54

re t u rn I N F INITY

end

Listing 2: Deﬁnition of an erroneous atomic model.

An example, Listing 2 deﬁnes an atomic model

which is valid regarding Crystal language seman-

tics, but invalid regarding PDEVS semantics. This

is caught at compile time by the rule described earlier

and produces the following output:

Er r or in e x a m p les / my m o del . cr :2 1: " you

are not s u p p o s ed to mut a te th e sta te

of an a tomi c m o del f rom the #

time_advance m e thod ."

@x = 54

ˆ˜˜ ˜ ˜ ˜ ˜

We should emphasize this particular check can be

avoided by adopting a metamodel which strictly con-

forms to the formalism. We could instead encapsulate

the state in an immutable data type and pass it to the

time advance function, at the expense of expressivity.

We deﬁned additional rules using this technique to

enforce PDEVS constraints, such as preventing ports

creation or removal outside the constructor, prevent-

ing state modiﬁcation from λ function, or preventing

the deposit of an output value outside λ.

However, this technique has limits. Crystal

macros are interpreted and can slow down compile

times. Also, more complicated rules are difﬁcult to

implement and hard to follow given the particular syn-

tax of Crystal macros. We currently explore an alter-

native which consists in developing a static analysis

tool to freely explore the abstract syntax tree. Since

Crystal compiler is self-bootstrapped, we can use its

parser and lexical analyzer to implement our model

analysis on top of the semantic analysis done by the

compiler itself.

5 APPLICATIONS

Due to its generic design, Quartz can be used to de-

velop any kind of PDEVS models and is not tied

to a speciﬁc domain. As we showed in section 3,

its modularity promotes the integration of new for-

malisms provided that their semantics conforms to

that of PDEVS.

However, two main reasons motivated the devel-

opment of Quartz. The ﬁrst one was to support a

multi-component approach, where models can inﬂu-

ence each other directly instead of interacting through

I/O ports. The second reason was to facilitate the

modelling and simulation of agent-based models by

implementing the Dynamic Parallel Discrete Event

Multi-Agent Speciﬁcation (Franceschini et al., 2017),

which formalizes the entities at play in a multi-agent

system using PDEVS constructs.

5.1 Multi-component Models

We used Quartz to implement the multiPDEVS for-

malism (Foures et al., 2018), which enable interac-

tions between components in a non-modular way. In-

stead of interacting through messages, components

An Overview of the Quartz Modelling and Simulation Framework

125

inﬂuence each other directly via state transitions.

While multiPDEVS lies in a lower level than a mod-

ular coupled network of systems such as PDEVS,

some class of systems may be best modelled in a non-

modular way. For example, systems such as cellu-

lar automata, individual-based models, and eventually

cellular environments in agent-based systems may be

good candidates.

Figure 5: A visualization of a classic Game of Life model

based on the multiPDEVS formalism.

Both modular and non-modular approaches can

be mixed to represent a particular system. First for-

mally, since a multiPDEVS model can be coupled

together with other PDEVS models, as showed in

(Foures et al., 2018), and secondly, on the implemen-

tation side as showed in section 3.2.

Although it can be used for other purposes, we

use multiPDEVS to represent spatially-explicit sys-

tems. For example, Figure 5 shows a visualization

of a cellular automaton modelled using multicompo-

nent capability of Quartz: the classic John Conway’s

Game of Life. In a similar way, we used the multi-

component approach to represent a ﬁrespread model

as a cellular automaton (Foures et al., 2018). As we

will see in the next section, we also use multicom-

ponent models within modular systems to represent

multi-agent systems.

5.2 Agent-based Models

Although Quartz is provided as a generic modelling

and simulation framework and as such, can be applied

to various domains, we personally intend to apply it

for multi-agent based simulation.

This software original main purpose was to pro-

vide a simulation kernel for a multi-agent system

speciﬁcation based on PDEVS and various exten-

sions. The DPDEMAS (Dynamic Parallel Discrete

Event Multi-Agent System) speciﬁcation (Frances-

chini et al., 2017) formalizes generic entities which

may compose an agent-based model. Given the

amount of components and interactions involved in

a multi-agent system and the diversity of application

domains, it is difﬁcult to express it in a single formal-

ism. As mentioned in section 2, PDEVS is often used

as a pivotal formalism. Models originally deﬁned in

other formalisms can be equivalently expressed using

PDEVS. Hence, PDEVS was chosen to deﬁne DPDE-

MAS since it allows to couple heterogeneous models

modularly. DPDEMAS provides a well-deﬁned struc-

ture for components that can be found in agent-based

models, such as agents and environments. Seman-

tics are also well deﬁned, since actions performed by

agents in their environment or interactions between

agents are also formalized.

Figure 6: A visualization showing the environment of the

SugarScape agent-based model (Epstein and Axtell, 1996).

Following this approach and the Quartz frame-

work, we replicated several classic agent-based mod-

els, such as the SugarScape (Epstein and Axtell,

1996) model. Figure 6 shows a visualization of the

SugarScape multi-agent system implemented using

the DPDEMAS speciﬁcation.

6 CONCLUSIONS

In this paper, we gave an overview of the Quartz

modelling and simulation framework. We described

its architecture as well as its features. The modular

and extensible architecture conforms with the princi-

ple of separation between modelling and simulation.

By this mean, integration of new formalisms is pos-

sible. The API allows to react to events issued by

the models or their processors during simulation. We

worked on several aspects of the framework to pro-

vide acceptable performances, in particular: (1) a se-

quential architecture, which provides predictable exe-

cution, (2) schedulers providing a constant amortized

complexity for all operations and (3), an automatic

SIMULTECH 2018 - 8th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

126

transformation of the model hierarchy to a depth of

one. Originally inherited from DEVS-Ruby (Frances-

chini et al., 2014), we showed that Quartz allows to

combine expressiveness with the performances of a

compiled language. To facilitate model development,

we described a set of dedicated expressions aiming

to simplify model programming, as well as a veriﬁca-

tion technique to detect potential errors about models,

either statically or at runtime.

As a perspective of this work, we wish to de-

velop Quartz by focusing on four aspects: (1) grow

the set of dedicated expressions in order to offer a

more complete domain-speciﬁc language and eventu-

ally consider a domain-speciﬁc external language; (2)

improve static veriﬁcations based on macros by devel-

oping a static analysis tool; (3) implement distributed

simulation algorithms; (4) promotes the tool through

a rich documentation to facilitate its use.

ACKNOWLEDGEMENTS

This work is supported by the Corsican region (CTC)

and the European Union (EU) through a PO-FEDER

regional program: MoonFish.

REFERENCES

Chen, B. and Vangheluwe, H. (2010). Symbolic Flattening

of DEVS Models. In Proceedings of the 2010 Sum-

mer Computer Simulation Conference, pages 209–

218, San Diego, CA, USA. Society for Computer Sim-

ulation International.

Chow, A. C. H. (1996). Parallel DEVS: A parallel, hi-

erarchical, modular modeling formalism and its dis-

tributed simulator. TRANSACTIONS of the Society for

Computer Simulation International, 13:55–67.

Epstein, J. M. and Axtell, R. L. (1996). Growing Artiﬁcial

Societies. Social Science from the Bottom Up. The

MIT Press.

Foures, D., Franceschini, R., Bisgambiglia, P.-A., and Zei-

gler, B. P. (2018). multiPDEVS: A Parallel Multicom-

ponent System Speciﬁcation Formalism. Complexity,

2018(3751917):19.

Franceschini, R., Bisgambiglia, P.-A., and Bisgambiglia,

P. (2017). Approche formelle pour la mod

elisation

et la simulation de syst

emes multi-agents. In Vingt-

cinqui

emes Journ

ees Francophones sur les Syst

emes

Multi-Agents, pages 193–202, Caen, France.

Franceschini, R., Bisgambiglia, P.-A., Bisgambiglia, P., and

Hill, D. R. C. (2014). DEVS-Ruby: a Domain Speciﬁc

Language for DEVS Modeling and Simulation (WIP).

In DEVS 14: Proceedings of the Symposium on The-

ory of M&S, pages 393–398. SCS International.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1994). Design Patterns: Elements of Reusable

Object-Oriented Sofware. Addison Wesley.

Goldstein, R., Breslav, S., and Khan, A. (2017). Practical

aspects of the DesignDEVS simulation environment.

SIMULATION.

Himmelspach, J. and Uhrmacher, A. M. (2006). Sequential

Processing of PDEVS models. In Proceedings of the

3rd EMSS, pages 239–244.

Muzy, A. and Nutaro, J. (2005). Algorithms for efﬁcient

implementations of the DEVS & DSDEVS abstract

simulators. In 2008 12th IEEE International Sympo-

sium on Distributed Simulation and Real-Time Appli-

cations (DS-RT), pages 273–279. IEEE.

Nutaro, J. (1999). ADEVS (A Discrete EVent

System simulator). Arizona Center for Inte-

grative Modeling {&} Simulation (ACIMS),

University of Arizona, Tucson. Available at

http://www.ece.arizona.edu/nutaro/index.php.

Quesnel, G., Duboz, R., and Ramat, E. (2009). The Virtual

Laboratory Environment – An operational framework

for multi-modelling, simulation and analysis of com-

plex dynamical systems. Simulation Modelling Prac-

tice and Theory, 17(4):641–653.

Tang, W. T., Goh, R. S. M., and Thng, I. L.-J. (2005).

Ladder Queue: An O(1) Priority Queue Structure

for Large-scale Discrete Event Simulation. ACM

Transactions on Modeling and Computer Simulation,

15(3):175–204.

Van Tendeloo, Y. and Vangheluwe, H. (2014). The Modular

Architecture of the Python(P)DEVS Simulation Ker-

nel Work In Progress paper. In Proceedings of the

Symposium On Theory of Modeling and Simulation

(TMS’14) SpringSim 2014, pages 387–392, Tampa,

FL, USA. SCS.

Van Tendeloo, Y. and Vangheluwe, H. (2016). An evalua-

tion of DEVS simulation tools. SIMULATION.

Vangheluwe, H. (2000). DEVS as a common denomina-

tor for multi-formalism hybrid systems modelling. In

IEEE International Symposium on Computer-Aided

Control System Design, 2000. CACSD 2000, pages

129–134. IEEE.

Vicino, D., Niyonkuru, D., Wainer, G. A., and Dalle, O.

(2015). Sequential PDEVS Architecture. In DEVS

15: Proceedings of the Symposium on Theory of Mod-

eling & Simulation: DEVS Integrative M&S Sympo-

sium, pages 906–913, Alexandria, VA, USA.

Wainer, G. A., Glinsky, E., and Gutierrez-Alcaraz, M.

(2011). Studying performance of DEVS modeling and

simulation environments using the DEVStone bench-

mark. SIMULATION, 87(7):555–580.

Zeigler, B. P., Kim, T. G., and Praehofer, H. (2000). Theory

of Modeling and Simulation, 2nd Ed. Integrating Dis-

crete Event and Continuous Complex Dynamic Sys-

tems. Academic Press, Orlando, FL, USA, 2nd edi-

tion.

An Overview of the Quartz Modelling and Simulation Framework

127