DISCRETE EVENT SYSTEM THEORY AND …msdl.cs.mcgill.ca/people/mosterman/tutorials/date08/...1 DISCRETE EVENT SYSTEM THEORY AND SIMULATION USING SIMEVENTS FOR TRANSACTION LEVEL MODELING

1

DISCRETE EVENT SYSTEM THEORYAND SIMULATION

USING SIMEVENTSFOR TRANSACTION LEVEL MODELING

C. G. CassandrasCenter for Information and Systems Engineering (CISE)Boston [email protected]://vita.bu.edu/cgc

Christos G. Cassandras CODES Lab. - Boston University

OUTLINE


Transaction-based systems as Discrete Event Systems (DES)

Event-driven vs Time-driven behavior

Why not to use time-driven models for DES…

DES examples – Queueing Systems

DES modeling frameworks and simulation

SIMEVENTS basics

2

DISCRETE EVENT SYSTEMS


“Transaction-based” systems exhibit event-driven behavior:System state changes only as a result of discrete events– not time

Events: “transaction starts”, “transaction ends”, etc.

Event-driven dynamics define the class ofDISCRETE EVENT SYSTEMS (DES) such as…

Manufacturing Systems Communication Networks (e.g., Internet)ComputersC3I (military) systemsTraffic systems - land, sea, airLogistics, business processesSoftware

TIME-DRIVEN SYSTEM

EVENT-DRIVEN SYSTEM

TIME-DRIVEN vs EVENT-DRIVEN SYSTEMS


STATES

TIMEt

STATE SPACE:

X = ℜ

DYNAMICS:

( )& ,x f x t=

x(t)

STATES

s1

s2

s3

s4

TIMEt

STATE SPACE:

{ }X s s s s= 1 2 3 4, , ,

DYNAMICS:

( )exfx ,'=t2

e2

x(t)

t3 t4 t5

e3 e4 e5EVENTS

t1

e1

3

TIME-DRIVEN EVENT-DRIVEN

REAL VALUED:Position, Velocity,Flow, Volume,Voltage, Current

INTEGER VALUED:Number of packets,Number of partsSYMBOLS:Traffic light: green, red,Processor status: on, off

TYPICALSTATES

CLOCK

Continuouslychanging

Discontinuouslychanging with eachEVENT

TIME-DRIVEN vs EVENT-DRIVEN SYSTEMS


CONTINUED

State variables are both discrete and continuouscannot rely on calculus alone;symbols vs. variables

Lack of event synchronization

Inherent uncertainties (events cannot be fully predictable)need accurate stochastic models

Inherent complexity (e.g., too many operating modes)

need to live without simple analytical expressions; combinatorial explosion;need new ‘paradigms’ and abstraction levels

time cannot drive state transitions;need new mathematical models for state dynamics

MAIN FEATURES OF EVENT-DRIVEN SYSTEMS


4

Wasted clock ticks

More wasted clock ticks

Even more wasted clock ticks…

INCREASING TIM

E GRANULARITY

Indistinguishable events

SYNCHRONOUS vs ASYNCHRONOUS BEHAVIOR


SYNCHRONOUS:

CLOCK drives all state updates

No event within a “clock tick” ⇒ no state transition

Two or more events within a “clock tick” ⇒ need increased time granularity

ASYNCHRONOUS:

EVENTS drive all state updates

Clock is controlled by events ⇒ clock is fixed until next event

SYNCHRONOUS vs ASYNCHRONOUS BEHAVIOR


5

WHY NOT TO USE TIME-DRIVEN MODELS FOR DES


A few reasons for NOT using a time-driven engine to model event-driven systems…

1. Asynchronous behavior causinginefficiencies and errors in computation

2. Need to model imperative semantics

3. Need to model concurrency

Simple computation example in a time-driven environment:

x + yxy

xy

TIME

TIME

Time-driven (synchronous) implementation:- Sum repeatedly evaluated unnecessarily- When evaluation is actually needed,

it is done at the wrong times !

t1 t2

Asynchronous

events

TIME-DRIVEN vs EVENT-DRIVEN COMPUTATION


6

TIME-DRIVEN vs EVENT-DRIVEN COMPUTATION


DECLARATIVE vs. IMPERATIVE SEMANTICS


TIME-DRIVEN SYSTEM– Model based on diff. equations– Declarative semantics– equation ⇒ variables must satisfy a constraint

EVENT-DRIVEN SYSTEM– Model based on “event calendar”– Imperative semantics– equation ⇒ strict assignment

7

An event-driven model must allow a variable to takemultiple values at each point in time.

Time-driven models are not intended to operate in this manner.

EVENT CONCURRENCY


At EVENT TIME t :- e1 disables process…- … and resets state,- e2 re-enables process

EVENT

Time-drivenpoint of view(final effect at tbecause of e2)

e1 e2

t Event-drivenpoint of view(effects of bothe1 and e2processed at t)

EVENT CONCURRENCY


CONTINUED

8

QUEUE SERVER

Customer(Transaction)Arrivals

Customer(Transaction)Departures

Typical EVENTS: a = arrival, d = departure

E = {a, d}

Typical STATES: x = number in system (0,1,2, …)

X = {0, 1, 2, …}

DES EXAMPLES: A SIMPLE QUEUEING SYSTEM


E = {a, d, r1, r2, d1, d2}

X = {(xCPU, x1, x2): xCPU, x1, x2 ≥ 0}

CPU

Jobs

JobDepartures

1

2

DES EXAMPLES: A COMPUTER SYSTEM


9

E = {a, d1, d2,…,dN}

X = {(x1,…, xN): 0 ≤ xi ≤ bi}

1Packets

2

3

PacketsLost

PacketsLost

…

b1

b2

b3

COMMUNICATION BLOCKING:packets lost if

downstream buffer full

DES EXAMPLES: A COMMUNICATION NETWORK


DES MODELING FRAMEWORKS


STATE AUTOMATA

PETRI NETS

MAX-PLUS ALGEBRA

QUEUEING THEORY

10

AUTOMATON: (E, X, Γ, f, x0)

Ε : Event Set

X : State Space

{ }e e1 2, ,K { }x x1 2, ,K( )f x e x, '=

Γ(x) : Set of feasible or enabled events at state x

x X0 ∈x0 : Initial State,

f X E X: × →( )e x∉Γ

f : State Transition Function(undefined for events )

STATE AUTOMATA


Add a Clock Structure V to the automaton: (E, X, Γ, f, x0 , V)where:

and vi is a Clock or Lifetime sequence: one for each event i

{ }V v= ∈i i E :

{ }K,, 21 iii vv=v

Need an internal mechanism to determineNEXT EVENT e´ and hence

NEXT STATE ( )x f x e' , '=

{ }x x1 2, ,K( )f x e x, ' '=

v1

vN

M

NEXT EVENT

TIMED AUTOMATON


11

CURRENT STATE

CURRENT EVENT

CURRENT EVENT TIME

Associate aCLOCK VALUE/RESIDUAL LIFETIME yi

with each feasible event ( )i x∈Γ

x∈X with feasible event set Γ(x)

e that caused transition into x

t associated with e

HOW THE TIMED AUTOMATON WORKS


NEXT/TRIGGERING EVENT e' :

( ){ }i

xiye

Γ∈= minarg'

NEXT EVENT TIME t' :

( ){ }i

xiyy

ytt

�∈=

+=min* :where

*'

NEXT STATE x' :

( )x f x e' , '=



CONTINUED

12

Determine new CLOCK VALUESfor every event ( )i x∈ Γ

′yi

( ) ( )( ) ( ){ }

iv

otherwise

exxiv

eixixiyy

y

ij

ij

i

i

event for lifetimenew :where

0

, ,*

=

⎪⎩

⎪⎨

⎧′−−′∈

′≠∈′∈−=′ ΓΓ

ΓΓ

{ }x x1 2, ,K( ) }{minarg' ,',')(

ixi

yeexfxΓ∈

==( )Vx,,' ygy =

v1

vNM

EVENT CLOCKS

ARE STATE VARIABLES



CONTINUED

QUEUE SERVER

ArrivalEvents

DepartureEvents

{ }{ }K,2,1,0

,

==

X

daE

( )f x ex e a

x e d x,

,′ =

+ ′ =− ′ = >

⎧⎨⎩

1

1 0

{ } { }KK ,, ,,, :input Given 2121 dddaaa vvvv == vv

( ) { }( ) { }a

xdax

=>=

0

0 allfor ,,

ΓΓ

TIMED AUTOMATON - EXAMPLE


13

t0

x0 = 0

a

e1 = a

x0 = 1

t1

ad

e2 = a

x0 = 2

t2

ad

e3 = a

x0 = 3

t3

ad

x0 = 2

e4 = d

t4

TIMED AUTOMATON – A TYPICAL STATE TRAJECTORY


Same idea with the Clock Structure consisting of Stochastic Processes

Associate with each event i a Lifetime Distribution based onwhich vi is generated

Generalized Semi-Markov Process(GSMP)

In a simulator, vi is generated through a pseudorandom number generator

STOCHASTIC TIMED AUTOMATON


14

Proceed by example and contrast to Timed Automaton model...

EVENTS: a = arrival, d = departure

E = {a, d}

STATES: x = number in system (0,1,2, ...)

X = {0, 1, 2, ...}

PETRI NETS


QUEUE SERVER

ArrivalEvents

DepartureEvents

TRANSITIONS (EVENTS):

- a : Customer arrives- s : Service starts- d : Customer departs

a

s

d

Q I

B

va

vd

PLACES (CONDITIONS):

- Q : Queue not empty- I : Server idle- B : Server busy

TRANSITION TIMING:

- a → va = {va,1, va,2, ...}- s → vs = 0 (no delay)

- d → vd = {vd,1, vd,2, ...}

Transition firesafter

specified delay

PETRI NETS


CONTINUED

15

ak : kth arrival timesk : kth service start timedk : kth departure time

πQ,k : kth time Q gets token

πI,k : kth time I gets token

πB,k : kth time B gets token

πππ

Q k k

I k k

B k k

a

d

s

,

,

,

=

==

−1

[ ]d a d v kk k k d k= + =−max , ,.1 1 2, K

a

s

d

Q I

B

va

vd

[ ]a a v

s

d v

k k a k

k Q k I k

k B k d k

= +

=

= +

−1 ,

, ,

, .

max ,π π

π

PETRI NETS


CONTINUED

ADDITION:

MULTIPLICATION:[ ]a b a b

a b a b

⊕ =⊗ = +

m a x ,

From Petri net model:

[ ]a a v a

d a v d v d

k k a k

k k a k k d k

= + =

= + + =

−

− −

1 0

1 1 0

0

0

,

, .max ,

Fix: v C v C ka k a d k d, , , ,= , = f o r a l l = 1 2 K

Equations become: ( ) ( )( ) ( )

a a C d L L

d a C d C

k k a k-

k k d k- d

+ = ⊗ ⊕ ⊗ − − = −∞

= ⊗ ⊕ ⊗1 1

1

MAX-PLUS ALGEBRA


16

In matrix form:a

d

C L

C C

a

dk

k

a

d d

k

k

+

−

⎡

⎣⎢

⎤

⎦⎥ =

−⎡

⎣⎢

⎤

⎦⎥⎡

⎣⎢

⎤

⎦⎥

1

1

Define:x Ak

k

k

a

d d

a

d

C L

C C=

⎡

⎣⎢

⎤

⎦⎥ =

−⎡

⎣⎢

⎤

⎦⎥

+ 1,

Get a “linear” system - in the max-plus sense:

x A x xk kaC

+ = =⎡

⎣⎢

⎤

⎦⎥1 0 0

,

MAX-PLUS ALGEBRA


CONTINUED

Queueing model:

A(t)B(t)

x(t)

Specify A(t) and B(t) as stochastic processes

Obtain the probability distribution of x(t):

πk(t) = P[x(t) = k], k = 0,1,2...

Many performance metrics of interest are expressed interms of πk(t)

QUEUEING THEORY


CONTINUED

17

Need “simple” models for A(t) and/or B(t) (e.g., Poisson processes)

Even for the simplest model, assuming the simplestpossible A(t), B(t): πk(t) is solution of a modified Bessel function !⇒ only steady-state solutions generally possible

For queueing networks, only a limited class of models can be solved⇒ limited complexity can be handled

Queueing theory is intended to be descriptive, not prescriptive, i.e., given a model and control policies:

DO ANALYSIS → OBTAIN PERFORMANCE (if possible)

→ CHECK IF OBJECTIVES ARE MET

but not: given objectives, what is the “best” control policy?

QUEUEING THEORY


…is simply a computer-based implementation of the DES state trajectory generation mechanism described so far

STATEx TIME

t

RANDOM VARIATEGENERATOR

SCHEDULEDEVENT LIST

e2 t2

...

e1 t1UPDATE TIME

t' = t1UPDATE STATE

x' = f(x,e1)

x'

INITIALIZE

DELETE INFEASIBLE(ek, tk)

x'

ADD NEW FEASIBLE(ek, t' +vk)

AND RE-ORDER

t'

new event lifetimes vk

t'

DISCRETE EVENT SIMULATION


18

t0

x0 = 0

e1 = a

x0 = 1

t1

e2 = a

x0 = 2

t2

e3 = a

x0 = 3

t3

x0 = 2

t1a

t4d

t2a

x0 = 2

e4 = d

t4

t4d

t3a

t5a

t4d SCHEDULEDEVENT LIST

(EVENT CALENDAR)

SCHEDULEDEVENT

SCHEDULEDTIME

DISCRETE EVENT SIMULATION - EXAMPLE


DISCRETE EVENT SIMULATIONFOR TRANSACTION-BASED SYSTEMS


General state-based models do not exploit structure of transaction-based system

Use queueing model paradigm instead with modeling“blocks” such as “queues”, “servers”, “switches”, etc.

Evaluate system PERFORMANCE through standard metrics:

SIMEVENTS

ThroughputMean Response Time

Prob. of meeting real-time constraintsProcessor Utilizations

etc…

19

STATES

TIMEt

x(t)TIME-DRIVEN SYSTEM

Simulink

Can also handle some “events”(e.g., level crossings)

STATES

TIMEt

Level-Crossing Events

SIMULINK FOR TIME-DRIVEN SYSTEMS


STATES

s1

s2

s3

s4

TIMEtt2

e2

x(t)

t3 t4 t5

e3 e4 e5EVENTS

t1

e1

EVENT-DRIVEN SYSTEM

STATES

s1

s2

s3

s4

TIMEtt2

e2

x(t)

t3 t4 t5

e3 e4 e5EVENTS

t1

e1

EVENT-DRIVEN SYSTEM

STATES

TIMEt

x(t)TIME-DRIVEN SYSTEM

+

HYBRID SYSTEM

Simulink

SimEvents

SIMEVENTS FOR EVENT-DRIVEN SYSTEMS


20

Systems modeled at transaction level

Model semantics are event-based

Time is not treated as independent variable

SIMEVENTS Model

DISCRETE EVENT SIMULATION WITH SIMEVENTS


http://www.mathworks.com/products/simevents/

SIMEVENTS info:

Entities and Attributes

Queues and Servers

Routing Entities

Accessing Statistics

Interfaces with Simulinkand Stateflow

Underlying Engine: The EVENT CALENDAR

SIMEVENTS COMPONENTS


21

ENTITIES– Abstraction of something that requires service: TRANSACTIONS– Move through queues, servers, gates, and switches

ATTRIBUTES– Data carried by entities (e.g., Type, Destination)

SimulinkSignalLine

SIMEVENTSEntity Path

ENTITIES AND ATTRIBUTES


QUEUE-SERVER pair models delays and storage of entities– Service time of server models processing time of entities

– Queue (of possibly finite capacity) models waiting, storage

BLOCKING – Entities advance ONLY when there is a place to go

EVENT PRIORITIES - control execution order of concurrent eventse.g., two entities simultaneously accessing a server

DELAY

QUEUES AND SERVERS


22

Various network topologiescan be created

– Merge entity paths

– SCHEDULING: Selectentity from input path

– ROUTING: Select outputpath for entity

– Replicating entities

Logic for the control of entity paths can be complicated, but the use of embedded MATLAB blocks makes it easy and flexible

ROUTING ENTITIES


Statistics– Number of entities departed– Average entity delay – Utilization– Average end to end delays

(using Timer blocks)– Number of Events

Statistics and states of blocks can be accessed by means of output signal ports PERFORMANCE ANALYSIS

Block states– Number of entities in block– Entity time in block– Pending Entity (blocking status)– Timer blocks – entity end to end

delay

STATISTICAL DATA COLLECTION


23

Entities can be combined to create data structures treated as one entity– Resulting entity can maintain individual component structures for future extraction…– … or collapses so as to only maintain the data

Combining entities can be used to model synchronization

ENTITY COMBINING


Attribute values can be vectors and N-dimensional arrays

Enables processing payloads of data which can represent audio, video, image, or any large aggregate data structure

VECTOR AND MATRIX ATTRIBUTES


24

Discrete Event Subsystemblocks execute only at event times (whenever event is detected at an input port)

Multiple Event types:– Value Change– Trigger– Sample Hit– None

Example: adding two queue lengths

SimulinkTiming

SIMEVENTSTiming

DISCRETE EVENT SUBSYSTEM


Function-calls, triggers, and value changes allow interfacing between SIMEVENTS and Simulink or Stateflow– SIMEVENTS can control Stateflow chart– Stateflow can control a SIMEVENTS block

INTERFACING WITH SIMULINK AND STATEFLOW


25

Translate SIMEVENTS block events: – Entity movement– State change– 1 or 2 function calls– Enabled option

… into Function Calls:– Simulink Function-Call Subsystems– Embedded MATLAB Function block– Stateflow charts

… and back again:– Simulink function calls can trigger

SIMEVENTS blocks

EVENT TRANSLATORS


Specify timing constraintson selected events or activities(e.g., amount of time a transactioncan wait to be executed beforeconsidered useless)

Timeout violation can triggerdesirable action in the model

TIMEOUT MODELING


26

SIMEVENTS MODEL EXAMPLE


• Cassandras and Lafortune, Introduction to Discrete Event Systems (2nd Edition), Springer, 2007

• David and Alla, Petri Nets and Grafcet: Tools for Modelling Discrete Event Systems, Prentice-Hall, 1992.

• Peterson, Petri Net Theory and the Modeling of Systems, Prentice Hall, 1981

• Glasserman and Yao, Monotone Structure in Discrete-Event Systems, Wiley, 1994

• Baccelli, Cohen, Olsder, and Quadrat, Synchronization and Linearity: An Algebra for Discrete Event Systems, Wiley, 1992

• Banks, J., and J.S. Carson, Discrete Event System Simulation, Prentice-Hall, Englewood Cliffs, NJ, 1984.

• Law, A.M., and W.D. Kelton, Simulation Modeling and Analysis, McGraw-Hill, New York, 1991.

• Zeigler, B.P., Theory of Modeling and Simulation, Wiley, New York, 1976.

REFERENCES ON DISCRETE EVENT SYSTEMSAND SIMULATION


Documents

DISCRETE EVENT SYSTEM THEORY AND …msdl.cs.mcgill.ca/people/mosterman/tutorials/date08/...1 DISCRETE EVENT SYSTEM THEORY AND SIMULATION USING SIMEVENTS FOR TRANSACTION LEVEL MODELING