discrete-event simulation concepts and event scheduling algorithm

DISCRETE-EVENT SIMULATION CONCEPTS and

EVENT SCHEDULING ALGORITHM

Discrete Event Simulation

Is concerned with modelling of a system as it evolves over time by a representation in which the system variables change at discrete points on time

Characteristics:• the passage of time is a part of simulation (Dynamic)

• usually contains random elements (Stochastic)

Discrete-Event Simulation Concepts

• System: A collection of entities (e.g. people and machines) that interact together over time to accomplish one or more goals

• Model: An abstract representation of a system, usually containing structural, logical, or mathematical relationships that describe a system in terms of its state, entities and their attributes, sets, processes, events, activities and delays.

• System State: A collection of variables that contain all the information necessary to describe a system at any point in time


• Entity: Any object or component in a system which requires explicit representation in the model (e.g. a server, a customer, a machine)

• Attributes: Properties of a given entity (e.g. priority of a waiting customer, the routing number of a job through a job shop)

• List: A collection of (permanently or temporarily) associated entities, ordered in some logical fashion (e.g. customers currently waiting in a queue ordered according to a queueing discipline) [sets, queues, chains]


• Event: An instantaneous occurrence that changes the state of a system (e.g. arrival of a new customer)

• Event Notice: A record of an event to occur at the current or some future time, along with any associated data to execute the event (at a minimum: event type, event time)

• Event List: A list of event notices for future events, ordered by time of occurrence, also know as future event list (FEL)


• Activity: A duration of time of specified length (e.g. service time), which is known when it begins. – deterministic– random– function of state variables or entity attributes

(deterministic/random)

• Delay: A duration of time of unspecified length, which is not directly known until it ends (an event triggers the end) [conditional wait] (e.g. time a customer spends in a waiting line)

• Clock: A variable representing simulated time (CLOCK)

Events and System State

C2

A2

C1

A1

0S1

S2

Timet1t2 t3 t4

0Time

t1 t2 t3 t4

L(t)

1

2

0Time

t1 t2 t3 t4

1

B(t)

Example: A Doctor’s Office


• System State– Q(t), the number of patients waiting to be examined at time t

– B(t), 0 or 1 indicate the doctor being busy or not at time t

• Entities– Neither the patients nor the doctor need to be explicitly

represented, except in terms of state variables unless certain patient averages are desired

• Events– Patient arrival event

– Examination completion event


• Activities:– Interarrival time

– Examination time

• Delay– A patient’s wait until the doctor is free

• What more to specify?– Consequences of events ( a logical description)

– Activity lengths (deterministic, probabilistic, a function)

– Triggers for the beginning and the end of delays

– Initial conditions (System state at time 0)

Time Advance

Advancing simulated time

Fixed time increments Variable time increments

Advances the clock by one time unit & examines the events and system state

(ACTIVITY SCANNING) ApproachNot an efficient approach for most systems

Advances the clock to the most imminent event time & examinethe system state

EVENT ORIENTATION

EVENT SCHEDULING

NEXT EVENT METHOD

Variable Time Increment

• Moves the system from one event time to the next event time

• Produces a sequence of system snapshots (or system images) which represent the system evolution through time

• System evolution can be represented by these snapshots since between events the system does not change

Variable Time Increment

• Snapshots at each event time include:– The current state of the system

– FEL for all activities currently in progress (their completion times)

– The current membership to all lists

– The status of all entities

– Current values of all cumulative statistics and counters

• Thus only the last snapshot is needed to construct the next snapshot (Markovian property)

Future Events List (FEL)

• In real world, the future events are not scheduled but merely happen at a certain time (random arrivals, failures)

• Yet these event times can be modeled by a statistical characterization (distribution) of the time to next occurrence (arrival, failure)

• In simulation activity lengths are determined by obtaining a random sample from the distribution associated with it.

• Completion Time = Starting Time + Activity Length

• The activity completion time is determined as the activity begins and the activity completion event is added to FEL.

Event-Scheduling

• At any given time t, the FEL contains all previously scheduled future events and their associated event times.

• The FEL is ordered by event time, which means that the events are in chronological order.

t < t1 <= t2 <= t3 <= . . . <= tn

• The time t is the value of CLOCK, current value of simulated time

• The event associated with time t1 is called the imminent event, which means the next event to occur.

• The snapshot at CLOCK= t is updated

Event-Scheduling

• Simulation time advances to CLOCK= t1

• Imminent event notice about t1 is removed from the FEL

• The event is executed

• The execution creates a new snapshot of the system at t1

based on the previous snapshot and the nature of the event• This snapshot may include new future event notices added

to FEL or not(depends on the nature of the executed event)• And the cycle continues by repeating the same steps after

advancing CLOCK to the time of the new imminent event until the end of the simulation

System Snapshot

CLOCK

System

State . . . Future Event List . . .

t (5,1,6) (4, t1) – Type 4 event to occur at t1

(1, t2) – Type 1 event to occur at t2


.

.

.

(3, tn) – Type 3 event to occur at tn

System Snapshot

CLOCK

System

State . . . Future Event List . . .

t1 (5,1,7) (1, t2) – Type 1 event to occur at t2

(2, t*) – Type 2 event to occur at t*


.

.

.

(3, tn) – Type 3 event to occur at tn

Future Event Generation

• Exogenous Events (Events that are not caused by the internal dynamics of the system. They happen outside the system, yet effect the evolution of the system):– The events that are in the initial system snapshot at time 0 (specified

by initial conditions). These are placed to the FEL before the simulation starts.

– Other external events such as arrivals to a queueing system. These events are generated using a technique called Bootstrapping

• This technique is based on each event causing another event of the same type

• The time between the events is an activity (a) (It may be a r.v.)• When an event occurs, schedule the next event in the same stream of

events and place the associated notice in the FEL• This next event in the stream is scheduled at t* = t + a

Bootstrapping

Future Event Generation

• Endogenous Events– Service-completion event

• Each time a customer starts service a service-completion event is scheduled (End of an activity)

• Note that service-start event is never scheduled, it is called a conditional event. A service-start occurs within an arrival or a service-completion event.

• The events that are placed on FEL are called primary events.

– Uptimes and downtimes for a system subject to breakdown

• End-of-uptime and end-of-downtime events (primary events)• Similar to bootstrapping

Stopping Simulation Runs

• At time 0, schedule a stop-simulation event at a specified future time TE ( Simulation runs in the interval [0, TE] )

• Stop the run at the time of occurrence of some specified event E. (The completion of the 1000th service at the server)

World Views

• When using a simulation package or even when doing hand simulation, a modeler adopts a world view or orientation for developing a model.

• The most prevalent world views are1. the event-scheduling world view2. the process-interaction world view3. the activity-scanning world view.

• Particular simulation packages (e.g. Arena) usually support one of these world views.

Event-Scheduling World View

• Concentrates on events and their effects on system state

• It makes use of the Future Event List and variable time increments

• This is the approach we have just discussed

• It is a very flexible approach using which any system can be simulated

• It requires lots of mechanisms (e.g. FEL handling) to be coded, which may slow down the development of the simulation model for very simple systems.

Event-Scheduling World View

• We have not used this method on any example last week. We are going to do it now on the doctor’s office system

• This is the world view that is usually used when the simulation program is directly coded on a general-purpose programming language such as Java.

• We are going to show its implementation in Java next week

• It would be hard to use this world view with EXCEL since the implementation of the standard mechanisms of Event-Scheduling is not easy in such environments (it could be done with extensive use of EXCEL macros)

Process-Interaction World View

• Models the system in terms of processes• Concentrates on entities, and their life cycles as

they flow through the system, demanding resources and queueing to wait for resources.

• A process is a time-sequenced list of events, activities and delays that define the life cycle of one entity as it moves through a system.

• Some activities might require resources that are limited, which may cause delays in the process


• This is the world view we adopted for the hand simulation of the doctor’s office system last week


• This approach is easier for the modeler since people usually perceive the systems in terms of the processes the entities experience

• But this approach is usually harder to implement directly, especially when the systems to be simulated are complex

• Thus, many simulation packages (including ARENA) use this view for the modeler to describe the system (user-interface), but an event-scheduling approach is used operationally to perform the simulation run, hidden from the user.

Activity-Scanning World View

• Concentrates on activities and conditions that allow them to begin

• It uses fixed time increments• At each clock advance, the conditions for each

activity are checked, and if the conditions hold, then the corresponding activity starts.

• The (M,N) inventory system simulation we used last week used activity-scanning approach. The time increment used was a day.

Activity-Scanning World View

• Simple in concept and leads to modular models that are easier to maintain, understand and modify.

• The repeated scanning (at each time increment) results in slow runtime on computers

• The pure activity-scanning approach has been modified by what is called the three-phase approach, which combines the features of event-scheduling with activity scanning to allow for variable time advance. (ARENA uses this as well)


• System State (Q(t),B(t))– Q(t), the number of patients waiting to be examined at time t

– B(t), 0 or 1 indicate the doctor being busy or not at time t

• Entities– (Pi,t), representing patient Pi who arrived at time t

• Events– Patient arrival event (A)

– Patient departure event (D)

– Stopping event (E)


• Event Notices– (A,t,Pi) represents the arrival of patient Pi at future time t– (D,t,Pi) represents the departure of patient Pi at future time t– (E,19) represents the simulation-stop event at future time 19

• Activities– Interarrival time, described in a following table– Service time, described in a following table

• Delay– Patient time spent in the waiting room

• Set– “Waiting Room”, the set of all patients in the waiting room– “Doctor’s Room”, the set of all patients in the doctor’s room

Arrival Event

Generate service time s & schedule new departure event at t+s

B(t)=1 ?

YESNO

Arrival event occursat CLOCK = t

Q(t)=Q(t)+1B(t)=1

Generate interarrival time a; schedule next arrival event at t+a

Collect statistics

Return control to time-advance routineto continue simulation

Service Completion Event

Q(t) 1 ?YESNO

Departure event occursat CLOCK = t

Q(t)=Q(t)-1B(t)=0

Generate service time s; schedule new departure at t+s

Collect statistics

Return control to time-advance routineto continue simulation

Input Data (Arrival)Interarrival time Probability Cumulative probability

1 0.30 0.30 2 0.25 0.553 0.20 0.754 0.15 0.905 0.07 0.976 0.03 1.00

0.00

0.05

0.10

0.15

0.20

0.25

0.30

1 2 3 4 5 6

Probability

0.00

0.20

0.40

0.60

0.80

1.00

1 2 3 4 5 6

Cumulative probability

Input Data (Service)Service time Probability Cumulative probability

1 0.25 0.25 2 0.25 0.503 0.25 0.754 0.25 1.00

0.00

0.05

0.10

0.15

0.20

0.25

1 2 3 4

Probability

0.00

0.20

0.40

0.60

0.80

1.00

1 2 3 4

Cumulative probability

Generation of interarrival timesInterarrival time Cumulative probability Random digit assignment

1 0.30 01-302 0.25 31-553 0.20 56-754 0.15 76-905 0.07 91-976 0.03 97-00

Customer No. Random digit Interarrival time

1 - -2 38 2

3 84 4

4 15 1

5 50 2

6 99 6

… … …

Label1

Generation of service timesInterarrival time Cumulative probability Random digit assignment

1 0.25 01-252 0.25 26-503 0.25 51-754 0.25 76-90

Customer No. Random digit Service time

1 28 22 24 1

3 73 3

4 46 2

5 04 1

6 85 4

… … …

Statistics

Discrete time statistics Continuous time statistics

(Observational data) Time dependent dataContinuous statisticsTime weighted statistics

Defined relative to the collection ofrandom variables with a discrete time index (Observational data)

Defined on the random variables {Q(t)},{B(t)}, each of which is indexed on the continuous time parameter̂

NotationTQ: time integral of Q(t) (from 0 to T)TB: time integral of B(t) (from 0 to T)TL: time integral of (B+Q)(t) (from 0 to T)R: total response time for patients (time-in-the-system) who departed by TW: total waiting time of patients (time-in-the-queue) who departed by TN: total number of departures by T

Example: calculation of TL : TLnew=TLold+(T-Told)(Bold +Qold)

T B+Q TL

0 0

2

3

0+(2-0)*1=2

2+(3-2)*1=3

6 3+(6-3)*0=3

19 13+(19-15)*1=17

1

1

0

1

0

Simulation table

Clock Q(t) FEL R N

TQB(t) W TB

17 4 6 4 13

0

2

3

6

7

9

11

12

15

19

1

1

0

1

1

1

1

0

1

0

0

0

0

0

1

1

0

0

0

0

(P1,0)

(P2,2)

(P3,6)

(P3,6)

(P4,7)

(P5,9)

(P6,15)

(P4,7)

(P5,9)

(A,2,P2),(D,2,P1),(E,19)

(D,3,P2),(A,6,P3),(E,19)

(A,6,P3),(E,19)

(A,7,P4),(D,9,P3),(E,19)

(A,9,P5),(D,9,P3),(E,19)

(D,11,P4),(A,15,P6),(E,19)

(D,12,P5),(A,15,P6),(E,19)

(A,15,P6),(E,19)

(D,19,P6),(E,19),(A,24,P7)

(A,24,P7)

0

2

3

3

3

6

10

13

13

17

0

0

0

0

0

2

4

4

4

4

0

1

2

2

2

3

4

5

5

6

0

0

0

0

0

2

4

4

4

4

0

2

3

3

4

6

8

9

9

13

DR WR

Another Example of Hand Simulation using Event-SchedulingFrom Chapter 2 of the Arena Book

ArrivingBlank Parts

DepartingFinished Parts

Machine(Server)

Queue (FIFO) Part in Service

4567

44

Model Specifics• Initially (time 0) empty and idle• Base time units: minutes• Input data (assume given for now …), in minutes:

Part Number Arrival Time Interarrival Time Service Time1 0.00 1.73 2.902 1.73 1.35 1.763 3.08 0.71 3.394 3.79 0.62 4.525 4.41 14.28 4.466 18.69 0.70 4.367 19.39 15.52 2.078 34.91 3.15 3.369 38.06 1.76 2.37

10 39.82 1.00 5.3811 40.82 . .

. . . .

. . . .• Stop when 20 minutes of (simulated) time have passed

System

Clock

B(t)

Q(t)

Arrival times of custs. in queue

Event calendar

Number of completed waiting times in queue

Total of waiting times in queue

Area under Q(t)

Area under B(t)

Q(t) graph B(t) graph

Time (Minutes) Interarrival times 1.73, 1.35, 0.71, 0.62, 14.28, 0.70, 15.52, 3.15, 1.76, 1.00, ...

Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...

Simulation by Hand:Setup

0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

System

Clock 0.00

B(t) 0

Q(t) 0


<empty>

Event calendar [1, 0.00, Arr] [–, 20.00, End]

Number of completed waiting times in queue 0

Total of waiting times in queue 0.00

Area under Q(t) 0.00

Area under B(t) 0.00



Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...

Simulation by Hand:t = 0.00, Initialize

0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

System

Clock 0.00

B(t) 1

Q(t) 0


<empty>

Event calendar [2, 1.73, Arr] [1, 2.90, Dep] [–, 20.00, End]







Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...

Simulation by Hand: t = 0.00, Arrival of Part 1

0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

1

System

Clock 1.73

B(t) 1

Q(t) 1


(1.73)

Event calendar [1, 2.90, Dep] [3, 3.08, Arr] [–, 20.00, End]







Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...


0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

12

System

Clock 2.90

B(t) 1

Q(t) 0


<empty>








Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...

Simulation by Hand: t = 2.90, Departure of Part 1

0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

2

System

Clock 3.08

B(t) 1

Q(t) 1


(3.08)








Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...


0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

23

System

Clock 3.79

B(t) 1

Q(t) 2


(3.79, 3.08)








Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...


0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

234

System

Clock 4.41

B(t) 1

Q(t) 3


(4.41, 3.79, 3.08)







Time (Minutes)

Interarrival times 1.73, 1.35, 0.71, 0.62, 14.28, 0.70, 15.52, 3.15, 1.76, 1.00, ...

Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...


0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

2345

System

Clock 4.66

B(t) 1

Q(t) 2


(4.41, 3.79)







Time (Minutes)


Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...


0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

345

System

Clock 8.05

B(t) 1

Q(t) 1


(4.41)







Time (Minutes)


Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...


0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

45

System

Clock 12.57

B(t) 1

Q(t) 0


()







Time (Minutes)


Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...


0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

5

System

Clock 17.03

B(t) 0

Q(t) 0

Arrival times of custs. in queue ()

Event calendar [6, 18.69, Arr] [–, 20.00, End]






Time (Minutes)


Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...


0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

System

Clock 18.69

B(t) 1

Q(t) 0

Arrival times of custs. in queue ()

Event calendar [7, 19.39, Arr] [–, 20.00, End] [6, 23.05, Dep]






Time (Minutes)


Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...


0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

6

System

Clock 19.39

B(t) 1

Q(t) 1


(19.39)

Event calendar [–, 20.00, End] [6, 23.05, Dep] [8, 34.91, Arr]






Time (Minutes)


Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...


0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

67

Simulation by Hand: t = 20.00, The End

0

1

2

3

4

0 5 10 15 20

012

0 5 10 15 20

67

System

Clock 20.00

B(t) 1

Q(t) 1


(19.39)

Event calendar [6, 23.05, Dep] [8, 34.91, Arr]






Time (Minutes)


Service times 2.90, 1.76, 3.39, 4.52, 4.46, 4.36, 2.07, 3.36, 2.37, 5.38, ...

Simulation by Hand:Finishing Up

• Average waiting time in queue:

• Time-average number in queue:

• Utilization of drill press:

part per minutes 53261715

queue in times of No.queue in times of Total

..

part 79020

7815value clock Final

curve under Area.

.)( tQ

less)(dimension 92020

3418value clock Final

curve under Area.

.)( tB

Complete Record of the Hand Simulation

discrete-event simulation concepts and event scheduling algorithm

Documents