General Simulation Principles



Refer to Chapter 3
Very Important Chapter
Section 3.1


Memorize all basic definitions & be able to
discuss thoroughly
Also includes additional material not in
book
1
Discrete Event Systems






Discrete systems – focus of course
Framework for modeling systems
General Terminology
General Purpose Languages vs.
Simulation Packages
Dynamic (over time)
Stochastic (randomness)
2
*Terminology (pg. 89)






System
Model
System State
Entity
Attributes
List






Event
Event notice
Event list (FEL)
Activity
Delay
Clock
3
Terminology
System
Model
Collection of one or more Abstract representation of
a system, in form other
entities interacting
than the system itself
together over time to
accomplish some goal
 Includes relationships
that describe system
or goals




School
Airport
Gas Station
Human Body

(state, entities,
activities, events,
processes, delays, etc.)
Mathematical, physical,
computer program, etc.
4
Terminology
System State
Entity
Collection of variables
necessary to fully
describe the system at
a point in time
 Number-in-queue
 Number-of-servers
 Status-of-servers
Object or component of
system that requires
representation in the
model; an object of
interest
 Customer
 Server
 Queue
5
Terminology
Attributes
Attribute Values
Properties of an entity
that describe it
Actual values assigned to
an attribute at a
particular point in time
1.
2.
3.
4.
5.
Length (of queue)
Capacity (of queue)
Status (of server)
Speed (of server)
Type (of customer
1.
2.
3.
4.
5.
0 to Capacity
1, 2, 3, …
Busy, Idle, On-Break
Num. Services/Time
Business, Personal
6
Terminology
List
Event
Collection of associated
entities, ordered in
some manner
Instantaneous occurrence
that changes the state
of system



FIFO queue of
customers
Priority queue of
customers
Available servers



Arrival of customer
Completion of service
Breakdown of
machine
7
Terminology
Event Notice
Event List (FEL)
Record of event to
occur at current or
future time + data
necessary to execute
it; event type & time
 Arrival, 10
 End-service, 30




Future Event List
List of Event Notices
ordered by time
Typically a linked list
Is the “driver” for a
simulation program
8
Terminology: ACTIVITY

Duration of time of specified length known
when begins; scheduled & desired;
Unconditional wait
Duration determination






Deterministic: always 10 minutes
Statistical: Uniform (1,10)
Functional: based on attribute (age, capacity)
Begins & Ends with an Event

Service time: Begin Service, End Service
9
Terminology: DELAY

Duration of time of unspecified, indefinite
length not known until it ends; duration
determined by system conditions; i.e. by
other events or activities; not scheduled
or desired

Conditional wait

Time waiting in queue
Time waiting on any other event

10
Terminology: CLOCK



Variable representing simulated time
Elapsed time in smallest time unit
necessary
Updated with each new event time as
the event is executed
11
Primary vs. Secondary Events

Primary Event




Occurrence is scheduled
Placed on FEL
Arrival, Complete Service
Secondary Event



Occurrence due to some other event or
condition
Not on FEL
Enter or Leave queue, Begin service
12
Waits
Conditional vs. Unconditional


Conditional Wait = Delay
 Caused by some other condition
 In Queue
Unconditional Wait = Activity
 Scheduled
 Service time
13
Example 2.6 – page 51
Computer technical support center is
staffed by 2 people, Able & Baker, who take
calls & answer questions to solve computer
problems. Able is more experienced &
faster. If both are idle, Able takes call. If
both busy, caller placed on hold & calls are
answered in the order received.
14
State components from Example 2.6






System
Model
System State
Entity
Attributes
List






Event
Event notice
Event list (FEL)
Activity
Delay
Clock
15
Dynamic Relationships &
Interactions Between Components


Consider the questions on page 91.
Answers are necessary to
determine correct model.
16
Time Management Methods

Determines how CLOCK is managed
(updated)
Time Slice Approach
 Continuous Systems
vs.
Critical Event Approach
 Discrete Event Approach
17
Time Slice Approach





Simulation is controlled by time
Clock is incremented by fixed number of
time units (N) each time
State of system is based on everything that
occurred in past N time units
Typical for simulating continuous systems
Able to easily compress or expand time by
varying N
18
Critical Event Approach




Simulation is controlled by occurrence of
“critical events”
Clock is incremented (updated) by
variable amounts as determined by
occurrence of next critical event
Critical events cause specific changes in
state of the system
Used for discrete systems
19
Time Slice vs. Discrete Event:
Examples
Discuss clock management & system
updates…
 Continuous



Release of pollutants into a river
Flood of city due to rain storm
Discrete


Use of student computer lab
Baggage check-in counter at airport
20
Future Events List (FEL)






A set of all events that have been
scheduled to occur at a future time
Arrange in chronological order
Linked List
t<= t1<= t2 <= t3<=…tn
t is value of clock
t1 is the imminent event
21
Future Events List

What are implementation
options? Pros & Cons?


Array
 Ordered, Unordered
Linked List
 Ordered
22
Event Scheduling –
Time Advance Algorithm (main)
1. Remove imminent event
2. Advance Clock
3. Execute imminent event: update state
4. Generate future events (as
necessary) & Place on FEL
5. Update Cumulative Statistics &
counters
6. Repeat (1-5) until simulation ends
23
Stop Event
An event whose occurrence causes
termination of the simulation
EXAMPLES:
1. Clock time exceeds value N
2. Number of events exceeds value N
3. Queue reaches length L
~~~ Others ???

24
Critical Events



In a basic queuing system,
there are 2 critical events.
What are they?
 1. ?????
 2. ?????
These are events in FEL
25
Arrival Event Processing
ARRIVAL*
No
BEGIN SERVICE*
Server
BUSY?
Yes
ENTER QUEUE
26
Complete Service Event Processing
Complete
Service
Server Idle
NO
Another
IN Q?
YES
Remove
from Q
Begin
Service*
27
Generating Events

Initialize



Next Arrival


Stop event (if stopping on TIME)
First Arrival (of each type)
As an Arrival is removed
Complete Service
As an arrival Begins Service
Note * on flowcharts  new event generated

28
Queuing System Components

Queue




Calling population
Discipline
Capacity
Arrivals


Times, rates
Nature of
29
Queuing System Components

Services



Times
Nature of
System





Number of queues
Number of servers
State variables
Capacity
Nature of Arrivals/ Departures
30
Characteristics



Key elements: Customers and Servers
Calling Population: set of potential
customers - finite vs. infinite
System Capacity: the total number which
may wait and be served at any given time
 Finite vs. infinite
 Arrival rate vs. effective arrival rate
31
Characteristics (cont.)

Arrival Process





Characterized by inter-arrival times of
successive customers
Scheduled vs. random
1 at a time or batches
Poisson Arrivals – independence
Examples
32
Introduction to Queuing Models



Queue = Waiting line
Customer = any entity that may
request “service” from a system
Typical Measures of System
Performance



Server utilization
Length of waiting lines
Delays of customers
33
Queuing Models (cont.)

Input Parameters
 Arrival rates
 Service demand
 Service rate
 Number & arrangements of
servers
34
Start-up vs. Wind-down Conditions

Start-up



What is state of system when simulation
starts? Empty? Full?
Initialization?
Wind-down


How is simulation stopped?
Are customers left in system? What do you
do with them?
35
Queuing Models


Mathematical Analysis vs. Simulation Analysis
Topics to be addressed






Dynamic behavior
General characteristics
Meaning and relationships of the important
performance measures
Estimation of performance measures
Effect of varying input parameters
Mathematical solutions to basic models
36
Queue Attributes






# of Phases or Stations (sequential)
# of Channels (parallel)
# of Servers
Blockers-non blocking stations
Capacity
Discipline (FIFO, LIFO, Priority, etc.)
37
Queue Behavior



Balk: upon arrival, customer decides
not to enter the system
Renege: after being in queue for
some period of time, customer leaves
system
Jockey: to change queues after
entering one queue
38
Queue Behavior


Priority: a number affecting the
processing of customers
Preempt: to stop serving one
customer before completion in order
to begin serving another customer
39
Single Server-Single Queue
Arrive
Queue
Server
Depart
40
Parallel Servers – Same Type
Single Queue
S
Arrive  Q
Depart
S
41
Parallel Servers & Queues
Different Servers
A1
Q1
S1
D
A2
Q2
S2
D
A1 & A2 have different arrival rates.
S1 & S2 are different types w/ different rates.
42
Parallel Servers
S1
Arrive
Depart
Q
S2
S1 & S2 provide same service but may have different service
rates. Choice between S1 & S2 may be rule-based or
43
random.
Sequential Servers
A
Q1
S1
Q2
S2
D
Each customer must receive both services.
44
Goals of Simulation

Common Questions
1. Average Queue Length?
2. Amount (%) of server Idle Time? (Utilization)
3. Mean Waiting time of Customers?
4. Others?
Consider
Information Cost Value
45
Simulation Methodology
1.
2.
3.
4.
5.
Plan
Model
Validate & Verify
Simulate
Apply
46
Simulation Methodology
1. Plan
 Define problem & factors that affect the
system
 Estimate resources needed to observe
system and collect data
 Determine feasibility of continuing
 Consider reduction
 Collect info.- interviews, literature search,
observation
47
Methodology (cont.)
Model
2.

Construct a REPRESENTATION
consisting of the minimal set
possible
48
Methodology (cont.)
3.
Validate and Verify



Validate: to ensure that the model accurately
represents the system
Verify: to ensure that the program accurately
represents the model
How? – historical data & predictions


Statistical tests
Sensitivity Analysis

Reasons for Failure to validate or verify
49
Methodology (cont.)
Apply
4.




What is output?
How should the results be
interpreted?
How can we use the results?
How can we communicate the results
to others?
50
Steady State




The system is running in such a way that
state variables (statistics) experience
only small variations
Must consider “start- up” & “wind- down”
conditions
How can steady state be recognized?
Why do we care?
51
Conway’s Method
(Determining Steady State)



Take snapshots of some stats –
independent, not cumulative
Rule: throw out first intervals such that
they are min or max. When first interval is
not, then in steady state.
Limits: Sensitive to interval size.
Which stats should be considered?
52
Emshoff & Sisson Method
(Determining Steady State)


Apply Conway to reduce the number of
intervals. Look at the individual points in
the set. Determine the % of values above
& below the mean. Use Chi Square test to
determine if the next interval is likely to
come from the previous cumulative
population.
Allows for gradual changes in data, but
spots dramatic or sudden changes.
53
World Views (3)
1.
2.
3.



Event Scheduling
Process Interaction
Activity Scanning
Way we view of the model & Interactions
Languages may favor one view
View may be hidden from user
54
Event Scheduling
(variable time advance)



Approach we have been discussing
Schedule & Process each individual event,
updating System State as each is
processed
Typical approach for simulation in high-level
language


Main: loops, removing events from FEL &
calling functions
Functions: begin-service, enter-queue, endservice, etc.
55
Process Interaction
(variable time advance)




View entities in terms of process they
follow; their life cycle
Process: time sequenced list of events,
activities, & delays, including demands for
resources, that define the life cycle of entity
as it moves through system
Underlying support is likely event-based
Simscript language
56
Process Example
Customer A Definition






Arrive at business
Get in Queue A
Request Service A
Receive Service A
End Service A
Leave business
Customer B Definition








Arrive at business
Get Cart
Get in Queue A
Request Service A
Receive Service A
End Service A
Return Cart
Leave business
57
Activity Scanning (time-slice)





Uses fixed time increment & rule-based
approach to determine when activities begin
At each time advance, conditions for each
activity checked, if true then activity starts
Simple, can be modular, easily maintainable
Repeated scanning can make simulation
run slowly
GPSS
58
Other World Views



Hybrids
Some languages, systems support
multiple views
Many simulation environments “hide”
approach with GUI
59
Next!
Read Implementation Paper posted on
Class Web Site
60