General Principles and Simulation

Software
SYSC 4005/5001W
Discrete Simulation/Modeling
Winter 2024

1
General Principles

2
Chapter Overview
• The goal is to develop a common framework for
complex systems modeling using DES. Entities
and
attributes
• In DES, a system is modeled in terms of:
• its state at each point in time, the entities that
pass through it, the entities represent system DES
resources, and activities and events that Building
cause state change. Blocks

• DES are appropriate when changes in system Events Activities

state occur only at discrete points in time.

• The focus is on the fundamental concepts and
methodologies underlying DES simulation
packages.
3
DES Concept of Dynamic & Stochastic Systems (1/3)

• A collection of entities (e.g., people, machine, ..) that interact together

System over time to accomplish one or more goals.

• An abstract representation of a system that describes a system in terms of

Model state, entities, sets, processes, events, activities, and delays.

System • A collection of variables that contain all information necessary to describe the
state system at any time.

• Any object or component in the system that requires explicit representation in

Entity the model (e.g., a server, a customer, a machine).

4
DES Concept of Dynamic & Stochastic Systems (2/3)

• The properties of a given entity (e.g., the priority of a waiting customer, the routing of
Attributes a job through a job shop)

List (or • A collection of (permanently or temporarily) associated entities ordered in some

set) logical fashion, such as first come first serve.

• An instantaneous occurrence that changes the state of a system, such as an arrival

Event of a new customer.

Event • A record of an event to occur at the current or future time along with any associated
notice data necessary to execute the event (at a minimum, it has event type and time).

5
DES Concept of Dynamic & Stochastic Systems (3/3)

• A list of event notices for future events, ordered by time of

Event list occurrence, aka future event list (FEL).

• A duration of time of specified length (e.g., a service time or

Activity interarrival time) which is known when it begins.

• A duration of time of unspecified indefinite length, which is not

Delay known until it ends.

Clock • A variable representing simulated time, usually called CLOCK.

6
More on Lists
• Sometimes are called sets, queues, or
chains.
• Lists are used to hold both entities and event
notices:
• The entities are always ordered by some
rule, such as FIFO or LIFO, or are ranked
by some entity attribute, such as priority
or due date.
• The future event list (FEL) is always
ranked by the event time recorded in the
event notice.

7
More on Activities
• An activity represents a service time, an interarrival time, or any other
processing time.
• An activity’s duration may be specified in a number of ways:
1. Deterministic: e.g., always exactly 5 minutes;
2. Statistical: e.g., as a random draw from the set {2, 5, 7} with equal
probabilities;
3. A function depending on system variables and/or entity attributes,
e.g., loading time for an iron ore ship as a function of the ship’s
allowed cargo weight and the loading rate in tons per hour.
• Sometimes called an unconditional wait.

8
Durations of Activities
• A duration of an activity:
• is computable from its specification at the instant it begins, and
• is not affected by the occurrence of other events.

• To keep track of activities and their expected completion time, at the

simulated instant that an activity duration begins, an event notice is
created having an event time equal to the activity’s completion time.
• E.g., if the current simulated time is CLOCK = 100 min. and an
inspection time of exactly 5 min is just beginning, then an event notice
is created that specifies the type of event (an end-of-inspection
event), and the event time (100 + 5 = 105 min.)

9
More on Delays
• Unlike an activity, a delay’s duration is not specified ahead of time, but
rather is determined by system conditions.
• A delay’s duration is measured and is one of the desired outputs of a
model run.
• A delay ends when some set of logical conditions becomes true or one or
more other events occur:
• e.g., a customer’s delay in a waiting line may be dependent on the
number and duration of service of other customers ahead in line as
well as the availability of servers and equipment.
• Sometimes called a conditional wait.

10
Primary vs. Secondary Events

• A primary event is the completion of an activity;

• it is managed by placing an event notice on the FEL*.
• A secondary event is the completion of a delay;
• is not represented by event notices, and doesn't appear on the FEL.
• Delays are managed by placing the associated entity on another list until
such time as system conditions permit the processing of the entity.

* FEL contains all event notices for events that have been scheduled to occur
at a future time

11
Example – Call Center
Lecture: Simulation Examples – Slide 30
Consider the Able–Baker call center system. A discrete-event model has
the following components:
• System state
𝐿𝐿𝑄𝑄 (𝑡𝑡), the number of callers waiting to be served at time 𝑡𝑡;
𝐿𝐿𝐴𝐴 (𝑡𝑡), 0 or 1 to indicate Able as being idle or busy at time 𝑡𝑡;
𝐿𝐿 𝐵𝐵 (𝑡𝑡), 0 or 1 to indicate Baker as being idle or busy at time 𝑡𝑡.
• Entities
Neither the callers nor the servers need to be explicitly represented,
except in terms of the state variables, unless certain caller averages
are desired.

12
Example – Call Center
Lecture: Simulation Examples – Slide 30
• Events
Arrival event;
Service completion by Able;
Service completion by Baker.
• Activities
Interarrival time,
Service time by Able,
Service time by Baker,
• Delay
A caller’s wait in queue until Able or Baker becomes free.

13
Dynamic Description of DES Model

How are activities

How does each event defined (i.e., Can the activity begin
What event marks the regardless of system
affect system state, deterministic,
beginning or end of state, or is its beginning
entity attributes, and probabilistic, or some conditioned on the system
other mathematical each activity?
set contents? being in a certain state?
equation)?

Which events trigger What events should be

Under what conditions generated at time 0 to
the beginning (and What is the system
does a delay begin or “prime” the model? i.e., to
end) of each type of state at time 0? get the simulation
end?
delay? started?

14
System Snapshots
• A DES is the modeling of a system over time;
• system’s state changes occur at discrete points in time (when an
event occurs.)
• A DES proceeds by producing a sequence of system snapshots that
represent the evolution of the system through time.
• A snapshot at a given time (CLOCK = 𝑡𝑡) includes:

1. the system state at time 𝑡𝑡, 4. the current values of

2. FEL: a list of all activities cumulative statistics and
currently in progress and counters that will be used to
when each activity will end, calculate summary statistics
at the end of the simulation.
3. the status of all entities,

15
System Snapshots – Prototype

16
The Event Scheduling/Time Advance Algorithm
This Algorithm shows the sequence of actions that DES must perform to:
1) advance the clock, and 2) build a new system snapshot.
• The mechanism for advancing simulation time and guaranteeing that all
events occur in correct chronological order is based on the FEL.
• Future event scheduling means that:
1. at the instant an activity begins, its duration is computed or drawn
as a sample from a statistical distribution, and
2. the end-activity event, together with its event time, is placed on FEL.
• Random future events are represented by the end of some activity, which
in turn is represented by statistical distribution.

17
 The Event Scheduling/Time Advance Algorithm

The FEL is ordered by

event time, the events are
arranged chronologically:
𝑡𝑡 < 𝑡𝑡1 ≤ 𝑡𝑡2 ≤ 𝑡𝑡3 ≤ ⋯ ≤ 𝑡𝑡𝑛𝑛

The imminent event is the

event associated with time
Time 𝑡𝑡 is the 𝑡𝑡1 , i.e., the next event that
value of CLOCK At time 𝑡𝑡, the FEL contains all will occur.
(the current value previously scheduled future
of simulated time. events and their event times.

18
The Event Scheduling/Time Advance Algorithm

A new system snapshot

The system snapshot at
The imminent event notice for time 𝑡𝑡1 is created
CLOCK = 𝑡𝑡 is updated.
is removed from the FEL, based on the old snapshot
Then, the CLOCK is
and the event is executed. and the nature of the
advanced to CLOCK = 𝑡𝑡1
imminent event.

At time 𝑡𝑡1 , new future After the new system

events may or might not snapshot for 𝑡𝑡1 has been This process
repeats until
be generated. If any are, updated, CLOCK is simulation is
their event notices are advanced to the time of over.
created and properly the new imminent event,
added on FEL. and it is executed.

19
Managing FEL
• The length and contents of FEL are constantly changing as simulation
progresses  this requires an efficient management.
• List processing is how to manage a list. The major list processing
operations performed on a FEL are:
• removal of the imminent event, its removal is as efficient as possible,
• addition of a new event, and
• occasionally removal/cancellation of an event.
• Last two operations requires a search of the list. The efficiency of this
search depends on the logical organization of the list and on how the
search is conducted.

20
Managing FEL – An Illustration

In Step 4, to determine the correct position of

Event 4 on the FEL, a top-down search (shown
to the right) or a bottom-up search can be used.

21
Managing FEL – An Illustration (cont.)

22
System Snapshot Creation
• The system snapshot at time 0 is defined by
1. the initial conditions, which define the system state at time 0, and
2. the generation of exogenous events, such as an arrival to a
queueing system.
• At time 0, the first arrival event is generated and is scheduled on FEL.
• When the clock eventually is advanced to the time of this first arrival, a
second arrival event is generated. Three examples:
• bootstrapping,
• service completion event in a queuing simulation,
• alternate generation of runtimes and downtimes for a machine.

23
Generating Future Events
Bootstrapping

An interarrival time, 𝑎𝑎∗ is

generated and then
added to the current
time, CLOCK = 𝑡𝑡

The resulting event time,

𝑡𝑡 + 𝑎𝑎 ∗ = 𝑡𝑡 ∗ is used to
position the new arrival Generation of an external arrival stream by bootstrapping
event notice on the FEL

24
Generating Future Events
Service Completion Event in Queueing Simulation

• When a customer completes service, at current time CLOCK = 𝑡𝑡, if the

next customer is present, then a new service time, 𝑠𝑠 ∗ , will be generated
for the next customer.
• The next service completion event will be scheduled to occur at future
time 𝑡𝑡 ∗ = 𝑡𝑡 + 𝑠𝑠 ∗ , by placing onto the FEL a new event notice, of type
service completion, with event time 𝑡𝑡 ∗ .
• A service-completion event will be generated and scheduled at the time
of an arrival event provided that, upon arrival, there is at least one idle
server in the server group.

25
Generating Future Events
Service Completion Event in Queueing Simulation

• Beginning service is a conditional event.

• Service completion is a primary event.
• A conditional event, such as beginning service, is triggered by a primary
event’s occurring and by certain conditions prevailing in the system.
• Only primary events appear on the FEL.

26
Generating Future Events
Alternate Generation or Runtime and Downtime

• The alternate generation of runtimes and downtimes for a machine

subject to breakdowns events.
• At time 0, the first runtime will be generated, and an end-of-runtime
event (primary event) will be scheduled.
• Whenever an end-of-runtime event occurs, a downtime will be
generated, and an end-of-downtime event (primary event) will be
scheduled on the FEL.
• When the CLOCK is eventually advanced to the time of this end-of-
downtime event, a runtime is generated, and an end-of-runtime event is
scheduled on the FEL.

27
Ending the Simulation

• Every simulation must have a stopping event 𝐸𝐸 which defines how long
the simulation will run.
• There are two ways to stop a simulation:
1. at time 0, schedule a stop simulation event at a specified future time
𝑇𝑇𝐸𝐸  the simulation will run over the time interval [0, 𝑇𝑇𝐸𝐸 ].
2. run length 𝑇𝑇𝐸𝐸 is determined by the simulation itself. Generally, 𝑇𝑇𝐸𝐸 is
the time of occurrence of a specified event 𝐸𝐸.
• In case 2, 𝑇𝑇𝐸𝐸 is not known ahead of time. It could be one of the statistics
of primary interest to be produced by the simulation.

28
World Views

A World View is the modeling framework that a modeler uses to

present a system and its behavior.

Event scheduling: Process interaction: Activity scanning:

the concentration is the focus is on the focus is on the
on events and their processes. A activities of a model
effect on system process is the life and their start
state. cycle of an entity. conditions.
Uses a fixed time
Use variable time advance
increment

29
World View – Process Interaction

Two interacting customer processes in a single-server queue

30
World View – Activity Scanning
• The focus is on the activities of a model and those conditions that allow
an activity to begin.
• At each clock advance, the conditions for each activity are checked, and,
if the conditions are true, then the corresponding activity begins.
• the repeated scanning to discover whether an activity can begin
results in slow runtime on computers  the pure activity-scanning
approach has been modified by the three-phase approach
• it combines some of the features of event scheduling with activity
scanning
• it allows for variable time advance and the avoidance of scanning
when it is not necessary,
• it keeps the main advantages of the activity-scanning approach.

31
Manual Simulation Using Event Scheduling
• In the conducting of an event-
scheduling simulation, a simulation
table is used to record the successive
system snapshots as time advances.

Example: Single-Channel Queue:

• Consider the grocery store with one
checkout counter. The system
consists of those customers in the
waiting line plus the one (if any)
checking out. A stopping time of 60
minutes is set for this example.

32
Manual Simulation Using Event Scheduling
Example: Model Components – 1
• The model has the following components:
System state
1. 𝐿𝐿𝐿𝐿(𝑡𝑡) is the number of customers in the waiting line.
2. 𝐿𝐿𝐿𝐿(𝑡𝑡) is the number being served (0 or 1) at time 𝑡𝑡.
Entities: The server and customers are not explicitly modeled, except in
terms of the state variables.
Events:
1. Arrival (𝐴𝐴);
2. Departure (𝐷𝐷);
3. Stopping event (𝐸𝐸), scheduled to occur at time 60.

33
Manual Simulation Using Event Scheduling
Example: Model Components – 2
• Event notices:
1. (𝐴𝐴, 𝑡𝑡), representing an arrival event to occur at future time 𝑡𝑡,
2. (𝐷𝐷, 𝑡𝑡), representing a customer departure at future time 𝑡𝑡,
3. (𝐸𝐸, 60), representing the simulation stop event at future time 60.
• Activities:
1. Interarrival time.
2. Service time.
• Delay:
• Customer time spent in waiting line.

34
 Execution of the
departure event

Execution of the
arrival event

35
 Simulation table of
checkout counter
till CLOCK = 8

B Total server busy time

MQ maximum queue length

36
Event-Scheduling Algorithm
Implementation in Simulation Software
• Remarks:
• The software maintains just one set of system states and other
attribute values, that is, just one snapshot (the current one or partially
updated one).
• The following rule should be followed:
• a new snapshot can be derived only from: 1) the previous
snapshot, 2) newly generated random variables, and 3) the event
logic.
• past snapshots should be ignored for advancing of the clock.
• the current snapshot must contain all information necessary to
continue the simulation.

37
List Structures

• Lists are a set of ordered or ranked records. In simulation, each record

represents one entity or one event notice.
• Each list has:
• a top or head (the first item on the list),
• some way to traverse the list (to find the second, third, etc. items on
the list), and
• a bottom or tail (the last item on the list).
• A head pointer is a variable that points to or indicates the record at the
top of the list.
• Some implementations also have a tail pointer that points to the bottom
item on the list.

38
Records Types

• A record in a list is an entity, along with its attributes or an event notice.

• the fields of an entity record includes the entity identifier and its
attributes.
• the fields of an event-notice record includes the event type and time,
and any other event-related data.
• Each record on a list will also have a field that holds a “next pointer” that
points to the next record on the list.
• Some lists also require a “previous pointer,” to allow for traversing the list
from bottom to top.

39
Main Operations on Lists

1. Removing a 2. Adding a record Can be carried out in minimal

record from the top to the top or bottom time by adjusting two record
of the list; of the list; pointers and the head or tail
pointer.

4. Adding a record Require at least a partial

3. Removing a at an arbitrary search through the list. This
record from any position in the list, search must be done
location on the list; one specified by the efficiently.
ranking rule.

40
Storing Lists on a Computer
• Each is stored in a physical location in computer memory.
• There are two basic possibilities:
1. storing all records in arrays: arrays hold successive records in
contiguous locations in computer memory. They can be referenced
by an array index that can be thought of as a row number in a
matrix.
2. representing all records by structures (as in C) or classes (as in
Java), allocated from RAM memory as needed, and tracked by
pointers to a record or structure.

Using Arrays for List Processing & Using

Self-Study
Dynamic Allocation and Linked Lists

41
Simulation Software

42
Categories of Simulation Software

Simulation
Software

General purpose Special purpose Simulation

programming programming environments
languages, (e.g., languages (e.g., (e.g., AnyLogic,
C, C++, Java) GPSS/H) Arena)

43
Simulation using General Purpose Programming
Languages
• They do not provide any facility directly aimed at aiding the simulation
analyst.
• All details of the event-scheduling/time-advance algorithm, the statistics-
gathering capability, the generation of samples from specified probability
distributions, and the report generator MUST be developed.
• Some languages have runtime libraries that provide random-number
generators.
• Example 2 (Chapter 4) shows how to use Java for Single-Server Queue
Simulation.

44
 Overall structure of an event-
scheduling simulation program

45
Organization of Program (1/3)

• Simulation starts at time 𝑡𝑡 = 0 with the main program invoking the

initialization routine that initializes the simulation clock to zero.
• The system state, the statistical counters, and the event list are
initialized.
• The control returns to the main program. The main program then invokes
the timing routing to determine which type of even is most imminent.
• If an event is the next to occur, the simulation clock is advanced to the
time of occurrence of that event type and control is returned to the main
program.

46
Organization of Program (2/3)
• Then, the main program invokes event routine to ensure the following:
1. the system state is updated,
2. statistical counters are updated, and
3. the times of occurrence of future events are generated and added to
the event list.
• Generation of random observations from probability distribution is made
to determine these future event times using library routine.

• After all processing has been completed, a check is made to determine if

the simulation should now be terminated.

47
Organization of Program (3/3)

• If yes, the report generator is invoked form the main program to compute
estimates of the desired measures of performance and to produce a
report.

• If not, control is passed back to the main program and the main program,
timing routine, main program, event routing, termination check cycle is
repeated until the stopping condition is eventually satisfied.

48
 Questions?

49