2.10 How Arena Manages Entities and Events
This section will provide a conceptual model for how Arena processes the entities. The discussion in this section is based in large part on the discussion found in (Schriber and Brunner 1998). To get a more detailed step by step view of Arena’s operation, I recommend using the Arena Run Controller as noted in Appendix D.2. The Arena Run Controller facilitates the tracking and tracing of entities as they move through the system. This section should help build a solid conceptual understanding for how entities are processed.
The processing of entities within Arena is based on a process-oriented view. The modeler describes the life of an entity as it moves through the system. In some sense, the system processes the entities. The entities enter the system (via CREATE modules), get processed (via various flow chart modules), and then depart the system (via DISPOSE modules). The entities act as transactions or units of work that must be processed. As the entities move through the processing they cause events to occur that change the state of the system. In addition, the entities cause future events to be scheduled.
There is a direct mapping of entity movement to event processing. Simulation languages have a construct called the event calendar that holds the events that are scheduled to occur in the future. This is similar to your own personal work calendar. Future events are placed on the calendar and as time passes, the event’s alarm goes off, then the event is processed. In discrete event modeling, the clock gets updated only when an event happens, causing the system to move through time. The movement of entities cause the events to be scheduled and processed.
According to (Schriber and Brunner 1998) there are two phases for processing events: the entity movement phase (EMP) and the clock update phase (CUP). The clock update phase is straightforward: when all events have been processed at the current time, update the simulation time to the time of the next scheduled event and process any events at this new updated time. The processing of an event corresponds to the entity movement phase. Thus, a key to understanding how this works is to understand how entities move within a model. One thing to keep in mind throughout this discussion is that only one event can be processed at a time. That is, only one entity can be moving at a time. It may seem obvious but if only one entity can be moving at a time, then all the other entities are not moving. However, the entities that are not moving have different reasons, given their current state.
(Schriber and Brunner 1998) divide the life of an entity into five states:
Active State The active state represents the entity that is currently being processed. The entity that is currently moving is in the active state. We call the entity in the active state, the active entity. To use a rugby analogy, the active entity is the one with the ball. The active entity keeps running through the model (with the ball) until it encounters some kind of delay. The active entity then gives up the ball to another entity and transitions into an alternative state. The new active entity (with the ball) then starts moving through the model.
Ready State Entities in the ready state are ready to move at the current simulation time. In the rugby analogy, they are ready to receive the ball so that they can start running through the model. There can be more than one entity in the ready state. Thus, a key issue that must be understood is how to determine which of the ready entities will receive the ball, i.e. start moving next. Ready state entities transition into the active state.
Time Delayed State Entities in the time delayed state are entities that are scheduled to transition into the ready state at some known future time. Time delayed entities have an event scheduled in the event calendar. The purpose of the event is to cause the entity to transition into the ready state. When the active entity executes an operation that causes a delay, such as the delay within a PROCESS module, an event is scheduled and the active entity is placed in the time delayed state.
Condition Delayed State Entities in the condition delayed state are waiting for a specific condition within the model to become true so that they can move into the ready state. For example, an entity that is waiting for a unit of a resource to become available is in the condition delayed state. When the condition causing the waiting is removed, the entity movement phase logic will evaluate whether or not the condition delayed entity becomes a ready state entity. This processing will occur automatically.
Dormant State The dormant state represents the situation where the an entity is not waiting on time or a condition that can be automatically processed within the model. The dormant state represents the situation where specialized logic must be added to the model in order to cause the entity to transition from the dormant state to the ready state.
Figure 2.73 illustrates how an entity can transition between the five states, based on Figure 24.9 of (Schriber and Brunner 1998). As illustrated in the figure, when an entity is created, it is placed in the Ready state or the Time Delayed state. CREATE modules place entities in the Time Delayed state and the SEPARATE module place entities in the READY state. An entity in the Ready state can only become active. The active entity can transition into the Ready state, any of the three delay states (Time Delayed, Condition Delayed, and Dormant), or be destroyed (DISPOSE). Any of the three delay states (Time Delayed, Condition Delayed, and Dormant) may transition to the Ready state.
Figure 2.73: Illustration of entity state transitions
When an entity is not the active entity, it must be held somewhere in memory. Entities that are in the ready state are held in the current events list (CEL). The current events list holds all the entities that are candidates to start moving at the current time. The list is processed in a first in first out manner. Entities can be placed on the CEL in four major ways:
The entity was a time delayed entity and they are now scheduled to move at the current time
The entity was a condition delayed entity and the blocking condition has been removed.
The entity was in the dormant state and the user executed logic to move the entity to the CEL.
The entity executed a SEPARATE module that duplicates the active entity. The duplicates are automatically placed on the CEL and become ready state entities.
Entities that are in the time delayed state are in the future events list (FEL). When an entity executes a module that schedules a future event, the entity is placed in the delayed state and held in the FEL. Entities in the condition delayed state are held in a delay list (DL) that is tied to the condition. Delay lists map to queue constructs within the model. For example, the PROCESS module with the SEIZE, DELAY, RELEASE option automatically defines a QUEUE that holds the entities that are waiting for the resource. There can be many delay lists within the model at any time. For example, the BATCH module’s queue is also a delay list.
Finally, entities that are in the dormant state are held in user managed lists (UML). In these are queues that are not tied to a specific condition. HOLD modules allow for an “infinite hold” option, which defines a user managed list. Thus, the entities within the model can be in a number of different states and be held in different lists as they are processed. Table 2.18 illustrates that many entities can be in the model at the same time in and each entity will be in a state and a list.
| IDENT | Entity.SerialNumber | Size | Weight | ProcessingTime | State | List |
|---|---|---|---|---|---|---|
| 1 | 1001 | 2 | 33 | 20 | Active | - |
| 2 | 1002 | 3 | 22 | 55 | Ready | CEL |
| 3 | 1003 | 1 | 11 | 44 | Time Delayed | FEL |
| 4 | 1001 | 2 | 33 | 20 | Ready | CEL |
| 5 | 1004 | 5 | 10 | 14 | Condition Delayed | DL |
| 6 | 1005 | 4 | 14 | 10 | Dormant | UML |
The entity movement phase and clock update phase within can be summarized with the following steps:
Remove entity at the top of the CEL and make it active
Allow active entity to move through model
If the active entity makes any duplicates, they are placed on the top of CEL. They will be last in first out among the ready state entities, but first in first out among themselves.
If the active entity removes any entities from user defined lists they will be placed last in first out order on the CEL
When the active entity stops moving, the entities on the CEL are processed, the top entity is selected and made active and allowed to move. This repeats until there are no more active entities in the CEL.
When there are no more entities on the CEL, the EMP logic checks to see if any conditions have changed related to entities that are in the condition delayed state. Any qualifying condition delayed entities are transferred to the CEL and it is processed as previously described. When there are no more entities on the CEL and no qualifying condition delayed entities, the clock update phase begins.
The clock update phase causes simulated time to be advanced to the next event on the FEL and initiates the processing of the FEL.
When processing the FEL, the logic removes any entities on the FEL that are scheduled to occur at the current time. The time delayed entities are moved from the FEL to the CEL. If there is more than one entity scheduled to move at the current time the entities are placed last in first out on the CEL. There is one caveat here. may use an internal entity to effect logic within the model. An example internal entity is the entity that is scheduled to cause the simulation to end. Internal entities will be processed immediately, without being placed on the CEL.
When there are no more entities to process, the simulation will automatically stop.
This discussion should provide you with a basic understanding of how entities are processed. If you can better conceptualize what is happening to each entity, then you can better verify that your model is working as intended.
Why does understanding entity processing matter? There are some common modeling situations that happen automatically, for which you may need to understand the default processing logic. (Schriber and Brunner 1998) discuss three of these modeling situations. Here we will just mention one case. Suppose that a customer releases a resource and then immediately tries to seize the resource again. What happens? As outlined in (Schriber and Brunner 1998) there are three logical possibilities:
Immediately upon the release, the resource is allocated to a waiting customer. Since the active entity is not a waiting customer, it cannot be allocated to the resource.
The allocation of the resource does not occur until the active entity stops moving. Thus, it would be a contender for the resource.
The releasing entity recaptures the resource immediately, without regard to any other waiting entities.
These three possibilities seem perfectly reasonable. What does Arena do? The first option is done automatically in Arena. If this is not the behavior that you desire then you may have to implement special logic.