Discrete Event Simulation Modeling

Overall Plan of Simulation and Modeling I Chapters
Introduction to Simulation Discrete Simulation Analytical Modeling Modeling Paradigms Input Modeling Random Number Generation Output Analysis Continuous and Hybrid Simulation Simulation Software
Simulation and Modeling I
Discrete Simulation 1
Discrete Simulation Goals

understand event list processing as the core of discrete simulation use of high-level simulation environments simulation at the programming language level
Contents
Organization of Discrete-Event Simulation (DES) Simulation of a Single-Server Queue Hand Simulation of the Queue Simulation with AnyLogic Simulation with AutoMod Simulation with OPNET Simulation with OMNeT++ Simulation with Syntony Simulation in Java List Processing in Simulation
Organization of Discrete-Event Simulation Recall: in discrete-event simulation, events occur instantaneously at separate points in time and change the state variables Two mechanisms to advance the simulated time:
next-event time advance the simulation clock is always advanced to the time of the next event, the state variables are updated and future event times are determined, until termination is used by all major simulation software and by most people coding their model in a general-purpose language will be used throughout the lectures fixed-increment time advance the simulation clock is always advanced in increments of t time units useful for systems in which the time advances in fixed increments (e.g., economic systems with annual change, slotted communication systems)
Organization of Discrete-Event Simulation (cont.) Recall: the single-server queue (SSQ)

arrival of customers waiting room (queue) customers depart from system service unit
although this model seems simple compared with those usually of real interest, how it is simulated is actually quite representative we will use it for illustrations throughout this and later lectures
Organization of Discrete-Event Simulation (cont.) Events and times in the single-server queue
ti = time of arrival of the i'th customer (i=1,2,3,) Ai = ti ti-1 = inter-arrival time between the (i-1)st and the i'th arrivals of customers (t0 = 0) Si = time the server spends serving the i'th customer (without the customers waiting time) Wi = waiting time of the i'th customer Di = Wi + Si = time in system of the i'th customer (also often called total delay or response time of the system) ci = ti + Wi + Si = ti + Di = time i'th customer completes service and departs ei = time of occurrence of i'th event of any type
Organization of Discrete-Event Simulation (cont.) State in the single-server queue

given by the number of customers in waiting room and service unit, i.e., number of customers in system at time t: N(t) in contrast, we denote by Q(t) the number of customers in the waiting room (queue length)
Organization of Discrete-Event Simulation (cont.) Next-event time advance

the simulation clock jumps from ei to ei+1
e0
0 A1
e1
t1 A2 S1
e2
t2
e3
c1 A3
e4
t3
e5
c2 Time
S2
Organization of Discrete-Event Simulation (cont.) Fixed-increment time advance

the simulation clock jumps t time units after clock update, a check is made whether any events have occurred during the previous interval if one or more have occurred, they are considered to occur at the end of the interval and the state is updated accordingly if two or more events have occurred in the same interval, rules are required to decide in which order they are processed this complicates matters, therefore the approach is not common
e 1 t
2t
e2 e3
3t e4
4t
Time
Organization of Discrete-Event Simulation (cont.) Typical components in DES (with next-event time approach):
system state: collection of state variables necessary to describe the system at a particular time simulation clock: variable giving the current value of simulated time event list: list containing the next time when each type of event will occur statistical counters: variables used for storing statistical information about system performance initialization routine: subprogram to initialize the simulation model at time 0 timing routine: subprogram that determines the next event from the event list and then advances the simulation clock to the time when that event is to occur
Organization of Discrete-Event Simulation (cont.)

event routine: subprogram that updates the system state when a particular type of event occurs (there is one event routine for each event type) library routines: set of subprograms used to generate random observations from probability distributions that were determined as part of the simulation model (and other statistical features) report generator: subprogram that computes estimates (from the statistical counters) of the desired measures of performance and produces a report when the simulation ends main program: subprogram that invokes the timing routine to determine the next event and then transfers control to the corresponding event routine to update the system state appropriately. The main program may also check for termination and invoke the report generator when the simulation is over
Simulation and Modeling I Discrete Simulation 10
Organization of Discrete-Event Simulation (cont.) Flow of control

Initialization routine 1. Set simulation clock = 0 2. Initialize system state and statistical counters 3. Initialize event list 0 1. Invoke the timing routine 2. Invoke event routine i Event routine i 2 Library routines Generate random variates Repeatedly Main program 0. Invoke the initialization routine 1 i Start Timing routine 1. Determine the next event type, say, i 2. Advance the simulation clock
1. Update system state 2. Update statistical counters 3. Generate future events and add to event list, eventually remove others from the event list
Is simulation over? Report generator Yes
No
1. Compute estimates of interest 2. Write report
Stop
Discrete Simulation Contents

Simulation of a Single-Server Queue Consider the single-server queue with

the random inter-arrival times A1, A2, ... the random service times S1, S2, ... upon completing service of a customer, the server chooses a customer from the queue (if any) in a FIFO manner at time 0 no customers are present and the server is idle termination of simulation when n'th customer enters service
Simulation of a Single-Server Queue (cont.) Define 3 measures of system performance for SSQ
d(n) = expected mean time in system (delay) of the first n customers q(n) = expected mean queue length until n customers have been served u(n) = expected utilization until n customers have been served = expected average proportion of time that the server is busy until n customers have been served
Random characteristics of the measures

on a given run of the simulation (or on a day of the real system) the observed means depend on the inter-arrival and service times on another run of the simulation (or on a different day of the real system), there would be probably different inter-arrival and service times, leading to different means thus, the means are random variables themselves we want to estimate the expected values of these random variables
Simulation of a Single-Server Queue (cont.) Estimation of the system time / delay / response time:
from a single run of the simulation resulting in customer delays D1, D2, D3, ..., an obvious estimator of d(n) is 1 n d(n) = Di n i=1 which is just the arithmetic mean of the n Dis that were observed in the simulation as a common convention, ^ (circumflex) above a symbol denotes an estimator since the average (arithmetic mean) is taken over a finite number of values (a subcase of a countable set), this measure is an example of a discrete-time statistics the expected mean waiting time is similarly estimated from W1, W2,
Simulation of a Single-Server Queue (cont.) Estimation of the queue length:

average is now taken over continuous time, rather than over customers thus we get a continuous-time statistics let Q(t) be the queue length at time t (customers in the waiting room), T(n) the termination time of the simulation (service completion of n'th customer), and t = 0 be the starting point, then formally 1 (n) = q T(n)
T (n ) 0
Q(t ) dt
for computing it easily, let Ti be the total time during the simulation that the queue is of length i, then 1 (n) = q iTi T(n) i=0 the area can be accumulated as rectangles as the simulation progresses over time
Simulation of a Single-Server Queue (cont.) Q(t) for a possible realization with n = 5:

Q(t) 3
0
e1=0.4
1
e2=1.6
4
e8=4.0 e7=3.8 e6=3.3
6
e11=5.8 e10=5.6
9 t
Arrivals
e3=2.1
e12=7.2
Departures
e4=2.4 e5=3.1
e9=4.9
e13=8.6=T (5)
Simulation of a Single-Server Queue (cont.)

arrivals occur at times 0.4, 1.6, 2.1, 3.8, 4.0, 5.6, 5.8, 7.2 service completions occur at times 2.4, 3.1, 3.3, 4.9, 8.6 termination at T(6) = 8.6 T0 = (1.6-0.0) + (4.0-3.1) + (5.6-4.9) = 3.2 T1 = (2.1-1.6) + (3.1-2.4) + (4.9-4.0) + (5.8-5.6) = 2.3 T2 = (2.4-2.1) + (7.2-5.8) = 1.7 T3 = (8.6-7.2) = 1.4 Ti = 0 for i > 3 test:
i=0
Ti = 3.2 + 2.3 + 1.7 + 1.4 = 8.6 = T(5)

i=0
numerator:
iTi = 0 3.2 + 1 2.3 + 2 1.7 + 3 1.4 = 9.9
our estimate of the average number in queue gets: q (5 ) = 9.9 / 8.6 = 1.15
Simulation of a Single-Server Queue (cont.) Estimation of the utilization

define a busy function (an indicator function) 1 server is busy at time t B(t ) = 0 server is idle at time t then the estimate can be expressed as a continuous-time statistics, as the proportion of time B(t) is equal to 1: 1 (n) = u T(n)
T (n ) 0
B( t ) dt
Simulation of a Single-Server Queue (cont.) In the example realization we get

B(t) 1
0 Arrivals e =0.4 1 Departures
1
e2=1.6
2
e3=2.1
4
e8=4.0 e7=3.8 e6=3.3
6
e11=5.8 e10=5.6
9t
e12=7.2 e13=8.6=T (5)
e4=2.4 e5=3.1
e9=4.9
and
(5 ) = u
( 3 .3 0 .4 ) + ( 8 .6 3 .8 ) 7 .7 = = 0.90 8 .6 8 .6

Hand Simulation of the Queue Hand simulation

we step through the first steps of a simulation to illustrate the changes and data structures involved in carrying out a DES the assumed inter-arrival times are: A1 = 0.4, A2 = 1.2, A3 = 0.5, A4 = 1.7, A5 = 0.2, A6 = 1.6, A7 = 0.2, A8 = 1.4, A9 = 1.9, ... the assumed service times are: S1 = 2.0, S2 = 0.7, S3 = 0.2, S4 = 1.1, S5 = 3.7, S6 = 0.6, ... inter-arrival times and service time are consistent with running example all time quantities are expressed in the same units, whatever one unit will be (minutes, hours, ...) each figure shows the situation after the occurrence of an event, the system and the computer representation are shown in the situation after all changes have been made the status of the system is on the left side the variables of the computer representation are on the right side
Hand Simulation of the Queue (cont.)

Initialization time = 0
System state 0 Clock 0 0 0
idle
Arrival 0.4 Departure Event list
poisoning
server
Server Number Times Time status in of last of queue arrival event of queued customers
Statistical counters 0 0 0 0
Number Total Area Area served waiting under under time Q(t) B(t)
System
Computer representation

Arrival time = 0.4
System state 0.4 Clock 1 0 0.4
0.4 arrival time
Arrival 1.6 Departure 2.4 Event list
Statistical counters 0 0 0 0
System

Arrival time = 1.6
System state 1.6 1 1 1.6 1.6 Clock
0.4 1.6 queued customer and his arrival time
Statistical counters 0 0 0 1.2
System

Arrival time = 2.1
System state 1.6 2.1 1 2 2.1 2.1 Clock
0.4 1.6 2.1
Statistical counters 0 0 0.5 1.7
System

Departure time = 2.4
1.6 2.1
Statistical counters 1 0.8 1.1 2.0
System

2.1
System

idle
Arrival 3.8 Departure Event list
System

Arrival time = 3.8
3.8
System

Arrival time = 4.0
3.8 4.0
System

4.0
System

Arrival time = 5.6
4.0 5.6
System

Arrival time = 5.8
4.0 5.6 5.8
System

Arrival time = 7.2
System state 5.6 5.8 7.2 7.2 Clock 7.2
4.0 5.6 5.8 7.2 1 3
System

5.6 5.8 7.2
System
Hand Simulation of the Queue (cont.) Compute estimates of interest

from statistical counters in report routine (simulation) clock = 8.6 (simulated time at service completion of 5th customer) estimate of utilization: (5) = [ Area under B(t) ] / clock = 7.7/8.6 = 0.9 compare with slide 20 estimate of average number in queue: q (5 ) = [ Area under Q(t) ] / clock = 9.9/8.6 = 1.15 compare with slide 18 estimate of expected mean waiting time: (5) = [ Total waiting time ] / [ Number served ] = 5.7/5 = 1.14 not computed before estimate for expected mean system time d ( 5 ) is obtained similarly in hand simulation
Hand Simulation of the Queue (cont.) Remarks

key element in the dynamics of a simulation is the interaction between the simulation clock and the event list while processing an event, no simulated time passes. Care must be taken to process updates of the state variables in the right order (e.g., first update the area calculators and only then the time of last event) it is sometimes easy to overlook certain updates of the state variables and counters (e.g., after a departure leaving the system empty, the server must be idled) it can happen that two (or more) entries in the event list are tied for smallest and a decision rule must be incorporated to break such time ties. The tie-breaking rule can sometimes significantly affect the result of the simulation next we turn to the use of computer software

Simulation with AnyLogic High-level simulation environment

general purpose discrete, continuous, and hybrid modeling paradigm is a variant of the Unified Modeling Language for real-time systems (RT-UML)
Basic model elements

active objects: model real-world objects statecharts: internal behavior of active objects ports: asynchronous message passing variables: shared variables all can be visualized
Java-based
textual model parts in Java executable model + simulation engine mapped on Java other Java code can be linked
Simulation with AnyLogic (cont.)

Visualization of active objects:
this object encapsulated object output variable (deprecated) variable reference (deprecated) input variable (deprecated) text box parameter variable collection variable (may be used to implement port queue)
connector
port (with queue; deprecated) port reference port (without queue) statechart event dynamic event
Simulation with AnyLogic (cont.)

A statechart:
start /get first item [Not all items checked] /get next item
Checking do/check item
[All items checked && all items available]
Dispatching do/initiate delivery

aktivity Delivered
[All items checked && some items not in stock] Item Received [some items not in stock]
transition
Waiting
self-transition State
Delivered
Simulation with AnyLogic (cont.) Interpretation of statecharts

states represent system states (states of object) transitions represent state changes transition label: event [guard] / action a transition may be taken if the trigger event occurs and the specified guard condition is true an action can be performed when the transition is taken all statecharts execute concurrently
more details later
Simulation with AnyLogic (cont.) Possible events

timeout: after a fixed time has elapsed (timeout may be computed according to some distribution) rate: after an exponentially distributed time has elapsed (special case) condition: when an expression becomes true message: after arrival of a message at the statechart queue; occurs, when Java object arrives at port, which is connected to statechart (via port.map(statechart)) when explicitly called from Java code (via statechart.fireEvent()or statechart.receiveMessage())
Underlying is discrete-event simulation

simulation clock is always advanced to the time of the next event (anywhere in the model) and the event is then executed (transition is taken and the actions are performed) time ties are broken randomly
Simulation with AnyLogic (cont.) Single-server queue with RT-UML, conceptual:

client generate port port server q idle (q.size()>0)/ q.removeFirst() busy exp(1/9)
exp(1/10)/port.send()
2 active objects: client and server connected via ports, with a queue at server port 2 timed events: exponentially distributed inter-arrival and service times with means equal to 10 and 9
Simulation with AnyLogic (cont.) Implementation in AnyLogic:
Rate Trigger 0.1 Action port.send(new Object());
Rate Trigger 0.11111 On Receive Action CustomerQueue.addLast(msg);
Condition Trigger CustomerQueue.size()>0 Action CustomerQueue.removeFirst();
Simulation with AnyLogic (cont.) Runtime view windows to inspect model execution
Simulation with AnyLogic (cont.) Measures for the single-server queue

mean waiting time = average time messages spend in port at server mean queue length = average number of messages in port at server utilization = average portion of time the server is in state busy throughput = average number of transitions from busy to idle per time unit
Implementation in AnyLogic:
Simulation with AnyLogic (cont.) Messages get time stamps in Client :

send a Double object with current time instead of object of class Object method time() delivers value of simulation clock
Rate Trigger 0.1 Action port.send(new Double(time()));
Simulation with AnyLogic (cont.) Statistical counters and state variables

plain variables are defined as orange circles with a `V` (e.g., Throughput in class Server) collection variables (arrays or lists, three orange dots) may serve to implement queues for ports (see CustomerQueue) variables may also be defined in for each class
Additional Class Code
Simulation with AnyLogic (cont.) Statistics

generated data for measure computation can be collected in Statistics obj. here: QueueLength.update() adds current number of customers in collection variable CustomerQueue (see Value field of QueueLength) functions for basic statistics (mean, variance, etc.) are built-in (see page 47)
select buttons for continuous-time statistics, like queue length or discrete-time statistics, like waiting time
Simulation with AnyLogic (cont.) Actions executed in Server:

when message is received at port when service is started when service ends
On Receive action CustomerQueue.addLast(msg) QueueLength.update();
Condition Trigger CustomerQueue.size() > 0 Action WaitingTime.add( time() CustomerQueue.removeFirst().doubleValue()); QueueLength.update(); BusyFunction.add(1, time());; Rate Trigger 0.11111 Action Throughput = (++CustomersServed)/time(); BusyFunction.add(0, time());
Simulation with AnyLogic (cont.) Graphical output (initial plots) and statistics (at t=10.000 sec)
flexible visualization of data via various types of charts (time plots, histograms, bar, stack and pie charts, etc.) usual procedure: collect data in Data Set objects connect data set to desired visualization object data is displayed during simulation run drawback: each graphic below requires two data sets (actual value and mean) in addition to Statistics objects (WaitingTime, QueueLength, BusyFunction)
Simulation with AnyLogic (cont.) Summary: simulation with AnyLogic

modeling identify main system objects and map them on active objects identify states and actions of objects and map them on statechart states and transitions model interaction between objects by message passing (and shared variables) no care required for dealing with event handling identify measures of interest and collect relevant statistics in Statistics objects of appropriate type (basic properties like mean and variance are then available); sophisticated measures require additional Java coding graphical output and built-in statistical evaluation reveals system behavior exercise class practice in various assignments detailed description in AnyLogic Users Manual distributed with the tool
More information

Simulation with AutoMod High-level simulation environment

a major commercial tool for manufacturing system simulation specialized model elements underlying discrete-event simulation
Basic model elements
many more model elements for manufacturing systems

conveyors, AGVs automated storage/retrieval systems (AS/RS) bridge cranes tanks & pipes (continuous) ...
loads: dynamic entities which are moved around queues: buffers where loads can reside (i.e., wait or are being processed) resources: needed for processing loads processes: logical control of movement and resource usage of loads, executed by loads, causes events to happen
Simulation with AutoMod (cont.) Single-Server queue with AutoMod

queue Q_waitingroom models the waiting room, infinite capacity queue Q_service models the server room, capacity = 1 resource R_server models the server load L_customer models customers exponentially distributed inter-arrival times with mean 10 min. first process: P_control process P_control models the flow of customers: begin P_control arriving move into Q_waitingroom move into Q_service use R_server for exponential 9 min send to die end
Simulation with AutoMod (cont.) Graphical representation
Result display
standard statistics about all modeling entities (queues, resources, ...): current value, mean, min, max, ... customized graphs (e.g., business graphics)
Simulation with AutoMod (cont.) Queue length of Q_waitingroom (1 day)
current value
averaged value
Simulation with AutoMod (cont.) Queue length of Q_waitingroom (1 month)
current value averaged value, 5
Simulation with AutoMod (cont.) Queue length of Q_waitingroom (1 year)
current value averaged value, 8.1
Simulation with AutoMod (cont.) Mean waiting time in Q_waitingroom (in sec)
79 min
Simulation with AutoMod (cont.) Utilization of Q_service:

0.9
Simulation with AutoMod (cont.) More information

exercise class practice in assignment tutorial: Getting Started with AutoMod with AutoMod installation, lecture Web page

Simulation with OPNET High-level simulation environment

a major commercial simulation tool for communication systems underlying discrete-event simulation libraries for all relevant networking protocols and systems
Modeling similar to AnyLogic
state-transition diagrams at the core, here called Finite-State Machines (FSMs) communication via packets ( messages) hierarchical structure (network, module and process level with dedicated editors: Project, Node and Process editor) packet streams are similar to connected ports, but the FSM itself must react to a reception (in AnyLogic port actions after a reception) initial states are needed in each FSM events have to be scheduled explicitly coding in C/C++ and Proto-C (OPNET-specific kernel procedures) even simple models require various kernel procedures
Main differences for modeling the M/M/1 queue
Simulation with OPNET (cont.) Single-server queue with OPNET, conceptual:

client init generate Packet Stream op_dist_exponential(10)/ op_intrpt_schedule_self() SVC_COMPLETION server ARRIVAL init idle_and_busy
2 modules (here processes) with an extended FSM each connected via a packet stream with a queue the guards ARRIVAL and SCV_COMPLETION control which transition may be taken causing specific actions (C code) ARRIVAL: get packet from stream; start service if end of idle period SVC_COMPLETION: start new service unless end of busy period
Simulation with OPNET (cont.) Implementation in OPNET:

Project/Network level
Attribute (instance of SSQ_node) Client.InterarrivalMean : 10 Server.ServiceMean : 9
Node/Module level
Attribute process model : SSQ_generator InterarrivalMean : promoted
Attribute process model : SSQ_service_unit ServiceMean : promoted
Simulation with OPNET (cont.)

Process level: Finite State Machines and their initialization procedures (for state init)
Simulation with OPNET (cont.) Packet Generation:
kernel procedures to generate packet (op_pk_create()) and send it to a packet stream (op_pk_send()) generated packets implicitly get a time stamp!
kernel procedures to generate exponentially distributed interrarrival times (op_dist_exponential()) and to schedule an interrupt for the next arrival time (op_intrpt_schedule_self())
Simulation with OPNET (cont.)

Packet Arrival and Service:
transition executives
interrupt from packet stream
interrupt from ended service

Simulation with OMNeT++ Simulation tool for communication systems

public-source, modular components embeddable discrete-event simulation kernel modeling frameworks for networking protocols mainly for scientific research
Modeling similar to OPNET
Finite-State Machines (FSMs) as C++ code, no graphical representation communication via messages hierarchical structure (network, complex and simple modules) textual representation of model structure: ned files graphical model structure editor: GNED initial states are needed in each FSM events have to be scheduled explicitly coding in C/C++ using the OMNeT++ API INET framework for internet protocols, mobility, wireless channels (loss, fading) used in a joint simulation study of our group and Siemens Industry for sensor networks in automation
QoS in Communication Systems
Simulation with OMNeT++ Single-server queue with OMNeT++, conceptual:

client generate gate exponential(10)/ scheduleAt() 2 simple modules with an extended FSM for the server, no FSM for the client connected gates queue explicitly represented in model
server connector init gate queue timer idle
handleMessage() busy
handleMessage()
Simulation with OMNeT++ model structure in ned file:

simple modules
simple client parameters: interarrivalMean: numeric; gates: out: out; endsimple simple server parameters: serviceMean: numeric; gates: in: in; endsimple
simple module client :

one parameter gate and direction
simple module server :

one parameter gate and direction
Simulation with OMNeT++ model structure in ned file:

module MM1 submodules: Client: client; Server: server; connections: Client.out --> Server.in; endmodule network mm1 : MM1 endnetwork
complex module MM1 :

submodules connection of gates
network structure mm1 :

one complex module MM1
graphical representation of model structure:
Simulation with OMNeT++ C++ implementation for the client:
kernel procedures to generate packet (new cMessage()) and send it to a port (send()) generated packets implicitly get a time stamp!
kernel procedures to generate exponentially distributed interrarrival times (exponential()) and to schedule an event for the next arrival time (scheduleAt())
Simulation with OMNeT++ C++ implementation for the server:

Declaration of the FSM, timers, queues and counters
Initial setup of server operation and statistics collection
Recording of statistics at the end of a simulation run
Simulation with OMNeT++ C++ implementation for the server (cont.):
Entering and exiting the IDLE state
Simulation with OMNeT++ C++ implementation for the server (cont.):
Entering and exiting the BUSY state
Simulation with OMNeT++ graphical output during simulation:
Simulation with OMNeT++ visualization of statistics:

Simulation with Syntony

UML-based simulation environment
for the network domain + general-purpose standard-compliant simulation approach allows integration into model driven design by our group in cooperation with Fraunhofer IIS composite structure diagrams for hierarchical structuring state machine diagrams for behavioral specification detailed action specification with activity diagrams or action language Casual non-functional aspects (times, randomness,...) with MARTE profile (Modeling and Analysis of Real-Time and Embedded systems) communication via signals sent over ports Syntony translates UML2 diagrams to C++ (for OMNeT++) or Java (for J-Sim) execution on simulation engines and backpropagation of measures tested for larger scenarios in inter-vehicle communication and for sensor networks in logistics
Modeling paradigm
Simulation with Syntony Single-server queue with Syntony, conceptual:

Client generate Connector Server client Completion exponential(10)/ create new client signal 2 composite structures with a state machine each connected via two ports and a connector the trigger client (arrival of a client signal) causes transition to busy state where the service is performed completion of service causes transition back to idle; next client may be served instantly
QoS in Communication Systems Discrete Simulation 85
idle
busy

UML model: Network
stereotype to indicate which resources are present in the network stereotype to record utilization and throughput of server cpu

UML model: Analysis
stereotype indicating which model (or part of the model) should be simulated
Definition of variables (and their values) that can be accessed in the model

UML model: Client
stereotype specifying the points in time when a new client is generated
Casual statement specifying the action to be taken on transition execution: Create a new client signal (client.create()) and send it to the port called departures (sendTo(departures))

UML model: Server
stereotype to record queue size statistics stereotypes to handle queueing of arriving client signals at the server
stereotype specifying service times demanded by clients on the server cpu
stereotype to record waiting times for clients at the server

User Interface: based on Eclipse
control translation process, simulation parameters and evaluation
analysis of model structure generated by the translator
select UML model for simulation

User Interface: simulation animation (OMNeT++)
contents of the server module
event log
network view

User Interface: evaluation of results
Histogram of the queue length at the server of a singleserver queue
select simulation results to plot
set the options for the plot (name, labels, colors, ...)

User Interface: evaluation of results
time series plot of the queue length at the server of a single-server queue
select simulation results to plot
set the options for the plot (name, labels, colors, ...)

Organization of Discrete-Event Simulation (DES) Simulation of a Single-Server Queue Hand Simulation of the Queue Simulation with AnyLogic Simulation with AutoMod Simulation with OPNET Simulation with OMNeT++ Simulation in Java List Processing in Simulation
Simulation in Java Coding simulations in Java

use of a general-purpose language we must pay attention to every detail and get a better understanding of how simulations operate sometimes necessary to code a simulation in a general-purpose language, since certain system aspects do not fit in the pre-programmed frameworks of simulation tools and languages still common to do the entire simulation this way
SSJ: Stochastic Simulation in Java

Java library from Paul LEcuyer, University of Montreal primarily for DES (event-/process-oriented), also continuous and hybrid classes for simulation clock and event list processing generating random numbers collecting statistics, writing output
Simulation in Java (cont.) Single-Server queue with SSJ

inter-arrivals and services exponentially distributed 3 event classes Arrival Departure EndOfSim event list processing event instances are inserted into event list with time of occurrence and executed when simulation clock reaches this time executing an event means invoking its actions method statistical counters Tally: discrete-time Accumulate: continuous-time
Simulation in Java (cont.) Beginning of the code, basic definitions:

public class QueueEv { static final double meanArr = 10.0; static final double meanServ = 9.0; static final double timeHorizon = 1000.0; RandMrg genArr = new RandMrg (); RandMrg genServ = new RandMrg (); List waitList = new List ("Customers in queue"); List servList = new List ("Customers in service"); Tally queuingD = new Tally ("Queuing delay"); Accumulate queueL = new Accumulate ("Queue length"); class Customer { double arrivTime, servTime; } ... some constants
2 random number streams 2 lists: queue + service unit 2 counters: mean queuing delay, mean queue length customers with their arrival and service times
Simulation in Java (cont.) Construction of simulation:
... public static void main (String[] args) { new QueueEv(); } public QueueEv() { Sim.init(); new EndOfSim().schedule (timeHorizon); new Arrival().schedule (Rand1.expon (genArr, meanArr)); Sim.start(); } ...
constructor initialization schedule EndOfSim schedule Arrival start event processing
Simulation in Java (cont.) Flow of control when an Arrival event is executed:
Simulation in Java (cont.) Arrival event execution:

... class Arrival extends Event { public void actions() { new Arrival().schedule (Rand1.expon (genArr, meanArr)); Customer cust = new Customer(); cust.arrivTime = Sim.time(); cust.servTime = Rand1.expon (genServ, meanServ); if (servList.size() > 0) { waitList.insert (cust, List.LAST); queueL.update (waitList.size()); } else { servList.insert (cust, List.LAST); new Departure().schedule (cust.servTime); queuingD.update (0.0); } } } ...
schedule next arrival create new customer, set arrival time, generate service time join queue, update counter enter service, schedule Departure, update counter
Simulation in Java (cont.) Flow of control when a Departure event is executed:
Simulation in Java (cont.) Departure event execution:

... class Departure extends Event { public void actions () { servList.remove (List.FIRST); if (waitList.size () > 0) { Customer cust = (Customer) waitList.remove (List.FIRST); servList.insert (cust, List.LAST); new Departure().schedule (cust.servTime); queuingD.update (Sim.time () - cust.arrivTime); queueL.update (waitList.size ()); } } } ...
remove customer move customer from queue to service unit, schedule Departure, update counters
Simulation in Java (cont.) EndOfSim event execution:
... class EndOfSim extends Event { public void actions () { queuingD.report(); queueL.report(); Sim.stop(); } } }
write statistical report for the two counters stop event processing
Simulation in Java (cont.) Output of the program:

REPORT on Tally stat. collector ==> Queuing delay min max average standard dev nb. obs. 0 113.721 49.554 22.336 97 REPORT on Accumulate stat. collector ==> Queue length From time To time 0 1000 Min 0 Max 12 Average 4.85
Values differ from AutoMod results, 1000 minutes correspond to 16 hours only!
Simulation in Java (cont.) SSJ classes

Sim: maintains simulation clock and event list EventList: event list, implemented as doubly linked list Event: abstract class for events, methods for scheduling and cancelling of events RandMrg: random number generators (uniform from 0 to 1) Rand1: random variate generators for various distributions Tally: discrete-time statistics Accumulate: continuous-time statistics List: lists of any type of object, implemented as doubly linked lists
Details in SSJ Users Guide
Simulation in Java (cont.) Main parts of the Sim class:

public abstract class Sim implements Runnable { public static double currentTime = 0.0; public static EventList eventList = new DoublyLinked (); public static boolean stopped = false; public static double time () {return currentTime;} public static void init () {currentTime = 0.0; eventList.cleanup (); stopped = false;} public static void init (EventList evlist) {init(); eventList = evlist;} ...
simulation clock event list returns value of simulation clock initialization
initialization with event list

Simulation in Java (cont.)

... public static void start () { if (eventList.isEmpty ()) error ("Sim.start with empty event list"); Event ev = eventList.removeFirst(); while (ev != null && !stopped) { currentTime = ev.eventTime; ev.actions(); ev = eventList.removeFirst(); } } public static void stop () {stopped = true;} } (dealing with processes is omitted)
start event list processing get first event set sim. clock, execute event, get next event
stop when start takes control
Simulation in Java (cont.) Main parts of the Event class:

public abstract class Event implements Cloneable { protected double eventTime; public static String descriptor; public Event (double delay) { if (delay >= 0.0) { eventTime = Sim.time() + delay; Sim.eventList.insert (this); } else error ("Scheduling an event in the past."); }
time of event occurrence event type identification construct + schedule event determine event time, insert in event list
Simulation in Java (cont.)

... public void schedule (double delay) { if (delay < 0.0) error ("Scheduling an event in the past."); eventTime = Sim.time() + delay; Sim.eventList.insert (this); } public final boolean cancel (String type) { Event ev = Sim.eventList.viewFirstOfClass (type); return ev.cancel(); } public final double time() {return eventTime;} public abstract void actions(); }
schedule event
remove event from event list
return event time method actions, invoked when event is executed

Simulation in Java (cont.) Summary: programming in event-oriented style

1. identify system states events measures of interest 2. implement data structures for system states (typically lists) and statistical counters, in example: lists: waitList, servList counters: here implicit as waitList.size(), servList.size() 3. write an event handling routine for each event in SSJ a class with an actions method for each event here: Arrival, Departure, EndOfSim
Higher level modeling paradigm and tool environment makes modeling less tedious

Organization of Discrete-Event Simulation (DES) Simulation of a Single-Server Queue Hand Simulation of the Queue Simulation with AnyLogic Simulation with AutoMod Simulation with OPNET Simulation in Java List Processing in Simulation
List Processing in Simulation In the shown queue simulation

event list (objects: events, variables: time of occurrence) list of customers waiting in the queue (objects: customers, variables: arrival time, service time)
General use of lists in simulations

most simulations require many lists which may contain many objects, consisting of several variables often necessary to process these lists other than FIFO lists are the dominating data structures in simulation programs usual implementation: pointers and dynamic memory allocation
List Processing in Simulation (cont.) Doubly linked lists

first object object object object last
can be implemented by using pointers (links) in C, Java (or arrays in languages without dynamic data structures such as FORTRAN) each object has a link to its successor and predecessor special links to the first and the last object of the list typical operations: insert an object in the list such that the list is sorted (increasing/decreasing) according to a certain variable get an object at the i'th position of the list (get the first, get the last element) remove a certain object according to its variable or position
List Processing in Simulation (cont.) More sophisticated data structures

for complex simulations involving a large number of events, much of the computer time required to perform the simulation can be expended on event-list processing implementing the event list as described leads to a linear search for events in it one way to improve the efficiency is to use other search techniques and the appropriate data structures for them binary search + search tree a pointer to the middle of the lists and other variants
List Processing in Simulation (cont.) Event list in SSJ

public interface EventList { public boolean isEmpty (); public void cleanup (); public void print (); public void insert (Event ev); public void insertFirst (Event ev); public void insertBefore (Event ev, Event other); public void insertAfter (Event ev, Event other); public Event viewFirst (); public Event viewFirstOfClass (String cl); public boolean remove (Event ev); public Event removeFirst (); }
List Processing in Simulation (cont.) A part of its implementation:

public class DoublyLinked implements EventList { private class Node {Event ev; Node prec, succ;} private Node first, last; private Node free = null; public DoublyLinked () {first = last = null;} public void insertFirst (Event ev) { Node newNode; if (free == null) newNode = new Node(); else {newNode = free; free = free.succ;} newNode.ev = ev; newNode.prec = null; if (first==null) {first=last=newNode; first.succ=null;} else {newNode.succ = first; first.prec = newNode; first = newNode;} } ...
node with predecessor, successor first and last pointers pointer to stack of free nodes insertion at first position

Discrete Event Simulation Modeling

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Discrete Event Simulation Modeling

Caricato da

Copyright:

Formati disponibili

Overall Plan of Simulation and Modeling I Chapters

Simulation and Modeling I

Discrete Simulation Goals

Simulation and Modeling I

Simulation and Modeling I

Organization of Discrete-Event Simulation (cont.) Recall: the single-server queue (SSQ)

Simulation and Modeling I

Simulation and Modeling I

Organization of Discrete-Event Simulation (cont.) State in the single-server queue

Simulation and Modeling I

Organization of Discrete-Event Simulation (cont.) Next-event time advance

Simulation and Modeling I

Organization of Discrete-Event Simulation (cont.) Fixed-increment time advance

Simulation and Modeling I

Simulation and Modeling I

Organization of Discrete-Event Simulation (cont.)

Organization of Discrete-Event Simulation (cont.) Flow of control

Is simulation over? Report generator Yes

1. Compute estimates of interest 2. Write report

Simulation and Modeling I

Discrete Simulation Contents

Simulation and Modeling I

Simulation of a Single-Server Queue Consider the single-server queue with

Simulation and Modeling I

Random characteristics of the measures

Simulation and Modeling I

Simulation and Modeling I

Simulation of a Single-Server Queue (cont.) Estimation of the queue length:

Simulation of a Single-Server Queue (cont.) Q(t) for a possible realization with n = 5:

Simulation and Modeling I

Simulation of a Single-Server Queue (cont.)

Ti = 3.2 + 2.3 + 1.7 + 1.4 = 8.6 = T(5)

iTi = 0 3.2 + 1 2.3 + 2 1.7 + 3 1.4 = 9.9

Simulation and Modeling I

Simulation of a Single-Server Queue (cont.) Estimation of the utilization

Simulation and Modeling I

Simulation of a Single-Server Queue (cont.) In the example realization we get

0 Arrivals e =0.4 1 Departures

e12=7.2 e13=8.6=T (5)

Simulation and Modeling I

Discrete Simulation Contents

Simulation and Modeling I

Hand Simulation of the Queue Hand simulation

Hand Simulation of the Queue (cont.)

System state 0 Clock 0 0 0

Arrival 0.4 Departure Event list

Hand Simulation of the Queue (cont.)

System state 0.4 Clock 1 0 0.4

0.4 arrival time

Arrival 1.6 Departure 2.4 Event list

Hand Simulation of the Queue (cont.)

System state 1.6 1 1 1.6 1.6 Clock

0.4 1.6 queued customer and his arrival time

Arrival 2.1 Departure 2.4 Event list

Statistical counters 0 0 0 1.2

Hand Simulation of the Queue (cont.)

System state 1.6 2.1 1 2 2.1 2.1 Clock

0.4 1.6 2.1

Arrival 3.8 Departure 2.4 Event list

Statistical counters 0 0 0.5 1.7

Hand Simulation of the Queue (cont.)

System state 2.1 1 1 2.4 2.4 Clock

Arrival 3.8 Departure 3.1 Event list

Statistical counters 1 0.8 1.1 2.0