Overview of Queues and Servers in Discrete-Event Simulation

In a SimEvents^® model, the Entity Queue and the Entity 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.

This example model represents a simple queuing system that generates entities, and queues them in a specified order, services them to change their attributes, and terminates them to represent their departure from the line. To learn more about basic queuing systems, see Model Basic Queuing Systems.

Storage with Queues

In a discrete-event simulation, an Entity Queue block stores entities for a length of time that cannot be determined in advance. The queue attempts to output entities when possible, but its output depends on whether the downstream block accepts new entities.

An everyday example of a queue is people waiting in line for a store register. A shopper cannot determine in advance how long they must wait to complete their purchase.

For example, a queue can represent the behavior of:

• 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

• Cars waiting in line in a gas station

To define the behavior of a queue, specify:

• Capacity — The number of entities a queue can store simultaneously.

• Queue Sorting Policy — Specifies which entity departs first such as first-in-first-out (FIFO), last-in-first-out (LIFO), or custom priority, if the queue stores multiple entities.

• Overwriting policy — Determines behavior when the queue is full. You can choose to block a new incoming entity or accept it to overwrite the oldest entity in the queue.

For more information about queue behavior, see Model Basic Queuing Systems.

Storage with Servers

In a discrete-event simulation, a server stores entities for a length of time, called the service time, then attempts to output the entity. During the service period, the block is serving the entity that it stores.

An everyday example of a server is a person (such as a bank teller or a retail cashier) with whom you perform a transaction with a projected duration. For more information, see Model Basic Queuing Systems.

The service time for each entity is computed when the entity arrives. However, if 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.

The distinguishing features of a server include:

• The number of entities it can serve simultaneously, which can be finite or infinite.

• The characteristics of, or the method of computing, the service times of arriving entities.

• Whether the server permits arriving entities to preempt entities that are already stored in the server. For more information, see Task Preemption in a Multitasking Processor.

Tip

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 to establish 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 locations in the model and the behavior might be more difficult for you to predict or analyze.

You can use a server to represent real-world systems such as:

• 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

• The processing unit in a production line application

• The processor in a network application

In some cases, a server 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 Events and Event Actions in Queuing Systems

You can use events and event actions to manipulate entity attributes and create custom behavior in your queueing system. For more information about event actions, see Events and Event Actions.

Suppose that you want to change entity attributes when entities enter or exit the Entity Queue or the Entity Server block. You can use actions that are invoked by events such as entry to a block, exit from a block, or service completion. For more information, see Model Basic Queuing Systems. You can also use event actions to create custom entity routing patterns. For more information, see Use Queue Event Actions to Model a Storage Tank.

Serial Queue-Server Pairs

Connecting two queue-server pairs in series can represent successive operations on an entity. For example, you can model how parts on an assembly line are processed sequentially by two machines.

Alternatively, you can model the same scenario by using a pair of servers without a queue between them.

However, in the absence of a queue, if the first server completes its service on an entity, and if the second server is available to accept a new entity:

• 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.

Connecting two queues in series might be useful if you are using entities to model items that experience two distinct sets of physical conditions while in storage. For example, additional inventory items that overflow one storage area have to stay in another storage area where 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. For more information, see Model Basic Queuing Systems.

Parallel Queue-Server Pairs as Alternatives

Connecting two queue-server pairs in parallel, in which entities are routed to one or to the other queue-server pair, can represent alternative operations. For example, you can model how vehicles wait in line for one of several tollbooths at a toll plaza. In this case, the model must have a decision logic, possibly in the form of a switch that precedes this pattern. For an example, see Serve High-Priority Customers by Sorting Entities Based on Priority.

Connecting two queue-server pairs in parallel, in which a copy of each entity arrives at each, can represent a multicasting scenario, such as sending a message to multiple recipients. Note that copying entities might not make sense in some applications. For an example, see Broadcast Entities Using Entity Multicasting.

Author Custom Storage Blocks Using MATLAB Discrete-Event System Block and Discrete-Event Chart

If you want to model more complex entity storage blocks and extend the behavior of the blocks provided by the SimEvents library, use the MATLAB Discrete-Event System block and Discrete-Event Chart block.

The MATLAB Discrete-Event System block extends System objects to create custom SimEvents blocks in your model. For more information about authoring custom SimEvents blocks, see Create Custom Blocks Using MATLAB Discrete-Event System Block.

The Discrete-Event Chart block uses Stateflow^® charts and provides a graphical language to create custom storage blocks in your model. For more information, see Flush Entities from a Queue-Server.