Object oriented computer simulation of discrete event systems

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 e

Object-Oriented Computer Simulation of Discrete-Event

Systems

ON DISCRETE EVENT DYNAMIC SYSTEMS

PERTURBATION ANALYSIS OF DISCRETE EVENT DYNAMIC SYSTEMS

Yu-Chi Ho and Xi-Ren Cao

MODELING AND CONTROL OF LOGICAL DISCRETE EVENT SYSTEMS

Ratnesh Kumar and Vijay K Garg

Object-Oriented

Discrete-Event Systems

Jerzy Tyszer

Poznan University of Technology, Poznan, Poland

SPRINGER SCIENCE+BUSINESS MEDIA, LLC

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, photo-copying, 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

viii

4.3.3 Optimistic mechanisms

5 Random number generators

5.1 Uniform random variables

5.3 Non-uniform variate generation

5.3.1 Inverse transformation method

5.3.2

5.3.3

5.3.4

Convolution Rejection method Further examples

6 Design of simulation experiments

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

8 Examples of simulation models

8.1 A simple preemptive system

8.2 A system with priorities and group servers

8.4 Finite-population queuing model

8.5 Satellite communication system

9 Epilog

10 Exercises

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

Preface

A few years ago, a friend of mine inherited a restaurant from a relative he had never met The restaurant was everything but a profitable institu-tion Many potential customers were being notoriously turned away because

of insufficient number of tables and lack of waiters Unfortunately, his ous 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

vigor-to the building owner, and staff costs went higher Furthermore, the invenvigor-tory 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 ar-rived 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 tion 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

simula-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 methodol-ogy devoted to proper answering questions about systems being simulated It can be easily observed that most of these books concentrate either on simu-lation 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 op-timal 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 impor-tance 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 be-come 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 presenta-tion 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, retical 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 sim-ulation 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

theo-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 ad-dressing 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 erations used to synchronize processes, demonstrate their realizations using

op-a coroutine fop-acility, op-and define op-a softwop-are environment in C++ to support

a quasi-concurrent programming technology The process interaction work developed in this chapter will allow us subsequently to discuss an entirely distributed simulation methodology in which a single simulation program is ex-ecuted 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)

frame-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 genera-tors are required? These questions are addressed in the next three chapters via statistical techniques that have become quite standard in the field of simula-tion 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 ex-ist to support design and analysis of simulation experiments, and although

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 lation The approaches employed to design simulation experiments will also

simu-be surveyed Chapter 6 simu-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 be-tween 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, me-chanical, civil, chemical, materials, biomedical, and microelectronics industries

as well as management and business administration, education, financial vices, health care systems, transportation, environmental forecasting, system sciences, and many others

ser-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

BEFORE we proceed to present major programming techniques appropriate to the developing of ad-vanced simulators, it is justified to start from a brief overview of exist-ing modeling and simulation termi-nology We begin this chapter by introducing several concepts under-lying models of discrete-event sys-tems, especially those related to time management mechanisms and event sequencing procedures We will then look at an example simula-tion model which can be easily exe-cuted by means of paper and pencil The chapter concludes with the sim-plest simulation technique known as the activity-oriented approach It will allow us to write simple yet non-trivial simulation programs

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

© Kluwer Academic Publishers 1999

1.1 Basic notions

Through the course of this book, simulation will be regarded as an mic technique of conducting experiments (by means of digital computers) on

algorith-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 un-der 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 ables 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

vari-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 dis-advantages 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 event strategy for advancing model time Here, the value of a clock, a global

next-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

activi-ties 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

EXAMPLE 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: begin- ning of service This event occurs (or activity hair cut starts) whenever there

is at least one waiting customer and the barber is idle

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-+ -+ Activity

- Process

l 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

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:

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

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

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 re-schedules 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 metic mean of all the observed customer system times, that is, the time spent

arith-in the bank by every sarith-ingle customer These numbers can be easily obtaarith-ined

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:

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:

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

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, associ-ated 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 sequently, several activities may be influenced by each others' actions Since checking of conditions is performed sequentially, it is possible that certain con-ditions 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 trig-gered 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 sec-tion), that is, an idle machine and at least one customer in a queue, may not

Con-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 ing form:

follow-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 correspond-ing 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 T min 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

jj

1.11

FIGURE 1.3: THE CUSTOMS CHECK POINT

2: If the simulation clock expired, terminate the simulation

3: If ARRIVE_TIME = 0, then invoke procedure ARRIVAL

4: 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

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 en-trance 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 supermar-ket 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 opera-tion 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

from the checkout counter and change in the checkout counter status (from open to closed and vice versa) State-dependent events comprise beginning of

shopping (to trigger such event at least one customer in the entrance queue and

at least one shopping cart is required) and beginning of service at the checkout

counter (this event, in order to be invoked, requires a non-empty queue and a free checkout counter) In order to handle the time events correctly, we will need a number of time indicators: one to record the arrival times, an array of attributes associated with the shopping carts (they will allow us to determine the shopping completion times), and two variables for each checkout counter (one for regular customers and another one to keep track of operation brakes)

Actions needed to serve the customer arrival event are analogous to those

of Algorithm 1.5 Also, the customer arrival at the checkout event requires only

putting a buyer at the tail of a shorter waiting line Completion of service at the checkout is performed in the following two steps:

ALGORITHM 1.8: DEPARTURE FROM THE CHECKOUT

1: Make the checkout free

2: Return a shopping cart

Perhaps the most interesting portion of this simulation model is a dure associated with the event designated to represent changes in the checkout status It is comprised of the following actions:

proce-ALGORITHM 1.9: CHECKOUT STATUS CHANGE

1: Invert a Boolean variable representing the current status of the checkout counter, that is, from closed to open or vice versa

2: If a new status is open, generate an operative period based on the

ap-propriate information, assign this value to the time indicator associated with this counter and make the checkout free

3: If a new status is closed then:

• generate a suspension period and assign this value to the same time indicator as in step 2,

• if a service completion event is scheduled (that is, this counter is busy), re-schedule this event by adding the suspension period value

to the current value of time indicator representing a time left to the end of service; otherwise make the checkout busy

It should be noted, that the last step of Algorithm 1.9 takes advantage of

relative time attributes and operations performed by Algorithm 1.2 Indeed,

1.3 Activity scanning 15

at any time the content of such attributes represents time that has to elapse before a respective event may occur Thus, operations required to modify the event occurrence times are especially easy to implement As can be verified, a duration of service that the affected customer will experience, will be basically increased by the amount of time during which the counter will not be available

The conditional event beginning of shopping requires two actions: picking

the shopping cart up and generating a shopping interval after which a given

customer will show up in the checkout area The relevant beginning of service

can be described in a manner similar to that of Algorithm 1.7 Thus, the main simulation loop can be eventually outlined in the following way:

ALGORITHM 1.10: SUPERMARKET

1: Initialize the model

2: If the termination conditions are true, stop the simulation

3: If ARRIVE_TIME = 0, then invoke procedure ARRIVAL

4: Find the time indicators associated with the shopping carts whose values are equal to zero For these variables invoke successively event procedure ARRIVAL-AT _CHECKOUT

5: If there are time indicators, associated with the checkout counters, which are zeros, then for these indicators invoke Algorithm 1.8

6: If there are time indicators, associated with the status flags of the out counters, which are zeros, then for these indicators invoke Algorithm 1.9

check-7: As long as the entrance queue is not empty and there are shopping carts, invoke procedure START _OF _SHOPPING

8: If the checkout queues are not empty and the corresponding counters are not busy, then invoke procedure START _OF _CHECKOUT

9: Update the simulation clock and go to step 2

As can be seen, the computational efficiency of the activity-scanning proach decreases with the increasing number of events This is due to the fact that at each scan of time indicators and system states only a small subset of relevant events can be triggered As potentially active events are not known a priori, all of them must be examined It clearly suggests that this method is especially suitable for systems with a relatively small number of events Some-times tests can be optimized or a mixed strategy can be adopted so that time events are handled differently For more detailed analysis of possible trade-offs between alternative simulation strategies, please refer to sections 2.2 and 2.3

ap-Event scheduling

programs are based on an event-scheduling approach In fact, the event scheduling constitutes the cornerstone of discrete-event com-puter simulation The reason for this popularity stems from the com-putational efficiency of the tech-nique There is a certain price that has to be paid, however The re-sulting simulation models are usu-ally quite obscure In addition, they require pretty sophisticated data structures to implement the simula-tion agenda In this chapter we will describe the event-scheduling strat-egy and compare a view of the world

it offers with that of the scanning methodology We will also have a look at a composite approach

activity-in which advantages of both niques are combined into a so-called ABC method

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

© Kluwer Academic Publishers 1999

18 2 Event scheduling

2.1 Main paradigm

The event-scheduling approach turns attention to time events and their impact

on system state The scheduling of events is accomplished by the now familiar next-event approach The simulation monitor selects events for execution by processing a time-ordered agenda of event notices, sometimes referred to as the

event calendar Every event notice consists of at least an absolute event time indicator and a reference to a corresponding event routine (Fig 2.1) In other words, the simulation program must feature a mechanism for fetching the next event scheduled to occur, advancing the simulation clock to the scheduled time

of occurrence of the event at the top of the agenda, and transferring control

to the appropriate event procedure Though Fig 2.1 suggests an ordered list

as an implementation platform for the simulation agenda (and indeed, various list structures are quite often in use, justifying a well deserved popularity of a

term event list), there are other solutions worth exploring We will return to

this subject in Chapter 3

FIGURE 2.1: CALENDAR OF EVENTS

Every event class is associated with an appropriate event routine which binds actions transforming system state at time instances corresponding to that event's occurrences Since the event list is used to keep track of pend-ing time events only, the event routines have to explicitly describe all relevant

conditional events that can be triggered due to changes in system state caused

by the time events Consider, for example, a time event customer arrival An associated event procedure ARRIVAL must consider a conditional event begin-

ning of service that can be invoked because there is a new customer Certainly,

a server's availability has to be also checked Furthermore, the same tional events may require examination by different event routines The before mentioned beginning of service is not only taken into account by ARRIVAL, but it can also be caused by DEPARTURE, the routine that defines what hap-pens when the server becomes dormant Indeed, the departure of a customer may immediately lead to the beginning of a new service, provided there is at least one customer awaiting in line The necessity of handling events in this way reveals a major disadvantage of the event-scheduling methodology: the simulation model may become fragmented with several scheduling instructions scattered throughout the program, especially in large models with many event routines and many interactions between them

condi-The main simulation loop of the event-scheduling strategy can be described

in a manner similar to that of Algorithm 1.1 Except the initialization phase,

it consists of continuous repeating of the following steps:

ALGORITHM 2.1: EVENT-SCHEDULING APPROACH

1: Initialize the model

2: If the simulation period expired or other stopping conditions are satisfied, terminate the simulation

S: Advance the simulation clock to a value provided by the time indicator

of the earliest event scheduled to occur (because events are arranged in chronological order, this event time is read from the first event notice kept on the event list)

4: Invoke an event routine corresponding to the earliest event scheduled to occur (which procedure should be called is also indicated by a respective entry of the first event notice)

5: Remove the first event notice from the event list and go to step 2

In order to start and keep running, the simulation experiment needs one

or more event notices to be placed at the appropriate positions in the agenda during the initialization phase Subsequently, "future" events have to be suc-cessively generated in the course of the simulation Typically, new events are

generated according to two paradigms The first one, called bootstrapping or

daisy chaining, refers to the process by which the occurrence of an event is used

to schedule the next occurrence of the same type of event The event routine ARRIVAL is perhaps the best illustration of this technique When invoked, it

20 2 Event scheduling

111111

FIGURE 2.2: CYCLIC QUEUING SYSTEM

should immediately create a new event notice (or even recycle the current event notice) and then schedule the next arrival to guarantee an uninterrupted stream

of upcoming customers Thus we can say that arrivals generate new arrivals as the simulation proceeds The second paradigm defines a scenario under which one type of events generates events of another type according to the logic of a model The same routine ARRIVAL may serve here to illustrate this concept After a customer's arrival, the procedure has to check if a service facility is idle

If so, then a service completion event can be scheduled The same operation

is also carried out by the routine DEPARTURE, which checks the queue to see whether a customer is waiting If this is the case, another service completion is scheduled, what is actually another example of the bootstrapping approach, as the service completion event generates a subsequent service completion event

In Algorithm 2.1 the termination conditions for the simulation are embodied

into a single step without further definitions The only exception is made for the simulation clock which is expected to reach a pre-defined value in order

to stop an experiment In general, however, other conditions are also possible

One may want to simulate for as long as it takes to:

• empty the event list,

• generate a given number of events,

• notice a particular event (this is a commonly used technique to finish the simulation by scheduling, at the very beginning, an event end of simulation; when using this approach, step 2 of Algorithm 2.1 is not needed),

• process a given number of entities,

• record a given number of samples or observations, etc

The remaining part of this section describes three example event-oriented simulation models of simple queuing and transportation systems First, con-sider an n-stage cyclic queuing system as shown in Fig 2.2 Note that the

system is closed, that is, there is no arrival from nor departure to the outside There is a finite population of jobs circulating in this system, so that a job de-parting from the ith server immediately enters the service facility (i+ 1) mod n,

where it begins its service unless the server is busy In the latter case the job is placed in a first-in first-out (FIFO) queue Despite a potentially large number

of events that can be represented by their notices in the simulation agenda (up

to n objects provided there are at least n jobs), there is only one event type that has to be considered This is because an arrival at one server is always the result of a departure from the other Thus, we will consider a service comple-tion event which, when scheduled, has a single parameter identifying a server

on which a corresponding action is planned Consequently, the essence of the entire simulation model can be captured by the following event routine: ALGORITHM 2.2: SERVICE COMPLETION (I: ADDRESS)

1: If the server (i + 1) mod n is free, set its status to busy and schedule the

service completion on this server; otherwise put the job at the end of the queue (i + 1) mod n

2: If the queue i is not empty, take the next job from the front of the queue and schedule the service completion on server i; otherwise set the status

conse-an average job distribution among all queues

Our next example is a service station with m parallel servers which share a common waiting line Note that the bank ATM center analyzed in section 1.2

is a good example of such a system for m = 3 Similarly as in several examples presented earlier, there are two types of time events: job arrival and service completion on one of the servers Event routine ARRIVAL, associated with the first type, schedules a new event of the same type to cause the arrival of the next job in the future The job just arrived is then added to the queue if all the servers are busy; otherwise a free server is acquired and the service completion

on this server is scheduled Thus, we can write down the following procedure: ALGORITHM 2.3: JOB ARRIVAL

1: Schedule the next job arrival

-FIGURE 2.3: THE BUS LOOP

2: If there is a free server, make it busy and schedule the service completion

on it; otherwise place the job in the queue

The content of the next algorithm, describing the service completion, resembles ideas presented in Algorithm 2.2 However, as jobs leave the system once the service has been completed, we obtain a very simple scheme:

ALGORITHM 2.4: SERVICE COMPLETION (I: ADDRESS)

1: If the queue is not empty, take the next job from the front of the queue and schedule the service completion on server i; otherwise set the status

to wait until its predecessor is departed

The following three event types can be distinguished in this system: bus arrival at a given stop, beginning of a take a seat action, and passenger arrival

at a given stop (in order to take a bus) The first two events are characterized by two attributes: the bus stop name and the bus number The last event requires only the bus stop name It also has the simplest event-handling routine which

is as follows:

ALGORITHM 2.5: PASSENGER ARRIVAL (I: BUS STOP)

1: Schedule the next passenger arrival at stop i

2: Enter a new passenger at the tail of the queue associated with stop i

The bus arrival at a given stop is comprised of the following steps:

ALGORITHM 2.6: Bus ARRIVAL (I: BUS STOP; B: BUS NUMBER)

1: If stop i is occupied by another bus, place bus b in a bus queue associated

with this stop and exit; otherwise perform the steps that follow

2: Make stop i occupied

3: Determine the number of passengers getting off at this stop and increase the number of available seats accordingly

4: Schedule take a seat event based on the number obtained in step 3

It is worth to note that time after which the boarding is to commence represents a period taken by passengers getting off the bus If nobody gets

off, then take a seat event will be scheduled at the current simulation time, thus initiating the getting in activity right after the bus arrival at the stop

The corresponding event routine will describe dynamics of this process from

a single passenger's viewpoint Therefore, the whole operation of taking seats

in the bus will consist of a sequence of schedule operations, performed until there are no passengers in the stop queue or there are no free seats in the bus Clearly, this approach allows us to board passengers who came at the stop after the bus arrival, but before its departure The event routine is defined by Algorithm 2.7

ALGORITHM 2.7: TAKE A SEAT (I: BUS STOP; B: BUS NUMBER)

1: If there are no passengers or there are no free seats, go to step 5 2: Remove the first passenger from the stop queue

3: Decrease the number of free seats in the bus by one

4: Schedule the next take a seat event and exit

5: Make the bus stop free

6: Schedule the bus arrival at the next stop

7: If there is another bus in the bus queue, remove it from that queue and execute Algorithm 2.6

24 2 Event scheduling

The last step of the above algorithm is of particular interest As we have seen, the arrival of a bus at a stop does not mean that service of passengers will start immediately This event is conditional and its occurrence depends on the stop availability Thus, when releasing the stop, it has to be checked whether there is another bus awaiting for which Algorithm 2.6 should be immediately executed

2.2 ABC approach

In the previous section we saw that the event-scheduling approach requires that each event routine explicitly identifies the subset of conditional events which can be triggered as a consequence of a time event occurrence As such relationships may be difficult to follow in a complex system, a modeler can turn into the activity-scanning approach in which all conditions, simple or complex, that allow an event to occur are explicitly enumerated and then scanned by the simulation monitor It makes this approach simple in concept and leads

to simulation models that are easy to understand and maintain The repeated scanning of conditions, however, deteriorates the computational efficiency of

a simulator Clearly, a more effective mechanism for handling both types of events would greatly improve the power of simulation To meet this problem, a

"three phase" or "ABC" approach was proposed It tries to integrate the scheduling and the activity-scanning approach to imitate the process behavior

event-by keeping the main advantages of both techniques

The control structure of the ABC simulation executive consists of the lowing three phases:

fol-• A: the simulation time Advance phase,

• B: execution of event routines associated with all the Bound (i.e., certain

to happen) events that have the same earliest activation time,

• C: scanning of Conditions that trigger successive conditional events Phase A is essentially the same as that of the event-scheduling strategy In other words, the ABC method maintains a simulation agenda (or an event list), and its simulation executive works in a fashion similar to that of Algorithm 2.1 The time event routines, however, are exactly the same as those used in the activity-scanning approach (see section 1.3), that is, with no concern for any consequences Therefore, during phase B, these procedures just refer to simple events and do not evaluate any conditions which may cause the conditional events to occur Finally, the whole collection of conditions is examined during phase C in order to see if, based on the system state just modified by the time events, the conditional event routines can be invoked Scanning to check if any

conditional events can be triggered has to be carried on until no additional events may occur Algorithm 2.8 summarizes the above steps

ALGORITHM 2.8: ABC APPROACH

1: Initialize the model

2: If the simulation period expired or other stopping conditions are satisfied, terminate the simulation

3: Advance the simulation clock to a value provided by a time indicator of the earliest event scheduled to occur

4: Invoke an event routine corresponding to this earliest event

5: Set the NO-EVENLTRIGGERED flag

6: Scan all state events and for those among them whose occurrence tions are satisfied, invoke the corresponding event routines and reset the NO_EVENT_TRIGGERED flag

condi-7: If the NO_EVENT _TRIGGERED flag is reset, return to step 5

8: Remove the first event notice from the event list and go to step 2

Benefits of the ABC approach gradually diminish with the increasing ber of conditions that have to be checked during phase C In particular, plenty

num-of time can be wasted due to the overhead num-of repetitive scans across rare tions that ideally should only be tested when a time event affecting an interest-ing part of a system occurs Such conscious appreciation of entity interactions might lead to a superior model structure over the conventional techniques Un-fortunately, it is difficult to incorporate such information in a general way Nev-ertheless, several attempts have been made to group conditional events with all time events with which they share some system's entities Consequently, only those conditional events that are linked with the currently being executed time events are considered as potentially active Needless to say, an attempt to group together and order time and state events pertaining to a common object seems to be the most natural way of describing what happens to a single entity through the course of its life cycle In fact, this is precisely the focal point of

condi-a process-intercondi-action methodology thcondi-at we will present in Chcondi-apter 4

2.3 Events versus activities

Having detailed the basics of three simulation strategies, we can see now that the choice of a particular approach is not straightforward as all have com-plementary strengths and weaknesses It is not clear, for instance, whether there are any differences between these approaches with respect to their ability

26 2 Event scheduling

to represent any given model Because of this ambiguity, diffe~ences between the simulation techniques are often perceived as a matter of efficiency, flexi-bility, convenience, security, eloquence and familiarity Nevertheless, despite equivocal conclusions many comparisons arrive with, a few important aspects and trade-offs should be pronounced In particular, applicability of event- and activity-oriented approaches to model some peculiar environments is of special interest The remainder of this section is based mainly on comparison presented

by Evans [18]

Perhaps the most obvious criterion to differentiate the event-oriented and activity-oriented world views is the number of events that a simulator has to cope with The activity-scanning approach is useful when there are a few time and state events However, as the size of the model grows, the inefficiency re-sulting from repeatedly scanning conditions cannot be ignored In this case the event-scheduling approach offers presumably better performance It depends mainly on data structures used to implement the simulation agenda The next chapter is entirely devoted to this subject A compromise introduced by the ABC technique has to be also carefully examined in order to avoid scenar-ios in which advantages of employing event lists can be overshadowed by an excessively long list of conditions to scan

The inherent efficiency of event-based models results from leaving the sponsibility of deciding when conditional events should take place to the pro-grammer It is thus relatively easy to develop software that produces some meaningful output, but in fact it fails to capture accurately behavior of a real system it is supposed to mimic In other words, the interdependency of events makes the simulation model difficult to write, understand and maintain The activity-scanning approach offers a much safer methodology, according to which it tries to invoke all conditional events after state changes caused by time events It is especially tempting to apply it in situations which require complex assignments of resources based on logical conditions We have to pay, unfortunately, for this security: the technique tends to be inefficient for larger models, as discussed earlier

re-Moreover, the activity-scanning approach is not completely reliable sider changes in system state caused by conditional events rather than time events The latter case is inherently handled by the algorithm The former one, however, may lead to errors if inappropriately programmed For example,

Con-a sequence of events in which previously occupied resources become Con-avCon-ailCon-able, enabling another event to occur, may not be executed correctly if the avail-ability of the resource is tested earlier in the same sequence One solution, presented in sections 1.3 and 2.2, is to repeat phase C until no more state events are possible It might be, sometimes, difficult to guarantee that these repetitions will ever terminate A classical deadlock problem may serve here

as an example It would be difficult to detect a state like that, and therefore

again it is left to the programmer to take necessary precautions to avoid such situations

Another problem with origins in phase C is related to the order of scanning the conditional events This order is imposed by a user and in certain appli-cations may lead to "unfair" distribution of resources Assume there are two state events with the same triggering conditions Clearly, the second event will

be invoked only if the first one is, implicitly implying a sequential relationship between these events - a phenomenon that may not be desired in a simulation model A straightforward solution is to replace phase C with three scans The first scan would select those conditional events that can be triggered based on their condition lists Subsequently, those events would be further examined in order to work out a "fair" allocation of available resources Finally, event rou-tines corresponding to conditional events which have received resources would

be invoked As far as the implementation is concerned, the approach in which

an equitable distribution in all possible circumstances is described does not seem to be feasible Imposing priorities on the conditional events may oc-casionally resolve the problem Unfortunately, only systems employing fixed priorities can be simulated in this way as, more frequently, priorities depend

on the nature of the available resources That brings us back to the original distribution dilemma

In summary, the following facts can be highlighted:

• the event-scheduling approach is employed to deal with the significant number of events existing in the system and, though not easy to compre-hend, offers higher run-time efficiency,

• the use of activity-scanning approach is beneficial whenever there is high interdependence between events and testing of the global system state is required; this more self-contained modeling fashion is achieved, however,

at the price of lower computational efficiency

CHAPTER 3

Event lists THE way the event list is

orga-nized and manipulated affects significantly the efficiency of event-oriented simulators Actions involv-ing the simulation agenda include finding and removing the most im-minent event from the list, insert-ing a new event into the list (event scheduling), removing the notice as-sociated with a given event type from the list (event canceling), or relocating an event notice in the list (event re-scheduling) Several implementations of the event lists have been proposed over the years

in order to carry out all these erations as quickly as possible given the number of events that have to

op-be scanned at every access to the simulation agenda In this chapter

we will e.xamine some of these lutions altogether with their worst case time complexity and the av-erage performance estimated based

so-on both theoretical and tal results

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

© Kluwer Academic Publishers 1999

3.1 Doubly linked linear list

Before discussing implementation details of any particular event list tions, we will introduce a generic framework for this problem A framework is

realiza-a set of clrealiza-asses realiza-and functions threaliza-at together provide realiza-a rough outline of realiza-a solution

to a given problem without going into detail Clearly, the central element of any event list implementation is the concept of event itself An event will be represented by an object of the following class event (in the remaining parts of the book we will be using C++ [7], [83] as the programming and presentation platform whenever it seems to be the best choice):

class event {

public: double event-time;

void virtual execute 0 = 0;

event (double time) : evenLtime (time) {}

if the same event routine is associated with various objects of the same type These further event attributes can be added then to those classes which detail successive event descriptions

In order to instantiate the event list, we will need another object pointing

to the set of pending events This object will use a member variable of another class, defined as follows:

template <class object> class link;

class evenLiist {

public: evenLiist 0;

event* first 0;

event* remove_first 0;

void schedule (event*);

void reschedule (event*);

void cancel (event*);

bool empty 0;

private: link <event>* head;

};