Basic Components of DES

Simulation State As shown before, the evolution of the simulation model

depends on the state transitions produced by a transition function in the form

3

σ(s, e) : S × E → S. Therefore, a DES model cannot prescind from the presence

of a simulation state. Historically, simulations states where regarded as a set of global variables which where explicitly defined within the model code and

altered by the execution of events.

Events The evolution of a simulation model proceeds thanks to the execution

of events. As stated before, an event is impulsive, i.e. it has no duration in time. A simulation model must define the logic associated with each event a-

priori (i.e., no “unknown events” can be delivered to a simulation model), thus a closed set E of events that can be executed during the simulation run must be programmatically defined. Each event e ∈ E is therefore handled by one of the

event handlers registered in the system. Due to the sequential nature of DES, during the execution of an event e any variable belonging to the simulation state

S can be freely accessed.

In order to give start to the simulation, an initial event (often referred to

as INIT) must be scheduled. The typical behaviour of this event entails the set up of the simulation model, i.e. the definition of the simulation state’s

initial conditions and the scheduling of next event(s) to be processed. The INIT event is usually automatically generated by the simulation kernel, but due to

its model-dependent nature, it must be explicitly managed by an event handler specifically implemented in the simulation model.

Clock Since a simulation model describes the evolution of a system during time, the model must keep track of this advancement. The simulation clock is

usually a global variable (which is often, but not necessarily, updated by the simulation kernel) which tracks this temporal evolution. It is important to em-

Therefore, given the nature of DES, its value does not continuously change, in-

stead it jumps from the timestamp Te of one event e to the timestamp Te0 of

the next event e0.

Event Queue During the execution of event e, the simulation model can

generate any number of new events, depending on the actual model’s logic. For example, given that the events are impulsive, activities that extend over

time are often modelled as a sequence of differentiated events, which might be generated, e.g., during the first event of the sequence. This behaviour requires a

data structure which takes care of managing generated (but still to be executed) events.

Since all the events are associated with their respective timestamps, the

list of pending events must be ordered according to this value [59]. In this way, determining which is the next event to be processed is as easy as taking the event

found on the head of the event queue. If the simulation kernel fails to do so, it means that the simulation might execute event e_x associated with timestamp

Tx> Tmin and modify state variables which were needed by event emin. This is like having the future which affects the past, and is clearly unacceptable: this

kind of error is called causality error.

The actual implementation of the event queue is not necessarily a linked

list, as due to performance requirements we want to reduce the time needed for insertion of events and selection of the next event to be processed [80]. Several

proposals entail the adoption of skip lists [131], calendar queues [17], splay trees [153], or ladder queues [35].

Ending Condition A large number of simulation models describe phenomena

Furthermore, many models involve stochastic processes to describe the evolution

of the system, making it impossible to predict before-hand how the simulation will evolve (isn’t this the goal of simulation, anyway?!). In order to collect

statistics which are meaningful for a specific experiment, it is important to configure the simulation so that when a particular ending condition is met, the

simulation halts. This can be done by specifying a time range of interest for the simulation (this kind of ending condition can be handled by the simulation

kernel), or by inspecting particular values of the simulation state along the simulation trajectory (this must necessarily be done by the simulation model,

using specific API provided by the simulation kernel).

Simulation Object Although a simulation object is not mandatory for a

DES model, it is an interesting extension which gives more semantic power to the model writer, and is therefore supported by a large number of simulation

kernels. A simulation object describes a portion of the whole model, let it be a spatial portion (e.g., a “cell” in grid simulations, like military simulations

[119]) or an agent (e.g., in agent-based social simulations [93], where simulation objects can model the behaviour of agents acting within the system). This

allows the model writer to concentrate on the description of subportions of the whole model, and to link them together in the end, via the usage of special

“interconnection events”, much like what the {Zi,j} set of Equation (2.2) was thought for.

Additionally, the simulation state can be reorganized, so that each simulation

object has its own set of state variables. As it will be shown in Section 2.3, this has been a fundamental step in literature to move DES to parallel/distributed

Algorithm 2.1 DES Skeleton procedure Init

End ← false

initialize State, Clock schedule IN IT end procedure

procedure Simulation-Loop while End == false do

Clock ← next event’s time process next event

Update Statistics end while

end procedure