The role of simulation as a research and analysis tool is widely recognized, and many simulation

programming languages have been developed to facilitate the translation of simulation models
into executable simulation programs.
These languages may be broadly classified according to the underlying modeling approach as
continuous or discrete. The discrete languages may be further classified as event scheduling (eg.
SIMSCRIPT, GASP), activity scanning (eg. ECSL), and process oriented modeling (eg. GPSS,
SIMULA).
There are three different approaches to discrete event simulation which are event-oriented
simulation, activity-oriented simulation and process-oriented simulation. (Herb Schwetman,
1986)
The choice of which approach to use is usually limited to the choice of languages and packages
available on a specific system. This is unfortunate, as there are situations in which the nature of
the model to be developed might make one approach preferable to the other. The choice is in
some sense a matter of taste, as any model developed using one approach could have been
implemented using the other. However, some models are more straightforward when
implemented using a particular approach.
Herb Schwetman. 1986. CSIM: A C-based, process oriented simulation language, Proceedings of
The 1986 Winter Simulation Conference.
Three widely recognized world views for simulation are: event-oriented view, process-oriented
view and activity-scanning view. The rst two views are the more widely used among the three
views. All the three views are equivalent in the sense that process-oriented and activity-scanning
views can be translated into semantically equivalent event-oriented views. (Kalyan S. Perumalla
& Richard M. Fujimoto, 1998)
Kalyan S. Perumalla & Richard M. Fujimoto, 1998. Efficient large-scale process-oriented
parallel simulations, Proceedings of the 1998 Winter Simulation Conference.
EVENT SCHEDULING

Event scheduling is one of the three classical world views. and also one of the most prevalent
modeling perspectives taken by computer simulation languages for discrete event simulations.
One key advantage to this world view is its speed in executing models of congested systems
(Schruben and Roeder 2003). Event scheduling provides locality of time where each event
routine in a model specification describes related actions that should always all occur in one
instant. (C. Michael Overstreet & Richard E. Nance 2004) In addition, Simulation Event Graphs
(SEGs), a type of event scheduling simulation, are able to compactly represent large models, and
can be analyzed using optimization and graph theory.
When using the event scheduling world view, the modeler concentrates on events and their effect
of events on system state. It also has variable time advance. System state is a collection of
variables that contain all the information necessary to describe the system at any point in time.
To model a system, the modeler must identify all events, when they can occur, and how system
state is affected. The simulation proceeds by arranging all events in chronological order and
proceeding from snapshot to snapshot. In this manner, an artificial history or simulation of the
system is developed.
In the event-oriented approach, the simulation programmer defines events and then writes
routines which are invoked as each kind of event occurs. Simulated time may pass between the
events.
Event-oriented simulation is probably the more prevalent approach in current use, for two
reasons: event-oriented simulation models can be implemented in standard high-level
programming languages (eg. Fortran, Pascal and C) and a number of packages and languages
which aid the development of these kinds of models are widely available.
On the other hand, it is generally perceived that event-oriented views can be more efciently
implemented than the other two views, especially in the context of optimistic parallel
simulations.
In simulation languages which take the event scheduling world view, algorithms and utilities are
provided to manage the occurrence of events. Those events which at any given simulated time
will occur at some known, definite future simulated time, are listed on the so-called future event

list (FEL). Each event on the FEL has an associated event time. The event on the FEL with the
smallest event time is called the imminent event which is it is the next event to occur.
For example, consider a single molding machine. We assume that raw material is always
available, and that molding time for one part is exactly 1 minute. When one part finishes being
molde, the next one begins molding immediately, provided the machine is running. The machine
is subject to random failures. The time until failure is 5 minutes with probability 0.6, or 7
minutes with probability 0.4. Repair time is always 2 minutes. We wish to simulate for 20
minutes of operation.
System state : The status of the molding machine
Entity

: Machine at speed 1 part/minute

Events

: Failure of the machine

Repair of the machine
Stop the simulation (at time 20)

Activities

: Time to failure (random)

Time to repair (constant)

Delays

: (None)

So, under this world view, an event is the major focus of modeling a system. The modeler
follows the steps described below: (Osman Balci, 1988)
1)
2)
3)
4)
5)

Identify the objects and their attributes.

Identify the attributes of the system.
Define what causes a change in the value of an attribute as an event.
Write a subroutine to execute each event.
Follow the logic of the flow chart in Figure 3 and use the event list as structured in Figure
4 to develop the simulation program.

J. Wilson, J. Henriksen & S. Roberts (1986), Introduction to discrete-event simulation,

Proceedings of the 1986 Winter Simulation Conference.

Schruben, L. W., and T. M. Roeder.2003. Fast Simulations of Large-Scale Highly Congested

Systems. Simulation: Transactions of the Society for Modeling and Simulation International.
C. Michael Overstreet & Richard E. Nance (2004), Characterizations and relationships of world
views, Proceedings of the 2004 Winter Simulation Conference.
Osman Balci (1988), The implementation of four conceptual frameworks for simulation
modeling in high level languages, Proceedings of The 1988 Winter Simulation Conference.

ACTIVITY SCANNING
In the activity-oriented approach, the programmer defines activities which are started when
certain conditions are satisfied. In many cases, this type of simulation uses a simulated clock
which advances in constant increments of time. With each advance, a list of activities is scanned,
and those which have become eligible are started. This type of model is used more often with
simulating physical devices.

PROCESS ORIENTED MODELING

In the process-oriented approach, the programmer defines the processes (entities, transactions,
etc) which use the resources of the system. Each process can be in one of three states: active
(currently being processed by the simulator), holding (waiting for an interval of simulated time
to pass) or waiting (in a queue) for an event to occur. Simulated time passes only when processes
are in the hold state.
Process-oriented simulation models are usually implemented in special simulation languages
which support this approach. Some notable examples are GPSS, Simula, SLAM and ASPOL. Of
these ASPOL and Simula are general purpose programming languages (enhanced with the
addition of some simulation features), while SLAM and GPSS are special purpose languages,
tailored to implementing simulation models.

An advantage of using the process-oriented view is that models tend to be smaller, and easier to
develop and understand, making it more appealing to the modelers.
To summarize, process-oriented simulation allows simulation programmers to model systems by
defining interacting processes as abstractions of the active entities in the system. Each process
must be able to execute in parallel with other active processes; each process requires a private
data area; and active processes must be able to interact (communicate and synchronize) with
other active processes.
RANDOMNESS IN SIMULATION
Many simulations include randomness, which can arise in a variety of ways. For example, model
of a manufacturing system. Let say jobs arrive at the system at random times according to some
stochastic process. After arriving, jobs require processing sequentially on two machines, labeled
1 and 2. Immediately after completing processing on Machine 1, a job goes to Machine 2, and a
job leaves the system after the processing at Machine 2. The processing times on Machine 1
(resp., Machine 2) are independent random variables with distribution G1 (resp., G2). A jobs
processing times on the two machines are independent. If a job arrives at a machine that is
currently busy, the job enters a rst-in-rst-out (FIFO) queue with unlimited capacity. The
processing times required at each machine follows a given probability distribution and the arrival
times of new jobs are stochastic. (Marvin K. Nakayama, 2008)
Another example of randomness in simulation is a simulation of an automatic teller machine
(ATM) at a bank, customers arrive at random times and the amount of time each customer
occupies the ATM is stochastic. In addition, future returns of risky assets (e.g., stocks) in
nancial simulations are often modeled as random variables. Because of the randomness in the
components driving a simulation, its output is also random.
The randomness of simulation output requires that it be analyzed using statistical techniques. The
data-analysis methods taught in introductory statistics courses typically assume that the data are
independent and identically distributed (i.i.d.) with a normal distribution, but the output data
from simulations are often not i.i.d. normal.

Marvin K. Nakayama, 2008. Statistical analysis of simulation output. Proceedings of the 2008
Winter Simulation Conference

COMPARING ALTERNATIVES
A fundamental use for system simulation is to predict system performance in new situations or
with new system designs. It is also to compare a number of different approaches to achieve a
stated objective. In other words, the analyst uses simulation to aid in answering what if
questions and to aid in evaluating multiple system designs and/or operation procedures. Thus,
simulation is used to compare alternatives.
For example, an industrial engineer may use a simulation of a manufacturing shop to estimate the
effect on lead time and on shop throughput realized by reducing the setup time for a particular
operation. We define lead time as the time to produce an assembly and shop throughput as the
mean number of assemblies produced per shift. The emphasis is on comparing the simulation
output obtained from two or more sets of inputs. Another way of stating the output analysis
problem is that the analyst wants to answer what if questions. We are assuming that the analyst
will rarely use a simulation to estimate performance for a single set of inputs. We will call each
set of inputs defined for comparison purposes an alternative. (Gordon M. Clark, 1988)
There is also other previous work that studies comparing alternatives via simulation under
different frameworks than what we consider here. For example, there are Bayesian methods that
determine the allocation of samples to the alternatives to maximize the posterior probability of
correctly selecting the true best alternative; e.g., see Chick (2006) for an overview. Also, Glynn
and Juneja (2004) adopt a large-deviations perspective for comparing alternatives.

Gordon M. Clark, 1988. Tutorial: Analysis of simulation output to compare alternatives.

Proceedings of The 1988 Winter Simulation Conference.

1) The Role of Discrete Event Simulation Techniques in Finite Capacity Scheduling

Author(s): R. Roy and S. E. Meikle
Reviewed work(s):
Source: The Journal of the Operational Research Society, Vol. 46, No. 11 (Nov., 1995), pp.
1310-1321