INTRODUCTION TO EVENT GRAPH MODELS Definition - The basic building block. Model Dynamics Reading an Event Graph Event Graph Enrichments.

INTRODUCTION TO

EVENT GRAPH MODELS

• Definition - The basic building block.

• Model Dynamics

• Reading an Event Graph

• Event Graph Enrichments

BANK1.MOD

RUN ENTER LEAVESTART(S)

ta

{Q=Q+1}

(S>0)

{S=S-1,Q=Q-1} {S=S+1}

(Q>0)

ts~

~

If want to Close Doors at tc

Quiz: Why won’t this work?

~

(CLK<tc)

1. In REWORK model, we put a rework job back in original queue... What happens?2. Move (REWORK,ENTER) edge back to (REWORK,START). What if LEAVE REWORK and ENTER events are simultaneously scheduled and the LEAVE event is executed next... In what order should all the other events be executed before the next clock advance?

RUN ENTER LEAVESTART

{S=1}

(Q, P)

ta

{Q=Q+1}

(S>0)

{S=0,Q=Q-1} {S=1}

(Q>0)

ts

tr

REWORK

(S>0)(RND<P)~

~

~

~

Distinguishing Features of Simulation

• Time (CLK) DYNAMICfocused on this aspect during the modeling section of the course

• Pseudorandom variables (RND) STOCHASTICwill focus on this aspect in coming weeks

Motivation

Graphical techniques can provide exceptional modeling power

Mappings between representations Permit alternative implementations Enhance logic checking Aid in model communication Translate analytical methods and

conditions

Modeling Paradigms• State Models - Markov Chains, Queues

and Event Relationship Graphs• Petri Nets - Activity Scanning

and Event Relationship Graphs

• Block Flow Diagrams - Process Interaction and Event Relationship Graphs

• Event Graphs – model relationships between the changes in system state or rules.

INTRODUCTION TO

EVENT GRAPH MODELS

• Definitions - The basic building block.

• Model Dynamics



Elements of a Discrete Event Simulation

Variables that describe the state

Events that change the state

Relationships between Events

Variables that describe the stateEvents that change the state


Elements of a Simulation

A

A B


• Scheduling and Cancelling

• Conditions

• Time Delays

A Bt

(i)

Event Graph Modeling

A Bt

(i)

Whenever event A occurs,


A Bt

Whenever event A occurs, if condition (i) is true,


(i)

A Bt

(i)

Whenever event A occurs, if condition (i) is true, then event B will be scheduled to occur


A Bt (i)

Whenever event A occurs, if condition (i) is true, then event B will be scheduled to occur after a delay of t.


A Bt

(i)



(often / will be used instead of ~ for arc conditions)

What about simultaneously scheduled events? priorities associated with edges

Indirect state changes that occur when testing edge conditions (the curse of C and Java programmers)

Sequence Issues

A Bt

(i)

1. Execute State Changes for current event.2. Then test conditions for all exiting edges. 3. Finally compute delay times and schedule

destination events for all true edges.

Execution Sequence

EVENT EXECUTION SEQUENCE(may differ slightly for different simulation languages)

1. Evaluate any "parameters" for the event (eg. which machine starts?).

2. Perform all state changes defined for the event.

3. Test ALL conditions for scheduling or canceling other events.

4. For ALL true conditions:

4.1 Cancel ALL events that are to be cancelled

4.2. For ALL events that are to be scheduled

4.2.1. Evaluate the attributes of the event to be scheduled

4.2.2. Evaluate the times that the event will be scheduled

4.2.3. Schedule the event

INTRODUCTION TO

EVENT GRAPH MODELS

• Definition - The basic building block.

• Model Dynamics



Single Resource Model• Variables

R = Number of ResourcesR = 0: Resource is busyR > 0: Resource is idle

Q = Number of jobs waiting in line (initially = 6)• Timing Data

ta = interarrivals ts = service times

• Events– Jobs ENTER the system every ta time units– START servicing the job taking ts time units– Jobs LEAVE the system

Single Resource Model

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts


RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

Marking: Tokens at Scheduled Events


RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 0.0


RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 0.0


RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 0.0

Q, The Number of Jobs Waiting

Time

Q=7

67

0

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 0.0

Time

Q = 7

0

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 0.0

Time

Q = 7

0

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 0.0 (Say, for example, that ta = 5.5)

Time

Q = 7

0

0

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 0.0

5.5 0

Time

Q = 7

0

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

CLK = 0.0

5.5

Time

Q = 6

0

ts

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 0.0 (Say, for example, that ts = 2.3)

5.5

Time

Q = 6

0

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 0.0

5.5 2.3

Time

Q = 6

0

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 2.3

5.5

Time

Q = 6

0 2.3

Q, The Number of Jobs Waiting

Time

Q=6

67

0

5

2.3

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 2.3

5.5

Time

Q = 6

0 2.3

2.3

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

Which Event is Executed Next? When?

5.5 2.3

Time

Q = 6

0 2.3

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

What is the value of Q after the next event?

5.5 2.3

Time

Q = 6

0 2.3

Time

Q = 5

0 2.3

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

CLK = 2.3

5.5

ts

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 2.3

5.5

Assume that ts = 1.8. QUIZ: When is the LEAVE scheduled?

Time

Q = 5

0 2.3

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 2.3

5.5 4.1

Time

Q = 5

0 2.3

LEAVE is scheduled at CLK +1.8 =2.3 +1.8 = 4.1

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

ENTER

ta

ts

CLK = 4.1

5.5

0

Time

Q = 5

2.3 4.1 (Q>0)

4.1

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

Quiz: For what range of service times, ts , would Q=5 before Q=3?(i.e., a customer ENTERs before the next service START?)

5.5

CLK = 4.1

0

Time

Q= 4

2.3 4.1

4.1

• Say, for example that the next service time is equal to 1.5.

• Thus the next LEAVE will be scheduled to occur at 4.1 + 1.5 = 5.6.

• The next ENTER event was scheduled at time, 5.5 so it happens next.

• Q will then increase from 4 to 5.

The Service Time Needs to be Greater than 1.4.

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts5.5

CLK = 4.1

0

Time

Q= 4

2.3 4.1

(Say, for example, now ts = 1.5)

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts5.5

CLK = 4.1

0

Time

Q= 4

2.3 4.1

5.6

RUN(Q)

START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

CLK = 5.5

0

Time

Q= 5

2.3 4.1 5.5

5.6

Let’s review the sequence of Events and watch how the clock and output changed as the Events occur.

Q = The Number of Jobs Waiting in Line

Time

Q = 6

0

RUN

67

54

3

2

1

Time

Q = 7

0

ENTER

67

54

3

2

1

Time

Q = 6

0

START

67

54

3

2

1

Time

Q = 6

2.30

LEAVE

67

54

3

2

1

Time

Q=5

2.30 4.1

START

67

54

3

2

1

Time

Q=5

2.30 4.1

LEAVE

67

54

3

2

1

Time

Q=4

2.30 4.1

67

54

3

2

1

START

Time

Q=5

2.30 4.1

67

54

3

2

1

ENTER

5.5

Time

2.30 4.1

67

54

3

2

1

Aside: Time Average Statistics

5.5

TAV{Q} = Ave height = area/length

Q

• Easy to Build Simple Models

• Very Restrictive Modeling Assumptions

• Powerful Analytical Development

• Suffers from the “Curse of Dimensionality”

State Machines

State Machine

1 2 3 40

Graph with Vertices Representing State Values

eg: A Single Server Queue

State MachineGraph with Vertices Representing State Values

eg: A Single Server Queue

1 2 3 40

Customer Arrival rate

Customer Departure rate

State MachineGraph with Vertices Representing State Values

Marking: Single Token At Current State (Start at 0)

1 2 3 40

State MachineArrival Event Occurs (State = 1)

1 2 3 40

State MachineAnother Arrival Occurs (State = 2)

1 2 3 40

1 2 3 40

State Machine Departure Event Occurs Next (State again is 1)

State Machine Arrival Occurs (State is 2)

1 2 3 40

Arrival Occurs (State is 3)

State Machine

1 2 3 40

1 2 3 40

State Machine Departure Occurs (State again is 2)

State Diagram (Single Server Queue)

1 2 3 40

Single Resource QueueVertices in State Machine Representing State Values

1 2 3 40

Edges represent Changes in State

Arrive

Depart

1 2 3 40

Reduced Event Graph for Single Server Queue

Q = number in system.

ARRIVE FINISH

{Q=Q+1} {Q=Q-1}

(Q= =1)

(Q>0)

ta tsts

QUIZ: Modify this EG for R Identical Parallel Resources.

ARRIVE FINISH

{Q=Q+1} {Q=Q-1}

(Q= =1)

(Q>0)

ta tsts

What is Reduced EGM for a Multiple (say R) Servers?

Note: Can still model any level of congestion with a single integer variable

ARRIVE FINISH

{Q=Q+1} {Q=Q-1}

(Q= =R)

(Q≥R)

ta tsts

Single Resource Event Graph Condenses into a Single Vertex

DEPART

(Q==0)

(Q>0)

ts

ta+ t

s

{Q = Q - 1 + A}

A = Number of Arrivals During a Service Epoch

Weather Model(Assume independence)

S = Sunny DayS = Sunny Day

C = Cloudy DayC = Cloudy Day

S C

Two Day Weather Patterns

S = Sunny DayS = Sunny Day

C = Cloudy DayC = Cloudy Day

K classes, N-Day Dependence…KN States

SS SC

CS CC

2 classes, 2-Day Dependence

Homework*: How many vertices for aK class, N dependent model?

Change

tS ~ (S) (C) ~

tC

tS = number of Sunny Days

Event Graph Daily Weather Model (any Markov Process)

Day

History

(W)

1

EVENT OCCURANCES

Advance TIME

Change the STATE

EVENT OCCURANCES

Advance TIME - Graph Edges

Change the STATE - Vertices

EVENT OCCURANCES

Advance TIME - Graph Edges

Change the STATE - Vertices

Tied together into a Model by the Event Graph

Minimalist Approach

Discrete Event Simulations model boththe passage of Time and Uncertainty....SIGMA has two basic variables.

• CLK Current simulated clock time. For modeling dynamics.

• RND Randomly chosen number, greater than 0 and less than 1. For modeling randomness.

Figure 2.7: Verbal Event Graph of a Single Server Queue

Initializethe RUN

Customer ENTERSystem

Customer LEAVEsSystem

Customer STARTsService

(Are Customers Waiting?)

(Is Server Idle?)~

ta

~

ts

ta

t s

= Time Between Customer Arrivals (Possibly Random)

= Time to Service a Single Customer (Possibly Random)

Figure 2.4: Simple Event Graph of a Carwash


{Idle=1,Busy=0,Server=Idle}

{Queue=Queue+1} {Server=Busy, Queue=Queue-1}

{Server=Idle}

What actually happens?

Scheduled events are on the Pending Events list, which acts as the “appointment book” for the system.

PENDING EVENTS LIST

Time Event Priority String of Attributes

3.32 Breakdown 2 3,4,6

4.52 Finish 3 3,4,6

5.42 Arrival 1 7

5.42 Finish 3 2,5,1

(Aside: “Future” Events List is a bad name…events are not necessarily in the future – may be now.)



PENDING EVENTS LIST



4.52 Finish 3 3,4,6

5.42 Arrival 1 7

5.42 Finish 3 2,5,1

Tool 3, Worker 4, Part 6

Part 7

Figure 2.2: Main Event Scheduling Algorithm

Cancel Events

Initialize

Advance Clock to Time of Next Event

Execute Event

Remove Event From List

State

Event List

Change State

Schedule Events

Summary StatisticsStop YesNo

Table 2.1: Future Events List for a System with Three Machines (Number everything starting with 0...) Time, CLK = 3.00 ARRIVAL event just executed Scheduling the next ARRIVAL at 3.37

Time Event Type Event Attribute (machine)

(Current time) 3.00 ARRIVAL

3.20 FINISH 0

3.35 BREAKDOWN 1

3.37 ARRIVAL

3.40 FINISH 1

3.43 REPAIRED 2

9.01 BREAKDOWN 0 Of the 3 machines – two are busy and one broken – why?

Table 2.2: Future Events List for a System with Three Machines(CLK = 3.20 FINISH event executed, scheduling the

next START event “now”).

Time Event Type Event Attributes

(Current time) 3.20 FINISH 0

3.20 START 0

3.35 BREAKDOWN 1

3.37 ARRIVAL

3.40 FINISH 1

3.43 REPAIRED 2

9.01 BREAKDOWN 0

Table 2.3: Future Events List for a System with Three Machines (CLK = 3.20 START event schedules FINISH at 4.40)


(Current time) 3.20 START 0

3.35 BREAKDOWN 1

3.37 ARRIVAL

3.40 FINISH 1

3.43 REPAIRED 2

4.40 FINISH 0

9.01 BREAKDOWN 0

Table 2.4: Future Events List for a System with Three Machines (CLK = 3.35 BREAKDOWN 1 cancels FINISH and schedules a REPAIRED event for machine 1)


(Current time) 3.35 BREAKDOWN 1

3.37 ARRIVAL

3.43 REPAIRED 2

4.40 FINISH 1

8.35 REPAIRED 1

9.01 BREAKDOWN 0

A B

Whenever event A occurs, if condition (i) is true, then cancel the next scheduled event B, if any.

Event Canceling

(i)

Event Cancelling

Event Canceling Options in SIGMA:

1. Next scheduled (FIFO to break ties)

2. All events of this type

3. Only specific events of this type with matching event parameters (more later)

BANK1.MOD


ta

{Q=Q+1}

(S>0)

{S=S-1,Q=Q-1} {S=S+1}

(Q>0)

ts~

~

What if want to Close Doors at tc?

BANK1.MOD


ta

{Q=Q+1}

(S>0)

{S=S-1,Q=Q-1} {S=S+1}

(Q>0)

ts~

~

If want to Close Doors at tc

Quiz: Why won’t this work?

~

(CLK<tc)

ENTER LEAVESTART

ta

{Q=Q+1}

(S>0)

{S=S-1,Q=Q-1} {S=S+1}

(Q>0)

ts~

~

RUN

CLOSE

{S=1}tc

(Q, tc)

Want to Close Doors at tc?

CLOSEIT.MOD

Exercise: Read this Graph

How might we model a Failure/Reject policy where we discard active job when failure occurs?

tF is the time until failure (again, never use TBF, why?)

tR is the time to repair


ta

(S>0)

(Q>0)

ts

~

~

Modeling Fundamental: You need to RESTART any resource cycle you break…


ta

(S>0)

(Q>0)

ts

FIX FAILtF

tR

{S= -1}{S=1}

~

~


ta

(S>0)

(Q>0)

ts

FIX FAIL

tR

(Q>0)

~

~

~tF

Modeling Fundamental: You must initially schedule every strongly connected event graph component.

BRKDN.MOD


{S=1}

(Q)

ta

{Q=Q+1}

(S>0)

{S=0,Q=Q-1}

{S=1}

(Q>0)

ts

FIX FAIL

tF

tR

{S= -1}{S=1}

(Q>0)

~

~

~tF

A Bt

(i)


Reading an Event Graph

Simply read the “exiting” edges of each vertex.


RUN START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

A simulation run is started by having the first job enter the system.


RUN START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

New jobs enter the system at random intervals.


RUN START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

When a job enters, if the resource is available the job can start service.


RUN START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

Once a job starts, it will leave after a service time delay.


RUN START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

Whenever a job leaves, if there is more work waiting, then service can start on the next job.

Putting the “edge” sentences together...

A simulation run is started by having the first job enter the system. New jobs enter the system at random intervals. When a job enters, if the resource is available the job can start service. Once a job starts, it will leave after a service time delay. Whenever a job leaves, if there is more work waiting, then service can start on the next job.

…we have a concise system description.

A simulation run is started by having the first job enter the system. New jobs enter the system at random intervals. When a job enters, if the resource is available the job can start service. Once a job starts, it will leave after a service time delay. Whenever a job leaves, if there is more work waiting, then service can start on the next job.

Multiple Resource Model?

RUN START LEAVE

{R=1} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

What if there were 5 identical resources ?

RUN START LEAVE

{R=5} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

Five resources are now available to work in parallel.

Multiple Resource Model

Batched Service Model?

RUN START LEAVE

{R=5} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(R>0)

(Q>0)

ENTER

ta

ts

B is the process batch size

Batched Service Model

RUN START LEAVE

{R=5} {Q=Q+1} {R=R-1,Q=Q-B}

{R=R+1}

(R>0&Q>=B)

(Q>=B)

ENTER

ta

ts

B is the process batch size

Flexible Batched Service?

RUN START LEAVE

{R=5} {Q=Q+1} {R=R-1,Q=Q-1}

{R=R+1}

(Q>0)

ENTER

ta

ts

B,b are Max and Min Process Batch Size

(R>0)

RUN START LEAVE

{R=5} {Q=Q+1} {R=R-1,Q=Q-min(B,Q)}

{R=R+1}

(Q>=b)

ENTER

ta

ts

B,b are Max and Min Process Batch Size

(R>0&

Q>=b)

Flexible Batched Service

1. In REWORK model, we put a rework job back in original queue... What happens?2. Move (REWORK,ENTER) edge back to (REWORK,START). What if LEAVE REWORK and ENTER events are simultaneously scheduled and the LEAVE event is executed next... In what order should all the other events be executed before the next clock advance?


{S=1}

(Q, P)

ta

{Q=Q+1}

(S>0)

{S=0,Q=Q-1} {S=1}

(Q>0)

ts

tr

REWORK

(S>0)(RND<P)~

~

~

~

131 Student ID______________________

REWORK1.MOD


{S=1}

(Q, P)

ta

{Q=Q+1}

(S>0)

{S=0,Q=Q-1} {S=1}

(Q>0)

ts

tr

REWORK

{Q=Q+1}(S>0)(RND<P)~~

~

~

SLOFAST0.MOD

RUN

{S[0]=S[0]-1,Q=Q-1} {S[0]=S[0]+1}

LEAVE0START0

(Q>0)

ts[0]

CHECK

(S[0]>0)

ARRIVE

ta

{Q=Q+1}

{S[1]=S[1]-1,Q=Q-1} {S[1]=S[1]+1}

LEAVE1START1

(Q>0)

ts[1]

(S[0]<=0 &S[1]>0)

{S[0]=1, S[1]=1}

~

~

~~

ASSEMKIT.MOD

RUN KIT PACKOPRN3

{S=1}

(P)

(S>0)

{S=0,Q[3]=Q[3]-1} {S=1}

(Q[3]>0)

ts

OPRN1

t1

t2

OPRN2

(Q[2]>=P & Q[1]>0)

{Q[1]=Q[1]+1}

{Q[2]=Q[2]+1}

(Q[2]>=P)

{Q[1]=Q[1]-1,Q[2]=Q[2]-P,Q[3]=Q[3]+1

~

~

~~

PERT Example - Table 5.3: Activity Precedence for a Project

Activity Must Follow Activities

COUNTER[I]

A None 0

B A 1

C None 0

D B and C 2

E B and D 2

F C 1

END_A

END_C

END_D

END_F

END_B END_E

DoneStart

PERT CHART FOR PROJECT Initialize Ni with number of predecessors

State change is Ni=Ni-1, Conditions Ni== 0Generate edge delay times in vertices!!!

A{Z=W}

{Z=Q}

~

~(X>Y)

(XY)

If-Then-Else: Event Graph or Boolean Variables

{Z=(X>Y)*W + (XY)*Q}

A...Or...

BUFFERQ.MOD

RUN

{S=1}

(Q, B)ARRIVE

ta

(Q<B)

{S=0,Q=Q-1} {S=1}

LEAVESTART

(Q>0)

tsENTER

{Q=Q+1}

(S>0)

~ ~

~

BUFFERQ.MOD (Using Boolean Variables)

RUN

{S=1}

(Q, B)

ta

{S=0,Q=Q-1} {S=1}

LEAVESTART

(Q>0)

tsENTER

{Q=Q+(Q<B)}

(S>0)

~

~

Modeling Resource Failures

Most languages offer some method for modeling failure and repair using:

TTF = time to failureTTR = time to repair

Most languages do not offer many options of what to do with the job when a failure occurs.

Notes:

1. Do NOT use exponential TTF with PMs - “lack of memory”

- “infinite tail”

2. Do NOT use TBF = time between failures - this data is often available, but can cause “queued failures” where resources can fail when the are already broken! or worse, Broken Tools Failing !

Basic Questions:

1. Is TTF in “working” time or “clock” time? - clock time is common but nonsense. How do you know it failed if it is idle?

2. What happens to the job being processed when the resource fails?

Basic Questions:

1. Is TTF in “working” time or “clock” time? - clock time is common but nonsense. How do you know it failed if it is idle?

2. What happens to the job being processed when the resource fails?

These are often not even answered in the Language Documentation!

We may...Reject: the part is discardedResume: continue work on the part where left off.Restart: processing is started over.

Some Policies for the Job being Processed


Perhaps After -Rework: additional work is needed before work on the part can be restarted.



Perhaps After -Rework: additional work needs to be done before work on the part can be restarted....Or...Reroute: Have another resource finish the work.


RESOURCE FAILURE WITH RESUME (update PT after TTF)(Note: assumed only one failure per part! min{TF)>max{TP})

START EVENT (with comments){S = 0, / Make server unavailableQ = Q - 1, / Remove job from queuePT = TP, / Generate job processing timeFAIL = (TTF<=PT), / Is there a failure during processing?TTF=(FAIL= =0) *(TTF-PT) / No failure - decrement Time To Failure + (FAIL= =1)*(TF-(PT-TTF)) / Failure - set new Time To Failure

PT = (FAIL= =0)*PT / No failure: process job + (FAIL= =1)*(PT + TR), / Failure: resume processing after repair

{S=1,

TTF = TF}

PT

(Q>0)

{S =1}

(S>0)

{Q=Q+1}

ta

EnterRun Start Finish

(See text)

TP = processing timeTF = time to failureTR = time to repair

Once a Resource Starts a Job, if it does not fail it will Finish in PT

Verbal EG of Resource Cycle

PTFinishStart

...OR...

(Not Fail)~

It Fails in TTF .

(Fail)

TTF

Fail

~PTFinishStart

~

(Not Fail)

It is Repaired

(Fail)

TTF

Fail

PTFinishStart

~

RepairTTR

~(Not Fail)

Job May be Reworked

(Fail)

TTF

Fail

~(Not Fail)PTFinishStart

~

RepairTTR

ReworkTw

(Rework) ~~

NoRework

(NoRework)

Job is then finished or discarded

(Fail)

TTF

Fail

~(Not Fail)

PT-TTF

FinishStart

~

RepairTTR

Reject

Resume

Restart

PT

~

~

~

PT

(Restart)

(Resume)

(Reject)

ReworkTw

(Rework) ~~

NoRework

(NoRework)

Fundamental Idea:Focus only on “interesting” events in the Resident Entity Cycles changes in fundamental state variables.

Here S = resource state = 0/1 = busy/idleQ = number of jobs waiting

Key Idea:Focus only on “interesting” events in the Resident Entity Cycles changes in fundamental state variables

Here S = resource state = 0/1 = busy/idleQ = number of jobs waiting

Eliminate Uninteresting events usingConditional Delays between Interestingevents.

Only the Start and the Finish Events are “Interesting”

(Fail)

TTF

Fail

~(Not Fail)

PT-TTF

FinishStart

~

RepairTTR

Reject

Resume

Restart

PT

~

~

~

PT

(Restart)

(Resume)

(Reject)

ReworkTw

(Rework) ~~

NoRework

(NoRework)

Key Idea:To model Resident Entity Cycle We Need To Compute only the Delay from Start to Finish.

Reduce the event graph!

Key Idea:To model Resident Entity Cycle We Need To Model only the Delay from Start to Finish.


The Delay time until a Resource becomes free is the Conditional Length of the Path from Start to Finish.

Key Idea:To model Resident Entity Cycle We Need To Model only the Delay from Start to Finish.


The Delay time until a Resource becomes free is the conditional length (in time) of the path from Start to Finish

Delay = Time*(Boolean Conditions)paths

We define the Boolean, FAIL = (TTFPT)

(Fail)

TTF

Fail

~(Not Fail)

PT-TTF

FinishStart

~

RepairTTR

Reject

Resume

Restart

PT

~

~

~

PT

(Restart)

(Resume)

(Reject)

ReworkTw

(Rework) ~~

NoRework

(NoRework)

(NoRework)

(Fail)

TTF

Fail

~(Not Fail)

PT-TTF

FinishStart

~

RepairTTR

Reject

Resume

Restart

PT

~

~

~

PT

Delay=(FAIL==0)*PT...

(Restart)

(Resume)

(Reject)

ReworkTw

(Rework) ~~

NoRework

(Fail)

TTF

Fail

~(Not Fail)

PT-TTF

FinishStart

~

RepairTTR

Reject

Resume

Restart

PT

~

~

~

PT

Delay=(FAIL==0)*PT+((FAIL)*(TTF+TTR+(Rework)*Tw+...

(Restart)

(Resume)

(Reject)

ReworkTw

(Rework) ~~

NoRework

(NoRework)

PT-TTF

Finish

Reject

Resume

Restart

PT

~

~

~

Delay=(FAIL==0)*PT+((FAIL)*(TTF+TTR+(Rework)*Tw

+(Restart)*PT + (Resume)*(PT-TTF))

(Restart)

(Resume)

(Reject)

(Fail)

TTF

Fail

~

RepairTTR

~(Not Fail)

StartPT

ReworkTw

(Rework) ~~

NoRework

(NoRework)

Define: R = {1,2,3,4}={rework,restart,resume,reject} Q = Number of jobs waiting S = Resource Busy/idle = 0/1 ts = Processing times (random?) tF = Time to failure (random?) tR = Time to repair (random?) tW = Time to rework (random?)

{Q = Q - 1, S = S - 1,

PT = ts,

FAIL=( TTF <= PT ), DELAY = ( FAIL==0 ) * PT +( ( FAIL==1 ) * ( TTF + tR

+(R==1) * ( tW + PT ) +(R==2) * PT +(R==3) * ( PT-TTF ) ) ), TTF = ( FAIL==0 ) * ( TTF - PT ) +( ( FAIL==1 ) *( ( R==1 ) * ( tF - tW - PT ) +( R==2 ) * ( tF - PT )

+( R==3 ) * (tF - (PT-TTF) ) ) )}

FinishStart DELAY

{S = S + 1}

Note: Multiple Resources will have different TTF,TTR, etc. (use event parameters and arrays… more later)

General Resource Failure Model – Modified Start Event

Failure.mod

Messages

1. Identify “Interesting” Events - where basic state variables change (here Q and S).

Messages


2. Use Verbal Event Graphs to develop logic for conditional paths between interesting events (here Start and Finish).

Messages



3. Eliminate Uninteresting Events using Conditional Delays

Delay = Time*Conditionpaths

Messages



3. Eliminate Uninteresting Events using Conditional Delays

Delay = Time*Conditionpaths

Boolean

BUILDING VERY LARGEMODELS Using Event

Parameters

What is the difference between a COMPLEX model and a BIG model?

A B

After executing Event A, the expressions, k, are evaluated. Later, before B is executed, the variables, j, are assigned the values previously computed for k.

Event Parameters

( j )k

A B

Rigorous Edge Definition

( j )k

t (i)~

After executing event A, a vector of expressions, k, is

evaluated. If condition (i) is then true, event B will be

scheduled to occur after a delay of t with variable vector, j, initialized to the values of k computed when B was scheduled.

T values of k become the attributes of scheduled events…

PENDING EVENTS LIST (“Future” Events list is not necessarily in future)

Time Event Priority Attributes


4.47 Finish 3 3,4,6

5.64 Arrival 4 7 Part number 7 5.64 Finish 3 2,5,1

Tool 3, worker 4, part 6

T values of k become the attributes of scheduled events…

PENDING EVENTS LIST (“Future” Events list is not necessarily in future)

Time Event Priority Attributes


4.47 Finish 3 3,4,6

5.64 Arrival 4 7 Part number 7 5.64 Finish 3 2,5,1

Tool 3, worker 4, part 6

The “attributes” for the edge that scheduled the Breakdown event are expressions for the values for the “parameters”, (Tool,Worker,Part)

I+1

EVENT (I)

~ (I < 7)

(I = = 7)

~2

Do EVENT: FOR I = 2 to 7

Do EVENT FOR I = 2 to 7 and J = 0 to I

I+1 , 0

EVENT (I,J)

~ ( I < 7 & J = = I )

~

I , J+1

~

( I 7 & J < I )

2 , 0

( I 7 & J I )

CLKA B(j)

10

1

CLKA B(j)

10

1

CLKA B(j)

10

1

What does Future Event List look like at time 13?

Recall SLOFAST0.MOD with two classes of serversWhat is particularly weak about this model? (say, for 1000 classes?)

RUN

{S[0]=S[0]-1,Q=Q-1} {S[0]=S[0]+1}

LEAVE0START0

(Q>0)

ts[0]

CHECK

(S[0]>0)

ARRIVE

ta

{Q=Q+1}

{S[1]=S[1]-1,Q=Q-1} {S[1]=S[1]+1}

LEAVE1START1

(Q>0)

ts[1]

(S[0]<=0 &S[1]>0)

{S[0]=1, S[1]=2}

~

~

~~

Simulating Many Servers of Many Different Types SLOFAST1.MOD

RUN

{S[A]=S[A]-1,Q=Q-1} {S[A]=S[A]+1}

LEAVESTART

(Q>0)

ts(A)CHECK

(S[A]>0)ARRIVE

ta

{Q=Q+1}

A(A) (A) (A)

A+1

S[A]<=0&A<N-1)

~

~

~

{N=,S[1]=,...S[N]=}

1

A

A

`

State for BANK2.MOD

Customers Waiting In Line

16 14 13 1215 11

8

10

6

Customers In Service

NEXT=11ID=15

Pending Events ListTime Type Parameters3.243 Leave 84.210 Enter5.593 Leave 66.478 Leave 10

BANK2.MOD

RUN

{Q=Q-1, S=S-1, NEXT=NEXT+1}

{S=S+1,W[IN]=CLK-W[IN]}

LEAVE

(Q>0)

tsSTART

(S>0)ENTER

ta

{ID=ID+1, Q=Q+1, W[ID]=CLK}

(S) (IN)

NEXT

(IN)ID IN

~

~

BANK2.MOD – can you simplfy? (IN not used in START)

RUN



LEAVE

(Q>0)

tsSTART

(S>0)ENTER

ta


(S) (IN)

NEXT

(IN)ID IN

~

~

BANK2.MOD (modifiedWhat about collecting wait in line only?)

RUN



LEAVE

(Q>0)

tsSTART

(S>0)ENTER

ta


(S) (IN)

~

~ NEXT

BANK2.MOD (modified – wait in queue only)

RUN

{Q=Q-1, S=S-1, W[IN]=CLK-W[IN],NEXT=NEXT+1}

{S=S+1}

LEAVE

(Q>0)

tsSTART(IN)

(S>0)ENTER

ta


(S)

~

~

NEXT

ID

BANK2.MOD – LIFO? Error – why?

RUN

{Q=Q-1, S=S-1}


LEAVE

(Q>0)

tsSTART

(S>0)ENTER

ta

{Q=Q+1, W[ID]=CLK}

(S) (IN)(IN)Q+1

~

~

REWORK


{S=1}

(Q,P,LM)

ta

{Q=Q+1}

(S>0)

{S=0,Q=Q-1} {S=1, R=RND}

(Q>0 & (R>P)

ts

tr

REWORK

{Q=Q+1}

(R<=P)

~

~

~~(S>0)

REWORK2.MOD

RUN ENTER LEAVESTART(Q,P,LM)

ta(S>0)

(Q>0 & (R>P | RW>=LM)

ts

tr

REWORK

(R<=P&RW<LM)

(RW)(RW)

1

RW RW+1

~

~

~

(RW)

RW1

LIMITED REWORK: Can rework only LM times

{S=1} {Q=Q+1} {S=0,Q=Q-1} {S=1, R=RND}

{Q=Q+1}

~(S>0)

RUN KIT PACKOPRN3

{S=1}

(P)

(S>0)

{S=0,Q[3]=Q[3]-1} {S=1}

(Q[3]>0)

ts

OPRN1

t1

t2

OPRN2

(Q[2]>=P & Q[1]>0)

{Q[1]=Q[1]+1}

{Q[2]=Q[2]+1}

(Q[2]>=P)

{Q[1]=Q[1]-1,Q[2]=Q[2]-P,Q[3]=Q[3]+1

~

~

~~

Recall ASSEMKIT.MOD with two types of components for assembly, what is particularly weak about this model? (say, for 1000 components?)

Event Parameters with an Assembly Operations

{S=S+1,Q[N]=Q[N]-1}

OPRN

t[I]

{S=1} {Q[I]=Q[I]+1}

I

(I)

{S=S-1}

KIT PACKASSEM(S) ts

(Q[N])(Q[I]>P[I] I<N)

A

{Q[I]=Q[I]-P[I] I<N,Q[N]=Q[N] +1}

A

~~

~

RUN(N,P[I]’s)

1

2

N

…

Tandem Queues

1 2 N

Q1 Q2 QN

•••

N Tandem Queues

START LEAVEENTER

N Tandem Queues

START LEAVEENTER(i) (i)

i i

i

(i)

N Tandem Queues

START LEAVEENTER

(i<N)

i+1

(i) (i) (i)i i

i

N Tandem Queues

START LEAVEENTER

1

(i=1)

(i<N)

i+1

(i) (i) (i)i i

i

N Multiple-Server Tandem Queues

N Multiple-Server Tandem Queues

ii

t

ti

(i<N)

(i==1)

i

LEAVE(i)

START(i)

ENTER(i)

1

i+1

(R[i])

(Q[i])

EG Enrichment: Model Size

N Stage Tandem Process

i+1i

i

t t

(i<N)

(i==1)

i

i

LEAVE(i)

START(i)

ENTER(i)

EG Model Enrichment - Adding to Graph

Example: Tandem Queues

tt

LEAVE(i)

START(i)

ENTER(i)

EG Model Enrichment - Adding to Graph

Example: Tandem Queues with Failures

F = Failure State Flag

tt

t

(Q&!F)

(S&!F) (Q)

(F)

LEAVE(i)

START(i)

ENTER(i)

FAIL(i)

FIX(i)

Start NextM

Enter

NextJ Finish Queue

Exit(m,j)

(m,j)(m)

(j)(j)

(m,j)

Job Shop Event Graph Model

Start NextM

Enter

NextJ Finish Queue

Exit(m,j)

(m,j)(m)

(j)(j)

(m,j)

Jobs Flowing Through System

Start NextM

Enter

NextJ Finish Queue

Exit(m,j)

(m,j)(m)

(j)(j)

(m,j)

Machines Processing Jobs

Start NextM

Enter

NextJ Finish Queue

Exit(m,j)

(m,j)(m)

(j)(j)

(m,j)

j

m,j

m,j

m,j

j

j

m

m,j

~

~~(j done)

Job Shop Verbal Event Graph

~(Q[m])

(j not done& m idle)

( j not done& m busy)

j

Event Graph Summary

General, Minimalist DEDS Modeling.

A Single Modeling Object

Completely General

– Models Turing Machine (Yucesan - Savage)

No event cancellation or parameters

Mappings from other paradigms offer alternative models (logic and efficiency)

Conditions for mappings to other paradigms can be used to establish modeling power

(i)t

A B

Complete Edge Definition

( j )k

t (i)~

After executing event A, a vector of expressions, k, is evaluated. If condition (i) is then true, event B will be scheduled to occur after a delay of t with variable vector, j, equal to those values of k.



PENDING EVENTS LIST



4.52 Finish 3 3,4,6

5.42 Arrival 1 7

5.42 Finish 3 2,5,1

(Aside: “Future” Events List is a bad name…events are not necessarily in the future – may be now.)

Figure 2.2: Main Event Scheduling Algorithm

Cancel Events

Initialize

Advance Clock to Time of Next Event

Execute Event

Remove Event From List

State

Event List

Change State

Schedule Events

Summary StatisticsStop YesNo

When to Use Event Graphs

• Very Large Scale Systems

• Complex Model Logic

• Whenever Speed and Flexibility are important

Ease of Use

Power

Tool Development

Ease of Use

Power

Tool Development

Simulators.

Languages

. .Petri Nets

Queueing.

Ease of Use

Power

Tool Development

Simulators.

Languages

. .Petri Nets

Queueing.

Ease of Use

Power

Tool Development

Simulators.

Languages

. .Petri Nets

Turing Machine

Queueing.

Ease of Use

Power

Tool Development

Simulators.

Languages

. .Petri Nets

Turing Machine

Event Graphs(Sigma)

Queueing.

ERG Applications• Teaching Simulation Languages

other languages can be written in SIGMA

• Semiconductor Manufacturing• Robotics• Banking Operations• Pharmaceutical Manufacturing• TV Spot Market Operations• Food Production and Logistics• Disease Control (Human and animal)• Sports (Golf course Management)

• Teaching Simulation Languages other languages can be written in SIGMA

• Semiconductor Manufacturing• Robotics• Banking Operations• Pharmaceutical Manufacturing• TV Spot Market Operations• Food Production and Logistics• Disease Control (Human and animal)• Sports (Golf course Management)

General Design for Cluster Tools

Load Locks: Single or Double

Single Chamber

Batch Chamber

Index Module

Robot(s): Chamber(s), Arm(s), Hand(s).

Process Modules(Chambers)

Transport Module(Robot)

Cassette Module(Load Lock)

Cluster Tool Used In Semiconductor Manufacturing

?

Start

End

Move

Startor

End

Loadlock Events

Robot Events

Chamber Processing Events

Decisions

Event Symbols

Event Graph: Generic Cluster Tool

Generic Cluster Tool Model (ref: Ding and Yi)

used for scheduling robot moves

Decision

Move

Done

tParameters

Parameters

General Electric modeled full factory with only two events

- LSC (delay the wafer with the Later Start from Cassette)

- ESC (delay wafer with the Earlier Start from Cassette)

- LSDM (delay wafer that Later Starts on Deadlock Module)

- FFDM (delay wafer Finishing First on Deadlock Module)

- MD (select wafer with Minimum Delay to break deadlock)

- LRT (select wafer with Least Remaining processing Time)

Some Wafer Delay Rules

Two Systems

System 1 Processing TimeOptimal 691 seconds,LSC/LFDM/LSDM 749 secondsLSC/LFDM 876 seconds

System 2 Processing TimeOptimal 698 secondsLSC/LSDM 708 secondsLSC/LFDM/LSDM 710 seconds

Which system is best?

(ft3)

HO

HR

HI

HCAP

HH (ft3)

HL (ft3)

HI - Hopper Input

HO - Hopper Output

HR - Net Rate

HCAP - Maximum Capacity

HH - High Probe Volume

HL - Low Probe Volume

Hopper Definitions

Bulk Flow Process Simulator

HCLP Cover Low ProbeHULP Uncover Low ProbeHCHP Cover High ProbeHUHP Uncover High Probe

HCLD Cover Low Probe Delay DPM - 1 second, BIB 3 seconds.

HULD Uncover Low Probe Delay DPM - 5 seconds, BIB 3 seconds

HCHD Cover High Probe Delay DPM and BIB - 6 seconds*

HUHD Uncover High Probe Delay DPM - 20 seconds, BIB 30,25,0r 20 sec.

* To allow conveyor to stop sending product

Hopper Events

Objective: Find Capacity - MAXT

A B(i)

Reschedule event B in t time units (from when?)

Event Rescheduling

t

Event Graph of GMI Simulation

RUN ChRate

CLP CHP

UHP

Empty

ConfigStartL

ULP

PUSH

CALL

All double arrows areRescheduling edges

SURGE VOLUME (at MAXT+)

NORTH SURGE vs TIME (190 ft3/min.)

Time

0

1

2

3

4

5

6

7

8

0 3 6 9 12 15 18

SURGE

SURGE VOLUME (at MAXT-)

NORTH SURGE vs TIME (170 ft3/min.)

Time

-1

0

1

2

3

4

5

0 1 2 3 4 5 6 7

SURGE

50% Reliable Line Run at MAXT- rate.

LINEBRK.MOD (SURGE vs Time - 0% starvatuib - 50% up)

Time

0

69

138

207

276

345

414

0 10 20 30 40 50 60 70

SURGE

LINEBRK.MOD (SURGE vs Time - 50% starvation - 50% up)

Time

0

13

26

39

52

65

78

0 10 20 30 40 50 60 70

SURGE

LINEBRK.MOD (SURGE vs Time - 50% starvation - 50% up)

Time

0

13

26

39

52

65

78

0 10 20 30 40 50 60 70

SURGE

Hopper Volume for 50% reliableDPM Line run at 1/2 MAXT rate

Run

Cash

Flow

Term

BONDRATE.MOD

Event Graph Disease Model

Clear

1

Sub-Clinical

1

Cinical

1

1

1

1

1

(S )i

(S )i

(S )i

Si = state of ith

member

H= population, treatments, and member histories

H

H

H

H

H

H

Event Graph EnrichmentsModeling

Event Graph Objects - Buss, Pierce and Nehme Qualitative Event Graphs – Ingalls Hierarchical graphs - Nehme (e.g. delay time = graph)

Analysis State Space and Event Reduction - Som, Sargent Initial Conditions Complexity Analysis - Jacobson, Yucesan Computation (bounds on events lists) Process Deadlock – Woodward and Mackulak Simultaneous Replication and Time Dilation - Hyden Response Sample Path Gradients – Freimer MIP representations

Event Graph Summary

A Simple, Completely General, Minimalist Approach To DEDS Modeling and Analysis.

An Easy Path to Discrete Event Simulation Applications and Education.

Event Graph Summary

General Applications and Education.

Many Simulation texts.

Process Language and Petri Net Emulation

Continuous Dynamics Modeling

Parametric Modeling of Large Scale Systems

Modeling Process1. Determine system and model functions.

2. Identify entities and their important attributes.

3. Identify the dynamic attributes and the events that cause their values to change .

4. Draw Event Relationship Graph.

INTRODUCTION TO EVENT GRAPH MODELS Definition - The basic building block. Model Dynamics Reading an Event Graph Event Graph Enrichments.

Documents