discrete event simulation modeling

Simulation and Modeling I Discrete Simulation 1

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


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)

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

arrival of customers

customers depart from system

waiting room (queue) service unit



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 customer´s 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



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)



Next-event time advance the simulation clock jumps from ei to ei+1

e0 e1 e2 e3 e4 e5

0 t1 t2 c1 t3 c2

A1 A2 A3

S1 S2

Time



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

e2 e3 e4 0 e1 ∆t Time 4∆t 2∆t 3∆t



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



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



Flow of control 0. Invoke the initialization routine 1. Invoke the timing routine 2. Invoke event routine i

Repeatedly

1. Set simulation clock = 0 2. Initialize system state and statistical counters 3. Initialize event list

1. Determine the next event type, say, i 2. Advance the simulation clock

1. Compute estimates of interest 2. Write report

Is simulation

over?

Stop

Initialization routine Main program Timing routine

1. Update system state 2. Update statistical counters 3. Generate future events and add to event list, eventually remove others from the event list

Event routine i

Library routines

Report generator Yes

Generate random variates

1

i

No

2

0

Start


Discrete Simulation



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



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

which is just the arithmetic mean of the n Di’s 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,…

( ) ∑=

=n

1iiD

n1nd



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

for computing it easily, let Ti be the total time during the simulation that the queue is of length i, then

the area can be accumulated as rectangles as the simulation progresses over time

( ) ( ) ( )( )

∫=nT

0dttQ

nT1nq

( ) ( )∑∞

==

0iiiT

nT1nq



Q(t) for a possible realization with n = 5: Q(t)

3

1

2

1 9 8 7 6 5 4 3 2 0 t

e1=0.4

e5=3.1 e4=2.4

e3=2.1

e2=1.6

e9=4.9

e8=4.0

e6=3.3

e7=3.8

e13=8.6=T (5)

e12=7.2

e11=5.8

e10=5.6 Arrivals

Departures



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:

numerator:

our estimate of the average number in queue gets:

)5(T6.84.17.13.22.3T3

0ii ==+++=∑

=

9.94.137.123.212.30iT3

0ii =×+×+×+×=∑

=

( ) 15.16.8/9.95q ==



Estimation of the utilization define a “busy function” (an indicator function)

then the estimate can be expressed as a continuous-time statistics, as the proportion of time B(t) is equal to 1:

=t time at idle is server0

t time atbusy is server1)t(B

( ) ( )( )

∫=nT

0dt)t(B

nT1nu



In the example realization we get

and ( ) 90.0

6.87.7

6.8)8.36.8()4.03.3(5u ==

−+−=

e1=0.4

e5=3.1 e4=2.4

e3=2.1

e2=1.6

e9=4.9

e8=4.0

e6=3.3 e7=3.8

e13=8.6=T (5)

e12=7.2 e11=5.8

e10=5.6 Arrivals

Departures

B(t)

1

0 1 3 5 4 2 1 9 8 7 6 t


Discrete Simulation



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.)

System Computer representation

Initialization time = 0

idle

System state

Statistical counters Number in

queue

Server status

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

0 0 0 0

0 0 0

0 0.4 ∞

Arrival Departure

poi-soning

server

Times of

arrival of

queued customers




Arrival time = 0.4

0.4

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

0 0 0 0

1 0 0.4

0.4 1.6 2.4

Arrival Departure

arrival time




Arrival time = 1.6

0.4

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

0 0 0 1.2

1 1 1.6

1.6 2.1 2.4

1.6

Arrival Departure

1.6

queued customer and

his arrival time




Arrival time = 2.1

0.4

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

0 0 0.5 1.7

1 2 2.1

2.1 3.8 2.4

1.6 2.1

Arrival Departure

1.6

2.1




Departure time = 2.4

1.6

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

1 0.8 1.1 2.0

1 1 2.4

2.4 3.8 3.1

2.1

Arrival Departure

2.1





2.1

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

2 1.8 1.8 2.7

1 0 3.1

3.1 3.8 3.3

Arrival Departure





idle

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

3 1.8 1.8 2.9

0 0 3.3

3.3 3.8 ∞

Arrival Departure




Arrival time = 3.8

3.8

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

3 1.8 1.8 2.9

1 0 3.8

3.8 4.0 4.9

Arrival Departure




Arrival time = 4.0

3.8

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

3 1.8 1.8 3.1

1 1 4.0

4.0 5.6 4.9

4.0

Arrival Departure

4.0





4.0

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

4 2.7 2.7 4.0

1 0 4.9

4.9 5.6 8.6

Arrival Departure




Arrival time = 5.6

4.0

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

4 2.7 2.7 4.7

1 1 5.6

5.6 5.8 8.6

5.6

Arrival Departure

5.6




Arrival time = 5.8

4.0

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

4 2.7 2.9 4.9

1 2 5.8

5.8 7.2 8.6

5.6 5.8

Arrival Departure

5.6

5.8




Arrival time = 7.2

4.0

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

4 2.7 5.7 6.3

1 3 7.2

7.2 9.1 8.6

7.2

5.6 5.8

Arrival Departure

5.6

5.8

7.2





5.6

System state


queue

Server status

Times of

arrival of

queued customers

Time of last event

Event list Clock

Area under B(t)

Area under Q(t)

Total waiting time

Number served

5 5.7 9.9 7.7

1 2 8.6

8.6 9.1 9.2

5.8 7.2

Arrival Departure

5.8

7.2



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: – = [ 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 is obtained similarly in hand simulation

)5(d

( )5q



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


Discrete Simulation



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:

collection variable (may be used to implement port queue)

output variable (deprecated)

variable reference (deprecated)

input variable (deprecated)

dynamic event statechart

port reference

port (without queue)

port (with queue; deprecated)

encapsulated object

this object connector

text box

variable

parameter

event



A statechart:

Dispatching

do/initiate delivery

Checking

do/check item

Delivered Waiting

start /get first item

[All items checked && all items available]

transition

State

aktivity

self-transition

Item Received [some items not in stock]

[Not all items checked] /get next item

[All items checked && some items not in stock] Delivered



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



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



Single-server queue with RT-UML, conceptual:

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

client server

generate

exp(1/10)/port.send()

port port

exp(1/9) (q.size()>0)/ q.removeFirst()

idle

busy

q



Implementation in AnyLogic:

Condition Trigger

CustomerQueue.size()>0

Action

CustomerQueue.removeFirst();

Rate Trigger

0.11111

Rate Trigger

0.1

Action

port.send(new Object()); On Receive Action

CustomerQueue.addLast(msg);



Runtime view windows to inspect model execution



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:



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 Additional Class Code for each class


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.) On Receive action

CustomerQueue.addLast(msg)

QueueLength.update(); Actions executed in Server: when message is received at port when service is started when service ends

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());



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)



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

More information exercise class practice in various assignments detailed description in AnyLogic User‘s Manual distributed with the tool


Discrete Simulation



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

many more model elements for manufacturing systems conveyors, AGVs automated storage/retrieval systems (AS/RS) bridge cranes tanks & pipes (continuous) ...


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



Graphical representation

Result display standard statistics about all modeling entities (queues, resources, ...): current value, mean, min, max, ... customized graphs (e.g., business graphics)



Queue length of Q_waitingroom (1 day)

current value

averaged value



Queue length of Q_waitingroom (1 month)

current value

averaged value, ≈ 5



Queue length of Q_waitingroom (1 year)

current value

averaged value, ≈ 8.1



Mean waiting time in Q_waitingroom (in sec)

≈ 79 min



Utilization of Q_service:

≈ 0.9



More information

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


Discrete Simulation



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)

Main differences for modeling the M/M/1 queue 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


Simulation with OPNET (cont.)

Single-server queue with OPNET, conceptual: client server

generate

op_dist_exponential(10)/ op_intrpt_schedule_self()

Packet

Stream

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

init idle_and_busy init

ARRIVAL

SVC_COMPLETION



Implementation in OPNET:

Project/Network level Node/Module level

Attribute

(instance of SSQ_node)

Client.InterarrivalMean : 10

Server.ServiceMean : 9

Attribute

process model : SSQ_generator

InterarrivalMean : promoted

Attribute

process model : SSQ_service_unit

ServiceMean : promoted



Process level: Finite State Machines and their initialization procedures (for state init)



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())



Packet Arrival and Service:

interrupt from

packet stream interrupt from

ended service

transition executives


Discrete Simulation


QoS in Communication Systems Discrete Simulation 73

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


Simulation with OMNeT++

Single-server queue with OMNeT++, conceptual: client server

generate

exponential(10)/ scheduleAt()

connector

2 simple modules with an extended FSM for the server, no FSM for the client

connected gates queue explicitly represented in

model

busy

init

idle

handleMessage() timer

handleMessage()

queue

gate gate


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

graphical representation of model structure:

complex module MM1 : submodules connection of gates

network structure mm1 : one complex module MM1


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:


Discrete Simulation



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

Modeling paradigm 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



Single-server queue with Syntony, conceptual: Client Server

generate

exponential(10)/ create new client signal

Connector

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

busy idle client

Completion



UML model: Network

stereotype to record utilization and throughput of server cpu

stereotype to indicate which resources are present in the network



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

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 queue size statistics

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 single-server 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, ...)


Discrete Simulation

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 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 L‘Ecuyer, 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



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; } ...

2 random number streams 2 lists: queue + service unit 2 counters: mean queuing delay, mean queue length

customers with their arrival and service times

some constants



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



Flow of control when an Arrival event is executed:



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



Flow of control when a Departure event is executed:



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



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



Output of the program: Values differ from AutoMod results,

1000 minutes correspond to 16 hours only!

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 Min Max Average 0 1000 0 12 4.85



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 User‘s Guide



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;} ...

initialization

initialization with event list

returns value of simulation clock

simulation clock event list



... 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;} }

start event list processing

set sim. clock, execute event, get next event

get first event

stop when start takes control

(dealing with processes is omitted)



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

construct + schedule event

determine event time, insert in event list

event type identification



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



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


Discrete Simulation

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

object object object object first last



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



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;} } ...

insertion at first position

node with predecessor, successor

first and last pointers

pointer to stack of free nodes

discrete event simulation modeling

Documents