System Simulation

General Principles

Section – I
Chapter 3

Course Notes are based on and accompany the Course Book:

Banks et al, “DESS 5th Ed.”, 2010.
 Chapter 3 Outline
1. Architecture of a Discr.-Evt.Simulation System
2. Concepts in Discrete-Event Simulation
- The Event Scheduling/Time Advance Algorithm
- World Views (event scheduling, process interaction,
and activity scanning).
- Manual Simulation Using Event Scheduling
3. List Processing
- Basic Properties and Operations Performed on Lists
- Dynamic Allocation and Linked Lists
An Architecture for DES System
User Interface

Event Queue Action Stochastic

Processor Processor Processor Processor

Experimentation Manager

Module Module Module

Module Module
 Components of a DES System - 1
• User Interface: allows the Input and output
configuration and initial data entry. It also
allows the selection of stopping condition
• Event Processor: Manages the events in the
system through a FEL: Future Event List.
• Action Processor: determines the next action
to be taken through maturing events and
other logical conditions available and INVOKES
the correct unit or module within the
simulator.
 Components of a DES System - 2
• Queue Processor: Manages the queues within
the system. It en-queues and de-queues
customers (or units).
• Stochastic Processor: Generates all the
stochastic variates used within the simulation
system.
• Experimentation Manager: Controls the
initialization of variables necessary for each
run of the simulation and runs the experiment
based on run-length and replication counts.
e.g. 100,000 packet or customer COMPLETIONs. For Replicating the statistical experiment
Concepts in Discrete-Event Simulation -1
• This chapter introduces and explains the fundamental
concepts and methodologies underlying all discrete-
event simulation packages (simulation languages and
software) using a package independent approach.
• Basic building blocks of all discrete-event simulation
models are covered:
– entities - attributes
– activities - events
• In discrete-event simulation, a system is modelled in
terms of its state at each point in time;
 Concepts in DES -2
• Important issues are: the entities that pass
through the system, the entities that
represent system resources, and the activities
and events that cause the system state to
change.
• Discrete-event models are appropriate for
those systems for which changes in system
state occur only at discrete points in time.
Concepts in Discrete-Event Simulation -3
• This chapter deals exclusively with dynamic,
stochastic systems (i.e., involving time and
containing random elements) that change in a
discrete manner.
• This section expands on these concepts and
proposes a framework for the development of
a discrete-event model of a system.
• The major concepts are briefly defined and
then illustrated by examples:
 Concepts in DES -4
• System: A collection of entities (e.g., people and machines)
that interact together over time to accomplish one or more
goals.
• Model: An abstract representation of a system, usually
containing structural, logical, or mathematical relationships
that describe a system in terms of state, entities and their
attributes, sets, processes, events, activities, and delays.
• System state: A collection of variables that contain all the
information necessary to describe the system at any time.
• Entity: Any object or component in the system that requires
explicit representation in the model (e.g., a server, a
customer, a machine).
Concepts in Discrete-Event Simulation -5
• Attributes: The properties of a given entity (e.g., the priority
of a waiting customer, the routing of a job through a job
shop).
• List: A collection of (permanently or temporarily) associated
entities, ordered in some logical fashion (such as all customers
currently in a waiting line, ordered by "first come, first
served," or by priority).
• Event: An instantaneous occurrence that changes the state of
a system (such as an arrival of a new customer).
• Event notice: A record of an event to occur at the current or
some future time, along with any associated data necessary to
execute the event; at a minimum, the record includes the
event type and the event time.
 Concepts in DES -6
• Event list: A list of event notices for future events, ordered by
time of occurrence; also known as the future event list (FEL).
• Activity: A duration of time of specified length (e.g., a service
time or interarrival time), which is known when it begins
(although it may be defined in terms of a statistical
distribution).
• Delay: A duration of time of unspecified indefinite length,
which is not known until it ends (e.g., a customer's delay in a
last-in-first-out waiting line which, when it begins, depends on
future arrivals).
• Clock: A variable representing simulated time, called CLOCK in
the examples to follow.
Refer to QSIM --> 09.11.21
 Concepts in DES -7
• Different simulation packages use different
terminology for the same or similar concepts – e.g.,
lists are sometimes called sets, queues, or chains.
Sets or lists are used to hold both entities and event
notices.
• The entities on a list are always ordered by some
rule, such as first-in-first-out or last-in-first-out, 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.
 Concepts in DES -8
• An activity typically represents a service time, an
interarrival time, or any other processing time whose
duration has been characterized and defined by the
modeller. An activity's duration may be specified in a
number of ways:
a. Deterministic-for example, always exactly 5 minutes;
b. Statistical-for example, as a random draw from the set {2,
5, 7} with equal probabilities;
c. A function depending on system variables and/or entity
attributes-for example, 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.
 Concepts in DES -9
• The duration of an activity is computable from its specification
at the instant it begins.
• Its duration is not affected by the occurrence of other events
(unless, as is allowed by some simulation packages, the model
contains logic to cancel or postpone an activity in progress).
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. For example, if the current
simulated time is CLOCK = 100 minutes and an inspection time
of exactly 5 minutes 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 minutes).
 Concepts in DES -10
• A delay's duration is not specified by the modeller ahead of
time, but rather is determined by system conditions. Quite
often, a delay's duration is measured and is one of the
desired outputs of a model run.
• Typically, a delay ends when some set of logical conditions
becomes true or one or more other events occur. For
example, 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.
 Concepts in DES -11
• A delay is sometimes called a conditional wait, an activity an
unconditional wait. The completion of an activity is an event,
often called a primary event, that is managed by placing an
event notice on the FEL.
• In contrast, delays are managed by placing the associated
entity on another list, perhaps representing a waiting line,
until such time as system conditions permit the processing of
the entity. The completion of a delay is sometimes called a
conditional or secondary event, but such events are not
represented by event notices, nor do they appear on the PEL.
The systems considered here are dynamic, that is, changing
over time.
 Concepts in DES -12
• Therefore, system state, entity attributes and the number of
active entities, the contents of sets, and the activities and
delays currently in progress are all functions of time and are
constantly changing over time. Time itself is represented by a
variable called CLOCK.
 Concepts in DES -13
• Example 3.1: Call Center, Revisited
Consider the Able-Baker call centre system of Example 2.6. A
discrete-event model has the following components:
• System state
LQ(t), the number of callers waiting to be served at time t;
LA(t), 0 or 1 to indicate Able as being idle or busy at time t;
LB(t), 0 or 1 to indicate Baker as being idle or busy at time t.
• 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 (compare Examples 3.4 and 3.5).
 Concepts in DES -14
• Events:
Arrival event;
Service completion by Able;
Service completion by Baker.
• Activities:
Interarrival time, defined in Table 2.12;
Service time by Able, defined in Table 2.13;
Service time by Baker, defined in Table 2.14.
• Delay
A caller's wait in queue until Able or Baker becomes free.
 Concepts in DES -15
• The definition of the model components provides a static
description of the model. In addition, a description of the
dynamic relationships and interactions between the
components is also needed. Some questions that need
answers include:
• 1. How does each event affect system state, entity attributes,
and set contents?
• 2. How are activities defined (i.e.·, deterministic, probabilistic,
or some other mathematical equation)? What event marks
the beginning or end of each activity? Can the activity begin
regardless of system state, or is its beginning conditioned on
the system being in a certain state? (For example, a machining
"activity" cannot begin unless the machine is idle, not broken,
and not in maintenance.)
 Concepts in DES -16
• 3. Which events trigger the beginning (and end) of each type
of delay? Under what conditions does a delay begin or end?
• 4. What is the system state at time O? What events should be
generated at time 0 to "prime" the model-that is, to get the
simulation started?
• A discrete-event simulation is the modelling over time of a
system all of whose state changes occur at discrete points in
time-those points when an event occurs. A discrete-event
simulation (hereafter called a simulation) proceeds by
producing a sequence of system snapshots (or system images)
that represent the evolution of the system through time.
 Concepts in DES -17
• A given snapshot at a given time (CLOCK = t) includes not only
the system state at time t, but also a list (the FEL) of all
activities currently in progress and when each such activity
will end, the status of all entities and current membership of
all sets, plus the current values of cumulative statistics and
counters that will be used to calculate summary statistics at
the end of the simulation. A prototype system snapshot is
shown in Figure 3.1.
• Mechanism for advancing simulation time and guaranteeing
that all events occur in correct chronological order is based on
the future event list (FEL). This list contains all event notices
for events that have been scheduled to occur at a future time.
 The Event Scheduling/Time
Advance Algorithm

Fig. 3.1 Prototype system snapshot at simulation time t

 The Event Scheduling/Time
Advance Algorithm -2
• Scheduling a future event means that, at the
instant an activity begins, its duration is
computed or drawn as a sample from a
statistical distribution; and that the end-
activity event, together with its event time, is
placed on the future event list.
• At any given time t, the FEL contains all
previously scheduled future events and their
associated event times.
 The Event Scheduling/Time
Advance Algorithm -3
• The FEL is ordered by event time, meaning
that the events are arranged chronologically-
that is, the event times satisfy: 1) TIME - ORDERED LIST
2) FCFS for equal time events

t < t1 ≤ t2 ≤ t3 ≤ … ≤ tn.
• Time t is the value of CLOCK, the current value
of simulated time. The event associated with
time t1 is called the imminent event; that is, it
is the next event that will occur. t1 is tie when event-1 will occur
FEL
CLOCK t t1 Event-Type

t2
 The Event Scheduling/Time
Advance Algorithm -4
• The sequence of actions that a simulator (or
simulation language) must perform to advance the
clock and build a new system snapshot is called the
event-scheduling/time-advance algorithm, whose
steps are listed in Figure 3.2.
Assume EVENT with occurence time t* has arrived!. What to do?:
 Updating Simulation Time and System Image
EV-TYP Time

(1)

EXECUTE EV_TYPE=3

(2)

(FEL
)

TIME SHOULD NEVER go BACK in a SIMULATION system...!!!! Otherwise wrong coding or implementation must have occured...!!!
 Updating Simulation Time and System Image
0 + iat1 = iat1 = 3.7s t1 = t + iat1
Generated Randomly t2 = t1 + iat2
by the PGEN t = t (now) + iat
t3 = t2 + iat3
IATs
iat1 = 3.7s Bootstrapping!
iat2 = 0.4s
iat3 = 3.3s

Customer
 Ending Simulations
• Every simulation must have a stopping event. In
this example it can be called E, and it defines the
duration of the simulation. There are two ways to
stop a simulation:
1. At t=0, schedule a “stop simulation” event for a
specified future time TE.
2. Run length TE is determined by the simulation;
i.e. it is the time of occurrence of a specified
event. E.g. TE could be the time of the 10,000th
service completion.
16.11.2021
 World Views
• When using a simulation package (or when
doing a manual simulation), a modeller adopts
a world view or orientation for developing a
model. The most prevalent world views are:
• The event scheduling world view,
• The process-interaction world view, and
• The activity-scanning world view.
 World Views - 2
• Event-scheduling approach: the simulation analyst
concentrates on events and their effect on system
state.
• Process-interaction approach: the simulation analyst
thinks in terms of processes. The analyst defines the
simulation model in terms of entities or objects and
their life cycle as they flow through the system,
demanding resources and queuing to wait for
resources. More precisely, a process is the life cycle of
one entity.
 World Views - 3
• A process is a time-sequenced list of events,
activities, and delays, including demands for
resources, that define the life cycle of one entity as it
moves through a system (see Fig.3.4).
• Both the event-scheduling and the process-
interaction approach use a variable time advance
mechanism;
• I.e. when all events and system state changes have
occurred at one instant of simulated time, the
simulation clock is advanced to the time of the next
imminent event on the FEL.
 World Views Ts(2) = Service Time for Customer 2

Waiting time in
= Ts (c-2)
queue for C-2

t2

Server RETURNS
to pick up customer
n+1

= Ts (c-3)

t3

• E.g. Interaction among processes: customer n+1 is

delayed until customer n’s “end service event”
occurs.
 World Views - 4
• Activity-scanning approach: it uses a fixed time
increment and a rule-based approach to decide
whether any activities can begin at each point in
simulated time.
• In this approach, a modeller concentrates on the
activities of a model and those conditions, simple or
complex, 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.
Manual Simulation using Event Scheduling
• A simulation table is used to record the successive
system snapshots as time advances.
• Ex.3.3 Single Channel Queue: this is the grocery store
with one checkout counter. The model components
are:
LQ(t)
Manual Simulation using Event Scheduling

• Event notice format: (event type, event time).

• In this model, the FEL will always contain either two or
three event notices. The effect of the arrival and
departure events are shown in Figs. 3.5 and 3.6.
Manual Simulation using Event Scheduling
• Statistics to be collected:
– Server Utilization
– Maximum Queue Length (MQ)
• Server Utilization: it is defined as the total
Server Busy Time (B) divided by total time TE.
• “Comments” column added to help reader.
• a* and s* are the generated interarrival and
service times respectively.
 IDLE BUSY
SET SERVER BUSY ENQUE CUSTOMER and Increment
LQ by LQ = LQ +1
IS SERVER
BUSY

Schedule event to FEL

 NO WAITING
customers

Set SERVER DEQUE NEXT WAITING CUSTOMER

to IDLE
Manual Simulation using Event Scheduling
• Ex. 3.3 Event Scheduling (cont.)
• Assume that the interarrival times and service times
are as follows:

• Initial conditions: the first customer arrives at time 0

and begins service.
• Shown in Table 3.1 by the system snapshot at time
zero (CLOCK = 0), with LQ(0) = 0, LS(0) = 1, and both a
departure event and arrival event on the PEL.
 The Checkout-Counter Simulation (Continued)
• Ex. 3.4 the Checkout-Counter Simulation:
• Suppose that in Example 3.3, the simulation
analyst desires to estimate:
– Mean response time (RT), and
– Mean proportion of customers who spend 5 or
more minutes in the system.
NB: A response time is the length of time a
customer spends in the system (Sojourn Time).
• To estimate the above expand the model to
represent the individual customers explicitly.
 The Checkout-Counter Simulation (Continued)
• In order to compute an individual customer's RT
when that customer departs, it is necessary to know
that customer's arrival time.
• Therefore, a customer entity with arrival time as an
attribute needs to be added to the list of model
components in Example 3.3. These customer entities
will be stored in a list to be called "CHECKOUT LINE";
they will be called C1, C2, C3, ...
• The event notices on the FEL will be expanded to
indicate which customer is affected. E.g., (D,4,C1)
means that customer C1 will depart at time 4.
 The Checkout-Counter Simulation (Continued)

• Three new cumulative statistics will be collected:

– S: sum of customer response times for all customers who
have departed by the current time;
– F: total number of customers who spend 5 or more
minutes at the checkout counter; and
– ND: total number of departures up to the current
simulation time. Can be used to determine No. of Customer
Completions
 The Checkout-Counter Simulation (Continued)

• These three cumulative statistics will be updated

whenever the departure event occurs.
• The simulation table is shown in Table 3.2.
• The same data for interarrival and service times are
used again as in Ex.3.3. Hence, Table 3.2 repeats
Table 3.1, except that the new components are
included (and the comment column has been
deleted).
• The new components are for the computation of the
cumulative statistics S, F, and ND.
 The Checkout-Counter Simulation (Continued)
SUM of RT
SIM-end-time
N: Number in the system
SERVER +
SYSTEM QUEUE
State
t
 The Checkout-Counter Simulation (Continued)
• E.g., at t=4, C1 departs. Customer C1 is removed from list
"CHECKOUT LINE";
• Attribute "time of arrival" is noted to be 0, so the response
time for this customer was 4 minutes. Hence, S is incremented
by 4 minutes. ND is incremented by one customer, but F is not
incremented, since “time in system” was less than 5 mins.
• Similarly, at t=23, when the departure event (D, 23, C6) is
being-executed, the response time for customer C6 is given by:

∴ increment S by 5 mins.; F and ND by 1 customer.

 The Checkout-Counter Simulation (Continued)
• For a simulation run length of 23 minutes, the average
response time was S/ND = 35/6 = 5.83 minutes, and the
observed proportion of customers who spent 5 or more
minutes in the system was F/ND = 0.83.
• Again, this simulation was far too short to regard these
estimates as having any degree of accuracy.
• The purpose of Ex.3.4, however, was to illustrate the notion
that, in many simulation models, the information desired
from the simulation (such as the statistics S/ND and F/ND) to
some extent dictates the structure of the model.

Next pg is APPDX: APPENDIX is optional for those who want to review

the use of Linked Lists or Arrays for LIST processing for FEL etc..
30.11.2021
 APPENDIX
List Processing (c.f. Data Structures)

• List processing deals with methods for handling

lists of entities and the future event list.
• Handling lists is crucial for the operation of
simulation software.
• Simulation packages provide, facilities for an
analyst or the model itself to use lists and to
perform the basic operations on lists.
• In simulation, each record represents one
entity or one event notice.
Basic Properties and Operations - 2
• Lists: are a set of ordered or ranked records. They
have/need the following:
• Top or Head: (the first item on the list),
• Mechanism to traverse the list: (to find the
second, third, etc. items on the list), and
• 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 of lists also have a tail pointer
that points to the bottom item on the list.
Basic Properties and Operations - 3
• An entity, along with its attributes or an event notice,
will be referred to as a record. An entity identifier and
its attributes are fields in the entity record; the event
type, event time, and any other event-related data are
fields in the event-notice record.
• Each record on a list will also have a field that holds a
"next pointer" that points to the next record on the
list, providing a way to traverse the list.
• Some lists also require a "previous pointer," to allow
for traversing the list from bottom to top.
Basic Properties and Operations - 4
• The main operations on a list are the following:
a. removing a record from the top of the list;
b. removing a record from any location on the list;
c. adding a record to the top or bottom of list;
d. adding a record at an arbitrary position in the
list, one specified by the ranking rule.
• Operations (a) and (c), can be carried out in
minimal time by adjusting two record pointers
and the head or tail pointer;
Basic Properties and Operations - 5
• The other two operations require at least a
partial search through the list. Making these
two operations efficient is the goal of list-
processing techniques.
• In the event-scheduling approach, when time
is advanced and the imminent event is due to
be executed, the removal operation takes place
first; i.e. the event at the top of the FEL is
removed from the FEL.
Basic Properties and Operations - 6
• If an arbitrary event is being cancelled, or an
entity is removed from a list based on some of
its attributes (say, for example, its priority and
due date) to begin an activity, then the second
removal operation is performed.
• When an entity joins the back of a FIFO queue
implemented as a list, then the third operation,
adding an entity to the bottom of a list, is
performed.
Basic Properties and Operations - 7
• Finally, if a queue has the ranking rule “earliest
due date first”, then, upon arrival at the
queue, an entity must be added to the list not
at the top or bottom but at the position
determined by the due-date ranking rule.
• In computer simulation, each entity record and
event notice is stored in a physical location in
computer memory.
Time ORDERED List
Basic Properties and Operations - 8
• There are two basic possibilities:
(a) All records are stored in arrays. They therefore can
be referenced by an array index that can be
thought of as a row number in a matrix.
(b) All entities and event notices are represented 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.
• Most simulation packages use dynamically
allocated records and pointers to keep track of
lists of items.