Discrete-event

Simulation
IE 411 ELECTIVE 2
2.1 Discrete-event Simulation
Discrete-event simulation is the modeling
of systems in which the state variable
changes only at a discrete set of point in
time. The simulation models are analyzed
by numerical rather than analytical
methods.
2.1 Discrete-event Simulation
Analytical methods employ the deductive
reasoning of mathematics to “solve” the
model.

Numerical methods employ computational

procedures to “solve” mathematical
models.
2.1 Discrete-event Simulation
In case of simulation models, which employ computational procedures
to “solve” mathematical methods, models are “run” rather than
solved-that is, an artificial history of the system is generated from the
model assumptions, and observations are collected to be analyzed and
to estimate the true system performance measures.

Real-world simulation models are rather large, and the amount of data
stored and manipulated is vast, so such runs are usually conducted
with aid of a computer
2.1 Discrete-event Simulation
The concept of a system and a model of a system discussed in the previous chapter.
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 concept are briefly defined and then
illustrated by examples:

System: A collection of entities (e.g., people and machine) that interact together over
time to accomplish one or more goals.
Model: An abstract representation of a system, usually containing structural, logical ,
or mathematical relationship that describes a system in terms of state, entities and
their attributes, sets, processes, events, activities and delays.
System rate: 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).
2.1 Discrete-event Simulation
Attributes: The properties of a given entity (e.g., the priority of a waiting customer,
the routing of a job through job shop).
List: A collection of (permanently or temporarily) associated entities, ordered in some
logical fashion. (such as calling customers currently in a waiting line)
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.
Event list: A list of event notices for future events, ordered by time of occurrence;
also known as future event list (FEL)
Activity: A duration of time specified length (e.g., a service time or interarrival time),
which is known when it begins
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 example to follow.
2.1 Discrete-event Simulation
Different simulation packages use different terminology for the same or similar
concepts – for example, lists are sometimes called sets, queues, or chains. Sets or
lists are used to hold both entities and event notices.

A discrete-event simulation is the modeling over time of a system all of whose state
changes occur at discrete point in time – those points when an event occurs. A
discrete event simulation proceeds by producing a sequence of system snapshots
that represent the evolution of the system through time.
2.2 The event scheduling/Time advance
algorithm
The mechanism for advancing simulation time and guaranteeing that all event 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. Scheduling a future event mean 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.
In the real world, most future events are not scheduled but merely happen- such as
random breakdowns or random arrivals. In the model, such random events are
represented by the end of some activity, which in turn is represented by a statistical
distribution.

At any given time t, the FEL contains all previously scheduled future events and their
associated event times (called t1, t2 … ). The FEL is ordered by event time,
meaning that the events are arranged chronologically-that is event times satisfy.
3.1 Random-number generation
Random numbers are a necessary basic ingredient in the simulation of almost all
discrete systems. Most computer languages have a subroutine, object, or function
that will generate a random number.

Random numbers are used to generate event times and other random variables in
simulation languages. In this chapter, the generation of random numbers and their
subsequent testing for randomness is described.
3.2 Properties of Random Number
A sequence of random number R1, R2 …., must have two important statistical
properties: uniformity and independence.

Each random number Ri must be an independent sample drawn from a continuous

uniform distribution between zero and 1.
3.2 Properties of Random Number
Some sequence of the uniformity and independence properties are the following:

1. If the interval [0, 1] is divided into n classes, or subinterval is N/n, where N is the
total number of observations.

2. The probability of observing a value in a particular interval is independent of the

previous values drawn.

In the next section we describe desirable properties of methods that produce

random numbers to drive simulations.
3.2 Generation of Pseudo-Random Numbers
Notice that the title of this section has the word “pseudo” in it. “Pseudo” means false,
so false random numbers are being generated! In this instance, “pseudo” is used to
imply that the very act of generating random numbers by a known method removes
the potential for true randomness. If the method is known, the set of random
numbers can be repeated. Then an argument can be made that the numbers are not
truly random. The goal of any generation scheme, however is to produce a
sequence of numbers between 0 and 1 that simulates or imitates, the ideal
properties of uniform distribution and independence as closely as possible.

To be sure, in the generation of pseudo-random numbers, certain problems or errors

can occur. These errors, or departures from ideal randomness, all related to the
properties stated previously.
3.2 Generation of Pseudo-Random Numbers
Some example of such departures include the following:

1. The generated numbers might not be uniformly distributed.

2. The generated numbers might be discrete-valued instead of continuous-valued.
3. The mean of generated numbers might be too high or too low.
4. The variance of the generated numbers might be too high or too low.
5. There might be dependence as measured, for instance, by autocorrelation.

Departures from uniformity and independence for a particular generation scheme

often can be detected by tests. If departures are detected, the generation scheme
should be dropped in favor of an acceptable generator.
3.2 Generation of Pseudo-Random Numbers
Usually random numbers are generated by a digital computer as part of the
simulation. There are numerous methods that can be used to generate the values.
Before we describe some of these methods, there are several important
considerations that we should mention:

1. The method should be fast. Individual computations are inexpensive, but

simulation could require many millions of random numbers. The total cost can be
managed by selecting a computationally efficient method of random-number
generation.

2. The method should be portable to different computers-and, ideally, to different

programming languages. This is desirable so that simulation program will produce
the same results wherever it is executed.

3. The method should have a sufficiently long cycle. The cycle length, or period,
represents the length of the random number sequence before previous number
begin to repeat themselves in an earlier order. Thus, if 10,000 events are to be
generated, the period should be many times that long.
3.2 Generation of Pseudo-Random Numbers
4. The random numbers should be repeatable. Given the starting point (or
conditions) it should be possible to generate the same set of random numbers,
completely independent of the system that is being simulated. This is helpful for
debugging purposes and facilitates comparisons between systems.
For the same reasons, it should be possible to easily specify different starting points,
widely separated, within the sequence.

5. Most important, the generated random numbers should closely approximate the
ideal statistical properties of uniformity and independence.
3.2 Generation of Pseudo-Random Numbers
Inventing techniques that seem to generate random numbers is easy; inventing
techniques that really produce sequences that appear to be independent, uniformly
distributed random numbers is incredibly difficult. There is now a vast literature and
rich theory on the topic, and many hours of testing have been devoted to
establishing the properties of various generators.
Even when a technique is known to be theoretically sound, it is seldom easy to
implement it in a way that will be fast and portable. The goal of this chapter is to
make the reader aware of the central issues in random-number generation, to
enhance understanding, and to show some of the techniques that are used by those
working in this area.
3.2 Generation of Pseudo-Random Numbers
Example of a generated Pseudo-Random Number
3.3 Test for random numbers
The desirable properties of random numbers- uniformity and independence- were
discussed previously. To check on whether these desirable properties have been
achieved, a number of tests can be performed. (Fortunately, the appropriate tests
have already been conducted for most commercial simulation software). The tests
can be placed in two categories, according to the properties of interest: uniformity
and independence. A brief description of two types of tests is given in this section:

1. Frequency test. Use of Kolmogorov-Smirnov or the chi-square test to compare the

distribution of the set of numbers generated to a uniform distribution.
2. Autocorrelation test. Tests the correlation between numbers and compares the
sample correlation to the desired correlation, zero.
3.3.1 Frequency test
Frequency test
A basic test that should always be performed to validate a new generator is the test
of uniformity. Two different methods of testing are the Kolmogorov-Smirmov and the
chi-square test. Both test measures the degree of agreement between the
distribution of a sample of generated random numbers and the theoretical uniform
distribution. Both tests are based on the null hypothesis of no significant difference
between the sample distribution and the theoretical distribution.
3.3.2 Test for Autocorrelation
Test for Autocorrelation
The test for autocorrelation are concerned with the dependence between number in
a sequence. As an example, consider the following sequence of numbers, read from
left to right.
3.3.2 Test for Autocorrelation
Test for Autocorrelation

From a visual inspection, these numbers appear random, and they would probably
pass all the tests presented to this point.
However, an examination of the 5th , 10th , 15th, (Every five numbers beginning with
the fifth), and so on, indicates a very large number in that position.
Now, 30 numbers is rather a small sample size on which to reject a random number
generator, but the notion is that the numbers in the sequence might be related.

In this section, a method for discovering whether such a relationship exists is

described. The relationship would not have to be all high numbers. It is possible to
have all low numbers in the locations being examined, or the numbers could
alternate from very low to very high.
3.4 Mechanics of discrete simulation
As an example, let’s think about a logistics chain
involving a truck:

1. it arrives at a warehouse;
2. it enters a loading gate;
3. it unloads its supplies;
4. and then it leaves the warehouse.
In the example above, you will see that each step is
a separate — i.e., discrete — event. In order to
simulate this process, you will typically use a
discrete event simulation model.
END