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
• Reading an Event Graph
• Event Graph Enrichments
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
Relationships between Events
Elements of a Simulation
A
A B
Relationships between Events
• Scheduling and Cancelling
• Conditions
• Time Delays
A Bt
(i)
Event Graph Modeling
A Bt
(i)
Whenever event A occurs,
Event Graph Modeling
A Bt
Whenever event A occurs, if condition (i) is true,
Event Graph Modeling
(i)
A Bt
(i)
Whenever event A occurs, if condition (i) is true, then event B will be scheduled to occur
Event Graph Modeling
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.
Event Graph Modeling
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.
Event Graph Modeling
(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
• Reading an Event Graph
• Event Graph Enrichments
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
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
Marking: Tokens at Scheduled Events
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
CLK = 0.0
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
CLK = 0.0
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
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
RUN ENTER LEAVESTART
{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.)
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
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)
Time Event Type Event Attributes
(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)
Time Event Type Event Attributes
(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
RUN ENTER LEAVESTART(S)
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
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)
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
RUN ENTER LEAVESTART
ta
(S>0)
(Q>0)
ts
~
~
Modeling Fundamental: You need to RESTART any resource cycle you break…
RUN ENTER LEAVESTART
ta
(S>0)
(Q>0)
ts
FIX FAILtF
tR
{S= -1}{S=1}
~
~
RUN ENTER LEAVESTART
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
RUN ENTER LEAVESTART
{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)
Whenever event A occurs, if condition (i) is true, then event B will be scheduled to occur after a delay of t.
Reading an Event Graph
Simply read the “exiting” edges of each vertex.
Single 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
A simulation run is started by having the first job enter the system.
Single 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
New jobs enter the system at random intervals.
Single 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
When a job enters, if the resource is available the job can start service.
Single 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
Once a job starts, it will leave after a service time delay.
Single 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
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?
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)~
~
~
~
131 Student ID______________________
REWORK1.MOD
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
{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
We may...Reject: the part is discardedResume: continue work on the part where left off.Restart: processing is started over.
Perhaps After -Rework: additional work is needed before work on the part can be restarted.
Some Policies for the Job being Processed
We may...Reject: the part is discardedResume: continue work on the part where left off.Restart: processing is started over.
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.
Some Policies for the Job being Processed
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.
Reduce the event graph!
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.
Reduce the event graph!
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
1. Identify “Interesting” Events - where basic state variables change (here Q and S).
2. Use Verbal Event Graphs to develop logic for conditional paths between interesting events (here Start and Finish).
Messages
1. Identify “Interesting” Events - where basic state variables change (here Q and S).
2. Use Verbal Event Graphs to develop logic for conditional paths between interesting events (here Start and Finish).
3. Eliminate Uninteresting Events using Conditional Delays
Delay = Time*Conditionpaths
Messages
1. Identify “Interesting” Events - where basic state variables change (here Q and S).
2. Use Verbal Event Graphs to develop logic for conditional paths between interesting events (here Start and Finish).
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
3.32 Breakdown 2 3,4,6
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
3.32 Breakdown 2 3,4,6
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
{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 (modifiedWhat about collecting wait in line only?)
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
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
{ID=ID+1, Q=Q+1, W[ID]=CLK}
(S)
~
~
NEXT
ID
BANK2.MOD – LIFO? Error – why?
RUN
{Q=Q-1, S=S-1}
{S=S+1,W[IN]=CLK-W[IN]}
LEAVE
(Q>0)
tsSTART
(S>0)ENTER
ta
{Q=Q+1, W[ID]=CLK}
(S) (IN)(IN)Q+1
~
~
REWORK
RUN ENTER LEAVESTART
{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.
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.)
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.