MODELING PRODUCTION LINES VIA INDEXED QUEUES AND RESOURCES

11.5 MODELING PRODUCTION LINES VIA INDEXED QUEUES AND RESOURCES

When models contain components with repetitive logic, then model construction can become tedious, and consequently, error-prone. A case in point is the packaging line model of Section 11.3, where component processes have analogous logic (although the parameters are different). More specifically, in each component process ( filling, cap- ping, labeling, sealing, and carton packing), units seize a resource, get processed, check if blocking occurs, and then release the corresponding resource. For models with such repetitive logic, Arena supports an efficient approach, called indexing, which largely eliminates the tedium of repetition. This approach exploits the fact that each object in Arena has an implicit integer ID number within its class; examples of object classes include such Arena constructs as queues, resources, and expressions. Thus, objects within a class can be viewed as object arrays, where individual objects are assigned an index for access and manipulation. An index is an integer that identifies the serial

240 Modeling Production Lines number of the object in the array, and as such it varies from 1 to the size of the array (the

number of objects created). Note that the array size is dynamic, and the modeler can enforce any particular order of objects in the array to facilitate indexing logic. To this end, the modeler can use the Queues, Resources, and Expressions elements from the Elements template panel, accessible from the Template Attach button in the Standard toolbar.

To illustrate the use of indexing in modeling repetitive components, we will modify the packaging line example of Section 11.3. Exploiting the Arena indexing feature, we first number all resources from 1 to 5, all resource queues from 1 to 5, and all blocking queues from 6 to 10, and then declare these objects and their indexes using the old Arena elements of Resources and Queues.

Figure 11.14 depicts the dialog box of the element called Queues Element (left) and the associated dialog box for a particular queue (right). Initially, Queues Element on the left is empty. The modeler clicks the Add button to pop up the dialog box on the right to define the relevant queue attributes for the queue selected in the Name field (here Filler Queue). The most important fields in the Queues dialog box are the index of the queue in the Arena queue array (specified in the Number field), and the queueing discipline of the queue (specified in the Ranking Criterion field). In addition, the modeler can select one of two types of specifications in the Associated Block field: either specify a (SIMAN) block with which the present queue will be associated, or enter the keyword shared, thereby signaling that the queue will be used in multiple Hold and Seize modules.

The assignment of user-specified index numbers to resources is similar. Figure 11.15 depicts the dialog box of the element called Resources Element (top) and the associated dialog box for a particular resource (bottom). Note that the Resources dialog box is handy for specifying additional information for a resource (in this case resource Filler). In addition to the resource index and name, the modeler can use the Capacity or Schedule field to enter either a static resource capacity or a schedule name governing

a dynamic time-dependent capacity. In Figure 11.15, we use the Resources dialog box merely to assign an index number to resource Filler.

Figure 11.14 Dialog boxes of Queues Element (left) and Queues (right).

Modeling Production Lines 241

Figure 11.15 Dialog boxes of Resources Element (top) and Resources (bottom).

Finally, indexing of Arena expressions in the packaging line is illustrated in Figure

11.16, which depicts the dialog box of the element called Expressions Element (left) and the associated dialog box for a particular expression (right). Expression arrays may

be vectors (one-dimensional) or matrices (two-dimensional). To specify a vector, the user enters its dimension in the 1-D Array Index field. Similarly, to specify a matrix, the user enters its dimensions in the 1-D Array Index and 2-D Array Index fields. The actual elements of the expression array are entered in sequence column by column, one expression per line. Here, the entered expressions are constants that specify processing times and buffer capacities.

The equivalent version of the Arena model of Section 11.3, modified to incorporate indexing, is depicted in Figure 11.17, where all indexed queues, expressions, and resources are shown in this order under the corresponding headings on the right side of the figure. Starting at the upper left corner, the Create module, called Create Jobs, operates exactly as module Create 1, its counterpart in Figure 11.2 (the “jobs” alluded to

242 Modeling Production Lines

Figure 11.16 Dialog boxes of Expressions Element (left) and Expressions (right).

are, of course, product units). This module generates 30 unit entities at time 0, which circulate repeatedly in the model. However, the logic of routing product units through the packaging line workstations is implemented in a manner analogous to a loop in a procedural programming language. In our case, the unit entity attribute Proc_Index keeps track of the loop's running index.

When a unit entity emerges from module Create Jobs, it proceeds to the Assign module, called Assign Process Index and Time, where its Proc_Index attribute is initialized to 1 (as well as saving the current simulation time in attribute Arr_Time for

Figure 11.17 Arena model with indexing for the packaging line system.

Modeling Production Lines 243 later collection of total flow-time observations (at the last workstation implementing the

packing process). Note that the packing line workstations model the resources Filler, Capper, Labeler, Sealer, and Packer, and these are indexed by 1, 2, 3, 4, and 5, respectively, as indicated by the list of resources under the Resources heading in Figure 11.17; the corresponding resource queues are indexed in the same way, as indicated by the list of queues under the Queues heading. Each unit entity will next be routed through the same sequence of modules, and its Proc_Index attribute will be incremented after each iteration so as to correspond to the next workstation to be visited. As will be seen, the appropriate service distribution for each workstation process will also be selected by this attribute.

The unit entity proceeds to the first module in the loop, namely, the Seize module called Seize Process. The dialog box for this module is displayed in Figure 11.18. Here, the Resources field indicates that the resource to be currently selected for seizing is specified by the current index number stored in attribute Proc_Index (initially the index is 1, which corresponds to resource Filler). The dialog box for the current resource in the loop is shown in Figure 11.19. Note that in this dialog box, the appropriate resource is selected by attribute (in the Type field), and the Attribute Name field specifies attribute Proc_Index.

Having seized the selected resource, the unit entity proceeds to the second module in the loop, namely, the Delay module called Processing Time. The dialog box for this module is displayed in Figure 11.20. Here, the Delay Time field indicates that a delay time for this module is the value at the current index position (saved in attribute Proc_Index) of the ProcTimes expression vector (recall that this expression vector was initialized previously, as illustrated in Figure 11.16).

Once the unit entity completes its delay and emerges from the Processing Time module, its processing at the current workstation is also complete. It now needs to make the following decision:

Figure 11.18 Dialog box of the first module (Seize) in the loop.

244 Modeling Production Lines

Figure 11.19 Dialog box of the current resource in the loop.

1. If this workstation (process) is not the last in the sequence, then proceed to the next workstation in the loop. Since the last process (packing) has index number 5, this is equivalent to checking whether Proc_Index < 5.

2. Otherwise (i.e., Proc_Index ¼¼ 5), proceed to collect the system flow time (sojourn time in all five workstations) for this product unit, and then restart another sequence of processes.

To this end, the unit entity enters the third module in the loop, namely, the Decide module called Not Done Yet. Figure 11.21 displays the dialog box for this module. Note that this Decide module implements a two-way decision (in the Type field), controlled by a (logical) expression (in the If field) specified as Proc_Index < 5 (in the Value field). If the value of this expression is false (i.e., Proc_Index ¼¼ 5 is true), then the unit entity processing is essentially complete, with only a few remaining housekeeping chores left.

Figure 11.20 Dialog box of the second module (Delay) in the loop.

Modeling Production Lines 245

Figure 11.21 Dialog box of the third module (Decide) in the loop.

Specifically, the unit entity will proceed in this case to the Release module, called Release Last Process, to release the last resource, and will enter the Record module,

called Flow Time, to collect the next system flow-time observation, before routing to the Assign module, called Assign Process Index and Time, for the next tour through all five workstations (new job processing). However, if Proc_Index < 5 is true, then the unit entity proceeds to the fourth module in the loop, namely, the Hold module called See if Process is Blocked; see the module's dialog box in Figure 11.22. In this module, the unit entity checks whether the next workstation (indexed by Proc_Index þ1) is full (i.e., that transfer to the next process is blocked), by checking the logical expression in the Condition field,

Figure 11.22 Dialog box of the fourth module (Hold) in the loop.

246 Modeling Production Lines

nq(Proc_ Index þ 1) < Buffer Caps(Proc_ Index þ 1):

Recall that Buffer Caps is an expression vector holding buffer capacities, which were previously initialized by the modeler. Note carefully that blocking queue indexes are specified by expressions (Queue Type field) whose values are given by Proc_Index þ 5 (Expression field). Thus, this Hold module is used for all processes, except for the last one; it holds a blocked unit entity at queue Proc_index þ5 until the next workstation has room to accommodate it.

As soon as the next workstation is found to have room (i.e., the next process is found to be nonblocking), the unit entity will move to the fifth module in the loop, namely, the Release module, called Release Process, to release the current resource (the one indexed by Proc_Index). The unit entity then proceeds to the sixth and last module in the loop, namely, the Assign module called Next Process, where the unit entity's attribute Proc_Index is incremented by 1, thereby pointing at the next workstation (process) to visit. Finally, the unit entity completes the loop by returning to the first module in the loop, namely, the Seize module, called Seize Process, to start the next loop iteration.

A comparison of run results of the equivalent packaging line models of Figures 11.2 and 11.17 shows that they produce identical statistics, as expected.