An M/M/1 Queuing Model That Uses Resources

In Chapter 2, Overview of SAS Simulation Studio, an M/M/1 queueing system was used to model a simple banking system with one teller to illustrate some of the basic concepts involved in building models in Simulation Studio. In this section the same system is modeled with the resource facilities provided by Simulation Studio. In this modeling scenario, the bank teller is the resource required by the customers. These two examples demonstrate the conceptual difference between a stationary resource and a mobile resource. All blocks used in these models can be found in the Standard and Resource templates provided in Simulation Studio.

To summarize the modeling requirements for this banking system, these models assume that customers arrive at the bank at a rate of 10 per hour (so that the interarrival time between customers is a sample from the exponential distribution with a mean of 6 minutes). Customers wait in a single line on a first-come, first-served basis. The models also assume that the teller has a service rate of 12 customers per hour (so that the service time for each customer is a sample from the exponential distribution with a mean of 5 minutes).

Figure 9.1 shows the original version of the model from Chapter 2, Overview of SAS Simulation Studio. The bank teller (represented by the Server block) is a stationary resource in the original model and is created during the model building phase. As a stationary resource, the bank teller never flows or moves throughout the model. A customer arrives at the bank teller, the bank teller services the customer, and the customer moves on—in this case exiting the system.

Figure 9.1 An M/M/1 Queueing Model
An M/M/1 Queueing Model

Figure 9.2 shows the same system modeled by using resources. The following description of the model highlights the functionality of the model and does not describe all of the details for the individual blocks used in the model. See Appendix A, Templates, for more information about the individual blocks.

The customer arrival process is the same as in the original model—an Entity Generator block creates customers and sends them to a FIFO Queue block to wait for service. In this second model, however, the bank teller is modeled as a mobile resource. Mobile resources are special entity objects; therefore, they must be created at run time. For this model, a new resource entity type named BankTellers is created by using the Entity Types dialog box. (See Chapter 8, Entities, for information about creating new entity types.) Figure 9.3 shows the attributes associated with the BankTellers resource entity type.

Figure 9.2 An M/M/1 Queueing Model That Uses Resources
An M/M/1 Queueing Model That Uses Resources

Figure 9.3 BankTellers Entity Type
BankTellers Entity Type

In the Block Properties dialog box for the Entity Generator block labeled "Create Teller," the BankTellers entity is selected from the drop-down list in the Name field of the EntityTypes tab, as shown in Figure 9.4.

Figure 9.4 EntityTypes Tab in Block Properties for Create Teller Dialog Box
EntityTypes Tab in Block Properties for Create Teller Dialog Box

You can also change the default attribute values for the BankTeller entity type in the EntityTypes tab.

In the Attributes tab of the Block Properties for Create Teller dialog box, you set the Maximum Number of Entities field value to 1, since the model requires only one bank teller. (See Figure 9.5.) The bank teller resource must be created before the simulation clock begins to advance. Therefore, you need to set the Start Time property to 0 and also select the At Start Time option in the First Entity Creation area. As soon as the bank teller resource entity is created, it is sent to a Resource Pool block (Teller Pool) to wait until it is needed by a customer.

Figure 9.5 Block Properties for Create Teller Dialog Box
Block Properties for Create Teller Dialog Box

In this example, a Seize block (Seize Teller), Resource Pool block (Teller Pool), Delay block (Hold Teller), and Release block (Release Teller) work together to mimic the functionality of the Server block (Teller) in the original model. When a customer entity arrives at the FIFO Queue block, the FIFO Queue block notifies the Seize Teller block that a customer is waiting. The Seize Teller block then checks whether the bank teller resource entity is available in the Teller Pool block. If it is not available, the customer entity stays in the queue. If the bank teller resource is available, the Seize Teller block accepts the customer entity from the Queue block, pulls the bank teller resource entity from the Teller Pool block, and attaches it to the customer entity. The customer entity is then sent to the Hold Teller block where the customer entity (along with the bank teller resource entity) resides until its service is completed, and then it is routed on to the Release Teller block. The Release Teller block then extracts the bank teller resource entity from the customer entity and sends the customer entity to the Disposer block to exit the model. The bank teller resource entity is routed back to the Teller Pool block.

A quick inspection of the values in the NumberHolder blocks in both models at the end of a simulation run reveals that both the original model and the new resource model produce the same results.

Why would you use this modeling paradigm over the simpler model depicted in the original bank teller model that made use of the Server block? Some modeling capabilities that mobile resources offer over stationary resources include:

  • seizing multiple resources simultaneously

  • preempting resources

  • releasing partial resources

  • routing resources to various locations

  • keeping statistics on select resources with specific attributes

In general, mobile resources offer more modeling flexibility and options, at a cost of additional modeling complexity and possibly run-time performance.

The resource-based banking system model is also an example of a closed system where resources are reused throughout the model execution. In some models of open systems, such as one where the resources are parts used to assemble a larger component, the resources leave the system as part of the larger component and the resource inventory potentially needs to be replenished during the simulation execution.