4.7 Modeling Systems with Routing Sequences

A network of queues can be thought of as a set of stations, where each station represents a service facility. In the simple case, each service facility might have a single queue feeding into a resource. In the most general case, customers may arrive to any station within the network from outside the system. Customers then proceed from station to station to receive service. After receiving all of their service requirements, the customers depart the system.

In general the customers, do not take the same path through the network and for a given customer type, the path may be deterministic or stochastic in nature. For example, consider the case of a job shop manufacturing setting. Each product that is manufactured may require a different set of manufacturing processes, which are supplied by particular stations (e.g. drilling, milling, etc.). As another example, consider a telecommunications network where packets are sent from some origin to some destination through a series of routers. In each of these cases, understanding how many resources to supply so that the customer can efficiently traverse the network at some minimum cost is important. As such, queuing networks are an important component of the efficient design of manufacturing, transportation, distribution, telecommunication, computer, and service systems. Figure 4.93 illustrates the concept of a network of stations for producing a vacuum cleaner.

Vaccum cleaner manufacturing system as a network of stations

Figure 4.93: Vaccum cleaner manufacturing system as a network of stations

The analytical treatment of the theory associated with networks of queues has been widely examined and remains an active area for theoretical research. It is beyond the scope of this text to discuss the enormous literature on queuing networks. The interested reader is referred to the following texts as a starting point, (Gross and Harris 1998), (Kelly 1979), (Buzacott and Shanthikumar 1993), or Bolch et al. (2006).

A number of examples have already been examined that can be considered queuing networks (e.g. the Tie-Dye T-Shirts and the LOTR’s Ring Making examples). The purpose of this section will be to introduce some constructs that facilitate the simulation of queuing networks. Since a queuing network involves the movement of entities between stations, the use of the STATION, ROUTE, and SEQUENCE modules from the Advanced Transfer template panel will be emphasized.

4.7.1 Computer Test and Repair Shop Example

Consider a test and repair shop for computer parts (e.g. circuit boards, hard drives, etc.) The system consists of an initial diagnostic station through which all newly arriving parts must be processed. Currently, newly arriving parts arrive according to a Poisson arrival process with a mean rate of 3 per hour. The diagnostic station consists of 2 diagnostic machines that are fed the arriving parts from a single queue. Data indicates that the diagnostic time is quite variable and follows an exponential distribution with a mean of 30 minutes. Based on the results of the diagnostics, a testing plan is formulated for the parts. There are currently three testing stations 1. 2, 3 which consist of one machine each. The testing plan consists of an ordered sequence of testing stations that must be visited by the part prior to proceeding to a repair station. Because the diagnosis often involves similar problems, there are common sequences that occur for the parts. The company collected extensive data on the visit sequences for the parts and found that the sequences in Table 4.3 constituted the vast majority of test plans for the parts.

Table 4.3: Test plan sequences
Test Plan % of Parts Sequence
1 25% 2,3,2,1
2 12.5% 3,1
3 37.5% 1,3,1
4 25% 2,3

For example, 25% of the newly arriving parts follow test plan 1, which consists of visiting test stations 2, 3, 2, and 1 prior to proceeding to the repair station.

The testing of the parts at each station takes time that may depend upon the sequence that the part follows. That is, while parts that follow test plan’s 1 and 3 both visit test station 1, data shows that the time spent processing at the station is not necessarily the same. Data on the testing times indicate that the distribution is well modeled with a lognormal distribution with mean, \(\ \mu\), and standard deviation, \(\sigma\) in minutes. Table 4.4 presents the mean and standard deviation for each of the testing time distributions for each station in the test plan.

Table 4.4: Testing and repair distributions
Test Plan Testing Time Parameters Repair Time Parameters
1 (20,4.1), (12,4.2), (18,4.3), (16,4.0) (30,60,80)
2 (12,4), (15,4) (45,55,70)
3 (18,4.2), (14,4.4), (12,4.3) (30,40,60)
4 (24,4), (30,4) (35,65,75)

For example, the first pair of parameters, (20, 4.1), for test plan 1 indicates that the testing time at test station 2 has a lognormal distribution with mean,\(\mu = 20\), and standard deviation,\(\sigma = 4.1\) minutes.

The repair station has 3 workers that attempt to complete the repairs based on the tests. The repair time also depends on the test plan that the part has been following. Data indicates that the repair time can be characterized by a triangular distribution with the minimum, mode, and maximum as specified in the previous table. After the repairs, the parts leave the system. When the parts move between stations assume that there is always a worker available and that the transfer time takes between 2 to 4 minutes uniformly distributed. Figure 4.94 illustrates the arrangement of the stations and the flow of the parts following Plan 2 in the test and repair shop.

Overview of the test and repair shop

Figure 4.94: Overview of the test and repair shop

The company is considering accepting a new contract that will increase the overall arrival rate of jobs to the system by 10%. They are interested in understanding where the potential bottlenecks are in the system and in developing alternatives to mitigate those bottlenecks so that they can still handle the contract. The new contract stipulates that 80% of the time the testing and repairs should be completed within 480 minutes. The company runs 2 shifts each day for each 5 day work week. Any jobs not completed at the end of the second shift are carried over to first shift of the next working day. Assume that the contract is going to last for 1 year (52 weeks). Build a simulation model that can assist the company in assessing the risks associated with the new contract.

4.7.2 Conceptualizing the Model

Before implementing the model, you should prepare by conceptualizing the process flow. Figure 4.95 illustrates the activity diagram for the test and repair system. Parts are created and flow first to the diagnostic station where they seize a diagnostic machine while the diagnostic activity occurs. Then, the test plan is assigned. The flow for the visitation of the parts to the test station is shown with a loop back to the transfer time between the stations. It should be clear that the activity diagram is representing any of the three test stations. After the final test station in the test plan has been visited, the part goes to the repair station, where 1 of 3 repair workers is seized for the repair activity. After the repair activity, the part leaves the system.

Activity diagram for test and repair system

Figure 4.95: Activity diagram for test and repair system

The following pseudo-code represent the main concepts for modeling the test and repair system. This is a straight forward representation of the flow presented in the activity diagram. From the activity diagram and the pseudo-code, it should be clear that with the current modeling constructs you should be able to model this situation. In order to model the situation, you need some way to represent where the part is currently located in the system (e.g. the current station). Secondly, you need some way to indicate where the part should go to next. And finally, you need some way to model the transfer and the time of the transfer of the part between stations. This type of modeling is very common. Because of this, there are special modules that are specifically designed to handle situations like this.

    SEIZE 1 diagnostic machine
    DELAY for diagnostic time
    RELEASE diagnostic machine
    determine test plan type
    determine SEQUENCE for test plan type
ROUTE for transfer time by SEQUENCE to STATION Test

    SEIZE appropriate test machine
    DELAY for testing time
    RELEASE test machine
DECIDE IF not at last station
        ROUTE for transfer time by SEQUENCE to STATION Test
        ROUTE for transfer time by SEQUENCE to STATION Repair

BEGIN PROCESS Repair Process 
    SEIZE repair worker from repair worker set
    DELAY for repair time
    RELEASE repair worker
RECORD statistics

The pseudo-code introduces some new concepts involving sequences, routes, and stations. The next section introduces these very useful constructs.

4.7.3 STATION, ROUTE, and SEQUENCE Modules

Entities typically represent the things that are flowing through the system. Entity transfer refers to the various ways by which entities can move between modules. As we have previously seen, the STATION and ROUTE modules facilitate the transfer of entities between stations with a transfer delay. The SEQUENCE module defines a list of stations to be visited.


The SEQUENCE module is a data module that defines an ordered list of stations. The list represents the natural order in which the stations will be visited, if transferred using the ROUTE module with the By Sequence option. In addition to defining a list of stations, a SEQUENCE permits the listing of a set of assignments (e.g. ASSIGN modules) to be executed when the transfer occurs.

Unlike our previous use of the STATION and ROUTE module, we may need to know where (at which station) the entities are in order to provide appropriate processing logic. Entities have a number of special purpose attributes that are useful when modeling with the SEQUENCE, STATION, and ROUTE modules. The Entity.Station and Entity.CurrentStation keep track of the location of the entity within the model. The attribute, Entity.CurrentStation is updated to the current station whenever the entity passes through the STATION module. This attribute is not user assignable, but can be used (read) in the model. It will return the station number for the current station of the entity or 0 if the entity is not currently at a station. In addition, every entity has an Entity.Station attribute, which returns the entity’s station or destination. The Entity.Station attribute is user assignable. It is (automatically) set to the intended destination station when an entity is transferred (e.g. via a ROUTE module). It will remain equal to the current station after the transfer or until either changed by the user or affected by another transfer type module (e. g. ROUTE module). Thus, the modules attached to a STATION module are conceptually at the station location.

In many modeling contexts, entities will follow a specific path through the system. In a manufacturing job shop, this is often called the process plan. In a bus system, this called a bus route. In the test and repair system, this is referred to as the test plan. To model a specify path through the system, the SEQUENCE module can be used. A sequence consists of an ordered list of job steps. Each job step must indicate the STATION associated with the step and may indicate a series of assignments that must take place when the entity reaches the station associated with the job step. Each job step can have an optional name and can give the name of the next step in the sequence. Thus, a sequence is built by simply providing the list of stations that must be visited.

Each entity has a number of special purpose attributes that facilitate the use of sequences. The Entity.Sequence attribute holds the sequence that the entity is currently following or 0 if no sequence has been assigned. The ASSIGN module can be used to assign a specific sequence to an entity. In addition, the entity has the attribute, Entity.JobStep, which indicates the current step within the sequence that the entity is executing. Entity.JobStep is user assignable and is automatically incremented when a transfer type module (e.g. ROUTE) is used with the By Sequence option. Finally, the attribute (Entity.PlannedStation) is available and represents the number of the station associated with the next job step in the sequence. Entity.PlannedStation is not user-assignable. It is automatically updated whenever Entity.Sequence or Entity.JobStep changes, or whenever the entity enters a station.

In the test and repair example, STATION modules will be associated with the diagnostic station, each of three test stations, and with the repair station. The work performed at each station will be modeled with a PROCESS module using the (SEIZE, DELAY, and RELEASE) option. The four different test plans will be modeled with four sequences. Finally, ROUTE modules, using the By Sequence transfer option will be used to transfer the entities between the stations with a UNIF(2,4) transfer delay time distribution in minutes. Other than the new modules for entity transfer this model is similar to previous models. This model can be built by following these steps:

  1. Define 5 different resources (DiagnosticMachine, TestMachine1, TestMachine2, TestMachine3, RepairWorkers) with capacity (2, 1, 1, 1, 3) respectively.

  2. Define 2 variables (vContractLimit, vMTBA) with initial values (480 and 20) respectively. These variables represent the length of the contract and the mean time between arrivals, respectively.

  3. Define 3 expressions (eDiagnosticTime, eTestPlanCDF, and eRepairTimeCDFs). eDiagnosticTime should be expo(30), eTestPlanCDF should be DISC(0.25, 1, 0.375, 2, 0.75,3, 1.0,4). In this distribution 1, 2, 3, 4 represents the four test plans. Finally, eRepairTimeCDFs should be an arrayed expression with four rows. Each row should specify a triangular distribution according to the information given concerning the repair time distributions (e.g. TRIA(30,60,80).

  4. Use the SEQUENCE module on the Advanced Transfer panel to define four different sequences. This is illustrated in Figure 4.96. First, double click on the SEQUENCE module to add a new sequence (row). The first sequence is called TestPlan1Seq. Then, add job steps to the sequence by clicking on the Steps button. Figure 4.96 shows the five job steps for test plan 1 (TestStation2, TestStation3, TestStation2, TestStation1, and RepairStation). Typing in a station name defines a station for use in the model window. Since every part must visit the repair station before exiting the system, RepairStation has been listed last in all the sequences.

    For each job step, define an assignment that will happen when the entity is transferred to the step. In the test and repair system, the testing time depends upon the job step. Thus, an attribute, myTestingTime, can be defined so that the value from the pertinent lognormally distributed test time distribution can be assigned. In the case illustrated, myTestingTime will be set equal to a random number from a LOGN(20, 4.1) distribution, which represents the distribution for test station 2 on the first test plan. The myTestingTime attribute is used to specify the delay time for each of the PROCESS modules that represent the testing processes.

  5. Finally, define a set to hold the sequences so that they can be randomly assigned to the parts after they visit the diagnostic machine. To define a Sequence set, you must use the Advance Set module on the Advance Process panel. Each of the sequences should be listed in the set as shown in Figure 4.97. The set type should be specified as Other. Unfortunately, the build expression option is not available here and each sequence name must be carefully typed into the dialog box. The order of the sequences is important.

Defining sequences, job steps, and assignments

Figure 4.96: Defining sequences, job steps, and assignments

Defining an advanced set to hold the sequences

Figure 4.97: Defining an advanced set to hold the sequences

Now that all the data modules have been specified, you can easily build the model using the flow chart modules. The completed model can be found in the book support files associated with chapter called, RepairShop.doe. Figure 4.98 presents an overview of the model. The pink colored modules in the figure are the STATION and ROUTE modules. A CREATE module is used to generate the parts needing testing and repair with a mean time between arrivals of 20 minutes exponentially distributed. Then, the entity proceeds through an ASSIGN module where the attribute, myArriveTime, is set to TNOW. This will be used to record the job’s system time. The next module is a STATION module that represents the diagnostic station, see Figure 4.99.

Overview of the test and repair model

Figure 4.98: Overview of the test and repair model

Modeling the diagnostics station with a STATION module

Figure 4.99: Modeling the diagnostics station with a STATION module

After passing through the STATION module, the entity goes through the diagnostic process. Following the diagnostic process, the part is assigned a test plan. Figure 4.100 shows that the test plan expression holding the DISC distribution across the test plans is used to assign a number 1, 2, 3, or 4 to the attribute myTestPlan. Then, the attribute is used to select the appropriate sequence from our previously defined set of test plan sequences. The sequence returned from the set is assigned to the special purpose attribute, Entity.Sequence, so that the entity can now follow this sequence.

Assigning the test plans

Figure 4.100: Assigning the test plans

The part then enters the ROUTE module for sending the parts to the testing stations. Figure 4.101 illustrates the ROUTE module. This module allows a time delay in the route time field and allows the user to select the method by which the entity will be transferred. Choosing the By Sequence option indicates that the entity should use its assigned sequence (via the Entity.Sequence attribute) to determine the destination station for the route. The entity’s sequence and its current job step are used. When the entity goes into the ROUTE module, Entity.JobStep is incremented to the next step. The entity’s Entity.Station attribute is set equal to the station associated with the step and all attributes associated with the step are executed. Then, the entity is transferred (starts the delay associated with the transfer). After the entity completes the transfer and enters the destination station, the entity’s Entity.CurrentStation attribute is updated.

Selecting the By Sequence option within the ROUTE module

Figure 4.101: Selecting the By Sequence option within the ROUTE module

In the example, the part is sent to the appropriate station on its sequence. Each of the stations used to represent the testing stations follow the same pattern (STATION, PROCESS (seize, delay, release), and ROUTE). The PROCESS module (Figure 4.102) uses the attribute, myTestingTime, to determine the delay time for the testing process. This attribute was set when the entity’s job step attributes were executed.

PROCESS module for the testing process

Figure 4.102: PROCESS module for the testing process

After proceeding through its testing plan, the part is finally routed to the RepairStation, since it was the station associated with the last job step. At the repair station, the part goes through its repair process by using the expression eRepairTimeCDFs and its attribute, myTestPlan, as shown in Figure 4.103.

PROCESS module for the repair process

Figure 4.103: PROCESS module for the repair process

The ASSIGN module after the repair process module simply computes the entity’s total system time in the attribute, mySysTime, so that the following two RECORD modules can compute the appropriate statistics as indicated in Figure 4.104.

RECORD modules for test and repair model

Figure 4.104: RECORD modules for test and repair model

4.7.4 Running the Test and Repair Model

Now the model is ready to set up and run. According to the problem, the purpose of the simulation is to evaluate the risk associated with the contract. The life of the contract is specified as 1 year (52 weeks \(\times\) 5 days/week \(\times\) 2 shifts/day \(\times\) 480 minutes/shift = 249,600 minutes). Since the problem states that any jobs not completed at the end of a shift are carried over to the next working day, it is as if there are 249,600 minutes or 4,160 hours of continuous operation available for the contract. This is also a terminating simulation since performance during the life of the contract is the primary concern. The only other issue to address is how to initialize the system. The analysis of the two situations (current contract versus contract with 10% more jobs) can be handled via a relative comparison. Thus, to perform a relative comparison you need to ensure that both alternatives start under the same initial conditions. For simplicity, assume that the test and repair shop starts each contract alternative under empty and idle conditions. Let’s assume that 10 replications of 4,160 hours will be sufficient as illustrated in Figure 4.105.

Run setup specification for test and repair shop model

Figure 4.105: Run setup specification for test and repair shop model

As shown in Figure 4.106, for the current situation, the probability that a job completes its testing and repair within 480 minutes is about 82%. The addition of more jobs should increase the risk of not meeting the contract specification. You are asked to analyze the new contract’s risks and make a recommendation to the company on how to proceed within the exercises.

User defined statistics for current contract

Figure 4.106: User defined statistics for current contract

In the test and repair example, the time that it took to transfer the parts between the stations was a simple stochastic delay (e.g. UNIF (2,4) minutes). The STATION, ROUTE, and SEQUENCE modules make the modeling of entity movement between stations in this case very straightforward. In some systems, the modeling of the movement is much more important because material handling devices (e.g. people to carry the parts, fork lifts, conveyors, etc.) may be required during the transfer. These will require an investigation of the modules within the Advanced Transfer Panel. This topic will be taken up in Chapter 7.


Bolch, G., S. Greiner, H. de Meer, and K. Trivedi. 2006. Queueing Networks and Markov Chains. 2nd ed. John Wiley & Sons.
Buzacott, J. A., and J. G. Shanthikumar. 1993. Stochastic Models of Manufacturing Systems. Prentice-Hall.
Gross, D., and C. M. Harris. 1998. Fundamentals of Queueing Theory. 3rd ed. New York: John Wiley & Sons.
Kelly, F. P. 1979. Reversibility and Stochastic Networks. John Wiley & Sons.