Object oriented computer simulation of discrete event systems

Object-Oriented Computer
Simulation of Discrete-Event
Systems


THE KLUWER INTERNATIONAL SERIES
ON DISCRETE EVENT DYNAMIC SYSTEMS

Series Editor

Yu-Chi Ho
Harvard University
TIMED PETRI NETS: Theory and Application
Jiacun Wang
ISBN: 0-7923-8270-6

GRADIENT ESTIMATION VIA PERTURBATION ANALYSIS
P. Glasserman
ISBN: 0-7923-9095-4

PERTURBATION ANALYSIS OF DISCRETE EVENT DYNAMIC SYSTEMS
Yu-Chi Ho and Xi-Ren Cao
ISBN: 0-7923-9174-8

PETRI NET SYNTHESIS FOR
MANUFACTURING SYSTEMS

DISCRETE

EVENT

CONTROL

OF

MengChu Zhou and Frank DiCesare
ISBN: 0-7923-9289-2

MODELING AND CONTROL OF LOGICAL DISCRETE EVENT SYSTEMS
Ratnesh Kumar and Vijay K. Garg
ISBN: 0-7923-9538-7

UNIFORM RANDOM NUMBERS: THEORY AND PRACTICE
Shu Tezuka
ISBN: 0-7923-9572-7

OPTIMIZATION OF STOCHASTIC MODELS: THE INTERFACE BETWEEN
SIMULATION AND OPTIMIZATION
Georg Ch. Pflug
ISBN: 0-7923-9780-0

CONDITIONAL MONTE CARLO:
OPTIMIZATION APPLICATIONS

GRADIENT

ESTIMATION

AND

Michael FU and Jian-Qiang HU

ISBN: 0-7923-9873-4

SUPERVISORY CONTROL OF DISCRETE EVENT SYSTEMS USING PETRI
NETS
John O. Moody and Panos J. Antsaklis
ISBN: 0-7923-8199-8


Object-Oriented
Computer Simulation of
Discrete-Event Systems
Jerzy Tyszer
Poznan University of Technology, Poznan, Poland

SPRINGER SCIENCE+BUSINESS MEDIA, LLC


ISBN 978-1-4613-7287-5

ISBN 978-1-4615-5033-4 (eBook)

DOI 10.1007/978-1-4615-5033-4

Library of Congress Cataloging-in-Publication Data
A C.I.P. Catalogue record for this book is available
from the Library of Congress.
Copyright © 1999 by Springer Science+Business Media New York
Originally published by Kluwer Academic Publishers in 1999
Softcover reprint ofthe hardcover Ist edition 1999
All rights reserved. No part of this publication may be reproduced, stored in a

retrieval system or transmitted in any form or by any means, mechanical, photocopying, recording, or otherwise, without the prior written permission of the
publisher, Springer Science+Business Media, LLC.
Printed on acid-free paper.


To Dorota and Janusz


Contents

Preface
1

xi

Getting started

1

1.1 Basic notions
1.2 Manual simulation
1.3 Activity scanning.

2
5
9

2 Event scheduling
2.1 Main paradigm · ....
2.2 ABC approach · ....

2.3 Events versus activities

17

3 Event lists
3.1 Doubly linked linear list
3.2 Indexed linear list
3.3 Henriksen's list · ...
3.4 Two-level indexed list
3.5 Heaps .........
3.6 Splay trees ......
3.7 Run-time efficiency of event scheduling.

29

4

Process interaction
4.1 Basic operations
4.2 Environment in C++
4.3 Distributed simulation
4.3.1 Decomposition of a simulation
4.3.2 Conservative mechanisms ...

18
24
25
30
35
39

42
48
52
58
65

66
68
77
77

79


viii

Contents
4.3.3

5

Optimistic mechanisms

83
87
88

Random number generators
5.1 Uniform random variables
5.2 Statistical tests . . . . . . .

5.2.1 Chi-square test .. .
5.2.2 Kolmogorov-Smirnov test
5.2.3 Poker test . . . . . . . .
5.2.4 Runs test . . . . . . . .
5.2.5 Coupon's collector test.
5.2.6 Gap test . . . . . . . . .
5.2.7 Autocorrelation test ..
5.3 Non-uniform variate generation
5.3.1 Inverse transformation method
5.3.2 Convolution . . . .
5.3.3 Rejection method .
5.3.4 Further examples .

101
102
103
105
107
110
112

6

Design of simulation experiments
6.1 Validation of models
6.2 Analysis of variance
6.3 Linear regression . .

115
116

128
134

7

Collection and analysis of simulation results
7.1 Gathering of results . . . . . .
7.2 Transient phase characteristics
7.2.1 Estimation of mean ..
7.2.2 Estimation of variance.
7.3 Estimation of steady-state phase characteristics
7.3.1 Length of the transient period
7.3.2 Independent replications method
7.3.3 Method of batch means
7.3.4 Regenerative method.
7.4 Variance reduction methods
7.4.1 Control variables . . .
7.4.2 Antithetic variates ..
7.4.3 Common random number streams

139

Examples of simulation models
8.1 A simple preemptive system . . . . . . . . .
8.2 A system with priorities and group servers.
8.3 Assembly line . . . . . . . . . . . . . . . . .

171
172

8

95
96
97

98
99
101

140
144
145
147
148
148
152
156
158
164
164
165
168

178
185


Contents
8.4

8.5

Finite-population queuing model
Satellite communication system

ix

191
196

Epilog

207

10 Exercises

213

A Probability distributions
A.l The standard normal distribution.
A.2 The Student's t distribution .
A.3 The chi-square distribution . . . .
A.4 The F distribution . . . . . . . . .
A.5 The Kolmogorov-Smirnov distribution

237

Bibliography

247

Index

255

9

238
239
240
241
245


Preface

few years ago, a friend of mine inherited a restaurant from a relative he
A had
never met. The restaurant was everything but a profitable institution. Many potential customers were being notoriously turned away because
of insufficient number of tables and lack of waiters. Unfortunately, his vigorous decisions to rent extra space and hire new staff made the situation even
worse. After the changes, many tables were never taken, he kept paying more
to the building owner, and staff costs went higher. Furthermore, the inventory
level of many products he was ordering went too high, so when the products
validity expired, many of them had to be thrown away. At some point he arrived with a basic question: is it possible to avoid such a disastrous scenario
of running painful experiments until being declared bankrupt? This book is
about an alternative scenario he was looking for. It is going not only to answer
the last question positively by advocating computer simulation as a valuable
and safe investigation tool, but also it will demonstrate how to use simulation
to estimate quantities of interest based on data we can provide to computer
programs.

Simulation is the art and science of constructing models of systems for the
purpose of experimentation. In particular, computer simulation is a technique
used to imitate, on computers, systems exhibiting complex, time-dependent
behavior. These systems, often not subject to direct experimentation, cannot
be studied by any other reasonable means. Consequently, computer simulation is becoming the dominant technique in many human activities. Examples
include designing manufacturing facilities and evaluating their performance,
designing transportation systems and projecting their behavior under various
traffic loads, designing communication networks and testing protocols used to
operate these networks, and many others. Clearly these systems can be all
treated as collections of objects bound into a web of complex and stochastic


xii
relations. Consequently, building either prototypes to run "real experiments"
or actual systems based on rough approximations is not a feasible solution as
too expensive and too risky a venture. Before we go on to discuss simulation
as a remedy for the problems like those listed above, a few words concerning
existing texts are in order.
A careful review of many textbooks on simulation available on the market
indicates clearly that they often lack harmony between two main aspects: the
programming techniques relevant to simulation and the statistical methodology devoted to proper answering questions about systems being simulated. It
can be easily observed that most of these books concentrate either on simulation programming or statistical foundations of simulation at the expense of
modeling aspects. Consequently, the reader needs to refer to other books for
missing information, or is left with incomplete data. This often precludes optimal design decisions and leads to inefficient implementations. In some cases
a customized simulation software is provided as a supplement to some of these
texts. Although usually easy to learn, it inherently deemphasizes the importance of many distinct elements of simulation programming art, and eventually
creates a kind of a package-dependent rather than well-educated modeler.
The main purpose of this book is to offer a complete and fairly balanced
yet not overlength presentation of a wide repertoire of computer simulation
techniques available to the modelers of dynamic systems. It will guide the

reader through the maze of alternative therapies, solutions, rules, and issues
relevant to computer simulation. Eventually, it will also help the reader to become comfortable with creating computer simulation models and to appreciate
the powerfulness of this technique. This is achieved by covering all basic and
generic concepts used in computer simulation of discrete event systems in a
comprehensive, uniform and self-contained manner. In addition, the presentation benefits from the object-oriented methodology which is used throughout
the book as its main programming platform. The reader is expected to have
only some programming experience in C++ and some background in the theory
of probability and statistics.
In the following chapters we will discuss a wide variety of paradigms, theoretical concepts and practical scenarios concerned with design, programming,
and exploitation of discrete-event simulation models. We will show that even
the simplest techniques provide a very high potential for the integration of
their features into efficient and portable simulation packages. In Chapter 1
the basic definitions associated with the discrete event systems and their simulation models are introduced. They are illustrated by means of an example
simulation model of automatic teller machines. The simulation experiment is
conducted here manually in order to demonstrate the concepts of simulation
clock and system state variables as well as time management methods and
event sequencing procedures. The chapter concludes with one of the simplest


Preface

xiii

simulation algorithms - a concept of activity scanning. We will demonstrate
how to partition the event domain into time-dependent and state-dependent
events, and how to advance the simulation clock based on global and relative
time attributes.
Chapter 2 introduces the most popular concept of constructing simulation
models by using an event-scheduling principle. The chapter also discusses
a superposition of the event-scheduling technique with the activity-oriented

methodology which results in so-called ABC method. Recommendations addressing possible applications of all presented algorithms supplement this part
of the book. As a run-time efficiency of the event-scheduling approach rests on
implementation of future event sets, a comprehensive survey of data structures
that can be employed to realize these sets is provided in Chapter 3. Customized
lists and trees are among structures whose object-oriented implementations are
discussed here altogether with a comparative study of their performance.
Chapter 4 introduces another paradigmatic modeling style. It is based on
a concept of a process being a sequence of events. We will show generic operations used to synchronize processes, demonstrate their realizations using
a coroutine facility, and define a software environment in C++ to support
a quasi-concurrent programming technology. The process interaction framework developed in this chapter will allow us subsequently to discuss an entirely
distributed simulation methodology in which a single simulation program is executed on a parallel computer. This is achieved by decomposing the simulation
into a set of concurrently running processes. Two basic mechanisms of parallel
simulation are presented: conservative (the approach to determine when it is
safe to process events) and optimistic (using detection and recovery approaches
with a rollback technique).
Although the simulation methodology is adequate for modeling arbitrary
kinds of systems, its drawback is that a great amount of care is necessary to
arrive at high confidence estimates of important system parameters. How long
do we need to simulate? Can we combine the results from various simulation
runs? How to implement randomness and what kind of pseudo-random generators are required? These questions are addressed in the next three chapters via
statistical techniques that have become quite standard in the field of simulation. Chapter 5 concerns the generation of pseudo-random numbers. It includes
the basic congruential schemes used to produce uniformly distributed random
numbers as well as a discussion of some common tests employed to evaluate
their properties. The second part of this chapter comprises a detailed survey
of the most commonly used techniques and algorithms to generate nonuniform
variates.
The aim of chapters 6 and 7 is to describe various aspects of statistical
treatment of simulation inputs and outputs. Many statistical techniques exist to support design and analysis of simulation experiments, and although

XIV

some of them are quite natural (e.g., longer simulations lead to more accurate
system parameter estimates), the investigator should be careful in designing
experiments so as to obtain the maximum amount of information in acceptable
simulation time. Therefore we will examine different methods for the estimation
of performance measures and techniques for improving the efficiency of simulation. The approaches employed to design simulation experiments will also
be surveyed. Chapter 6 begins, however, with several introductory elements of
the queuing theory that can be used in validation of simulation models.
Chapter 8 presents complete examples of simulation models written in C++.
It is intended to illustrate methods and algorithms presented in the preceding
chapters of the text. We will focus on system identification, distinction between time and state events and selection of simulation technique. Simple yet
not trivial object-oriented programs show the associated techniques for data
collection, time management, and statistical instrumentation. In particular,
different classes of queuing networks have been chosen as particularly adequate
means for capturing variety of systems in a compact form, especially if they
exhibit certain regularities.
Chapter 9 summarizes the methods and techniques presented in the book
and surveys selected elements of simulation methodology. In particular, main
phases of a typical simulation project are discussed as well as advantages and
disadvantages of simulation are listed along with commonly made mistakes
when using computer simulation. Also, motivations behind the development
of simulation languages and their features are briefly described. The book
is not, however, tied down to any particular simulation language, as such a
language could be presented sufficiently only in a separate software manual.
We will conclude with a collection of 50 simulation problems and exercises for
the readers in their first attempts to write simulation programs (Chapter 10).
The author hopes that the broadness of the covered material, simplicity of
its presentation, and variety of used illustrations will enhance the applicability
of this text to a large and diversified audience including students, teachers,

practitioners and researchers working in industrial, government, and academic
R&D environments that embody computer, telecommunication, aerospace, mechanical, civil, chemical, materials, biomedical, and microelectronics industries
as well as management and business administration, education, financial services, health care systems, transportation, environmental forecasting, system
sciences, and many others.
I would like to thank Zbyszko Czerpinski and Jan Kniat for their valuable
comments and helpful discussions we had. My special thanks go to Agnieszka
Wachowska for her help in preparation of the manuscript.
J erzy Tyszer


(HAPTER 1

Getting
started

B

EFORE we proceed to present
major programming techniques
appropriate to the developing of advanced simulators, it is justified to
start from a brief overview of existing modeling and simulation terminology. We begin this chapter by
introducing several concepts underlying models of discrete-event systems, especially those related to
time management mechanisms and
event sequencing procedures. We
will then look at an example simulation model which can be easily executed by means of paper and pencil.
The chapter concludes with the simplest simulation technique known as
the activity-oriented approach. It
will allow us to write simple yet nontrivial simulation programs.

J. Tyszer, Object-Oriented Computer Simulation of Discrete-Event Systems

© Kluwer Academic Publishers 1999


2

1.1

1. Getting started

Basic notions

Through the course of this book, simulation will be regarded as an algorithmic technique of conducting experiments (by means of digital computers) on
numerical models of systems evolving in time. A system can be defined as a
collection of mutually dependent components whose actions on each other form
a dynamic process. In order to capture the behavior of the system of interest,
one has to prepare a suitable model consisting of internal representation and a
set of transformational rules. It can be then used to predict the operation of
the system in terms of individual events associated with system's entities under the influence of several internal and environmental conditions. The internal
representation may employ a number of variables corresponding to a variety of
attributes - characteristics and properties describing entities. These variables,
often referred to as state variables, are subsequently used to define the system
state, that is, every rational combination of values assumed by the state variables. The second component of the model, the transformational rules, allows
one to mimic the dynamic behavior of the system by appropriate changing of
the state variables. This is essentially what we mean by simulation of dynamic
systems.
The state variables may change their values either in a continuous manner,
that is, by an amount ~v in an increment ~t of time, or by arbitrary amounts
only at specified time points. Models adopting the former scenario are usually
composed of a number of differential equations which can be solved by applying
classical numerical methods. These problems are beyond the scope of this book.

The interested readers may refer to [58]. The latter concept, on the other hand,
is frequently used in modeling of discrete-event systems, and simulation of this
type of systems will be discussed in the remaining parts of this text. An event,
a key term in this context, is defined to be an instantaneous change in the value
of one or more state variables. In rather rare cases we will use term endogenous
to indicate events occurring within a system, while the term exogenous will refer
to events affecting the system.
Simulation of discrete-event systems can be basically performed according
to one of the following two paradigms. The first approach, called synchronous
simulation, assumes a discrete time parameter. In other words, the system is
observed only at particular time epochs, typically evenly spaced. Although this
"fixed-time increment" mechanism is conceptually very simple and some models
are of this type (for instance in economics applications), it has a number of disadvantages. They can be mainly attributed to the fact that non-simultaneous
events may be now treated as simultaneous ones as they are allowed to occur
only at specific moments. Clearly, events falling into the same interval have
to be artificially merged, which consequently leads to ambiguity in handling
of their order of occurrence and priority. Furthermore, in order to guarantee


1.1. Basic notions

3

accurate results, the time increment has to be sufficiently small, thus slowing
down the whole simulation experiment. For these reasons, the synchronous
simulation will be outside our concern.
The second approach, known as an asynchronous simulation, uses a nextevent strategy for advancing model time. Here, the value of a clock, a global
variable maintained by every simulator in order to represent the passage of time,
is incremented directly from one event time to the next event time, no matter
what interval separates them, provided no further actions can be performed

at the current time instant. The underlying principle of this methodology is
an observation that the system state remains unchanged between events, and
therefore the system does not have to be observed during this period of time.
It significantly simplifies ways the events are manipulated and the system state
is updated. Many existing simulation algorithms and virtually all computer
languages for simulation of discrete-event systems employ this strategy despite
clear differences among them in their philosophies. We will elaborate on this
primary aspect of the event sequencing strategy in the next chapters of this
book.
Usually events occurrences coincide with the beginning and end of activities. An activity is an action extended over time and performed by a system
component. It starts when some pre-specified conditions are satisfied and ends
after a significant duration of time. It should be emphasized that the term
activity does not necessarily imply that the component is active in an intuitive
fashion: simply waiting for some conditions to be met can also be regarded
as an activity since it takes time. The above definition also indicates that,
in general, events can be divided into two categories according to conditions
under which they may occur:
• time events - in order to invoke an event belonging to this class it suffices
to determine a point on the time axis (or in the simulator agenda) when
this event should occur,
• state (conditional) events - the occurrence of this type of events is guarded
by a condition (a system state) specifying under which circumstances
(different than time) an event can be triggered.
1.1 Consider a barber shop where a single barber serves, in order of
arrival, a stream of customers. There are two time-oriented events: customer
arrival and service completion. There is also one state-dependent event: beginning of service. This event occurs (or activity hair cut starts) whenever there
is at least one waiting customer and the barber is idle.

EXAMPLE

Events and activities allow one to view a model of the system as a collection
of co-existing and interacting objects. If several events can be logically con-


4

1. Getting started

+-------+ Activity

l

- . Process
Event

~--_14

FIGURE

•

1.1: EVENTS, ACTIVITIES AND PROCESSES.

nected with the same entity, or similarly, the corresponding activities can be
grouped into a conceptual closure of actions accompanying these events, then
the ordered sequence of events (activities) forms a process. Hence, the behavior
of a system can be represented by a set of concurrent and interacting processes.
The barber shop example could contain successive customer processes as well
as a single barber process. In the first case, each process would consist of
two activities (actions): waiting for service and the actual hair cut (service).

The process associated with the barber may comprise two alternating actions:
carrying out the hair cut and waiting for a new customer.
The relationships between terms just introduced are shown in Fig. 1.1.
Obviously our rough definitions will not satisfy everybody. Moreover, as we
will see later, some terms are used in somehow ambiguous manner. We will
carryon, therefore, leaving more general concepts to be defined by the context
in which they are encountered. It is worth, however, to recall a characterization
of discrete-event simulation given by Shannon [79] and modified by Evans [18].
It ties up the simulation terminology by defining this technique as

entities
having attributes that
interact with one another during activities
under certain conditions
creating events
that change the system state.


1.2. Manual simulation

5

._. I.

FIGURE 1.2: THE BANK ATM CENTER.

1.2 Manual simulation
The purpose of this section is to familiarize the reader with the basic simulation
concepts and mechanisms, such as model time, simulator clock, event times,
event notices, and scheduling of events. Consider a bank foyer where three

automatic teller machines (ATM), labeled from 1 to 3, have been installed
(Fig. 1.2). Though customers may arrive at this place randomly, we will assume
for a moment that values of inter arrival times for the first 15 clients are known
a priori and are as follows: 2, 5, 1,4, 1, 3, 3, 2,4, 5, 9, 6, 7, 1, and 4 time units.
In other words, the first customer is assumed to show up at time 2, the second
customer arrives five time units later, that is at time 2 + 5 = 7. The third
customer will come 1 time unit later at time 7 + 1 = 8, and so on. Customers
go to the first available machine, unless all of them are occupied. In such a
case, they join a waiting line. In order to complete service which may include
withdrawing cash, depositing checks, checking an account balance, and many
other operations, the examined customers will need the following amounts of
i.;ime: 12, 10, 16, 9, 10, 13, 17, 10, 8, 12, 14, 13, 10, 12, and 15 units. In fact, we
will end the simulation after these 15 customers have completed their service.
The primary goal of this simulation experiment is to answer the following
questions:


6

1. Getting started
1. What is the probability that a customer has to wait in the queue?
2. What is the average waiting time of those who had to join the queue?
3. What is the average time a customer spends in the bank?
4. How long during simulation:
• there was no waiting line,
• only one customer was waiting in the queue,
• two customers were waiting in the queue,
• three customers were waiting in the queue, etc.
5. What is the proportion of busy or idle time of each machine?

In the next chapters of this book we will see how to design an environment that
will allow us to answer the posed questions by means of computer programs.
Right now, however, we will perform simulation directly without the aid of a
computer. This "manual" experiment will provide us with an insight into the
methodology of discrete-event simulation experiments and the accompanying
techniques for gathering simulation results.
In general, simulation of discrete-event systems requires the maintenance of
two objects:
• an internal clock to keep track of the passage of time,
• an event list to determine the order of occurrence of events in time.
Let us assume that the value of the clock is held in variable CLOCK, and this
value is incremented according to the next-event paradigm. Also, in order to
imitate a simulation agenda or an event list, let us use a simple table which
keeps track of the time at which each event occurs (see Table 1.1). The table
is organized as follows. Its first column shows the simulation time. The second
column records the time of each customer's arrival event, while the next three
columns are used to record the time of customer departure events. In addition,
the last column of the table depicts the number of customers in the queue (with
service times requested by these customers).
We start observation of the ATM system at time 0, that is, for CLOCK= O.
As shown in the table, the first customer arrival is the only scheduled event
(at time 2). Thus, the simulation clock can be advanced to its event time.
The arriving customer immediately begins service (by choosing the first ATM)
which requires 12 time units. Consequently, this client's departure can be
scheduled at time 2 + 12 = 14, as indicated in column ATM-1. Moreover,
since the next customer is going to arrive in 5 time units, this event can be


1.2. Manual simulation

7

Table 1.1: Manual simulation.
CLOCK

0
2
7
8
12
13
14
16
17
19
21
23
24
25
27
30
36
37
39
41
44
45
49
52
53

55
57
58
62
67
73

Arrival
0+2-2)
2+5=7)
7+1=8)
8 + 4 = 12 )
12 + 1 + 13 )
13 + 3 = 16
16 )
16 + 3 = 19
19 )
19 + 2 = 21 )
21 + 4 = 25
25
25 )
25 + 5 = 30
30 )
30 + 9 = 39
39
39 )
39 + 6 = 45
45
45 )
45 + 7 = 52

52 )
52 + 1 = 53 )
53 + 4 = 57
57 )
-

-

-

ATM-1

-

ATM-2

-

2 + 12 = 14
14
7 + 10 = 17
14
17
14
17
14 )
17
14+9=23
17
23

17 )
23
17 + 10 = 27
23
27
23 )
27
27
23 + 13 = 36
36
27
36
27 )
36
27 + 10 = 37
36 )
37
36 + 8 = 44
37 )
44
37 + 12 = 49
44
49
44 )
49
49
49 )
45 + 13 = 58
58
58

52 + 10 = 62
58
62
58
62
57 )
62
62 )
58 + 15 = 73
73
73 )
-

Queue
0
0
0
0
8 + 16 = 24
24
1 (9)
24
2 (9, 10)
24
1 (10)
24
2 (10, 13)
24
1 (13)
24

2 (13, 17)
24
3 (13, 17, 10)
24 )
2 (17, 10)
1 (10)
24 + 17 = 41
41
2 (10, 8)
41
1 (8)
41
2 (8, 12)
41
1 (12)
41
0
1 (14)
41 )
41+14=55
0
55
0
0
55
55
0
0
55
1(12)

55 )
0
55 + 12 = 67
1 (15)
67
0
67
67 )
0
0
0
ATM-3

-

scheduled at time 2 + 5 = 7 by putting a corresponding event notice in column
Arrival. Recapitulating, two new events are scheduled during these operations:
the second customer arrival (at time 7) and the service completion on the ATM
No.1 (at time 14). Clearly, the incrementing of the clock is now performed by
finding the smallest event time among those available in the simulation agenda
and taking it as the current clock value. The reader can easily verify that
the arrival of the second customer, who will grab the ATM No.2 for next 10


8

1. Getting started

time units, will be the next event. The corresponding event notice regarding
the time when this customer will be finished is subsequently placed in column

ATM-2.
The smallest event times for every simulation step are marked in successive
rows of Table 1.1 by J. As can be seen, our simulation begins by scheduling five
successive customer arrivals. As a result, all ATMs are busy and two customers
end up in the queue. In particular, the fifth customer, arriving at time 13,
cannot begin service until time 17. Between times 21 and 23 we may notice the
longest waiting line (3 customers in the queue). The whole experiment stops
when the last customer finishes service at time 73. Though all events have been
scheduled and triggered here manually, some interesting rules can already be
noticed at this point. Each time it is scheduled, the arrival event effectively reschedules itself to occur some time in the future, according to the data provided
earlier. Similarly, the departure event attempts to re-schedule itself on a given
ATM, provided there is at least one customer waiting in the line. Otherwise,
this ATM becomes idle and there are no further events associated with it at this
moment. These mechanisms form the essence of event simulation techniques
and will be discussed in greater detail in the next chapters as a basis for writing
simulation procedures.
A careful analysis of entries gathered in Table 1.1 allows one to answer
questions formulated earlier in this section.
Queuing probability. This is the probability that an arriving customer does not
find an idle ATM. It can be determined as a ratio of the number of customers
who had to wait to the total number of customers. From the last column of
Table 1.1 it is evident that 10 customers were forced to wait (just count how
many times the queue size was increased). Thus, the simulation estimate of
the desired probability is 10/20 = 0.5.
Average waiting time. This quantity can be estimated as the arithmetic mean
of all the observed customer waiting times. Note that to compute this estimate
we have to measure for each customer the amount of time elapsed from the
arrival until the beginning of this customer's service. For instance, the ninth
customer arriving at time 25 will only start service after 11 units, that is at
time 36, because of occupancy of all the ATMs. Table 1.2 lists waiting times

for all the customers. From this data we can determine the average waiting
time as 47/20 = 2.35.
A verage system time. Similarly as before, this can be estimated as the arithmetic mean of all the observed customer system times, that is, the time spent
in the bank by every single customer. These numbers can be easily obtained
by adding the respective numbers from Table 1.2 to the corresponding service
times. Hence, we have 228/20 = 11.4.
Mean queue length. This can be calculated based on the following formula:


1.3. Activity scanning

9

Table 1.2: Waiting and system times.
Customer
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Waiting time 0 0 0 2 4 7 5 6 11 7 2 0 0 2 1
System time 12 10 16 11 14 20 22 16 19 19 16 13 10 14 16

00

Q = Liq(i),

(1.1)

i=O

where q(i) is the probability that the queue length is i over the total simulation
time. In order to obtain estimates of q(i), we have to sum up all time intervals
during which the waiting line was comprised of i customers. From Table 1.1

we have, for instance, that two customers were waiting for service during the
following intervals: (14-13), (17-16), (21-19), (24-23), (27-25), (36-30),
which give in total 13 time units. Thus, the average queue length is:
-

15
73

Q= 1.-

13
2
+ 2 . -73
+ 3 . -73

= 0 6438.
.

ATM utilizations. These are probabilities that each machine is busy during the
time it takes to serve 20 customers. Each of them can be determined as a ratio
of the total busy time of the ATM to the total simulation time. The required
numbers can be easily obtained by summing up the service times occurring in
columns ATM-l, ATM-2 and ATM-3 of Table 1.1. For example, for the first
machine, its total utilization time is 12 + 9 + 13 + 8 + 13 + 15 = 70. Thus, the
requested probability is given by 70/73 = 0.96. In a similar fashion, one can
compute the remaining two probabilities, which are 0.71 and 0.81, respectively.
It has to be emphasized that the quantities obtained from this example
simulation run are only rough estimates of the actual performance measures
of the bank ATM center. In order to increase the accuracy of these findings,
usually a much longer simulation experiments would be needed. The problems

related to design and conduction of such experiments will be the subject of
thorough analysis in Chapters 6 and 7.

1.3 Activity scanning
We are now ready to learn the first simulation technique which is particularly
easy to program. It is called the activity-scanning approach and offers the convenience of not having to worry about the global picture of simulated systems
due to the absence of explicit handling of interactions between events. In every


10

1. Getting started

simulation step the algorithm scans all activities, checking whether they can be
started or finished. In fact, as events delimit corresponding activities, a model
control unit cyclically verifies conditions under which these events (rather than
activities), both time and state, may occur. Every event is, therefore, associated with a set of conditions or a time indicator that specify when it can take
place. The time indicators are further classified into two categories: relative
and absolute (global) ones. In the former case the time indicator gives a time
period after which a particular event will occur. The latter one provides the
same information in terms of a global simulation time.
Typically an event occurrence leads to changes in the system state. Consequently, several activities may be influenced by each others' actions. Since
checking of conditions is performed sequentially, it is possible that certain conditions would be tested before a system has actually reached this particular
state. As a result, some events may be either triggered too late or not triggered at all. Therefore, scanning of all conditions has to be repeated until no
activity is able to start throughout a whole cycle. Otherwise, for example, the
starting conditions of a service at the bank ATM center (see the previous section), that is, an idle machine and at least one customer in a queue, may not
be tried again, even though the termination of another service may release one
of the ATMs at the same moment. In many simple models, on the other hand,
such repeated scans may not be necessary. A sufficient remedy to resolve such
a problem is a proper ordering of event condition tests, or just making sure

that the time events precede the state events on the simulator check list.
In general, the activity-scanning strategy can be summarized in the following form:
ALGORITHM 1.1: ACTIVITY-SCANNING APPROACH
1: Initialize the model.
2: If the simulation period expired or other stopping conditions are satisfied,
terminate the simulation.

S: Set the NO_EVENLTRIGGERED flag.

4: Scan all events and for those among them whose occurrence conditions are
satisfied, change the system state appropriately by invoking corresponding event routines and subsequently reset the NO_EVENT _TRIGGERED
flag.
5: If the NO_EVENT_TRIGGERED flag is reset, return to step 3.
6: Advance the simulation clock and go to step 2.
A time flow mechanism (step 6) uses, at any moment of time, only those
time indicators whose values are greater than the current value of the simulation


1.3. Activity scanning

11

clock (if a simulator works with absolute event times) or are greater than zero
(for relative event times). In other words, only those event times are considered
that point out to events scheduled to occur in the future. For the relative time
indicators, the simulation clock can be advanced according to the following
algorithm:
ALGORITHM

1.2:

TIME MANAGEMENT - RELATIVE VALUES

1: Find the smallest time indicator T min among those event times whose
current values are greater than zero.
2: Subtract the value of Tmin from all time indicators defined in the model.
3: Add the value of T min to the simulation clock.
Clearly, event times assuming value of zero indicate current time events for
which the corresponding procedures should be invoked. Furthermore, negative
time indicators are associated with events which are currently not scheduled
to occur in the future. An absolute value of such an indicator can be regarded
as a time that has passed from this event's last occurrence. For absolute time
indicators, the simulation clock advance scenario is as follows:
ALGORITHM

1.3:

TIME MANAGEMENT - ABSOLUTE VALUES

1: Find the smallest time indicator T min among those event times whose
current values are greater than the current simulation clock.
2: Assign the value of T min to the simulation clock.
As can be easily noticed, occurrence of time events is, in this case, determined
by those time indicators whose values are equal to the current simulation clock.
We will now view two simple service systems through the activity-oriented
scenario. First, consider a customs check point located in a small airport
(Fig. 1.3). A single customs officer serves, in order of arrival, a stream of
passengers leaving the baggage claim area. There are three distinct event types:
passenger arrival, service completion, and beginning of service. The first two
types represent time events while the last one is a state event. There will

be two relative attributes: ARRIVE_TIME and DEPART-TIME, recording the
times which are left to the next passenger arrival at the check point, and to
the service completion by the customs officer, respectively. It is worth noting
that if occurrence conditions regarding time events are checked first, then this
simulation model does not require repeated scans of all conditions. Thus, the
main simulation loop will consist of the following steps:
ALGORITHM

1.4:

CUSTOMS CHECK POINT

1: Initialize event times and other variables.


12

1. Getting started

jj

1.11
FIGURE 1.3: THE CUSTOMS CHECK POINT.

2: If the simulation clock expired, terminate the simulation.

3: If ARRIVE_TIME

4:

= 0, then invoke procedure ARRIVAL.

If DEPART_TIME = 0, then invoke procedure DEPARTURE.

5: If there is at least one passenger in the queue and the officer is idle, invoke
procedure SERVICE.
6: Update the simulation clock (Algorithm 1.2) and go to step 2.
The actions of the event procedures are fairly straightforward and can be
written as follows.
ALGORITHM 1.5: ARRIVAL
1: Enter a new passenger at the tail of the queue.

2: Generate an interarrival interval based on the appropriate information
and assign this value to ARRIVE_TIME.
ALGORITHM 1.6: DEPARTURE
1: Make the customs officer free.
ALGORITHM 1.7: SERVICE
1: Remove the first passenger from the queue.
2: Make the customs officer busy.

3: Generate a service time based on the appropriate information and assign
this value to DEPART _TIME.


1.3. Activity scanning

-

13

•• II

--

l

-•

lNlnm
~

00000 0

FIGURE 1.4: THE SUPERMARKET MODEL.

During the initialization phase (step 1) variable ARRIVE_TIME may assume
value of the first passenger arrival time, while attribute DEPART _TIME can be
set to the value of -1. As a result, all conditions will not be satisfied during the
first simulation cycle, and the simulation clock will be advanced to the value
held in ARRIVE_TIME. Clearly, there are other initialization scenarios possible
in which, for example, there are already passengers waiting in line, the customs
officer is busy, and there are time events scheduled to occur in the future. Such
arrangements can appear useful if one wants to shorten a transition period of
a simulation process, as will be shown in Chapter 7.
Our next example is a simulation model of a supermarket. Its operation is
schematically shown in Fig. 1.4. Customers arrive and are either immediately
allowed to enter the shopping area, provided there is at least one available
shopping cart (their number is limited), or they have to wait in line at the entrance until another customer will return a cart. After time necessary to collect
required goods, a buyer enters the checkout for service. There are two checkout
counters, and one with a currently shorter line is chosen by the client. When

the checkout has finished with a customer, the customer leaves the supermarket returning the shopping cart. At the same time the next waiting customer
enters the checkout for service. If no customer is present, the checkout becomes
dormant. In addition, each checkout counter suspends periodically its operation for a short period of time in order to deposit collected money. This brake,
however, does not change the state of both waiting lines, though it may impact
the total service time.
There are four time event types in the above system: customer arrival at
the supermarket, customer arrival at the checkout area, customer departure