|On this page…|
See also the example in Build a Discrete-Event Model, which illustrates how to create a queue-server pair and view statistics such as server utilization.
Here are some examples of ways to combine FIFO Queue and Single 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.
While you might alternatively model the situation as a pair of servers without a queue between them, 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 and 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.
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.
A similar example is in Example of a Logical Queue, except that the example there does not suggest any physical distinction between the two queues.
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 modeled 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.
Suppose you are modeling a queue that can physically hold 100 entities and you want to determine what proportion of the time the queue length exceeds 10. You can model the long queue as a pair of shorter queues connected in series. The shorter queues have length 90 and 10 (open modelmodel).
Although the division of the long queue into two shorter queues has no basis in physical reality, it enables you to gather statistics specifically related to one of the shorter queues. In particular, you can view the queue length signal (#n) of the queue having length 90. If the signal is positive over a nonzero time interval, then the length-90 queue contains an entity that cannot advance to the length-10 queue. This means that the length-10 queue is full. As a result, the physical length-100 queue contains more than 10 items. Determining the proportion of time the physical queue length exceeds 10 is equivalent to determining the proportion of time the queue length signal of the logical length-90 queue exceeds 0.
The subsystem described in Lesson 3: Add Event-Based Behavior includes an Infinite Server block that serves each entity for a random amount of time. The random duration is the value of a signal that serves as an input to the Infinite Server block. Similarly, the Single Server block can read the service time from a signal, which enables you to vary the service time for each entity that arrives at the server.
Some scenarios in which you might use a varying service time are as follows:
You want the service time to come from a random number generator. In this case, set the Single Server block's Service time from parameter to Signal port t and use the Event-Based Random Number block to generate the input signal for the Single Server block. Be aware that some distributions can produce negative numbers, which are not valid service times.
You want the service time to come from data attached to each entity. In this case, set the Single Server block's Service time from parameter to Attribute and set Attribute name to the name of the attribute containing the service time. An example is in the figure below.
To learn more about attaching data to entities, see Set Entity Attributes.
You want the service time to arise from dynamics of the simulation. In this case, set the Single Server block's Service time from parameter to Signal port t and create a signal whose value at the time an entity arrives at the server is equal to the desired service time for that entity.
If the signal representing the service time is an event-based signal such as the output of a Get Attribute block, ensure that the signal's updates occur before the entity arrives at the server. For common problems and troubleshooting tips, see Unexpected Use of Old Value of Signal.
Open the model that you created in Build a Discrete-Event Model, or enter simeventsdocex('doc_dd1')simeventsdocex('doc_dd1') in the MATLAB® Command Window to open a prebuilt version of the same model. By examining the Single Server block's Service time from and Service time parameters, you can see that the block is configured to use a constant service time of 1 second. To use a random service time instead, follow these steps:
Set Service time from to Signal port t. This causes the block to have a signal input port labeled t.
From the Signal Generators sublibrary of the Generators library, drag the Event-Based Random Number block into the model window and connect it to the Single Server block's signal input port labeled t.
Run the simulation and note how the plot differs from the one corresponding to constant service times (shown in Results of the Simulation).