Advanced Modelling in Operations

Management (EBAMO5A)
Simulation Modelling and Analysis
CHAPTER ONE: Basic Simulation Modelling
Presented by www.vut.ac.za
Asser Letsatsi Tau (Pr Eng Tech, MSAIChE, SACAA, PhD (Operations) , Master RD (Operations), MEng (Chemical), PDBA, SCT 41 (Civil Eng)
1
 THE NATURE OF SIMULATION

• Techniques can be used through computers to imitate, or simulate, the operations of various kinds of real-world
facilities or processes.
• The facility or process of interest is usually called a system, and in order to study it scientifically we often have to
make a set of assumptions about how it works.
• These assumptions, which usually take the form of mathematical or logical relationships, constitute a model that
is used to try to gain some understanding of how the corresponding system behaves.
• If the relationships that compose the model are simple enough, it may be possible to use mathematical methods
(such as algebra, calculus, or probability theory) to obtain exact information on questions of interest; this is
called an analytic solution.
• However, most real-world systems are too complex to allow realistic models to be evaluated analytically, and
these models must be studied by means of simulation.
• In a simulation we use a computer to evaluate a model numerically, and data are gathered in order to estimate the
desired true characteristics of the model.

2
• As an example of the use of simulation, consider a manufacturing company that is contemplating building a large
extension on to one of its plants but is not sure if the potential gain in productivity would justify the construction
cost. It certainly would not be cost-effective to build the extension and then remove it later if it does not work out.
• However, a careful simulation study could shed some light on the question by simulating the operation of the plant
as it currently exists and as it would be if the plant were expanded.
• Application areas for simulation are numerous and diverse. Below is a list of some particular kinds of problems for
which simulation has been found to be a useful and powerful tool:
a) Designing and analysing manufacturing systems
b) Evaluating military weapons systems or their logistics requirements
c) Determining hardware requirements or protocols for communications networks
d) Designing and operating transportation systems such as airports, freeways, ports, and subways
e) Evaluatingdesignsforserviceorganizationssuchascallcenters,fast-food restaurants, hospitals, and post offices
f) Reengineering of business processes
g) Analysing supply chains
h) Determining ordering policies for an inventory system
i) Analysing mining operations

3
• Simulation is one of the most widely used operations-research and management- science techniques.
• Winter Simulation Conference, which attracts 600 to 800 people every year is one of the testament.
• Other operations research conferences includes International Conference on Industrial Engineering and Operations
Management (IEOM), Southern African Institute for Industrial Engineering (SAIIE) Annual Conference,
International Conference on Industrial Engineering and Engineering Management (IEEM), International
Conference on Information Management and Industrial Engineering (ICII), International Conference on Design
and Manufacturing Engineering (ICDM), International Conference on Logistics Operations Management etc.
which can attract > 100 participants per year taking place in different countries.
• Journal publications also reports operations research whereby simulation studies are being conducted.
• The other two “operations-research techniques” are “math programming” (a catch-all term that includes many
individual techniques such as linear programming, nonlinear programming, etc.) and “statistics” (which is not an
operations-research technique per se).
• Gupta (1997) analysed 1294 papers from the journal Interfaces (one of the leading journals dealing with
applications of operations research) from 1970 through 1992, and found that simulation was second only to “math
programming” among 13 techniques considered.
• However, several impediments to even wider acceptance and usefulness of simulation exist. For example:
a) Models used to study large-scale systems tend to be very complex, and writing computer programs to execute
them can be an laborious task indeed.
4
b) Simulation of complex systems sometimes requires large amount of computer time.
c) There appears to be an unfortunate impression that simulation is just an exercise in computer programming, though
a complicated one.
• Consequently, many simulation “studies” have been composed of heuristic model building, programming, and a
single run of the program to obtain “the answer” .
• This perspective on modelling can potentially neglect the important issue of how a properly coded model can be
used to make inferences about the system of interest, thus it has doubtlessly led to erroneous conclusions being
drawn from many simulation studies (validity and reliability?????? #wondering??).
• These are questions of simulation methodology, which are largely independent of the software and hardware used
(to be discussed latter).

5
 SYSTEMS, MODELS, AND SIMULATION
• A system is defined to be a collection of entities, e.g., people or machines, that act and interact together toward
the accomplishment of some logical end. [This definition was proposed by Schmidt and Taylor (1970).]
• For example, if one wants to study a bank to determine the number of tellers needed to provide adequate service
for customers who want just to cash a check or make a savings deposit, the system can be defined to be that
portion of the bank consisting of the tellers and the customers waiting in line or being served.
• The state of a system to be that collection of variables necessary to describe a system at a particular time, relative
to the objectives of a study.
• For example, in the study of a bank, examples of possible state variables are the number of busy tellers, the
number of customers in the bank, and the time of arrival of each customer in the bank.
• Systems can be of two types, viz: discrete and continuous.
a) A Discrete system is one for which the state variables change instantaneously at separated points in time.
A bank is an example of a discrete system, since state variables— e.g., the number of customers in the bank—change only when a
customer arrives or when a customer finishes being served and departs
b) A continuous system is one for which the state variables change continuously with respect to time.
An airplane moving through the air is an example of a continuous system, since state variables such as position and velocity can change
continuously with respect to time.

6
• Few systems in practice are wholly discrete or wholly continuous; but since one type of change predominates for
most systems, it will usually be possible to classify a system as being either discrete or continuous.
• At some point in the lives of most systems, there is a need to study them to try to gain some insight into the
relationships among various components, or to predict performance under some new conditions being considered
(think scenario planning????)

• Figure 1 bellow maps out different ways in which a system might be studied.

Figure 1: Ways to study a system.

7
• Experiment with the Actual System vs. Experiment with a Model of the System
o If it is possible (and cost-effective) to alter the system physically and then let it operate under the new conditions, it
is probably desirable to do so, for in this case there is no question about whether what we study is valid. However,
it is rarely feasible to do this, because such an experiment would often be too costly or too disruptive to the system.
o More graphically, the “system” might not even exist, but we nevertheless want to study it in its various proposed
alternative con- figurations to see how it should be built in the first place
o It is usually necessary to build a model as a representation of the system and study it as a substitute for the actual
system. When using a model, there is always the question of whether it accurately reflects the system for the
purposes of the decisions to be made; this question of model validity (to be discussed in later chapters).
• Physical Model vs. Mathematical Model
o Physical models are also called iconic models
o Occasionally, it has been found useful to build physical models to study engineering or management systems;
examples include tabletop scale models of material-handling systems, and in at least one case a full-scale physical
model of a fast-food restaurant inside a warehouse, complete with full-scale, real (and presumably hungry) humans
[see Swart and Donno (1981)].
But the vast majority of models built for such purposes are mathematical, representing a system in terms of logical and
quantitative relationships that are then manipulated and changed to see how the model reacts, and thus how the system
would react—if the mathematical model is a valid one.
8
• Analytical Solution vs. Simulation
o Once we have built a mathematical model, it must then be examined to see how it can be used to answer the
questions of interest about the system it is supposed to represent. If the model is simple enough, it may be possible
to work with its relationships and quantities to get an exact, analytical solution.
• However, many systems are highly complex, so that valid mathematical models of them are themselves complex,
precluding any possibility of an analytical solution. In this case, the model must be studied by means of simulation,
i.e., numerically exercising the model for the inputs in question to see how they affect the output measures of
performance.
• Given, then, that we have a mathematical model to be studied by means of simulation (henceforth referred to as a
simulation model), we must then look for particular tools to do this. It is useful for this purpose to classify
simulation models along three different dimensions:
a) Static vs. Dynamic Simulation Models
A static simulation model is a representation of a system at a particular time, or one that may be used to represent a
system in which time simply plays no role; examples of static simulations are certain Monte Carlo models (to be discussed in
later chapters).On the other hand, a dynamic simulation model represents a system as it evolves over time, such as a
conveyor system in a factory.

9
b) Deterministic vs. Stochastic Simulation Models
o If a simulation model does not contain any probabilistic (i.e., random) components, it is called deterministic; a
complicated (and analytically intractable) system of differential equations describing a chemical reaction might be
such a model. In deterministic models, the output is “determined” once the set of input quantities and relationships
in the model have been specified, even though it might take a lot of computer time to evaluate what it is.
o Many systems, however, must be modelled as having at least some random input components, and these give rise
to stochastic simulation models.
o Most queueing and inventory systems are modelled stochastically. Stochastic simulation models produce output
that is itself random, and must therefore be treated as only an estimate of the true characteristics of the model; this
is one of the main disadvantages of simulation (to be discussed later).

c) Continuous vs. Discrete Simulation Models

o The definition of discrete and continuous simulation models are stated equally as defined the way discrete and
continuous systems were explained previously.
o The decision whether to use a discrete or a continuous model for a particular system depends on the specific
objectives of the study.

10
 DISCRETE-EVENT SIMULATION
• Discrete-event simulation concerns the modeling of a system as it evolves over time by a representation in which
the state variables change instantaneously at separate points in time. (In more mathematical terms, we might say that the
system can change at only a countable number of points in time.)
• These points in time are the ones at which an event occurs, where an event is defined as an instantaneous occur-
rence that may change the state of the system. Although discrete-event simulation could conceptually be done by
hand calculations, the amount of data that must be stored and manipulated for most real-world systems dictates
that discrete-event simulations be done on a digital computer.
Events actually changed the state of the system, but in some discrete-event simulation models events are used for
purposes that do not actually effect such a change. For example, an event might be used to schedule the end of a
simulation run at a particular time (to be discussed later) or to schedule a decision about a system’s operation at a
particular time (to be discussed later) and might not actually result in a change in the state of the system. This is why
we originally said that an event may change the state of a system.
Time-Advance Mechanisms
a) Simulation clock
Because of the dynamic nature of discrete-event simulation models, we must keep track of the current value of
simulated time as the simulation proceeds, and we also need a mechanism to advance simulated time from one value
to another. We call the variable in a simulation model that gives the current value of simulated time the simulation
clock.
11
• The unit of time for the simulation clock is never stated explicitly when a model is written in a general-purpose
language such as C, and it is assumed to be in the same units as the input parameters. Also, there is generally no
relationship between simulated time and the time needed to run a simulation on the computer.
• Historically, two principal approaches have been suggested for advancing the simulation clock: next-event time
advance and fixed-increment time advance. Since the first approach is used by all major simulation software and
by most people programming their model in a general-purpose language, and since the second is a special case of
the first, the next-event time-advance approach for all discrete-event simulation models is used for our study.
• With the next-event time-advance approach, the simulation clock is initialized to zero and the times of occurrence
of future events are determined. The simulation clock is then advanced to the time of occurrence of the most
imminent (first) of these future events, at which point the state of the system is updated to account for the fact that
an event has occurred, and our knowledge of the times of occurrence of future events is also updated.
• Then the simulation clock is advanced to the time of the (new) most imminent event, the state of the system is
updated, and future event times are determined, etc. This process of advancing the simulation clock from one event
time to another is continued until eventually some prespecified stopping condition is satisfied. Since all state
changes occur only at event times for a discrete- event simulation model, periods of inactivity are skipped over by
jumping the clock from event time to event time.

12
Components and Organization of a Discrete-Event Simulation Model
• Although simulation has been applied to a great diversity of real-world systems, discrete-event simulation models
all share a number of common components and there is a logical organization for these components that promotes
the programming, debugging, and future changing of a simulation model’s computer program.
• In particular, the following components will be found in most discrete-event simulation models using the next-
event time-advance approach programmed in a general- purpose language:
a) System state: The collection of state variables necessary to describe the system at a particular time
b) Simulation clock: A variable giving the current value of simulated time
c) Event list: A list containing the next time when each type of event will occur
d) Statistical counters: Variables used for storing statistical information about system performance
e) Initialization routine: A subprogram to initialize the simulation model at time 0
f) Timing routine: A subprogram that determines the next event from the event list and then advances the
simulation clock to the time when that event is to occur
g) Event routine: A subprogram that updates the system state when a particular type of event occurs (there is one
event routine for each event type).
h) Library routines: A set of subprograms used to generate random observations from probability distributions that
were determined as part of the simulation model.
13
i) Report generator: A subprogram that computes estimates (from the statistical counters) of the desired measures of
performance and produces a report when the simulation ends
j) Main program: A subprogram that invokes the timing routine to determine the next event and then transfers
control to the corresponding event routine to update the system state appropriately. The main program may also
check for termination and invoke the report generator when the simulation is over.
• The logical relationships (flow of control) among these components are shown in Figure 2.

Fig. 2: Flow of control for the next-event time-advance approach.

14
• This indicates that a system is a well-defined collection of entities. Entities are characterized by data values called
attributes, and these attributes are part of the system state for a discrete-event simulation model.
• Furthermore, entities with some common property are often grouped together in lists (or files or sets). For each
entity there is a record in the list consisting of the entity’s attributes, and the order in which the records are placed
in the list depends on some specified rule.
• For example, in a system such as bank, a server has the attribute “server status” (busy or idle), and the customers
waiting in queue have the attribute “time of arrival.” (The number of customers in the queue might also be
considered an attribute of the server.).
• The organization and action of a discrete-event simulation program using the next-event time-advance mechanism
are fairly typical when programming such simulations in a general-purpose programming language. This is called
the event-scheduling approach to simulation modeling, since the times of future events are explicitly coded into
the model and are scheduled to occur in the simulated future.
There is an alternative approach to simulation modeling, called the process approach, that instead views the simulation
in terms of the individual entities involved, and the code written describes the “experience” of a “typical” entity as it
“flows” through the system; programming simulations modeled from the process point of view usually requires the use
of special-purpose simulation software.

15
 Simulation Of A Single-server Qu eu eing System
• Entails simulation of a single-server queueing system such as a one-
operator barbershop. Although this system seems very simple
compared with those usually of real interest, how it is simulated is
actually quite representative of the operation of simulations of great
complexity. A single-server queueing system is represented by
Figure 3.
• The interarrival times A1, A2, . . . are independent and identically
distributed (IID) random variables.
• (“Identically distributed” means that the interarrival times have the
same probability distribution.) A customer who arrives and finds the
server idle enters service immediately, and the service times S1, S2,
. . . of the successive customers are IID random variables that are
independent of the interarrival times.
• A customer who arrives and finds the server busy joins the end of a
single queue. Upon completing service for a customer, the server
chooses a customer from the queue (if any) in a first-in, first- out
(FIFO) manner.
• The simulation will begin in the “empty-and-idle” state; i.e., no
Figure 3: A single-server queueing system
customers are present and the server is idle. 16
Intuitive Explanation

17
 Program Organization and Logic

• By learning to simulate in a general-purpose

language, in which one must pay attention to
every detail, there will be a greater understanding
of how simulations actually operate, and thus less
chance of conceptual errors if a switch is later
made to high-level simulation software.

Figure 4: Flowchart for arrival routine, queueing model.

18
Figure 4: Flowchart for arrival routine, queueing model. 19
 Determining the Events and Variables
• An event as an instantaneous occurrence that may change the
system state.
Figure 5 show the event graph for the single-server queueing system,
where the heavy, smooth arrows indicate that an event at the end of the
arrow may be scheduled from the event at the beginning of the arrow in
a (possibly) nonzero amount of time, and the thin jagged arrow indicates Figure 5: Event graph, queueing model..
that the event at its end is scheduled initially. Thus, the arrival event
reschedules itself and may schedule a departure (in the case of an arrival
who fi nds the server idle), and the departure event may reschedule
itself (if a departure leaves behind someone else in queue)
• In Figure 6 The two thin smooth arrows each represent an event at
the beginning of an arrow potentially scheduling an event at the end
of the arrow without any intervening time, i.e., immediately; in thisFigure 6: Event graph, queueing model with
case the straight thin smooth arrow refers to a customer who arrives separate “enter-service” event.
to an empty system and whose “enter-service” event is thus scheduled
to occur immediately, and the curved thin smooth arrow represents a
customer departing with a queue left behind, and so the fi rst
customer in the queue would be scheduled to enter service
immediately.
20
PARALLEL/DISTRIBUTED SIMULATION AND THE HIGH LEVEL ARCHITECTURE
• A simulation clock and an event list interact to determine which event will be processed next, the simulation
clock is advanced to the time of this event, and the computer executes the event logic, which may include
updating state variables, updating the event list, and collecting statistics.
• This logic is executed in order of the events’ simulated time of occurrence; i.e., the simulation is sequential.
Furthermore, all work is done on a single computer.
• In recent years computer technology has enabled individual processors or computers to be linked together into
parallel or distributed computing environments. This allows the possibility of executing different parts of a single
simulation model on multiple processors operating at the same time, or in “parallel,” and thus reducing the
overall time to complete the simulation. Alternatively, two or more different simulation models operating on
separate computers might be tied together over a network to produce one overall simulation model, where the
individual models interact with each other over time. In this section we introduce these alternative approaches to
executing a simulation model.
Parallel Simulation
Parallel discrete-event simulation is concerned with the execution of a simulation model on a tightly coupled
computer system (e.g., a supercomputer or a shared-memory multiprocessor). By spreading the execution of a
simulation over several different processors, it is hoped that the model execution time can be reduced considerably
(up to a factor equal to the number of processors).

21
• For example, if one is simulating a communications network with thousands of nodes or a large military model,
then the execution time could be excessive and parallel simulation might be considered. Another possible use for
parallel simulation is in real-time decision making. For example, in an air-traffic control system, it might be of
interest to simulate several hours of air traffic to decide “now” how best to reroute traffic.
• To develop a parallel simulation, a model is decomposed into several logical processes (LPs) (or submodels). The
individual LPs (or groups of them) are assigned to different processors, each of which goes to work simulating its
piece of the model. The LPs communicate with each other by sending time-stamped messages or events to each
other. For example, a manufacturing system is typically modeled as an interconnected network of queueing
systems, each representing a different workstation. When a job leaves one workstation, an “arrival” event must be
sent to the next station on the job’s routing (unless the job is leaving the system).
• A crucial issue in parallel simulation is to ensure that events in the overall simulation model, regardless of their
LP, are processed in their proper time sequence. For example, if the arrival of a particular job to one station is
supposed to take place before the departure of another job from a different station, then there must be a
synchronization mechanism to make sure that this takes place. If each LP processes all its events (generated
either by itself or by another LP) in increasing order of event time, a requirement called the local causality
constraint, then it can be shown that the parallel simulation will produce exactly the same results as if the overall
simulation model were run sequentially on a single computer.

22
• Historically, two different types of synchronization mechanisms have been used: conservative and optimistic. In
conservative synchronization , the goal is to absolutely avoid violating the local causality constraint. For
example, suppose that a particular LP is currently at simulation time 25 and is ready to process its next event that
has an event time of 30. Then the synchronization mechanism must make sure that this LP won’t later receive an
event from another LP with an event time of less than 30. Thus, the goal is to determine when it is actually “safe”
to process a particular event, i.e., when can it be guaranteed that no event will later be received by this LP with a
smaller event time.
• In optimistic synchronization, violations of the local causality constraint are allowed to occur, but the
synchronization mechanism detects violations and recovers from them. As above, each LP simulates its own
piece of the model forward in time, but does not wait to receive messages from other processors that may be
moving along at different rates—this waiting is necessary for conservative synchronization.

23
STEPS IN A SOUND SIMULATION STUDY

24
ADVANTAGES AND DISADVANTAGES OF SIMULATION
Some possible advantages of simulation that may account for its widespread appeal are the following:
o Most complex, real-world systems with stochastic elements cannot be accurately described by a mathematical
model that can be evaluated analytically. Thus, a simulation is often the only type of investigation possible.
o Simulation allows one to estimate the performance of an existing system under some projected set of operating
conditions.
o Alternative proposed system designs (or alternative operating policies for a single system) can be compared via
simulation to see which best meets a specified requirement.
o In a simulation we can maintain much better control over experimental conditions than would generally be
possible when experimenting with the system itself.
o Simulation allows us to study a system with a long time frame—e.g., an economic system—in compressed time,
or alternatively to study the detailed workings of a system in expanded time.

25
Some possible disadvantages of simulation that are the following:
o Each run of a stochastic simulation model produces only estimates of a model’s true characteristics for a
particular set of input parameters.
o Simulation models are often expensive and time-consuming to develop.
o The large volume of numbers produced by a simulation study or the persuasive impact of a realistic animation
often creates a tendency to place greater confidence in a study’s results than is justified. If a model is not a
“valid” representation of a system under study, the simulation results, no matter how impressive they appear, will
provide little useful information about the actual system.

26
 …END…

[email protected]

27