# Event Graphs

### From Sigma

m |
Current revision (17:38, 20 August 2008) (edit) (undo)m |
||

Line 55: | Line 55: | ||

Now re-read the above paragraph without looking at the figure. You will see that it is a concise description of the behavior of a queueing system. With practice, a system description can be read easily from the edges of an event graph. This is an excellent way to communicate the essential features of a simulation model and a good first step in model validation. With experience in reading event graphs, it becomes easier to detect modeling errors. This graph represents a completely defined simulation model. To run this model, only the starting and ending conditions for the run need to be specified. | Now re-read the above paragraph without looking at the figure. You will see that it is a concise description of the behavior of a queueing system. With practice, a system description can be read easily from the edges of an event graph. This is an excellent way to communicate the essential features of a simulation model and a good first step in model validation. With experience in reading event graphs, it becomes easier to detect modeling errors. This graph represents a completely defined simulation model. To run this model, only the starting and ending conditions for the run need to be specified. | ||

- | :''See also: [http://www.sigmawiki.com | + | :''See also: [http://www.sigmawiki.com/support/powerpoints/WaikinEG01andEG02.mht Event Graphs Overview] |

[[About|Back to About]] | [[About|Back to About]] |

## Current revision

The three elements of a discrete event system model are the state variables, the events that change the values of these state variables, and the relationships between the events (one event causing another to occur). An event graph organizes sets of these three objects into a simulation model. In the graph, events are represented as vertices (nodes) and the relationships between events are represented as edges (arrows) connecting pairs of event vertices. Time sometimes elapses between the occurrence of events.

The basic unit of an event graph is an edge connecting two vertices. Suppose the edge represented in below is part of an event graph. We interpret the edge between A and B as follows:

Whenever event A occurs, it might cause event B to occur.

Basically, edges represent the conditions under which one event will cause another event to occur, perhaps after a time delay.

Using this notation, we can build a model that simulates a simple waiting line with one server (e.g., a ticket booth at a theater, the drive-in window at a fast-food restaurant, etc.). For our example, we will model an automatic carwash with one washing bay. The event graph of our carwash is represented below

We will begin our examination of this graph by discussing each vertex. The RUN vertex models the initialization of the simulation, the ENTER vertex models a car entering the carwash line, the START vertex models the start of service, and the LEAVE vertex models the end of service.

The state variables chosen to describe this system are:

SERVER = the status of the washing bay (busy, idle), initially set idle.

QUEUE = the number of cars waiting in line, initially set equal to zero.

To make our model more readable, we also define the constants, IDLE=1 and BUSY=0.

Next, we will focus on the changes in the state variables, shown in braces. The simulation RUN is started by making the washing bay at the carwash available for use {IDLE=1,BUSY=0,SERVER=IDLE}. Each time a car ENTERs the line, the length of the waiting line is incremented {QUEUE=QUEUE+1}. When service STARTs, the washing bay is made busy {SERVER=BUSY} and the length of the line is decremented {QUEUE=QUEUE-1}. Whenever a car has been washed and LEAVEs the washing bay, the washing bay is again made available {SERVER=IDLE} to wash other cars.

The dynamics of an event graph model are expressed in the edges of the graph. We read an event graph simply by describing the edges exiting each vertex (out-edges). In-edges take care of themselves. Continuing with our example, we look at each edge in the figure.

The simulation RUN is started by having the first car ENTER the carwash (edge from RUN to ENTER). If the ENTERing car finds the washing bay idle, service will START immediately (edge from ENTER to START). Each time a car ENTERs the carwash, the next car will be scheduled to ENTER sometime in the future (edge from ENTER to ENTER). The START service event will always schedule a car to LEAVE after that car has been washed (edge from START to LEAVE). Finally, if there are cars waiting in line when a car LEAVEs, the washing bay will START servicing the next car right away (edge from LEAVE to START).

The self-scheduling edge (the loop) on the ENTER event is the conventional way of perpetuating successive customer arrivals to the system. There will typically be some random time delay between customer arrivals.

After looking at the carwash model, you may have guessed that the state changes for an event vertex are typically very simple. Most of the action occurs on the edges of the graph. The conditions and delays associated with the edges of the event graph are very important; it is on the graph edges that the logical flow and dynamic behavior of the model are defined. For each edge in the graph we will need to define under what conditions and after how long one event might schedule another event to occur.

We will associate with each edge a set of conditions that must be true in order for an event to be scheduled. Also associated with each edge will be a delay time equal to the interval until the scheduled event occurs. Time will be measured in minutes for our examples. We have enriched the basic event graph to include edge conditions and edge delay times (see below). This edge is interpreted as follows:

If condition (i) is true at the instant event A occurs, then event B will be scheduled to occur t minutes later.

If the condition is not true, nothing will happen, and the edge can be ignored until the next time event A occurs. You can think of an edge as nonexistent unless its edge condition is true. If the condition for an edge is always true (denoted as 1==1), the condition is left off the graph. We will call edges with conditions that are always true unconditional edges. Zero time delays for edges are not shown on the graph.

While you are learning to read event graphs, it might be a good idea to use the edge interpretation in the previous paragraph as a template for describing each edge. Once the edges in the graph are correct, the state changes associated with each vertex are typically easy to check.

Our carwash model with edge conditions and delay times is shown in below. The state variables SERVER and QUEUE are now denoted by S and Q, respectively, and the status of S is indicated by 1 or 0 ( IDLE=1, BUSY=0 ). In addition, the time between successive car arrivals (probably random) is denoted by ta and the service time required to wash a car is denoted by ts. When values of ta are actually needed, they might be obtained from a data file or generated by algorithms like those in Input Modeling

In the below figure, state changes associated with each vertex are enclosed in braces and edge conditions in parentheses. As you read the following description, identify a single edge with each sentence.

At the start of the simulation RUN, the first car will ENTER the system. Successive cars ENTER the system every ta minutes. If ENTERing cars find that the server is available (S>0), they can START service. Once cars START service, ts minutes later they can LEAVE. Whenever a car LEAVEs, if the queue is not empty (Q>0), the server will START with the next car.

Now re-read the above paragraph without looking at the figure. You will see that it is a concise description of the behavior of a queueing system. With practice, a system description can be read easily from the edges of an event graph. This is an excellent way to communicate the essential features of a simulation model and a good first step in model validation. With experience in reading event graphs, it becomes easier to detect modeling errors. This graph represents a completely defined simulation model. To run this model, only the starting and ending conditions for the run need to be specified.

*See also: Event Graphs Overview*