Queue and server blocks are storage blocks that hold entities.
Queues order entities and sort them according to queue policies.
Servers delay entities until certain conditions are met.
In a discrete-event simulation, a queue stores entities for a length of time that cannot be determined in advance. The queue attempts to output entities as soon as it can, but its success depends on whether the next block accepts new entities. An everyday example of a queue is when you stand in a line with other people to wait for some type of service to address your needs and you cannot determine in advance how long you must wait.
Distinguishing features of different queues include:
Capacity — The number of entities the queue can store simultaneously
Discipline — A feature determines which entity departs first if the queue stores multiple entities
In some cases, a queue in a model is similar to an analogous aspect of the real-world system being modeled. This kind of queue is sometimes called a physical queue. For example, you might use a queue to represent a sequence of:
People standing in line
Airplanes waiting to access a runway
Messages waiting to be sent
Parts waiting to be assembled in a factory
Computer programs waiting to be executed
In other cases, a queue in a model does not arise in an obvious way from the real-world system but instead is included for modeling purposes. This kind of queue is sometimes called a logical queue. For example, you might use a queue to provide a temporary storage area for entities that might otherwise have nowhere to go. Such use of a logical queue can prevent deadlocks or simplify the simulation.
Use the Entity Queue block to model queues.
The Entity Queue block uses these queue policies:
FIFO — The block processes the entity as first in first out.
LIFO — The block processes the entity as last in first out.
Priority — The block reads the priority from the Priority Source parameter. This parameter is a particular attribute value that the block stores based on the value of the number.
Storage blocks have event actions based on events influencing entities in the corresponding storage blocks. Each block has a set of actions particular to the block.
|Entity Generator||Entity Queue||Entity Server||Entity Terminator||Resource Acquirer|
Entity entry to queue block
Entity entry to server block
Entity entry to terminator block
Entity entry to acquirer block
Entity exit from block
Entity exit from block
Service completion of entity
Entity exit from acquirer block
Entity is blocked
Entity exit from block
Entity is blocked
Entity is preempted
This illustration shows the flow of actions as entities move through a discrete-event system simulation.
Entity entry, exit, and blocking actions are performed as part of an entity forward event.
Service completion action is performed following a timer event.
Entity termination event performs a destruction action.
For more information on event actions, see Events and Event Actions.
In a discrete-event simulation, a server stores entities for a length of time, called the service time, and then attempts to output the entity. During the service period, the block is said to be serving the entity that it stores. An everyday example of a server is a person (a bank teller, a retail cashier, etc.) with whom you perform a transaction with a projected duration.
The service time for each entity is computed when it arrives, which contrasts with the inherent unknowability of the storage time for entities in queues. If, however, the next block does not accept the arrival of an entity that has completed its service, the server is forced to hold the entity longer.
Distinguishing features of different servers include:
The number of entities it can serve simultaneously, which could be finite or infinite
Characteristics of, or the method of computing, the service times of arriving entities
Whether the server permits certain arriving entities to preempt entities that are already stored in the server
In the absence of preemption, a finite-capacity server does not accept new arrivals when it is already full. You can place a queue before each finite-capacity server, establishing a place for entities to stay while they are waiting for the server to accept them. Otherwise, the waiting entities might be stored in various different locations in the model and the situation might be more difficult for you to predict or analyze.
In some cases, a server in a model is similar to an analogous aspect of the real-world system being modeled. For example, you might use a server to represent:
A person (such as a bank teller) who performs a transaction with each arriving customer
A transmitter that processes and sends messages
A machine that assembles parts in a factory
A computer that executes programs
In some cases, a server in a model does not represent a real-world system. A common modeling technique involves a delay of duration zero, that is, an infinite server whose service time is zero, to provide a place for an entity to reside to manipulate its attributes.
Use the Entity Server block to model queues.
Common server use cases of a server include:
In a production line application, the processing unit
In a network application, the processor
You can combine Entity Queue and Entity Server blocks to model different situations:
Two queue-server pairs connected in series represent successive operations that an entity undergoes. For example, parts on an assembly line are processed sequentially by two machines.
You can alternatively model the situation as a pair of servers without a queue between them. However, the absence of the queue means that if the first server completes service on an entity before the second server is available:
The entity must stay in the first server past the end of service.
The first server cannot accept a new entity for service until the second server becomes available.
Two queue-server pairs connected in parallel, in which each entity arrives at one or the other, represent alternative operations. For example, vehicles wait in line for one of several tollbooths at a toll plaza. In this case, the model must have decision logic, possibly in the form of a switch preceding this pattern.
Two queue-server pairs connected in parallel, in which a copy of each entity arrives at both, represent a multicasting situation such as sending a message to multiple recipients. Note that copying entities might not make sense in some applications.
Two queues connected in series might be useful if you are using entities to model items that physically experience two distinct sets of conditions while in storage. For example, additional inventory items that overflow one storage area have to stay in another storage area in which a less well-regulated temperature affects the items’ long-term quality. Modeling the two storage areas as distinct queue blocks facilitates viewing the average length of time that entities stay in the overflow storage area.
Two queues connected in parallel, in which each entity arrives at one or the other, represent alternative paths for waiting. The paths might lead to different operations, such as a line of vehicles waiting for a tollbooth and a line of vehicles waiting on a jammed exit ramp of the freeway. You might model the tollbooth as a server and the traffic jam as a gate.
Multicast mode enables multiple queues to receive entities from
one Entity Multicast block. The receiving block for
an Entity Multicast blocks is a Multicast Receive
Queue block whose Tag parameters have
the same value. The Multicast Receive Queue block is
essentially the Entity Queue block with the Entity
Arrival source parameter set to
Using the Entity Multicast block requires no connecting lines. The Tag parameters just need to match.
From the SimEvents® library, drag the Entity Multicast and Multicast Receive Queue blocks.
In both dialog boxes, in the Multicast tag parameters,
enter the same text. For example,
The software uses these tags to match the broadcaster and broadcastees.
This is example shows entities broadcast to two queues. Notice that the FIFO blocks for both queues have the A tag.
Resources are commodities shared by entities in your model. They are independent of entities and attributes, and can exist in the model even if no entity exists or uses them. Resources are different from attributes, which are associated with entities and exist or disappear with their entity.
For example, if you are modeling a restaurant, you can create tables and food as resources for customer entities. Entities can access resources from types of resources. For more information on resources, see Model with Resources.