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

customers depart from system waiting room (queue)

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



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

e1

e2

e3

e4

e5

0

t1

t2

c1

t3

c2

A1

A2

A3 S1


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

0

e1 ∆t


2∆t

e2 e3

3∆t e4

4∆t

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


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

Start

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

Main program

Timing routine

0. Invoke the initialization routine 0

1 1. Invoke the timing routine 2. Invoke event routine i

Repeatedly

i

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

2

Event routine i

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

Library routines Generate random variates

No

Yes

1. Compute estimates of interest 2. Write report

Stop



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 with Syntony  Simulation in Java  List Processing in 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



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 n ˆd(n) = 1 ∑ Di n i=1

 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,…



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 qˆ(n) = T(n)

T (n )

∫ Q(t ) dt

0

 for computing it easily, let Ti be the total time during the simulation that the queue is of length i, then 1 ∞ qˆ(n) = iTi ∑ T(n) i=0  the area can be accumulated as rectangles as the simulation progresses over time Simulation and Modeling I


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

2

1

0

Arrivals

1 e1=0.4

2

3

4


6

e8=4.0

e2=1.6

Departures

5

e3=2.1

e7=3.8

7

8

9 t

e11=5.8 e10=5.6

e12=7.2

e6=3.3 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:

3

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

i=0

 numerator:

3

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

i=0

 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 uˆ(n) = T(n)


T (n )

∫ B( t ) dt

0


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

0

2

1

Arrivals e =0.4 1

e3=2.1 e2=1.6

Departures

 and

4

3

e8=4.0 e7=3.8 e6=3.3

e4=2.4 e5=3.1

uˆ(5 ) =

5

6 e11=5.8 e10=5.6

7

8

9t

e12=7.2

e9=4.9

e13=8.6=T (5)

( 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 Simulation and Modeling I


Hand Simulation of the Queue (cont.) Initialization time = 0

System state 0

idle

server

Clock 0

0


Event list

0

Server Number Times Time status in of last of queue arrival event of queued customers

System

poisoning

Arrival 0.4 Departure ∞

Statistical counters 0

0

0

0

Number Total Area Area served waiting under under time Q(t) B(t)

Computer representation Discrete Simulation 23

Hand Simulation of the Queue (cont.) Arrival time = 0.4

System state 0.4

0.4 arrival time

Arrival 1.6 Departure 2.4

Clock 1

0

0.4


System Simulation and Modeling I

Event list


0

0

0




System state 1.6

0.4 1.6 queued customer and his arrival time

1.6


Clock 1

1

1.6



Event list


0

0

1.2




System state 1.6 2.1

0.4 1.6 2.1

2.1

1

2

Clock


Event list

2.1


System



0

0.5

1.7



Hand Simulation of the Queue (cont.) Departure time = 2.4

System state 2.1

1.6 2.1

2.4


Clock 1

1

2.4



Event list


0.8

1.1

2.0




System state 3.1

2.1


Clock 1

0

3.1



Event list


1.8

1.8

2.7




System state 3.3

idle

Arrival 3.8 Departure ∞

Clock 0

0

3.3



Event list


1.8

1.8

2.9




System state 3.8

3.8


Clock 1

0

3.8



Event list


1.8

1.8

2.9




System state 4.0

3.8 4.0

4.0


Clock 1

1

4.0



Event list


1.8

1.8

3.1




System state 4.9

4.0


Clock 1

0

4.9



Event list


2.7

2.7

4.0




System state 5.6

4.0 5.6

5.6


Clock 1

1

5.6



Event list


2.7

2.7

4.7





4.0 5.6 5.8

5.8

1

2

Clock


Event list

5.8


System



2.7

2.9

4.9




System state

4.0 5.6 5.8 7.2

1

3

5.6 5.8 7.2

7.2 Clock


Event list

7.2


System



2.7

5.7

6.3





5.6 5.8 7.2

8.6

1

2

Clock


Event list

8.6


System



5.7

9.9

7.7



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 Simulation and Modeling I


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 and Modeling I


Simulation with AnyLogic (cont.) Visualization of active objects: this object encapsulated object

output variable (deprecated)

connector

variable reference (deprecated) input variable (deprecated)

port (with queue; deprecated) port reference

text box

variable

port (without queue) statechart


parameter

event

dynamic event

collection variable (may be used to implement port queue)


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]

[All items checked && some items not in stock] Item Received [some items not in stock]


do/initiate delivery aktivity Delivered

transition

Delivered

Waiting self-transition

Dispatching

State


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 and Modeling I


Simulation with AnyLogic (cont.)  Single-server queue with RT-UML, conceptual: client

server generate

port

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

port

q

idle (q.size()>0)/ q.removeFirst()

exp(1/9) busy

 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 and Modeling I


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

Additional Class Code

for each class Simulation and Modeling I


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:

On Receive action CustomerQueue.addLast(msg) QueueLength.update();

 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()); Simulation and Modeling I


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

 More information

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






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



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)

 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: server

client init

generate

Packet

ARRIVAL init

idle_and_busy

Stream op_dist_exponential(10)/ op_intrpt_schedule_self()

SVC_COMPLETION

 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 and Modeling I


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

client generate gate

connector

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 QoS in Communication Systems

init gate idle

queue timer

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

 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



Simulation with Syntony  Single-server queue with Syntony, conceptual: Server

Client generate

Connector

idle

client

busy

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


Simulation with Syntony  UML model: Network stereotype to indicate which resources are present in the network


stereotype to record utilization and throughput of server cpu


Simulation with Syntony  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



Simulation with Syntony  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))


Simulation with Syntony  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



Simulation with Syntony  User Interface: based on Eclipse

analysis of model structure generated by the translator


control translation process, simulation parameters and evaluation

select UML model for simulation


Simulation with Syntony  User Interface: simulation animation (OMNeT++)

contents of the server module

event log

network view



Simulation with Syntony  User Interface: evaluation of results

select simulation results to plot


Histogram of the queue length at the server of a singleserver queue

set the options for the plot (name, labels, colors, ...)


Simulation with Syntony  User Interface: evaluation of results

select simulation results to plot


time series plot of the queue length at the server of a single-server queue

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 and Modeling I


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 Discrete Simulation 97

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 and Modeling I


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

simulation clock event list

public static double time () {return currentTime;}

returns value of simulation clock

public static void init () {currentTime = 0.0; eventList.cleanup (); stopped = false;}

initialization

public static void init (EventList evlist) {init(); eventList = evlist;} ...

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

start event list processing get first event set sim. clock, execute event, get next event

stop when start takes control

} (dealing with processes is omitted) Simulation and Modeling I


Simulation in Java (cont.) Main parts of the Event class: public abstract class Event implements Cloneable { protected double eventTime;

time of event occurrence

public static String descriptor;

event type identification

public Event (double delay) { if (delay >= 0.0) { eventTime = Sim.time() + delay; Sim.eventList.insert (this); } else error ("Scheduling an event in the past."); } … Simulation and Modeling I

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

schedule event

public final boolean cancel (String type) { Event ev = Sim.eventList.viewFirstOfClass (type); return ev.cancel(); }

remove event from event list

public final double time() {return eventTime;}

return event time

public abstract void actions();

method actions, invoked when event is executed

} Simulation and Modeling I


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 Simulation and Modeling I


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 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 (); } Simulation and Modeling I


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

... Simulation and Modeling I


Discrete Event Simulation Modeling

Recommend Documents